Cómo ganan dinero las empresas de código abierto

Por Brian Tr · Actualizado el 2 de octubre de 2026

Una empresa de código abierto regala su producto principal y aun así tiene que pagar salarios. Suena a contradicción, y es la primera pregunta que se hacen todos los fundadores e inversionistas sobre el modelo. La respuesta es que el código rara vez es lo que se vende. Los clientes pagan por lo que rodea al código: alguien que lo ejecute, lo respalde, lo certifique, lo amplíe o asuma la responsabilidad legal por él.

Este artículo explica qué significa realmente "código abierto", las principales formas en que las empresas lo convierten en ingresos y la tensión que llevó a varias empresas conocidas a cambiar sus licencias entre 2021 y 2026. Es una referencia sobre el modelo de negocio, no asesoría legal, y no compara los precios vigentes de los proveedores. Para ver el conjunto más amplio de formas en que las startups ganan dinero, consulte los modelos de precios de SaaS.

Qué significa realmente "código abierto"

"Código abierto" no es un sinónimo vago de "gratis" ni de "el código es público". La Open Source Initiative (OSI) mantiene la Open Source Definition, una lista de diez criterios que debe cumplir una licencia. Tres importan sobre todo para los modelos de negocio:

• Redistribución libre. La licencia no puede impedir que nadie venda o regale el software.
• Obras derivadas. La licencia debe permitir modificaciones y obras derivadas.
• Sin discriminación contra ámbitos de actividad. La licencia no puede restringir a nadie el uso del programa en un ámbito específico, lo que en la práctica incluye ejecutarlo con fines comerciales.

Ese último criterio es donde los modelos de negocio chocan con la definición. Una licencia que dice "cualquiera puede usar esto, excepto para venderlo como un servicio alojado de la competencia" está restringiendo un ámbito de actividad. Puede ser una decisión comercial perfectamente razonable, pero según la lectura de la OSI no es código abierto. La OSI dijo exactamente esto sobre la Server Side Public License (SSPL) en una declaración de enero de 2021, y calificó de engaño la práctica de describir ese software como código abierto.

Así que en realidad hay dos bandos:

El resto de este artículo mantiene separados ambos conceptos. La distinción importa para los clientes (¿qué se les permite hacer?), para los colaboradores (¿mi trabajo seguirá abierto?) y para los fundadores (¿qué puedo prometer?).

La paradoja de regalar el núcleo

Si cualquiera puede descargar, modificar y ejecutar el producto gratis, ¿por qué alguien pagaría? Las empresas de código abierto responden de una de cuatro maneras:

1. Reducir la carga. Ejecutar bien el software es difícil. Los clientes pagan para que otro lo opere.
2. Reducir el riesgo. Las organizaciones grandes quieren un proveedor al que llamar, un equipo de respuesta de seguridad y una garantía legal.
3. Añadir lo que le falta a la versión gratuita. Las funciones que importan sobre todo a los equipos grandes (controles de acceso, registros de auditoría, inicio de sesión único) se venden por separado.
4. Proteger el derecho a cobrar. Algunas empresas mantienen el código abierto a la lectura pero limitan quién puede revenderlo.

Regalar el núcleo también funciona como distribución. Los desarrolladores adoptan lo que pueden probar sin un proceso de compras, y la empresa que gana esa adopción tiene un canal de ventas entrante. Es una lógica cercana al crecimiento liderado por el producto y a los modelos de negocio freemium, con una diferencia: un usuario gratuito de software de código abierto también puede bifurcar el código (fork), alojarlo por su cuenta y no convertirse nunca en cliente.

Los principales modelos de monetización

1. Soporte y suscripciones (el modelo Red Hat)

El modelo más antiguo vende garantías en torno a un software gratuito. Red Hat es el ejemplo estándar. El anuncio de octubre de 2018 de IBM sobre su acuerdo para adquirir Red Hat a $190 por acción, con un valor empresarial de unos $34 mil millones, describía a la empresa como un proveedor líder de software empresarial de código abierto, que incluye Linux, nube híbrida, contenedores y tecnologías de Kubernetes.

