Archivos y software libre

Resumen:
La aplicación del software libre en archivos se relaciona normalmente con el uso de las aplicaciones desarrolladas por dos proyectos ya emblemáticos en la comunidad profesional: Archivist Toolkit y Archon. En agosto de 2009 se anunció la próxima integración de estas dos iniciativas, y dos meses más tarde se publicó el primer borrador con las especificaciones del software que resultará de esta integración. Esta contribución resume las características anunciadas en este primer borrador. El autor también señala la necesidad de que los gestores del proyecto hagan pública una planificación y un calendario detallado que ofrezca garantías a la comunidad de usuarios, y que contribuya a eliminar las posibles dudas sobre la viabilidad del proyecto.

Archivos y software libre



Cómo citar este artículo:
Eíto-Brun, Ricardo. «Archivos y software libre«. Anuario ThinkEPI, 2010, v. 4, pp. 195-199.

4 Replies to “Archivos y software libre”

  1. 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.

  2. 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.

  3. 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.

  4. 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».

Comments are closed.