Modelo de negócio open source: por que abrir o código

A equipe de infraestrutura escolheu a ferramenta num sábado. Baixou, subiu num contêiner, testou contra dados reais e já sabia se servia antes de segunda-feira. Não falou com vendedor, não assinou termo de confidencialidade, não pediu ambiente de demonstração.

Três meses depois a empresa assinou um contrato anual com a mesma fornecedora, agora pela versão gerenciada, com suporte e controle de acesso corporativo.

Essa sequência não é acidente. É o desenho comercial inteiro, e é por isso que vale entender o modelo de negócio open source antes de tratar código aberto como gesto de generosidade.

Abrir o código raramente é filantropia. É distribuição: o repositório tira o atrito da avaliação, dispensa vendedor no começo do funil e vira canal, enquanto a receita fica no que é chato de manter sozinho.

Por que abrir o código funciona como distribuição

Vender software corporativo pelo caminho tradicional é caro. Alguém precisa prospectar, qualificar, apresentar, montar prova de conceito e negociar. O custo de aquisição sobe antes de o cliente saber se a ferramenta resolve o problema.

Um repositório público corta esse trecho. O desenvolvedor encontra o projeto numa busca, lê o código, roda localmente e decide sozinho. Todo modelo de negócio open source aposta nisso: a avaliação acontece sem custo de venda, e a empresa só entra na conversa quando o projeto já está em uso.

Isso muda o funil. A primeira conversa comercial começa em "já rodamos isso há dois meses e precisamos de suporte". O desenho lembra o de um plano gratuito bem construído, com uma diferença: no código aberto o usuário pode continuar para sempre sem pagar, e isso é parte do acordo, não uma falha.

Quem adota cedo ainda escreve integração, plugin e tutorial. Esse trabalho reduz o custo de engenharia da empresa e cria documentação que nenhum time de marketing produziria no mesmo volume.

O modelo de negócio open source começa no gargalo, não no código

O ponto de cobrança aparece quando o projeto sai da máquina do desenvolvedor e vai para produção. Aí surgem perguntas que o código sozinho não responde. Quem opera o banco às três da manhã, quem garante atualização de segurança, quem assume responsabilidade contratual se o serviço cair.

O modelo de negócio open source cobra de cinco formas, e a maioria das empresas usa duas ou três ao mesmo tempo.

Nuvem gerenciada. A empresa hospeda o próprio projeto e vende o trabalho de operar: backup, escala, atualização, observabilidade. É o modelo com maior margem e o mais difícil de copiar, porque depende de operação, não de propriedade intelectual. O texto sobre IaaS, PaaS e SaaS organiza essas camadas.

API cobrada por chamada. O código do modelo ou do motor está aberto, mas a inferência num endereço estável, com latência previsível e hardware que você não precisa comprar, é paga. É o formato dominante entre as empresas de IA que publicam pesos, tema tratado em alternativas de IA open source.

Suporte com acordo de nível de serviço. O software é o mesmo para todo mundo. O que você compra é tempo de resposta contratado, escalonamento e alguém nomeado para atender.

Open core. O núcleo fica aberto e os recursos que só uma empresa grande precisa ficam fechados: login único, trilha de auditoria, controle de acesso por papel, multi-tenant, retenção longa. O critério de corte é o mesmo: o que o time de conformidade exige entra na versão paga.

Certificação e treinamento. Receita menor, mas constante, e serve de barreira: profissional certificado empurra a ferramenta dentro da empresa onde trabalha.

As licenças por trás de cada modelo de negócio open source

A licença não é detalhe jurídico. Ela define quem pode fazer dinheiro com o código e quem fica de fora, e por isso muda conforme a empresa aperta ou afrouxa a defesa.

A AGPL v3 é a peça mais interessante do conjunto. A seção 13 exige que quem modifica o programa e o oferece a usuários por rede ofereça a esses usuários o código correspondente. Isso fecha a brecha que a GPL comum deixava para software em servidor. Ela é aprovada pela Open Source Initiative desde 2008, e por isso sustenta um modelo de negócio open source com defesa comercial e rótulo de código aberto ao mesmo tempo.

BSL e SSPL jogam outro jogo. O código fica publicado, qualquer pessoa lê e usa, mas oferecê-lo como serviço concorrente é proibido. A Open Source Definition exige liberdade de uso para qualquer finalidade, então essas licenças não recebem aprovação da OSI. O termo correto é source available. Para comparar o que cada família permite vender, veja licenças open source e o que você pode vender.

O conflito com o provedor de nuvem