¿Por qué paga un cliente de Red Hat? Sus propias preguntas frecuentes sobre suscripciones enumeran parches, correcciones de errores, actualizaciones y mejoras, soporte técnico con disponibilidad 24/7 y certificaciones de hardware, software y proveedores de nube. También señalan que un cliente que deja vencer una suscripción pierde las erratas de seguridad, las correcciones de errores y el soporte técnico. En otras palabras, el producto es una versión mantenida, certificada y con soporte, no el código fuente en sí.

Dónde funciona: software de infraestructura que las grandes organizaciones ejecutan en producción y no pueden permitirse que falle. Dónde le cuesta: las ventas son lentas y pesadas, y el modelo escala con personas y confianza, no con descargas.

2. Open core

En una empresa open core, el producto base es de código abierto y un conjunto de funciones adicionales es propietario y de pago. Los extras suelen ser lo que piden las organizaciones grandes: seguridad avanzada, gobernanza, herramientas de escalabilidad, integraciones oficiales y soporte dedicado.

La pregunta estratégica es dónde trazar la línea. Si pone muy poco en la versión gratuita, la comunidad no tiene motivos para adoptarla. Si pone demasiado, nadie tiene motivos para pagar. Los fundadores suelen aplicar una prueba simple: las funciones que ayudan a un desarrollador individual siguen siendo gratuitas, y las que ayudan a una organización a coordinarse (permisos, cumplimiento, administración) son de pago.

El riesgo es la confianza. Cuando una empresa mueve una función del nivel gratuito al de pago, la comunidad puede interpretarlo como una traición, y puede seguir un fork.

3. Nube gestionada (servicio alojado)

La mayor parte de los ingresos modernos del código abierto proviene de ejecutar el software para los clientes. La empresa lo aloja, se encarga de las actualizaciones, las copias de seguridad y el escalado, y cobra por uso o capacidad. Es el modelo SaaS aplicado a un producto de código abierto, y la mecánica de precios se trata en el precio basado en el uso.

MongoDB muestra hasta dónde puede llegar esto. En su comunicado de resultados del año fiscal 2026 (año fiscal cerrado el 31 de enero de 2026), MongoDB reportó ingresos totales de $2.46 mil millones, y su servicio en la nube Atlas representó cerca de $1.81 mil millones de ese total, alrededor de 73%. Es la cifra del año fiscal de una empresa, no un parámetro del sector, y la base de datos principal de MongoDB tiene código disponible en lugar de ser de código abierto (más sobre esto abajo).

Dónde funciona: productos que son penosos de operar, de modo que la comodidad vale la pena pagarla. Dónde le cuesta: cualquiera con una cuenta en la nube puede ofrecer el mismo servicio, incluidos los mayores proveedores de nube. Esa es la raíz de las disputas de licencias que se describen más abajo.

4. Doble licencia

Con la doble licencia, el mismo código se ofrece bajo dos licencias. Una es gratuita, normalmente copyleft, que exige que quien construya sobre ella comparta su propio código fuente bajo los mismos términos. La otra es una licencia comercial de pago para las empresas que quieren integrar el software en un producto cerrado sin esa obligación.

Funciona mejor para bibliotecas y componentes que otras empresas integran en sus propios productos. Funciona mal para aplicaciones de usuario final, donde nadie necesita una excepción a los términos copyleft. Además, suele exigir que la empresa tenga los derechos para volver a licenciar, y ahí entran los acuerdos de colaboradores (vea abajo).

5. Código disponible y cambios de licencia

Un grupo creciente de empresas publica ahora su código fuente con licencias que restringen el uso comercial, normalmente para impedir que los competidores revendan el producto como servicio alojado. Ejemplos comunes son la SSPL, la Business Source License y las licencias de estilo fair-code. Estas licencias permiten a los clientes leer, ejecutar y modificar el código, y le dejan al proveedor el derecho exclusivo de venderlo como servicio.

