Alternativas open source a SaaS pago: a lista honesta

A lista chega pronta, quase sempre no mesmo formato: uma coluna com o produto pago, outra com o substituto gratuito, um logo bonito e a promessa de economia anual. Ninguém pergunta o que acontece depois do docker compose up.

Eu abri as páginas de sete projetos que aparecem nessas listas de alternativas open source e anotei o que elas nunca trazem: o nome da licença, a data do último release e a função que o produto pago tem e o projeto aberto não tem. A consulta foi em 23 de setembro de 2026, direto no GitHub e no site oficial de cada um.

O resultado é menos animador e muito mais útil. Alternativas open source existem e funcionam, só que a decisão de trocar depende de três informações que a lista bonita omite de propósito, porque elas estragam a manchete.

Trocar SaaS pago por projeto aberto não é uma comparação de preço, é uma transferência de trabalho: você deixa de pagar mensalidade e passa a pagar hospedagem, backup, atualização, autenticação e o tempo da pessoa que opera isso tudo.

O que as listas de alternativas open source deixam de fora

Uma lista de alternativas open source responde a uma pergunta fácil, "o que substitui isso?", e ignora as quatro difíceis.

A primeira é a licença. Muita gente trata "open source" como sinônimo de "livre para qualquer coisa", e não é. Existe diferença prática entre MIT, GPL, AGPL e os modelos chamados de fair-code, que permitem ver o código e limitam o uso comercial. Essa diferença decide se você pode revender, se pode modificar sem publicar e se pode incluir a ferramenta num produto seu. O assunto tem detalhe suficiente para um texto próprio sobre o que cada licença open source permite vender.

A segunda é a manutenção. Um repositório parado há dois anos continua no ar, continua com estrelas e continua aparecendo em lista. Ele só não recebe correção de segurança.

A terceira é quem mantém. Empresa com faturamento, fundação, ou uma pessoa que faz isso no tempo livre. As três situações são legítimas e têm riscos diferentes.

A quarta é a lacuna. Todo substituto tem uma função que o produto pago entrega e ele não. Às vezes é relatório, às vezes é integração, às vezes é suporte com telefone. A lista nunca diz qual é.

Licença das alternativas open source: AGPL, GPL e o que fair-code faz com o seu plano

Vale separar três famílias antes de olhar projeto.

MIT é permissiva. Você usa, modifica, embute no seu produto e vende, sem obrigação de publicar nada. Chatwoot está nessa faixa.

GPL e AGPL são recíprocas. Elas exigem que modificações distribuídas voltem para a comunidade. A AGPL fecha a brecha da nuvem: se você oferece o software modificado como serviço pela rede, precisa disponibilizar o código. Para uso interno da sua equipe, nenhuma das duas atrapalha. Para quem pretende revender hospedagem daquilo, a leitura do texto deixa de ser opcional.

Fair-code é outra coisa. O n8n publica o código sob a Sustainable Use License, que autoriza uso interno e uso não comercial e restringe o resto, além de manter arquivos marcados como .ee sob licença enterprise separada. Está escrito no arquivo de licença do repositório. Isso não desqualifica a ferramenta, que é excelente, e explica bem o que ela é em o que é o n8n. Só significa que chamar aquilo de open source numa proposta comercial é impreciso.

As sete substituições que consegui conferir na fonte

Abri a página de cada uma das alternativas open source em 23 de setembro de 2026. Quem não abriu, ficou de fora.

Falta o sétimo, que é o caso mais interessante. O Nextcloud substitui Google Drive e Dropbox, está sob AGPLv3, e a versão 35.0.0 saiu em 15 de setembro de 2026. A lacuna dele não é função, é desempenho previsível: sincronização de muitos arquivos pequenos depende de banco, cache e disco bem ajustados, e essa é a parte que ninguém coloca na lista.

