- A las empresas comerciales de código abierto les cuesta sostenerse solo con sustitutos de productos de pago existentes a los que se les pone una licencia MIT; necesitan una razón clara para ser de código abierto o un producto superior.
- A diferencia de los proyectos sin fines de lucro o basados en patrocinio, un negocio de código abierto necesita ingresos para contratar, crecer y continuar el desarrollo.
- Las startups suelen inclinarse por un plan gratuito o una versión open source, y las grandes empresas tratan el costo de SaaS como una partida presupuestaria, por lo que es difícil cambiar una decisión de compra solo por ser más barato.
- El código abierto se fortalece cuando el código cerrado genera problemas de transparencia que afectan la confianza del cliente, y cuando existen problemas de extensibilidad que requieren muchas integraciones y plugins.
- Los casos de PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte y Elastic muestran que el código abierto puede convertirse en un mejor producto gracias a la auditabilidad, el self-hosting y las contribuciones de la comunidad.
Los sustitutos open source por sí solos no bastan
- Descripciones como “la versión open source de Stripe Billing” o “la versión open source de Chargebee” ayudan a entender rápidamente un producto, pero son una base débil para sostener un negocio.
- A las herramientas comerciales de código abierto les resulta difícil depender solo de posicionarse como una alternativa open source a productos de pago que ya tuvieron éxito.
- No basta con que un desarrollador imite un producto y le ponga una licencia MIT, y el hecho de ser open source tampoco garantiza el éxito.
- La discusión se centra en proyectos de código abierto comercial que compiten con soluciones de pago populares.
- Productos impulsados por la comunidad o financiados por patrocinio, como React, TypeORM o VSCode, tienen otras prioridades.
- React cuenta con el apoyo de una organización más grande como Meta, y TypeORM financia su desarrollo con donaciones.
- Estos proyectos, en esencia, no son empresas.
- Para que una empresa open source tenga éxito, debe haber una razón clara para que sea de código abierto o debe superar a sus competidores.
El criterio de éxito no es el uso, sino los ingresos
- Salvo en proyectos sin fines de lucro que reciben donaciones o apoyo de una empresa matriz, el criterio final de un negocio open source común es el ingreso.
- Las empresas con fines de lucro financian la contratación, el crecimiento, la sostenibilidad y el desarrollo continuo a través de los ingresos.
- Las empresas que crean software gratuito y aun así generan ingresos son casos positivos; una empresa open source no busca explotar en exceso a sus clientes, sino seguir operando.
- MongoDB creció hasta convertirse en una gran empresa de bases de datos con más de 4,600 empleados.
- Después cambió a la licencia SSPL para limitar que los proveedores cloud desplegaran el servicio sin contribuir al proyecto.
- SSPL no cuenta con aprobación de la OSI, pero en la práctica se describe como algo muy cercano al open source.
- Al medir el éxito a largo plazo, hay que distinguir entre adopción e ingresos.
- Un proyecto puede tener una alta adopción y aun así desaparecer si no genera ingresos.
- Se considera que hay muy poca evidencia que respalde la expectativa de que la comunidad tomará el relevo del proyecto.
Ser más barato no es una ventaja sostenible
- Una estrategia orientada solo a clientes sensibles al precio se parece mucho a una batalla perdida.
- En un caso hipotético de crear una versión open source de Amplitude, podría argumentarse que Amplitude es caro, que resulta pesado para una startup y que incluso una gran empresa podría ahorrar dinero.
- Sin embargo, como las startups son sensibles al precio, es más probable que elijan una versión open source o un plan gratuito, y eso no suele ser suficiente para sostener el negocio.
- La estrategia de crear una alternativa más barata suele parecerse más a un boleto hacia una futura quiebra.
- Las grandes empresas tampoco suelen preocuparse por quebrar a causa del costo de Amplitude.
- En una negociación contractual pueden evaluar el precio dentro del presupuesto.
- Pero la mayoría de los SaaS terminan siendo solo una línea más de gasto.
- Lo más importante es si es una buena solución, si será sostenible a largo plazo y si es fácil de administrar.
- Desplegar una solución open source puede ser difícil de gestionar.
- La excepción es cuando el costo de una solución representa una parte muy grande del presupuesto total.
- Ahí entran las empresas que tuvieron que reducir Oracle porque el costo se disparó por el uso de la base de datos.
- Pero la mayoría de las soluciones open source no reemplazan una de las tres partidas de gasto más grandes, por lo que el precio difícilmente se convierte en el criterio principal de decisión.
Primera forma en que gana el open source: transparencia
- Un caso típico en que una solución open source se vuelve poderosa es cuando el código cerrado genera un problema de transparencia que crea desconfianza entre cliente y proveedor.
- Como alternativa open source a Amplitude está PostHog.
- PostHog ha crecido con clientes como Airbus, DHL y Staples.
- Combina varias soluciones SaaS de producto y las ofrece como open source.
- Incluso tiene abierto el código fuente de su blog y su roadmap.
- PostHog se posiciona como un mejor producto que sus competidores porque las herramientas de analítica manejan datos sensibles de clientes, como direcciones IP, nombres y grabaciones de sesiones.
- En un entorno con más regulaciones de datos como GDPR y CCPA, puede ser una carga dejar que un tercero almacene este tipo de datos.
- PostHog ofrece dos opciones.
- Hacer self-hosting de la solución de analítica.
- Contratar a PostHog como tercero, pero con transparencia sobre cómo se almacenan los datos y cómo migrar más adelante a self-hosting.
- Aunque el método más favorable para la privacidad sea el self-hosting, muchas empresas pueden seguir eligiendo el modelo hospedado.
- Aun así, pueden ver línea por línea cómo funciona el software.
- También pueden conocer el proceso para migrar al modelo self-hosted cuando lo necesiten.
- Las empresas open source no ganan eliminando la necesidad de un tercero, sino permitiendo auditar públicamente cómo funciona el producto y así generar confianza.
Casos de productos donde la transparencia importa
- Medplum es una plataforma de historia clínica electrónica open source que compite con proveedores cerrados tradicionales.
- Al ser open source, los usuarios pueden verificar exactamente qué soporta y qué no soporta la plataforma.
- SuperTokens es una alternativa open source a soluciones de autenticación como Auth0.
- El inicio de sesión maneja datos sensibles como nombre, correo electrónico y contraseña.
- El hecho de ser open source ayuda a generar más confianza.
- TableFlow es una alternativa open source a plataformas de importación de CSV como Flatfile.
- Lo importante es que los datos importados pueden ser sensibles.
- Minio es una alternativa open source al almacenamiento AWS S3.
- En S3 puede almacenarse PII de clientes mediante capturas de pantalla o archivos JSON estructurados.
- Minio puede ser una alternativa para empresas que se preocupan por quién puede acceder a los datos de los usuarios.
- AWS afirma que sus empleados no acceden directamente a los datos de los clientes, pero en el código cerrado esa afirmación sigue siendo una cuestión de confianza.
- Lago también maneja información de facturación y de uso del producto, y considera que, por la sensibilidad de esos datos, puede generar mejor confianza del usuario mediante open source.
Segunda forma en que gana el open source: extensibilidad
- Una gran ventaja del open source es que abre a la comunidad el desarrollo de funciones de nicho.
- El producto principal suele mantenerse por un equipo central de ingeniería, pero los desarrolladores de la comunidad pueden crear integraciones o plugins, que a veces terminan fusionándose en la rama principal.
- Las soluciones cerradas dependen de su propio equipo de ingeniería, por lo que les cuesta escalar de la misma manera.
- Esto es especialmente favorable para empresas open source que construyen sistemas que deben conectarse con muchas librerías, frameworks y aplicaciones.
- Airbyte creció mucho como plataforma ELT open source gracias a los connectors agregados por la comunidad.
- Elastic también fue originalmente una empresa más grande basada en open source y ofrece numerosas integraciones de datos.
- SuperTokens hizo de la extensibilidad una propuesta de valor central, y los miembros de la comunidad pueden crear integraciones con proveedores de autenticación poco comunes, lo que beneficia a todos.
Tercera forma en que gana el open source: un mejor producto
- La transparencia y la extensibilidad contribuyen a que el código abierto comercial pueda convertirse, a largo plazo, en un mejor producto.
- Los proyectos open source pueden aprovechar el feedback y la ayuda de la comunidad para evolucionar más rápido que las soluciones cerradas.
- PostHog comenzó como alternativa a Amplitude y FullStory, pero luego creció hasta convertirse en una solución integral grande que también compite con LaunchDarkly y Pendo.
- PostHog levantó una inversión Series B de 15 millones de dólares.
- Ese crecimiento ocurrió en los últimos años, y PostHog considera a la comunidad como una de las razones clave.
- Los proyectos open source no se limitan al código abierto comercial y durante décadas han sido un motor importante de mejora de productos.
- Algunos tipos de software pueden seguir siendo cerrados por la naturaleza de sus efectos de red.
- Pero en áreas donde la transparencia y la extensibilidad son un problema, un competidor open source que llega después sí puede convertirse en una amenaza real.
3 comentarios
Lo encontré por casualidad mientras buscaba, y me hace preguntarme cuándo la IA corregirá de una vez este tipo de traducciones literales del inglés ("por ser barato").
Este es el resultado de ejecutar Claude 4.5 Sonnet hoy (2026-01-12)
"El código abierto no gana por ser más barato"
Prompt
El código abierto no gana simplemente por ser barato.
Los factores de éxito del código abierto no están en su bajo costo, sino en otra parte.
El código abierto no se impone por su bajo precio.
Opiniones de Hacker News
Aquí la palabra ganancia (profit) suena rara y ambigua.
He llevado proyectos de software libre y de código abierto durante casi 24 años, y durante unos 17 de esos años también generaron ingresos, pero no hubo “ganancia”, solo ingresos (revenue).
Normalmente, como lo vería una empresa o un contador, la ganancia es el dinero que queda después de restar la remuneración y los costos de las personas que participan en el proyecto.
Los únicos proyectos de código abierto que necesitan ganancia en ese sentido son los que recibieron inversión de capital de inversionistas que esperan un “retorno”; existen proyectos así, pero no son la mayoría.
Además, como suele pasar con los textos que llegan a HN, en general está demasiado sesgado hacia web/SaaS. Aunque cueste creerlo, también hay otros tipos de proyectos de código abierto.
En ese contexto, la ganancia es lo que queda después de cobrar ingresos y pagar costos, y esos costos incluyen cosas como salarios fijos, contratos laborales y recibos de nómina.
Un negocio puede usar sus ganancias de muchas maneras. Puede acumularlas como reserva de efectivo para poder cubrir costos en meses de bajos ingresos, comprar activos como hardware nuevo o permitir nuevas contrataciones. Aunque es menos común de lo que uno pensaría, también puede pagarlas como dividendos a los dueños.
Sin muchos detalles sobre tu situación solo se puede especular, pero si lo operas solo y el proyecto es pequeño, sin necesidad ni intención de aumentar personal, los ingresos en la práctica se parecen más a ingresos personales. Como algunos meses cobras más y otros menos, en este contexto lo correcto es verlo como “ingresos” y no como “ganancia”.
Esto es todavía más cierto si se trata de software con casi ningún otro gasto indirecto y donde llevar el seguimiento de costos para fines fiscales no tiene mucho sentido; incluso puede que ni lleves libros contables formales. Si esa es tu situación, entiendo por qué el texto no te resulta identificable. El texto trata de una situación bastante distinta.
Si no hay inversionistas puros exigiendo retornos continuos, la presión baja mucho y es más fácil hacer lo que conviene al proyecto.
Pero en áreas de producto donde compites con empresas ambiciosas, el crecimiento también es necesario y probablemente razonable.
Dejar ganancia para prepararse ante recesiones, oportunidades o grandes gastos no es simplemente algo razonable. Cuantas más personas y clientes participan, más razones hay para no quemar todos los ingresos que entran.
En empresas grandes, de hecho, a menudo esos dos son números no relacionados entre sí, y cada uno se define según a quién se comunica y qué reglas aplican a esa comunicación.
También puede existir algo como “ganancia de gestión”, un término general para métricas no estandarizadas ni reguladas. Por ejemplo, aunque una empresa haya dejado la contabilidad de caja para fines fiscales y de reporte a inversionistas, al equipo directivo existente le puede seguir resultando útil monitorear la definición anterior de ganancia. Puede ser por costumbre, porque muestra bien el flujo de caja o porque resulta útil de otra manera.
Este es uno de esos problemas posmodernos. La SEC, el IRS y el ejecutivo del banco no aceptan expresiones como “ganancia SEC” y exigen la ganancia “real”. Es como un político local que le pregunta ingenuamente a un hospital cuánto costó “de verdad” una obra a la constructora.
En todo caso, el autor también usa los términos desde su propia perspectiva, como la SEC o el IRS. Cuando dice “el código abierto no gana por ser más barato”, “código abierto” se refiere a negocios de código abierto con modelos como MongoDB. Por eso da por sentados inversionistas y objetivos de crecimiento.
El texto mismo lo dejó claro, así que no hay mucha necesidad de entrar en gruñidos semánticos.
El problema de este modelo de negocio es que crea tensión entre la versión OSS y la versión de pago.
Uno quiere que la versión OSS sea buena, pero no tan buena como para que nadie sienta la necesidad de pagar por SaaS, consultoría, etc.
Esa tensión parece terminar llevando a que falten funciones claramente necesarias, o a que las funciones y el conocimiento necesarios para operar a escala se oculten como código cerrado para monetización de la empresa patrocinadora.
Si el producto tiene carácter de infraestructura, ya quedó instalado el patrón de cambiar a una licencia que solo permite ver, pero no tocar, para que los grandes proveedores de nube no se lo coman como servicio de un clic, como en los casos de Elastic y Hashicorp.
No quiero decir que el artículo esté equivocado, pero me gustaría que no se fingiera que el OSS con patrocinio comercial es un kumbaya de ganar-ganar para todos. En realidad, se parece más a una estructura en la que una startup lo usa como growth hacking para generar confianza y, cuando llega el momento de generar ingresos, termina apretando de alguna forma a la comunidad que ayudó a su crecimiento.
Mantuve un módulo pequeño y durante años recibí muchas solicitudes de funcionalidades y de soporte. Hasta que gane lo suficiente para pagar la renta, no siento ni un poco de culpa por cobrar por ese trabajo.
Incluso cobro por apretar el botón de merge de un Pull Request si eso me toma aunque sea 1 segundo de mi tiempo. Al código le dediqué meses, años, y lo publiqué gratis para el mundo.
Si se necesitan funciones adicionales o mi tiempo, hay que pagar.
Que muchas empresas no puedan hacerlo no significa que este modelo de negocio no funcione; más bien significa que hacerlo bien es muy difícil.
Aun así, si asumimos que la mayoría de la gente en general es buena, vale la pena considerar que estas empresas o personas tal vez encararon mal el mercado. Puede ser incompetencia más que mala fe.
Si desde el primer día se deja claro y de forma transparente qué será gratis para siempre y qué terminará siendo de pago, no lo vería como una traición a la comunidad.
Claro, bajo la premisa de que se respete el roadmap y se ajuste según el feedback y las contribuciones.
El soporte de pago o las funciones ampliadas pueden quedar en el ámbito comercial, que de todos modos es donde el software genera la mayor parte del dinero.
No servirá para todos los casos de uso, pero tampoco tiene por qué hacerlo. La mayor parte de la computación debería ser personal.
Hay una frase que dice que “MinIO es una buena alternativa para las empresas a las que les importa quién accede a los datos de sus usuarios”, pero ¿no podría una empresa afirmar que aloja software open source y en realidad usar software interno de código cerrado que imita los mismos endpoints de API?
Entonces seguiría haciendo falta el mismo tipo de confianza que con AWS.
No hay que asumir que autoalojar significa tener alta conciencia de seguridad. En la mayoría de las empresas, la TI on-premise se trata como el HVAC o la instalación eléctrica, solo que más molesta.
Cualquiera con ropa de trabajo podría engañar a recepción para que le entregue la llave de la sala de servidores.
Solo significa que el proveedor comparte el código fuente que dice estar ejecutando detrás de su servicio.
Incluso si ese código coincide exactamente, es poco probable que sea el único código que corre detrás del servicio “oficial”. Y el usuario tampoco puede compilarlo por su cuenta y desplegarlo en los servidores de ellos.
El open source solo tiene verdadero significado cuando se autoaloja; de lo contrario, en la práctica no se diferencia del software propietario. Todo depende de la confianza en el proveedor y, si es posible, del contrato.
Por ejemplo, si el contrato dice que los datos entran y salen a través de este código open source y no van a ningún otro lado, y enumera los procedimientos para garantizarlo, pero todo eso es una mentira descarada, se convierte en un problema grave de forma clara y ejecutable.
También sería difícil ocultárselo a los empleados internos, y la gente entra y sale. Si no fuera cierto, es poco probable que hicieran esa afirmación.
El autor aclara que se refiere específicamente a soluciones open source que compiten con productos pagos.
Personalmente, creo que en este contexto todavía no está claro si el open source “gana”.
En los últimos 10 años aumentó mucho la cantidad de productos open source, y en los últimos 5 años aproximadamente también vimos que muchos de ellos se alejaron del open source. MongoDB, el stack de Hashicorp, Elastic, Red Hat, MinIO, etc., son ejemplos de eso.
No quedan muchos productos verdaderamente open source y comercialmente competitivos, y muchos de ellos todavía están tratando de demostrar que este es un modelo de negocio viable.
Hace unas semanas di una charla sobre este tema en un evento interno de la empresa, y en unas semanas volveré a presentarla en GoWest.
La premisa central es que una licencia open source, literalmente, otorga libertad, pero no ofrece otras cosas por las que una empresa estaría dispuesta a pagar. Una licencia propietaria ofrece lo que una empresa necesita, pero sacrifica la libertad.
Creo que existe un tercer modelo que funciona en un punto medio sin comprometer la libertad ni la confiabilidad. Manteniéndose open source y cubriendo con patrocinio las brechas que las empresas necesitan, puede ser posible para algunos proyectos.
Ahora estamos rediseñando el sitio web de Caddy en torno a este mensaje, y espero que funcione bien.
Cuando dices que MinIO “se alejó del open source”, ¿te refieres a eso?
El título es tonto. Por supuesto que el open source gana por ser más barato.
Lo que el autor quiere decir es que el negocio open source no gana por ser más barato.
Una base de código open source siempre gana por ser más barata. Nadie paga por un algoritmo de compresión, un daemon de hora de red o un transcodificador de medios. El open source eliminó por completo esos mercados.
Pero molesta que el título sea literalmente incorrecto por una sola palabra.
Volví a leer los párrafos anteriores pensando que quizá me había perdido algo.
Desde la perspectiva de un ingeniero que influye en la adopción de tecnología, el open source gana por ser comprensible.
Si mis colegas y yo podemos ver el código fuente, podemos evaluar si el producto será capaz de hacer lo que afirma.
Si durante el uso encontramos un bug o un caso de uso inesperado, al menos podemos investigar una solución y sugerirla en un reporte de bug, o incluso abrir un PR.
Eso permite crear un workaround rápido y, normalmente, también reportar el bug.
A las empresas no les importa tanto el código en sí. E incluso si les importa, una cláusula de continuidad del negocio puede reducir la mayoría de las preocupaciones sobre el software cerrado.
Al final, ¿cuántas financieras se pasaron de Excel a OpenOffice Calc?
La estrategia de entrada al mercado de AWS dependía de atraer a startups y desarrolladores individuales con servicios de bajo costo y pago por uso, y eso encajó muy bien. Airbnb, Stripe, Twitch, etc., crecieron junto con AWS al convertirse en grandes empresas.
No hay muchas cosas que puedan competir con lo barato o gratuito. Después puedes subir al mercado de mayor valor. Pregúntenles a ARM e Intel.
Para las startups de herramientas de desarrollo, el open source prácticamente se volvió la estrategia de entrada al mercado por defecto. Aunque, como señala correctamente el artículo, no es un modelo de negocio.
Así que, a menos que seas tan excelente como Snowflake y puedas enfrentarte también al campo libre y open source como Databricks, conviene más el modelo open core.
Si pueden compilarlo directamente, lo prefieren mucho más.
Si estás montando Postgres tú mismo en un servidor físico, a los inversionistas no les importará, o harán preguntas difíciles sobre cuánto tiempo desperdiciaste. En ese caso necesitas una respuesta bastante buena o un inversionista que empatice.
Me sorprende que no mencionen el vendor lock-in. Es un punto de venta claro del open source.
Por supuesto, varía según la organización y la persona, y hay muchos que no se preocupan por quedar atados si confían en la empresa, pero nunca es cero.
Cuando trabajaba en Red Hat como consultor de OpenShift, conocí a muchos ejecutivos preocupados por el vendor lock-in. Para ellos, elegir OpenShift era una decisión obvia.
Es algo solo ligeramente relacionado con la venta de software, pero hace tiempo vendí una actualización de interfaz de usuario para un juego con un diseño pésimo.
Le puse un precio del doble que el del juego en sí, y aun así la gente la compró. Porque estaba diseñada profesionalmente.
Yo, como diseñador profesional, aparté tiempo de mi trabajo principal para hacer algo que ese desarrollador probablemente no podía hacer.
En los comentarios de la plataforma de distribución digital donde se vendía en ese momento, la queja más clara era que la actualización era demasiado cara, y la gente, naturalmente, comentaba sobre el posicionamiento de precio.
Pero una cosa estaba clara: el juego en sí era demasiado barato.
Si la gente se queja solo del precio pero sigue comprando, significa que no tiene nada más de qué quejarse.
Los pájaros siempre quieren comida gratis. No hay que acomodarse a los pájaros.
Además, esa actualización también fue distribuida ilegalmente y se difundió bastante entre usuarios de copias pirata. Eso en realidad me alegró, porque la mayoría de los clientes pagó.
También quedó claro que yo estaba satisfaciendo un conjunto de funciones deseadas que no se ofrecía en otro lado. Ese tipo de problema es un síntoma bastante bueno de que hiciste algo que la gente quiere.
Creo que muchos proyectos de código abierto no se vuelven open source por elección, sino por necesidad
Algunos productos solo tienen alguna posibilidad de adopción si se hacen open source
El autor se concentra en una minoría de proyectos open source de élite, y esos no representan a la gran mayoría de los proyectos open source
Algunas empresas tienen los contactos adecuados en negocios y gobierno, por lo que pueden vender licencias de producto fácilmente a precios altos, pero son pocas
La mayoría de las personas y pequeñas empresas no tienen esas redes. Sin una red de negocios adecuada, es difícil ganar aunque sea algo de dinero
No importa qué tan bueno sea el producto ni cuánto pueda reducir los costos de alguien. Nadie confía en él ni lo prueba. Aunque el beneficio a largo plazo pueda ser enorme, la barrera de adopción es demasiado alta
Hacer que el producto sea open source es la única forma de meter aunque sea un pie en la puerta. Porque le da una mínima posibilidad de llamar la atención, y a veces eso es todo