Hay una persona en Astorga de la que depende la marcha de la economía mundial

Quizás ha llegado el momento de reconocer que Internet y —por extensión— la economía mundial se sustentan en el trabajo que algunos desarrolladores realizan, de forma altruista, en su tiempo libre.

A principios de enero, Marak Squires —desarrollador de varios proyectos open source— decidió subir una última versión de «faker.js» que eliminaba todo su código y otra de «colors.js», que ejecutaba un bucle infinito que imprimía caracteres aleatorios, y provocó que todas las aplicaciones que los usaban empezaran a fallar en cadena.

El asunto no era menor, porque los dos paquetes sumaban más de 25 millones de descargas a la semana y estaban incluidos en otros 21.000 proyectos open source, que dependían de los mismos para su correcto funcionamiento.
 
No era la primera vez ni será la última que un bug en un popular paquete de software open source provocara fallos y vulnerabilidades de seguridad en los cientos de miles de aplicaciones que lo usan, pero en esta ocasión, el desarrollador había roto a propósito su propio software. ¿Qué empujo a Squires a hacer algo así?

El 8 de noviembre publicó una issue en el repositorio de GitHub de faker.js en la que afirmaba literalmente que se había cansado de trabajar gratis para las grandes corporaciones que usaban su software y que, si estas querían que alguien siguiera manteniéndolo, le ofrecieran un contrato de trabajo o lo clonaran y lo hicieran ellas mismas. La advertencia no cristalizó en ninguna propuesta aceptable para Squires y este, en vez de simplemente dejar de mantener sus proyectos, decidió mandar un «mensaje» causando el mayor daño posible corrompiendo 2 de sus proyectos más populares. El problema era que estos no eran empleados solo por malignas megacorporaciones, sino en el software desarrollado por y para cientos de miles de pequeñas y medianas empresas de todo el mundo.

Al fin y al cabo, el acto de rebeldía de Marak solo ha sido un toque de atención —ninguno de los dos proyectos que rompió aposta era un componente crítico—, pero en diciembre se descubrió una vulnerabilidad en la veterana librería Log4j que ha puesto en jaque a media industria, que la usaba para registrar lo que iba pasando en cientos de miles de aplicaciones corporativas.

La Comunidad se indignó por las críticas y presiones que recibió el equipo de Log4j para solucionar cuanto antes los agujeros de seguridad, sobre todo al enterarse de que lo estaban haciendo por pura responsabilidad —pidiendo vacaciones en sus respectivos trabajos y pasando noches sin dormir—, pero sin recibir el más mínimo soporte de las empresas que obtenían rendimiento de su esfuerzo y, lo que es peor aún, al descubrir que la brecha se había producido en una antigua funcionalidad que querían eliminar desde hace algún tiempo, pero que habían mantenido precisamente para evitar cualquier potencial problema al software puesto en producción por dichas empresas.

La reacción de Microsoft —dueña de GitHub y npm— ante la vileza de Squires fue un aviso a navegantes: suspender su cuenta en la primera y revertir sus cambios en la segunda. Tu proyecto open source es tuyo mientras lo mantengas.

La preocupación por casos como el de Log4j llevó a la Casa Blanca a convocar una reunión con algunos de los actores más relevantes de la industria para debatir sobre el potencial riesgo que puede suponer para la Seguridad Nacional los problemas de seguridad del software open source. Algunos, como IBM o Google, propusieron hacer una lista de las aplicaciones más críticas y asegurarse de que las mismas cuentan con suficientes recursos para mantenerse y están sometidas a auditorias de seguridad. Un auténtico «matar moscas a cañonazos» que puede mitigar el impacto de futuros bugs de seguridad, pero que no va a evitar que estos existan ni que la industria entera dependa de las horas que una persona anónima —en Nebraska o Astorga— saque los sábados por la tarde, después de una barbacoa con los colegas.

Quizás tendría más sentido que las empresas se conciencien de una vez por todas de la importancia de las buenas prácticas de desarrollo, para evitar problemas con versiones y dependencias, y poder actuar rápidamente ante el descubrimiento de una vulnerabilidad. Al fin y al cabo, la maldad de Marak solo afectó a aquellos que actualizaron sus proyectos sin preocuparse de qué contenían o, peor aun, siempre usaban la última versión de los mismos.

Una de las primeras cosas que aprendí como desarrollador de software fue no integrar la ultimísima versión de cada librería o modulo de terceros que usaba, simplemente por el hecho de que existiera. «Que el betatesting lo haga otro». Y es que cada vez que actualizamos el software de un tercero estamos corriendo un riesgo, pero casi nadie se para a pensar si merece la pena a cambio de las supuestas mejoras que incorpora.

Quizás también tendría sentido que las empresas se involucren más en los proyectos open source sobre los que cimientan sus propios productos y servicios. Nuestro software solo debería depender de módulos y librerías que tengan garantizado su mantenimiento y, si dependemos de algo, deberíamos contribuir de alguna forma a su mantenimiento. Es puro sentido común. Es justo.

Dedicar desarrolladores al mantenimiento de dichos proyectos es algo que solo pueden permitirse las grandes multinacionales y, hasta hace poco, contribuir de forma económica era complicado y farragoso —excepto para las iniciativas más grandes, como las de la Fundación Apache o Mozilla—, porque detrás de los mismos no suele haber ninguna estructura empresarial sino un puñado de voluntarios que no tienen forma de recibir y gastar legalmente el dinero de las donaciones. Sin embargo, han surgido una pléyade de servicios y plataformas —como Open Collective, Open Source Collective o GitHub Sponsors— que ha hecho más fácil que las empresas podamos contribuir economicamente al mantenimiento de los proyectos open source que utilizamos. Todas. Todos.

Quizás tendría sentido que dejemos de esperar que las grandes corporaciones tomen la iniciativa de hacer sostenible el software open source, solo porque sería lo mas justo, y contribuir con nuestro pequeño granito de arena. Pero, sobre todo, que seamos conscientes de las implicaciones de no hacerlo.

No sé si moverá mucho la aguja o no que cada desarrollador que trabaje en Manfred disponga, a partir de ahora, de un presupuesto mínimo —algo simbólico, como 100€ al año— para distribuir como ellos quieran entre los proyectos open source que utilizamos, pero sí sé que es más de lo que hemos hecho hasta ahora: nada.