Rug pulls, forks y el feudalismo del código abierto

• Un repaso de cómo funcionan las dinámicas de poder en el ecosistema open source entre empresas, desarrolladores y usuarios, y del impacto de tácticas como el rug pull (relicenciamiento) y el fork para alterar ese equilibrio
• Mientras los grandes proveedores de nube ejercen una fuerte influencia, los proyectos centrados en una sola empresa pueden relicenciar para redistribuir el poder, y como respuesta aparecen los forks
• El análisis de casos como Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey y Puppet→OpenVox muestra distintos patrones de reconfiguración de comunidades y movimiento de contribuidores
• La adopción de CLA, el control de una sola empresa y el momento del traspaso a una fundación se señalan como señales de riesgo de rug pull, y se recomienda gobernanza neutral y ampliar la base de contribuciones multiinstitucionales como estrategia de respuesta
• En conclusión, el relicenciamiento puede servir para contener a los proveedores de nube, pero también debilita el poder de los contribuidores, mientras que la posibilidad de un fork actúa como freno sobre la toma de decisiones empresariales

---

Estructura de poder en el open source, rug pulls y forks

• En el ecosistema del software open source, grandes empresas, pymes, contribuidores y usuarios ejercen poder para influir en la dirección del software y en la estructura de ingresos
• En particular, los grandes proveedores de nube han acumulado un poder considerable y tienden a imponerse sobre empresas pequeñas o comunidades
• En este contexto, se producen desplazamientos de poder cuando la empresa desarrolladora o propietaria del proyecto cambia la licencia del software (rug pull) o, por el contrario, cuando la comunidad u otra empresa impulsa un fork

Panorama de las dinámicas de poder y las tácticas

• En el mundo open source, los grandes proveedores de nube ejercen el mayor poder de canal y distribución, formando una estructura que explota a empresas pequeñas, contribuidores y usuarios
  • De forma similar al control de la tierra en el feudalismo, los proveedores de nube convierten el software open source en servicio y evitan contribuir
  • Las empresas pequeñas hacen la mayor parte del trabajo de desarrollo, pero quedan en desventaja porque los proveedores de nube aprovechan ese trabajo gratis
• Como táctica de rug pull, las empresas pequeñas relicencian el software para responder a los proveedores de nube, pero esto termina perjudicando aún más a contribuidores y usuarios
  • Los proveedores de nube debilitan el poder de las empresas pequeñas al convertir el proyecto en servicio sin contribuir
  • El relicenciamiento perjudica a los usuarios, pero el fork permite reajustar el equilibrio de poder
• En los proyectos liderados por una sola empresa, el riesgo de rug pull es alto, por lo que conviene evaluar la reputación de la compañía, aunque eso puede dejar de servir ante adquisiciones o quiebras
  • La presión de los inversionistas puede impulsar relicenciamientos para aumentar ingresos, sobre todo cuando se compite con proveedores de nube
  • Al usar licencias más restrictivas, se busca dificultar que terceros moneticen el software y así desplazar el poder
• La creación de forks tras un rug pull es una forma de acción colectiva rebelde para recuperar poder, pero el riesgo de fracaso es alto por falta de personal y recursos
  • Las grandes empresas o proveedores de nube pueden apoyar forks con sus recursos, pero un fork popular no siempre tiene éxito
  • Hay casos como MongoDB o Sentry donde no surgió un fork; en Puppet, la adquisición por parte de Perforce y el cierre del desarrollo provocaron el fork de OpenVox

Comparación de casos principales

Dawn Foster analiza con datos varios casos de rug pulls, forks y sus efectos posteriores. (Se publicaron parcialmente los resultados a través de un dataset en Jupyter Notebook)

• Elasticsearch → OpenSearch
  • En 2021, tras el relicenciamiento a SSPL de Elastic, AWS organizó el fork OpenSearch
  • En Elastic, la proporción de contribuidores internos casi no cambió antes y después del fork; en OpenSearch se mantuvo un patrón de contribuciones lideradas por Amazon
  • El análisis indica que incluso después del traspaso a la Linux Foundation en 2024 no se observó un aumento fuerte de contribuciones externas
