La financiación del código abierto ya no es neutral: tu stack nunca votó
El dinero que mantiene vivo el software de base cada vez llega con una visión del mundo incorporada. Eso convierte la financiación en un mecanismo de bifurcación, y «¿en qué rama estoy?» en una pregunta que tu mapa de riesgos nunca se ha planteado.
La suposición más peligrosa sobre tu stack es que las partes aburridas están resueltas. En los últimos tres años la capa de caché, el índice de búsqueda y la herramienta de infraestructura como código, componentes que empresas enteras estandarizaron precisamente porque parecían permanentes, se han partido cada uno en ramas rivales financiadas por separado. La financiación del código abierto solía ser demasiado aburrida como para preguntarse por ella. Ahora decide qué rama de tu propia plataforma sobrevive, y a nadie en compras le llegó el memorando.
Empecemos por la capa de infraestructura. En agosto de 2023 HashiCorp trasladó Terraform y el resto de sus herramientas insignia de la licencia abierta Mozilla Public License a la Business Source License, que prohíbe a los competidores usarlas en producción. En cuestión de días, empresas cuyos productos dependen de Terraform publicaron el manifiesto de OpenTofu, y para septiembre la bifurcación ya tenía casa en la Linux Foundation, con sus patrocinadores comprometiendo ingenieros a tiempo completo durante al menos cinco años. La licencia de Terraform y la comunidad de Terraform viven ahora en edificios distintos.
La caché repitió la jugada más rápido. En marzo de 2024 Redis abandonó la licencia permisiva BSD que arrastraba desde su primer lanzamiento, en favor de condiciones duales «source-available». Días después la Linux Foundation anunció Valkey, una bifurcación de la última versión BSD, con AWS, Google Cloud y Oracle entre sus patrocinadores. Catorce meses más tarde, Redis 8 recuperó la AGPLv3, una licencia abierta aprobada por la OSI, entre sus opciones.
El índice de búsqueda ya había recorrido el arco completo antes. Elastic relicenció Elasticsearch y Kibana fuera de Apache 2.0 en enero de 2021, un movimiento dirigido directamente contra AWS. AWS respondió bifurcando ambos proyectos como OpenSearch, que hoy tiene fundación propia dentro del paraguas de la Linux Foundation. En agosto de 2024 Elastic añadió la AGPLv3 y declaró que Elasticsearch vuelve a ser código abierto.
Las marchas atrás son la pista. Dos veces ya, un proyecto relicenciado ha restaurado una licencia abierta después de que su bifurcación encontrara dinero institucional. Ninguna de las dos empresas describe la secuencia como una rendición, y el vínculo causal es una lectura de esta redacción, no algo que conste en ningún informe. Pero si las bifurcaciones financiadas no estuvieran funcionando como palanca, cuesta explicar para qué sirvieron esas marchas atrás.
¿De dónde sale realmente el dinero del código abierto ahora?
La respuesta clásica sigue cubriendo la mayor parte: proveedores que emplean a mantenedores y fundaciones que agrupan cuotas corporativas, ambas cosas premiando en general la relevancia comercial. El dinero nuevo no es una sola cosa. Al menos tres motivaciones distintas firman cheques hoy, y quieren mundos distintos.
Primero, el dinero de consorcio defensivo: empresas que financian una bifurcación porque sus propios productos dependen de condiciones que el original abandonó. Eso es exactamente la lista de patrocinadores de Valkey, y los compromisos de ingeniería a cinco años de OpenTofu. Aquí no hace falta inferir nada: los propios anuncios de las fundaciones exponen el motivo sin rodeos. Los financiadores están protegiendo su suministro.
Segundo, los programas estatales de soberanía. La Sovereign Tech Agency alemana, financiada a través del ministerio federal de Economía, paga el mantenimiento de componentes que casi nadie más financiaría. Su cartera de inversión publicada recogía, a principios de 2025, más de 23 millones de euros comprometidos en más de 60 tecnologías de base desde que empezó a financiar a finales de 2022, curl y WireGuard entre ellas, explícitamente en nombre de la soberanía digital europea. Es una categoría de financiador que no existía hace cinco años y que ahora declara gasto de ocho cifras. Para una economía como la española, integrada en ese mismo debate de soberanía digital europea, la pregunta ya no es teórica.
Tercero, el mecenazgo por valores, más antiguo que los otros dos y en general más pequeño. Devuan mantiene una bifurcación de Debian sin systemd desde que el comité técnico de Debian adoptó systemd en 2014, sostenida por las donaciones que solicita precisamente para preservar esa independencia. XLibre bifurcó el servidor gráfico X.Org en junio de 2025, presentándose ante voluntarios y mecenas como refugio frente a la gobernanza previa. Y las GNU coreutils, con licencia GPL y tuteladas por el proyecto GNU desde principios de los noventa, compiten hoy con uutils, una reescritura en Rust con licencia MIT iniciada en 2013 y liderada actualmente por Sylvestre Ledru, que Ubuntu 25.10 incorporó por defecto el pasado octubre. Si quienes pagan estos proyectos están comprando disidencia de gobernanza o simplemente el software que prefieren, no existe ninguna encuesta a donantes que lo confirme; sus propios llamamientos apelan a principios, y esta redacción lee el dinero en consecuencia: como inferencia, no como hecho probado.
Fíjate en lo que estas tres categorías no comparten: un futuro preferido. El dinero de consorcio quiere continuidad de condiciones. El dinero de soberanía quiere menos componentes compartidos, pero mejor mantenidos. El mecenazgo existe para mantener viva la disidencia. Tiran en direcciones incompatibles, cada uno dispuesto a financiar su dirección indefinidamente, y hablar de «la financiación del open source» como si fuera un único flujo es exactamente lo que oculta el riesgo.
¿Por qué los proyectos relicenciados siguen bifurcándose?
Porque las bifurcaciones ya no pasan hambre. Cuando el dinero seguía al mérito comercial, el bando perdedor de un cisma solía carecer de recursos para persistir, así que los conflictos se resolvían solos. Ahora una bifurcación creíble puede encontrar un mecenas cuyo único interés es que esa bifurcación exista, sea ese mecenas un hiperescalador protegiendo un servicio gestionado o una base de donantes pagando por independencia. Devuan lleva más de una década demostrando la durabilidad del mecenazgo pequeño; Valkey demostró la velocidad del mecenazgo grande en dos semanas. La viabilidad de una bifurcación solía ser una cuestión de capacidad técnica. A la luz de estos casos, se está convirtiendo en una cuestión de quién está dispuesto a pagar, y por qué.
Lo que genera una pregunta de continuidad que casi ningún checklist de compras contempla: ¿en qué rama financiada de este componente estamos realmente, y por decisión de quién? ¿Quién la financia y qué quiere a cambio? ¿Qué pasa si el mecenas principal se retira, o la licencia vuelve a cambiar? ¿Fluyen los parches de seguridad entre ramas, y con qué rapidez? ¿Y cuánto costaría migrar a la rama hermana si la nuestra pierde la partida?
¿Qué debería preguntar tu due diligence ahora?
Trata la rama financiada, no el nombre del proyecto, como unidad de análisis. Para cada componente crítico: ¿en qué rama estamos, y por decisión de quién? ¿Quién la financia y qué quiere? ¿Qué ocurre si el mecenas principal se marcha, o la licencia cambia otra vez? ¿Circulan los parches de seguridad entre ramas, y a qué velocidad? ¿Y cuánto costaría migrar a la rama hermana si la nuestra pierde la partida?
Nada de esto aparece en un inventario de software (SBOM), que registra lo que ejecutas pero no quién paga para que siga existiendo. Mapear esto es trabajo de dependencias poco vistoso: exactamente lo que una estrategia tecnológica deliberada existe para sacar a la luz antes de que se convierta en incidente, y algo que una revisión independiente detecta más rápido que un equipo interno que siempre dio por hecho que la capa base era problema de otro.
Los bienes comunes sobre los que está construido tu negocio siguen ahí. Simplemente ya no son una sola cosa, y quienes pagan por sus piezas ya no quieren el mismo futuro. Averigua qué futuro estás financiando por defecto. Luego decide si es el que quieres.
Preguntas frecuentes
¿Cómo sé quién financia un proyecto de código abierto del que depende mi empresa?
Empieza por la página de gobernanza del propio proyecto, su condición de miembro en fundaciones y cualquier lista de patrocinadores publicada, y después mira quién emplea a los mantenedores más activos, porque el empleo es la forma más silenciosa de financiación. Si esas respuestas son difíciles de encontrar, la propia opacidad ya debería figurar en tu mapa de riesgos.
¿Es arriesgado depender de una bifurcación de un proyecto de código abierto?
No por sí mismo. Una bifurcación con financiación sostenida, varios mantenedores activos y un proceso de seguridad que funciona puede ser más segura que un original abandonado. El riesgo real está en los periodos de transición, cuando los parches llegan a una rama y tardan en llegar a la otra, o no llegan. Evalúa cada rama por su historial operativo, no por en qué lado del debate se sitúa.
¿Debería mi empresa financiar el software de código abierto que utiliza?
Si el fallo de un componente pararía tu producto, pagar a sus mantenedores no es filantropía, es un seguro barato. Una pequeña parte de los ingresos destinada aguas arriba compra aviso temprano, influencia y buena voluntad. Eso sí, en el clima actual tu dinero también es un voto por un modelo de gobernanza, lo pretendas o no.
Relacionado
- Epic contra Google: la cláusula que cede el catálogo, no las comisiones, es la que cambia el mercado
- La memoria ha cambiado de rumbo: renegocia el contrato de suministro antes del próximo ciclo de renovación
- Cómo la IA empeora a los malos jefes: la máquina de la complacencia en el sillón de mando
- Digital Business
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.