Algunas de estas licencias también se convierten en una licencia totalmente abierta tras un plazo fijo. Es una forma de prometer apertura a futuro mientras se protege una ventaja inicial en el presente.

6. Donaciones, patrocinios y fundaciones

No todo proyecto de código abierto es una empresa. Muchos los mantienen voluntarios, los financian patrocinadores o los alojan fundaciones. La Apache Software Foundation, por ejemplo, pide a los colaboradores importantes que firmen un acuerdo de licencia de colaborador individual para que la fundación pueda defender el proyecto si surge una disputa legal sobre el software. Las fundaciones dan a los proyectos una gobernanza neutral y cobertura legal, pero no pagan a los fundadores. A menudo surgen empresas comerciales en torno a los proyectos de fundaciones y venden soporte o alojamiento, lo que alimenta los modelos del 1 al 3.

Comparación de los modelos

La mayoría de las empresas reales combinan varios. Un producto típico tiene un open core gratuito, una versión alojada, un nivel enterprise y una opción de soporte.

El problema de los hiperescaladores y la ola de cambios de licencia de 2021 a 2026

La nube gestionada es el modelo más rentable, y también el más fácil de copiar para un competidor más grande. Si la licencia lo permite, un proveedor de nube puede alojar una base de datos o herramienta de código abierto, cobrar por ella y aportar poco a cambio. Los proveedores de código abierto lo llaman "strip-mining" (saqueo).

Varias empresas respondieron cambiando sus licencias. Cada uno de los anuncios siguientes proviene de la propia empresa.

Al leer estos anuncios en conjunto, destacan varias cosas.

Los motivos son coherentes. Elastic dijo que el cambio buscaba impedir que los proveedores ofrecieran su software como servicio sin aportar a cambio. HashiCorp sostuvo que algunos proveedores se benefician del trabajo de código abierto sin contribuir. Redis dijo que la mayoría de sus ventas comerciales se canalizaban a través de los mayores proveedores de servicios en la nube.

La honestidad sobre la etiqueta importa. Redis declaró sin rodeos que sus nuevas licencias no cumplen la definición de la OSI y que llamaría a la versión gratuita "Community Edition" en lugar de código abierto. La OSI ha adoptado la misma postura sobre la SSPL.

Hay marchas atrás. Elastic y Redis añadieron después la AGPL, aprobada por la OSI, como opción. Redis dijo que su cambio anterior había dañado su relación con la comunidad, y Elastic dijo que su decisión había obedecido a preocupaciones sobre las prácticas de Amazon, pero que la situación había cambiado. Para un fundador, la lección no es que una licencia sea la correcta. Es que un cambio de licencia es una decisión de negocio con un costo comunitario que puede durar años.

Algunas licencias incluyen un reloj. Directus dice que cada versión de su software pasa a ser totalmente de código abierto bajo GPLv3 tras cuatro años, y que, según sus umbrales, las organizaciones con menos de $5 millones de ingresos anuales y 50 empleados pueden usarlo gratis. Una licencia con plazo busca proteger al proveedor ahora y cumplir después la promesa de código abierto.

Comunidad frente a ingresos: la tensión central

Las empresas comerciales de código abierto conviven con un conflicto permanente. La comunidad quiere software estable, gratuito y con licencia permisiva. Los inversionistas y los empleados quieren ingresos que crezcan. Cada decisión de monetización inclina la balanza.

Algunos puntos de presión prácticos:

• Limitar funciones. Mover una función existente detrás de un muro de pago rompe una promesa tácita a usuarios y colaboradores.
• Gobernanza. Si una sola empresa controla la hoja de ruta, los colaboradores externos pueden alejarse. Una fundación da control neutral, pero le quita algo a la empresa.
• Forks. Si un cambio de licencia enoja a suficiente parte de la comunidad, puede aparecer un fork bajo una licencia permisiva. El fork conserva el código anterior y puede atraer a los proveedores de nube que la empresa intentaba bloquear.
• Marca registrada. Aunque el código se pueda copiar libremente, el nombre normalmente no. Redis, por ejemplo, limita ahora el uso de "Redis" en los nombres de otros productos conforme a su política de marcas.

