Um navegador independente, construído do zero, com motor próprio, financiado pelo cofundador do GitHub. Parecia o projeto open source mais promissor da década. Até que os mantenedores trancaram a porta.

O Ladybird — o único navegador novo que não roda Chromium nem Gecko — acabou de anunciar que não aceita mais pull requests de contribuidores externos. Todos os PRs abertos foram fechados. Sem aviso prévio, sem período de transição, sem “vamos repensar daqui a 6 meses”. Acabou.

E a razão principal? IA.

O Único Navegador que Não Copia Ninguém

Antes de entender por que essa decisão é tão radical, vale contextualizar o que o Ladybird representa.

Andreas Kling começou o projeto em 2019 como uma biblioteca HTML dentro do SerenityOS, sistema operacional que ele também criou do zero. O cara trabalhou no KHTML (o motor que virou o WebKit), passou pela Nokia, trabalhou na Apple no Safari, e decidiu que queria construir um navegador completamente independente.

Em 2022, o Ladybird virou projeto separado. Em 2024, Chris Wanstrath — cofundador do GitHub — entrou como financiador principal. O projeto ganhou fôlego real: uma equipe dedicada, infraestrutura séria e a promessa de um alpha para 2026.

Hoje, o Ladybird tem seu próprio motor de renderização e seu próprio motor JavaScript. Nenhuma linha de código do Chromium, nenhuma do Firefox. É o primeiro navegador verdadeiramente novo em mais de uma década.

E é exatamente por isso que a decisão de fechar os PRs pesa tanto.

O Que Exatamente Mudou

O post oficial do Ladybird não enrola. A mensagem é clara: a partir de agora, apenas mantenedores do projeto podem introduzir mudanças no código. Contribuidores externos continuam bem-vindos para:

• Reportar bugs
• Testar builds
• Participar de discussões de design
• Enviar relatórios de segurança
• Dar feedback técnico

Mas código? Só quem é do time.

E para quem pensou em contornar — nada de mandar patches por email, colar código em issues ou abrir forks como “fila de review”. Nenhum canal alternativo vai funcionar como substituto dos PRs.

# O que NÃO funciona mais:
git checkout -b minha-feature
# ... 3 horas de trabalho ...
git push origin minha-feature
# Abrir PR no GitHub
# ❌ PR será fechado automaticamente

A justificativa oficial tem três pilares: segurança, responsabilidade e o elefante na sala — inteligência artificial.

“Um Pull Request Não Diz Mais Quem Você É”

Essa frase do post oficial resume tudo.

Eu já vi muitos projetos open source reclamarem de PRs de baixa qualidade. Spam de Hacktoberfest, contribuições cosméticas para inflar currículo, aquele clássico “fix typo” que na verdade quebra o build. Mas o Ladybird está falando de algo mais sério.

A equipe argumenta que ferramentas de IA mudaram a economia das contribuições open source de forma fundamental. Antes, se alguém mandava um PR bem escrito, com testes, seguindo as convenções do projeto, isso dizia algo sobre a pessoa. Significava que ela leu o código, entendeu a arquitetura, investiu tempo. Hoje? O Claude, o Copilot ou o Cursor fazem isso em minutos.

“A pull request no longer tells us as much as it used to about the person submitting it.”

O problema não é que código gerado por IA seja necessariamente ruim. O problema é que ele destrói o sinal. Quando qualquer pessoa pode gerar um PR que parece legítimo sem entender uma linha do que está sendo proposto, o processo de review vira roleta russa.

E para um navegador, roleta russa é inaceitável.

Por Que um Navegador É Diferente

Se fosse uma biblioteca de utilidades, um framework CSS ou até um ORM, talvez desse para conviver com o risco. Mas um navegador web processa conteúdo não confiável da internet o dia inteiro. Cada página que você abre é, tecnicamente, código executando na sua máquina.

O Ladybird tem:

• Motor de renderização próprio — qualquer bug é potencialmente um RCE
• Motor JavaScript próprio — a superfície de ataque é enorme
• Parser de HTML, CSS, SVG, WebAssembly — cada formato é um vetor
• Networking stack — TLS, HTTP/2, WebSockets, cada protocolo importa

Uma vulnerabilidade bem disfarçada em qualquer uma dessas camadas pode comprometer milhões de usuários. E o post do Ladybird é explícito sobre isso:

“One well-disguised vulnerability is all an attacker needs.”

Não é paranoia. É a realidade do que aconteceu com o XZ Utils.

O Fantasma do XZ Utils

