El documento explora la viabilidad de vivir del software de código abierto (OSS), analizando modelos de monetización, estrategias de licencias y los desafíos que enfrentan los desarrolladores en este campo. Se discuten casos de cambio de licencia en proyectos populares y la experiencia de QuestDB en el desarrollo y sostenibilidad de su software. El autor enfatiza la importancia de una planificación y comunicación efectiva con la comunidad para lograr un equilibrio entre la oferta de OSS y la generación de ingresos.

1. ¿Se puede vivir del
Open Source?
Javier Ramírez
@supercoco9
@j@chaos.social
Database Advocate

2. 2
https://xkcd.com/2347/

3. 3
https://blog.opencollective.com/frontend-masters/
Marc Grabanski,
desarrollador de JQuery UI date
picker.

4. 4
https://twitter.com/phaidinyak/status/1754851060831633555

5. 5
https://twitter.com/fxn/status/1540565108920827904

6. 6
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4693148
Las empresas tendrían que
gastar 3.5 veces más de lo que
gastan en software si no hubiese
OSS.
Por un valor de $8.8 trillones

7. Algunas cosas
de las que quiero hablar
● Si el open source es gratis, ¿Es sólo un
hobby o se puede vivir de ello?
● Montas un proyecto open source, lo das
gratis, y luego viene una empresa
gigante y hace negocio vendiéndolo.
¿Cómo te quedas?
● ¿Qué hay detrás de los cambios de
licencia en proyectos como MongoDB,
Redis, Terraform, o Elastic?
● Posibles modelos de negocio si quieres
monetizar tu proyecto

8. ¿Quién soy yo para hablar de esto?
● Usuario de open source, profesionalmente, desde ~1999 👴
● Co-organizador de grupos locales y eventos sobre el lenguaje Ruby 2006-2012 💎
● Speaker frecuente sobre proyectos open source, sobre todo en lo relacionado a datos, desde 2006 🗣
● El momento más tenso cuando entrevisté para AWS fue al preguntar sobre Open Source 🙊 (spoiler:
pasé la entrevista)
● En dos de mis empresas hemos hecho fork de otros proyectos por conflictos de intereses 👀
● Asistente habitual de FOSDEM, he sido speaker (x3) y organizador de una sala sobre datos rápidos🔥
● En 2023 OpenUK me metió en la lista “UK Top 100 influencers in Open Source”, pero me sacaron cuando
les dije que llevaba 4 años sin vivir en UK 💔
● Desde 2022 trabajo para QuestDB, una base de datos con licencia Apache 2.0 💰
● Mi usuario de github es ´javier´ 😂

9. 9

10. ¿Qué es eso de QuestDB?

12. Si sólo puedes usar una base
de datos para todo, elige
PostgreSQL*
* O cualquier otra base de datos relacional que te mole y esté bien soportada

14. Hay cosas para las que las RDBMS no están diseñadas
● Escribir más rápido de lo que lees (varios millones de inserciones al día, o más)
● Agregados con respecto a diferentes unidades de tiempo (por año/minuto/microsegundo)
● Identificar huecos o datos que faltan en un intervalo determinado
● Unir tablas por timestamp aproximado
● Tablas “sparse” (con cientos o miles de columnas)
● Agregados sobre billones de registros
● Servir como backend de dashboards en tiempo real

15. ¿Qué es open source?. Lo que diga la
1. Free Redistribution
2. Source Code
3. Derived Works
4. Integrity of The Author’s Source Code
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor
7. Distribution of License
8. License Must Not Be Specific to a Product
9. License Must Not Restrict Other Software
10. License Must Be Technology-Neutral

16. ¿Y la ?
1. Use: Freedom to run the program as you wish, for any purpose
2. Study: Freedom to study how the program works, and change it as you wish
3. Share: Freedom to redistribute copies, so you can help others
4. Improve: Freedom to distribute copies of your modified version to others
We prefer the term “free software” because it refers to freedom—something that the
term “open source“ does not do.
OSS ~ FOSS ~ FLOSS

