Blogs de Festeros.es

Sin duda, el código abierto es la forma más ventajosa de crear software: cuando un proyecto de software toma la forma de código abierto y logra congregar a una comunidad de desarrolladores trabajando activamente en él, documentándolo y mejorándolo constantemente, se obtiene un círculo claramente virtuoso en el que, entre otras cosas, se cumple la conocida Ley de Linus: "dado un número suficientemente elevado de ojos, todos los errores se vuelven obvios".

Cuando un cierto número de personas, diversas y no pertenecientes a una única organización, se coordinan para desarrollar un proyecto de software, los resultados suelen ser buenos. Buena parte del software que utilizamos habitualmente tiene su base en proyectos de código abierto, simplemente porque es la manera más adecuada de desarrollar software. Simplemente el hecho de querer que un software esté disponible en forma de código abierto obliga a sus creadores, como mínimo, a revisarlo profundamente y a documentarlo de forma adecuada, algo que a pocos desarrolladores les gusta hacer, pero que resulta fundamental si quieres que pueda ser inspeccionado, entendido y mejorado por otros. La idea, además, de crear un software para que cualquiera pueda beneficiarse de su uso tiene un componente altruista que resulta sumamente interesante de cara a lo que deberían ser nuestras sociedades.

Sin embargo, un estudio reciente que tomó como base más de 1.2 millones de proyectos de software de código abierto se encontró con una conclusión preocupante: tan solo alrededor del 11% de estos proyectos reciben un mantenimiento mínimamente activo. La preocupación emerge, lógicamente, de lo que suele ocurrir cuando el software, que es cualquier cosa menos algo aislado, estable y monolítico, no es sometido a ese mantenimiento: los proyectos de software, por lo general, tienen múltiples dependencias que pueden cambiar a medida que lo hacen las versiones de los componentes en los que se apoyan para sus funcionalidades.

Sin el adecuado mantenimiento periódico, en el software suelen aparecer vulnerabilidades, que pueden ser activamente explotadas por actores interesados: se calcula que en torno al 10% de las incidencias de seguridad se deben a vulnerabilidades surgidas en software de código abierto.

El resultado de este estudio, en cualquier caso, no debería desilusionar a nadie: los "grandes" proyectos de código abierto mantienen una salud excelente y tienden cada vez más a convertirse en estándares, en cimientos sólidos para otros proyectos, en grandes generadores de valor. Sin embargo, entre los proyectos de código abierto hay muchísima diversidad: hay muchos pequeños proyectos, a veces unipersonales o que no logran alcanzar la escala de comunidad, que sin embargo, son capaces en muchas ocasiones de tener una gran importancia.

A veces, de hecho, nos encontramos con la paradoja de que esas piezas creadas por auténticos devotos que durante un tiempo encontraron su motivación en su creación son utilizadas como componentes en muchos otros proyectos, lo que tiende a generar enormes estructuras que, en último término, se apoyan sobre un eslabón débil, sobre algo a lo que su creador, a menudo ya en otra fase de su vida y con otros intereses, ya no le da mantenimiento. En muchos casos, ese software simplemente no logró interesar a suficientes desarrolladores como para que, además de utilizarlo en sus proyectos, colaborasen en su mejora o mantenimiento. Puede ser que el autor original no lograse darle suficiente difusión, posiblemente no estaba cortado para liderar una comunidad, o simplemente lo hizo tan bien que no parecía que precisase nada más. Hay un montón de posibilidades de muchos tipos que pueden hacer que un proyecto de código abierto no se convierta en comunidad, incluso aunque obtenga popularidad. Utilizar algo no requiere el mismo nivel de compromiso que colaborar en su desarrollo. Muchos, simplemente, ni se lo plantean.

La cuestión resulta sumamente interesante: el software permite que cualquiera con las ideas adecuadas pueda añadir valor, pero ese valor no siempre se expresa de formas convencionales. A menudo, un desarrollador que crea proyectos interesantes se ve remunerado con mejores trabajos o con más prestigio, pero no necesariamente de manera directa. A partir de ahí, con el software que creó puede ocurrir cualquier cosa: puede simplemente caer en la obsolescencia, pero también puede, si es bueno, convertirse en algo en lo que otros desarrolladores pasan a apoyarse de forma habitual para sus proyectos.

Cada vez más, es habitual encontrarse con problemas de este tipo: pequeños componentes de código no mantenidos por su creador o creadores durante años, que terminan generando problemas. Si incorporamos la inteligencia artificial a la ecuación, podemos encontrarnos con asistentes que toman porciones de código de repositorios en función de una necesidad determinada, pero que ni siquiera dejan clara su trazabilidad, su tipo de licencia, de dónde proceden o sus condiciones en términos de mantenimiento. El uso de componentes de software creados mediante inteligencia artificial y machine learning en entornos corporativos creció el pasado un 135%.

Si ya en muchos casos, el retorno a la comunidad de los proyectos que utilizan componentes software de código abierto es escaso o nulo ?poco menos que las gracias, si acaso? cuando quien decide qué código se utiliza es un algoritmo, ese retorno suele volverse inexistente. Si muchos desarrolladores, como hemos visto, ni se plantean colaborar con la mejora o mantenimiento de una pieza de software de código abierto que utilizan, ¿qué esperamos de un simple algoritmo carente de tales razonamientos? ¿Va el algoritmo a decir «hmmm, a lo mejor sería interesante ayudar aquí y mejorar esto»? No, simplemente va a tomar lo que necesite, e irse sin ni siquiera decir eso de… hasta luego, y gracias por todo el pescado!

¿Cómo manejarnos en un entorno cada vez más complejo y variado, con cada vez más piezas creadas mediante procesos en muchos casos voluntaristas, y que son gestionadas cada vez más de manera arbitraria y sin demasiada visibilidad? ¿Cómo dotar a los repositorios de software de la inteligencia adecuada como para entender cuándo es recomendable o no reutilizar un componente? O mejor, ¿cómo crear incentivos para que una tarea como el mantenimiento, mucho menos motivadora que el desarrollo como tal, reciba la atención adecuada y se reconozca su valor?

This article is also available in English on my Medium page, «Open source is a wonderful thing, but AI is exposing its weaknesses»

Publicado con licencia Creative Commons 3.0 España