• Terraform → OpenTofu
  • En 2023, justo después del cambio a BSL por parte de HashiCorp, OpenTofu nació bajo la Linux Foundation
  • Terraform siguió manteniendo contribuciones centradas en personal interno, mientras que OpenTofu recibió rápidamente nuevos contribuidores de varias empresas
  • Este caso sugiere que un fork impulsado por usuarios + el nacimiento bajo una fundación neutral favoreció la formación de una comunidad activa
• Redis → Valkey
  • En 2024, justo después del cambio a SSPL de Redis, muchos de los contribuidores externos existentes se movieron a Valkey
  • Redis era un caso excepcional porque antes del fork tenía una alta proporción de contribuciones externas; después del fork cayó abruptamente a 0 contribuciones externas, mientras que Valkey arrancó como una comunidad aliada de múltiples empresas
• Puppet → OpenVox
  • Tras la adquisición por Perforce (2022), hubo cierre del desarrollo y de los lanzamientos y una reducción en la frecuencia de releases; en respuesta, la comunidad impulsó el fork OpenVox

Observaciones de datos y métricas

• Después de un rug pull, suele observarse un aumento brusco en la cantidad de forks en GitHub, lo que se interpreta como una señal proxy de movimientos para evaluar un hard fork
  • A largo plazo, el original y el fork tienden a avanzar en paralelo, pero el análisis observa que el original relicenciado tiende a perder uso
• Nacer bajo el paraguas de una fundación ayuda a atraer contribuciones en la etapa inicial de un proyecto nuevo, pero traspasarlo después puede tener un efecto limitado
  • El caso de OpenSearch sugiere que el simple traspaso no garantiza un aumento fuerte de contribuciones externas

Señales de riesgo y lineamientos

• El uso de CLA (Contributor License Agreement) es una señal de concentración del poder de relicenciamiento en manos de la empresa, lo que amplía el desequilibrio de poder
  • Los proyectos basados en DCO (Developers Certificate of Origin) tienden a tener un menor riesgo de rug pull
• Hace falta revisar la gobernanza, y el control de una sola empresa junto con la concentración del liderazgo son factores de riesgo
  • Los proyectos con fundación neutral, liderazgo multiinstitucional y base de contribuciones externas están mejor posicionados en términos de sostenibilidad
• La amplitud y profundidad de la base de contribuidores también es un criterio clave de evaluación
  • Las empresas deben fortalecer al mismo tiempo su influencia y la sostenibilidad de los proyectos de los que dependen enviando contribuidores propios
  • Las métricas y guías para practitioners de CHAOSS pueden usarse para diagnosticar y mejorar la salud de un proyecto

Propuestas sobre comunidad y gobernanza

• Promover una gobernanza neutral y ampliar la participación de contribuidores externos es una medida real para frenar los rug pulls
  • La posibilidad de un fork por sí misma eleva el costo de decidir un relicenciamiento para una empresa y actúa como mecanismo de disuasión
• Ante la pregunta de Hazel Weakly sobre mecanismos de protección, la ponente mencionó los éxitos de Valkey y OpenTofu como casos reales que llevaron a reconsiderar relicenciamientos
  • Dirk Hohndel subrayó que atraer más contribuidores externos aumenta el riesgo de rug pull y eleva el riesgo para la decisión gerencial

Conclusión

• A medida que crece la influencia de los grandes proveedores de nube, el ecosistema open source se está volviendo cada vez más feudal
• Cambiar la licencia sirve para contener el poder de los proveedores de nube, pero en el proceso trae el efecto secundario de reducir el poder de los contribuidores de la comunidad
• Sin embargo, para contribuidores y usuarios existe el fork como herramienta de respuesta, una fuerza propia del open source que lo diferencia del feudalismo histórico
• La posibilidad real de un fork influye en futuras decisiones de política empresarial y, de hecho, inspiradas por los casos exitosos de Valkey y OpenTofu, algunas empresas han retirado planes de rug pull
• En última instancia, la neutralidad de la gobernanza del proyecto y la activación de contribuidores externos son la clave para prevenir rug pulls y mantener un ecosistema saludable

Material de referencia

• Diapositivas de la presentación: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

Como hacer un fork todavía no es algo fácil, ojalá hubiera organizaciones relacionadas con el open source que ayudaran con esto.

