Como as empresas de código aberto ganham dinheiro

Por Brian Tr · Atualizado em 2 de outubro de 2026

Uma empresa de código aberto distribui de graça seu produto central e ainda precisa pagar salários. Isso soa como uma contradição, e é a primeira pergunta que todo fundador e investidor faz sobre o modelo. A resposta é que o código raramente é o que está sendo vendido. Os clientes pagam pelo que cerca o código: alguém para operá-lo, dar suporte, certificá-lo, estendê-lo ou assumir a responsabilidade legal por ele.

Este artigo explica o que "código aberto" realmente significa, as principais formas de as empresas transformá-lo em receita e a tensão que levou várias empresas conhecidas a mudar suas licenças entre 2021 e 2026. É uma referência sobre o modelo de negócio, não aconselhamento jurídico, e não compara os preços atuais dos fornecedores. Para ver o conjunto mais amplo de formas de as startups ganharem dinheiro, consulte os modelos de precificação de SaaS.

O que "código aberto" realmente significa

"Código aberto" não é um sinônimo solto de "gratuito" ou de "o código é público". A Open Source Initiative (OSI) mantém a Open Source Definition, uma lista de dez critérios que uma licença precisa cumprir. Três importam mais para os modelos de negócio:

• Redistribuição livre. A licença não pode impedir ninguém de vender ou distribuir o software.
• Trabalhos derivados. A licença deve permitir modificações e trabalhos derivados.
• Sem discriminação contra áreas de atuação. A licença não pode impedir ninguém de usar o programa em uma área específica, o que na prática inclui executá-lo comercialmente.

Esse último critério é onde os modelos de negócio colidem com a definição. Uma licença que diz "qualquer um pode usar isto, exceto para vendê-lo como um serviço hospedado concorrente" está restringindo uma área de atuação. Pode ser uma escolha comercial perfeitamente razoável, mas, na leitura da OSI, não é código aberto. A OSI disse exatamente isso sobre a Server Side Public License (SSPL) em um comunicado de janeiro de 2021, chamando de enganosa a prática de descrever esse tipo de software como código aberto.

Então existem, na verdade, dois campos:

O restante deste artigo mantém os dois separados. A distinção importa para os clientes (o que eles têm permissão de fazer?), para os contribuidores (meu trabalho vai continuar aberto?) e para os fundadores (o que posso prometer?).

O paradoxo de distribuir o núcleo

Se qualquer pessoa pode baixar, modificar e executar o produto de graça, por que alguém pagaria? As empresas de código aberto respondem de uma de quatro maneiras:

1. Reduzir o peso. Operar bem o software é difícil. Os clientes pagam para que outra pessoa o opere.
2. Reduzir o risco. As grandes organizações querem um fornecedor a quem recorrer, uma equipe de resposta a incidentes de segurança e uma garantia legal.
3. Acrescentar o que a versão gratuita não tem. Recursos que importam sobretudo para equipes grandes (controles de acesso, logs de auditoria, single sign-on) são vendidos à parte.
4. Proteger o direito de cobrar. Algumas empresas mantêm o código aberto para leitura, mas limitam quem pode revendê-lo.

Distribuir o núcleo também funciona como distribuição de mercado. Os desenvolvedores adotam o que podem experimentar sem um processo de compras, e a empresa que conquista essa adoção ganha um canal de vendas inbound. Isso se aproxima da lógica do product-led growth e dos modelos de negócio freemium, com uma diferença: um usuário gratuito de software de código aberto também pode fazer um fork do código, hospedá-lo por conta própria e nunca se tornar cliente.

Os principais modelos de monetização

1. Suporte e assinaturas (o modelo Red Hat)

O modelo mais antigo vende garantias em torno de software gratuito. A Red Hat é o exemplo clássico. O comunicado de outubro de 2018 da IBM sobre o acordo para adquirir a Red Hat por $190 por ação, um valor da empresa de cerca de $34 bilhões, descreveu a empresa-alvo como uma das principais fornecedoras de software empresarial de código aberto, incluindo tecnologias de Linux, nuvem híbrida, contêineres e Kubernetes.

