Hace poco leí una noticia sobre software libre y sus implicaciones en ciencia. En ocasiones he trabajado en proyectos, con esta filosofía, sin conocer muy bien luego lo que implicaban. Ya pasado un tiempo, conoces lo que ocurre y te mentalizas de otra forma.
Una de los ejemplos que comentan es sobre la primera foto de un agujero negro que se tomó, que no hubiera sido posible sin el procesado con Matplotlib que “es una biblioteca para la generación de gráficos a partir de datos contenidos en listas o arrays en el lenguaje de programación Python y su extensión matemática NumPy”. Pues 5 días después la NFS (la Fundación Nacional de Ciencias de Estados Unidos) rechaza una propuesta basada en este sistema de software libre.
Y es que el software libre implica un problema, a priori, que dependerá sobre todo de sus creadores o creador/a. El software libre, una vez que se libera puede ser usado. En ocasiones, puede ser usado por muchas personas, y al final eso se traduce en localización de bugs, mejoras, que van a salir a la luz, y preguntas. Y esto se convierte en tiempo, tiempo invertido por sus creadores para aplicar estas mejoras o solventar problemas; tiempo que, lamentablemente, y en un gran porcentaje, no es pagado y es tiempo libre, con lo cual, al final el creador/a desiste o deja a la deriva el proyecto.
Hace poco, estuve probando mailpile, una idea genial que te crea un gestor de correos en tu servidor. Le di un tiempo prudencial para probarlo, hasta darme cuenta de que su creador había sucumbido al éxito. La idea era tan buena, la base es tan buena, que por lo que veo y entiendo, no puede dedicarle todo el tiempo libre que quisiera, por lo que muchas veces el trabajo solucionando errores o problemas es de otros, que contribuyen al código abierto. Al final la inestabilidad del mismo me obligaron a desistir. En la actualidad tiene más de 300 “tickets” con problemas y más de 1200 cerrados. Mucho tiempo y mucho esfuerzo, sin remuneración, pero sigue en activo poco a poco.
Otros, que seguro conocéis mejor, son WordPress o Prestashop, este último ha hecho un brutal esfuerzo en dar el salto de su versión 1.6 multiconocida a una versión 1.7 que cambió o rompió mucho con la opinión de los usuarios, en pro de crear sus propios paquetes de módulos para venderlos o quitar funcionalidades que ahora son de pago.
La idea es poder generar un modelo sostenible de trabajo remunerado abriendo el código de su software. ¿Qué permite esto? Pues permite que hay una comunidad que se beneficia del conocimiento de estos programas (y de su código) y que se ganan la vida ayudando a otros con ellos o creando módulos/plugins para venderlos. Pero también permite ver su código, es decir, ni todo es malo ni todo es bueno. Por un lado, te beneficias de que hay mucha más gente viendo tu código por lo que puedes detectar bugs o fallos de seguridad antes; por otro lado, tu código está abierto. Si alguien encuentra un agujero de seguridad y no lo publica, puede utilizarlo. Algo así pasa con muchos plugins de WordPress. Ahora están intentando crear una sistemática para quitar de su repositorio plugins con fallos de seguridad detectados. ¿Qué pasa con esto? Imagina un plugin que han instalado miles de personas, en ocasiones cientos de miles. Una persona que quiera colar su código, tiene un agujero de seguridad y cientos de miles de posibles huéspedes, por lo que empiezan a ser atractivos para este tipo de atacantes. Y dirás ¿pero si yo no tengo nada en mi web? Ya, pero a veces persiguen otros propósitos: uno puede ser tomar el control de tu servidor y enviar spam, con el consecuente ingreso en listas de spam, bloqueo de cuentas y del servidor por tu proveedor; en otras ocasiones es colar páginas de pishing o spam en tu web, y usarte de almacenamiento de spam; o en otras ocasiones y si tienes muchas visitas es usar tu posicionamiento para aparecer en buscadores o cambiar tu página principal o los enlaces de tu página para poner publicidad y convertirte en una gran página de venta de viagra u otros medicamentos.
En ciencia pasa lo mismo, existen programas que se usan y son libres, algunos desarrollados por personal de organizaciones importantes, otros por científicos independientes. Lo que ocurre muchas veces es que en ocasiones las buenas prácticas a la hora de hacer el código no son las mejores; o tienen problemas para mantener un lugar donde alojar copias o el propio código, o simplemente se ven abrumados por tantas horas en el soporte invertido o por las consecuencias de tener que dedicar muchas más horas de las esperadas. Muchas veces toca entrar en un sistema de control de versiones en el que no todo el mundo está preparado para trabajar o no saben correr las pruebas necesarias para garantizar que el código funcione sin problemas, o no hay tiempo para desarrollar una documentación que ayude al usuario y que resuelva dudas antes de que se pongan a buscar donde preguntarte.
Aunque en otras ocasiones esto no es así y se consigue un método de trabajo, que ayude a conciliar tiempo y remuneración, en ocasiones, consiguen un modelo de negocio que mantiene al personal trabajando.
Por poner algunos ejemplos de programas que son libres y de mucha utilidad:
- Cellprofiler – https://cellprofiler.org/ Con este programa puedes medir cuantitativamente diferentes tipos de células a partir de imágenes de forma automática.
- PHAST – Programa que simular el flujo de agua subterránea, transporte de solutos y reacciones geoquímicas multicomponentes. Ver aquí
- PHASTER (PHAge Search Tool Enhanced Release) Es un servidor para la rápida identificación y anotación de secuencias de fagos en genomas y plásmidos bacterianos. http://phaster.ca/
Finalmente, existen muchos proyectos de software libre, muchas bases de datos o programas. Si te decides por este camino, no es sencillo, pero es un camino donde aprendes mucho y creces profesionalmente, y en ocasiones, haces algo que nadie antes hizo. Sigue esta guía de buenas maneras para el desarrollo de software. Tu proyecto te puede abrir las puertas a otros trabajos o si todo va bien, puedes convertirlo en tu trabajo a tiempo completo.