Convertí mi proyecto de código abierto en un negocio a tiempo completo
Un proyecto de herramientas de correo electrónico que comenzó como software libre y de código abierto fue relicenciado como un producto de pago, disponible con código fuente, y con una simple comprobación de clave de licencia, lo que permitió a su desarrollador en solitario obtener ingresos a tiempo completo. Los comentaristas exploran por qué este modelo funciona en B2B —la mayoría de las empresas prefiere pagar menos de 1.000 USD/año antes que arriesgarse a violar licencias o gastar tiempo de ingeniería— y lo contrastan con la casi imposibilidad de monetizar herramientas “gratuitas” solo mediante donaciones. El hilo también plantea tensiones éticas y prácticas en torno a los acuerdos de licencia de contribuyentes, los percibidos “rug pulls” cuando los proyectos se vuelven propietarios, y si licencias copyleft como GPL/AGPL protegen mejor a los mantenedores frente a grandes empresas que extraen valor sin devolver nada.
Cambio de licencia y modelo de negocio
- Movimiento principal: el proyecto pasó de ser de código abierto (AGPL, aunque el artículo dice LGPL) a estar disponible como código fuente con una licencia comercial y una comprobación de clave de licencia.
- Esto fue posible gracias a exigir CLAs desde el principio, lo que dio al mantenedor principal el derecho legal a relicenciar.
- Las versiones antiguas bajo AGPL siguen en GitHub; la licencia cerrada solo se aplica a partir de ahora.
- Varios comentaristas ven esto como una respuesta racional a grandes empresas que extraen un valor enorme sin contribuir con dinero, PRs o siquiera agradecimientos.
Piratería, cumplimiento de licencias y comportamiento de los clientes
- Muchos señalan que las comprobaciones locales de licencia son triviales de eludir o parchear.
- El consenso: para B2B, los principales disuasivos son el riesgo legal, las señales de alerta en la diligencia debida y el valor del soporte/las actualizaciones; la mayoría de los clientes serios simplemente paga.
- Para herramientas de nicho para desarrolladores y B2C, la piratería sería mucho mayor; algunos desarrolladores independientes informan de pocos piratas observados incluso con comprobaciones débiles.
- Algunos argumentan que los piratas que nunca habrían pagado de todos modos no representan “ventas perdidas”.
CLAs, derechos de los contribuyentes y preocupaciones por “rug pull”
- Algunos ven los CLAs como una forma explícita de habilitar futuros “rug pulls” (relicenciar a propietario).
- Los críticos sostienen que el trabajo de los contribuyentes se monetiza sin reparto de ingresos, aunque su parte de código sea diminuta.
- Otros responden que, en este caso, las contribuciones externas fueron mínimas y que cualquier lanzamiento previo de código abierto sigue siendo libre y se puede bifurcar.
- Varios recomiendan tratar “CLA requerido” como una señal clara de que probablemente habrá relicenciamiento.
Precios, compras empresariales y facturación
- El precio fijo por debajo de 1.000 USD/año se describe repetidamente como un “punto óptimo”: por debajo de umbrales de aprobación, fácil de justificar y mucho más simple que el SaaS por puesto.
- La complejidad y la fricción de compras, no el nivel de precio, suelen bloquear la adopción.
- Se discuten los marketplaces (p. ej., cloud) y los Merchants of Record (Paddle, Lemon Squeezy, FastSpring) como formas de externalizar impuestos/IVA y papeleo; Stripe es común cuando puedes encargarte de los impuestos.
Sostenibilidad del código abierto, copyleft y motivación
- Muchos sostienen que “el código abierto no es un modelo de negocio”; hay que diseñar ingresos (soporte, doble licencia, servicio alojado, etc.).
- Son comunes las experiencias de agotamiento y resentimiento cuando los unicornios obtienen beneficios del FOSS sin devolver nada.
- Algunos abogan por GPL/AGPL o doble licencia AGPL/propietaria para forzar “devuelve algo o paga”, y critican MIT/BSD como perjudiciales para los autores.
- Otros enfatizan que el FOSS debe abordarse con objetivos no monetarios claros (aprendizaje, estatus, contribuir al bien común), o se corre el riesgo de desilusionarse.
Disponible con código fuente y dinámica de soporte
- Se valora el modelo source-available por la depuración, la transparencia de seguridad y la opción de corregir por uno mismo problemas críticos.
- Se informa de que los usuarios de pago dan comentarios más centrados y orientados al negocio que los usuarios gratuitos, que a menudo piden funciones especulativas de tipo “¿y si…?”.
- La carga de soporte para un desarrollador independiente en este caso se describe como moderada (unas una hora al día), ayudada por la competencia de los clientes para autoalojar el software.