Una carta de amor al Open Source y cómo podemos protegerlo

👆👆👆 Suscríbete a nuestro podcast. Y mejor aún, a nuestro boletín mensual: todo cosas útiles que no encontrarás en otro lado, una vez al mes.

Imagina que te despiertas una mañana y descubres que internet ha dejado de funcionar. No puedes acceder a tus correos, ni a tus redes sociales, ni siquiera a tu cuenta bancaria online. Suena a guion de una peli postapocalíptica, ¿verdad? Pues bien, hace unos meses estuvimos más cerca que nunca de vivir este escenario apocalíptico. Y lo más sorprendente es que todo se debía a un pequeño programa de código abierto del que probablemente nunca hayas oído hablar...

Este programa se llama XZ. Detrás de ese nombre tan corto y que no dice mucho está una herramienta de compresión de datos que se usa en miles de millones de dispositivos en todo el mundo. Está en tu móvil, en tu televisor inteligente y en los servidores Linux que almacenan tus fotos en la nube. Se utiliza para todo. Y durante un tiempo este año, estuvo a punto de convertirse en la puerta trasera más peligrosa de la historia de internet.

¿Cómo es posible que un simple programa de compresión pudiera poner en jaque a toda la red? Bueno, pues la respuesta tiene que ver con la forma en que se desarrolla el software hoy en día y con el modelo que revolucionó a nuestra industria ya hace décadas: el Open Source o código abierto.

Porque, antes de entrar en detalles, piensa por un momento: ¿cuántas veces has usado hoy software de código abierto incluso sin darte cuenta? Es más, ¿cuánto software Open Source, por pequeño que sea, estás utilizando en el proyecto en el que estés trabajando ahora mismo?

Pues, probablemente estás usando muchísimo más del que imaginas. Y es que el Open Source está en todas partes, partiendo del propio sistema operativo que estás utilizando para trabajar hasta el servidor en el que despliegas las aplicaciones que construyes pasando por las herramientas de programación en las que te basas.

Esta omnipresencia del código abierto es una de las razones por las que la historia de XZ nos afecta a todos. Porque nos muestra tanto el poder como la fragilidad de un sistema en el que confiamos ciegamente cada día. Un sistema que ha cambiado para siempre la forma en que creamos y usamos la tecnología.

La revolución silenciosa: cómo el código abierto lo ha conquistado todo

Vamos a ir atrás en el tiempo por un momento. Hasta finales de los años 80. En aquella época, si querías desarrollar software, tenías básicamente dos opciones: o trabajabas para una gran empresa como Microsoft donde tenías acceso a su enorme colección de código interno, o te buscabas la vida y lo hacías todo desde cero por tu cuenta. El código era un secreto muy bien guardado, algo que se protegía como si fuera la fórmula de la Coca-Cola.

Pero entonces, algo empezó a cambiar. Muchos programadores en todo el mundo comenzaron a compartir su código en foros y tablones de anuncios online, muchas veces sin conocimiento de su empresa que, seguramente de saberlo, los hubiese despedido. No lo hacían por dinero, sino por algo más básico: porque era divertido y porque creían que compartir el conocimiento era la mejor forma de mejorarlo.

Uno de estos programadores era Bruce Perens, que trabajaba en Pixar creando herramientas como las que años más tarde servirían para hacer películas como Toy Story. Bruce desarrolló un programa llamado Electric Fence, que ayudaba a detectar y depurar errores en el código, algo que ahora damos por hecho pero que era revolucionario en aquel momento.

Y, en lugar de guardárselo para sí mismo o para su empresa, Bruce decidió compartirlo con todo el mundo.

Y aquí viene lo interesante: no solo otras personas de todo el mundo empezaron a usar Electric Fence, sino que además comenzaron a mejorarlo y a devolverle esas mejoras a Bruce. De repente, su pequeño proyecto se había convertido en algo mucho más grande y potente gracias a la colaboración de desconocidos "random" en internet.

