Amiko Forks Rails on a Bet: the Framework Is Finished

Nearly a year after a few hundred developers signed an open letter asking the Rails core team to cut ties with David Heinemeier Hansson — a request the core team ignored and DHH publicly mocked — the fork it threatened has a name. Lucas Dohmen, co-author of The Rails 8 Way, announced this weekend that the community behind that letter is building Amiko: a hard fork of Rails 8.x with community governance, an explicit code of conduct, and a deliberately unambitious technical mission.

The provocative title of Dohmen's announcement, "Rails is done," is doing double duty. It's a resignation letter from mainline Rails, but it's also a technical claim: that the framework is finished. The core gems — Active Record, Action Pack, Active Support — haven't seen a major redesign since Rails 6.0 shipped Zeitwerk in 2019. Everything headline-worthy since has been layered around that core: Hotwire, the Solid trifecta, Kamal, the authentication generator. If the engine is done, the argument goes, you don't need DHH's product vision to keep it running. You need maintainers.

That framing is the most interesting thing about Amiko, and it deserves a closer look than the culture-war coverage will give it.

Forking a framework that stopped moving

Most protest forks die because they implicitly promise to out-develop the original, and can't. Node.js survived io.js in 2014 only by capitulating — the fork had captured the actual core contributors, so the foundation absorbed it. OpenTofu and Valkey worked because a license rug-pull handed them corporate sponsors with payrolls. Forks with neither the contributors nor the money — and open source history is littered with them — fade within a year.

Amiko, on paper, has neither. Rails development is bankrolled by 37signals and Shopify; the Rails Foundation funds docs and marketing; the core team stayed put after the letter. Amiko's governance repo shows single-digit commits, and its organizers report about 140 people in a Matrix space, hashing out a Sociocracy-based decision model. Ryan Bigg — no DHH apologist, and author of Maintainable Rails — has already dismissed it as virtue signalling, arguing that anyone unhappy enough to leave Rails should put that energy into Hanami, which rethought the architecture rather than renaming it.

But Bigg's critique assumes Amiko is competing on development, and Dohmen explicitly says it isn't. The stated scope is narrow: fork the core gems from Rails 8.x, keep backward compatibility, port upstream security patches, use an alias trick so gems that depend on rails still resolve, and otherwise leave the framework alone. Optional components and new features are out of scope. That's not a rival framework. That's a long-term support channel with a values statement attached — and an LTS project is the one kind of fork where a finished codebase and a modest volunteer pool might actually be enough. Porting security patches to a stable branch is a maintenance job, not an R&D job.

The LTS math is the real story

Here's why that scope hits a nerve, regardless of what you think of the politics. Rails' maintenance policy gives each minor release one year of bug fixes and two years of security patches. Run the dates: Rails 7.2 reached security end-of-life today, August 9, 2026. Rails 8.0 loses security support on November 7, 2026. Rails 8.1 is covered until October 10, 2027. If you're running 8.0 in production, you have three months of patches left on your current series.

The treadmill is real, even if the individual upgrades are mild these days. And there's long-standing proof that people will pay to get off it: makandra's Rails LTS has sold commercial security support for end-of-life Rails versions — back to Rails 2 — for over a decade, with 37signals itself among the customers. The demand Amiko wants to serve isn't hypothetical; it's an existing market that until now had exactly one vendor. A free, community-run LTS for 8.x apps that don't want to chase mainline releases — or whose teams no longer want their dependency governed by DHH — is a genuinely useful thing that currently doesn't exist.

Whether Amiko can deliver it is another question. Security backporting is unglamorous, deadline-driven work, and the project hasn't yet shipped a gem, let alone demonstrated CVE turnaround. Volunteer LTS efforts have a worse survival record than volunteer feature development, because nobody joins open source to backport patches. The Sociocracy governance experiments are admirable, but a CVE doesn't wait for consent-based decision rounds.

What to actually do

If you run Rails in production, nothing about your near-term plan should change this week. Concretely:

• On 8.0 or earlier: your deadline pressure comes from Rails' own policy, not from this fork. Get to 8.1, which buys you until late 2027. The 8.0-to-8.1 jump is small; this is a normal quarter's chore, not a migration project.
• Stuck on an old version: makandra's Rails LTS remains the only proven option, and it costs money. That's the status quo Amiko is challenging.
• Curious about Amiko: watch for two signals before touching it — a published gem release your Gemfile can actually point at, and evidence they've shipped a security patch within days of an upstream advisory. Until both exist, this is a governance experiment, not infrastructure.

My read: Amiko will not displace Rails, and it isn't trying to. The mainline framework keeps its funded contributors, its release cadence, and the overwhelming majority of its users, most of whom demonstrably don't choose frameworks on the founder's politics. But the fork's diagnosis is sharper than its critics allow. Rails really is largely done as a core framework, its official support windows really are short, and the community really did just learn that its governance has no mechanism for accountability beyond "leave." Amiko is what leaving looks like when you can't afford to rewrite. Even if it fizzles — and the base rate says it will — it's put a number on something the Rails Foundation should find uncomfortable: how many teams want the framework without the figurehead, and how little of the framework's future they'd have to give up to get it.