[patio11]

What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications?

Step 1: Learn to speak Japanese. Step 2: Express that the startup speed of a project that, IIRC, none of them use and that doesn't pay the bills at their day jobs is Really Really Important To White People and that anything which compromises its utility -- which should be checked exhaustively at every release -- should block shipping.

I use Rails, and love Rails, but back home Rails is not yet the core Ruby use case, not by a long shot. Rails has peculiar needs with regards to typical Ruby applications, and a certain portion of the developer community feels that people who write themselves peculiar needs can write their own solutions to them. (i.e. "If they're going to run tests every few seconds and load a thousand files every time it runs... why is poor performance our problem again?")

Apologies for being a wee bit snippy but variations on this discussion have come up before.

[aneth]

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 obligated to promptly fix egregious performance regressions. A certain portion of the developer community might feel that it is irresponsible not to support your user base.

[tptacek]

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.

[aneth]

> 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.

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.