[GN⁺]

Opinión de Hacker News

• Considero que en los proyectos que usan CLA (Contributor License Agreement) los rug pulls (cuando el esfuerzo de los contribuidores termina siendo apropiado por unos pocos) ocurren con más frecuencia, mientras que en los proyectos que usan DCO (Developers Certificate of Origin) este desequilibrio es menor. Al firmar un CLA, le das al proyecto el derecho de relicenciar el código que aportas. Es decir, incluso si contribuyes bajo GPL a un proyecto GPL, luego pueden cambiar la licencia. Si ya se trata de una licencia permisiva, el CLA no tiene mucho impacto, pero si es copyleft (por ejemplo GPL), entonces solo quien recibió el CLA puede apropiarse de forma exclusiva, lo que lo vuelve injusto. Para evitar un rug pull, conviene usar una licencia copyleft y evitar firmar un CLA. Con licencias permisivas, hay que entender que el rug pull es "parte del juego"
  • Los proyectos GNU también exigen CLA, pero no creo que lo hagan con la intención de hacer un rug pull
  • Quiero dejar claro que firmar un CLA no siempre otorga automáticamente todos los derechos de relicenciamiento; depende de cada CLA. Por ejemplo, según la cláusula del CLA de Canonical(enlace), también se promete que mi contribución estará disponible bajo la licencia existente. Es importante leer y entender el CLA. En la mayoría de los CLA, el copyright sigue siendo del contribuidor, así que uno conserva el derecho de hacer con su aporte lo que quiera. El problema de fondo es que puede romperse la confianza en el dueño del proyecto. El CLA le da control al propietario y aumenta el riesgo de rug pull. Para responder a un rug pull, en la práctica hay que hacer un fork y colaborar directamente ahí para obtener beneficios. Cuando se combina una licencia copyleft con un CLA (por ejemplo, AGPL + CLA), incluso puede ser más dañino que una licencia permisiva + CLA. La AGPL obliga a publicar el código también en despliegues como servicio, pero con un CLA el dueño puede ofrecer un servicio cerrado sin publicar sus mejoras. Casos reales como Incus y LXD muestran cómo la combinación de licencia y CLA puede provocar división en la comunidad y restricciones al compartir código(caso detallado)
  • Creo que en el open source no existe realmente un fenómeno de rug pull. Las copias GPL existen para siempre
  • Usar una licencia permisiva sí aumenta la posibilidad de rug pull, pero señalo que un CLA no siempre entrega todos los derechos
  • No creo que sea sano ver el discurso negativo del "rug pull" en open source desde una postura excesivamente purista. Los proyectos tienen que ser sostenibles. En una situación donde los grandes proveedores cloud monopolizan la infraestructura, pienso que sería mejor que los desarrolladores pequeños dedicaran su energía a aliviar ese monopolio de las grandes empresas en vez de pelear por disputas alrededor de proyectos open source o basados en CLA
• Los contribuidores y maintainers muchas veces tienen incluso menos poder que las pequeñas empresas. Aun así, con una licencia liberal, si uno no está conforme puede hacer un fork y tomar otro camino. El caso de Valkey muestra lo interesante que puede ser la dinámica de cambios de licencia con Redis. En general, siento que la comunidad de desarrolladores hoy está demasiado cómoda usando servicios cloud y le falta la iniciativa de antes para forkar o reimplementar sistemas operativos, compiladores o bases de datos. También suele pasarse por alto que empresas cloud como AWS ayudaron a dar visibilidad a muchos proyectos al ofrecerlos como servicio (por ejemplo, la popularidad de ElasticSearch después de que AWS lo ofreciera). Además, el cloud contribuye a kernel, gcc y jdk, lo que también beneficia indirectamente a empresas pequeñas. En vez de culpar tan fácilmente a los grandes proveedores cloud, sería bueno repensar el modelo de negocio. Si un proyecto hubiera empezado cerrado desde el principio, a nadie le habría importado
• Si en vez de recibir el software como binario lo compilas tú mismo desde el código fuente, tu capacidad de respuesta ante eventos como un rug pull aumenta. Quien instala desde binarios o imágenes del vendor lo tiene más difícil para cambiar a un fork, pero migrar la infraestructura de build a una nueva fuente es relativamente sencillo. Además, como puedes aplicar directamente los cambios o funciones que necesitas, disminuye la dependencia del mantenimiento ajeno
  • Esa es precisamente una de las razones por las que me gusta Guix. Compilar desde fuente es lo normal, pero también ofrece paquetes binarios mediante caché. Si no hay binario, compila la fuente localmente de forma reproducible. Incluso las versiones parcheadas pueden instalarse fácilmente con el mismo package manager, así que no hace falta una infraestructura de build aparte. En entornos de despliegue grandes, tener un servidor de build sí resulta eficiente
  • No sé por qué hay votos negativos, pero estoy de acuerdo. Compilar desde fuente por lo general no es difícil (véase sqlite)
  • En la práctica, las restricciones varían según la licencia del software. Incluso hay software comercial que entrega el código fuente, pero cuya licencia no permite modificarlo libremente. Por ejemplo, productos comerciales basados en lenguajes de scripting, o casos de consultoría empresarial donde se le entrega el código al cliente pero el derecho a compilarlo requiere pagar aparte
