0005 号 巻頭言
誰のための Ruby?
Rubyist Magazine 第 5 号をお届けする。
前回予告した通り、 2 ヶ月ぶりの発行となった。 間は空いたが、今号も増井俊之さんへのインタビューをはじめ、 めでたく最終回を迎えた「Ruby ではじめるプログラミング」と 「lily でブログカスタマイズ」、 最近話題の Ruby on Rails について、テストの手法や内部の紹介を行う 「続・ RubyOnRails を使ってみる」、 片や WebObject ライクな構成で根強いファンを持つ CGIKit で実際にアプリケーションを作成する 「CGIKit、TapKit を利用した Web アプリケーションの作成」、 比較的少ないと言われている Windows 上での Ruby の活用について、 異なる切り口で紹介する 「Win32OLE 活用法」と 「Ruby Library Report — [第4回] Win32Utils」、 さらに Ruby のゲームへの応用としても、 また製品への応用事例として興味深い RGSS を概観する 「Rubyist が知りたいかもしれない RGSS の世界」と、充実した内容となった。 お待ちいただいた読者の方々にも満足していただければ幸いである。
ところで、前号発行からの短い間にも、 海外での Ruby の注目度がより高まってきたように感じている。
本誌でももりきゅうさんの連載で扱っている、 以前から次第に注目を集めていた Web アプリケーションフレームワーク、 Ruby on Rails (RoR) の 紹介記事がオライリーのサイトに掲載された (Rolling with Ruby on Rails)。 「Java のフレームワークよりも 10 倍早く開発できる」という煽り気味の宣伝文句と共に 公開されたその記事は、 Java や Python のユーザを巻き込んで多くのサイトで Ruby と RoR が取り上げられたようだ。 RoR の blog では、いささか過剰ではないかと思われるほどに賛否両論の反応を (そもそも「賛」なのか「否」なのかもわからない、 まつもとさんによる日本語の日記の記事のキャプチャすらも) 取り上げ、 自身のサイトとアプリケーションの盛り上げに貢献させている。 そのあおりを受け、Ruby のインストーラのダウンロード数も増加したり、 ruby-talk の流量も 4000 件を軽く越え、過去最高を記録したりと、 影響力はあなどれない。
また、why the lucky stiff さんの blog サイト、redhanded では、 日本の Ruby 界隈の情報を紹介する人を募集し、 それに応えてはんばあぐさんと馬場さんが ゲストブロガーとして登場するようになったのも見逃せない。 新年会や Debian の話題をとりあげるはんばあぐさんや、 Python の型付けに関する Matz にっきでの発言を翻訳する 馬場さんのコメントは、日本からの情報に飢えている 海外の Rubyist からの歓迎と感謝の言葉が相次いでいた。
海外で Ruby に近いポジションで使われている言語は何と言っても Python だろう。 かの Bruce Eckel 氏も、 「Ruby が現れるまで、Python の対抗馬は現れなかった。 そして今は、そのライバルがいる」と言っている (Re: Fixes What’s Wrong With Python)。 その勢いはまだまだこれからも伸び続けていきそうである。
とはいえ、Ruby の現状を手放しでは喜べるわけではない。Ruby に対する辛い評価もある。
昨年暮れ、めでたくリリースされた Ruby 1.8.2 だが、 そのリリースエンジニアリングについては、 パッケージングに失敗したり、 更新内容の告知などの点で、 まだまだ改善の余地があることを思わされた。 もっとも、私自身は開発には何の役にも立たないので 邪魔にならないよう周りをうろちょろしてたまに突いてみたりする程度だが、 どうせ前日になって突付くのであればもっと早めにつついておけばよかった、と反省している。
なお、更新情報については、 sheepman さんなどの手によって書かれた(らしい。Wiki なので詳細は不明であるが) 1.8.2 の更新情報のページの形で補完されている。ありがたいことである。
また、これに関連して最近 ruby-dev ML で話題になったのは、1.8.2 の互換性についてである。 Ruby では、1.8.0 と 1.8.1、1.8.1 と 1.8.2 など、 3 つ目の数字が変わっただけのバージョン違いのものでも、 挙動が変わることがある。1.8.1 と 1.8.2 についても 上記の更新内容のところで紹介されているが、 これまでのところあまりはっきりとした基準のないまま変更の必要性が判断され、 実施されてきた。
更新内容の公開にせよ、バージョン間の互換性にせよ、 これらの影響を大きく受けるのは、 Ruby そのものの開発にはコミットしていない Ruby ユーザである。 つまり、自分で Ruby のアプリケーションを作成しているユーザである 「Ruby アプリケーション作者」と、 誰かが作成した Ruby のアプリケーションをそのまま使用する 「Ruby アプリケーションユーザ」である。
彼らには強く Ruby に関わる動機も理由もない。前者のアプリケーション 作者にとってみれば、自分が使いやすいように Ruby が変更される ことは歓迎だが、そのための説得にわざわざコストを費やそうとか、 高くもあり低くもある「敷居」を越えようとはなかなか思わないだろう。 また、Ruby に余計な変更が加われば、今まで自分が作成したアプリケーションに 手を入れなければならなくなる必要がある。バージョン間の互換性が 問題になるのであれば、バージョンを判別しふるまいを変更する 特別なコードを新たに追加しなければいけなくなるかも知れない。 それは厄介である。 さらに後者の、Ruby アプリケーションを利用するユーザにとってみれば、 Ruby そのものが改良されようがされまいが意味がない。 Ruby 1.8.1 用に作られたアプリケーションを使いたいユーザにとって、 そのソースが正常に実行できなくなってしまった Ruby 1.8.x は、 単に「壊れた Ruby」でしかない。
何かしら Ruby が「良く」なったとしても、 彼ら Ruby ユーザにとってそれが本当に「良い」ものだと 認識されているかどうかは疑問である。 彼らにしてみれば、 多少言語が「良く」ならなくとも、 以前のバグを含めた互換性が確保されるほうがよほど望ましいし、 逆に変更しなければいけない点はあらかじめ十分に告知されていなければならない。 それができないなら、サポートの手間が増えるだけであり、 いっそリリースされない方がよい。 そう考えていても不思議ではない。
……と、このように書けば、前号での巻頭言の言葉も踏まえ、 「私たちはもっと見知らぬユーザのことを考えなければならないのだ」 といったような流れになると思われるかもしれない。 しかし、話はそう簡単ではない。
ここで Linux Magazine に掲載されていたまつもとさんの連載から、 2003 年 2 月号の記事を引用したい。
ああ、重要な点を忘れていました。一番大切にしなければならないのは 開発コミュニティであってユーザーコミュニティではない、ということです。 少々暴論ですが、フリーソフトウェアを開発する動機でもっとも大きいものは、 「ソフトウェア開発したいから、楽しいから」と言うものだと思いますが、 単なるソフトウェアユーザーはなかなかそれを理解してくれません。 フリーソフトウェアの場合、どれだけユーザーがいても「もうけ」が あるわけではありませんから、より楽しい開発に集中するのは むしろ当然だと思います。すぐれたソフトウェアのユーザーコミュニティは、 開発コミュニティの周辺に自然発生すると思います。 (Ruby 開発日記「大人になる、ということ」より)
明確に開発者優位の姿勢をとっていることがわかる。
これはユーザを置き去りにした「わがまま」な態度なのだろうか？ そうではない。 言語開発者が開発を中止してしまえば、 いくらユーザが望んだところでその言語は衰退してしまう、 ということは、別に脅しでもなんでもなく、端的な事実である。 個人が開発している言語の寿命は開発者が握ってしまっている。 その意味で、Ruby開発者が開発者 (コミュニティ) 優先を唱えることには何の齟齬もない。 順調に続いているように見えている Ruby の開発も、 他愛無いことであっさり中断される危険性を孕んでいる。
この事実を持って、Ruby の開発基盤の脆弱性を問題視する向きもあるかもしれない。 しかしながら、ほとんどのフリーソフトウェア・オープンソースソフトウェアに よる言語処理系は同様の事情にあるように思う。 ましてや Ruby は「プログラミングのたのしさ」といった、 露骨に主観的な要素を重視する言語である。 開発者の意向をかなりの程度優先させなければ、 開発の持続可能性を確保することは困難だろう。
とはいえ、開発の継続のために、開発者はユーザの意向を軽視してもいいのだろうか？ それもまた極論である。
豊かな開発コミュニティを維持するには、 新たにコミュニティに帰属する者が一定数以上求められる。 以前からの Ruby ユーザであれば、 かつては内外の Ruby 関連メーリングリストなどを舞台に活発な活動をされていたにも関わらず、 久しくご無沙汰になっている方々を幾人も思い出せるだろう。 彼・彼女らに代わって活躍するのは、当時は Ruby の存在そのものも 知らなかったかもしれない新参者たちである。
そのような新しい成員が新しいプロダクトに関わるのは、たいていユーザとしてだろう。 そして、開発者コミュニティを活性化させるような開発者であれば、 そのプロダクト自身の潜在的価値を見抜き、 それがユーザである彼・彼女からも十分魅力的でなければ、それ以上関わろうとしないはずだ。 その意味では、影響力のある開発者を集めるためにも、 その言語がユーザにとっても魅力的なものでなければならない。 すなわち、「開発者優先」というポリシーと、 「ユーザ重視」というポリシーは両立するのではないか。
いろいろ書いてはみたが、 正直な話、私自身、この問題については落とし所が見えていない。 あるいは、ここでも「バランスが重要」ということになるのかもしれない。 見えないユーザ、見えない開発協力者、見えない理想の言語を目指して、 一歩ずつ Ruby の開発が進められていく。 異なる立場の人々によるせめぎあい自体に関与することも、Ruby という言語がもたらすたのしみの一つであるとも言える。 私としては、 このせめぎあいの場所に立ち会えたことに感謝しつつ、 せめて自分なりの貢献を通して、 たのしみの一端を享受できれば、と思っている。