Esta idea de colaboración abierta empezó a extenderse como la pólvora. Imagina que en lugar de que cada empresa tuviera que reinventar la rueda una y otra vez, todos compartieran sus "ruedas" y trabajaran juntos para mejorarlas. Eso es básicamente lo que propuso el movimiento del Open Source.

Al principio, las grandes empresas se rieron. ¿Cómo iba a funcionar un modelo en el que regalas tu trabajo? Pero poco a poco, la realidad les fue dando una lección. Empresas posteriores, como Google o Facebook, empezaron a construir sus imperios sobre cimientos de código abierto y se fueron comiendo a empresas "de toda la vida" que se quedaban atrás. Y este nuevo estilo de empresas no solo construyeron su software basándolo en el de otra gente gracias al Open Source sino que también, y más importante, empezaron a liberar parte de su propio código.

Porque se dieron cuenta de que era más valioso tener un ejército de programadores de todo el mundo mejorando tu software que mantenerlo todo en secreto. Incluso Microsoft, que una vez consideró al Open Source como su mayor enemigo, acabó rindiéndose a la evidencia y ha abrazado este modelo ya hace años (aunque tardó mucho más que los demás).

Hoy en día, el Open Source es el motor que está detrás del desarrollo de casi todo el software y de internet. Como decía antes, se utiliza en los servidores que alojan tus desarrollos web, en el ordenador que utilizas para ganarte la vida y, por supuesto, en todas las herramientas que usas para programar. Te guste más o menos, se ha convertido en la forma por defecto de crear software moderno.

Pero este éxito también ha traído consigo nuevos desafíos. Porque, ¿qué pasa cuando todo el mundo depende de un software que nadie se siente responsable de mantener? Esa es la pregunta que nos lleva de vuelta a la historia de XZ y a uno de los mayores peligros a los que se ha enfrentado internet en los últimos años.

El dilema del mantenimiento: héroes anónimos del software

Imagínate que en lugar de crear software eres jardinero y tienes que encargarte del mantenimiento de un jardín muy bonito y que lo visitan muchas personas cada día. Como el jardín te gusta mucho y te da subidón ver lo bonito que queda, lo mantienes en tu tiempo libre, sin cobrar un céntimo. Y la gran mayoría de los que visitan las plantas ni siquiera sabe que existes y mucho menos cómo te llamas. Bienvenido al mundo de los mantenedores de proyectos Open Source.

Estos héroes anónimos del software son los responsables de que muchas cosas sigan funcionando día tras día. Son los que se encargan de que esas "ruedas" de las que hablábamos antes no solo no se oxiden, sino que sigan girando cada vez mejor.

Pero ser un mantenedor de Open Source no es tarea fácil. Es como ser ese jardinero en un jardín público: todo el mundo disfruta de las flores, pero nadie se para a pensar en quién las riega. Y lo que es peor, a veces la gente se empieza a quejar de que la hierba está un poco alta, sin darse cuenta de que el jardinero lleva meses trabajando gratis para ellos.

Y eso nos lleva al caso de de Lasse Collin, el creador de XZ. Durante años, esta persona se encargó de mantener este programa que, con el tiempo, se convirtió en crucial para el funcionamiento de internet. Lo hacía en su tiempo libre, movido por la pasión y el compromiso con la comunidad. Pero como ocurre con muchos proyectos Open Source, llegó un momento en que la tarea se le iba de las manos.

Y es que mantener software no es solo corregir errores. Es adaptarlo a nuevos sistemas operativos, a nuevos procesadores, a nuevas necesidades, a nuevas formas de usar la tecnología... Es como si nuestro jardinero, además de regar las plantas, tuviera que estar constantemente rediseñando el jardín para adaptarlo a los gustos de la gente e incluso al cambio climático.

