Earlier quoted context omitted.
By extension, Rails is built on a house of cards - a language team that does not intend to support it, and doesn't care if they cause a majority of their international users a great deal of pain. That would be, as I said before, disappointing and frustrating. While the MRI team benefits enormously from the international success of Ruby that is largely attributable to Rails, you are right that they are not technically…
In open source, nobody is entitled to someone else's time and energy. But that's what the word "irresponsible" implies. So, I think you should choose your words more carefully. As regards the technical problems you're talking about, switch Rubies (I'm a fan of JRuby), or fork MRI.
My words are chosen pretty carefully. Irresponsible implies just that - irresponsible. Taken to its extreme it would be irresponsible for Matz or Linus to suddenly retire from their projects without a trace. Nobody is entitled to have them continue to work on these projects unless they have a business engagement ("open source" has nothing to do with it.) That doesn't make it ok to abandon people who have come to depend on them, who have made them successful, and who have supported them. There are responsible and irresponsible ways to leave a project.
Case in point: _why left an awesome legacy, but screwed a number of people over by disappearing. People have reasons for behaving irresponsibly sometimes, it can be forgiven, and it doesn't mean they are bad people - but that doesn't make it any less irresponsible.
Even your employer is not entitled to have you finish projects you start before quitting, or to have you cooperate in knowledge transfer when you leave - you could quit at any time and provide the minimal contractually required information. Responsible? No.
So yes, the stewards of open source project do have some responsibility to their user base. "Fork it" is the standard, poorly thought through, open source geek answer. It is far more beneficial for everyone to work within the community and voice concerns than it is to fracture the code base. Additionally, there are many layers of software all of which no one is an expert in, and forks introduce their own management headaches. I for one would not be comfortable supporting a fork - I depend on the MRI team for that. We all depend on each other, and anyone claiming they have no responsibility to their user base should let their users know they feel this way so that the users can choose a different library or platform.