Kling explicitly frames the Swift decision as non-religious and pragmatic: Rust's C++ interop was too painful for incremental migration, while Swift 6's bidirectional C++ interop, strict concurrency model, and value-type semantics let the team keep shipping while gradually escaping decades of C++ undefined behavior. The language was chosen for engineering reasons, not ideology.
Kling structures Ladybird as a 501(c)(3) with an explicit ban on search defaults, ad partners, 'acceptable ads' programs, and VC rounds — pointing to Mozilla's 80% dependence on Google search revenue (now threatened by DOJ action) as the cautionary example. Donations from Tobi Lütke, GitHub, and ProtonMail are positioned as proof the model can fund a real engine.
The editorial argues that with only three independent engines remaining — Blink, Gecko, and WebKit — and two of them controlled by ad companies, the web's openness depends on a genuinely independent fourth engine. Ladybird's governance structure matters more than its language choice because it's the only thing that addresses the root cause of the duopoly.
Andreas Kling published a long post on the Ladybird blog announcing three changes that, taken together, reshape what the project actually is. First, Ladybird is migrating from C++ to Swift as its primary implementation language, with new code written in Swift and existing C++ ported incrementally. Second, Ladybird has incorporated as a US 501(c)(3) non-profit — the Ladybird Browser Initiative — funded entirely by donations and corporate sponsorships, with an explicit ban on advertising deals and venture capital. Third, Kling is stepping away from day-to-day SerenityOS work to focus exclusively on the browser. The fork has eaten the parent.
The Swift decision is the part that's lighting up Hacker News. Kling's reasoning, summarized: he evaluated Rust, Swift, and a few others; Rust's interop story with the existing C++ codebase was painful enough to be a non-starter for an incremental migration; Swift 6's strict concurrency model, value-type semantics, and — critically — its bidirectional C++ interop made it the path of least resistance. He's explicit that this is not a religious choice. It's the language that lets the team keep shipping while gradually getting out from under decades of accumulated C++ undefined behavior.
The non-profit structure is the part that should matter more. Mozilla raises around $500M/year, of which roughly 80% comes from a Google search-default deal that the DOJ is currently trying to break. Ladybird is pre-committing to never accept that kind of revenue — no search defaults, no ad partners, no "acceptable ads" program, no VC rounds with a liquidity clock. The initial funding came from a $1M donation from Shopify CEO Tobi Lütke and follow-on sponsorships from GitHub, ProtonMail, and a handful of individuals.
There are three independent browser engines in the world: Blink (Chrome, Edge, Brave, Opera, Arc), Gecko (Firefox), and WebKit (Safari). Two of them are controlled by ad companies. The third is controlled by a hardware company that uses it as a moat. Ladybird is the only credible attempt in twenty years to build a fourth from scratch — no Chromium fork, no Gecko fork, no WebKit fork. The last serious from-scratch browser engine was Servo in 2012, and Mozilla laid off the entire Servo team in 2020.
The Swift choice is more interesting than the language-war framing suggests. Swift was designed by Chris Lattner — who also designed LLVM — and it has spent the last three years quietly building exactly the features a systems project needs: ownership annotations, non-copyable types, strict concurrency, and the only production-quality bidirectional C++ interop that exists. Rust's C++ interop, via cxx or autocxx, requires hand-written bridge code for anything non-trivial. Swift can `import CxxStdlib` and call STL containers directly. For a project with 500K+ lines of existing C++, that delta is the whole ballgame.
The community reaction on HN (693 points, 800+ comments at time of writing) splits along predictable lines. The Rust camp argues Swift is a Mac-first language with a heavyweight runtime and weak Linux tooling. The Swift camp points out that the Swift Foundation has been pushing hard on Linux and Windows support, that the runtime is smaller than people assume, and that Apple's investment in Swift-for-systems is the only reason features like non-copyable types exist. The real signal isn't which camp is right — it's that a serious browser project just publicly declared Rust's borrow checker is not worth the migration cost when an alternative with similar guarantees and better C++ interop exists.
The non-profit structure deserves a separate look. Mozilla's structural problem isn't engineering — it's that a 501(c)(3) (the Mozilla Foundation) wholly owns a for-profit (the Mozilla Corporation) that depends on a single customer (Google) for ~80% of its revenue. Every product decision is downstream of "don't lose the Google deal." Ladybird is trying to avoid that trap by refusing the for-profit subsidiary entirely. Whether $1M/year in donations can fund a browser team is the open question — Mozilla spends ~$300M/year on Firefox engineering alone — but the structural intent is honest.
For the next two to three years, nothing. Ladybird targets an alpha in 2026 and has explicitly told users not to use it as a daily driver yet. Your web app will still be tested against Chromium, Gecko, and WebKit. But if you're a library author or a standards person, start running your code against Ladybird's WPT (Web Platform Tests) numbers — they're publishing them publicly and the gap is closing faster than anyone expected. A genuinely independent fourth engine changes the calculus on standards: when Chrome ships a half-baked API and Firefox refuses to implement it, today the story ends there. With a fourth engine that has no ad revenue to protect, the standards-body politics shift.
If you're a Swift developer, this is the most credible signal yet that Swift is becoming a real cross-platform systems language outside the Apple ecosystem. The Ladybird team will be one of the largest non-Apple Swift codebases in production, and they'll be hitting Linux-specific bugs in the toolchain before anyone else. Expect a wave of upstream Swift Foundation contributions over the next 18 months. If you've been waiting for an excuse to take Swift-on-Linux seriously, this is it.
If you donate to open source, the Ladybird Browser Initiative is now a 501(c)(3) — donations are tax-deductible in the US, and they're publishing a financial report quarterly. The structural commitment to never take ad money or VC is the part worth funding. There are very few projects of this scope with that constraint.
The two-year question is whether Ladybird can ship a usable browser on donation revenue alone. The five-year question is whether the Swift bet pays off — whether Swift-on-Linux matures fast enough that the toolchain isn't a constant drag, and whether the C++→Swift migration completes without the project getting stuck in a permanent bilingual state (the fate of every "we'll migrate incrementally" project ever). Bet on Kling: SerenityOS shipped a working kernel, GUI, compiler, and browser engine in seven years with no funding. If anyone can make a from-scratch browser work in 2026, it's the person who already did the impossible version once.
"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