No sé mucho de informática. Es más, realmente sé muy poco, creo que como la mayoría de profesionales del mundo bibliotecario. Pero no es algo de lo que me sienta orgulloso. Nos guste más o menos, el mundo está inundado por la informática y resistirse a ello es una especie de anacoretismo del siglo XXI ausente de sentido.
No creo que me pase diciendo que tener conocimientos de informática y, concretamente de bases de datos, se está convirtiendo en algo inexcusable. Sólo basta con ver la literatura científica que se está produciendo en el ámbito de las ciencias de la información (a mi entender, término más amplio y correcto que Biblioteconomía). Considero que no sólo basta con tener conocimientos iniciales de lógica y de informática. No creo que deba estar muy lejos el día en que más de uno de nosotr@s esté picando códigos. De lo contrario, dentro de una década nos estaremos quejando de que los informáticos son “intrusos” en el mundo bibliotecario (si no lo son ya).
¿Y todo este exordio a qué viene? Tiene su razón de ser. Imagino que muchos conoceréis el SIGB (Sistema Integrado de Gestión Bibliotecaria) de código abierto KOHA. Se trata de uno de los proyectos más exitosos. Sin embargo, actualmente no es segura su continuidad.
Su historia se remonta a 1999. La empresa neozelandesa de comunicaciones Katipo, encabezada por el desarrollador Chris Cormack, fue contratada por la Fundación de la Horowhenua Library para realizar un SIGB y para liberar el código de éste bajo una licencia de código abierto. El año 2000 se hizo pública la primera versión. El proyecto Koha fue creciendo en los años sucesivos, y surgieron varias empresas dedicadas a ofrecer soporte y servicios de personalización a Koha (desde el seguimiento de las adquisiciones hasta la integración con los sistemas de catalogación de otras bibliotecas).
En 2005, uno de los desarrolladores de Koha, Ferraro Josué, que a su vez era propietario de una de esas empresas de soporte, concretamente Liblime, adquiere los activos de Katipo en Koha, incluidos los derechos de autor sobre el código fuente Koha. Además se hace cargo del sitio web koha.org. Posteriormente, la vida siguió igual, con Liblime participando en el desarrollo de Koha, de la misma manera que otros negocios, personas y bibliotecas lo habían hecho hasta entonces.
Los problemas comienzan cuando Liblime (propiedad de Ferraro Josué) anuncia a mediados de 2009 que ofrecerá a sus clientes una versión de Koha construido a partir de una git privada, en lugar del código fuente público gestionado por la comunidad de desarrolladores. La mayoría de ellos consideran que con este anuncio Liblime se salía del proyecto Koha. Ferraro Josué afirmó que esto no era así. Y dio diferentes razones para mantener un código base independiente: la necesidad de cumplir con los plazos de las cargas de trabajo, la falta de un control de calidad para las contribuciones de la comunidad, y la confidencialidad de los datos de los clientes. Pero Ferraro dijo seguir comprometido con el movimiento de código abierto y que Liblime publicaría sus aportaciones a Koha.
Sin embargo, Liblime no ha publicado sus aportaciones desde junio de 2009 y el código fuente de Liblime sigue inaccesible para el público.
Ante estas circunstancias, la comunidad de desarrolladores temió por el futuro del proyecto y creó un nuevo dominio, Koha-community.org. Siguieron desarrollando Koha con una versión 3.2, paralela al desarrollo de Liblime.
Las desavenencias parecía que iban a salvarse cuando la empresa Progressive Technology Federal Systems anunció a comienzos de 2010 que iba a adquirir Liblime, y dijo que liberaría el código. Pero al poco tiempo aparecieron conflictos sobre la ubicación del repositorio del código fuente y algo más tarde Progressive Technology afirmo que su nueva versión era superior a la de la comunidad.
Como afirma Nathan Willis, Koha no es el primer proyecto de código abierto que pasa por el problema de la división de parte de la comunidad. Y nos explica las claves de esta problemática.
Como dice, no hay manera de impedir que personas o empresas que han colaborado en un proyecto de código abierto sean hostiles. Pero una de las claves era la excesiva vulnerabilidad de Koha al comportamiento de Liblime. Dicha debilidad se sustanciaba en:
-Por un lado, controlaba y gestionaba el sitio web de la comunidad, koha.org.
-Por otro lado, al adquirir los activos de Katipo, Liblime creía que tenía derecho a crear un código cerrado propietario de Koha, incluidos los derechos de autor. Nadie de la comunidad se preocupó de solucionar las cuestiones legales para evitar estos problemas. Se trata de algo que lleva mucho tiempo y que es costoso económicamente. La consecuencia de ello es que el proyecto Koha corre serio peligro.
Para que no ocurra lo mismo en otros proyectos, Roy Tennant nos da algunas claves.
-Tiene que haber una comunidad comprometida para que el código fuente siga vivo.
-Ha de establecerse unos objetivos claros para la integración de las mejoras y la corrección de los errores. Así las personas que quieran contribuir al desarrollo del código, sabrán cómo hacerlo.
-Ha de haber varios testadores o confirmadores del código, así como establecer claramente los pasos para llegar a ser confirmador del código.
-Supresión de cualquier licencia o marca registrada.
-Supresión de cualquier tipo de propiedad sobre el código fuente.
-Aportar soluciones a los problemas que planteen otros colaboradores u otros clientes. Es decir, que se realicen actualizaciones.
-Algo obvio, pero no por ello menos importante: la elaboración de una buena documentación, para que cualquier cliente sepa cómo configurar, instalar y utilizar su aplicación.
De la misma manera que ocurre con las licencias Creative Commons o con la iniciativa Open Access para la investigación científica, el código abierto no es la piedra filosofal. Es sólo una opción entre otras, con aspectos positivos y negativos. Lo más importante para una biblioteca es saber quién le va a proporcionar soporte técnico y cómo van a ser tratadas sus peticiones y mejoras. Tener la seguridad de que nuestro SIGB no se va a quedar “tirado” en ningún momento es crucial. De momento, la apuesta mayoritaria en España para SIGB es de software propietario. Posiblemente, el código abierto para SIGB podría prosperar si está auspiciado y financiado por un organismo público o por fundaciones. Ojála que dentro de poco muchos bibliotecarios estén participando en alguno de estos proyectos, no sólo como asesores, sino como colaboradores activos. Es cuestión de ampliar nuestros conocimientos, de nosotr@s depende.
Nota: para la elaboración de este artículo he utilizado los textos de Roy Tennant (Library Journal, 14 de mayo) y de Nathan Willis (LWN.net, 5 de mayo).
No hay comentarios:
Publicar un comentario