Seit einigen Jahren hat sich Ruby durch den Erfolg von Rails neben anderen Skriptsprachen wie PHP, Perl und Python einen festen Platz in Webhosting-Stacks gesichert. Wo allerdings mehrere Ruby-Versionen gleichzeitig genutzt werden, ergeben sich schnell Probleme.

Zudem wird die Auswahl an möglichen Ruby-Interpretern und -Versionen zunehmend unübersichtlich. Der klassische Ruby Interpreter – oft nach seinem Haupt-Entwickler "Matz's Ruby Interpreter" oder kurz MRI [2] genannt – wird durch Änderungen, die die Rückwärtskompatibilität brechen, derzeit im 1.8er und 1.9er Branch gepflegt. Projekte, die auf Ruby 1.8 setzen, nutzen für den Live-Betrieb nicht selten die um einen verbesserten Garbage Collector erweiterte Ruby Enterprise Edition (REE)[3]. Java-nahe und Performance-kritische Projekte setzen mit JRuby [4] eine Ruby-Implementation in Java ein, um etwa in einem Rails-Projekt von Java-Bindings zu profitieren.

Zugleich gibt es mit Rubygems [5] einen De-facto-Standard für Erweiterungen, vergleichbar zu Perl CPAN, PHP Pear und Python Eggs. Gems werden über ein eigenes Paketmanagement verwaltet, was die Arbeit zwar zunächst vereinfacht, bei mehreren Projekten mit verschiedenen Gem-Abhängigkeiten aber schnell unübersichtlich werden kann. Einen Ausweg aus der komplexen Verschränkung von Ruby-Interpretern und -Versionen sowie Gems bietet »rvm« [1] mit der Möglichkeit, projektbasierte Umgebungen zu pflegen.

Die Standard-Installation von »rvm« gestaltet sich einfach, wenn auch für Administratoren eher ungewohnt. Wie in der Ruby-/Rails-Welt nicht selten, wird das Installationsskript