Pelo que um cliente da Red Hat paga? Seu próprio FAQ de assinatura lista patches, correções de bugs, atualizações e upgrades, suporte técnico com disponibilidade 24/7 e certificações de hardware, software e provedores de nuvem. Ele também afirma que o cliente que deixa a assinatura vencer perde errata de segurança, correções de bugs e suporte técnico. Em outras palavras, o produto é uma versão mantida, certificada e com suporte, não o código-fonte em si.

Onde funciona: software de infraestrutura que grandes organizações executam em produção e não podem se dar ao luxo de ver quebrar. Onde tem dificuldade: as vendas são lentas e pesadas, e o modelo escala com pessoas e confiança, não com downloads.

2. Open core

Em uma empresa de open core, o produto-base é de código aberto e um conjunto de recursos adicionais é proprietário e pago. Os extras costumam ser aquilo que as grandes organizações pedem: segurança avançada, governança, ferramentas de escalabilidade, integrações oficiais e suporte dedicado.

A questão estratégica é onde traçar a linha. Se você coloca pouco na versão gratuita, a comunidade não tem motivo para adotá-la. Se coloca demais, ninguém tem motivo para pagar. Os fundadores costumam usar um teste simples: os recursos que ajudam um desenvolvedor individual continuam gratuitos, e os que ajudam uma organização a se coordenar (permissões, compliance, administração) são pagos.

O risco é a confiança. Quando uma empresa move um recurso do plano gratuito para o pago, a comunidade pode entender isso como traição, e um fork pode surgir.

3. Nuvem gerenciada (serviço hospedado)

A maior parte da receita moderna de código aberto vem de operar o software para os clientes. A empresa o hospeda, cuida de upgrades, backups e escalabilidade, e cobra por uso ou capacidade. É o modelo SaaS aplicado a um produto de código aberto, e a mecânica de preços é tratada em usage-based pricing.

A MongoDB mostra o tamanho que isso pode ter. No comunicado de resultados do ano fiscal de 2026 (ano fiscal encerrado em 31 de janeiro de 2026), a MongoDB reportou receita total de $2,46 bilhões, e seu serviço de nuvem Atlas respondeu por cerca de $1,81 bilhão disso, aproximadamente 73%. É o número de um ano fiscal de uma única empresa, não um parâmetro do setor, e o banco de dados central da MongoDB é source-available, e não de código aberto (mais sobre isso adiante).

Onde funciona: produtos trabalhosos de operar, nos quais a conveniência vale o preço. Onde tem dificuldade: qualquer pessoa com uma conta de nuvem pode oferecer o mesmo serviço, inclusive os maiores provedores de nuvem. Essa é a raiz das disputas de licenciamento descritas adiante.

4. Licenciamento duplo

No licenciamento duplo, o mesmo código é oferecido sob duas licenças. Uma é gratuita, em geral copyleft, e exige que quem constrói sobre ele compartilhe o próprio código-fonte nos mesmos termos. A outra é uma licença comercial paga para empresas que querem embutir o software em um produto fechado sem essa obrigação.

Funciona melhor para bibliotecas e componentes que outras empresas embutem em seus próprios produtos. Funciona mal para aplicativos de usuário final, em que ninguém precisa de uma isenção dos termos de copyleft. Também costuma exigir que a empresa detenha os direitos de relicenciar, e é aí que entram os contratos de contribuidores (veja abaixo).

5. Source-available e mudanças de licença

Um grupo crescente de empresas agora publica o código-fonte sob licenças que restringem o uso comercial, em geral para impedir que concorrentes revendam o produto como serviço hospedado. Exemplos comuns são a SSPL, a Business Source License e licenças no estilo fair-code. Essas licenças deixam os clientes ler, executar e modificar o código, e deixam o fornecedor com o direito exclusivo de vendê-lo como serviço.

