Changing how we develop Ladybird
Overview of the change
- Ladybird will no longer accept public code contributions; only maintainers can land changes.
- Source and license remain open; the change is about development process, not licensing.
- Rationale given: security risk for a browser, and the collapse of PRs as a trust signal in the age of AI-generated code.
Reactions on openness and project fate
- Some see this as the “death” of the project’s community aspect, predicting lost goodwill and fewer users who care about independent browsers.
- Others argue this is a reasonable, even inevitable move for serious end‑user software, pointing to SQLite, Lua, parts of Blender, etc. as successful “open source but not open development” models.
- Debate over terminology: many insist it’s still clearly open source (by license), not merely “source-available,” even if contributions are closed.
AI, PR “slop”, and broken trust signals
- Central theme: AI has made it cheap to generate large patches, so a big PR no longer proves deep understanding or good faith.
- Maintainers report being overwhelmed by low-quality or AI-vibecoded PRs and duplicate vulnerability reports; review effort hasn’t gotten cheaper.
- Several commenters generalize this to writing and forums: AI breaks the implicit social contract that substantial output implies substantial human effort.
Security, review cost, and burnout
- For a browser running untrusted code, a single subtle vulnerability is catastrophic; this amplifies mistrust of unknown contributors.
- Many maintainers say reviewing external PRs is often a net cost and easier than just writing the fix themselves, especially under AI spam.
- Some see this as analogous to a DDoS: first response is to put up a firewall.
Pathways for future contributors and maintainers
- Major worry: with no external PRs or even emailed patches, how will new maintainers emerge?
- Suggestions from the thread: trust/reputation systems, in‑person vetting at conferences, small/limited PR quotas, reputation across projects, or recruitment via forks.
- Others counter that historically, trust was often built socially (mailing lists, long‑term interaction) rather than just through GitHub PRs, and expect a return to that.
Broader implications for open source
- Many expect more large projects to adopt “cathedral” or closed‑contribution models as AI scales PR volume.
- Some fear this accelerates the decline of open, community‑oriented development and pushes work into closed communities, private chats, or invite‑only spaces.
- Others see it as a necessary reset away from “GitHub-as-social-network” back toward smaller, high‑trust groups, even if that excludes many would‑be contributors.