Jason Lee

Posted on Aug 13

Ladybird Just Closed Its Doors to Public PRs. AI Reputation Farming Is Why.

#opensource #browser #security #webdev

On June 5, 2026, the Ladybird project did something almost no popular open-source repository does voluntarily: it shut its own front door. The maintainers announced that Ladybird would stop accepting public pull requests entirely. Not "pull requests need more review." Not "we're tightening CI." Full stop — from that day forward, code that ships in Ladybird is written by a small, named set of maintainers, and outside contributors can no longer open a PR and have it merged.

For a project that has spent four years building its identity on being a from-scratch, community-driven alternative to the Chromium monoculture, this is a strange moment to read about. It's also, I'd argue, the most interesting story in browser engineering this year — more interesting than the alpha release itself, because it's a preview of a problem every popular open-source project is about to have.

What Ladybird actually is

Ladybird is a web browser built on an engine written from zero — no Chromium/Blink, no Gecko, no WebKit fork underneath it. That distinction matters more than it sounds. Almost every browser you've heard of that isn't Firefox or Safari is Chromium wearing a different skin: Edge, Brave, Opera, Arc, Vivaldi, Samsung Internet — all Blink under the hood, all inheriting Google's rendering decisions, its extension platform choices (see the ongoing Manifest V3 fights), and its release cadence.

Ladybird began life as the browser component of SerenityOS, Andreas Kling's hobby Unix-like operating system built entirely from scratch as a personal project. In 2022, Kling split the browser out into its own repository because it had become useful independent of the OS around it, and it needed a life of its own to reach the modern web. That's the whole origin story, and it explains the codebase's texture: the engine components still carry the SerenityOS "Lib" naming convention.

The project is now governed by the Ladybird Browser Initiative, a 501(c)(3) nonprofit co-founded by Kling and Chris Wanstrath, the co-founder of GitHub. Wanstrath has been a major funder since mid-2024, and the initiative also counts Cloudflare, FUTO, Shopify, and 37signals among its sponsors — a donation-funded model deliberately built to avoid the ad-revenue dependency that shapes Chrome's and (arguably) Firefox's incentives.

The GitHub repository currently sits at roughly 65,500 stars, 3,100 forks, and just under 82,000 commits, with 305 watchers and 495 open issues. It picked up around 740 stars in the past week alone — modest by the standards of an AI agent repo going viral overnight, but for a project that just told the internet "no more of your code," that's a sign people are paying attention for reasons other than "can I contribute."

How the engine actually works

Ladybird's architecture is a multi-process design, which by 2026 is table stakes for browsers but is worth spelling out because it's the part doing the security work:

LibWeb — the rendering engine: HTML parsing, CSS layout, the DOM.
LibJS — a standalone, spec-compliant JavaScript engine (used independently by other projects, notably as an embeddable JS runtime).
LibWasm — WebAssembly execution.
LibCrypto / LibTLS — cryptographic primitives and TLS, implemented rather than wrapped around OpenSSL.
LibHTTP — the HTTP/1.1 client stack.
LibGfx — 2D graphics, image decoding, rasterization.
LibUnicode — Unicode and locale handling.
LibMedia — audio/video decode and playback.
LibCore — event loop and OS abstraction.
LibIPC — inter-process communication, which is the glue holding the whole sandboxed model together.

The practical upshot: a main UI process spawns a separate WebContent renderer process per tab, plus dedicated ImageDecoder and RequestServer processes. Image decoding and network I/O happen out-of-process specifically so that a malformed image or a hostile server response can't directly compromise the renderer, and each tab's renderer is sandboxed from the rest of the system. This is the same general shape as Chromium's process model, arrived at independently, in a language (C++, with newer components leaning on Swift experiments) and codebase that owes nothing to Google's.

As of the most recent public Web Platform Tests comparison, Ladybird ranked fourth among tracked engines — behind Chrome, Safari, and Firefox, but ahead of the field of everything else attempting to render the modern web from scratch. That's a genuinely hard result to get to. WPT conformance is not a vanity metric; it's the difference between "renders your CSS demo" and "doesn't break when it hits your bank's login form."

From OS side-project to a funded nonprofit, in four years

