A Utopia FOSS e a Distância da Realidade

Todos os excelentes projetos de código aberto que vi e usei são desenvolvidos por grandes empresas/organizações ou têm mais de noventa por cento do seu código escrito por um único desenvolvedor de alto nível. Esses projetos, em vez de serem verdadeiramente de código aberto, são na verdade mais como "código-fonte público", porque é difícil para pessoas externas se envolverem no processo de desenvolvimento principal. No antagonismo entre "Catedral" e "Bazar", esses projetos obviamente tendem mais para o lado da "Catedral", embora usem a pele do "código aberto".

Os projetos de código aberto que vi que absorvem amplamente desenvolvedores externos, projetos em que a maioria das pessoas pode se envolver no processo de desenvolvimento, são universalmente desastres de nível "caixote de lixo em chamas". Esses são os verdadeiros "código aberto", e no antagonismo entre "Catedral" e "Bazar", eles obviamente pertencem ao lado do "Bazar".

Com as experiências acima, é difícil não ter uma opinião sobre a prática do modelo "Bazar". O estado atual da indústria de software provou que o modelo "Bazar" não é adequado para a maioria dos projetos de software.

Pergunte a si mesmo, quantos forks de projetos de código aberto você manteve? Seu fork consegue acompanhar o progresso upstream?

A maioria dos projetos forkeados mantidos por indivíduos/pequenas organizações se torna uma ruína após um pequeno período de commits intensos:

Mesmo para grandes forks resultantes de divergências de opinião, mantidos por alguns membros da equipe de desenvolvimento original, muitas vezes é difícil mantê-los. A evidência é óbvia: não há muitos softwares no mercado que, após um grande fork, conseguiram manter o desenvolvimento paralelo— não demora muito para que um lado saia vitorioso. Os poucos grandes forks que conseguem manter o desenvolvimento paralelo ou têm um upstream que é um projeto maduro que quase não adiciona novas funcionalidades, ou se desvincularam completamente da dependência do upstream.

Há uma diferença abismal no nível de conhecimento do projeto entre os principais mantenedores do projeto e os "estranhos aleatórios da internet": Para escrever "código correto" ou código de nível de "programação estratégica", estes últimos precisam gastar muito tempo e esforço para aprimorar seu conhecimento do projeto. Infelizmente, a maioria dos contribuidores não possui esse nível de espírito de código aberto ou condições objetivas.

Os mantenedores de projetos de código aberto precisam revisar os pull requests enviados por "estranhos aleatórios da internet" e, com alta probabilidade, descobrir que a maioria dos pull requests não pode ser mesclada diretamente. Quanto mais fácil um projeto atrair desenvolvedores de baixo nível, mais provável será que ele encontre esse tipo de pull request. Seja guiando os contribuidores externos a reescrever o código para que ele possa ser mesclado, ou os mantenedores reescrevendo o código pessoalmente, ambos exigem tempo e energia. Os ciclos de comunicação e feedback construídos sobre a filosofia do código aberto geralmente são extremamente ineficientes, a ponto de, muitas vezes, não compensarem o esforço investido, e os mantenedores deveriam gastar seu tempo em lugares mais eficientes.

É um fenômeno comum a existência de diferenças entre os objetivos dos contribuidores externos e os da equipe de desenvolvimento, e muitos projetos, portanto, não precisam de contribuições externas no nível de funcionalidade.

Para as funcionalidades que a equipe de desenvolvimento realmente se importa, a implementação oficial é frequentemente rápida e boa. Para as funcionalidades que eles realmente não se importam, as solicitações de funcionalidades são fechadas por um bot após um período de silêncio, e os pull requests caem em um buraco negro. Ou, pior, uma implementação apressada é mesclada, tornando-se uma vulnerabilidade de segurança no software, retornando em versões subsequentes após múltiplas tentativas de correção, para finalmente não escapar do destino de ser excluída.

Como manter a elegância ao manter projetos de código aberto? Melhor resposta: Eu não sei.

