60% de mantenedores open source no cobra: la propuesta de forzar el pago

⏱️ Lectura: 13 min

El 60% de los mantenedores de proyectos open source no cobra nada por su trabajo, y ese número no cambió en tres años: Tidelift lo midió igual en 2021, 2023 y 2024. Redis, Elasticsearch y HashiCorp probaron cobrar de todas formas entre 2021 y 2024, cambiando la licencia de sus proyectos estrella, y las tres perdieron contra un fork gratuito en menos de un año. Un ensayo publicado en Seldo.com plantea una salida distinta: forzar el pago no desde la licencia, sino desde el registry por donde pasan todas las descargas.

📑 En este artículo

1. TL;DR
2. Introducción
3. Qué pasó
4. Contexto e historia
5. Detalles técnicos y rendimiento
6. Cómo empezar a pagarle a los mantenedores open source que usás
7. Impacto y análisis
8. Qué sigue
9. Preguntas frecuentes
   1. ¿Qué significa que el open source sea una estrategia evolutivamente estable?
   2. ¿Por qué Redis, Elasticsearch y Terraform no pudieron cobrar por su código?
   3. ¿Qué es Valkey y por qué le ganó a Redis?
   4. ¿Cómo puede una empresa empezar a pagarle a los mantenedores que usa?
   5. ¿Qué es el Census II de Linux Foundation?
   6. ¿Los registries como npm o PyPI ya cobran por publicar paquetes?
10. Referencias

La propuesta no es filosófica: implica que npm, PyPI o crates.io cobren peaje a las empresas que más descargan sin retribuir nada a cambio.

TL;DR

• El 60% de los mantenedores de open source no cobra por su trabajo, el mismo porcentaje que en 2023 y 2021, según Tidelift.
• 136 desarrolladores escriben más del 80% del código de los 50 paquetes open source más usados, según el Census II de Linux Foundation.
• Un estudio de Harvard calculó que reemplazar todo el software open source costaría 8,8 billones de dólares a las empresas que lo usan gratis.
• Solo el 5% de los desarrolladores produce el 96% del valor generado por el open source, según ese mismo estudio.
• Facebook relicenció React de BSD+Patentes a MIT en 2017, en semanas, tras el rechazo de Apache Software Foundation y WordPress.
• Elastic cerró Elasticsearch en 2021, Amazon forkeó OpenSearch, y en 2024 Elastic volvió a una licencia abierta.
• HashiCorp cerró Terraform en 2023, nació el fork OpenTofu en Linux Foundation, y HashiCorp terminó comprada por IBM.
• Redis cerró su licencia en marzo de 2024, el fork Valkey sumó a todos los proveedores cloud en una semana, y Redis volvió a AGPL en mayo de 2025.

Introducción

La sostenibilidad de los mantenedores open source volvió a la conversación técnica después de una serie de intentos fallidos por cobrar directamente en la licencia. El patrón se repite desde 2017: una empresa que sostiene un proyecto de código abierto intenta cambiar los términos para frenar a un proveedor cloud que revende su trabajo sin aportar nada, la comunidad reacciona con un fork bajo una fundación neutral, y ese fork termina ganando el mercado en meses.

El ensayo de Seldo.com no se detiene en el diagnóstico. Argumenta que mientras la licencia sea el único mecanismo de cobro, el resultado va a ser siempre el mismo: el software libre gana por diseño, porque compite contra software cerrado que cuesta dinero. La alternativa que propone corre por otro carril: usar el registry, el sistema que reparte cada paquete a cada instalación, como punto de cobro en lugar de la licencia.

Qué pasó

Cuatro proyectos probaron, por separado, cerrar su licencia para frenar a quien los revendía sin pagar. Los cuatro terminaron perdiendo contra un fork abierto, aunque con matices distintos en cada caso.

Proyecto	Cambio de licencia	Fork abierto	Resultado
React	2017: Apache Software Foundation prohíbe la licencia BSD+Patentes de Facebook en sus proyectos	Sin fork: WordPress anunció que abandonaba React	Facebook relicencia a MIT en semanas
Elasticsearch	2021: Elastic pasa a licencia source-available para frenar el servicio gestionado de Amazon	OpenSearch (Amazon, luego Linux Foundation)	Elastic vuelve a licencia open source en 2024
Terraform	2023: HashiCorp cambia a Business Source License	OpenTofu, bajo Linux Foundation	HashiCorp termina comprada por IBM
Redis	Marzo de 2024: Redis Labs pasa a licencia dual con SSPL y RSALv2	Valkey, adoptado por AWS, Google Cloud y Oracle en una semana	Redis vuelve a AGPL en mayo de 2025

El caso de Valkey es el más rápido de los cuatro: la fundación recibió el fork, sumó a los tres proveedores cloud grandes en cuestión de días, y Redis admitió que el cambio de licencia le había costado más de lo que ganó al revertirla en 2025. OpenTofu siguió un camino parecido con Terraform. Hoy vive en Linux Foundation con cientos de contribuyentes, mientras HashiCorp pasó a manos de IBM.

