Código abierto: así burlan a la muerte los proyectos de software abandonados

A mediados de 2019, el programador Denis Pushkarev dijo que era probable que fuese a la cárcel. Lo anunció en un hilo de la plataforma de desarrollo colaborativo Github, donde desde 2014 mantiene Core-JS, una librería de código que permite a otros programadores reutilizar desarrollos prefabricados sin tener que empezar desde cero. Pushkarev era entonces el único gestor activo y con permisos para mantener el proyecto, que registra más de 20 millones de descargas a la semana de usuarios que integran Core-js en sus propios trabajos. Según recoge una sentencia del tribunal regional de Altai (Rusia), Pushkarev se vio envuelto en un accidente donde dos personas fueron atropelladas —una resultó herida, la otra falleció—, intentó sin éxito alegar que las víctimas estaban ebrias para rebajar su responsabilidad en los hechos y se disponía a cumplir una condena 18 meses.

La sentencia dio paso a casi un año de silencio. Entre enero y octubre de 2020, Core-js estuvo abandonado. Pushkarev no designó otros mantenedores y se limitó a dejar el repositorio sin actualizar hasta que anunció su regreso con un escueto “estoy de vuelta”. El suyo es un caso extremo y particularmente rocambolesco, pero los abandonos de librerías y otros proyectos de código abierto son frecuentes en el sector. Por un lado, el mantenimiento y la gestión de la comunidad de colaboradores se vuelve más exigente cuanto más reconocimiento se obtiene.

“La creciente popularidad de un proyecto puede llegar acompañada de un creciente número de contribuciones que tienen que analizarse e incrementan la carga de trabajo para quienes lo mantienen”, confirma Alexander Serebrenik, investigador de la Universidad Tecnológica de Eindhoven (Países Bajos). Por otro lado, la falta de recursos o el exceso de celo dejan en muchas ocasiones la enorme responsabilidad de mantener vivo el proyecto en manos de equipos diminutos —o unipersonales— que además compaginan estas tareas con sus obligaciones laborales.

Este fenómeno crea en plataformas como Github, que en 2020 registró más de 60 millones de repositorios de nueva creación, una suerte de cementerio de elefantes donde asoman las osamentas de lo que en su día fueron hervideros de ideas. En Bitergia llevan casi una década midiendo la salud de estas comunidades y la relación entre los responsables del proyecto y sus colaboradores. “Uno de los factores que analizamos es la probabilidad de que un proyecto sobreviva si los desarrolladores principales tienen algún accidente”, comenta Daniel Izquierdo, director ejecutivo y cofundador de esta empresa, que colabora con fundaciones de software libre de la talla de Linux, Mozilla o Wikimedia. Según un estudio reciente, el 65% de los proyectos con 20 o más desarrolladores están activos después de 165 meses. En el caso de los equipos menores, el porcentaje de supervivientes cae al 20%.

Pero el silencio de esos páramos digitales cuyos registros muestran los años que han pasado desde que alguien se asomó a hacer la última contribución no es la única consecuencia del abandono. Cuanto más popular haya sido el proyecto, más probabilidades hay de que una larga lista de desarrolladores lo hayan implementado en sus propios trabajos. Estos, advierte Izquierdo, se verán expuestos a problemas de seguridad que “pueden ser catastróficos” a medio plazo. El investigador y coordinador de la oficina de conocimiento y cultura libres de la Universidad Rey Juan Carlos, Jesús González-Barahona, explica que esas piezas de código se quedan ancladas en el pasado. “No van a adaptarse a nuevos entornos, hardware o versiones del sistema operativo”. Y tampoco incorporarán nuevas funciones ni correcciones de errores. ¿Cuál es la alternativa? “Si este proyecto es muy crítico para ti o te importan mínimamente los proyectos de software libre, de alguna manera tendrías que tener la iniciativa de participar e intentar que eso se solvente”, concluye Izquierdo.

El abandono de proyectos no es nuevo, Peter Mattis y Spencer Kimball, creadores de la popular herramienta de dibujo GIMP ya abandonaron su criatura en los 90. “Les dejamos un poco en la estacada cuando conseguimos un empleo”, explicaron a EL PAÍS en una entrevista. Pero su experiencia demuestra que la partida de los impulsores originales no tiene por qué ser una sentencia de muerte: más de 25 años después, GIMP sigue vivito y coleando gracias al trabajo de un nutrido y comprometido grupo de colaboradores. De acuerdo con las investigaciones de Serebrenik, lo que motiva estas adopciones de iniciativas huérfanas es el deseo de evitar que el proyecto se interrumpa y contribuir a la continuidad de la comunidad del software libre, de cuyas aportaciones se han beneficiado.

Lo cierto es que pese a sus dificultades, estos proyectos están especialmente preparados para burlar a la muerte. “El problema es más grave con el software no libre. Si el fabricante deja de mantenerlo, no tienes a dónde acudir. En el caso del software libre, si hay suficiente interés o recursos, siempre se puede encontrar gente que reviva el proyecto: la licencia lo permite”, explica González-Barahona. La posibilidad de que cualquier usuario obtenga el código para usarlo, modificarlo, redistribuirlo o estudiarlo permite que la historia de GIMP no sea un caso aislado. “Quizás el ejemplo más conocido es Firefox, que surgió de un proyecto abandonado por Netscape, la empresa que a finales de los 90 era uno de los líderes en navegadores web”, añade.

¿Cuál es el protocolo para adoptar un proyecto abandonado? La plataforma Code Shelter propone un sistema parecido a los refugios de mascotas donde aquellos con ganas de echar un cable pueden encontrar iniciativas cuyos gestores no dan abasto o se disponen a bajarse del barco. “Yo siempre recomendaría al menos preguntar, ver qué tal se encuentran y si puedes echar una mano. Y si no, en Github es tan barato como darle a un botón y ya tienes una copia en tu cuenta”, comenta Izquierdo. Las buenas formas en la gestión de las aportaciones de la comunidad son clave también para la salud de estas iniciativas. “El rechazo puede parecer injusto a los colaboradores y desalentarles de seguir contribuyendo, no solo al proyecto en concreto, sino al software libre en general”, advierte Serebrenik. Además, si llegase a ser necesario un traspaso de carteras, los gestores más amistosos tienen más posibilidades de encontrar herederos voluntariosos y dispuestos a recoger el testigo.