Open core

Open core, código aberto e freemium são três linhas diferentes

Esses termos são usados como sinônimos e cortam em eixos diferentes. Vale ser preciso, porque a diferença decide o que acontece com você se o fornecedor mudar de ideia.

• Código aberto é um fato de licenciamento sobre o código: a licença concede o direito de executar, estudar, modificar e redistribuir. Não diz nada sobre quem paga o quê.
• Open core é uma decisão de empacotamento em cima disso: parte do produto tem licença aberta e parte simplesmente não existe em público. A metade proprietária costuma ser o serviço hospedado, o login único, os registros de auditoria, as permissões e aquilo que os maiores clientes pedem.
• [Freemium](/glossary/freemium) é uma decisão de preço dentro de um único produto proprietário: um plano gratuito e planos pagos do mesmo software fechado. Nada é aberto e auto-hospedar não está em jogo.
• [Preço por uso](/glossary/usage-based-pricing) é ortogonal aos três — descreve como a conta é calculada, não o que você tem permissão de fazer com o código.

Um teste útil: no freemium, bater no teto significa que você faz upgrade. No open core, bater no teto significa que você faz upgrade ou constrói você mesmo a peça que falta, porque tem o resto do sistema nas mãos. Essa segunda opção é todo o valor do modelo para quem adota, e ela é real com mais frequência do que se imagina.

Lendo um repositório para ver onde a linha realmente cai

Escrevemos com regularidade sobre ferramentas de crescimento de código aberto nas nossas páginas /grow, e depois de mais de sessenta delas o padrão é constante o bastante para virar checklist. O que o selo afirma e onde fica o paywall são fatos separados, e o segundo é o que decide se a ferramenta resolve o seu problema. Procure por isto antes de adotar qualquer coisa:

• Abra o arquivo LICENSE, não o selo. O próprio campo de licença do GitHub mostra `NOASSERTION` quando ele não consegue classificar o que encontrou, e alguns repositórios com selo de licença não têm texto de licença nenhum. Isso sozinho não é prova cabal, mas é o único campo em que você não pode se dar ao luxo de adivinhar.
• Procure a nota de rodapé que diz somente na nuvem. O formato mais comum é uma lista de recursos no README em que uma ou duas entradas trazem uma observação discreta de que estão disponíveis no plano hospedado. Se essa entrada é o motivo pelo qual você ia adotar a ferramenta, você já leu a história inteira.
• Leia a tabela comparativa que o próprio projeto publica. É marketing, então trate as colunas dos concorrentes com desconfiança, mas a coluna que descreve o próprio produto costuma ser precisa e revela o que os mantenedores acham que estão vendendo.
• Veja quais plugins ou módulos são marcados como núcleo. Um projeto que marca certos recursos como núcleo e outros como opcionais já traçou a linha em público, e isso é bem mais confiável do que uma página de preços.
• Confira quem detém o copyright e se há acordo de contribuição. Uma única empresa detentora do copyright pode relicenciar depois; uma fundação ou uma base ampla de contribuidores torna isso consideravelmente mais difícil. É esse campo que prevê o que acontece daqui a três anos.

O docmd, um compilador de documentação que analisamos em 3 de setembro de 2026, é um exemplo pequeno e limpo do formato feito de modo legível: o compilador e todas as suas saídas de build são MIT no repositório, e a única peça hospedada — um relay que permite a um site puramente estático rodar o assistente de IA sem operar um backend — está claramente marcada como o serviço opcional. Em um minuto dá para saber o que você auto-hospedaria e o que compraria, o que não vale para todos os projetos da categoria.

O que isso significa se você adota, e se você constrói

Como quem adota, a pergunta honesta não é se a ferramenta é aberta, é quanto custa a sua saída. Auto-hospedar é grátis em termos de licença e não é grátis em horas: alguém cuida das atualizações, dos backups e da queda. Compare isso com o plano hospedado no tamanho que você espera ter daqui a um ano, não no tamanho de agora. Ainda assim, o que você compra com essas horas é real: seus dados ficam num banco que você controla e, se o roteiro do fornecedor se afastar de você, sobra um sistema funcionando em vez de uma migração.

Como fundador avaliando o modelo para o próprio produto, é preciso enxergar com clareza que open core é uma estratégia de distribuição antes de ser de receita. Ele compra alcance, credibilidade com quem desenvolve e um fluxo de contribuições; não produz clientes sozinho e restringe você depois, porque mover um recurso do lado aberto para o lado pago é uma das poucas decisões que custam a boa vontade de um projeto de forma confiável. Decida a linha antes de o repositório ficar público e escreva isso onde as pessoas usuárias possam ler.

Ele também não elimina nada do trabalho de ser encontrado. Um repositório aberto é um canal de distribuição com o mesmo problema de todos os outros — alguém precisa ficar sabendo. É por isso que os projetos que vencem nesse modelo costumam ser os que fazem o trabalho comum de conteúdo e comunidade ao lado da engenharia, e não os que supuseram que a licença faria o marketing.