The argument that “Rails is done” is one I have been hearing quietly from senior Rails developers for the better part of two years. The framework has reached a state where the core routing, controller, model, and view layers barely move. Releases since 6.0 in 2019 have mostly added optional packages, swap-in backends, and tooling that lives outside the core gems. The version-after-version cadence has produced releases that look impressive in the changelog and that ship almost no behavior change in the parts of Rails that actually answer a request. That mismatch is the wedge a new fork is now trying to drive.
The fork, currently going by the working name Amiko, is not a competitor to Hanami, Bridgetown, or Roda. It is closer to a long-term-support branch of the current Rails maintained by people who explicitly do not want to ship a new feature every quarter. The thesis is that Rails 8 is already the Rails most apps actually need, and what is missing is a community that ports security patches, evaluates performance improvements carefully, and keeps the framework boring for the next several years. That is a different value proposition than “rewrite your app,” and it lands in a different part of the decision space than anything in the Ruby web space today.
What “done” actually means when the package manager keeps shipping
The clearest signal that the core is settled is what rails new --minimal produces. The minimal app pulls in six gems: railties, actionpack, activesupport, activemodel, activerecord, and actionview. Those are the parts of Rails that have to move together to keep a request-response cycle working. Look at the changelog for those six gems since 6.0 and the volume is small. Zeitwerk landed in 6.0. ActiveRecord picked up composite primary keys, at-work encryption, asynchronous query loading, and a handful of authentication methods. Outside that, the change log is bug fixes and deprecation warnings.
What has changed is everything that hangs off those six. Asset pipelines have cycled through Sprockets, webpacker, jsbundling-rails, importmap-rails, and propshaft. The JavaScript story is whatever Hotwire, Stimulus, and Turbo you want to slot in. Kamal appeared as a deployment tool that is happy to ship any containerized web app, not just Rails. A reverse proxy written in Go, a default caching backend, a default ActiveJob backend, a default ActionCable backend. Each of those is a gem or an npm package you can replace if you do not like it. The pattern is the same: optional layer, swappable, no behavior change in the core that would force you to upgrade it.
That shape is what “done” means in this context. The framework is not a frozen codebase. The team that maintains it is still active, still merging pull requests, still shipping releases. The framework just no longer needs sweeping rewrites of its core to keep up with the web. Every release is mostly a new optional component, a security fix, and a small performance improvement. The implication is that if your real complaint about the current Rails is the behavior of the people running the project, you do not need to throw Rails out. You need to fork the maintenance work.
What the fork is actually trying to be
The stated goal of Amiko, as the post that started this conversation describes it, is a long-term-support version of Rails 8 maintained by a community that has decided which values it will and will not tolerate. Every existing Rails 8 application should be able to switch over by swapping a set of gem aliases, running a handful of search-and-replace operations, and deploying. Target users are teams that already have a Rails app they cannot “just rewrite in Hanami” and that want a stable place to land for the next several years.
Borrowing more from the way Debian or PostgreSQL maintain a long-term branch than from the way most Ruby projects ship, the working group treats “stable target” as the design center. There is a clear stable target. There is a small group of people who can invest significant time. The job is to monitor the upstream repository for security patches, port those patches, and evaluate performance and small improvements on their own merit. New features are not the goal. Compatibility-breaking changes are not the goal. The work that earns a commit is the work that keeps a running app secure and fast without requiring the application team to relearn the framework every eighteen months.
The current name is Amiko, and the project is small enough that the name will probably change before the first tagged release. The point of the name is not the name. The point is that there is a Matrix room, there are spikes for how the fork will work, and there is at least one public way to join if you are interested. The question is whether the working group can hold the boring-and-friendly line under pressure from people who want to ship ambitious changes.
Where the framework’s loosest seams are
The argument is not that Rails has no rough edges. The asset pipeline has been in a state of half-working chaos since 2021. There is a real discussion to be had about how a future “Amiko new” would handle asset bundling, and there is a real case to be made that the answer is to do less in the framework and rely on the JavaScript side to keep up with bundling innovation. There are smaller seams too. The “omakase versus fast food” debate about how opinionated the framework should be is real. The current core team’s choice of opinionated default gems is a defensible engineering decision, and it is also a decision that some teams do not want.
The fork inherits all of those seams. It does not pretend they are not there. What it changes is the answer to the question of who decides what to do about them. The current answer is a small group at the top of the project. The forked answer is a community with explicit values, public discussions in chat, and a stated bias toward stability over novelty. Neither answer is automatically better, and the difference matters more when the project ships at the cadence Rails has been shipping at for the last few years.
Beyond the rough edges, the project also has a real set of policy decisions the working group will have to make, and a list of seams that any new Rails 8 fork has to decide on:
- Asset pipeline strategy (keep sprockets, port to propshaft, or punt to importmap)
- Default caching backend (redis, memcached, solid_cache, or hand-rolled)
- ActionCable transport and the default pubsub adapter
- Default testing stack (minitest, RSpec, or both)
- JavaScript side (Hotwire-by-default versus “bring your own”)
- ActiveJob backend choice for new applications
- Authentication story (the current has_secure_password path versus a heavier third-party gem)
Each of those seams is a place where the fork can either keep the upstream default, swap to a different default, or punt the decision to the application team. Each swap has a real maintenance cost.
What this is not
The fork is not a Hanami competitor. Hanami is a different framework, with a different design, and the people behind it are not what this fork is responding to. The fork is also not a Bridgetown or Roda competitor. Those projects are aimed at teams that want a different shape of web application entirely. Amiko is aimed at teams that want a Rails shape of web application with a different kind of maintenance contract.
That distinction is the part of the conversation that is easy to miss. The complaint that motivates the fork is not “Rails is the wrong shape for a modern web application.” The complaint is that the maintenance contract on the current Rails is not what the community needs right now. There are teams who would never rewrite in Hanami because the existing Rails app is large enough that a rewrite is a multi-year project that does not pencil out. Those teams are the actual addressable audience.
Trade-offs
A maintenance-focused fork has to make some hard calls about what to ship and what to leave alone. Strictness on the boring-and-friendly line is the first. If the fork says yes to every performance improvement that lands in upstream, it ends up shipping a release every quarter and the boring promise erodes. If it says no to almost everything, security patches queue up and the LTS promise becomes a security liability. Picking the right middle is a social problem as much as a technical one, and the fork is too new to have an answer yet.
Community scale is the second hard call. Forks that try to replace the upstream project have to grow a contributor base that can carry a serious maintenance load. The people behind Amiko have signaled that the bar is to monitor for security patches, port them, and pick the occasional performance improvement. That is a tractable workload for a small group. It is a much larger workload if the project decides to support every supported Ruby version, every database backend Rails supports, and every operating system package manager in the wild. The community will have to choose a support matrix that is narrow enough to be sustainable.
Relationship with upstream is the third hard call. The fork’s value proposition depends on a steady stream of patches coming from the upstream repository. Current plan is to follow. That is the right plan for an LTS, and it is also the plan that puts the fork’s long-term direction at the mercy of the upstream project’s decisions. The forked project will have to keep good relationships with the upstream maintainers even when those maintainers do not want to be on good terms.
What I would tell past me
If you are looking at this from the outside and trying to figure out whether to wait for Amiko to mature or to keep building on current Rails, the practical answer is to keep building on current Rails. The fork is too new to migrate an existing app to without a long evaluation period, and the value proposition is most felt after you have been on the same Rails version for a year or two. A team starting a new Rails app today should still pick current Rails.
A team about to start a long-running maintenance contract for an existing Rails app should pay closer attention. If the working group can land a first release in a stable shape and prove the maintenance model on one or two backports, the option value of a friendly LTS branch of Rails 8 starts to matter for any team whose app will outlive the next eighteen months of normal Rails releases. That option does not exist today, and it is the part of this story that the headline misses.
The bigger lesson is that the Ruby web framework world is not a monoculture anymore, and that is a healthy place for it to be. Current Rails, the upcoming Hanami, Bridgetown for static-first sites, Roda for small apps, and a friendly LTS fork for the existing app you cannot rewrite are all distinct options aimed at different jobs. Picking the right one starts with naming the job.