Como transformei um projeto open source em um negócio

• Comecei a escrever e distribuir software open source pela primeira vez há cerca de 15 anos e, naquela época, usava apenas licenças permissivas como MIT ou BSD.
• Eu me sentia honrado ao ver empresas de primeira linha usando minhas bibliotecas open source, como o Nodemailer, mas cheguei a recusar uma oferta de doação do fundador de um grande serviço de e-mail.
• Mas, quando uma startup que usava o Nodemailer foi adquirida por 500 milhões de dólares, comecei a me perguntar o que eu havia ganhado com isso.
• Quando iniciei o EmailEngine, tentei me proteger o máximo possível, usando a licença LGPL e configurando um processo de CLA (Contributor License Agreement).
• Muitas pessoas não gostam de CLA, mas como escrevi 98,1% do código do Nodemailer e, no caso do EmailEngine, 99,8%, o fato de PRs (pull requests) não serem mesclados não era um grande problema.
• Para gerar receita com o novo projeto, publiquei o projeto sob licença LGPL e deixei a versão MIT disponível apenas para quem assinasse, com uma taxa anual de 250 euros.
• Mas esse modelo de negócio fracassou e, ao longo de um ano e meio, a receita total foi de apenas 750 euros.
• Redesenhei profissionalmente a UI do aplicativo e introduzi um sistema de chaves de licença; para usar o EmailEngine, era necessária uma chave de licença disponível apenas para assinantes pagantes.
• Mudei de LGPL para uma licença comercial; o código-fonte continua público no GitHub, mas não é mais open source, e sim "source-available".
• Continuo publicando ferramentas menores sob licença MIT, mas não faço isso com os projetos principais.
• Por exemplo, extraí do EmailEngine a funcionalidade de cliente IMAP e a publiquei sob licença MIT como uma biblioteca genérica de cliente IMAP para Node.js; esse módulo oferece desempenho muito superior às alternativas existentes.
• No começo, não havia opção de teste e, se uma chave de licença válida não fosse fornecida em até 15 minutos após o início da aplicação, o app parava de funcionar.
• Mantive o mesmo preço e, no primeiro mês, vendi 1.750 euros em assinaturas, o que definiu o destino do projeto.
• Fui aumentando o preço gradualmente, e isso não reduziu o número de clientes; para empresas, parece que valores abaixo de 1.000 dólares não pesam tanto.
• Atualmente, a receita recorrente mensal (MRR) do EmailEngine é de 6.100 euros e, na Estônia, isso me permite pagar a mim mesmo um salário adequado e me dedicar integralmente ao projeto.

Opinião do GN⁺

• Este artigo compartilha o processo de transformar um projeto open source em um negócio comercial e mostra aos desenvolvedores open source a possibilidade de gerar receita.
• Ele destaca que oferecer software open source gratuitamente pode, no longo prazo, ser desfavorável ao desenvolvedor, e mostra que a migração para uma licença comercial pode proporcionar uma receita estável.
• O artigo oferece insights sobre a importância do CLA dentro da comunidade open source e sobre o impacto da escolha da licença no modelo de negócio.
• É preciso considerar os tipos de licença e seus impactos legais e financeiros, além de prever a reação da comunidade e o nível de contribuição no processo de comercialização de um projeto open source.
• A vantagem dessa abordagem é obter uma receita estável e um ambiente que permite focar no desenvolvimento profissional do produto, mas a desvantagem é poder perder apoio e contribuições da comunidade open source.

[GN⁺]

Opiniões do Hacker News

• O ponto central da história é que o autor começou a conseguir assinantes quando fez o software parar de funcionar sem uma licença.

  Se uma chave de licença válida não for fornecida em até 15 minutos após o início da aplicação, o app para de funcionar.

  • Para a maioria dos usuários, mudanças de licença (MIT/LGPL etc.) não importam. No Hacker News (HN), essas diferenças sutis são levadas a sério, mas para funcionários de empresas que só querem resolver o trabalho do dia a dia, isso provavelmente não faz tanta diferença.
  • Os usuários procuram um software para resolver um problema, instalam, verificam se funciona e seguem com o dia. Mas, se o software para de funcionar depois de 15 minutos, eles precisam resolver esse bloqueio.
  • Dá para presumir que alguns usuários leriam o código e removeriam a checagem de licença, mas outros preferem simplesmente pagar com cartão de crédito.