• Después del rug pull de Elasticsearch, que Amazon terminara contribuyendo directamente a un fork open source (OpenSearch) puede considerarse, aunque no era la intención inicial, como un resultado con cierto valor. Sin embargo, también es un tema importante que las grandes empresas generen inestabilidad en los proyectos por el desequilibrio entre quienes contribuyen y quienes se benefician
  • No hay problema en usar software cumpliendo la licencia; más bien, cuando desarrolladores o startups usan licencias permisivas pensando solo en la difusión y el crecimiento, y luego se quejan cuando entran los grandes proveedores cloud, hay una contradicción. No se puede tener ambas cosas al mismo tiempo
  • El resultado que Elastic buscaba era vender más licencias, pero muchos usuarios se pasaron al fork y la confianza en Elastic cayó. Incluso podría decirse que la competencia entre OpenSearch y ElasticSearch beneficia al ecosistema, pero ahora ambos productos ya no son compatibles y la posición de Elastic se debilitó
  • Las licencias copyleft como AGPL/GPL exigen por la fuerza contribuir el código de vuelta, así que pueden formar un ciclo de retroalimentación aun sin una licencia propietaria
• En los proyectos open source, un rug pull no se vuelve fácil solo por cambiar la licencia. El problema más de fondo es que no vivimos en una utopía donde cualquiera pueda trabajar gratis y aun así tener una buena calidad de vida. Sin maintainers, la vida media de un proyecto necesariamente será corta, y sin sponsorships la migración hacia licencias más cerradas se va a acelerar
  • Me recuerda al caso de la comunidad Bukkit con Mojang/Microsoft. Durante la contratación de desarrolladores, compraron el proyecto en secreto y terminaron haciendo que voluntarios trabajaran durante años sin pago, hasta que uno de ellos usó la DMCA para apagar el proyecto. Más detalles aquí: blog
  • Al final es un problema de incentivos. Aunque uno cree software open source directamente, los proveedores cloud pueden tomarlo fácilmente y monetizarlo. Sé que eso forma parte del significado de una licencia FOSS (Fully Open Source Software), pero siento que la sociedad se ha acostumbrado demasiado al trabajo gratuito. Por eso cada vez me parecen más atractivos enfoques nuevos como SSPL (Source-available licensing). Que por la diferencia de una sola cláusula AGPL sea foss y SSPL no lo sea me parece una confusión terminológica
• Entiendo la frustración de los usuarios frente a un rug pull, pero incluso las empresas que realmente lideran el desarrollo y mantenimiento de un proyecto tienen límites financieros y terminan con pocas opciones. Si no hay un modelo de ingresos, cambiar la licencia puede volverse inevitable. Como alternativas, se piensa en crowdfunding, reducir la carga de trabajo, vender merchandising o, si no hay fondos adicionales, avisar que el proyecto dejará de ser abierto. Texto relacionado
  • La esencia de la molestia es que primero se publicó como OSS, se ganó una base de usuarios y luego de repente se cambió a una licencia más cerrada. Si nunca hubiera sido OSS desde el comienzo, no habría sensación de traición, pero el problema es haber empezado como OSS para atraer usuarios y cambiar después
  • Mongo, Elastic, Redis y Hashicorp no estaban precisamente en una gran crisis financiera cuando hicieron el rug pull. En el caso de Hashicorp, incluso pudo haber sido una estrategia para aumentar su valor de adquisición
