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