「CVSの言い訳」と途方にくれるユーザー

オープンソースソフトウェアで一番不満に思うことの1つは、CVSを盾にした言い訳がよく見られることだ。このことは、ユーザーを蚊帳の外に置いてしまっているのではないだろうか。

[Nathan-Willis，japan.linux.com]

　オープンソースソフトウェアで一番不満に思うことの1つは、CVSを盾にした言い訳がよく見られることだ。わたしはこれを「CVSの言い訳（CVS cop-out）」と呼んでいる。例えば、わたしが何かの記事か会話の中で、あるオープンソースアプリケーションの短所を（正当に）批判すると、「それは間違いだ。その機能は4週間前にCVSで修正されている」と反論する人がいるのだ。

　言葉は違うかもしれないが、同じような反応は随所で見られる。そのバグは論点になっていないとか、そのバグはβ版やα版、CVS、開発者メーリングリストで配布されたパッチで修正されているのだから、出荷版のアプリケーションのバグをどうこう言うのは見当違いだとかいう具合である。それは開発者的な見方であり、ユーザーにとっては不親切きわまりない。

　リビジョン管理システムにパッチが投稿されればその問題は終わり、という考え方は非常に無責任である。Linuxユーザーやオープンソースユーザーの大部分は、ソフトウェアをコンパイル済みバイナリの形で入手しているのであり、CVSやSVNなどから直接入手しているわけではない。

　さらに、正確な数字は分からないにしても、わたしの考えではかなりの数のLinuxユーザーが、ディストリビューターから提供されたバージョンのアプリケーションをそのままずっと使用していると思われる。リリースサイクルの比較的短いディストリビューターであっても、提供されているアプリケーションのバージョンは、最新版よりも1リリース分から数リリース分遅れている（テストや統合が必要なため）。従って、「4週間前にCVSで修正」されたものでも大衆市場に出回るのは1年後ということになる。

言い訳の例

　この点が特に問題になりやすいのは、（1）開発者数が少ないアプリケーションと、（2）ほかの多数のプロジェクトに統合されるアプリケーションである。例えばMozilla Firefoxは自己完結性が高く、資金も十分にあるアプリケーションなので、この種のジレンマに悩むことはほとんどない。

　それと対極にあるのが、何かと問題の多いオーディオプレイヤーだ。オーディオプレイヤーの処理は非常に複雑なので、ほとんどのオーディオプレイヤーは、さまざまなサウンド形式、メタデータ、同期/修正、効果、管理をサポートするために、多数のI/Oライブラリと処理ライブラリに頼っている。

　しかしその複雑さゆえに、例えばRhythmboxにバグが見つかって*.m4bファイルの再生機能が削除された場合、一般ユーザーがRhythmboxの*.m4bの再生機能を再び使えるようになるまでには早くて6カ月程度かかることになる。

　残念ながら、この問題を簡単に解決する方法はなさそうだ。Rhythmboxの例で言えば、Rhythmboxは50個以上のパッケージに直接依存しており、Rhythmboxのメディアサポートの大部分を担っているGStreamerは、それ自体がRhythmboxと同じくらい複雑な構造になっているのである。CVSのパッチがアップストリームに適用され、この複雑な階層を経て、途方にくれている*.m4b利用者のところに届くまでには、それなりに時間がかかってしまうだろう。

　しかし、ユーザーを蚊帳の外に置いておくよりは、α/βテスト用のダウンロード可能な「開発中」ブランチを継続的に一般公開した方がいいのは間違いない。CVSを盾にして言い訳するよりも、最新の修正を反映させた不安的なコードを大衆市場に公開した方が世間のためになるだろう。

　つまり、「早めにリリース、しょっちゅうリリース」という長年の伝統に従えばいいだけのことだ。バグリポートが増えすぎると心配する向きもあるだろうが、ユーザーはオープンソースプロジェクトの血液であり、バグリポートは白血球である。多少増えたとしても、それは悪いことではない。

　わたしがここで「CVSの言い訳」を取り上げたのは、解決策を示すためではなく、問題提起をするためである。問題に名前を与えると、議論が進んで解決策が見えてくることがある。おかしな名前だと思う人もいるだろうが、この問題についてぜひ考えてみてもらいたい。

原文へのリンク