Nadie paga por el software libre: cobrar en los registros

El código libre que sostiene la economía digital no recibe dinero de quien lo consume

Un estudio de Harvard estima que reemplazar el software de código abierto costaría 8,8 billones de dólares a las empresas. Un análisis de Sonatype sobre 1,2 millones de proyectos en 2023 encontró que solo el 11% se mantenía activamente. Y según el Census II de la Linux Foundation, 136 desarrolladores escribieron más del 80% del código en los 50 paquetes más usados. El mismo estudio de Harvard concluyó que el 5% de los desarrolladores produce el 96% del valor.

Para cualquier founder hispanohablante, esos números significan una cosa: el software sobre el que corre tu stack, desde React hasta PostgreSQL, descansa sobre un grupo extraordinariamente pequeño de personas que, en su mayoría, no cobran por hacerlo. No es un tema ideológico. Es una cuestión de dónde se captura el dinero en la cadena de suministro.

¿Quién paga hoy por el software libre? Las empresas, pero no a quien lo escribe

Las empresas sí pagan por código abierto, solo que el dinero no llega a los maintainers. JFrog, que vende Artifactory —un mirror privado que se coloca entre los servidores de build y los registros públicos—, tuvo 532 millones de dólares de ingresos en 2025, un 24% más que el año anterior. Snyk, dedicado al escaneo de vulnerabilidades en dependencias, ronda los 326 millones anuales. Docker, que opera el registro del que sale casi toda imagen de contenedor, factura 207 millones. Chainguard, que vende versiones endurecidas de imágenes open source, pasó de unos 40 millones a un objetivo de 100 millones en un año.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En septiembre de 2026, Gartner incluyó a JFrog como Leader en su primer Magic Quadrant de Software Supply Chain Security, una señal clara de que el mercado de "asegurar código que no escribiste" ya no es nicho.

¿Qué compran exactamente estas empresas? Seguro. Una capa que garantiza que tus builds no se rompan cuando el registro público cae, que tus dependencias están escaneadas, firmadas y son realmente lo que dicen ser, y que cuando ocurra el próximo Log4Shell puedas saber en una hora cuáles de tus dos mil servicios están afectados. Es un problema real que los departamentos de compras saben cómo presupuestar. El problema es que ese dinero se queda dos capas arriba del maintainer, que es justamente la persona que puede hacer el código más seguro.

El caso xz y el costo humano del "equilibrio estable"

En 2024 se descubrió que xz Utils, una biblioteca de compresión presente en prácticamente cada máquina Linux del planeta, contenía una puerta trasera insertada durante dos años por un contribuidor falso que había engañado al único mantenedor no pagado del proyecto. La puerta trasera la detectó un ingeniero de Microsoft que notó que SSH tardaba medio segundo más de lo debido. Es exactamente el tipo de defensa que no quieres como única línea de seguridad.

La encuesta 2024 de Tidelift, replicada por Socket, confirma que el patrón no es excepcional: el 60% de los maintainers no cobra por su trabajo, el 61% de los que no cobran mantiene su proyecto solo, y el 60% ha dejado o ha pensado en dejar de mantener. Lo más elocuente: el 81% preferiría recibir un ingreso mensual predecible, y solo el 7% un pago único. La mayoría no recibe ninguna de las dos cosas.

El cofundador de Tidelift, Luis Villa, resumió así la situación: "En ninguna otra parte de la economía global esperamos que voluntarios resuelvan nuestros problemas, pero aparentemente eso es lo que estamos haciendo aquí".

¿Por qué treinta años de pedir caridad no han movido el equilibrio?

En julio de 2026, GitHub Sponsors superó los 100 millones de dólares en pagos acumulados desde su lanzamiento. Suena mucho hasta que lo pones al lado de 8,8 billones. La distribución es la de siempre: ley de potencias, unos cuantos perfiles conocidos viven de esto y la mediana mantiene su almuerzo.

Las fundaciones (Linux Foundation, Apache, OpenJS, Python Software Foundation) pagan sueldos, eventos e infraestructura, pero según la misma encuesta de Tidelift solo el 3% de los maintainers recibió dinero de una fundación y el 1% de un gobierno. El Sovereign Tech Fund de Alemania lleva más de 24 millones de euros a unos sesenta proyectos desde 2022, pero es un único fondo en uno de los 190 países, con un presupuesto anual cercano a los 20 millones.