17. Categorías de software según la FSF
https://www.gnu.org/philosophy/categories.html.en
Por haber usado este gráfico, ahora
tengo que poner mi presentación
bajo la licencia Creative Commons
Attribution-ShareAlike 4.0
International

18. Eligiendo tu licencia
● Permisiva: Unlicense, MIT, BSD, Apache
● Copyleft: GPL, AGPL, LGPL, GPL with Classpath Exception, EPL, MPL
Si eliges una licencia copyleft, no puedes evitar que otras organizaciones
utilicen tu software o lo vendan, pero les obligas a que su software sea también
open source.

19. Posibilidad de licencia dual
● Una licencia copyleft (GPL, AGPL normalmente)
● Una licencia comercial
En este caso, solo el propietario del copyright puede ofrecer la licencia, lo que
implica que si aceptas contribuciones externas no podrás incorporarlas en la
licencia comercial, que es el motivo por el que muchos proyectos te piden
firmar un Contributor License Agreement.

20. 20
Los CLAs pueden ser una
fuente de fricción
importante. Puedes
perder contribuciones
https://element.io/blog/synapse-now-lives-at-github-com-element-hq-synapse/

21. Modelos de monetización
● No monetizar (o no directamente)
● Mecenas/Patrocinadores
● Anuncios
● Donaciones/merchandising
● Cobrar por soporte, formación, certificación y servicios profesionales
● Licencia dual para enterprise
● Open Core/Commercial Open Source
● Software As A Service/managed cloud
● Cobrar por el empaquetado y los binarios
● Trademark y licenciar a partners

22. 22

23. Algunos puntos de fricción
● Si tu proyecto se puede usar gratis, es difícil convencer para que te paguen
● Si hay varios contribuidores, ¿Quién cobra?
● Aunque quieras pagar a los voluntarios del proyecto, si ya tienen trabajos y hacen esto en su tiempo libre,
puede ser difícil convencerles para que cobren dinero. Puede que su contrato lo impida.
● Hay mecenas que querrán pagarte por desarrollar funcionalidades específicas, pero seguramente no para
mantenimiento o bugs generales
● Las donaciones suelen ser de desarrolladores individuales. Las empresas prefieren pagar contra factura. Es
difícil escalar con donaciones
● Si no estás establecido como empresa, puede ser complicado recibir dinero.
● Si te estableces como empresa, es posible que necesites mucho dinero para empezar, sobre todo si quieres
tener un equipo core.
● Si tienes un modelo Open Core y alguien de tu comunidad quiere contribuir al proyecto abierto una
funcionalidad que tú ofreces como propietaria, ¿Qué haces?

24. 24
https://github.com/hoppscotch/hoppscotch/pull/3266

25. Por definición, cualquiera puede monetizar tu
software si tiene una licencia Open Source*
* Y es muy posible que ellos sí tengan dinero para contratar
equipo de desarrollo, marketing y ventas

26. 26
El fundador de MariaDB y
MySQL anuncia la licencia
BSL, que para la mayoría
de gente se comporta
como OSS, pero introduce
restricciones para
algunos usuarios.
Las funcionalidades
cerradas acaban siendo
open source pasados
unos años.
https://timreview.ca/article/691

27. 27
El core sigue siendo
Apache 2.0. Los plugins
pasan a ser “Source
Available”, pero no Open
Source
https://www.elastic.co/blog/doubling-down-on-open

28. 28
Redis hace algo parecido,
con los plugins bajo la
Commons Clause
https://web.archive.org/web/20180821212957/https://redislabs.com/community/commons-clause/

29. 29
Mientras tanto,
MongoDB anuncia su
licencia SSPL
https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues-new-server-side-public-lice
nse-for-mongodb-community-server

30. 30
Neo4j también se va a un
modelo Open Core,
comentando que los
proveedores de nube son
una amenaza
https://neo4j.com/open-core-and-neo4j/