Contexto e historia

El ensayo de Seldo.com explica este patrón con un modelo de teoría de juegos tomado de biología evolutiva: halcones y palomas. En una población que compite por un recurso, los halcones pelean por él y las palomas lo comparten. Una población de puros halcones es inestable porque todos terminan lastimados; una población de puras palomas también es inestable porque el primer halcón que aparece gana siempre. Lo único estable es una mezcla de ambos en una proporción donde cambiar de estrategia no mejora el resultado individual. Esa mezcla se llama estrategia evolutivamente estable (ESS).

💭 Clave: una estrategia evolutivamente estable no es necesariamente la mejor posible, es la única de la que ningún jugador individual gana algo por abandonarla. Por eso ninguna empresa logró sostener una licencia cerrada frente a un fork bien organizado.

Aplicado a software, el código cerrado es el halcón: compite, cobra caro y pelea por quedarse con la ventaja. El open source es la paloma: coopera y se beneficia de que los demás también cooperen. La estrategia evolutivamente estable a la que llegó la industria es muy específica: cualquiera puede usar el código para lo que quiera, incluso comercialmente, gratis. Esa es la promesa de licencias como MIT, BSD y Apache. Cada vez que un proyecto intentó ser una paloma un poco menos generosa, perdió contra un proyecto que se mantuvo totalmente gratis.

flowchart TD
A["Proyecto abre su codigo con licencia permisiva"] --> B["Proveedor cloud lo revende sin aportar codigo"]
B --> C["La empresa mantenedora cierra la licencia"]
C --> D["La comunidad crea un fork abierto"]
D --> E["El fork migra a una fundacion neutral"]
E --> F["Los proveedores cloud adoptan el fork"]
F --> G["La empresa original revierte a licencia abierta"]

Ese ciclo explica por qué el mercado del software terminó dividido en dos mitades muy desiguales: una mitad enorme y gratuita que usa casi todo el mundo, y una mitad chica y cara que concentra casi todas las ganancias. Android tiene el volumen y iOS tiene el margen, y las dos estrategias son un éxito según qué número se mire. El open source gana en adopción; el software cerrado gana en ingresos.

Detalles técnicos y rendimiento

El problema no es abstracto: recae sobre un grupo muy pequeño de personas. Según el Census II de la Linux Foundation, citado en el ensayo de Seldo.com, 136 desarrolladores escriben más del 80% del código de los 50 paquetes open source más usados del mundo. Sonatype revisó 1,2 millones de proyectos open source en 2023 y encontró que solo el 11% tenía mantenimiento activo. De los mantenedores sin pago, el 61% trabaja completamente solo, sin un segundo par de manos que lo cubra si se enferma, cambia de trabajo o simplemente se cansa.

Un estudio de Harvard calculó qué pasaría si el open source desapareciera de un día para el otro. Reemplazarlo con software propio o contratado costaría 8,8 billones de dólares a las empresas que hoy lo usan gratis. El mismo estudio encontró que apenas el 5% de los desarrolladores produce el 96% de ese valor. Es la razón técnica detrás del agotamiento de tantos mantenedores open source: la carga no se reparte parejo, se concentra en un puñado de proyectos de los que depende buena parte de internet.

Acá es donde entra la propuesta de los registries. Hoy, un registry como npm sabe cuántas descargas tiene cada paquete, qué organizaciones lo instalan y con qué frecuencia. Esa telemetría ya existe: lo que no existe es un mecanismo que la convierta en un cobro. El campo funding de package.json, por ejemplo, es la versión actual y completamente voluntaria de esa idea. Un mantenedor declara dónde recibir donaciones, pero nada obliga a nadie a mirarlo, y mucho menos a pagar.

Cómo empezar a pagarle a los mantenedores open source que usás

Antes de pensar en si un registry debería cobrar peaje, cualquier equipo puede medir cuánto le debe hoy al open source que usa gratis. El primer paso es ver qué porcentaje de sus dependencias directas declara un canal de financiamiento:

npm fund

Este comando recorre el árbol de dependencias del proyecto actual y lista los links de financiamiento que cada paquete declaró en su package.json. Si nunca lo corriste, es habitual que la lista salga vacía o casi vacía, aunque el proyecto tenga cien dependencias.

Si mantenés una librería propia, declarar dónde recibir apoyo toma dos minutos. Este es un package.json con el campo funding apuntando a Open Collective:

{
  "name": "componente-interno",
  "version": "2.3.0",
  "description": "Cliente HTTP interno con reintentos y circuit breaker",
  "funding": {
    "type": "opencollective",
    "url": "https://opencollective.com/componente-interno"
  }
}

Para confirmar cuántas de tus dependencias directas ya declaran ese campo, sin leerlas una por una, podés cruzar la salida de npm con jq:

npm fund --json | jq 'keys | length'

Ese número, comparado contra el total de dependencias directas (npm ls --depth=0 --json | jq '.dependencies | keys | length'), es una forma rápida de ver qué tan lejos está tu stack de un modelo donde alguien además del mantenedor original se hace cargo del costo.