El problema es que, mientras que a todo el mundo le gusta visitar el jardín, a muy pocos les gusta la jardinería y, de esos, muchos menos aún se ofrecen voluntarios para ayudar a mantenerlo. Pero si el jardinero voluntario decide dejar de hacerlo, al cabo de un tiempo aquello es un desastre.

Esta situación crea un desequilibrio peligroso. Por un lado, tenemos empresas multimillonarias y servicios críticos que dependen de estos proyectos Open Source. Por otro, tenemos a mantenedores sobrecargados de trabajo, a menudo trabajando solos, sin recompensa económica y sin ni siquiera un reconocimiento por su trabajo.

La pregunta que debemos hacernos es: ¿es justo o sostenible este modelo? ¿Podemos seguir dependiendo de la buena voluntad de unos pocos para mantener la infraestructura digital de la que todos dependemos?

Porque, como veremos a continuación, cuando un mantenedor se cansa o se ve sobrepasado, las consecuencias pueden ser devastadoras...

Y eso nos lleva otra vez a la historia de XZ, y a cómo un simple cambio de mantenedor estuvo a punto de poner en jaque a todo internet.

Cuando la confianza se convierte en vulnerabilidad: el caso XZ

XZ es un programa relativamente sencillo y pequeño pero que forma parte de los sistemas operativos de tipo UNIX. Así que básicamente está en todas partes, haciendo su trabajo de comprimir y descomprimir datos sin que nadie sepa siquiera que está ahí. Hoy en día lo usan desde tu móvil hasta los servidores que guardan tus fotos en la nube. Es tan ubicuo que se ha convertido en parte de la fontanería invisible de la red.

Pero mantener XZ no era tarea fácil. Su creador llevaba años haciéndolo en su tiempo libre, actualizándolo para que siguiera funcionando en nuevos sistemas y dispositivos. Y, como comenté antes, llegó un momento en que la tarea se volvió abrumadora.

Es aquí donde entra en escena nuestro villano: Jia Tan. O mejor dicho, alguien que se hacía llamar Jia Tan. Este personaje apareció de la nada y empezó a contribuir al proyecto XZ. A contribuir mucho y bien además. Hasta aquí, todo normal. Así es como funciona el Open Source y es la filosofía que hay detrás: gente de todo el mundo colaborando para mejorar el software.

Pero el tal Jia Tan tenía otros planes. Poco a poco, fue ganándose la confianza de la comunidad porque hacía un buen trabajo. Pero, como se supo luego, incluso estuvo detrás una campaña de acoso contra Lasse, tratando de minarle la moral y que lo dejase, presionándole para que cediera el control del proyecto a alguien. Y funcionó. Así que Lasse, cansado y desbordado porque además le estaban comiendo la moral para ello, le pasó el testigo a este Jia Tan, que tanto y tan bien había contribuido durante los últimos años, confiando en que haría un gran trabajo.

Lo que nadie sabía es que Jia Tan no era una persona, sino probablemente un grupo de hackers (además probablemente financiado por un Estado que no nombraré) con un plan meticulosamente elaborado y a largo plazo. Su objetivo: convertir XZ en un caballo de Troya que les diera acceso a prácticamente todos los sistemas importantes del mundo.

¿Cómo? Modificando XZ para que pudiera abrir una puerta trasera en OpenSSH, el programa que se usa para controlar remotamente la mayoría de los servidores de internet.

Lo que más miedo da es lo cerca que estuvieron de lograrlo. La versión manipulada de XZ ya estaba en fase de pruebas en varios sistemas operativos importantes (como los de RedHat) sin que nadie se diese cuenta, ni siquiera los mantenedores de esos sistemas operativos. De hecho, esto echa abajo también uno de los mitos de la seguridad y el Open Source: que miles de ojos observando pueden detectar a tiempo estos problemas. Cosa que no ocurrió, quizá porque el software era tan "pequeño".

