Ladybird announced that outside code contributions are over. The code stays under an open source license and development stays visible, but only project maintainers will introduce changes. The team’s core claim is not simply “AI code is bad.” It is that pull requests used to signal commitment, understanding, and good faith because writing a substantial patch was expensive. With LLMs, that signal collapsed. For a browser engine, where one subtle vulnerability can matter, they no longer want code entering the tree from people who will not own the consequences.
Most people thought the diagnosis was dead on even if the remedy felt bleak. The discussion kept returning to the same point: code generation got radically cheaper, but understanding, reviewing, and maintaining code did not. That turns
PR queues into a cost-transfer machine. Outsiders spend tokens. Maintainers spend the scarce resource, attention. Several maintainers from other projects said they are seeing the same flood of AI-written issues and PRs already, and some said external contributions were often a net negative even before LLMs. The old
GitHub model only worked because generating plausible patches had enough friction to act as a rough proof of work.
Where the conversation sharpened was on what this means for open source as a social system. A lot of commenters argued this is less the death of open source than a return from GitHub-era “social coding” to older cathedral-style development, where code is public but trust is earned socially and slowly. SQLite, Lua, and parts of the BSD world came up as precedents. Others pushed back that this closes off the main apprenticeship path for future maintainers, especially on ambitious projects like a browser engine. No one had a satisfying replacement. Proposals like reputation systems, issue-first workflows, manual whitelisting, in-person vetting, and contributor bonds all drew interest, but none looked ready to absorb the volume problem without creating new fairness or governance problems.
A smaller but persistent argument said Ladybird may be overcorrecting. Some people insisted good
drive-by fixes still matter, that reviewing a patch can be cheaper than rediscovering a bug from scratch, and that a blanket ban throws away useful contributions along with slop. That view did not carry the room. The dominant landing point was harsher: if your maintainers are overloaded and your codebase is security-sensitive, banning unsolicited code is rational triage. The broader takeaway people seemed to accept is that “open source” as a license survives, but “open contributions by default” no longer looks like a stable operating model for serious projects.