Cómo convertí un proyecto de código abierto en un negocio

• Empecé a escribir y distribuir software de código abierto por primera vez hace unos 15 años, y en ese entonces solo usaba licencias permisivas como MIT o BSD.
• Me sentía honrado de que empresas de primer nivel usaran mis bibliotecas de código abierto, como Nodemailer, aunque incluso rechacé una oferta de donación del fundador de un gran servicio de correo electrónico.
• Pero cuando una startup que usaba Nodemailer fue adquirida por 500 millones de dólares, empecé a preguntarme qué era lo que yo había ganado.
• Cuando inicié EmailEngine, traté de protegerme lo más posible, así que usé la licencia LGPL y establecí un proceso de CLA (Contributor License Agreement).
• A mucha gente no le gustan los CLA, pero como yo escribí directamente el 98.1% del código de Nodemailer y el 99.8% en el caso de EmailEngine, no era un gran problema que no se fusionaran PR (pull requests).
• Quise monetizar el nuevo proyecto, así que lo publiqué con licencia LGPL y dejé que la versión MIT solo pudiera obtenerse mediante suscripción; la cuota anual era de 250 euros.
• Pero este modelo de negocio fracasó, y durante un año y medio los ingresos totales fueron de apenas 750 euros.
• Rediseñé profesionalmente la UI de la app e introduje un sistema de claves de licencia; para usar EmailEngine se necesitaba una clave de licencia que solo podían obtener los suscriptores de pago.
• Cambié de LGPL a una licencia comercial; el código fuente sigue público en GitHub, pero ya no es open source, sino "source-available".
• Sigo publicando herramientas más pequeñas con licencia MIT, pero no lo hago con los proyectos principales.
• Por ejemplo, extraje de EmailEngine la funcionalidad de cliente IMAP y la publiqué bajo licencia MIT como una biblioteca general de cliente IMAP para Node.js; este módulo ofrece un rendimiento muy superior al de las alternativas existentes.
• Al principio no había opción de prueba, y si no se proporcionaba una clave de licencia válida dentro de los 15 minutos posteriores al inicio de la aplicación, la app dejaba de funcionar.
• Mantuve el mismo precio, y en el primer mes vendí suscripciones por un valor de 1,750 euros, lo que decidió el destino del proyecto.
• Fui aumentando gradualmente el precio, y eso no redujo la cantidad de clientes; para las empresas, una cifra menor a 1,000 dólares no parece ser una carga importante.
• Actualmente, el ingreso recurrente mensual (MRR) de EmailEngine es de 6,100 euros y, en Estonia, eso me permite pagarme un sueldo razonable y dedicarme de lleno al proyecto.

La opinión de GN⁺

• Este artículo comparte el proceso de convertir un proyecto de código abierto en un negocio comercial y muestra a los desarrolladores open source que sí existe la posibilidad de generar ingresos.
• Subraya que ofrecer software de código abierto gratis puede perjudicar al desarrollador a largo plazo, y muestra que es posible obtener ingresos estables mediante la transición a una licencia comercial.
• También ofrece ideas valiosas sobre la importancia del CLA dentro de la comunidad open source y sobre cómo la elección de licencia influye en el modelo de negocio.
• Hay que considerar los tipos de licencia y sus implicaciones legales y financieras, y es importante prever la reacción de la comunidad y el nivel de contribución al comercializar un proyecto open source.
• La ventaja de elegir este enfoque es contar con ingresos estables y un entorno que permite enfocarse en el desarrollo profesional del producto, pero la desventaja es que se puede perder apoyo y contribuciones de la comunidad open source.

[GN⁺]

Opiniones en Hacker News