Si no hubiera sido por el Trastorno Obsesivo Compulsivo y la curiosidad de un programador de Microsoft llamado Andres Freund, el ataque podría haber tenido éxito. Andres, que notaba que su SSH iba "un poco" lento, no pudo evitar investigarlo y, al hacerlo, descubrió la vulnerabilidad crítica introducida por estos crackers, y calificada con una puntuación perfecta de 10.0 en CVSS, el estándar que se usa en la industria informática para valorar las vulnerabilidades.

👁️ Te contamos la historia en el número de abril de nuestro boletín mensual para programadores, hace ya unos meses, cuando se descubrió todo.

Esta historia nos plantea preguntas incómodas. ¿Cómo es posible que un componente tan crucial de internet dependiera de una sola persona? ¿Cómo podemos confiar en el software que usamos si no sabemos quién lo mantiene realmente?

Pero más allá de eso, nos obliga a repensar nuestra relación con el Open Source. Porque si bien la apertura y la colaboración son su mayor fortaleza, también pueden convertirse en su talón de Aquiles si no las gestionamos adecuadamente.

La próxima vez que uses una biblioteca Open Source en tu proyecto, pregúntate: ¿quién está detrás de este código? ¿Cómo puedo contribuir a su mantenimiento? Porque, como hemos visto, la seguridad de prácticamente todo puede depender de ello.

La economía del Open Source

El Open Source ha revolucionado la economía del software de una forma que nadie podía prever hace 30 años. Ha pasado de ser el proyecto idealista de unos cuantos programadores a convertirse en el motor que impulsa a algunas de las empresas más valiosas del mundo.

Pero, mientras estas empresas ganan miles de millones gracias al Open Source y contribuyen por su propio interés a liberar nuevo código, muchos de los proyectos de los que dependen los siguen manteniendo voluntarios que trabajan en su tiempo libre y a los que nadie ayuda.

Es como si tuviéramos rascacielos de lujo construidos sobre cimientos que mantiene un tipo desde el garaje más profundo, en sus ratos libres del fin de semana. No hace falta ser un genio para ver que este modelo tiene sus lagunas.

Y es que el Open Source ha creado una especie de tragedia de los comunes digital. Todos nos beneficiamos de él, pero pocos se sienten responsables de su mantenimiento. Las empresas lo usan para ahorrar costes, los desarrolladores los usamos para aprender y para construir nuestros programas mucho más rápido, pero ¿quién se encarga de que todo siga funcionando?

Algunas empresas han intentado abordar este problema. Red Hat, por ejemplo, construyó un modelo de negocio basado en ofrecer soporte para software Open Source. GitHub (propiedad de Microsoft) lanzó un programa de patrocinio para mantenedores de proyectos. Pero estas iniciativas, aunque interesantes, no acaban de funcionar del todo y son solo una gota en el océano.

¿A cuántos proyectos Open Source patrocinas? ¿Y a cuántos contribuyes aunque sea revisando bugs o haciendo documentación? Quizá sí que lo hagas, y yo también, pero ya te digo que no es lo normal en absoluto.

El caso de XZ nos muestra las consecuencias potenciales de este desequilibrio. Un proyecto crucial para el funcionamiento de internet, mantenido por una sola persona sin apoyo económico, que acaba convirtiéndose en un agujero de seguridad (quizá el más gordo de la historia).

Vale, entonces, ¿cuál es la solución? No hay respuestas fáciles, pero está claro que necesitamos repensar cómo valoramos, financiamos y apoyamos el Open Source.

Como desarrolladores, tenemos que ser conscientes de que cada vez que usamos una biblioteca Open Source, estamos contrayendo una deuda técnica y ética. ¿Estamos dispuestos a contribuir al mantenimiento de las herramientas que usamos? ¿Los patrocinamos con 5€ al mes? ¿Podemos presionar a nuestras empresas para que destinen recursos (o sea, nuestro tiempo) a apoyar los proyectos de los que dependemos?

