開発側とエンドユーザの意識のギャップ。開発者はソースコードを直し、まとまりのいいところでリリースするが、ユーザーは現在直面している問題を直ちに解決してくれることを望んでいる。
リビジョン管理システムにパッチが投稿されればその問題は終わり、という考え方は非常に無責任である。Linuxユーザやオープンソースユーザの大部分は、ソフトウェアをコンパイル済みバイナリの形で入手しているのであり、CVSやSVNなどから直接入手しているわけではない。
さらに、正確な数字はわからないにしても、私の考えではかなりの数のLinuxユーザが、ディストリビュータから提供されたバージョンのアプリケーションをそのままずっと使用していると思われる。リリースサイクルの比較的短いディストリビュータであっても、提供されているアプリケーションのバージョンは、最新版よりも1リリース分から数リリース分遅れている（テストや統合が必要なため）。したがって、「4週間前にCVSで修正」されたものでも大衆市場に出回るのは1年後ということになる。
だから「素早くリリース、何度もリリース」だよ、という論調。
ワタシは必ずしもそうは思わない。この記事の執筆者はディストリビューションの存在を時定数かなにかと勘違いしているようだ。素早く、何度も、の部分の判断の役目はディストリビューションが負うべきだ。
distributionとupstreamのバイナリは別物
ディストリビューションはupstream（開発元）からソースを入手し、パッケージを作って配布する。問題があればどこか（野良、あるいは開発元のCVS）からパッチを取ってきて、または自分達でパッチを作ってパッケージのソースに当てて再びパッケージングする。そうやって、ディストリビューションが持っているバイナリは開発元の同一バージョン番号のものとは食い違っていく。
開発元ではいちいちどのディストリビューションがどんなパッチを当てているか把握していない。そもそもそんなことはできっこない。報告の義務さえないし、誰かがパッチを投稿しても、誰のものがどれとどれで、というようなchangesetを管理する機能がCVSにはない*1。
改変されたソースのことは知らん！
そうした、極端に言えば「同じバージョン番号で複数のソースが配布されている」状況に、エンドユーザーがとどめをさす。直接開発元にバグ報告を投げるのだ。そして開発元は途方に暮れる。
ワタシはhogehoge linuxを使っています。バージョンx.xxでこういう操作をしたらアボートしました。設定ファイルはこんな感じです。よろしく。
このエンドユーザーの報告はまともに見えるだろうか？だとしたらあなたの立場は相当エンドユーザー寄りだ。このような報告を受けて開発側が取らなければならないアクションは以下の通りだ。
- hogehoge linuxのパッケージのソースにどのような改変が加えられているか調べる
- そのソースで問題が再現することを確認する
- 原因を特定し、それを修正するパッチを作る
- 自分達の（つまり開発元の）ソース、特定のリリース番号とCVS HEADでその問題を修正するパッチを作る
- CVSにコミットする
- hogehoge linuxに問題を報告してパッチを当ててもらうよう、報告者に返答する
そんなことはもちろんやってられない。分かってもらえるだろうか。CVSの言い訳はまだ親切なほうなのだ。最大限の努力といってもいいだろう。だって彼らにはhogehoge linuxのためにそれ以上のことはできないのだ。あとはそっちでやってくれ、という感じである。
もっと不幸な例
もっと不幸な例をワタシは知っている。GRUBだ。レガシーな*2GRUBに、あるときsplashimage patchなるものを提案したヒトがいた。ncursesベースだったGRUBにVGAサポートを加えて、背景画像の表示を可能にするパッチだった。多くの人がこれを歓迎したが、このパッチはパッチと呼ぶにはあまりに大きかった。そして当時の(そして現在の)メンテナはそのパッチは汚くて「メンテナンスが困難である」という理由でこれを却下した。
しかし問題はそれでは終わらなかった。メジャーなディストリビューションが見栄えを重視してこのパッチを採用し、splashimage付きのGRUBを配布したのだ。もちろん、BIOS画面の後にきれいな背景画像とブートメニューが出るのは大変見栄えがよろしい。ユーザーの評判も上々。そして開発元にはその"modified version"に関するバグレポートが殺到するようになったのだ。
もちろん開発元は改変されたソースに関するバグレポートは改変した者に相談してくれ、という返事を返す。しかしその数が多すぎて、数少ないメンテナでは捌ききれない場合だってあるのだ。結果としてGRUBのバグ対応は滞り、開発者は新しいGRUBに注力するようになって、レガシーなGRUBは二つに、いや、ディストリビューションの数だけ多くのバージョンに、分かれたまま朽ちていこうとしている。
ディストリビューションによる橋渡し
ではどうすればよかったのか。このような不幸な例から得られる教訓は次のようなものだ。
- ディストリビューションのバグはまずディストリビューションで受け、原則としてディストリビューションの中で問題を解決する。
- 開発元で同様の問題が発生していないか調べる。すでに開発元では解決している場合はパッチを入手して自分達のソースに適用する。もちろん必要なら適切に改変する。
- もちろん、外部（開発元を含めて）に落ちているパッチを拾ってきて当てるのは（それがライセンス的にクリーンなパッチである限り）問題ない。
- 開発元に同様の報告がなければ、そしてそれが開発元のソースでも発生する問題だと思われるなら、事象の報告とともに開発元にパッチを投稿して知識を共有する。
- ディストリビューションは新しいパッケージを「素早く、何度も」リリースする。
つまり、ディストリビューションがエンドユーザーと開発者の橋渡しをするようなモデルだ。これは既に存在し、機能しているが、エンドユーザーには意外と知られていないようだ。
なぜ「橋渡し」が機能するのか
橋渡しが機能するのは、エンドユーザー、ディストリビューション、開発者、それぞれの向いている方向が少しずつ異なっており、しかもディストリビューションがほぼ中間に位置しているからだ。
- エンドユーザーは「アボートせず動く、便利なシステム」を求めている。
- ディストリビューションはあちこちからソースを集めて「アボートせず動く、便利なシステム」を統合環境として提供することを目的としている。
- 開発者は自分達のソースが自分達の目的に適って動作することを追求している。
つまり、ディストリビューションを作る作業そのものが既に橋渡しなのだ。バグレポートもその橋を通って行き来させるのが自然な成り行きというものである。エンドユーザーにバイナリを提供しているのはディストリビューションなのだから、ディストリビューションが「素早く、何度も」リリースすればよいのであって、開発者は開発に専念すべきだ。
というのが、ワタシの考えだ。