Algumas dessas licenças também se convertem em uma licença totalmente aberta após um prazo fixo. É uma forma de prometer abertura no futuro protegendo a vantagem de largada no presente.

6. Doações, patrocínios e fundações

Nem todo projeto de código aberto é uma empresa. Muitos são mantidos por voluntários, financiados por patrocinadores ou abrigados em fundações. A Apache Software Foundation, por exemplo, pede que contribuidores relevantes assinem um contrato individual de licença de contribuidor para que a fundação possa defender o projeto caso surja uma disputa legal sobre o software. As fundações dão aos projetos governança neutra e cobertura jurídica, mas não pagam os fundadores. Empresas comerciais muitas vezes crescem em torno de projetos de fundações e vendem suporte ou hospedagem, o que realimenta os modelos de 1 a 3.

Comparando os modelos

A maioria das empresas reais combina vários. Um produto típico tem um open core gratuito, uma versão hospedada, um plano enterprise e uma opção de suporte.

O problema dos hyperscalers e a onda de mudanças de licença de 2021 a 2026

A nuvem gerenciada é o modelo mais lucrativo e também o mais fácil de um concorrente maior copiar. Se a licença permitir, um provedor de nuvem pode hospedar um banco de dados ou ferramenta de código aberto, cobrar por ele e devolver pouco. Os fornecedores de código aberto chamam isso de "strip-mining" (mineração predatória).

Várias empresas reagiram mudando as licenças. Cada um dos anúncios abaixo vem da própria empresa.

Algumas coisas chamam a atenção quando se leem esses anúncios em conjunto.

Os motivos são consistentes. A Elastic disse que a mudança servia para impedir que provedores oferecessem seu software como serviço sem contribuir. A HashiCorp argumentou que alguns fornecedores se beneficiam do trabalho de código aberto sem contribuir. A Redis disse que a maioria de suas vendas comerciais era canalizada pelos maiores provedores de serviços de nuvem.

Ser honesto sobre o selo importa. A Redis declarou com clareza que suas novas licenças não atendem à definição da OSI e que chamaria a versão gratuita de "Community Edition" em vez de código aberto. A OSI tem a mesma visão sobre a SSPL.

Há reviravoltas. A Elastic e a Redis acrescentaram depois a AGPL, aprovada pela OSI, como opção. A Redis disse que sua mudança anterior tinha prejudicado a relação com a comunidade, e a Elastic disse que sua decisão fora motivada por preocupações com as práticas da Amazon, mas que a situação havia mudado. Para um fundador, a lição não é que uma licença seja a certa. É que mudar de licença é uma decisão de negócio com um custo junto à comunidade que pode durar anos.

Algumas licenças trazem um relógio. A Directus diz que toda versão de seu software se torna totalmente de código aberto sob a GPLv3 após quatro anos, e que, dentro de seus limites, organizações abaixo de $5 milhões de receita anual e 50 funcionários podem usá-la de graça. Uma licença com prazo tenta proteger o fornecedor agora e cumprir a promessa de código aberto depois.

Comunidade versus receita: a tensão central

As empresas comerciais de código aberto vivem um conflito permanente. A comunidade quer software estável, gratuito e com licença permissiva. Investidores e funcionários querem receita que cresça. Cada decisão de monetização muda o equilíbrio.

Alguns pontos práticos de pressão:

• Restrição de recursos. Mover um recurso existente para trás de um paywall quebra uma promessa tácita aos usuários e contribuidores.
• Governança. Se uma só empresa controla o roadmap, os contribuidores externos podem se afastar. Uma fundação dá controle neutro, mas tira parte do controle da empresa.
• Forks. Se uma mudança de licença irrita boa parte da comunidade, pode surgir um fork sob uma licença permissiva. O fork mantém o código antigo e pode atrair os provedores de nuvem que a empresa tentava barrar.
• Marca registrada. Mesmo quando o código é livre para copiar, o nome normalmente não é. A Redis, por exemplo, agora limita o uso de "Redis" em nomes de outros produtos por meio de sua política de marca registrada.