• La idea central de la historia es que el autor empezó a conseguir suscriptores cuando hizo que el software dejara de funcionar sin una licencia.

  Si no se proporciona una clave de licencia válida dentro de los 15 minutos posteriores al inicio de la aplicación, la app deja de funcionar.

  • Para la mayoría de los usuarios, un cambio de licencia (MIT/LGPL, etc.) no importa. En Hacker News (HN) se presta atención a esas diferencias sutiles, pero para empleados de empresas que solo quieren resolver su trabajo, probablemente no sea un gran problema.
  • Los usuarios buscan el software para resolver un problema, lo instalan, verifican si funciona y siguen con su día. Pero si el software deja de funcionar después de 15 minutos, tienen que resolver ese bloqueo.
  • Se puede asumir que los usuarios leerán el código y quitarán la verificación de licencia, pero algunos prefieren pagar con tarjeta de crédito en su lugar.

• La experiencia del autor con el software de código abierto es que, cuando se ofrece gratis, las empresas casi nunca pagan aunque reconozcan su valor. En cambio, una suma pequeña como 1,000 USD al año suele poder ser aprobada por un desarrollador en la mayoría de las empresas sin demasiado papeleo.

  • Una vez que se entra en el terreno de ventas enterprise, todo se vuelve mucho más complejo y el ciclo de ventas se alarga. Para un fundador en solitario, este esquema de precios es perfecto.

• Cuando una startup que usaba Nodemailer fue adquirida por 500 millones de dólares, el autor empezó a pensar qué había obtenido él de eso.

  • Mientras algunas personas se esfuerzan por mejorar recursos compartidos, hay empresas optimizadas para maximizar ganancias de corto plazo. Esas empresas no van a devolver nada.
  • Esto puede pasarle a cualquier desarrollador de open source, y es humano sentir que uno debería recibir parte de los ingresos al ver empresas ganando mucho dinero.
  • FOSS hace del mundo un lugar mejor, pero es lamentable llevar a alguien a pensar que eso fue un error y concluir que, en su lugar, debería crear proyectos que las organizaciones FOSS no puedan usar.
  • Si se crea el mejor software FOSS, todos se benefician, y uno puede sentir orgullo de que una persona individual tenga acceso a los mismos recursos que una gran empresa.
  • Hay una aprobación cautelosa hacia la idea de asustar a las grandes empresas con software con licencia GPLv3 o AGPL.

• Para quienes tienen curiosidad por la licencia, se explica que la firma estándar usa una clave EC (sect239k1).

  • El autor puede escribir la fecha de validez y los detalles de la licencia (como el nombre del host), firmarlos y entregárselos al cliente.

• Cuando empezó a subir los precios, le sorprendió que la cantidad de clientes no disminuyera.

  • Para los negocios, una cifra menor a 1,000 dólares no suele ser un problema, así que subir el precio solo mejora los ingresos.

• Los desarrolladores de código abierto se identifican con los usuarios, pero los negocios que buscan retorno sobre la inversión (ROI) no son lo mismo que consumidores.

• Nadie trabaja gratis; trabajamos para obtener dinero, estatus o disfrute.

  • Una forma de hacer que la gente trabaje sin pagarle son las redes sociales financiadas con publicidad. Les dan entretenimiento a las personas y obtienen gratis su atención para los anuncios.
  • Si uno se enfoca en trabajar para obtener estatus, un buen ejemplo es el doctorado. Si alguien obtiene un PhD y se queda en la academia, el salario es muy bajo frente al de la industria, pero existe la promesa de estatus.
  • En open source pasa algo parecido: los debates sobre la pureza y los argumentos de autosacrificio son evidencia de que la gente está obteniendo estatus en vez de dinero.
  • Eso no es malo en sí mismo (ni en open source ni en la academia); la gente debería poder elegir libremente cómo vender su tiempo.
  • El problema es que quienes se benefician de una estructura de trabajo basada en estatus (grandes empresas, universidades y sus líderes) tienen incentivos para usar patrones oscuros y mantener esa estructura.

• El título es engañoso. El autor cambió un proyecto open source por un producto comercial con código disponible. No es un negocio alrededor de un proyecto open source, como sugiere el título, sino un cambio de licencia.

• El autor dice que su único arrepentimiento es no haber empezado antes a vender el software, en lugar de publicar solo software open source gratuito.

• También hay una opinión que se pregunta si el autor alguna vez pidió patrocinio para Nodemailer.