Linus Torvalds, o líder de projetos de código aberto mais influente, provavelmente também não sabe. Considerando que os projetos que ele gerencia têm um limiar de entrada bastante alto, a ponto de pequenas figuras como eu nem sequer pensarem em contribuir, a capacidade necessária para desempenhar suas funções é inimaginável para pessoas comuns. Mesmo nesses projetos de alto limiar, onde as informações chegam aos olhos de Linus após múltiplas camadas de filtragem, Linus às vezes age de forma dura e cruel, usando sarcasmo e insultos extremos ao criticar— esse fenômeno é tão grave que apreciar esses desabafos emocionais se tornou uma espécie de prazer. Uma proporção considerável de desenvolvedores vê o emocionalismo de Linus de forma positiva, e até o considera uma parte importante da boa reputação de Linus (em parte porque essas informações têm maior potencial de propagação), porque um mundo sem ditadores técnicos como Linus é bastante fácil de imaginar: não teríamos a qualidade de software que temos agora, e tudo seria pior do que é atualmente. Para aqueles que não são gerentes, a situação é semelhante: a comunidade de código aberto não é um grupo de elogios, e as formas de comunicação mais eficientes são frequentemente tóxicas.

Existem, de fato, alguns super-humanos no mundo que conseguem manter a calma em todas as situações e lidar com tudo de forma suave, o que atribuo a talento ou medicação. Porque se essa capacidade pudesse ser ensinada, ou pelo menos adquirida através de prática, então já teria sido amplamente promovida, afinal, muitas pessoas no mundo deveriam querer essa capacidade de controle emocional. Ao mesmo tempo, deve-se notar que esses super-humanos raramente estão no topo do campo tecnológico— o topo do campo tecnológico é basicamente ocupado por megalomaníacos tóxicos, e a diferença que você vê entre essas pessoas depende principalmente do poder de relações públicas. Essa correlação nos leva a uma lei que não pode ser provada, mas que parece objetivamente existir: um bom espírito de código aberto e um bom estado mental são como peixe e patas de urso, não se pode ter ambos.

A menos que você já esteja no auge do seu campo, sempre terá a oportunidade de conhecer pessoas melhores que você: que sabem mais que você, pensam mais profundamente que você e fazem melhor que você. A lacuna entre o pior engenheiro e o melhor engenheiro não pode ser simplesmente resumida como "engenheiro 10x". Em subdomínios, acompanhada pela diferença de experiência e conhecimento especializado, a lacuna entre engenheiros pode ser muito maior do que dez vezes.

Apenas em relação ao movimento de código aberto, há uma maneira simples de classificar engenheiros com diferentes níveis de habilidade:

No entanto, na comunidade de código aberto, a falta de autoconsciência de engenheiros falsos é tão comum que parece validar o efeito Dunning-Kruger. Esses criadores de problemas geralmente também são ávidos por ganhar "pontos sociais", preferindo deixar textos com pouca informação útil e contribuindo apenas por contribuir. Entre os dois tipos de engenheiros, há na verdade uma fase de transição, conhecida como síndrome do impostor, e essas pessoas geralmente não participam de projetos de código aberto e, portanto, são muito menos prejudiciais.

A parte mais irritante do código aberto é que erros, problemas e mal-entendidos que poderiam ser resolvidos de forma independente são erroneamente transferidos de engenheiros falsos para engenheiros verdadeiros devido às diferenças nos níveis de habilidade. Isso é puramente um desperdício do tempo destes últimos. Se as pessoas pudessem primeiro duvidar de si mesmas e agir com cuidado e cautela, a maioria dessas situações poderia ser evitada, mesmo com diferenças nos níveis de habilidade. Tragicamente, essas qualidades que deveriam ser habilidades básicas são, na verdade, bastante raras, e o movimento de código aberto carece de meios eficazes para manter os engenheiros falsos afastados.

Reconheça ou não, os conceitos de software livre e software de código aberto, quando voltados para usuários finais, significam basicamente a mesma coisa— são sinônimos de "software gratuito e seguro".

"Ter recompensas sem pagar" tem um efeito muito forte no nível de marketing, e a maioria das pessoas não consegue resistir a essa tentação. O exemplo mais típico ocorre na indústria de jogos (que também faz parte da indústria de software), onde os jogos mais lucrativos são os chamados "jogos gratuitos". Pergunte a si mesmo: se não fosse gratuito, você ainda o escolheria?