Contratos de licença de contribuidor

Um contrato de licença de contribuidor (CLA) é um documento em que um contribuidor concede ao projeto os direitos de que ele precisa para usar sua contribuição. As fundações os usam por clareza jurídica, como mostra a justificativa do ICLA da Apache Software Foundation.

Para uma empresa, o CLA tem um segundo propósito: possibilita mudar a licença depois ou vender o código sob uma licença comercial, porque a empresa detém os direitos de que precisa. A Redis, por exemplo, disse que exige que os contribuidores aceitem seu CLA antes de considerar as contribuições.

Os contribuidores às vezes veem os CLAs como uma via de mão única. Uma empresa que quer manter a boa vontade da comunidade deve deixar claro por que exige um e o que promete em troca.

O que isso significa para uma startup

Se você está considerando um modelo de negócio de código aberto, vale responder cedo a algumas perguntas.

1. Pelo que os clientes vão pagar se o código é gratuito? Conveniência, redução de risco, recursos ou permissão. Se você não consegue nomear, ainda não tem um modelo de negócio.
2. Quem poderia revender o seu produto? Se a resposta for "qualquer provedor de nuvem", escolha a licença pensando nisso desde o início, porque mudá-la depois é caro.
3. Como você vai conquistar a confiança da comunidade? Decida o que nunca vai mover para trás de um paywall e escreva isso.
4. Você entende a economia? Usuários gratuitos custam dinheiro para atender e dar suporte. Acompanhe os unit economics do segmento pagante, não o total de downloads.
5. Existe um fosso além do código? Marca, expertise de hospedagem, ecossistema e dados podem importar mais que a licença. O artigo sobre fosso econômico trata dessa ideia em detalhe, e os efeitos de rede podem valer quando uma grande comunidade de desenvolvedores torna o produto mais valioso.

As equipes em estágio inicial, em particular, devem comparar esse modelo com outras opções, como os modelos de negócio de plataforma, antes de se comprometer.

As práticas sobre licenciamento e contratos de contribuidores variam por país e por investidor, então os fundadores devem buscar aconselhamento jurídico para a própria situação. Não encontramos uma fonte comparativa confiável sobre práticas de negócios de código aberto especificamente no Sudeste Asiático.

Fatos principais

• A Open Source Definition da OSI tem dez critérios e foi modificada pela última vez em 2007. Um deles proíbe restrições a áreas de atuação.
• A OSI declarou em janeiro de 2021 que a SSPL não é uma licença de código aberto.
• A IBM anunciou em outubro de 2018 que adquiriria a Red Hat por $190 por ação, cerca de $34 bilhões em valor da empresa.
• O FAQ de assinatura da Red Hat lista patches, atualizações, suporte e certificações como o que uma assinatura oferece.
• O serviço Atlas da MongoDB gerou cerca de 73% de sua receita de $2,46 bilhões no ano fiscal de 2026.
• A Elastic passou para a SSPL em janeiro de 2021 e acrescentou a AGPL em agosto de 2024.
• A HashiCorp adotou a BSL 1.1 em agosto de 2023.
• A Redis passou a ser source-available em março de 2024 e acrescentou a AGPLv3 em maio de 2025.
• A NocoDB e a Directus passaram ambas a licenças source-available em 2026.
• Uma licença source-available não é código aberto segundo a OSI, mesmo quando o código é público.

Leitura relacionada

• Modelos de negócio freemium
• Product-led growth
• Fosso econômico
• Modelos de negócio de startups de hardware
• Modelos de precificação de SaaS
• Modelo de negócio de plataforma