A tensão tem nome e endereço. Uma empresa pequena mantém o projeto, paga os desenvolvedores e carrega o roteiro. Um provedor de nuvem grande pega o mesmo código, oferece como serviço gerenciado dentro do próprio catálogo e captura a receita de operação sem dividir custo de desenvolvimento.

Três casos documentados mostram como isso terminou.

A HashiCorp anunciou em 10 de agosto de 2023 a troca da Mozilla Public License 2.0 pela Business Source License 1.1 em praticamente toda a linha de produtos. O anúncio oficial afirma que o código aberto reduziu a barreira para copiar inovação e vendê-la por canais de distribuição já existentes. O texto cita fornecedores que se aproveitam do modelo sem contribuição material de volta. A licença permite uso comercial e não comercial, exceto quando a oferta compete com a HashiCorp.

A Elastic trocou de licença em 2021 e voltou atrás. Em 29 de agosto de 2024, a empresa anunciou a adição da AGPL ao Elasticsearch. Shay Banon escreve que a mudança anterior nasceu de problemas com a AWS e de confusão de mercado, e que a decisão funcionou. Ele acrescenta que a Amazon investiu no próprio fork e que a parceria com a AWS está mais forte do que nunca.

O Redis percorreu caminho parecido. Em 1º de maio de 2025, a empresa anunciou a AGPLv3 como opção de licença no Redis 8. O texto reconhece que a mudança para SSPL, feita em março de 2024, protegeu a inovação contra os forks mantidos por AWS e Google. A empresa admite que a decisão prejudicou a relação com a comunidade. O texto lembra que a OSI esclareceu que a SSPL não atende aos requisitos de uma licença aprovada.

O padrão se repete em todo modelo de negócio open source que sofre essa pressão: aperta a licença para conter o provedor de nuvem, perde parte da comunidade, depois recalibra.

O que muda para quem compra

Do lado do cliente, o modelo de negócio open source funciona como promessa de saída. Ela é real, mas condicionada, e vale checar três coisas antes de assinar.

Dependência. Se você usa a nuvem gerenciada, o código aberto não garante portabilidade. O formato de dado, o painel, as integrações e a automação podem ser específicos do serviço. A pergunta útil é se existe caminho testado para rodar aquilo na sua própria infraestrutura.

Saída. Fork é direito, não plano. Manter um fork exige gente que entenda o código, capacidade de aplicar correção de segurança e disposição de carregar isso por anos. Poucas empresas têm isso, e nenhuma descobre no meio de uma migração de emergência.

Mudança de licença. Se uma única empresa detém o copyright, ou se os contribuidores assinam cessão de direitos, ela pode relicenciar as versões futuras sem pedir autorização a ninguém. O que você já baixou continua sob a licença antiga, mas as correções que vierem depois vão para a nova. Projeto sob fundação neutra ou com copyright distribuído entre muitos autores torna a manobra mais difícil.

Essas três perguntas cabem na planilha em que você já compara propostas, com uma coluna a mais: o custo de sair.

Como avaliar um fornecedor open source antes de assinar

1. Leia a licença do que você vai usar em produção, não a do repositório principal. Muitas empresas mantêm SDK e bibliotecas sob licença permissiva e o produto sob outra.
2. Descubra quem detém o copyright. Procure o acordo de cessão de direitos dos contribuidores no repositório. Se existe e aponta para uma empresa só, relicenciamento futuro é possível.
3. Separe núcleo de módulo pago. Liste quais recursos você vai precisar em doze meses e confira em qual lado da linha cada um está hoje.
4. Teste a instalação própria uma vez. Suba a versão aberta num ambiente de teste com dados reais e cronometre. Esse número é o seu custo de saída.
5. Verifique o histórico de licença do projeto. Num modelo de negócio open source, duas trocas em três anos dizem mais sobre risco futuro do que qualquer cláusula de contrato.
6. Negocie a permanência do preço por mais de um ciclo. Quem já mudou de licença também muda de tabela.

Para quem está do outro lado e monta o produto, a ordem é a mesma de qualquer lançamento: primeiro o MVP que prova o uso, depois a decisão de licença, nunca o contrário.

O ponto que fica

O modelo de negócio open source é um arranjo de distribuição com cobrança deslocada para a operação. Funciona bem quando o gargalo real é operar, e trava quando o gargalo é o próprio código, porque aí o concorrente também o tem.

Quem compra deveria tratar a licença como cláusula contratual, com data e versão anotadas. Em agosto de 2023 a HashiCorp trocou a MPL 2.0 pela BSL 1.1; em agosto de 2024 a Elastic adicionou a AGPL ao Elasticsearch; em maio de 2025 o Redis fez o mesmo no Redis 8. Nos três casos, a decisão foi de uma empresa, anunciada num post de blog.