It's worth sitting with how fast this went from "one developer's hobby" to "a project with enough gravity to make governance news." SerenityOS started as Kling's personal project after he left a job at a games company; the browser inside it was originally just good enough to render the OS's own documentation. By the time it was split out in 2022, LibWeb and LibJS had matured to the point where the browser was the more actively developed, more externally relevant half of the codebase — the OS was the container, the browser turned out to be the payload.

The funding story tracks the same trajectory. Early Ladybird development ran on the same shoestring, donation-and-goodwill model as most solo open-source projects. That changed materially from mid-2024 onward, when Wanstrath committed serious money and helped formalize the Ladybird Browser Initiative as a 501(c)(3) — a structure that matters because it puts Ladybird in the same funding category as the Python Software Foundation or the Rust Foundation rather than a for-profit venture with an eventual monetization plan. Cloudflare, FUTO, Shopify, and 37signals signing on as sponsors afterward is the kind of validation that's hard to fake: those are infrastructure and SaaS companies with every incentive to want a less Chromium-dependent web, not consumer brands looking for a marketing tie-in.

That funding is also the quiet precondition for the PR-freeze decision. A donation-funded nonprofit with paid maintainers can afford to say "we'll write the code ourselves" in a way a purely volunteer project living on drive-by contributions cannot — closing the gate to public PRs is a luxury that requires already having enough committed engineering hours to not depend on outside patches to keep moving. That's worth naming explicitly, because it means Ladybird's response isn't a template every under-resourced maintainer can copy; it's what closing the gate looks like when you can also afford to open more paid seats behind it.

The part that's actually new: closing the door on public PRs

Here's the announcement's substance, as reported across Slashdot, PiunikaWeb, and other outlets covering it in early June: Ladybird stopped merging public pull requests, closed the ones already open, and moved to a model where only maintainers write code that lands in the tree. The stated reasons were a tighter development process, a clearer security model heading into the alpha, and a smaller, accountable set of people responsible for what enters the browser.

The trigger behind the timing is the part that should get every maintainer's attention: concerns about AI agents farming GitHub reputation. Coverage of the decision cites a documented case of a single AI agent opening 103 pull requests across 95 different repositories in a two-week span — not to fix bugs, but to accumulate a plausible-looking commit and contribution history that could later be leveraged, whether for social engineering, for laundering low-quality or malicious code past distracted reviewers, or simply for building a fake track record. A codebase the size of a browser engine, with memory-unsafe C++ throughout its rendering and parsing layers, is an unusually dangerous place to be experimentally generous about who gets commit-adjacent trust.

This is a genuinely different failure mode than "we got a lot of drive-by low-quality PRs," which every popular repo has dealt with since forever and usually solves with contribution guidelines, a CLA, or more aggressive triage. What Ladybird is describing is adversarial: automated agents optimizing for acceptance, not for correctness, at a volume and fluency that makes traditional "does this look like a competent human wrote it" review heuristics stop working. A plausible-sounding, well-formatted, test-passing PR that quietly introduces a subtle memory-safety bug in an HTML parser is a much scarier proposition than an obviously bad one.

It's worth being precise about what didn't close: issues and Discord discussion remain open, and the project's public roadmap and rationale were published rather than done quietly. This isn't a project going dark — it's a project explicitly trading "anyone can contribute code" for "anyone can propose, only maintainers commit," right as the code they're protecting is about to be run by ordinary users for the first time.

Why this matters beyond one browser

Two separate stories are colliding here, and Ladybird happens to sit at their intersection.

Story one: engine diversity is nearly extinct, and that's a policy problem, not just a technical one. By 2026, Chromium's Blink engine is estimated to render something like 78-79% of global web traffic once you count every Blink-based browser (Chrome, Edge, Opera, Brave, Samsung Internet, and the rest). WebKit, effectively synonymous with Safari on iOS due to Apple's platform rules, accounts for roughly 17-18%. Gecko, Firefox's engine, is down to somewhere in the 3-4% range. That leaves a rounding error — under 1% combined — for every ground-up alternative, which today means basically two projects: Ladybird and Servo, the Rust engine Mozilla open-sourced, let go dormant after 2020 layoffs, and which is now developed under the Linux Foundation Europe with renewed momentum (currently focused on embeddable use cases and a minimal browser shell rather than a full consumer browser).