La generosidad corporativa tiene su propio techo. Dan Lorenc, ex Google y OpenSSF, reconoció que tenían más dinero del que podían dar y aun así no arreglaron nada. El Open Source Pledge de Sentry, que pide 2.000 dólares por desarrollador al año, arrancó en 2024 con aproximadamente 1,3 millones comprometidos.

Lo que une a todos estos intentos es que son voluntarios. Se pide a las empresas que donen, algunas donan, la mayoría no, y las que no donan reciben exactamente el mismo software que las que sí. Treinta años de pedir son, en palabras del autor del artículo —ex director de npm durante cinco años—, una apelación completamente testeada que no escaló.

La propuesta: cobrar a las empresas en el registro, pagar a los maintainers

La propuesta del artículo se sostiene sobre tres piezas que ya existen por separado. Primero, los registros miden el uso corporativo y lo cobran. npm, PyPI, Docker Hub y Maven Central ya tienen rate limits, autenticación y tiers empresariales; los vendors de mirrors ya facturan por asiento. La regla de Docker es la correcta: individuos, equipos pequeños y proyectos open source no pagan y ni se enteran; una empresa por encima de cierto tamaño paga una suscripción al nivel que procurement firma sin agendar una reunión.

Segundo, una parte fija de esa facturación es una regalía y va a los paquetes. Pro rata, a cada paquete que aparece en los árboles de dependencias de los clientes que pagan, ponderado por cuántos clientes dependen de él, de forma automática, cada mes, sin solicitudes ni formularios. thanks.dev ya hace distribución pro rata sobre árboles de dependencias; Flossbank lo hizo entre 2020 y 2022 y funcionaba. Lo que nunca se conectó fue la mitad de la recolección con la mitad del pago.

Tercero, quienes lo hacen son quienes ya son dueños del dominio. Hay unas doce registries que importan; cada maintainer ya tiene cuenta en la que le importa, con nombre y un método de pago a un campo de distancia. GitHub es dueño de npm y de GitHub Sponsors y tiene todas las piezas en un mismo edificio.

La objeción obvia es que las empresas migrarán a un mirror gratis. No lo harán por la misma razón por la que ya pagan a JFrog medio billón al año sin que ningún mirror gratis los coma: lo que compran no es el código, es no tener que pensar de dónde sale.

Valkey, OpenTofu y Redis: lo que pasa cuando intentas cobrar por la licencia

Tres intentos recientes ilustran por qué la propuesta pasa por el registro y no por la licencia. En 2021 Elastic movió Elasticsearch a una licencia source-available para frenar a Amazon; Amazon lo forkeó como OpenSearch, el fork pasó a la Linux Foundation y en 2024 Elastic volvió silenciosamente a una licencia abierta. En 2023 HashiCorp hizo lo mismo con Terraform; OpenTofu pasó a la Linux Foundation y HashiCorp terminó adquirida por IBM. En 2024 Redis replicó el movimiento; Valkey recogió a todos los cloud providers en una semana y en mayo de 2025 Redis restituyó la AGPL con su CEO admitiendo que el cambio les había costado enormemente. En mayo de 2026, según reportó Diginomica, Valkey publicó su versión 9.1 con búsqueda híbrida y agentes de IA integrados al propio flujo de mantenimiento del proyecto, bajo gobierno de la Linux Foundation.

Cada vez que alguien intentó ser "un halcón" en el juego del código, un fork competente lo devolvió al estado de paloma. La estructura del mercado lo exige, no la ideología.

¿Qué significa esto para tu startup?

Si diriges una empresa tech que depende de software libre, hay dos cosas concretas que puedes hacer hoy:

Audita tu cadena de suministro de software con el mismo rigor que auditas a tus proveedores de nube. Pregunta qué paquetes críticos de tu stack tienen un solo maintainer, cuántos llevan meses sin release y quién los paga. La pregunta ya no es técnica, es de riesgo corporativo: si tu proveedor crítico de una dependencia se quema, ¿cuánto tarda tu producto en caer con él?
Si vendes software a desarrolladores (un SaaS, una herramienta, un marketplace), internaliza que ya estás pagando por no operar tu propia cadena de suministro al contratar infraestructura de registros y mirrors. Lo que la propuesta plantea es que una fracción de esa factura se reparta automáticamente a quien mantiene el código del que dependes, sin que tengas que negociar nada ni montar un programa de grants propio.

El cambio más importante no es técnico, es mental: dejar de tratar al software libre como caridad y empezar a tratarlo como lo que ya es, un insumo crítico por el que tu empresa ya paga, solo que a la capa equivocada.