Em março de 2024, a comunidade open source descobriu que o XZ Utils — uma biblioteca de compressão presente em praticamente todo sistema Linux — tinha um backdoor inserido por um contribuidor que passou dois anos construindo confiança.

O atacante, usando o nome “Jia Tan”, começou com contribuições legítimas e pequenas. Ganhou confiança. Virou co-mantenedor. E então injetou código malicioso nos tarballs de release, sem tocar na branch principal do repositório. Foi engenharia social no nível mais sofisticado possível.

Agora imagine o mesmo cenário potencializado por IA:

A OpenSSF já alertou que LLMs baratearam drasticamente a criação de “sock puppet networks” — redes de perfis falsos com histórico convincente. Um atacante não precisa mais investir dois anos cultivando confiança. Ele pode criar 50 perfis falsos, cada um contribuindo para projetos diferentes, todos gerando código que passa no CI.

O Ladybird olhou para esse cenário e decidiu que a única defesa real é cortar o vetor na raiz.

A Ironia Deliciosa

Tem um detalhe que torna essa história particularmente interessante.

Em fevereiro de 2026, o Ladybird anunciou que está migrando seu motor de C++ para Rust. E sabe como eles estão acelerando a migração? Usando agentes de IA para fazer a conversão automatizada do código.

Ou seja: o Ladybird baniu contribuições externas por medo de código de IA, mas usa IA internamente para reescrever o próprio motor.

Antes de gritar hipocrisia, tem uma diferença crucial. Quando a equipe do Ladybird usa IA internamente, os mantenedores estão no controle. Eles definem o prompt, revisam o output, entendem o contexto, e são responsáveis pelo resultado. Quando um estranho manda um PR gerado por IA, ninguém sabe o que foi pedido, o que foi modificado manualmente, ou se o contribuidor sequer entende o código que está propondo.

É a mesma lógica de uma empresa que usa automação internamente mas não aceita “contribuições automatizadas” de estranhos. O risco não está na ferramenta — está em quem controla a ferramenta.

O Modelo Cathedral Está de Volta

Eric Raymond escreveu em 1997 que o open source venceria porque “The Bazaar” — o modelo aberto, caótico, onde qualquer um contribui — era superior ao “Cathedral” — o modelo fechado, controlado, onde poucos decidem.

O Ladybird acabou de escolher a Catedral.

E eles não estão sozinhos nessa tendência. Nos últimos dois anos, vários projetos começaram a restringir contribuições:

• Linux kernel: Linus Torvalds reforçou regras sobre revisão e accountability
• curl: Daniel Stenberg tem reclamado publicamente de PRs gerados por IA
• Projetos da CNCF: Várias fundações estão discutindo políticas para contribuições automatizadas

A ironia é que o modelo Bazaar funcionou por décadas porque havia um custo natural: escrever código bom dava trabalho. Esse custo era, na prática, um filtro de qualidade e um proxy para confiança. A IA eliminou esse custo — e com ele, o filtro.

O Que Isso Significa para Você

Se você contribui para projetos open source, prepare-se: mais projetos vão seguir esse caminho.

Não necessariamente fechando PRs completamente como o Ladybird, mas criando barreiras. Vou chutar algumas tendências:

• Contributor License Agreements mais rígidos com cláusulas sobre uso de IA
• Mandatory disclosure: “este PR foi gerado/assistido por IA?”
• Contribuições por convite em projetos críticos de infraestrutura
• Proof of understanding: testes orais ou documentação obrigatória explicando o “porquê” além do “o quê”

Para mantenedores, a pergunta deixou de ser “como atrair mais contribuidores?” e virou “como garantir que cada linha de código que entra foi entendida por alguém de confiança?”

O Custo do Silêncio

A decisão do Ladybird é corajosa, mas vem com custos reais.

Projetos open source dependem de contribuidores externos não só pelo código, mas pelo efeito de comunidade. Contribuir para um projeto é como fazer estágio — você aprende, o projeto ganha braços extras, e eventualmente os melhores contribuidores viram mantenedores.

Fechar os PRs quebra esse pipeline. O Ladybird vai ter que encontrar e contratar talentos por outros meios. E novos desenvolvedores que queiram aprender sobre motores de navegador perderam um dos poucos projetos onde isso era possível.

É uma troca: segurança por comunidade. E o Ladybird claramente decidiu que, para um navegador web em 2026, segurança vence.

Talvez o open source precise aceitar que o modelo que funcionou por 30 anos não sobrevive intacto à era dos agentes de IA. A pergunta real não é se o Ladybird está certo — é quanto tempo até o próximo grande projeto fazer o mesmo.

Fonte de inspiração: Changing How We Develop Ladybird