⚠️ Ojo: forzar el pago desde el registry tiene un problema de raíz. npm, PyPI y crates.io también son proyectos con presupuesto ajustado: pedirles que arbitren qué empresa paga cuánto agrega una capa de gobernanza que hoy no existe ni está financiada, y que alguien tendría que operar.

Impacto y análisis

La idea de mover el cobro de la licencia al registry cambia quién tiene el poder de negociación. Con una licencia, el mantenedor negocia solo contra cada empresa que lo usa, y pierde casi siempre porque un fork gratuito está a un git clone de distancia. Con un registry, el punto de cobro es infraestructura compartida: todo el mundo tiene que pasar por ahí para instalar el paquete, así que forkear el código no alcanza, también habría que forkear la distribución.

Ese cambio de punto de apoyo ya tiene precedentes parciales. Tidelift arma contratos entre empresas y mantenedores curados. Open Collective y GitHub Sponsors canalizan donaciones puntuales. El Sovereign Tech Fund de Alemania financia directamente infraestructura crítica de internet. Ninguno de estos mecanismos, sin embargo, es obligatorio: dependen de que una empresa decida pagar por voluntad propia, exactamente lo que el 60% de los proyectos no consigue.

La limitación real de la propuesta es de gobernanza, no técnica. Un registry podría, en teoría, exigir una cuota a partir de cierto volumen de descargas corporativas. Pero definir qué cuenta como uso corporativo, cobrar en decenas de países con regulaciones distintas y resolver disputas sobre quién debe pagar cuánto es un trabajo que ni npm, ni PyPI, ni crates.io tienen hoy presupuesto ni mandato legal para hacer. Son fundaciones o empresas con equipos chicos, no reguladores.

Qué sigue

El ensayo de Seldo.com no propone una fecha ni una implementación cerrada, plantea la dirección. Lo más probable en el corto plazo es que la presión siga viniendo de mecanismos ya existentes, no de un cambio estructural en cómo funcionan los registries. Sovereign Tech Fund, Tidelift y Open Collective van a seguir creciendo, y es esperable que más registries agreguen fricciones suaves, como avisos o rankings de dependencias sin financiamiento, antes que cobros obligatorios.

El caso Redis-Valkey dejó una lección que cualquier empresa que dependa de un solo proveedor de open source debería anotar: cambiar la licencia no resuelve el problema de fondo, solo mueve el conflicto un paso más adelante. Mientras el registry no tenga un mecanismo propio de cobro, la estrategia evolutivamente estable va a seguir premiando a quien regala su código y castigando a quien intenta cobrar por él.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré npm fund en el proyecto que tengas abierto ahora mismo y contá cuántas de tus dependencias directas no tienen ningún canal de financiamiento declarado.

Preguntas frecuentes

¿Qué significa que el open source sea una estrategia evolutivamente estable?

Es un concepto de teoría de juegos aplicado a licencias de software: describe el punto de equilibrio al que llega el mercado, no el punto ideal. En ese equilibrio, ningún proyecto individual gana nada por dejar de regalar su código, porque siempre aparece un fork gratuito que lo reemplaza.

¿Por qué Redis, Elasticsearch y Terraform no pudieron cobrar por su código?

Porque en cada caso apareció un fork bajo una fundación neutral (Valkey, OpenSearch, OpenTofu) que mantuvo la licencia original y sumó rápido a los mismos proveedores cloud que la empresa original quería frenar.

¿Qué es Valkey y por qué le ganó a Redis?

Valkey es el fork de Redis que nació en marzo de 2024, cuando Redis Labs cambió a una licencia dual con SSPL y RSALv2. AWS, Google Cloud y Oracle lo adoptaron en la primera semana, antes de que Redis pudiera revertir el cambio en mayo de 2025.

¿Cómo puede una empresa empezar a pagarle a los mantenedores que usa?

Corriendo npm fund, o el equivalente en su gestor de paquetes, para ver qué dependencias declaran un canal de donación, y sumándose a plataformas como Tidelift, Open Collective o GitHub Sponsors para las que más usa.

¿Qué es el Census II de Linux Foundation?

Es un estudio que mapea quién escribe el código de los paquetes open source más usados del mundo. Encontró que apenas 136 personas escriben más del 80% del código de los 50 paquetes con más descargas.

¿Los registries como npm o PyPI ya cobran por publicar paquetes?

No. Publicar un paquete público en npm, PyPI o crates.io es gratis y no requiere ninguna cuota. El campo funding de package.json es voluntario: declara dónde donar, pero no obliga a nadie a pagar.

Referencias

• Seldo.com: el ensayo original, “Nobody pays for open source. We can force them to.”
• OpenTofu: el fork abierto de Terraform, hoy bajo Linux Foundation.
• Valkey: el fork abierto de Redis adoptado por los grandes proveedores cloud.
• OpenSearch: el fork abierto de Elasticsearch, originado por Amazon.
• Documentación de npm: referencia del campo funding en package.json.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.