Sobre o Matomo e o Metabase, o dado de licença está na própria página dos repositórios, matomo-org/matomo e metabase/metabase. O Vaultwarden avisa no próprio repositório que não tem associação com a Bitwarden, Inc. e pede que problemas não sejam levados ao suporte oficial. Quem compara CRM aberto com CRM pago encontra mais nomes e critérios no guia de CRM open source.

A conta que a lista não faz

Cancelar uma assinatura de 300 reais por mês e instalar uma das alternativas open source em um servidor de 60 reais parece economia de 240. A conta real tem mais linhas.

Hospedagem é a menor delas. Depois vem backup, e backup só conta quando você já restaurou uma vez e viu o sistema voltar. Vem certificado e domínio. Vem autenticação, porque a instalação padrão de quase todo projeto nasce com login e senha simples, e ninguém deveria deixar CRM ou cofre de senha assim. Vem atualização, que no caso de projetos ativos significa uma janela por mês, com leitura de changelog e risco de quebra.

E vem o item que decide tudo: o tempo de quem opera. Se a pessoa que vai cuidar disso é a mesma que fecha o mês fiscal, o custo aparece em outro lugar do seu orçamento, com outro nome. Vale a mesma advertência que se aplica aos serviços de nuvem gratuitos: o plano zero real cobra em atenção.

Empacotar tudo em contêiner reduz o atrito de instalação e não elimina nenhum desses itens. Ajuda a padronizar, e o assunto está em o que é Docker.

Estrela no GitHub não mede qualidade nem manutenção

Estrela é marcador de leitura. Ela sobe quando alguém acha o projeto interessante e nunca desce quando o projeto para. Um repositório com 40 mil estrelas e nenhum commit desde 2024 continua com 40 mil estrelas.

Os sinais que separam as alternativas open source vivas das paradas são outros, e todos ficam a dois cliques:

• Data do último release, não do último commit qualquer. Commit de tradução não é manutenção.
• Quantidade de pessoas diferentes assinando commits nos últimos três meses. Um autor só é risco de ônibus.
• Issues de segurança abertas e há quanto tempo. Aberta há um ano diz mais que o README inteiro.
• Existência de política de versão. Projeto que numera e data release trata compatibilidade como problema.

Quando não vale substituir

Existem quatro situações em que a resposta honesta é continuar pagando.

Quando o sistema guarda dado regulado e você não tem quem responda por controle de acesso, registro e retenção. Quando a equipe não tem uma pessoa com responsabilidade formal por servidor, e a manutenção vira favor. Quando a assinatura custa menos que duas horas mensais da pessoa que faria a manutenção. E quando a função que sustenta o processo está justamente na lacuna do projeto aberto, como permissão por linha num BI ou relatório que a diretoria já usa.

Nesses casos, pagar é a decisão barata. Trocar para provar um ponto sai caro em dezembro, quando o servidor cai e a pessoa que sabia está de férias.

Como testar antes de migrar

1. Abra o arquivo LICENSE do repositório e anote o nome exato da licença. Não confie no que a lista disse.
2. Veja a data do último release e quantos autores diferentes commitaram nos últimos três meses.
3. Escreva a lacuna em uma frase. O que o pago faz e este não faz. Se você não consegue escrever, ainda não pesquisou o suficiente.
4. Suba em ambiente de teste com dado real anonimizado, não com o exemplo do tutorial.
5. Faça um backup e restaure ele em outra máquina. Migração sem restauração testada é aposta.
6. Rode uma janela de atualização antes de migrar em produção. Você vai descobrir ali se aguenta a cadência do projeto.
7. Some o custo mensal com o tempo de operação e compare com a assinatura. Decida com esse número na frente.

Quem faz esses sete passos costuma migrar duas ou três ferramentas e manter o resto pago, o que é um resultado bom. Das sete alternativas open source que eu conferi, seis tiveram release nos últimos noventa dias e nenhuma delas entrega, na versão gratuita, tudo o que a versão paga do concorrente entrega.