Si prefieres ver esta newsletter en un navegador, es aquí.

Esta newsletter ha sido patrocinada por

Edición patrocinada por Vidext

Si quieres patrocinar esta newsletter (ya para 2026) tienes más información aquí. 

37signals ha lanzado una herramienta de gestión de proyectos. Y, como en cada uno de sus lanzamientos, han buscado con qué polémica podían alimentarlo. Y esta vez le ha tocado el turno al mundo Open Source. 

Fizzy tiene una licencia que han llamado O'Saasy y que han inventado ellos. Básicamente modifica la licencia MIT —una de las más permisivas— para evitar que otros revendan el software que has desarrollado.

Así que ellos etiquetan su software como Open Source –porque puedes ver el código– pero acotan una de las libertades que permiten las licencias que realmente son Open Source. Eso ha provocado la crítica encarnizada de los puristas del Open Source.

El motivo es que consideran que proporcionar el código es una condición necesaria pero no suficiente para considerarse Open Source y que hay que acompañarlo con otras libertades. El tema habrá sorprendido cero a DHH, que lleva participando en el mundo Open Source desde hace decenas de años, y la polémica, como siempre, le estará trayendo bastante visibilidad. 

Así que hoy vamos a hablar sobre cómo se está usando la etiqueta Open Source para vender más. 

Partamos de esta base. Yo arranqué mi carrera en un laboratorio de investigación en el que usar algo que no fuera open source era prácticamente un delito. Y ahí me quedó claro que Open Source no es solamente enseñar el código: es acompañarlo de unas libertades claramente definidas y aceptadas por todos. 

Matt Mullenweg, el creador de WordPress, hace una buena analogía de este caso y compara el uso DHH de la palabra Open Source con el uso que hace Corea del Norte de la palabra Democracia. Y, aunque extremo como siempre es él, lleva razón en su comparativa. Hay palabras que están acompañadas de mayor significado que solamente el que les da el lenguaje y utilizarlas mal a sabiendas no está bonito. 

Pero, también es cierto, que se producen muchos abusos del código Open Source. 

Que una pequeña empresa utilice un producto Open Source gigante y lo revenda o lo añada a su infraestructura no parece un gran problema para ninguna de las partes. 

Pero cuando los grandes del cloud se dedican a revender productos Open Source llevando al límite las licencias que tienen, pues la cosa se pone más fea. Hay varios ejemplos de empresas que han cambiado de licencia porque –al menos oficialmente– les ha sucedido esto. 

Elastic cuando Amazon lanzó Amazon Elasticsearch Service, además de denunciarlos por incumplimiento de marca, procedió a cambiar su licencia. También le sucedió lo mismo a Redis con Google Cloud o a MongoDB con el propio Amazon. 

¿Es justo que las empresas creen software Open Source como estrategia para popularizarse y luego cambien las licencias? No creo que lo sea. ¿Es justo que AWS o GCP se aprovechen del trabajo de empresas que crean el producto Open Source para revenderlo sin más? Pues tampoco lo creo.

Con la colaboración de Indexa Capital

Hay otras empresas con productos Open Source que mantienen sus licencias pero convierten en propietaria una parte indispensable para que su producto se convierta en usable. 

Por ejemplo, Confluent no cambió la licencia de Kafka, principalmente porque no podía hacerlo. Pero sí que licenció muchas partes que había desarrollado fuera del paraguas de la Apache Foundation para que no se pudieran revender. Componentes que eran muy relevantes para hacer un uso intensivo de Kafka. Paradójicamente, ahora IBM ha comprado Confluent y controla a casi el 75% de sus commiters. Como bien dice Javi, no pueden cambiar la licencia, pero podrían paralizar el proyecto si quisieran. 

Otro buen ejemplo está en ClickHouse que, desde que se estableció como compañía en 2021 y, especialmente desde que levantó una tonelada de millones, ha comenzado a lanzar funcionalidades de forma exclusiva para su cloud privado. Son proyectos que se definen como Open Core, manteniendo una versión abierta de su producto pero cerrando funcionalidades que, si lo quieres usar de forma seria, son muy deseables. Podríamos llamar a la estrategia “Te lo regalo pero mejor págame”. 

También hablamos ya en esta newsletter de la polémica que se mantuvo entre WPEngine y WordPress. Su queja principal, legítima o no, era que WPEngine se beneficiaba mucho de Wordpress pero contribuía poco. Y eso sucede en muchos proyectos Open Source.

La realidad es que hay muchos proyectos Open Source que ni siquiera tienen una forma de monetización clara detrás. Hay muchos proyectos que, a pesar de ser parte crucial en la infraestructura de muchas empresas, están desarrollados principalmente por voluntarios. 

Un ejemplo es el de FFmpeg, que tuvo una polémica bastante guapa a finales del año pasado en la que contó como el trabajo de sus voluntarios estaba saturado por las continuas peticiones de empresas que usaban su producto. La explosión vino cuando un agente de Google detectó un bug que provocaba un fallo decodificando los primeros 20 frames del Rebel Assault, un juego de 1995. Además lo calificó como de medio impacto. 

Un caso muy parecido lo vivió también libxml2: Una librería que se utiliza en miles de proyectos y que únicamente ha recibido 17000$ de donaciones. Curl, una herramienta que casi todos hemos utilizado en algún momento, solamente tiene un empleado a tiempo completo. En OpenSSL solamente una persona aprobó más de la mitad de las contribuciones recibidas en las más de 450.000 líneas de código del proyecto. 

Todos ellos son proyectos vitales para un montón de empresas y sus mantenedores están infrapagados y sobrepasados. La pregunta que nos hacemos todos los que nos dedicamos a los negocios es, ¿Por qué no monetizan? ¿Quizás la solución sería montar un negocio alrededor de ellos? 

Pero ese negocio volvería a traer la polémica que hemos visto arriba. En cuanto las empresas empezasen a conseguir financiación externa y esos inversores quisieran ver los retornos que quieren ver los inversores de Venture Capital, esos productos empezarían a ser cada vez menos libres, sus licencias empezarían a cerrarse y sus funcionalidades abiertas serían más pobres. 

¿Es mejor camino? ¿Es peor? Sinceramente, no tengo respuesta pero este es un mundo fascinante. 

Si has llegado aquí sin estar suscrito

puedes suscribirte aquí

Recuerda que todo feedback es bienvenido, puedes contestar directamente a este correo y te responderé personalmente.

Darme de baja | Modificar mis datos