31. 31
Y lo mismo con Confluent y
parte de los componentes
alrededor de Kafka, aunque el
core de Kafka sigue teniendo
licencia Apache
https://www.confluent.io/blog/license-changes-confluent-platform/

32. 32
A Elastic se les complica la
vida, porque una empresa de
la comunidad desarrolla
funcionalidades muy
parecidas y, según elastic,
inspiradas en el código
disponible, visible, pero no
abierto.
https://www.elastic.co/blog/dear-search-guard-users

33. 33
Redis ve cómo la
comunidad le da la
espalda y amenazan con
un fork.
Nuevo cambio de licencia
y se van a la SSPL
https://redis.com/blog/redis-license-bsd-will-remain-bsd/

34. 34
CockroachDB se pasa de
Apache 2.0 al modelo BSL,
en el que no se puede
competir vendiendo su DB
como servicio.
Pasados tres años el
código pasa a ser open
source bajo Apache 2.0.
Parece open source, pero
no lo es.
https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/

35. 35
No solo en
proyectos de
datos.
Software de
observabilidad
como Sentry
también cambió
de licencia en 2019
y 2023.
https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/

36. 36
Y Elastic acaba
adaptando la SSPL
también
https://www.elastic.co/blog/licensing-change

37. 37
Y AWS aprovechó para
sacar Open Search, un
fork de Elastic
https://aws.amazon.com/es/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

38. 38
A HashiCorp con
terraform ya le han salido
forks, semanas tras su
anuncio.
https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

39. ¿Cómo lo hacemos en
QuestDB?

40. Un poco de historia
● El proyecto empieza en 2014, con un solo desarrollador
● Conforme el desarrollador iba cambiando de empresa, se iba usando en
más sitios
● En 2020 se junta con otro co-founder y deciden que para que funcione hace
falta un equipo core de ingeniería, y para eso se necesita dinero.
Consiguieron entrar en YC y luego levantar una ronda de $12MM, con la que
contratar al equipo (yo entre ellos)
● Al principio solo teníamos ingresos por soporte ad-hoc, pero eso no escalaba

41. QuestDB OSS
Open Source. Apache 2.0. Self-managed.
Suitable for production workloads.
https://github.com/questdb/questdb
QuestDB Enterprise
Licensed. Self-managed. Enterprise features like
RBAC, compression, replication, TLS on all
protocols, cold storage, K8s operator…
https://questdb.io/enterprise/
QuestDB Cloud
Fully managed, pay per usage environment,
with enterprise-grade features.
https://questdb.io/cloud/

42. Cómo planeamos la sostenibilidad del proyecto
● Aunque el dinero nos llega de licencias enterprise y pago por uso en nube,
nuestra base de usuarios más grande es la de Open Source, que no pagan
pero son los que más contribuyen en código y conversaciones
● Es muy difícil convertir usuarios de OSS en usuarios de pago
● En principio no nos planteamos cambiar a licencias no OSI
● Notamos cierta tensión en qué funcionalidades son OSS y cuáles hacemos
propietarias. Intentamos hacerlo con cierto sentido común
● A día de hoy, somos ~20 personas en el core y no somos rentables

43. Cerrando
Que esta gente querrá irse a casa
● Se puede vivir del open source,
pero no es algo inmediato.
También se puede decidir
hacerlo de manera altruista.
● La licencia que elijas es crítica.
● Planea bien, y comunica, a tu
comunidad cuál es el modelo.
● Si no eres purista, hay formatos
muy parecidos al open source
que te dan un poco más de
protección con respecto a la
competencia, pero lo mismo te
permiten crecer menos de forma
orgánica

44. 44
Q&A
● github.com/questdb/questdb
● https://questdb.io
● https://demo.questdb.io
● https://github.com/questdb/time-series-streaming-
analytics-template
● https://slack.questdb.io/
Javier Ramirez
@supercoco9
We 💕 contributions
and GitHub ⭐ stars