Once líneas de código borradas. Eso fue todo lo que se necesitó para causar el caos en cientos -quizá miles- de aplicaciones y servicios web en internet. La semana pasada un programador llamado Azer Koçulu decidió eliminar todos sus proyectos de GitHub, pero el problema es que al hacerlo hizo que otros muchos que dependían de parte del código que escribió: en concreto, de una sencilla rutina de 11 líneas llamada lefpad.js de la que dependían numerosos proyectos de software escrito en Javascript.
La desaparición de ese código hizo que durante dos horas cundiera el pánico en la comunidad de desarrolladores. El tema se acabó solucionando tras la recuperación y republicación del código -a pesar de que su creador lo hubiera borrado- pero la situación deja claro lo mucho que dependendemos del código Open Source. ¿Y si estos proyectos empezaran a desaparecer?
El extraño caso de la función que desaparecía
La historia de Koçulu sacudió a la comunidad Open Source la semana pasada. Este joven programador autodidacta de 28 años contaba cómo todo lo que tenía "se lo debo a la gente que nunca se rindió con la filosofía Open Source". Eso fue lo que le animó a comenzar a colaborar con el proyecto npm, una conocida herramienta que facilita la instalación de paquetes de software JavaScript para Node.js, una de las plataformas de desarrollo de aplicaciones web más populares en los últimos tiempos.
Sus aportaciones al proyecto fueron muy variadas, pero había una que sin ser particularmente compleja -de hecho, era más bien simplona- acabó siendo vital para cientos de proyectos. Estas 11 líneas de código fueron las responsables de una catástrofe:
Esas líneas se usan para añadir caracteres al principio de una cadena de texto, y aunque cualquier programador podría haberlas integrado en su proyecto sin demasiados quebraderos de cabeza, el hecho de el problema ya estuviera solucionado y formara parte del repositorio del proyecto npm hizo que nadie pensase en que alguien pudiera eliminarlas.
¿Por qué decidió eliminarlas? Resulta que uno de los proyectos desarrollados por Koçulu era kik, un paquete que permitía a otros desarrolladores crear plantillas para sus propios proyectos. Esa herramienta tenía un nombre idéntico a KiK (si no tenemos en cuenta el uso de mayúsculas), la aplicación de mensajería. Los responsables de esta quisieron evitar confusiones cuando se dispusieron a crear su propio paquete con ese nombre, y se pusieron en contacto con Koçulu para pedirle que cambiara el nombre de su paquete.
El joven programador no se tomó bien la petición -que al menos en primer término se formuló de forma totalmente correcta- y la discusión con los responsables del servicio acabó incluyendo potenciales demandas por violación de una marca registrada, aunque acabarían disculpándose por la forma de expresarse, que admiten que "no fue perfecta" en su versión de los hechos.
Los responsables de KiK -la aplicación de mensajería- se pusieron en contacto con los del proyecto NPM -que aparte de la plataforma Open Source mantiene una serie de servicios comerciales- y estos recomendaron a Koçulu que cediera. En lugar de eso, éste llegó al límite y tomó la decisión de eliminar todas sus contribuciones a ese código.
Eso hizo que el 22 de marzo, cuando efectivamente tomó esa decisión, comenzaran a aparecer mensajes de error a todos los que corrían haciendo uso de esa pequeña y aparentemente insignificante función llamada leftpad. Entre ellas, como comentaban en Quartz, estaba su motor de creación de gráficos y diagramas, Atlas, pero sobre todo plataformas mucho más populares como React, desarrollada por Facebook, y que de buenas a primeras no dejaba de dar errores.
This action puts the wider interests of the community of npm users at odds with the wishes of one author; we picked the needs of the many.
— Laurie Voss (@seldo) March 22, 2016
Los responsables de npm acabaron haciendo frente a la crisis con una decisión excepcional: "des-des-publicar", o lo que es lo mismo, republicar esas líneas de código. Laurie Voss, CTO de npm, afirmaba que esta decisión se había tomado "dada la severidad y amplia naturaleza del problema, y no se había tomado a la ligera". De hecho, añadía, "esta acción pone los intereses de la comunidad de los usuarios de npm en contra de los deseos de un autor: hemos optado por las necesidades de la mayoría".
Los problemas dieron lugar a una larga serie de críticas por parte de los defensores del Open Source, que como Koçulu se sentían traicionados por la actitud de los responsables de npm. Estos explicaron su postura en un artículo en su blog, para más tarde acabar tomando una decisión que afectará a la política para "despublicar" paquetes a partir de ahora en este proyecto y que precisamente tratará de protegerles de problemas similares en el futuro. Pero, ¿y si el problema se extendiese?
El Open Source te da, y el Open Source te quita
No es necesario reinventar la rueda. Este es uno de los principios básicos del desarrollo software: si algo funciona y puedes utilizarlo, no pierdas tiempo en ello y aprovéchalo para construir sobre ese componente.
Esa reutilización del código es una realidad palpable en todo tipo de proyectos, y de hecho es la base de que muchos desarrolladores puedan evitar invertir recursos en problemas que ya están (teóricamente) bien resueltos, pero también tiene una pega. Una muy importante.
Cuando reutilizas código, lo haces con todas las consecuencias. Y una de ellas es que el código cambie o, como ocurrió en el caso citado, desaparezca. Si ese código original cambia el programador que lo ha reutilizado deberá a su vez actualizar el suyo si eso afecta a su propio proyecto. Aquí es donde las célebres actualizaciones evitan que conflictos en la base afecten a conflictos en esa parte que disfrutamos nosotros -los servicios y aplicaciones que ejecutamos-. El problema aquí es perfectamente asumible y desde luego está perfectamente asumido.
La cosa cambia cuando el código original desaparece: en esos casos se produce el caos, puesto que un elemento clave de ese desarrollo, uno del que dependía parte de su capacidad, ya no está disponible. Los responsables de estos desarrollos deben entonces enfrentarse a una situación que tiene difícil solución si uno no ha sido mínimamente previsor.
Cuando reutilizas código, lo haces con todas las consecuencias
Aunque es algo también evidente en software propietario o privativo, este tipo de filosofía de reutilización del código es especialmente popular en desarrollos Open Source en los que coger un programa y mejorarlo o utilizarlo como parte de otro no es solo algo que se hace: es algo que las licencias de este tipo te animan a hacer. Como diría con orgullo Richard Stallman en su definición del Software Libre, coge el código, ejecútalo como y donde quieras, estúdialo y cámbialo para que haga lo que quieras, y redistribúyelo incluyendo (si las hay)s modificaciones. Compartir es vivir, vaya.
Esa filosofía ha hecho más válido que nunca el concepto de reutilización del código, pero también ha hecho que haya aparecido otro efecto colateral tan frecuente que tiene su propia entrada en la Wikipedia. Se trata del infierno de las dependencias. En realidad y como explican allí ese infierno está más relacionado con estar ligado a versiones específicas de paquetes y código que a la propia existencia de dependencias, sean cuales sean este.
En cualquiera caso el infierno de las dependencias existe y solo hay una forma de prevenirlo: tener algún tipo de backup de las librerías y dependencias que los desarrolladores tienen en sus proyectos. Hay numerosos ejemplos, pero muchos de ellos los podemos encontrar por ejemplo en Github, el servicio estrella para compartir todo tipo de desarrollos y código y uno que precisamente tiene como aliado esa operación de fork de cualquier repositorio para que uno trabaje sobre ella, la modifique y la vuelva a compartir con esa filosofía del software libre de la que hablábamos.
Eso, claro, tiene también sus peligros. Como explicaban hace tiempo en Stack Exchange, si tu código en el repositorio A depende de un repositorio B lo mejor que puedes hacer es crear un backup (vamos, un fork que no toques) del repo A para guardarte las espaldas. De ese modo si el propietario del repositorio B decide borrarlo por lo que sea -y puede hacerlo, obviamente- no te dejará a ti y a todos los usuarios de tu repositorio (incluidos los que a su vez lo utilizan como pilar de algo más) colgados.
Forks y backups alivian el problema
Lo comentábamos con nuestro compañero Txema Durbon (@durbon), coordinador de Genbeta Dev, que nos explicaba que esa práctica de integrar ese código en forma de backup es algo tradicional entre desarrolladores y también entre las empresas de desarrollo. De hecho, nos comentaba "solemos tener ese código en nuestros repos internos como librerías de terceras partes, entre otras cosas para evitar que salir fuera (internet) para obtenerlas o asegurarnos de que cierta versión no desaparezca)".
El problema es que puede no ser suficiente con Github, así que el consejo de nuestro compañero se hace más válido aún. En Wired reflexionaban hace unos meses sobre lo bien que funciona Github y lo mucho que dependemos de él. Este gigantesco servicio que alberga miles -¿millones?- de proyectos Open Source no solo permite acceder a ese código, sino a las modificaciones que sus creadores han ido haciendo en él. Es una prodigiosa máquina del tiempo, pero está sujeta a que Github siga funcionando como negocio.
Ahí es donde da miedo comprobar lo que ocurrió con Sourceforge, la referencia en este campo antes de que surgiese Github. Los usuarios de Sourceforge también alababan el servicio, pero tras la adquisición por parte de DHI Holdings en 2012 comenzaron a sucederse cambios que iban destinados a monetizar la plataforma pero que causaron numerosas quejas por parte de los usuarios.
De hecho, en Sourceforge acababan provocando que los usuarios descargaran software que no deseaban con un estratégico diseño que engañaba sobre los enlaces reales de descarga y confusión con lo que era publicidad y lo que no. Las cosas fueron más allá cuando en Sourceforge incluso integraron software malicioso en los instaladores legítimos y publicitario con el intento de impulsar el uso de aplicaciones que obviamente pagaban a Sourceforge por esos empujoncitos comerciales.
Proyectos Open Source como GIMP se causaron de la situación y dejaron de estar hospedados allí, pero como explicaban en Wired en lugar de aceptar ese abandono en Sourceforge acabaron ofreciendo sitios espejo (mirrors) de descarga sin permiso. Otros proyectos famosos como VLC, Notepad++ o wine siguieron los pasos tras todas estas tácticas.
En GitHub eso no ha ocurrido y por ahora solo pagan aquellos que quieren mantener proyectos privados, pero eso podría cambiar: las necesidades en materia de infraestructura son enormes para un servicio que ha dejado mordiendo el polvo a alternativas como Google Code o Microsoft CodePlex. Si la empresa necesita ingresos para mantener el funcionamiento puede que acuda a otros métodos, algo que también podría pasar si es adquirida o sale a bolsa.
Pero todo esto son solo hipótesis, y lo que es cierto es que cualquier usuario con su código publicado en GitHub puede despublicarlo cuando quiera fácilmente. No parece que en GitHub vayan a aplicar los términos que han querido aplicar en NPM tras los recientes sucesos -endureciendo las conduciones para despublicar código-, pero aún así lo que sí es cierto es que en GitHub la mecánica de crear forks es tan transparente que será difícil que en cuestión de dependencias haya problemas.
¿Cuánto dependemos del Open Source?
A la vista de todo esto, cabe preguntarse si el Open Source y el Software Libre son realmente tan importantes en nuestro mundo. Si ocurriría algo si proyectos aquí y allá comenzaran a desaparecer porque sus programadores decidieran eliminar esos proyectos de la faz de la tierra. Pues bien: mejor no imaginarse las consecuencias, porque serían enormes.
Hac eun año un estudio de Black Duck Software publicó su estudio anual "Future of Open Source" -teóricamente la nueva edición estaría a punto de aparecer-y en él llegó a varias conclusiones. Entre ellas, el hecho que el 78% de las empresas incluidas en su estudio demostraban basar buena parte de su negocio en soluciones Open Source.
Esa encuesta solo arañaba la superficie de ese gigantesco iceberg del Open Source. Muchas de las grandes empresas tecnológicas basan su infraestructura en soluciones Open Source, y eso hace que a su vez miles de grandes en todo el mundo y en todos los ámbitos -automoción, banca, industria, energía, salud, educación e investigación, etc- utilizan por extensión este software.
Para el usuario final el efecto de la desaparición del Open Source también sería crítico: la cuota de mercado de Android -no todo en él es Open Source, pero sí sus pilares- es uno de los mejores ejemplos de cómo de buenas a primeras no podríamos usar esta alternativa y tendríamos que recurrir a soluciones propietarias en este y otros entornos personales y profesionales.
Nuestra rutina diaria está dominada por tareas que dependen en menor o mayor medida de todo tipo de soluciones Open Source. Ocurre desde luego con el funcionamiento de internet y de muchos de sus servicios, de nuestros dispositivos, de nuestras redes energéticas y de transporte, o de la forma en la que se gestionan innumerables servicios que hacen que cuando apretamos un botón acabe pasando eso que queríamos que pasara.
Mejor no pensar si lo que pasó con esas 11 líneas de código comenzase a ponerse de moda.
En Genbeta | No subestimes a Linux, nunca imaginarías dónde te lo puedes encontrar
Ver 1 comentarios