Rails Is Done. So Why Are Developers Ready to Burn It Down?

You’ve felt it. That slow, creeping unease every time DHH posts another breathless AI paean on his blog. The guy who once called crypto a Ponzi scheme and treated hype cycles with aristocratic disdain is now the loudest cheerleader in the room. And you’re supposed to just… go along with it.

Here’s the thing nobody in the comment sections wants to say out loud: the proposed Rails fork isn’t about missing features. It’s not about performance. It’s not even about code.

When a framework is feature-complete and people still want to fork it, you’re not watching a technical decision. You’re watching a divorce.

The original post declares “Rails is done” — meaning, the framework has reached feature completeness. It works. It ships. It does what it needs to do. So by all logic, a fork should be unnecessary. If the product is finished, you maintain it. You don’t split it.

But that’s the twist. The fork exists precisely because Rails is “done” as a technical project — and yet DHH keeps trying to make it something else. A vehicle for his personal AI pivot. A megaphone for his evolving worldview. A stage where the framework is stable but the leader keeps rewriting the script.

One commenter nailed it with surgical precision: “Since DHH got the Shopify board membership and went from an AI skeptic to an AI shill, I welcome this fork.”

That’s not a technical critique. That’s a trust breakdown.

Open source doesn’t die from missing features. It dies when the community stops believing the person holding the keys shares their values.

Think about what’s actually happening here. For nearly two decades, Rails developers built their careers, their companies, and their identities around a framework that promised convention over configuration, happiness over hype. DHH was the philosophical anchor — opinionated, yes, but principled. You knew where he stood because his stance was consistent with the framework’s DNA.

Then came the Shopify board seat. Then came the AI enthusiasm. Then came the posts that read like they were generated by the very tools he was promoting — flat, performative, hollow. The community noticed. They always do.

And here’s where it gets uncomfortable: the fork’s loudest advocates can’t even articulate a technical justification. As one commenter pointed out, “There’s no real substance behind the fork other than ‘I don’t like DHH.'” On the surface, that sounds like a weakness. It’s actually the whole point.

When someone says ‘I don’t like the direction this is going’ and can’t point to a single broken feature, they’re not talking about software. They’re talking about soul.

Every Rails developer now faces a question that has nothing to do with performance benchmarks or migration paths. The question is: do you stay on a framework led by someone whose values you no longer recognize? Or do you bet your career on a fork with no technical justification, led by people whose main qualification is that they’re not him?

That’s a terrible choice. And it’s the kind of choice that only exists when leadership fails.

Because here’s what DHH seems to have forgotten — or decided he no longer cares about: Rails was never just code. It was a community held together by shared philosophy. The framework’s famous “programmer happiness” wasn’t a marketing slogan. It was a covenant. You optimize for developer joy, you resist hype, you ship real things for real people.

When the person who wrote that covenant starts posting AI-generated enthusiasm pieces that read like sponsored content, the covenant breaks. Not in the codebase. In the trust.

The most dangerous thing a leader can do isn’t make a wrong technical decision. It’s make the community wonder whose side they’re really on.

The comment about the submission being flagged is its own quiet tragedy. A fork of the most famous web framework in the world — arguably the most significant event in the Rails ecosystem in a decade — gets buried while a Muse 30B model nobody can run on a normal PC gets top billing. The platform itself seems allergic to the conversation.

But that’s how these stories usually go. The real fracture happens quietly, in the spaces between official channels. In private Slack channels where senior Rails devs ask each other, “Are you thinking about switching?” In the GitHub issues where maintainers go silent. In the conference talks that get quietly declined.

The fork may fail. It probably will. Most forks do. But that’s not the story.

The story is that it existed at all — that a feature-complete framework with a two-decade track record still drove people to walk away. Not because the code broke. Because the person at the top changed.

A framework can survive bugs, outages, and competing standards. What it cannot survive is a leader who treats the community’s identity like a personal wardrobe — something to be swapped when the trend changes.

If you’re a Rails developer right now, you don’t need a migration plan. You need to decide what you’re loyal to: the code, or the person who controls it. And if those two things have finally diverged — well, that’s not a technical problem. That’s a reckoning.