Transformei meu projeto open source em um negócio em tempo integral
Um projeto de ferramentas de e-mail que começou como software livre open source foi relicenciado como um produto pago, source-available, com uma verificação simples de chave de licença, permitindo que seu desenvolvedor solo ganhasse uma renda em tempo integral. Os comentadores exploram por que esse modelo funciona em B2B — a maioria das empresas prefere pagar menos de US$ 1.000/ano a correr o risco de violar licenças ou gastar tempo de engenharia — e o contrastam com a quase impossibilidade de monetizar ferramentas “gratuitas” apenas com doações. O tópico também levanta tensões éticas e práticas em torno de contributor license agreements, “rug pulls” percebidos quando projetos se tornam proprietários, e se licenças copyleft como GPL/AGPL protegem melhor os mantenedores de grandes empresas extraindo valor sem retribuir.
Mudança de licenciamento & modelo de negócio
- Movimento central: o projeto passou de open source (AGPL, embora o artigo diga LGPL) para source-available com uma licença comercial e verificação de chave de licença.
- Isso foi viabilizado ao exigir CLAs desde o início, dando ao mantenedor principal o direito legal de relicenciar.
- Versões antigas em AGPL permanecem no GitHub; o licenciamento fechado se aplica apenas daqui para frente.
- Vários comentadores veem isso como uma resposta racional a grandes empresas extraindo enorme valor sem contribuir com dinheiro, PRs ou sequer agradecimentos.
Pirataria, aplicação de licença & comportamento do cliente
- Muitos observam que verificações locais de licença são triviais de contornar ou patchar.
- O consenso: para B2B, os principais impedimentos são risco jurídico, sinais de alerta na due diligence e o valor de suporte/atualizações; a maioria dos clientes sérios simplesmente paga.
- Para ferramentas de nicho para devs e B2C, a pirataria seria muito maior; alguns devs solo relatam poucos piratas observados mesmo com verificações fracas.
- Alguns argumentam que piratas que nunca teriam pago de qualquer forma não representam “vendas perdidas”.
CLAs, direitos de contribuidores & preocupações com “rug pull”
- CLAs são vistos por alguns como algo que explicitamente viabiliza futuros “rug pulls” (relicenciamento para proprietário).
- Críticos argumentam que o trabalho dos contribuidores é monetizado sem divisão de receita, mesmo que sua parcela de código seja minúscula.
- Outros respondem que, neste caso, as contribuições externas foram mínimas e que qualquer lançamento anterior aberto permanece livre e passível de fork.
- Vários recomendam tratar “CLA obrigatório” como um sinal claro de que o relicenciamento é provável.
Preços, compras corporativas & faturamento
- Preços fixos abaixo de US$ 1 mil/ano são repetidamente descritos como um “ponto ideal”: abaixo de limites de aprovação, fáceis de justificar, muito mais simples do que SaaS por assento.
- Complexidade e atrito de procurement, não o nível de preço, frequentemente bloqueiam a adoção.
- Marketplaces (por exemplo, cloud) e Merchants of Record (Paddle, Lemon Squeezy, FastSpring) são discutidos como formas de terceirizar impostos/VAT e papelada; Stripe é comum quando você consegue lidar com impostos.
Sustentabilidade do open source, copyleft & motivação
- Muitos argumentam que “open source não é um modelo de negócio”; você precisa estruturar receita (suporte, licença dupla, serviço hospedado etc.).
- Experiências de burnout e ressentimento quando unicórnios lucram com FOSS sem retribuir são comuns.
- Alguns defendem GPL/AGPL ou AGPL/proprietário em modelo dual para forçar “retribuir ou pagar”, e criticam MIT/BSD como prejudiciais aos autores.
- Outros enfatizam que FOSS deve ser abordado com objetivos não monetários claros (aprendizado, status, contribuição ao comum), ou você corre o risco de desilusão.
Source-available & dinâmica de suporte
- Source-available é valorizado por depuração, transparência de segurança e a opção de corrigir por conta própria problemas críticos.
- Usuários pagantes, segundo relatos, fornecem feedback mais focado e orientado ao negócio do que usuários gratuitos, que muitas vezes pedem recursos especulativos do tipo “e se”.
- A carga de suporte do dev solo neste caso é descrita como modesta (cerca de uma hora por dia), ajudada pela competência dos clientes em auto-hospedagem.