When two engines control 96%+ of how the web renders, "the web" is, in practice, whatever those two engines' maintainers decide it is — for extension APIs, for ad-blocking capability, for what CSS/JS features get prioritized, for privacy defaults. That's the argument for Ladybird's existence independent of whether you'll ever use it as a daily driver: a third (fourth, counting Servo) truly independent implementation is a check on that concentration, the same way independent audits catch bugs a single reviewer misses. A donation-funded nonprofit with no ad business is structurally free of the conflicts that shape decisions at Google and, to a lesser extent, Mozilla.

Story two: AI-generated contributions are breaking the trust model open source runs on. GitHub's entire contribution pipeline — issue, PR, review, merge — was designed assuming the marginal cost of writing a plausible PR was human time and expertise. Coding agents have driven that cost toward zero for anyone willing to point one at a repo, whether their goal is genuine (if low-quality) help or reputation laundering. Ladybird is an early, visible casualty, but it will not be the last project to conclude that open contribution and AI-agent scale are incompatible without new tooling nobody has built yet: provenance signals, agent-disclosure norms, reputation systems that can't be farmed at scale, or — the blunt instrument Ladybird chose — just closing the gate.

The specific shape of the 103-PRs-across-95-repos case is what makes it worse than ordinary spam. Traditional low-effort PR spam is self-limiting: it's usually obviously bad, gets closed in seconds, and costs the spammer nothing but also gains them nothing beyond a bruised GitHub notification count. Reputation farming inverts the incentive — the PRs are engineered to look competent enough to merge, or at minimum to sit open long enough to pad a contribution graph and a "merged PRs across N repositories" credential that later gets pointed at a recruiter, a bug bounty program, or a maintainer who's more likely to trust a contributor with visible history. The attack isn't against any single repository; it's against the ambient signal every repository collectively emits about who's a "real" contributor. A browser engine happens to be one of the higher-value targets for exactly that laundering, because "I have merged commits in a browser rendering engine" is a much stronger credibility signal than "I fixed a typo in a README," which raises the stakes on exactly the kind of project least equipped to individually verify each contributor's intent at scale.

That's also why Ladybird's response — closing the gate entirely rather than adding more automated screening — reads as a considered choice rather than a panic reaction. Automated detection of AI-generated PRs is an arms race Ladybird's maintainers evidently decided not to fight, correctly, given how fast agent-generated text has closed the stylistic gap with human-written code and commit messages. Rather than build a detector that degrades every few months as agents improve, they removed the surface the detector would have been protecting.

Practical use cases: who actually touches this code today

Given the pre-alpha label, "should I use Ladybird" is the wrong question for almost everyone right now. The more useful question is who gets value from the codebase itself, today, without waiting for a stable release:

Web standards contributors and browser engineers get a second (really, fourth) real-world implementation to test spec ambiguities against. When the HTML or CSS spec is genuinely ambiguous, having Ladybird's interpretation alongside Chromium's and WebKit's is a legitimate signal for standards bodies, not just an academic exercise — WPT scores only mean something because there are multiple independent implementations disagreeing on edge cases and converging through the test suite.
Anyone embedding a JS engine outside a browser context has reason to look at LibJS specifically. A standalone, spec-compliant JavaScript engine not tied to V8's or JavaScriptCore's licensing or governance is a genuinely useful building block independent of whether the browser around it ships, the same way SQLite's parser has uses far outside SQLite itself.
Security researchers interested in memory-safety tooling for C++ codebases have a large, actively developed, sandboxed multi-process C++ application to point static analyzers, fuzzers, and sanitizers at — Ladybird's own build documentation leans on this kind of tooling given the memory-unsafe language choice for the core engine.
Developers who just want to read well-organized systems code get a rarity: a browser engine you can actually read end to end without needing a decade of institutional context, because it's young enough that the whole architecture is still legible to a newcomer, unlike Chromium's multi-million-line, multi-decade codebase.

None of that requires trusting the alpha as a daily browser. It's the difference between "is this ready to replace Chrome" (no, not for years) and "is this codebase already doing useful work for the ecosystem around it" (yes, arguably today).

