Cuando el bazar se defiende: la década de los forks
En 2004, Lawrence Rosen escribió que los forks (la escisión de un proyecto en dos ramas rivales) habían demostrado ser muy raros en el mundo open source. Era cierto entonces. Veinte años después, el fork se convirtió en el mecanismo central de disciplina del ecosistema, y la historia de cómo pasó eso es la mejor clase de gobernanza tecnológica disponible.
El detonante fue el problema del polizón a escala industrial. Rosen lo había descrito en abstracto: en open source no puedes impedir que otros lucren con tu trabajo sin devolver nada. Lo que nadie dimensionó fue que los polizones serían los actores más grandes de la economía digital. Los hiperescaladores de nube tomaron software abierto exitoso (bases de datos, buscadores, herramientas de infraestructura), lo ofrecieron como servicio administrado y capturaron la renta sin contribuir proporcionalmente al desarrollo. Legal al cien por ciento: recuerden la entrega 4, ofrecer software como servicio no es distribuir y no gatilla reciprocidad alguna.
La reacción de las empresas afectadas fue una ola de relicenciamientos hacia esquemas que ya no son open source: MongoDB inventó la SSPL, Elastic cambió Elasticsearch, Redis abandonó la BSD, HashiCorp pasó Terraform a una licencia de disponibilidad de código con restricciones de competencia. El término de arte es source available: puedes ver el código, pero las libertades de la definición open source ya no están completas. Cada anuncio vino envuelto en el mismo argumento: sostenibilidad. Cada uno era, también, un cambio unilateral de las reglas del juego a mitad del partido.
¿Cómo pudieron hacerlo, si el software tenía miles de contribuyentes? La lección jurídica la dio Rosen hace veinte años: no puedes relicenciar contribuciones que no posees. La llave del relicenciamiento son los acuerdos de contribución (CLA) que concentran la titularidad o los derechos de relicenciamiento en la empresa. Ese CLA que firmaste sin leer, para proteger el proyecto, es exactamente el instrumento que permite cerrarlo mañana. Moraleja para cualquiera que contribuye código: lee lo que cedes, y prefiere proyectos donde la titularidad está distribuida o en manos de una fundación neutral.
Porque la respuesta de la comunidad fue institucional, no retórica. El relicenciamiento opera solo hacia adelante: las versiones ya publicadas bajo licencia abierta son irrevocables. Sobre esa base se montaron forks institucionalizados bajo fundaciones: Terraform se bifurcó en OpenTofu bajo la Linux Foundation; Redis, en Valkey; Elasticsearch ya se había bifurcado en OpenSearch. La diferencia con los forks caóticos del pasado es la infraestructura de confianza: una fundación neutraliza la titularidad, imposibilita el cierre unilateral futuro y le da a los usuarios corporativos la certeza que necesitan para migrar. El fork hereda comunidad, no solo código.
El epílogo es elocuente y ya no es un caso aislado. Elastic, que encendió una de las mayores controversias, volvió en 2024 a ofrecer sus productos bajo AGPL. Redis hizo lo mismo en mayo de 2025, con el regreso de su creador original, Salvatore Sanfilippo, empujando la rectificación: Redis 8 sumó AGPLv3 como tercera opción de licencia. Y HashiCorp, que nunca revirtió, terminó comprada por IBM en 2025. Cerrar tiene costos de mercado que los balances tardan un par de años en mostrar: pérdida de comunidad, de confianza, de canal de distribución. Pero la lección más dura de 2026 es la otra mitad: las reversiones no revirtieron la migración. Valkey es hoy la opción por defecto en AWS ElastiCache y Google Memorystore, y en Fedora, Ubuntu y Debian; OpenTofu supera los diez millones de descargas. El péndulo de la licencia existe; el de la comunidad, no.
La lección general excede al software. La licencia te dice qué puedes hacer hoy; la gobernanza te dice qué te pueden hacer mañana. Al evaluar dependencia de cualquier tecnología abierta (y esto aplica letra por letra a los modelos de IA de pesos abiertos, tema de la próxima entrega), las preguntas correctas son dos y en este orden: quién tiene la titularidad y qué instituciones limitan su discreción. Un proyecto con licencia perfecta y titularidad concentrada es una promesa unilateral, y las promesas unilaterales se cambian por comunicado de prensa.
Próxima entrega: la más importante de la serie. Por qué la IA open source casi nunca es open source, qué exige la definición de la OSI y qué significa que los pesos abiertos sean el binario y no el código.l código.