O Financiamento do Open Source Tornou-se Ideológico. A Sua Stack Não Teve Direito de Voto
O dinheiro que mantém viva a camada de software mais básica do seu negócio vem cada vez mais associado a uma visão do mundo. Isso transforma o financiamento num mecanismo de fork, e 'em que ramo estou?' numa pergunta que o seu mapa de riscos nunca chegou a fazer.
O pressuposto mais perigoso na sua stack é que as partes maçadoras estão resolvidas. Nos últimos três anos, a camada de cache, o índice de pesquisa e a ferramenta de infraestrutura como código, componentes em que empresas inteiras assentaram precisamente porque pareciam permanentes, dividiram-se cada um em ramos rivais, financiados separadamente. O financiamento do open source costumava ser demasiado enfadonho para se questionar. Agora decide qual o ramo da sua própria plataforma que sobrevive, e ninguém enviou o memorando à sua equipa de compras.
Comecemos pela camada de infraestrutura. Em agosto de 2023, a HashiCorp migrou o Terraform e as suas outras ferramentas principais da licença aberta Mozilla Public License para a Business Source License, que proíbe concorrentes de as usar em produção. Dias depois, empresas cujos produtos dependem do Terraform publicaram o manifesto do OpenTofu, e em setembro o fork já tinha casa na Linux Foundation, com os seus apoiantes a comprometerem-se a financiar engenheiros a tempo inteiro durante pelo menos cinco anos. A licença do Terraform e a comunidade do Terraform vivem agora em edifícios diferentes.
A camada de cache repetiu a mesma jogada, mais depressa. Em março de 2024, a Redis abandonou a licença permissiva BSD que mantinha desde o seu primeiro lançamento, a favor de termos duplos de código disponível (source-available). Dias depois, a Linux Foundation anunciou o Valkey, um fork da última versão BSD, com a AWS, a Google Cloud e a Oracle entre os seus apoiantes. Catorze meses depois, o Redis 8 voltou a incluir a AGPLv3, uma licença aberta aprovada pela OSI, entre as suas opções.
O índice de pesquisa percorreu primeiro o arco completo. A Elastic relicenciou o Elasticsearch e o Kibana, afastando-os da Apache 2.0, em janeiro de 2021, um movimento dirigido diretamente à AWS. A AWS respondeu criando um fork de ambos sob o nome OpenSearch, hoje alojado na sua própria fundação, sob o chapéu da Linux Foundation. Em agosto de 2024, a Elastic acrescentou a AGPLv3 e declarou que o Elasticsearch voltou a ser open source.
Os recuos são o sinal a reter. Já por duas vezes um original relicenciado restaurou uma licença aberta depois de o seu fork ter encontrado dinheiro institucional. Nenhuma das empresas descreve a sequência como uma capitulação, e a ligação causal é uma inferência deste órgão de informação, não algo constante de qualquer documento oficial. Mas se os forks financiados não estivessem a funcionar como alavanca, é difícil perceber para que serviram esses recuos.
De onde vem, afinal, o dinheiro do open source hoje em dia?
A resposta antiga ainda cobre a maior parte do dinheiro: fornecedores que empregam mantenedores e fundações que juntam subscrições empresariais, ambos a recompensar, em termos gerais, a relevância comercial. O dinheiro mais recente não é uma coisa só. Pelo menos três motivações distintas passaram a emitir cheques, e cada uma quer um mundo diferente.
Primeiro, o dinheiro de consórcio defensivo: empresas que financiam um fork porque os seus próprios produtos dependem de termos que o original abandonou. É isso que representa a lista de apoiantes do Valkey, e são esses os compromissos de engenharia a cinco anos do OpenTofu. Aqui não é preciso qualquer inferência: os próprios anúncios das fundações declaram o motivo sem rodeios. Os financiadores estão a proteger o seu fornecimento.
Segundo, os programas estatais de soberania. A Sovereign Tech Agency alemã, financiada através do ministério federal da Economia, paga pela manutenção de componentes que praticamente mais ninguém financiaria. O seu portefólio de investimento publicado indicava, no início de 2025, mais de 23 milhões de euros comprometidos em mais de 60 tecnologias fundacionais desde o início do financiamento, no final de 2022, entre elas o curl e o WireGuard, explicitamente em nome da soberania digital europeia. Uma classe de financiadores que não existia há cinco anos está agora a divulgar despesas de oito dígitos.
Terceiro, o mecenato de valores, mais antigo do que os dois anteriores e, em regra, mais pequeno. A Devuan mantém um fork do Debian sem systemd desde que o comité técnico do Debian adotou o systemd em 2014, sustentado pelas doações que solicita precisamente para preservar essa independência. O XLibre criou, em junho de 2025, um fork do servidor gráfico X.Org, apresentando-se junto de voluntários e mecenas como refúgio da governação a montante (upstream). E os GNU coreutils, licenciados sob GPL e geridos no âmbito do projeto GNU desde o início da década de 1990, competem hoje com o uutils, uma reescrita em Rust sob licença MIT, iniciada em 2013 e hoje liderada por Sylvestre Ledru, que o Ubuntu 25.10 passou a incluir por omissão em outubro passado. Se quem paga por estes projetos está a comprar dissidência de governação ou simplesmente o software que prefere, não existe nenhum inquérito a doadores que o diga; os seus próprios apelos assentam em princípios, e este órgão de informação lê o dinheiro nesse sentido, como inferência e não como registo factual.
Repare no que as três classes não partilham: um futuro preferido. O dinheiro de consórcio quer continuidade de termos. O dinheiro de soberania quer componentes partilhados, menos numerosos e melhor mantidos. O dinheiro de mecenato existe para manter viva a dissidência. Puxam em direções incompatíveis, cada um pronto a financiar o seu próprio rumo indefinidamente, e falar de 'financiamento do open source' como se fosse um único fluxo é exatamente a forma como o risco se esconde.
Porque é que os projetos relicenciados continuam a sofrer forks?
Porque os forks já não passam fome. Quando o dinheiro seguia o mérito comercial, o lado perdedor de um cisma normalmente não tinha recursos para persistir, e os conflitos resolviam-se. Agora, um fork credível pode encontrar um mecenas cujo interesse é a simples existência do fork, seja esse mecenas uma hiperescala a proteger um serviço gerido, seja uma base de doadores a pagar por independência. A Devuan demonstrou, ao longo de mais de uma década, a durabilidade do pequeno mecenato; o Valkey demonstrou a velocidade do grande mecenato em duas semanas. A viabilidade de um fork costumava ser uma questão de capacidade de engenharia. Pela leitura que este órgão de informação faz dos casos acima, está a tornar-se uma questão de quem está disposto a pagar, e porquê.
O que produz uma questão de continuidade que praticamente nenhuma lista de due diligence contém: em que ramo financiado deste componente é que realmente estamos, quem o financia, e o ramo rival continua a receber atenção de segurança? Provavelmente não escolheu o seu ramo. Foi a sua distribuição ou o seu fornecedor de cloud que o escolheu por si, e eles mudam de lado: a troca de coreutils no Ubuntu chegou num anúncio de versão, não no seu registo de alterações.
O que deve a sua due diligence perguntar agora?
Trate o ramo financiado, não o nome do projeto, como a unidade de análise. Para cada componente estrutural: em que ramo estamos, e por decisão de quem? Quem o financia, e o que quer em troca? O que acontece se o principal mecenas se afastar, ou se a licença voltar a mudar? As correções de segurança circulam entre ramos, e com que rapidez? E quanto custaria migrar para o ramo irmão se o nosso lado do fork ficar a perder?
Nada disto aparece numa lista de materiais de software (software bill of materials), que regista o que está a correr, mas não quem paga para que continue a existir. Mapear isto é trabalho de dependências pouco glamoroso: exatamente aquilo que uma estratégia técnica deliberada existe para revelar antes de se tornar um incidente, e algo que uma revisão independente alcança mais depressa do que uma equipa interna que sempre assumiu que a camada de base era problema de outra pessoa.
Os bens comuns em que o seu negócio assenta continuam lá. Só que já não são uma coisa só, e quem paga pelas suas peças já não quer o mesmo futuro. Descubra que futuro está a financiar por defeito. Depois, decida se é isso mesmo que quer.
Perguntas frequentes
Como posso descobrir quem financia um projeto open source de que a minha empresa depende?
Comece pela própria página de governação do projeto, pela sua filiação numa fundação e por qualquer lista de patrocinadores publicada, depois veja quem emprega os mantenedores mais ativos, já que o emprego é a forma mais discreta de financiamento. Se estas respostas forem difíceis de encontrar, essa própria opacidade deve entrar no seu mapa de riscos.
É arriscado depender de um fork de um projeto open source?
Não é arriscado por natureza. Um fork com financiamento sustentado, vários mantenedores ativos e um processo de segurança a funcionar pode ser mais seguro do que um original negligenciado. O verdadeiro risco está nos períodos de transição, quando as correções chegam a um ramo e demoram a chegar ao outro, ou nunca chegam, por isso avalie cada ramo pela sua evidência operacional e não por que lado do argumento ocupa.
A minha empresa deve financiar o software open source que utiliza?
Se a falha de um componente pudesse parar o seu produto, pagar aos seus mantenedores não é caridade, é um seguro barato. Uma pequena fatia da receita canalizada a montante compra aviso antecipado, influência e boa vontade. Só que, no clima atual, o seu dinheiro é também um voto num modelo de governação, quer o pretenda quer não.
Relacionado
- Epic vs. Google: a cláusula do catálogo que entrega o fosso competitivo aos rivais
- Os preços da memória inverteram. Renegoceie o contrato de fornecimento antes da próxima renovação.
- Como a IA Deixa Chefes Ruins Ainda Piores: a Máquina de Bajulação na Sala da Diretoria
- Digital Business
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.