Uma proporção considerável de "projetos de código aberto" tem o valor de sua etiqueta "código aberto" como publicidade muito maior do que o valor do "código aberto" como modelo. Essas pessoas ou percebem claramente que esses projetos são difíceis de sobreviver uma vez separados da equipe de desenvolvimento original, usando o código aberto apenas como uma ferramenta de marketing para superar concorrentes; ou simplesmente usam sua própria "licença de código aberto" definida, e quando um "projeto de código aberto" não usa licenças comuns, não é difícil imaginar a armadilha; alguns projetos originalmente de código aberto, após mudarem para licenças não-código aberto, continuam a confundir o público sob o nome de código aberto, o que mostra o valor de marketing das palavras "código aberto".

No campo da inteligência artificial, até mesmo "pesos abertos" agora são chamados de "código aberto". Assim como "código-fonte legível" não é código aberto, "pesos abertos" também não são código aberto. Os únicos a se beneficiar desse disparate de expansão casual de semântica são aqueles que contam com o código aberto como publicidade.

O lado feio do software de código aberto é frequentemente mascarado pelo "gratuito" superficial. Não existe almoço grátis, e aprender, compreender, utilizar e contribuir para o software de código aberto tem custos. Devido à documentação mais esparsa do software de código aberto, a correção de erros e o suporte dependem muito da comunidade, e a presença generalizada de código não testado em campo, o software de código aberto muitas vezes gera custos inesperados. Quando você decide depender de um projeto de código aberto, já está arcando com esses custos.

A única parte gratuita do software de código aberto reside na auto-escravidão dos mantenedores por idealismo e senso de missão, o que facilmente leva a um colapso maior. Um software de código aberto que funciona bem temporariamente não significa que funcionará bem no futuro. O mantenedor pode se cansar, desistir, perder a capacidade de manter, ter capacidade insuficiente ou até mesmo, por uma doença súbita, decidir destruir um projeto que antes era bom. Portanto, usar software de código aberto não só tem custos, mas também envolve riscos. O software comercial, devido a incentivos de lucro óbvios, na verdade oferece mais garantia do que o software de código aberto.

"Mas os mantenedores de código aberto não te devem nada!" —Espero que você ainda possa dizer isso com confiança quando sofrer perdas devido a ataques à cadeia de suprimentos e vulnerabilidades de segurança. Mesmo que seja apenas uma esmola, urinar nela é imperdoável. A confiança cega e o abuso das pessoas em relação ao software de código aberto criaram muitas oportunidades para urinar na "sopa", resultando em qualquer software que usa dependências externas podendo, acidentalmente, introduzir dependências problemáticas, prejudicando assim todos que estão na cadeia de dependência. Essa crise de confiança aumenta fundamentalmente o custo para todos que continuam a usar software de código aberto, e no final, todas as coisas que eram originalmente leves serão sobrecarregadas por grilhões pesados devido à "performance de segurança" de algumas pessoas que "tentam resolver problemas" e que surgiram do nada.

O abuso de LLMs fez com que os problemas já existentes no FOSS explodissem de forma completa e concentrada. Se antes o software de código aberto ainda tinha algum valor de uso, hoje ele perdeu completamente esse valor: o custo de julgar o nível de habilidade do autor e seu conhecimento do domínio do problema através do código tornou-se muito alto. Especialmente o código lançado após novembro de 2025, não vale mais um segundo de atenção séria; apenas tratá-lo como lixo é eficiente.

Na minha opinião, o FOSS já existe apenas no nome, e a única saída para a comunidade é criar uma nova marca, unindo aqueles que ainda respeitam a qualidade do código sob uma nova bandeira —isso ainda teria que ser construído com base na capacidade dessas pessoas de superar a nova geração de worse is better causada pela programação de LLM.

Até que os LLMs colapsem devido aos novos dados de treinamento sendo apenas lixo, acredito que a comunidade FOSS não tem chance de se recuperar. A melhor escolha que eles podem fazer é reconhecer o valor do código gerado por LLM, então fingir que tudo ainda está bem e, finalmente, desaparecer em silêncio e asfixia como a União Soviética.