Kickstarter: rails.app

Especially since this is coming from Yehuda Katz. I've seen several people using things like Gun.io to fund patches and small additions to open source libraries, but it always seems to come from people you never see in the community - outsourcers, or people who just aren't that into coding but still code. But once a leader in the community does this... It's up in the air what this will do long term.

Here's one possible outcome. It becomes "cool" to crowd fund open source projects, so a few of the up-and-coming coders with new open source projects start doing this too. In a year or two, a big chunk of the top coders are charging to do open source work. It's a badge of worthiness... Coderwall.com get's it's "$25k+ achievement" badge.

Then one of two things can happen. The unlikely thing is, it evens out, there's a happy balance - some people charge, some people don't. Much more likely is people either start charging ridiculous amounts, the quality of free open source projects drastically decreases, or people start keeping their projects to themselves. This eventually leads to rebellion, and the true ones left start ANOTHER Free Software Foundation that gets back to the roots.

This kind of stuff happens, out of seemingly innocent and well-intentioned moves.

Like everyone's said, companies like 37signals and all the companies we work at fund open source projects, so one way or another we're getting some sort of payment. It's totally cool to make money off your open source work like this, nobody really sees it even though we all know. It's this indirectness that keeps the community healthy. It creates a feeling of open-ness. A culture. Asking for money directly like this doesn't make things feel open anymore, and like everything it will spiral.

But, they break.

The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters).

Isn't rails the one with the 17 different testing frameworks and TDD kool-aid? How about adding structured tests for the installation procedure, too?

Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable.

Hint one, two, three

The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?).

answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?"

That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies).

The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation).

It's not as hard as you make it out to be, really.