From completely outside the community... this seems like wishcasting, including the headline? I thought this was going to be something like "now that LLMs can generate your routes and SQL, you don't need to write web apps in a high level language anymore", or "now that LLMs can port things to another language, you can lower your Rails app into Rust for performance" or something. Instead, this seems like "we don't like his politics and he sucks all the air out of the room so we're storming out of the room". In fact, he says they already stormed out of the room and no one cared so they're forking? I'm not bothered by people forking, I'm bothered by stupid headlines.
I'm confused by this response. It's relatively clear that the title is a reply to Ryan Biggs talk that outright refuses the possibility of creating a Rails fork for momentum reasons. Ryan also asserts they should all move to Hanami.
I think you are reading too much into what he is writing. Lucas only does his due diligence to show that attempts have been made to clear the air in the room. A serious attempt at a fork - however - has not been attempted. And, as he lays out - it's quite feasible, especially, because Rails is in a "done" state, with not many surface changes expected.
It's very clear that the title is a reply to Ryan Biggs talk that outright refuses the possibility of creating a Rails fork for momentum reasons.
Is it very clear to someone from outside the community? I don't see that talk mentioned anywhere. All I got when I clicked through the rationale was "DHH is the Fox News of Ruby".
You're saying "done" in this context means "feature complete" not "sent to the trashbin"? First, still a crappy headline. Next question is naturally, so if it's "done" why fork?
Edit: I searched around for "bigg" to find anywhere I missed. Turns out the last name is written "Big" in the post. You're talking about his blog post on Hanakai? Something else I've never heard of.
Next question is naturally, so if it's "done" why fork?
Feature complete software still needs maintenance. Well, some very simple software can be fully "done" and require no further changes ever, but Rails is nowhere near that level of simplicity.
Feature complete software still needs maintenance.
Aha so why should anyone use this maintenance-mode fork that no one's ever heard of, over mainline Rails which has been led by the same guy over its existence, other than political grievances against the lead dev? I immediately[1] assumed that's what this all was, just knowing how open source is, so I went looking for counter-examples to prove me wrong and I immediately get "Fox News of Ruby" and complaining about his politics. Unserious.
[1] (edit) well, I guess second after thinking it would be about LLMs
Why is it so hard to believe that extreme political grievance is a reason to use alternative software, whether it's a fork or a different framework entirely?
Strawman. I believe it is for some, for sure. Whether a political disagreement is a suitable basis for a parallel technical project... well, we certainly don't need to argue about it now, we'll see where they are in 5 years.
You think it’s a strawman that some people don’t want to have to interact with a guy who says that London has too many brown people and that Denmark should deport gypsies?
You are seriously underselling how disgusting dhh's political views are. And those views matter, because if you are a member of one of the numerous groups dhh is bigoted against, are you going to contribute to Rails?
You are seriously underselling how disgusting dhh's political views are.
I am... searches brain I guess completely unaware of DHH's opinions? I know he made Rails and got rich and now drives fancy cars. I know wars have been fought for minor disagreements about theology, and I know people throw around words like "Nazi" today like candy, so... lol I'm literally scratching my head about how to continue this sentence. People are actually nuts! My priors are that the folks who'll split a technical project over someone's private views are probably the bad guys. Note that this comment was not a request to inform me all about how "disgusting" his views are.
Literally read any of his own public statements that people are criticizing, which they link, before forming an opinion - too much to ask? It's pretty irrational to be willfully ignorant of something but assume that people upset about it must be nuts or "the bad guys" anyway.
Consider a less controversial example: Eric S. Raymond. Currently he is ranting on X about "low IQ savages" for whom "segregation, sundown towns, lynchings" are a "rational containment strategy". And yes, these are literal quotes. And in context they're even worse.
You talk about "private political views", but they're not really "private", are they? If they would keep their views reasonably private then that would be different, but they're not. Both esr and DHH are using the "fame" they gathered from their programming activities to advance a bunch of viewpoints. That's fine, but it's also fine to judge them for it. Or even distance yourself from them over it (I scrubbed all mentions of esr from my site when I learned of this).
Surely you can't fault someone for not wanting to engage with someone who seems to quite literally advocate for the lynching of black people (or in his words, "low IQ savages").
DHH is nowhere near as extreme as esr, mind you. My point is only to explain that the specifics matter and can't just be handwaved away. If you want to argue that DHH's views are not a big deal then that's fair. Proudly declaring your ignorance of them and declaring you have no interest is quite a different matter.
As a general point I am broadly sympathetic to your point of view. And I don't trust 3rd party write-ups on how bad someone's views are either (the "boy who cried racism"-effect is real).
If you don't want to know what DHH writes about this then that's fair enough. Lots more interesting things to read about in the world. But then you maybe also shouldn't posting strong opinions on it. Coming in with generalised abstracts when dealing with a specific case is just rarely useful. I would certainly be embarrassed posting such strong opinions while also so proudly declaring how little I know about the specifics.
He's run the project for decades, and suddenly he's problematic in any way that matters to the project? Go ahead, fight your own political battles, I'm not going to be shamed by the latest attempt at cancellation. Have fun!
This does not engage even in the slightest with what I wrote.
Let me ask directly and clearly: do you think it's reasonable to distance yourself from someone ranting about "low IQ savages" for whom "segregation, sundown towns, lynchings" are a "rational containment strategy"?
Which, to be open, I find a poor post. It does not even present well why Amiko is a virtue-signalling attempt and not a serious project.
I understand your point of wanting people to join your side (and - as an ex-lead of the Padrino project, where much get the feeling). But some people are okay with the Rails way.
The problem of writing such post is:
Should Amiko actually succeed at the goals they are setting themselves, you set a tone of non-collaboration.
Should Amiko not succeed, but people want to spend their time elsewhere, you just lowered your chances of them joining you.
The people running Amiko are not unknown people in the Rails space, so there's definitely serious power behind it.
I seriously don't understand what your goal with this post is.
The title is definitely misleading, though. Nothing about it suggests any of the obvious points you mentioned, unless you’re already into the anti-DHH movement or have been following all the niche topics and ideologies around every technology and person mentioned in the article.
"Feature complete", like another user mentioned would've been a nice, positive read instead.
This obsession with being anti-DHH is kind of weird to me. Most people in my circle couldn’t care less about his blog posts or personal views, for the same reason we don’t care about every tech CEO’s opinions.
By all means, fork it. More alternatives are great. But if the main selling point is simply that it’s not made by DHH, I’d just ignore it.
we don't like his politics and he sucks all the air out of the room so we're storming out of the room.
That's not what the post saying.
It's saying that they're a group of people who fork Rails and are going to keep maintaining Rails separately from DHH. They're saying that this is possible for a relatively small team of volunteers because Rails is done. It's not a rapidly evolving project which needs tonnes of man-hours to keep up with. I don't know if it's correct, but that's the argument.
Assuming it's right, and given the damage association with DHH does to a project like Rails, I wish the Amiko project well. It seems like it could serve as a nice alternative to Rails for people who are deeply invested in the technology but don't like its leadership. (Maybe even lobste.rs could eventually move to it?)
That's cool, that sounds like the GNU project not wanting to use any liberally licensed software in their linux distribution. Not being totally free is icky on ideological grounds. Everyone can use what they want ¯\_(ツ)_/¯ But in that situation, GNU will use different free implementations of things. With Rails... will checks notes Amiko just maintain downstream Rails compatibility? In which case it's just a "Rails distribution" that's less icky somehow because they changed the name and added a text file in protest?
It's too early to tell what Amiko ends up being. If it's a hard fork except for the occasional bug fix backport, it's different than if it's a soft fork which just becomes a Rails downstream.
Is Michael Hartl still in the Rails world and/or on Lobsters? His voice is the one that introduced me to RoR and I wonder what his opinion is on how complete the core of the project is and the viability of forks like the ones listed in this article.
how complete the core of the project is and the viability of forks like the ones listed in this article.
The "core of Rails" being "done" isn't wrong from a user perspective. As in, the bread and butter APIs have largely stabilized. Not necessarily because they're perfect, but because the cost of significantly breaking them now largely outweigh the benefits.
But from a maintainer perspective it absolutely isn't done.
The more mundane maintenance work of fixing bugs, handling security reports, keeping compatibility with other parts of the ecosystem, improving performance, etc still is a very significant amount of work (you can have a look at GitHub statistics), and even Rails can't quite keep up with the amount of new pull requests and issues (it got noticeably worse since AI became a thing but that's another topic).
That being said, this maintenance load is largely proportional to the popularity of the project. Less users means less people running into bugs, so less bugs to fix in practice.
So I think even a single person could pull it off, given enough commitment.
Where it might get more tricky in the long run is that the public API isn't the whole story. There's hundreds of popular gems integrating more or less tightly in Rails, and not being compatible with those is a deal breaker for many users.
As they diverge (assuming that's what they want to do eventually), they'll become more and more incompatible with these, and whether these related projects will bother to be compatible with Amiko is another question entirely.
As always, the challenging part isn't strictly technical, Rails committers aren't special, tons of other people could do the work. The tricky part is the network effect and the ecosystem fracture.
There is a bigger question for me about, are the politics of a person who creates embedded in the thing they created? Is using it endorsing it?
Rails specifically has been made to make projects of every political stripe, so it's hard for me to imagine the mere use of the framework is a political act.
And I have a bit of an allergy to this whole argument given I grew up in a restrictive religious environment that espoused that if you listened to music by someone with an "immoral" lifestyle, that was going to corrupt you.
When I think about selecting a framework, what I want is lots of eyeballs on it, so its hard to reject Rails from that perspective.
There is a bigger question for me about, are the politics of a person who creates embedded in the thing they created? Is using it endorsing it?
You’re essentially asking the same question as to whether or not we can separate art from the artist, and I strongly believe the answer is “no”. This article about the false comfort of separating the art from the artist describes all of the issues with the attempt to do so better than I can but, whether we realize it or not, our views and beliefs inform what we make and bleed into it in many ways that range from obvious to subtle. There is no separating the art from the artist because the art IS the artist.
That being said, I don’t think I’d go so far as to say that using a thing is tacit endorsement of the person or people who made the thing. We live in a global economy in the digital age and make dozens (if not hundreds) of micro-decisions every single day about the things we use and we cannot possibly know who is behind all of them. Even when it comes to the things we do have background on, our choices come down to series of tradeoffs about what decisions we can make to have a better impact while also not causing ourselves such a high burden that we burn out from decision paralysis while trying to distance ourselves from every single bad thing.
It's a very different argument for the project. It's not that much about contributors/users changes by association. It's that I want people welcome in Rails and not needing to weigh contributing/using against giving slightly more influence to a person who hates who they are and their lives.
Because next time it can be you, your coworker, your friend, etc. It's the usual: software projects are not apolitical, most project leaders just don't stand against your life. Imaging telling someone "Just send a change to this guy. Yeah, the one who wants you thrown out of the country and thinks your kids are retarded. You can totally have a reasonable tech conversation."
The politics of a person who creates is embedded in the thing they created when the person who creates the thing is still face of the project. Literally. DHH's face is featured prominently on https://rubyonrails.org/.
If the Ruby on Rails project publicly distanced itself from DHH, maybe your question would have some merit. Like how Mojang and Microsoft has completely separated Minecraft from Notch, as an example. But that's clearly not the case here.
Given projects of every political stripe use Rails, if usage of Rails is endorsement, then it results in a situation where left and right groups end up endorsing his views. Usage isn't endorsement, it needs a stronger act. And it's a pivot though to go from "politics of a person who creates is embedded" to "DHH's face is featured prominently". The homepage point is a much stronger one and I totally concede that.
However, if I'm selecting a framework I still find it hard to argue against maturity and eyeballs as the primary criteria in selection.
Choosing Rails may very well be the right choice for a particular project. If I was already highly familiar with Ruby and Rails and that whole way of doing things, I may still choose Rails as a web framework for a new project. But its continued deep ties to DHH would be a mark against it. At some point, a fork (such as this Amiko) might become reputable enough that I would choose that instead of Rails.
No one is arguing that we should never use anything built by anyone who later became racist.
What people are arguing is that they don't want to actively associate or collaborate with such people.
The difference seems obvious.
William Shockley is actually quite a good example of this:
According to Shurkin, by this time, "His racism destroyed his credibility. Almost no one wanted to be associated with him, and many of those who were willing did him more harm than good".
At the time of his death he was estranged from most of his friends and family, with the exception of his second wife. His children learned of his death by reading his obituary in the newspaper.
My first thoughts echoed what @byroot wrote (and I speak with far less authority than them anyway): Rails may be "done" in the sense that the core features are stable, but rarely is software truly "done".
Thinking aloud, I can foresee four possibilities for Amiko (or for any Rails fork):
(1) It remains a fully-compatible fork-in-name-only.
I include this for logical completeness. The question is whether "Rails without DHH" is a bright-enough North Star to keep people involved for the long haul. I don't have a crystal ball, and I won't speculate.
(2) It provides a better "omakase" experience.
Akimo expands options for functionality while remaining compatible. It adds shims, patches, decorates libraries, et cetera, to facilitate more choices. That sounds great in the idealized world in my head. I could also see that feeling like thankless work, however it does appear to be the initial focus (per the article):
We might also work on some flaws in Rails if we can do that without breaking compatibility.
(3) Some eventual divergence.
The real temptation, and the real unknown, lies here. If the Akimo project lives its best life through the long-running efforts of a team, they may eventually find good reasons to significantly deviate from Rails in this-or-that aspect, in a way that damages compatibility. Should that day arrive, it will be the "proof of the pudding is in the eating" moment. Everyone who has worked with Rails for long enough has their list of things they would have done differently. I sure do. If I were to lend effort to such a fork, I just know I would be increasingly tempted to see one of my pet changes, some how, some way. But because I don't have the spare effort to lend, I shall keep those thoughts to myself.
(4) A positive influence on Rails.
Some combination of good ideas or implementations from (2) or (3) prove so effective or desirable that it leads to Rails adopting some of those itself.
You may already know this, but for anyone unaware, there is some precedent for option 4 with what happened with Merb 16-17 years ago. While it was a clean-room implementation of Rails' ideas, it brought of a lot of ideas (largely modularity/better decoupling of features) to an eventual merge into Rails 3.
Also it was David basically buying out merb. He hired Yehuda to do the merge via 37 signals (now basecamp). Merb was the clearly superior architecture but rails had momentum as a first mover. It is a shame David more or less railroaded (heh) Yehuda when he tried asserting more of his opinions. We’ve lost a lot of good people because of David over the years. I wonder what could have been.
I think if people really want to rally behind forking Rails, I think it would be an interesting idea to re-envision it and not just make a fork. What would a rails for the next decade look like?
It would look like Hanami: https://hanakai.org/hanami. It has learned a lot of the lessons from building Rails applications for over 2 decades and has drastically improved the organisation of those applications.
That would be a different project. This one is explicitly based on the idea that no major changes need to be made to RoR, just bug fixes and the occasional correction of a detail widely recognized to have been a bad idea.
Perhaps my perspective is strange because I have been in the tech world for more than four decades now. I see a few basic kinds of major revisions to large infrastructure-ish software projects:
we found out what the users want and made it more usable for some or all of them (this happens a lot early in project lifetimes, rarely happens in the late stages)
our dependencies changed out from underneath us and we are adapting because we don't want to support the old dependencies as well
we decided to make visible changes because if we only make things better, how will people know we are cool? (this doesn't just affect commercial projects, but it always affects commercial projects that last long enough to change project managers)
we are disgusted by the accumulated cruft and will start over with our much better design (this always needs a new name because disaster follows when people assume it is a simple upgrade)
I can't think of an ideological fork that has ever succeeded (with one caveat). The orange and the red website combined see six or so a year and they all peter out very quickly.
My model is that a fork exists because patches cannot flow bidirectionally between upstream and a user for some reason. The two most common forms are:
patches can't flow to the user for legal reasons, namely upstream relicensed away from open-source, so the fork exists to remain open-source, e.g. Valkey
patches aren't flowing to upstream because they don't want them, and the fork exists to host a large feature, e.g. oven-sh/zig
What is a fork that doesn't have a wall in either direction? Who works on it, and who uses it? If a feature appears upstream, and you're going to integrate it, what are we doing here? But if you're not going to integrate it, how are you going to attract users? And if a patch you create solves some problem, upstream can still integrate it, because it's open-source.
It seems to me that the point of an ideological fork should be to drive an ecosystem split. Accrue users by being the second type of fork on purpose, promising backwards compatibility and bonus capabilities, and hope that forwards incompatibility you create starts becoming a headache of libraries, while remaining more obviously attractive than the competition. You would need to introduce a change that every user wants and sees no downside in, while being a staggeringly large leap for upstream to adopt, and you would need to boil the frog very slowly so that users trust you won't just vanish leaving them with unmaintained software.
Hence the caveat: This seems to be the strategy that Lix is pursuing. They haven't failed yet, but neither have they succeeded, because it takes a ton of work and a really long time. You essentially need to prove that you are a better maintainer than upstream on the technical merits. And if that was the case, why define yourself by ideology? The rallying cry needs to be technical, in order to acquire any users who didn't already agree with you; and you can only end up on the right side of an ecosystem split if you do. But if you don't have a technical vision for the project already, it's unlikely to come to you in a dream, which is also something Lix is struggling with after the Great RIIR.
kbd | 15 days ago
From completely outside the community... this seems like wishcasting, including the headline? I thought this was going to be something like "now that LLMs can generate your routes and SQL, you don't need to write web apps in a high level language anymore", or "now that LLMs can port things to another language, you can lower your Rails app into Rust for performance" or something. Instead, this seems like "we don't like his politics and he sucks all the air out of the room so we're storming out of the room". In fact, he says they already stormed out of the room and no one cared so they're forking? I'm not bothered by people forking, I'm bothered by stupid headlines.
skade | 15 days ago
I'm confused by this response. It's relatively clear that the title is a reply to Ryan Biggs talk that outright refuses the possibility of creating a Rails fork for momentum reasons. Ryan also asserts they should all move to Hanami.
I think you are reading too much into what he is writing. Lucas only does his due diligence to show that attempts have been made to clear the air in the room. A serious attempt at a fork - however - has not been attempted. And, as he lays out - it's quite feasible, especially, because Rails is in a "done" state, with not many surface changes expected.
kbd | 15 days ago
Is it very clear to someone from outside the community? I don't see that talk mentioned anywhere. All I got when I clicked through the rationale was "DHH is the Fox News of Ruby".
You're saying "done" in this context means "feature complete" not "sent to the trashbin"? First, still a crappy headline. Next question is naturally, so if it's "done" why fork?
Edit: I searched around for "bigg" to find anywhere I missed. Turns out the last name is written "Big" in the post. You're talking about his blog post on Hanakai? Something else I've never heard of.
muvlon | 15 days ago
Feature complete software still needs maintenance. Well, some very simple software can be fully "done" and require no further changes ever, but Rails is nowhere near that level of simplicity.
kbd | 15 days ago
Aha so why should anyone use this maintenance-mode fork that no one's ever heard of, over mainline Rails which has been led by the same guy over its existence, other than political grievances against the lead dev? I immediately[1] assumed that's what this all was, just knowing how open source is, so I went looking for counter-examples to prove me wrong and I immediately get "Fox News of Ruby" and complaining about his politics. Unserious.
[1] (edit) well, I guess second after thinking it would be about LLMs
davidcelis | 15 days ago
Why is it so hard to believe that extreme political grievance is a reason to use alternative software, whether it's a fork or a different framework entirely?
kbd | 15 days ago
Strawman. I believe it is for some, for sure. Whether a political disagreement is a suitable basis for a parallel technical project... well, we certainly don't need to argue about it now, we'll see where they are in 5 years.
yawaramin | 15 days ago
You think it’s a strawman that some people don’t want to have to interact with a guy who says that London has too many brown people and that Denmark should deport gypsies?
hjvt | 15 days ago
You are seriously underselling how disgusting dhh's political views are. And those views matter, because if you are a member of one of the numerous groups dhh is bigoted against, are you going to contribute to Rails?
kbd | 15 days ago
I am... searches brain I guess completely unaware of DHH's opinions? I know he made Rails and got rich and now drives fancy cars. I know wars have been fought for minor disagreements about theology, and I know people throw around words like "Nazi" today like candy, so... lol I'm literally scratching my head about how to continue this sentence. People are actually nuts! My priors are that the folks who'll split a technical project over someone's private views are probably the bad guys. Note that this comment was not a request to inform me all about how "disgusting" his views are.
bmo | 15 days ago
Literally read any of his own public statements that people are criticizing, which they link, before forming an opinion - too much to ask? It's pretty irrational to be willfully ignorant of something but assume that people upset about it must be nuts or "the bad guys" anyway.
arp242 | 15 days ago
Consider a less controversial example: Eric S. Raymond. Currently he is ranting on X about "low IQ savages" for whom "segregation, sundown towns, lynchings" are a "rational containment strategy". And yes, these are literal quotes. And in context they're even worse.
You talk about "private political views", but they're not really "private", are they? If they would keep their views reasonably private then that would be different, but they're not. Both esr and DHH are using the "fame" they gathered from their programming activities to advance a bunch of viewpoints. That's fine, but it's also fine to judge them for it. Or even distance yourself from them over it (I scrubbed all mentions of esr from my site when I learned of this).
Surely you can't fault someone for not wanting to engage with someone who seems to quite literally advocate for the lynching of black people (or in his words, "low IQ savages").
DHH is nowhere near as extreme as esr, mind you. My point is only to explain that the specifics matter and can't just be handwaved away. If you want to argue that DHH's views are not a big deal then that's fair. Proudly declaring your ignorance of them and declaring you have no interest is quite a different matter.
As a general point I am broadly sympathetic to your point of view. And I don't trust 3rd party write-ups on how bad someone's views are either (the "boy who cried racism"-effect is real).
If you don't want to know what DHH writes about this then that's fair enough. Lots more interesting things to read about in the world. But then you maybe also shouldn't posting strong opinions on it. Coming in with generalised abstracts when dealing with a specific case is just rarely useful. I would certainly be embarrassed posting such strong opinions while also so proudly declaring how little I know about the specifics.
kbd | 15 days ago
He's run the project for decades, and suddenly he's problematic in any way that matters to the project? Go ahead, fight your own political battles, I'm not going to be shamed by the latest attempt at cancellation. Have fun!
davidcelis | 15 days ago
It's not sudden. People have been talking about this for over a decade even if it has gotten markedly worse in the last 4-5 years.
arp242 | 15 days ago
This does not engage even in the slightest with what I wrote.
Let me ask directly and clearly: do you think it's reasonable to distance yourself from someone ranting about "low IQ savages" for whom "segregation, sundown towns, lynchings" are a "rational containment strategy"?
ryanbigg | 15 days ago
He's referring to my blog post here: https://ryanbigg.com/2026/08/amiko-a-desperate-virtue-signalling-attempt
skade | 14 days ago
Which, to be open, I find a poor post. It does not even present well why Amiko is a virtue-signalling attempt and not a serious project.
I understand your point of wanting people to join your side (and - as an ex-lead of the Padrino project, where much get the feeling). But some people are okay with the Rails way.
The problem of writing such post is:
The people running Amiko are not unknown people in the Rails space, so there's definitely serious power behind it.
I seriously don't understand what your goal with this post is.
azuan | 15 days ago
The title is definitely misleading, though. Nothing about it suggests any of the obvious points you mentioned, unless you’re already into the anti-DHH movement or have been following all the niche topics and ideologies around every technology and person mentioned in the article.
"Feature complete", like another user mentioned would've been a nice, positive read instead.
This obsession with being anti-DHH is kind of weird to me. Most people in my circle couldn’t care less about his blog posts or personal views, for the same reason we don’t care about every tech CEO’s opinions.
By all means, fork it. More alternatives are great. But if the main selling point is simply that it’s not made by DHH, I’d just ignore it.
mort | 15 days ago
That's not what the post saying.
It's saying that they're a group of people who fork Rails and are going to keep maintaining Rails separately from DHH. They're saying that this is possible for a relatively small team of volunteers because Rails is done. It's not a rapidly evolving project which needs tonnes of man-hours to keep up with. I don't know if it's correct, but that's the argument.
Assuming it's right, and given the damage association with DHH does to a project like Rails, I wish the Amiko project well. It seems like it could serve as a nice alternative to Rails for people who are deeply invested in the technology but don't like its leadership. (Maybe even lobste.rs could eventually move to it?)
kbd | 15 days ago
That's cool, that sounds like the GNU project not wanting to use any liberally licensed software in their linux distribution. Not being totally free is icky on ideological grounds. Everyone can use what they want
¯\_(ツ)_/¯But in that situation, GNU will use different free implementations of things. With Rails... will checks notes Amiko just maintain downstream Rails compatibility? In which case it's just a "Rails distribution" that's less icky somehow because they changed the name and added a text file in protest?mort | 14 days ago
It's too early to tell what Amiko ends up being. If it's a hard fork except for the occasional bug fix backport, it's different than if it's a soft fork which just becomes a Rails downstream.
ryan-duve | 15 days ago
Is Michael Hartl still in the Rails world and/or on Lobsters? His voice is the one that introduced me to RoR and I wonder what his opinion is on how complete the core of the project is and the viability of forks like the ones listed in this article.
byroot | 15 days ago
The "core of Rails" being "done" isn't wrong from a user perspective. As in, the bread and butter APIs have largely stabilized. Not necessarily because they're perfect, but because the cost of significantly breaking them now largely outweigh the benefits.
But from a maintainer perspective it absolutely isn't done.
The more mundane maintenance work of fixing bugs, handling security reports, keeping compatibility with other parts of the ecosystem, improving performance, etc still is a very significant amount of work (you can have a look at GitHub statistics), and even Rails can't quite keep up with the amount of new pull requests and issues (it got noticeably worse since AI became a thing but that's another topic).
That being said, this maintenance load is largely proportional to the popularity of the project. Less users means less people running into bugs, so less bugs to fix in practice. So I think even a single person could pull it off, given enough commitment.
Where it might get more tricky in the long run is that the public API isn't the whole story. There's hundreds of popular gems integrating more or less tightly in Rails, and not being compatible with those is a deal breaker for many users. As they diverge (assuming that's what they want to do eventually), they'll become more and more incompatible with these, and whether these related projects will bother to be compatible with Amiko is another question entirely.
As always, the challenging part isn't strictly technical, Rails committers aren't special, tons of other people could do the work. The tricky part is the network effect and the ecosystem fracture.
joshbuddy | 15 days ago
There is a bigger question for me about, are the politics of a person who creates embedded in the thing they created? Is using it endorsing it?
Rails specifically has been made to make projects of every political stripe, so it's hard for me to imagine the mere use of the framework is a political act.
And I have a bit of an allergy to this whole argument given I grew up in a restrictive religious environment that espoused that if you listened to music by someone with an "immoral" lifestyle, that was going to corrupt you.
When I think about selecting a framework, what I want is lots of eyeballs on it, so its hard to reject Rails from that perspective.
davidcelis | 15 days ago
You’re essentially asking the same question as to whether or not we can separate art from the artist, and I strongly believe the answer is “no”. This article about the false comfort of separating the art from the artist describes all of the issues with the attempt to do so better than I can but, whether we realize it or not, our views and beliefs inform what we make and bleed into it in many ways that range from obvious to subtle. There is no separating the art from the artist because the art IS the artist.
That being said, I don’t think I’d go so far as to say that using a thing is tacit endorsement of the person or people who made the thing. We live in a global economy in the digital age and make dozens (if not hundreds) of micro-decisions every single day about the things we use and we cannot possibly know who is behind all of them. Even when it comes to the things we do have background on, our choices come down to series of tradeoffs about what decisions we can make to have a better impact while also not causing ourselves such a high burden that we burn out from decision paralysis while trying to distance ourselves from every single bad thing.
viraptor | 15 days ago
It's a very different argument for the project. It's not that much about contributors/users changes by association. It's that I want people welcome in Rails and not needing to weigh contributing/using against giving slightly more influence to a person who hates who they are and their lives.
Because next time it can be you, your coworker, your friend, etc. It's the usual: software projects are not apolitical, most project leaders just don't stand against your life. Imaging telling someone "Just send a change to this guy. Yeah, the one who wants you thrown out of the country and thinks your kids are retarded. You can totally have a reasonable tech conversation."
mort | 15 days ago
The politics of a person who creates is embedded in the thing they created when the person who creates the thing is still face of the project. Literally. DHH's face is featured prominently on https://rubyonrails.org/.
If the Ruby on Rails project publicly distanced itself from DHH, maybe your question would have some merit. Like how Mojang and Microsoft has completely separated Minecraft from Notch, as an example. But that's clearly not the case here.
joshbuddy | 15 days ago
Given projects of every political stripe use Rails, if usage of Rails is endorsement, then it results in a situation where left and right groups end up endorsing his views. Usage isn't endorsement, it needs a stronger act. And it's a pivot though to go from "politics of a person who creates is embedded" to "DHH's face is featured prominently". The homepage point is a much stronger one and I totally concede that.
However, if I'm selecting a framework I still find it hard to argue against maturity and eyeballs as the primary criteria in selection.
mort | 15 days ago
Choosing Rails may very well be the right choice for a particular project. If I was already highly familiar with Ruby and Rails and that whole way of doing things, I may still choose Rails as a web framework for a new project. But its continued deep ties to DHH would be a mark against it. At some point, a fork (such as this Amiko) might become reputable enough that I would choose that instead of Rails.
bitboxer | 15 days ago
Would you hang Hitlers paintings into your home?
This is the old “separate art from the artist” trope here. You cannot separate them.
johnjoz | 15 days ago
You're responding with a computer using countless transistors, and Shockley was racist way beyond anything DHH says or implies.
https://en.wikipedia.org/wiki/William_Shockley
davidcelis | 15 days ago
this is the epitome of the "we should improve society somewhat" meme
arp242 | 15 days ago
No one is arguing that we should never use anything built by anyone who later became racist.
What people are arguing is that they don't want to actively associate or collaborate with such people.
The difference seems obvious.
William Shockley is actually quite a good example of this:
meowfie | 15 days ago
I think using is endorsing if you are simultaneously aware of the views of the author.
swifthand | 15 days ago
My first thoughts echoed what @byroot wrote (and I speak with far less authority than them anyway): Rails may be "done" in the sense that the core features are stable, but rarely is software truly "done".
Thinking aloud, I can foresee four possibilities for Amiko (or for any Rails fork):
(1) It remains a fully-compatible fork-in-name-only.
I include this for logical completeness. The question is whether "Rails without DHH" is a bright-enough North Star to keep people involved for the long haul. I don't have a crystal ball, and I won't speculate.
(2) It provides a better "omakase" experience.
Akimo expands options for functionality while remaining compatible. It adds shims, patches, decorates libraries, et cetera, to facilitate more choices. That sounds great in the idealized world in my head. I could also see that feeling like thankless work, however it does appear to be the initial focus (per the article):
(3) Some eventual divergence.
The real temptation, and the real unknown, lies here. If the Akimo project lives its best life through the long-running efforts of a team, they may eventually find good reasons to significantly deviate from Rails in this-or-that aspect, in a way that damages compatibility. Should that day arrive, it will be the "proof of the pudding is in the eating" moment. Everyone who has worked with Rails for long enough has their list of things they would have done differently. I sure do. If I were to lend effort to such a fork, I just know I would be increasingly tempted to see one of my pet changes, some how, some way. But because I don't have the spare effort to lend, I shall keep those thoughts to myself.
(4) A positive influence on Rails.
Some combination of good ideas or implementations from (2) or (3) prove so effective or desirable that it leads to Rails adopting some of those itself.
peterc | 15 days ago
You may already know this, but for anyone unaware, there is some precedent for option 4 with what happened with Merb 16-17 years ago. While it was a clean-room implementation of Rails' ideas, it brought of a lot of ideas (largely modularity/better decoupling of features) to an eventual merge into Rails 3.
schneems | 15 days ago
Also it was David basically buying out merb. He hired Yehuda to do the merge via 37 signals (now basecamp). Merb was the clearly superior architecture but rails had momentum as a first mover. It is a shame David more or less railroaded (heh) Yehuda when he tried asserting more of his opinions. We’ve lost a lot of good people because of David over the years. I wonder what could have been.
mitsuhiko | 15 days ago
I think if people really want to rally behind forking Rails, I think it would be an interesting idea to re-envision it and not just make a fork. What would a rails for the next decade look like?
ryanbigg | 15 days ago
It would look like Hanami: https://hanakai.org/hanami. It has learned a lot of the lessons from building Rails applications for over 2 decades and has drastically improved the organisation of those applications.
dsr | 15 days ago
That would be a different project. This one is explicitly based on the idea that no major changes need to be made to RoR, just bug fixes and the occasional correction of a detail widely recognized to have been a bad idea.
Perhaps my perspective is strange because I have been in the tech world for more than four decades now. I see a few basic kinds of major revisions to large infrastructure-ish software projects:
we found out what the users want and made it more usable for some or all of them (this happens a lot early in project lifetimes, rarely happens in the late stages)
our dependencies changed out from underneath us and we are adapting because we don't want to support the old dependencies as well
we decided to make visible changes because if we only make things better, how will people know we are cool? (this doesn't just affect commercial projects, but it always affects commercial projects that last long enough to change project managers)
we are disgusted by the accumulated cruft and will start over with our much better design (this always needs a new name because disaster follows when people assume it is a simple upgrade)
mitsuhiko | 15 days ago
In a way, so was Ruby on Rails 3. Would not be uncalled for at all.
srcrip | 15 days ago
Counterpoint: move to Phoenix/LiveView! You can laugh at DHH from afar like a bad memory.
pie_flavor | 14 days ago
I can't think of an ideological fork that has ever succeeded (with one caveat). The orange and the red website combined see six or so a year and they all peter out very quickly.
My model is that a fork exists because patches cannot flow bidirectionally between upstream and a user for some reason. The two most common forms are:
What is a fork that doesn't have a wall in either direction? Who works on it, and who uses it? If a feature appears upstream, and you're going to integrate it, what are we doing here? But if you're not going to integrate it, how are you going to attract users? And if a patch you create solves some problem, upstream can still integrate it, because it's open-source.
It seems to me that the point of an ideological fork should be to drive an ecosystem split. Accrue users by being the second type of fork on purpose, promising backwards compatibility and bonus capabilities, and hope that forwards incompatibility you create starts becoming a headache of libraries, while remaining more obviously attractive than the competition. You would need to introduce a change that every user wants and sees no downside in, while being a staggeringly large leap for upstream to adopt, and you would need to boil the frog very slowly so that users trust you won't just vanish leaving them with unmaintained software.
Hence the caveat: This seems to be the strategy that Lix is pursuing. They haven't failed yet, but neither have they succeeded, because it takes a ton of work and a really long time. You essentially need to prove that you are a better maintainer than upstream on the technical merits. And if that was the case, why define yourself by ideology? The rallying cry needs to be technical, in order to acquire any users who didn't already agree with you; and you can only end up on the right side of an ecosystem split if you do. But if you don't have a technical vision for the project already, it's unlikely to come to you in a dream, which is also something Lix is struggling with after the Great RIIR.