Open source gera adoção, mas não basta como modelo de negócio

Tese central

Ben Williams argumenta que software open source popular não é, por si só, um modelo de negócio: a licença permite usar o produto sem pagar, e a empresa precisa explicar por que alguém pagaria mesmo assim. A pergunta central é o que se torna valioso o suficiente para pagar depois que alguém já usa o software. Pode ser hospedagem e operação, controle de acesso, conformidade ou suporte - não existe resposta única. O autor mapeia seis modelos e os públicos de cada um.

Os seis modelos

Open core: o produto base é open source e o cliente paga por recursos proprietários adicionais (GitLab com Premium/Ultimate, Grafana com recursos Enterprise, Metabase com permissões avançadas). O produto gratuito precisa resolver um problema completo para um usuário; o limite pago aparece quando a organização precisa governar o uso - permissões, auditoria, SSO. Williams relata sua experiência na CloudBees, onde o Jenkins open source somado a Kubernetes erodiu gradualmente o valor cobrado pelo Enterprise Jenkins. O risco está em mover o limite: adicionar recursos pagos é fácil; cobrar pelo que era grátis não. O caso MinIO ilustra isso: em maio de 2025, um release removeu o console de administração da edição comunitária, usuários fizeram fork e migraram, e o repositório acabou arquivado em 2026. A lição é definir a linha antes de as pessoas construírem no lado errado.

Cloud gerenciada: a empresa opera o software pelo cliente (Supabase, Grafana Cloud, Temporal Cloud). A instalação raramente é o problema; o valor está em assumir manutenção, backups, atualizações e disponibilidade. Bancos de dados, filas e sistemas de streaming se encaixam bem porque o trabalho cresce com o uso.

Suporte e serviços: vende-se expertise e um compromisso de SLA (Red Hat, Percona, SQLite). Red Hat não vende software, mas uma resposta confiável à pergunta de como a infraestrutura será mantida por uma década. A limitação: se cada cliente exige um atendimento sob medida, crescer receita significa contratar mais gente.

Licenciamento comercial: reúne duas decisões - dupla licença (termos comerciais para quem não pode cumprir as obrigações open source, como Qt e MySQL) e restrições source-available, que tipicamente bloqueiam serviços hospedados concorrentes (Confluent). Precondição: ter direito de relicenciar cada linha, geralmente via CLA. O autor ressalva que os detalhes importam: os termos LGPL da Qt podem permitir aplicações fechadas, e as restrições da Confluent valem só para componentes específicos, com o Kafka permanecendo Apache.

Patrocínio: empresas patrocinam projetos de que dependem (Vue.js, ESLint, webpack), com GitHub Sponsors e Open Collective facilitando o pagamento. Sustenta um projeto, mas não escala para um negócio.

Produtos complementares pagos: venda de algo separado útil a quem já usa o projeto gratuito (Laravel Nova, Tailwind Plus, SQLite Encryption Extension). Não exige time de vendas enterprise e não impõe teto - o negócio da Laravel recebeu investimento de US$ 57 milhões da Accel.

O muro do source-available e os forks

As restrições source-available aparecem quase sempre no mesmo cenário: o projeto é infraestrutura, um provedor de nuvem o oferece como serviço gerenciado, e quem mantém o projeto vende serviço concorrente. MongoDB abriu a sequência em 2018; Confluent seguiu semanas depois; Elastic mudou a licença em 2021 após disputas com AWS; Redis em março de 2024. Em todos os casos, alguém fez fork da última versão aberta: a AWS transformou Elasticsearch em OpenSearch, e oito dias após o anúncio da Redis a Linux Foundation lançou o Valkey, com AWS, Google, Oracle, Ericsson e Snap. HashiCorp ganhou o OpenTofu. Elastic (2024) e Redis (2025) readicionaram licenças open source; a Redis admitiu ter prejudicado a relação com a comunidade, mas ambas afirmam que a mudança cumpriu seu objetivo.

Como escolher e conclusão

Williams propõe quatro perguntas: quem responde quando a ferramenta se espalha (open core vende para essa pessoa, geralmente um líder de plataforma ou engenheiro de segurança); quem fica de plantão pela operação (se o trabalho cresce com o uso, cloud gerenciada e suporte fazem sentido); quem é bloqueado pela licença (dupla licença atinge um grupo pequeno e específico; bloquear concorrentes não gera compra); e o que o usuário precisa em seguida (produto complementar). O modelo escolhido precisa definir quem compra, qual problema tem e por que a versão FOSS não o resolve. E o limite entre grátis e pago tem prazo de validade: precisa ser monitorado e revisitado. A conclusão do autor: open source gera adoção, mas não gera receita - isso precisa ser desenhado.