• A experiência do autor com software de código aberto é que, quando ele é oferecido de graça, as empresas quase nunca pagam, mesmo reconhecendo seu valor. Em contrapartida, um valor pequeno como 1.000 USD por ano pode ser comprado por desenvolvedores na maioria das empresas sem muita burocracia.

  • Quando se entra na área de vendas enterprise, a situação fica muito mais complexa e o ciclo de vendas fica mais longo. Para um fundador solo, essa política de preços é perfeita.

• Quando uma startup que usava o Nodemailer foi adquirida por 500 milhões de dólares, o autor começou a pensar no que ele tinha ganhado com isso.

  • Enquanto alguns se esforçam para melhorar recursos compartilhados, há empresas otimizadas para maximizar ganhos de curto prazo. Elas não vão devolver nada.
  • Isso pode acontecer com qualquer desenvolvedor de código aberto, e é humano olhar para empresas que estão ganhando muito dinheiro e sentir que se deveria receber parte dessa receita.
  • FOSS torna o mundo melhor, mas é triste ver alguém chegar à conclusão de que isso foi um erro e que, em vez disso, deveria criar projetos que instituições ligadas a FOSS não possam usar.
  • Se você cria o melhor software FOSS, todo mundo se beneficia, e dá para sentir orgulho do fato de que indivíduos têm acesso aos mesmos recursos que grandes empresas.
  • Há uma concordância cautelosa com a ideia de assustar grandes empresas com software licenciado em GPLv3 ou AGPL.

• Para quem está curioso sobre a licença, é explicado que a assinatura padrão usa uma chave EC (sect239k1).

  • O autor pode escrever a data de validade/detalhes da licença (como nome do host etc.), assinar isso e entregar ao cliente.

• Quando começou a aumentar os preços, o autor se surpreendeu ao ver que o número de clientes não caiu.

  • Para empresas, valores abaixo de 1.000 dólares não costumam ser um grande problema, então aumentar o preço só melhora a receita.

• Desenvolvedores de código aberto se identificam com os usuários, mas empresas que obtêm retorno sobre investimento (ROI) são diferentes de consumidores.

• Ninguém trabalha de graça; nós trabalhamos para ganhar dinheiro, status ou prazer.

  • Uma forma de fazer as pessoas trabalharem sem pagar é por meio de redes sociais sustentadas por anúncios. Elas oferecem diversão às pessoas e obtêm atenção para anúncios de graça.
  • Se o foco for trabalhar para obter status, um bom exemplo é o doutorado. Ao fazer um doutorado e permanecer na academia, o salário é muito baixo em comparação com a indústria, mas existe a promessa de status.
  • O mesmo vale para o código aberto: debates sobre pureza e argumentos em favor do auto-sacrifício são evidências de que as pessoas estão recebendo status em vez de dinheiro.
  • Isso não é ruim por si só (nem no código aberto nem na academia), e as pessoas devem ser livres para escolher como vender seu tempo.
  • O problema é que aqueles que lucram com estruturas de trabalho baseadas em status (grandes empresas, universidades e seus líderes) têm incentivo para usar dark patterns para manter essa estrutura.

• O título é enganoso. O autor transformou um projeto de código aberto em um produto comercial com código-fonte disponível. Não se trata de um negócio em torno de um projeto de código aberto, como o título sugere, mas de uma mudança de licença.

• O único arrependimento do autor é não ter começado a vender o software antes, em vez de publicar apenas software livre e de código aberto gratuitamente.

• Há um comentário perguntando se o autor já chegou a pedir patrocínio para o Nodemailer.