Kling argues bluntly that a modern web engine is not a hobby-scale codebase, and pretending otherwise produced predictable bottlenecks: slow review cycles, abandoned drive-by contributions, and core subsystems waiting on whoever had a free Saturday. Centralizing core work on paid engineers funded through the Ladybird Browser Initiative is presented as the only honest path to hit the 2026 Alpha-1 and 2027 public release targets.
Frames the shift as overdue honesty about what shipping a browser engine actually costs, citing Servo as the cautionary tale: Mozilla's paid Servo team was laid off in 2020 and the project now limps along on part-time effort under the Linux Foundation. The editorial reads Ladybird's restructuring as an implicit acknowledgment that browser engines are not 'finish it and walk away' problems.
A dominant reaction in the 303-comment thread was appreciation that someone is finally being candid about the engineering investment a real browser engine requires, rather than pretending volunteer Saturdays can compete with Chromium's full-time staffing. Commenters saw the announcement as a healthy correction rather than a retreat.
A second major thread of comments questioned whether six- and seven-figure sponsorships from Shopify, GitHub, and individual donors like Chris Wanstrath can sustain a full-time browser engine team through 2027 and beyond. Citing Servo's fate after Mozilla's 2020 layoffs, these commenters worry the funding model creates a single point of failure if sponsors lose interest.
The post explicitly keeps the door open for external contributors but only on 'bounded, well-scoped tasks,' with more up-front design review and less merge-then-fix. This raises the question of whether the SerenityOS-style open contribution culture that produced Ladybird in the first place can coexist with a paid-team-first model where outsiders are channeled into pre-approved lanes.
Ladybird — the from-scratch, independent browser engine spun out of SerenityOS by Andreas Kling — published a post titled *Changing How We Develop Ladybird*, announcing that the project is moving away from its volunteer-and-spare-time development model and toward a structure built around full-time, paid engineers. The post hit Hacker News and pulled 457 points, with a comment thread dominated by two reactions: relief that someone is finally being honest about what it costs to ship a browser engine, and skepticism that the funding runway is long enough to matter.
Kling's framing is blunt: a modern web engine is not a hobby-scale codebase, and pretending otherwise produced predictable bottlenecks — slow review cycles, drive-by contributions that never land, and core subsystems waiting on whoever had a free Saturday. The new model centralizes core work on the paid team (currently a handful of engineers funded through the Ladybird Browser Initiative non-profit), while keeping the door open for external contributors on bounded, well-scoped tasks. The restructuring also tightens the contribution process: more design review up front, less merge-then-fix.
The non-profit has been collecting six- and seven-figure sponsorships from Shopify, GitHub, and a roster of individual donors (including Chris Wanstrath) since mid-2024. The Alpha-1 target remains 2026, with a public release sometime in 2027. None of that timeline shifted with this announcement — what shifted is the honesty about what's required to hit it.
The last serious attempt at a new browser engine from outside the Chromium/Gecko/WebKit triad was Servo, and Servo's history is the cautionary tale Ladybird is implicitly responding to. Mozilla built Servo with paid engineers, then laid them off in 2020; the Linux Foundation adopted it in 2023 and it now limps along on part-time volunteer effort. Servo's lesson is that browser engines are not a 'finish it and walk away' problem — they are a permanent maintenance burden measured in millions of lines of spec-conformant code, and the moment the paid headcount goes to zero, velocity collapses.
Ladybird is making the opposite bet: keep the paid headcount, accept the governance overhead, and stop pretending that GitHub stars convert to merged PRs at any useful rate. This is also a quiet correction to a narrative the project itself benefited from in 2024 — the 'built by volunteers in a Discord server' framing that helped it go viral but was already misleading by the time the donations rolled in. The HN thread caught this: several top comments noted that calling Ladybird community-driven once Kling went full-time was always a stretch.
There's a deeper point about web platform power. Chromium is now effectively the web standard, with Edge, Brave, Arc, Opera, and Vivaldi all riding on Blink, and Safari the only meaningful non-Chromium browser most users will ever touch. Gecko's market share is rounding-error territory. A third engine that actually ships — even at single-digit conformance with the latest CSS specs — changes the negotiating posture for everyone who currently has to ship Chrome-flavored web apps and pray Safari catches up. Ladybird won't dethrone Chromium. But its existence makes 'works in Chrome' a less defensible engineering shortcut.
The funding model is also worth dwelling on. Ladybird has explicitly refused search-deal money — no Google default, no Yahoo distribution kickback — which removes the structural conflict that has shaped every other browser org's roadmap for two decades. The trade-off is that the project is now dependent on continued corporate sponsorship from companies whose interests in 'an independent browser' are sincere but not infinite. Shopify and GitHub fund Ladybird because Chromium dominance is bad for their long-term web freedom; the day either of them rethinks that math, the runway changes.
For most developers, nothing changes in 2026. Ladybird still can't run your React app reliably, and the Acid3-style conformance work is years from feature parity with Blink. If you're shipping a production web app, your test matrix is still Chrome, Safari, and Firefox in that order of importance.
That said, two things are worth tracking. First, if you maintain a web standard, a polyfill, or a library that touches the platform edges — service workers, WebGPU, the various Storage APIs, font metrics — Ladybird's independent implementation will start surfacing spec ambiguities that Blink and WebKit have papered over with shared assumptions. Independent implementations are how 'works in practice' becomes 'works according to the spec,' and that gap is where most cross-browser bugs actually live. Filing issues against Ladybird now, while the team is small and responsive, is one of the highest-leverage standards contributions available.
Second, if you're an engineer who has ever wanted to work on a browser engine without joining Google, Apple, or Mozilla, the labor market just got a third option. Ladybird is hiring, the codebase is C++ (with a Swift rewrite of selected components underway — itself a story worth watching), and the work is the kind of from-first-principles systems engineering that's increasingly rare. The catch: salaries are funded by donations, not equity or FAANG comp bands.
The interesting question for 2027 is whether Ladybird can sustain the paid-engineer model through a full economic cycle. Every previous independent browser project died not from technical failure but from funding decay; Ladybird's structural innovation is admitting that up front and building the org around it. If the Alpha-1 ships on time and the conformance numbers are credible, expect the sponsor list to grow — and expect the first real test of whether 'no search deals' survives contact with a long sponsor-renewal cycle.
"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