The project's official blog post argues that with paid engineers and growing external contributions landing patches against the same subsystems, the old 'hundred enthusiastic strangers each touching layout' model no longer scales. They are introducing per-subsystem approvers, deliberate roadmap milestones, and clearer signals to drive-by contributors as a precondition for shipping a 2026 alpha.
By submitting this post and driving it to 323 points, the submitter signals that the developer community treats Ladybird's governance overhaul as significant news — not bureaucratic overhead but a necessary maturation step for a project trying to ship a real browser.
The editorial frames the governance change as high-stakes precisely because the browser engine market has consolidated to Blink, WebKit, and Gecko — with Mozilla in decline. Ladybird, building HTML parser, LibJS, LibWeb, and networking from scratch with nonprofit backing from Shopify and GitHub, is the sole counterweight to single-vendor capture of web standards.
The Ladybird Browser Initiative posted a blog titled 'Changing How We Develop Ladybird,' outlining a new contribution and review workflow for the project. The post lays out tighter conventions for who can approve PRs, how changes get scoped, and how the project plans to keep velocity high without letting the codebase fragment as more paid engineers and external contributors land patches against the same subsystems.
For context: Ladybird is the browser project spun out of Andreas Kling's SerenityOS, now run as an independent US-based nonprofit funded by donations and corporate sponsors (Shopify and GitHub among them). It is building everything from scratch — HTML parser, layout engine, the LibJS JavaScript engine, LibWeb, networking, the lot. No forks of Blink, WebKit, or Gecko. The project has a stated goal of shipping a first alpha in 2026.
The blog reframes development around a smaller circle of 'approvers' per subsystem, more deliberate roadmap milestones, and a clearer signal to drive-by contributors about what kinds of patches will actually merge. In other words: the project is admitting it has outgrown the 'a hundred enthusiastic strangers each touching layout' model and needs structural discipline to ship.
Look at the browser engine market in June 2026 and the picture is bleak. Chrome, Edge, Opera, Brave, Arc, Vivaldi, Samsung Internet — every one of them ships Blink. Safari is WebKit, which Google still contributes to but which only ships on Apple hardware. Firefox is Gecko, and Mozilla's market share has been in slow decline for the better part of a decade while the org pivots toward AI side-projects. The number of *independent* browser engines under active, well-funded, from-scratch development in the world right now is one. It is Ladybird.
That is not a sentimental observation. Web standards are negotiated by the people who implement them. When implementations consolidate to a single vendor's engine, the spec process becomes a rubber stamp on Chrome's behavior — which has direct consequences for any developer whose stack touches HTML, CSS, WebRTC, WebGPU, Service Workers, or the Permissions API. The last decade of 'works in Chrome, breaks in Safari, never tested in Firefox' has been bad enough. A future with literally one engine is qualitatively worse.
So why does the process change matter? Because the failure mode for a project like Ladybird isn't lack of enthusiasm — it's the second-system problem at industrial scale. Browser engines are some of the largest pieces of software humans build; Chromium alone is roughly 35 million lines of code and ships on a six-week train run by hundreds of full-time engineers. Trying to match a moving target with a much smaller team means every wasted PR, every duplicated effort, every nondeterministic test, every unmaintained subsystem compounds. Reorganizing review around named approvers and tightening the contribution funnel is what 'we are serious about shipping' looks like in practice.
It's also worth comparing to what didn't work elsewhere. Servo, Mozilla's Rust-based engine, was technically interesting and produced great research output (Stylo shipped into Firefox, WebRender shipped into Firefox), but Servo as a *browser* never crossed the finish line and got laid off in 2020. The Linux Foundation revived it, but its cadence is glacial. KHTML, Presto, Trident — each of these died not because the code was bad but because nobody could afford to keep paying engineers to chase the standards treadmill. Ladybird's bet is that a small, focused nonprofit with a few million dollars a year and a disciplined merge process can do what billion-dollar orgs failed to: hold one extra engine alive in the wild.
Community reaction on Hacker News (323 points) skews supportive but skeptical of timelines. The recurring complaint isn't 'why are you doing this' but 'why are you also writing your own JS engine, image decoders, TLS stack, and font shaper instead of pulling proven dependencies in?' The team's answer has been consistent: every dependency is a thing you don't actually understand, and a browser is a security boundary where 'we don't understand it' eventually shows up as a CVE. The new process doubles down on that posture — fewer drive-by patches, more owned components, longer-lived expertise per subsystem.
If you ship anything to the web, this is the project to follow even if you never run the browser. The realistic near-term outcome isn't 'Ladybird takes 5% market share.' It's 'Ladybird becomes the third reference implementation that spec authors must care about,' which alone is enough to keep the web from collapsing entirely into Chrome's behavior. Run your CSS through Ladybird's test runner once it's stable and you will find genuine spec ambiguities you've been quietly relying on Chrome to paper over.
For anyone building developer tooling — testing frameworks, headless rendering services, e2e harnesses, screenshot diffing — start planning for a non-Chromium target that isn't WebKit-on-Mac. Playwright already supports Firefox and WebKit; Ladybird will eventually fit into that same slot, and being early there is a small but real moat. If you maintain a web framework or a polyfill library, your bug reports are about to get more interesting in a useful way.
For contributors thinking about jumping in: the new process means PRs need to be scoped, justified, and aligned to a milestone, not just 'I rewrote the box layout because I had a weekend.' That's a higher bar but a clearer one. The README and CONTRIBUTING docs are the place to start, and the linked blog spells out which subsystems are actively recruiting reviewers.
The interesting test isn't whether Ladybird ships its 2026 alpha on time — it almost certainly won't — but whether the new development model holds together at 2x the current contributor count. Engines die at organizational scale, not technical scale. If Kling and the nonprofit can institutionalize the project so it survives him stepping away one day, the web gets a real second engine for the first time in a decade. If they can't, the monoculture gets one notch deeper and we all keep writing CSS to whatever Chrome decided this quarter.
"A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds." I believe this is the key point the article makes and it's valid for most projects out there
On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.On the other hand, while not accepting external code contributions will certainly improve their security postur
> There will not be a [..] process for submitting patches by [any] means> Outside involvement still matters: clear bug reportsSo I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.Instead they have to re-figure it out. The team must be thrilled to re-do work
Stuff like this makes me wish AI had never happened.An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that whi