¿Se puede vivir del open source? T3chfest
1 recomendación41 vistas
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.
¿Se puede vivir del open source? T3chfest
- 1. ¿Se puede vivir del Open Source? Javier Ramírez @supercoco9 @j@chaos.social Database Advocate
- 3. 3 https://blog.opencollective.com/frontend-masters/ Marc Grabanski, desarrollador de JQuery UI date picker.
- 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?
- 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