What developers should actually take from this

If you maintain anything popular enough to attract automated PR traffic, Ladybird's decision is a data point worth sitting with even if you don't copy the response. A few concrete takeaways:

"More PRs" stopped being an unambiguous health signal. A repo with a rising PR count now needs a second number next to it — accepted-and-shipped versus opened-and-closed — before that growth means anything.
Maintainer-only merge doesn't have to mean closed development. Ladybird kept issues and design discussion open; the constraint is specifically on who can land code, not on who can shape direction. That's a narrower, more defensible position than "we're going proprietary," and worth distinguishing from actual closed-sourcing, which this isn't.
If you're building or using coding agents that open PRs autonomously, this is the reputational externality you're generating for the ecosystem, not just for your own repo. The 103-PR-across-95-repos case is exactly the kind of behavior that makes maintainers of unrelated projects tighten their own gates.
Engine diversity is a dependency you're carrying whether you think about it or not. If your product, your extension, or your testing matrix implicitly assumes "Chromium behavior is web behavior," Ladybird's WPT ranking climbing every quarter is worth tracking — it's the closest thing to a canary for where a fourth engine's quirks might eventually surface in production.

Where it stands against the field

Engine	Backing	Independence	Approx. traffic share (2026)	Status
Blink (Chromium)	Google	Forked/adopted by Edge, Brave, Opera, etc.	~78-79%	Dominant, actively evolving
WebKit (Safari)	Apple	Independent, iOS-exclusive by policy	~17-18%	Stable, platform-locked
Gecko (Firefox)	Mozilla	Independent	~3-4%	Declining share, actively maintained
Servo	Linux Foundation Europe	Independent (Rust, ex-Mozilla)	<1%	Embeddable-focused, pre-consumer-browser
Ladybird	Ladybird Browser Initiative (nonprofit)	Independent, from scratch	<1%, pre-alpha	Alpha targeted 2026, maintainer-only development

The honest limitations

None of this should be read as "Ladybird is ready." It is pre-alpha software, explicitly labeled as suitable only for developers right now, targeting a public alpha in 2026, beta in 2027, and stable release in 2028 — a multi-year runway before anyone should consider it for daily use. Fourth place on WPT conformance, while impressive for a from-scratch project, still means real, user-visible gaps against Chrome, Safari, and Firefox on today's web, which is built and tested almost exclusively against Blink and WebKit. Performance benchmarks against mature JIT-optimized engines aren't something the project or independent reviewers have published in a way that would let anyone claim parity, and a browser this young inherits every unglamorous problem browsers have — font rendering edge cases, video codec licensing, extension ecosystem from zero, enterprise policy support — that take years to grind down even with resources far larger than a donation-funded nonprofit's.

The PR-freeze decision also has a real cost the announcement doesn't dwell on: it forecloses the "many eyes make bugs shallow" model that open-source security arguments have leaned on for decades, right at the project trading on being more trustworthy than Big Tech's browsers. Trusting a smaller, named set of maintainers is a different trust model, not a strictly stronger one, and it's fair to ask whether it will scale if Ladybird's contributor interest keeps growing while its committer list stays small.

Who should actually pay attention

If you're a browser or web-standards nerd, or you maintain anything that touches rendering, parsing, or IPC-heavy sandboxing architecture, Ladybird's codebase is worth reading regardless of whether you'll ever ship it to users — LibWeb and LibJS are legitimately interesting, readable implementations of hard problems. If you're evaluating it as an actual browser to use, wait; pre-alpha means pre-alpha, and the 2028 stable target is not a formality. And if you maintain any repository popular enough to see automated contribution traffic, treat Ladybird's June decision less as a browser story and more as an early incident report from a fellow maintainer — one you'll likely be writing your own version of within the next year or two.

Discussion question: if AI-agent-generated PRs keep scaling the way the 103-PRs-in-two-weeks case suggests, is maintainer-only merge (Ladybird's answer) the right default for security-critical open source going forward, or does it just push the trust problem from "who can submit code" to "who gets to become a maintainer" — and is that actually a smaller, more solvable problem?

Sources:

DEV Community