Porque al final, lo quieras o no, la economía del Open Source nos afecta a todos. Y si queremos seguir disfrutando de sus beneficios, tendremos que encontrar formas de hacerlo sostenible a largo plazo.

Protegiendo nuestro futuro digital: soluciones y responsabilidades compartidas

El Open Source es genial. Una de las mejores ideas espontáneas que han surgido de un grupo en las ultimas décadas. El caso de XZ solo es el más llamativo de los últimos tiempos, pero hay muchos más. Por ejemplo, cada vez que te bajas un paquete NPM para tu proyecto Front-End no sabes qué se está trayendo por debajo y qué agujeros de seguridad trae a tu sistema, porque ya ha pasado en varias ocasiones.

La buena noticia es que, como desarrolladores, tenemos el poder de cambiar las cosas. Somos los que diseñamos y construimos este mundo digital, así que tenemos la posibilidad de hacerlo más seguro y más justo. Aquí van algunas ideas concretas de cómo puedes contribuir:

1. Conoce lo que utilizas: haz un inventario de todas las bibliotecas y herramientas Open Source que usas en tus proyectos. ¿Sabes quién las mantiene? ¿Cuándo fue la última actualización? Conocer tu "cadena de suministro" de software es el primer paso para protegerla. Es de sentido común, pero no todos lo hacen.
2. Contribuye más allá del código: no hace falta ser un genio de la programación para ayudar. Puedes mejorar la documentación, reportar bugs de forma detallada, o incluso ayudar con traducciones. Cada granito de arena cuenta. Lo importante es tenerlo en mente y procurar sacar algún rato de vez en cuando para hacerlo.
3. Apoya económicamente: si tu empresa se beneficia de un proyecto Open Source, plantea la posibilidad de patrocinarlo. Lo puedes hacer por tan solo 5€ al mes, así que hasta siendo un desarrollador individual puedes hacerlo si quieres.
4. Considera mantener un proyecto: si usas mucho una biblioteca o una herramienta de código abierto pero ves que está poco mantenida, plantéate contribuir. Ya digo que no hace falta dominar el proyecto ni ser un megacrack. Puede ser traduciendo el proyecto o la documentación al español, arreglando un pequeño bug o contestando a las "issues" que escribe la gente. A veces es frustrante hacerlo y que luego no te hagan caso, que también pasa, pero al menos lo has intentado.
5. Educa a tus compañeros y a tus jefes: muchas empresas no son conscientes de cuánto dependen del Open Source. Ayuda a crear conciencia sobre su importancia y los riesgos de no cuidar el ecosistema con medidas como las anteriores. Divulgando esto se aporta mucho también.

Recuerda, el Open Source no es sacarle partido al código de otros: es una comunidad. Y como toda comunidad, necesita que sus miembros nos apoyemos mutuamente. No podemos seguir tratando el software libre como si fuera un recurso infinito y gratuito.

El caso de XZ nos ha mostrado lo cerca que podemos estar del desastre. Pero también nos ha enseñado el poder de la colaboración y la vigilancia colectiva. Fue la curiosidad de un desarrollador lo que evitó una catástrofe.

El futuro del Open Source, y por lo tanto de gran parte de nuestra infraestructura digital, está en nuestras manos. Y no vale decir que soy demasiado pequeño para hacer algo. Todo cuenta. No es un algo fácil, pero el primer paso es tener la mentalidad adecuada para empezar a hacer algo. Que es lo que estoy tratando de divulgar hoy.

Así que la próxima vez que uses una biblioteca Open Source, no te limites a bajártela y usarla. Piensa en las personas que hay detrás de ese código al que le vas a sacar partido y pregúntate: ¿qué puedo hacer yo para fortalecer este proyecto, esta comunidad? Aunque sea algo pequeño.

Porque al final, estarás invirtiendo en tu propio futuro digital.