• Últimamente aumentan los casos en que se forman boards de gobernanza y modelos de operación más regulados para empujar a que los técnicos se retiren por cuenta propia, mientras se reprimen opiniones contrarias y se revocan permisos dentro del proyecto. En la práctica, se está introduciendo en la comunidad un ambiente orwelliano amparado en la "seguridad"
• Casi todos los usuarios de open source son free riders. Usamos libremente proyectos a los que no aportamos nada. Puede verse el open source como un regalo sin contraprestación, o como una cultura de aprender mirando la tarea de otros. Si quieres contribuir al mundo, hazlo con gusto, pero sin esperar ninguna recompensa. Llamarlo rug pull solo porque cambia la licencia también es una forma sesgada de verlo. Al fin y al cabo, ya recibimos el código; aunque sea triste que cambie la dirección del proyecto, nada en este mundo dura para siempre
  • La afirmación de que "la mayoría solo usamos sin devolver nada" no es completamente cierta. En muchos proyectos hubo contribuciones muy variadas en código, pruebas, documentación, marketing y evangelización. Estos proyectos no eran desarrollos silenciosos subidos por casualidad a GitHub, sino iniciativas donde la empresa invirtió mucho dinero en contratar evangelistas para difundir las ventajas técnicas y de licencia, y así ampliar la base de usuarios. En ese contexto, recibir grandes cantidades de código y contribuciones, cambiar de repente la licencia y romper esa promesa cuando otros proyectos FOSS ya dependen de ella, es precisamente lo que se critica como rug pull. Si fuera un proyecto que apareció casualmente en GitHub sin marketing y fue adoptado orgánicamente, probablemente no sería visto como un rug pull. Pero casi no he visto casos así
  • No creo que tenga que ser necesariamente así. Las empresas o entidades con recursos pueden mejorar la sostenibilidad de los proyectos open source de los que dependen mediante aportes financieros y técnicos. Hay formas como crear una Open Source Program Office, analizar todo el software usado y sus dependencias, dedicar tiempo de contribuidores y financiamiento, e impulsar esta cultura también en otras empresas del sector
• En la empresa donde trabajo también hay confusión entre la dirección por temas de rug pull. Siempre insistieron en tener contratos de soporte para los sistemas, pero situaciones parecidas se han repetido con Chef, CentOS, VMWare y Broadcom. Incluso cuando se planeaba pagar, el soporte básico de mantenimiento puede costar desde miles hasta decenas de miles de dólares al año, y aun así no inspira confianza. En este contexto, me parece mejor apoyar a una fundación o contratar directamente de forma periódica a maintainers de OSS. Antes me parecía una idea ingenua, pero cada vez veo más apoyo a esa postura. Personalmente, antes que pagarle a VMWare, contrataría a desarrolladores de Proxmox o qemu
  • Me parece una idea correcta. Es importante revisar todo el software utilizado y sus dependencias, garantizar sostenibilidad mediante tiempo de desarrollo y aportes económicos, y expandir esa actitud dentro del sector
  • Curiosamente, las empresas mencionadas crearon Open Source Program Offices con la intención de acercarse a la comunidad, pero cuando la organización se vuelve demasiado grande, esa dualidad entre comunidad e interés corporativo parece ser un costo inevitable
• Hacer un fork no es fácil; para que funcione hacen falta personas y recursos. El open source al final solo funciona cuando hay suficientes contribuidores. Si un fork muere, eso significa que había demasiados free riders en ese proyecto. Creo que el mayor problema del rug pull es que en la práctica se parece a publicidad engañosa. Se atrajo a clientes con la promesa de open source y, cuando dejó de convenirles, rompieron esa promesa, lo que es moralmente cuestionable. En cambio, que alguien deje de contribuir no me preocupa tanto. Nadie está obligado a quedarse para siempre en un proyecto, así que es natural que una persona o una empresa se retire de vez en cuando