Archivos y software libre
Por Ricardo Eíto-Brun16 December 2009
Con bastante frecuencia, desde las páginas de El profesional de la información y desde los foros profesionales, se hace referencia a las ventajas que ofrece el software libre, especialmente para aquellos centros con presupuestos ajustados, y que a priori no pueden afrontar los costes que supone el despliegue de una aplicación comercial.
Erróneamente, se sigue asociando software libre con gratuidad. Aunque estos dos términos suelen ir unidos, y el idearium colectivo piensa en el “coste cero” como primera ventaja de estos programas, ésta no debería ser la base de nuestras preferencias a la hora de optar por el uso de este tipo de herramientas.
Es cierto que las organizaciones que distribuyen su software bajo licencias libres evitan el desembolso de ciertas cantidades en concepto de licencias, pero no es menos cierto que el despliegue de un sistema informático libre, y su parametrización y adaptación a las preferencias de cada centro, sigue exigiendo un esfuerzo, inversión y capacidades técnicas que no siempre están al alcance de pequeñas bibliotecas y archivos.
Otro inconveniente asociado al software libre es la falta de confianza que genera el no saber las intenciones y la capacidad de sus fabricantes para garantizar la continuidad de sus desarrollos. ¿Quién está detrás de un determinado programa? ¿Tiene solvencia para asegurar la evolución y el mantenimiento del mismo? ¿Se seguirá prestando servicio dentro de cierto tiempo? ¿Corregirán los problemas y adaptarán el programa a la evolución futura de los estándares?
Son dudas razonables que hacen que exista cierto recelo sobre la viabilidad de muchos programas libres y la conveniencia de adoptarlos. Este inconveniente se compensa parcialmente si se crean grupos de usuarios del programa que compartan nuevos desarrollos.
Aun siendo conscientes de estos inconvenientes, es aconsejable estar pendiente de las distintas iniciativas libres que se lanzan, conocer su evolución y ver en qué medida estas herramientas pueden sernos útiles para asegurar una gestión eficiente de la información y prestar mejores servicios a los usuarios.
Software libre para archivos
Entre las iniciativas software libre más interesantes desarrolladas en los último años se encuentran los programas para archivos, con tres casos especialmente relevantes: ArchivstToolkit, Archon y el programa ICA-AToM (Access to Memory) del International Council of Archives (ICA).
Archivist Toolkit es el resultado del trabajo conjunto de Five Colleges, Inc., la New York University Libraries y las Ucsd Libraries. Se viene desarrollando desde el año 2006 bajo el patrocinio de la Andrew W. Mellon Foundation. Recientemente se concluyó la segunda fase de este proyecto con la versión 2.0 del programa, publicada a finales de septiembre de 2009.
Archon también se ha producido en el entorno académico, concretamente, por la Uiuc Library (University of Illinois at Urbana-Champaign), e igualmente con el soporte económico de la Andrew W. Mellon Foundation. La última versión publicada de este software -en abril de 2009- es la 2.23.
Finalmente, del software del ICA únicamente comentaremos que aún se encuentra en estado beta (es decir, versión preliminar), a pesar de que su presentación oficial se hizo hace ya un año, en diciembre de 2008 como parte del DLM Forum en Tolosa (Francia).
Aunque un resumen exhaustivo de las capacidades de estos programas excede el objetivo de esta nota, sí comentaremos que Archivist Toolkit ofrece una interfaz gráfica que nos permite completar con facilidad descripciones de fondos (o de otras unidades) compatibles con el estándar EAD (Encoded Archival Description). También permite establecer listados de autoridades para nombres de personas, entidades, familias, temas, lugares, etc., y asegurar así la homogeneidad de las descripciones.
Además de facilitar la descripción, Archivist Toolkit incorpora funciones adicionales para registrar los ingresos de documentos y generar visualizaciones html y exportar datos a EAD o Marc.
Estas funciones resultan especialmente útiles para facilitar la posterior publicación de las descripciones vía web, compartirlas con otros centros o generar productos impresos tipo guías o inventarios.
Un aspecto claramente mejorable de Archivist Toolkit es su capacidad de dar visibilidad en la Web a las descripciones, ya que el programa exige una conversión y posterior publicación en un sitio web, y no incorpora ninguna función para la publicación inmediata ni para la búsqueda de descripciones a través del web.
Ese aspecto mejorable de Archivist Toolkit es el punto fuerte de Archon. Este programa ofrece una interfaz (en este caso 100% web) para crear descripciones, de tal forma que éstas están disponibles de manera inmediata para los usuarios que accedan vía web. Archon también incorpora un sistema de búsqueda a texto completo y distintos mecanismos de navegación mediante índices.
La gestión de listados de autoridades y la importación y exportación de descripciones a distintos formatos (incluyendo EAD y Marc), están igualmente soportadas por Archon.
La integración de Archivist Toolkit y Archon
Existen por tanto similitudes entre los dos programas, pero una importante diferencia: mientras Archivist Toolkit es un sistema orientado a la creación de descripciones y no incorpora funciones para la publicación en la Web más allá de la exportación de las descripciones a EAD/html, Archon está orientado a la publicación y recuperación de las descripciones en la Web.
El pasado 30 de octubre el equipo de trabajo de Archivist Toolkit publicó un primer borrador con los requisitos y especificaciones que la futura integración de estos dos programas tiene previsto ofrecer (curiosamente, no se ha dado a esta noticia una visibilidad semejante en el sitio web de Archon). El objetivo del borrador es fomentar la discusión entre los grupos de usuarios para identificar funciones que o bien se hayan pasado por alto o bien se hayan identificado pero se juzguen innecesarias.
La intención de integrar los desarrollos de Archivist Toolkit y Archon había sido anunciada con anterioridad, concretamente el 18 de agosto de 2009, y era una consecuencia lógica de la necesidad de optimizar los resultados del soporte económico que la Alfred W. Mellon Foundation estaba ofreciendo a estos dos proyectos.
Respecto al contenido del borrador con las especificaciones, no se trata de un documento sumamente detallado, sino de una hoja Excel con funciones identificadas de manera general, y organizadas en siete grandes áreas:
1) Funciones del archivo, donde se incluye un repertorio de los datos que el programa debe ser capaz de gestionar. Abarca aspectos tales como: datos organizativos del centro, usuarios, estadísticas, colecciones, valoraciones, ingresos, cuadros de clasificación y listados de autoridad.
2) Importación, con los distintos tipos de formatos que el sistema debe ser capaz de reconocer para facilitar la recepción de datos. Se incluye la capacidad de importar datos EAD, Marc, y de las bases de datos existentes en Archivist Toolkit y Archon.
3) Exportación, similar al anterior; se enumeran los formatos a los que debe poder exportarse: EAD, Marc, EAC, Mods, pdf, etc.
4) Informes; con un total de 54, se cubren distintos aspectos relacionados con la gestión del archivo.
5) Hojas de estilo, para facilitar la visualización de los datos en formato EAD, EAC, html y pdf.
6) Funciones de aplicación genéricas para la parametrización del programa (funciones de la interfaz de usuario, ayuda en línea, etc.).
7) Acceso web, donde se reúnen requisitos relativos a la capacidad para publicar contenidos y dar servicios a través de la Web. Especifica contenidos de la página home, opciones para la búsqueda, hiperenlaces que deben estar disponibles para explotar las relaciones entre los distintos ítems de los que se guarda información, etc.
A pesar de ser un borrador inicial y de estar redactado de forma general, se trata de un documento de interés ya que puede servirnos no sólo para conocer las futuras prestaciones del software resultado de esta integración, sino también como guía para evaluar las características de otros programas informáticos y para identificar posibles mejoras en sistemas existentes.
Falta esperar a ver cómo se desarrollan los acontecimientos y conocer el plan de evolución de este nuevo producto. Disponer de una planificación detallada y tener una visibilidad de su estado es, sin duda, una de las acciones que más puede contribuir a aumentar la confianza de la comunidad de usuarios en un programa basado en software libre.
Aquellos proyectos que no ofrezcan esta visibilidad y nivel de confianza difícilmente pueden convertirse en alternativas, ya que irremediablemente siempre existirá cierta sospecha o duda sobre la viabilidad real de los programas desarrollados bajo este paradigma.
1. http://www.archon.org
2. http://www.archiviststoolkit.org/
3. http://www.ica-atom.org
4. http://www.loc.gov/ead/
Ricardo Eíto-Brun
Miembro del Grupo ThinkEPI
documenéame -
Otras aportaciones
TÍPICOS TÓPICOS ACERCA DEL SOFTWARE LIBRE
Por Oskar Calvo
Creo que hay un gran problema con el software libre, y es la idea de que software libre es software gratuito o económico, no es cierto, sólo hay que ver el precio de implementar Plone/Zope, Fedora, DSpace, etc.
La única ventaja del software libre sobre las herramientas propietarias es que se puede acceder al código fuente (es una ventaja en muchos aspectos), y que se puede conseguir distribuciones más o menos completas de las mismas, que a diferencia de los productos privativos, no son demos con tiempo de caducidad o que tienen limitadas las funcionalidades.
A la hora de probar un producto es muy importante tener acceso al mismo de forma completa, y no sólo parcial, además de no tener limitado el acceso al mismo de forma limitada en el tiempo.
Curiosamente, y siempre lo defiendo, lo comento y lo digo, en las 4 libertades que defiende el software libre no se menciona precio cero o gratuidad. Ojo, libre distribución no implica que no exista un coste del mismo.
Está claro que una cosa es ofrecer un producto de libre acceso y otra cosa muy diferente es trabajar de forma gratuita, por favor, seamos serios, si las empresas que trabajamos con software libre no cobrásemos por nuestro trabajo, no existiríamos.
El problema que realmente se tiene son los conceptos:
Software libre = software gratuito.
Software libre = profesionales cobran menos.
Son dos ideas que se tienen que quitar de la cabeza, porque no es así.
Otro inconveniente asociado al software libre es la falta de confianza que genera el no saber las intenciones y la capacidad de sus fabricantes para garantizar la continuidad de sus desarrollos. ¿Quién está detrás de un determinado programa? ¿Tiene solvencia para asegurar la evolución y el mantenimiento del mismo? ¿Se seguirá prestando servicio dentro de cierto tiempo? ¿Corregirán los problemas y adaptarán el programa a la evolución
futura de los estándares? Son dudas razonables que hacen que exista cierto recelo sobre la viabilidad de muchos programas libres y la conveniencia de adoptarlos. Este inconveniente se compensa parcialmente si se crean grupos de usuarios del programa que compartan nuevos desarrollos.
Siento decir que el párrafo anterior es un mero panfleto propagandístico a favor del software propietario, lo cierto es que las mismas preguntas que te haces sobre el software libre te las deberías hacer sobre el software propietario.
Un ejemplo, Microsoft ha estado durante 10 años con un error de seguridad grave en su reproductor multimedia y no quiso invertir en arreglarlo; eso es confianza.
Otro ejemplo de confianza es Windows Vista, nos deberíamos plantear qué empresa se atreve a sacar un SO que tiene menos compatibilidades que el anterior.
Volviendo a la continuidad del software, ni empresas privadas ni de software libre aseguran la “vida” de un producto, si el producto no vende se cierra y los usuarios que lo tienen sólo podrán protestar.
La diferencia: un producto de software cerrado, si cierra, cierra y no se puede hacer nada, no se tienen acceso al código fuente ni se tiene derecho para modificarlo. Un producto de software libre, si cierra, se puede seguir con el proyecto mediante otras personas u instituciones, ya que si pueden tocar, modificar, distribuir el código fuente nuevo.
Un ejemplo de ello es el producto Docmanager, que ha sufrido sus más y menos, pero que al ser software libre diferentes personas se han encargado de mantener el proyecto.
Sobre estándares se sabe -y está demostrado- que es el software libre quien trabaja con ellos, ya que dichos estándares facilitan el desarrollo y la conexión con otros equipos.
El software propietario huye de los estándares porque los ven como un problema, ya que puede ser un “atentado” contra sus productos. Un ejemplo de ellos son los diferentes e infumables Internet Explorer 5, 5.5, 6, 7 y 8, que para nada respetan los estándares del W3C.
Lo dicho, son dudas razonables para todo tipo de programas, con la salvedad de que en este punto el software libre tiene la ventaja de poder continuar el proyecto; un ejemplo de ello es Firefox, que es la evolución de Netscape, ya que cuando éste “cerró”, liberó el código fuente y surgió el proyecto Firefox, que ahora mismo se está posicionando como el navegador más utilizado, seguro y fiable.
Respecto a Archivist Toolkit, éste es una aplicación de escritorio, construida en Java, y no es para nada una aplicación web; hay que entenderla como tal: una herramienta para generar “registros” en formato EAD y, por lo tanto, pedirle que publique en web, eso es otro cantar.
Lo que hecho de menos en Archon, y que no parece que se vaya a desarrollar, es un mayor control de los records, ya que ahora mismo (versión 2.2 es la que estoy manejando) los records o son públicos o privados, no existe acceso a los mismos por roles o usuarios, y es algo necesario al menos en España.
Archon tiene un serio problema, y es que no está programado como MVC, es decir, que tienen todo mezclado y es muy complicado separar el código php de la plantilla html.
Respecto al borrador, aunque es un buen documento de partida para valorar otros softwares, considero que no hay que olvidar que cada valoración se hace en base a las necesidades concretas de un archivo, y por lo tantom hay que analizarlos desde diferentes puntos de vista, tanto softwares libres como privativos.
Siento comentar que este ThinkEPI me parece algo pobre, la primera parte del mismo cae en errores de típicos tópicos sobre el software libre, que para una persona que empieza de cero podrían ser hasta creíbles, pero muchas de las ideas que se han planteado en la primera parte del documento se han
hablado y discutido en esta lista, mil y una veces, y puedo asegurar que en dichos debates se ha demostrado sobre la seguridad/inseguridad de ambos tipos de software, sobre los desarrollos de proyectos, etc.
La segunda parte del documento, aunque me ha gustado más, lo cierto es que le hecho en falta un mayor detalle de las debilidades y amenazas que tienen las tres aplicaciones, Aunque solo he trabajado con Archon e Ica-Atom, sé muy bien de qué pie cojean y cuáles son los problemas de ambos, y me asombra que no se hayan resuelto, sobre todo porque algunas de ellas se han planteado a los desarrolladores.
ADAPTAR EL SOFTWARE A CADA CENTRO DE INFORMACIÓN Y NO AL CONTRARIO
Por Julián Moyano
Desde mi pequeña experiencia con el software libre, creo que es la única alternativa al desarrollo e innovación en los archivos, bibliotecas y otros centros de información.
Cada institución requiere de unas necesidades concretas y particulares (aparte del uso de estándares y normas), con unos servicios a desarrollar específicos e individuales. El software propietario nos da un programa que solamente podemos utilizar, tal y como es, enlatado, sin posibilidad de cambios, mejoras y “customizaciones”.
Nuestras quejas/sugerencias siempre serán tenidas en cuenta para las nuevas ediciones, que tampoco garantizarán cubrir nuestras cambiantes expectativas.
El software libre, no. Te ofrece un programa y tú lo puedes adaptar, cambiar y modificar a tus necesidades, por muy exigentes, cambiantes y “raras” que sean, (por eso no es gratuito como bien dice Oskar), para así acoplar el software a cada centro de información y no al contrario, esa es para mi una de las mayores ventajas del software libre.
Estos cambios, para adaptarlos a cada necesidad, hacen que mejore, innove e incluso se distribuya, etc., creciendo constantemente con el aporte de todos, para convertirse así en un programa que no solamente satisface una necesidad muy concreta (la que ofrece el código propietario), sino muchas, variadas, distintas, y diferentes.
SERVICIOS PROFESIONALES EN TORNO AL SOFTWARE LIBRE
Por Ricardo Eíto-Brun
Es costumbre que los autores de contribuciones a ThinkEPI respondamos a los mensajes de respuesta que envían los lectores del foro.
Por este motivo, y en relación al mensaje en el que comentábamos la próxima integración de Archon y Archivist Toolkit, respondemos a los dos mensajes de nuestros compañeros Julián y Oskar.
Julián ha señalado acertadamente la relación entre software libre e innovación. La capacidad de adaptar libremente los programas informáticos nos permite afrontar nuevos retos y dar respuesta a los problemas actuales y futuros de cada centro.
En relación al mensaje de Oskar, estamos totalmente de acuerdo en el derecho que tienen las personas que desempeñan su actividad profesional en torno al software libre a ganarse la vida dignamente.
Ofrecer servicios profesionales en torno a estos programas es una actividad lucrativa igual de digna que optar por vender licencias, y como señala Oskar, igualar las empresas que trabajan con software libre con ONGs y entidades caritativas
Es un tópico tan burdo y erróneo como el de pintar continuamente a Microsoft con cuernos y rabo.
Debo decir, sin embargo, que no me parecen correctas, ni en su forma ni ajustadas al contenido del texto objeto de crítica, las opiniones sobre otras partes del texto, si bien me consta que lo desacertado de la redacción no corresponde a ningún tipo de animosidad y que no se ha hecho con mala intención; pienso, más bien, que puede tratarse de un problema de expresión, quizás debida a la rapidez con la que tendemos a actuar en los entornos “online”.
Sinceramente, creo que ningún lector que haya leído el mensaje pensará que se pueda adjetivar al texto de panfletario. Panfletario no lo es, porque no somos, en este tema, ni juez ni parte.
Señalar que la mencionada primera parte contiene “numerosos errores que pueden conducir a engaño a quienes se aproximen por primera vez al software libre”, también me parece un comentario anormal: cualquier persona que haya leído el texto con una mínima atención habrá observado todos los puntos que se señalan a favor del software libre (y que son los normalmente reconocidos). Incluso esos puntos a favor son mucho más
numerosos que los que el texto puede señalar en su contra.
Sobre éstos, negar que muchas organizaciones y personas tienen dudas sobre la viabilidad de determinados proyectos software libre sería simplemente negar un hecho objetivo.
Afortunadamente, cada día contamos con un mayor número de profesionales que optan por hacer del software libre desarrollado por otros su medio de vida, y confío firmemente en que su buen hacer hará que esta desconfianza sea, día a día, cada vez menor.
Para cerrar este punto, pienso que la primera parte del texto podría tacharse de breve, escueta o sucinta, pero nunca de “pobre”.
Ha sido sin embargo enormemente satisfactorio para mí saber que la segunda parte del artículo sí ha resultado del agrado de Oskar. Me parecen muy acertados los aspectos que ha señalado que deben mejorar los dos programas que mencionábamos en la noticia.
Conocer las debilidades y amenazas de estos programas es un gran punto de partida, porque -tratándose de software libre-, incluso si sus desarrolladores caen en la tentación vanidosa de no atender a nuestras sugerencias y críticas, disponemos del código fuente para poder corregirlas por nosotros mismos que, a fin de cuentas, es de lo que se trata.
LA CONTINUACIÓN DE PROYECTOS DE SOFTWARE LIBRE
Por Oskar Calvo
Respecto a mi correo electrónico, en ningún momento he querido faltar al respeto a nadie, ni mucho menos, sobre todo teniendo en cuenta que Ricardo y yo estuvimos conversando en las Jornadas Archivando, montadas por la Fundación Sierra-Pambley en León.
Pero me choca que cuando se hablase de la viabilidad de los proyectos de software libre se cayese en un tópico. Y digo tópico porque en esta lista de correo ya se ha hablado en el último año sobre la continuidad del software libre, y en los pros y contras sobre la continuación de proyectos de software libre y software privativo, creo que todos aceptamos lo siguiente.
Tanto el software libre como el software privativo tiene el problema de la continuidad, nadie puede asegurar que pueda asegurarse la continuidad de nada, ni siquiera Microsoft o Google pueden asegurar la continuidad de los mismos, ejemplos de ello son los fiascos tanto de uno como de otro, por lo tanto, si estos dos “pesos pesados” no son capaces de mantener sus propias aplicaciones, pensar que otras pueden hacerlo es una entelequia.
Pensar que el software libre es menos fiable en cuanto a la continuidad del producto es una idea que se sustenta con pinzas muy finas; como ya se ha dicho, tanto uno como otro depende de los desarrolladores, inversores y ventas del mismo. En caso de un software privativo sean licencias, desarrollos, servicios, formación. En el caso del software libre servicios, formación, desarrollos.
Una vez que hemos visto que ambos tipos de software tienen el mismo problema, que es el de la continuidad, y les afecta de la misma forma a ambos. Veamos las ventajas que tiene el software libre sobre el software propietario al respecto.
Cuando un proyecto de software privativo cierra su continuidad se considera muerto, ya que no se tiene derecho a continuar con el proyecto, modificar el código fuente o distribuirlo de forma legal.
Un proyecto de software libre que ha cesado en su desarrollo o mantenimiento puede ser retomado por otra empresa, persona, comunidad, etc. Recordemos que las 4 libertades del software permiten que este tipo de “resurrecciones” sean posibles y legales.
Como he dicho, todo esto se planteó en su día en esta lista de debate, creo que obviar estas 4 ventajas en la posibilidad de continuidad del software libre respecto del software propietario deja cojo el ThinkEPI, y es el motivo por el cual lo planteé como “panfleto”, ya que se obvia la realidad y se cae en un tópico difundido por Microsoft: “el software libre no tiene continuidad”.