¿Cuándo un proyecto se puede considera Open Source?
¿Qué significa que un proyecto sea Open Source? ¿Basta con liberar el código o hay algo más? ¿Cuáles son los beneficios de un proyecto de este tipo?
Hace tiempo que llevo dándole vueltas a este tema y creo que se merece una reflexión más larga que un tuit. Después de participar en la FOSDEM este fin de semana -y en mayor medida tras una interesante charla del grupo TODO-, me he animado a poner mis pensamientos negro sobre blanco.
Hace ya unos meses, dirigentes de todo el mundo se pusieron manos a la obra para trabajar en aplicaciones para móvil que facilitasen el rastreos de contactos con positivos por COVID-19. En particular, mi reflexión viene tras observar de cerca como ha evolucionado el proyecto de la(s) aplicación(es) de rastreo de contactos que ha impulsado el Gobierno de España, Radar COVID. Como muchos sabréis, hubo cierta polémica por varios motivos: el primero es la discusión que se generó entorno a la privacidad de los usuarios, el otro motivo es la forma (y suma) de la concesión.
Con respecto a este último, quiero recordar que la concesión se le hizo a Indra por una cantidad de 330,000 € y sin concurso público de por medio (gracias al llamado procedimiento de emergencia). Es más, al pasar unos meses se amplió el contrato por 1,4 M€ para mantener el código. Podemos estar más o menos de acuerdo con la forma, las cifras o las condiciones, no voy a entrar en este tema porque no es el objetivo, lo que sí creo que tenemos que plantearnos es si un proyecto en el que se busca la transparencia (en este caso mediante el Open Source), es compatible mecanismos de concesión en los que el tiempo de ejecución está acotado y es muy difícil fomentar la colaboración con gente externa al proyecto.
El otro aspecto de discordia tiene que ver con la privacidad. Se habló de protocolos centralizados o descentralizados y tras un breve e infructuoso intento se apostó por la versión descentralizada basada en DP-3T (Decentralized Privacy-Preserving Proximity Tracing). Esta fue la primera parte de la discusión, pero además, el gran público comenzó a mencionar la necesidad de liberar el código. ¡Incluso los medios generalistas se hicieron eco múltiples veces! ¿Quién iba a pensar que el ecosistema Open Source se volvería algún día mainstream?
¿Quién iba a pensar que el ecosistema Open Source se volvería mainstream?
Y efectivamente, el código se acabó liberando bajo una licencia MPL 2.0. Tan pronto como se hizo esto la discusión se desvaneció de los medios y el gran público se dio por satisfecho. Pero, ¿ya está? ¿Es RADAR Covid un proyecto Open Source? ¿Está la privacidad de los usuarios más protegida?
Vamos allá. Desde que se liberó el código y la primera versión de la aplicación, ha habido tan sólo 4 actualizaciones de la misma (para Android). Es más, tomando por ejemplo la aplicación de Android, los responsables de proyecto y del repositorio ha aceptado sólo cuatro Pull Requests, tres correspondientes a archivos de markdown y una correspondiente a un XML de configuración. Ninguna, cero, que realmente añadan, modifiquen, o mejoren la funcionalidad. También cabe destacar que en el último mes (y algo más también), el único movimiento del repositorios fueron 3 issues abiertos que no han recibido ninguna respuesta.
Entonces, ¿qué es lo que realmente convierte un proyecto en Open Source?. Pues en mí humilde opinión, además de liberar el código, es de vital importancia la colaboración con la Comunidad. O dicho de otra forma, liberar el código de un proyecto no es lo mismo que convertirlo en Open Source y de facto, un proyecto con código libre podría bien ser un proyecto cerrado o Closed Source. Efectivamente la traducción literal al español puede llevar a confusión, pero, en mí opinión, debemos tener claro que detrás de un proyecto Open Source existoso hay MUCHO más que código. Bien es cierto que el hecho de que el código tenga una licencia copyleft podría permitir a la comunidad hacer un fork y llevar el proyecto por otro camino, pero, si es la administración publica quien impulsa y promociona un proyecto, ¿realmente tendría éxito la alternativa?
Veamos entonces. ¿Por qué es tan importante esta colaboración? ¿Qué aporta? ¿Cuáles son las ventajas de este trabajo conjunto?
Siempre solemos escuchar que el mero hecho de que el código sea público hace que el proyecto sea más seguro. Hay varios factores que pueden hacer que esto no sea del todo cierto: cuando no hay suficientes ojos verificando la implementación un proyecto o cuando se desoyen las recomendaciones de los contribuyentes, por ejemplo. Es decir, cuando no hay colaboración.
Otro de los beneficios del Open Source es que aparecen usuarios con habilidades, preocupaciones o inquietudes muy diferentes a las que tiene el equipo original. Estos pueden contribuir con mejoras que ni siquiera estaban sobre la mesa. Algún ejemplo de esto serían traducciones a nuevos idiomas, cuestiones de usabilidad o mejoras en la documentación. Por supuesto también pueden contribuir técnicamente igual o más que el grupo original. Como os imagináis, para que esto suceda es clave la colaboración.
A la hora de decidir el camino a seguir de un proyecto también es muy importante la colaboración. En primer lugar para que la Comunidad se sienta integrada pero también para disponer de más puntos de vista y para saber qué esperan del proyecto una parte importante de sus usuarios (aunque no la única).
Por ir acabando, la conclusión es que para que un proyecto sea Open Source es necesaria que exista Open Collaboration, aunque el camino inverso puede no darse. Desconozco la mejor traducción al español, quizás, por lo menos en el caso de RADAR Covid, pedir "abrir el proyecto" hubiese sido más acertado que "liberar el código".
Con esta entrada no pretendo desanimar a nadie a que se instale la aplicación. Todo lo contrario, os animo a todos a que la tengáis instalada en vuestros dispositivos, aunque eso no quita que pensemos en estás cuestiones para futuras ocasiones: