The bootstrap for RVM 2.0 is something we're thinking about very seriously, to make sure it's handled properly and isn't brittle. As an rvm maintainer, one of t

The bootstrap for RVM 2.0 is something we're thinking about very seriously, to make sure it's handled properly and isn't brittle. As an rvm maintainer, one of the most frustrating things about working on it is how untestable and how brittle the installation (rvm + all build deps required to get a ruby built locally) can be. It's a known problem and one of the current big design issues, especially because rvm is so complex today in what it's capable of on the user's behalf, so we plan to get that right first time as much as we can. I agree with you on both of your points: the BountySource page is a bit hand wavy, although there's only so much room to spell out what we think our benefits are; that rvm can make life more complicated, not simpler. I come to the project late in its life and I'm well aware it's a bit of a beast in many ways, so I can at least say that I'll be pushing Michal towards simplicity. It's one of the reasons 2.0 exists, rather than us heading towards 1.3 instead. It's just too hard to make large changes to 1.2 now, mostly because of the complexity inherent to being a shell program that works (mostly!) portably on the myriad OSes we now support.