Acuerdos de licencia de colaborador

Un acuerdo de licencia de colaborador (CLA) es un documento en el que un colaborador otorga a un proyecto los derechos que necesita para usar su contribución. Las fundaciones los usan por claridad legal, como muestra la justificación del ICLA de la Apache Software Foundation.

Para una empresa, un CLA tiene un segundo propósito: hace posible cambiar la licencia más adelante o vender el código bajo una licencia comercial, porque la empresa tiene los derechos que necesita. Redis, por ejemplo, dijo que exige a los colaboradores aceptar su CLA antes de considerar sus contribuciones.

A veces los colaboradores ven los CLA como una calle de un solo sentido. Una empresa que quiera conservar la buena voluntad de la comunidad debe ser clara sobre por qué exige uno y qué promete a cambio.

Qué significa esto para una startup

Si está considerando un modelo de negocio de código abierto, conviene resolver temprano algunas preguntas.

1. ¿Por qué pagan los clientes si el código es gratis? Por comodidad, reducción de riesgo, funciones o permiso. Si no puede nombrarlo, todavía no tiene un modelo de negocio.
2. ¿Quién podría revender su producto? Si la respuesta es "cualquier proveedor de nube", elija su licencia pensando en eso desde el principio, porque cambiarla después es costoso.
3. ¿Cómo se ganará la confianza de la comunidad? Decida qué nunca pasará detrás de un muro de pago, y déjelo por escrito.
4. ¿Entiende la economía? Atender y dar soporte a los usuarios gratuitos cuesta dinero. Siga los unit economics del segmento de pago, no el total de descargas.
5. ¿Hay un foso más allá del código? La marca, la experiencia en alojamiento, el ecosistema y los datos pueden importar más que la licencia. El artículo sobre el foso económico trata esta idea en detalle, y los efectos de red pueden aplicar cuando una gran comunidad de desarrolladores hace más valioso el producto.

Los equipos en etapa inicial, en particular, deberían comparar este modelo con otras opciones, como los modelos de negocio de plataforma, antes de comprometerse.

Las prácticas en torno a las licencias y los acuerdos de colaboradores varían según el país y el inversionista, así que los fundadores deben buscar asesoría legal para su propia situación. No hemos encontrado una fuente comparativa fiable sobre las prácticas de negocio de código abierto en el Sudeste Asiático en particular.

Datos clave

• La Open Source Definition de la OSI tiene diez criterios y se modificó por última vez en 2007. Uno de ellos prohíbe las restricciones sobre ámbitos de actividad.
• La OSI declaró en enero de 2021 que la SSPL no es una licencia de código abierto.
• IBM anunció en octubre de 2018 que adquiriría Red Hat a $190 por acción, unos $34 mil millones en valor empresarial.
• Las preguntas frecuentes sobre suscripciones de Red Hat enumeran parches, actualizaciones, soporte y certificaciones como lo que ofrece una suscripción.
• El servicio Atlas de MongoDB generó cerca de 73% de sus $2.46 mil millones de ingresos en el año fiscal 2026.
• Elastic pasó a la SSPL en enero de 2021 y añadió la AGPL en agosto de 2024.
• HashiCorp adoptó la BSL 1.1 en agosto de 2023.
• Redis pasó a código disponible en marzo de 2024 y añadió la AGPLv3 en mayo de 2025.
• NocoDB y Directus pasaron ambos a licencias de código disponible en 2026.
• Una licencia de código disponible no es código abierto según la OSI, aunque el código sea público.

Lecturas relacionadas

• Modelos de negocio freemium
• Crecimiento liderado por el producto
• Foso económico
• Modelos de negocio de las startups de hardware
• Modelos de precios de SaaS
• Modelo de negocio de plataforma