Rubyは現在、興味深い（不愉快ともいえる）状態にある。なぜなら、機能が変わると実装/ブランチが異なるからで、いつもと違ってJRubyやRubinius、MagLev、IronRubyといった競争相手のことを言っているのではなく、Rubyのバージョン1.8.6、1.8.7、1.9.1のことを言っているのである。
Ruby 1.9.1初の安定リリースが出たのは数週間前で、やっと実験段階が終わり、1.8のラインから開発者を取り込み始めている。2008年5月にリリースされた1.8.7は機能とAPIの変更をバックポートすること(参考記事)により、1.8から1.9への移行を楽にしようとした。残念ながら、ライブラリとフレームワークがこの新しいマイナーリリースで常にうまく動くわけではなかったので、多くの人が1.8.7に手を出さなかった。他のRuby実装においても1.8.7の採用はどちらかと言えばゆっくりで、結果的にJRubyでは完全に1.8.7をスキップすることとなった (参考記事)。
こういう理由で、現在使用されていて、Rubyの中心的な開発者らがメンテナンスを行っているMatzのRubyには、少々互換性のないバージョンが3つ存在する。現状について現在行われている議論では、1.8.6のメンテナンス権を他者に譲ってはどうかとRubyのコアチームに提案されることとなったが、現在のメンテンス者であるShyouheiは乗り気なようだ(リンク)。Engineyard（Ruby 1.8.6上で約6,000基の仮想マシンを動作中(リンク)で、アップグレードを予定していない）のEzra Zygmuntowicz氏(リンク)は「Ruby 1.8.6のメンテナーを引き継ぐことは名誉である」と言っており、Shyouheiもこれを歓迎して(リンク)、「他の誰にもその気がないなら、Ruby 1.8.6の管理権をEngineyardに渡すことに異論はない」と述べている。
GitHubに移動すべきか否か、どのパッチをバックポートすべきか(リンク)など、まだ議論中の問題もある。非常に期待できそうなのがBrent Romanの「MBARI」パッチで、このパッチでは長いこと解消されなかったメモリリークとRuby GCに伴う問題（InfoQではMBARIパッチとその働きについて、すでに記事を掲載済みである(参考記事)）を修正している。 Zygmuntowicz氏のメーリングリストの投稿には次のような記述がある:
私たちは現在、Brentがパッチを1.8.6にポートできるよう支援中で、このパッチがRubyのメインラインである1.8.6、1.8.7、1.8.*と一体化することを心から望んでいます。このパッチはAPIや下位互換性に全く問題をもたらさないばかりか、テストしたすべてのRubyアプリケーションでメモリプレッシャーを劇的に改善しています。RubyのアプリケーションはGCにCPUのウォールタイムを最大で45%使うこともありますが、このパッチを利用すればその割合が大幅に減少します。
Rubyのどのバージョンを使うべきかを決定する上で、この件が開発者の役に立たないとしても、Ruby 1.8.6が存続し、維持されることは確実である。まだ1.8.6を使っているなら、何がアップグレードの妨げとなっているのだろうか。