バージョン番号の衰亡
最初にそう実感したのは1週間前のことである。私はScott Robert Laddが書いたGCC 4.0についてのレビューを読んでいた。このレビュー自体は的確で、しっかりした根拠もあり、よく考えられたものだった。読み応えのある記事だったと思う。問題は、記事の締めくくりに書かれた次の一文だ。
… x.0.0リリースに製品の完全な機能を期待している人など1人もいない。GCCのように複雑なソフトウェアシステムではなおさらそうだ。
そんな馬鹿な。歴史的に見ても、x.0リリースと言えば完成した製品を指すはずである。だからこそ、リリースチームは、最後のバグ退治を進めている最中の成果物にギリシャ文字の接尾辞や貴金属名のあだなを付け、最終的な製品と区別していたのだ。それがいつ変わってしまったのか？ 私は悩んでしまった。果たしてx.0リリースはきちんとした完成品なのか、それともそうではないのか？
そこで私はLinuxカーネルのことを思い出した。私が初めてLinuxを実行した頃は、確立された奇数／偶数の二系統の体系が守られていた。つまり、2.1は開発版、2.0は安定版という原則である。これも今は失われてしまった。2.6.0の公開前には、「pre-なんとか」や「pre-なんとか-testX」といったカーネルがいくつも目撃されたものである。
しかもそれ以降、奇数番号のカーネルシリーズは見かけなくなった。現在では、開発はそれぞれのブランチ保守担当者が管理するブランチの中で行われている。この変化は2つの大きな影響をもたらした。第一に、kernel.orgのホームページの簡潔さが損なわれた。以前は2つのリンクだけでカーネルの状況をすべて示すことができたが、現在では11ものカーネルがあり、定義も4ページある（[1]、[2]、[3]、[4]）。FAQやWikiでは今も奇数／偶数の体系を使っているように書かれているが、実際には数年前から守られていない。
第二に、Linux信奉者が恐怖に怯えるようになった。その恐怖とは、いつか（もしかしたら今日にも）知り合いの非Linuxプログラマに街角でばったり会って、その人に「Linuxの次の新しいバージョンはどうなるのかな」と聞かれやしないだろうか、というものである。Linux信奉者は反射的にこう答えるだろう。「そうだね。奇数番号のカーネルは開発用の不安定なリリースで、偶数番号のカーネルは安定版のリリースなんだけど。じゃあね」。しかしこの説明どおりにはならないので、この信奉者はBitKeeperの失態のように長々とした釈明をするか、嘘八百で切り抜けることになる。
また、私としては、GNOME開発者たちが「2.8の後は2.10が来る」と説明するのに膨大な時間を費やしたり、Ubuntu初心者が「Ubuntu 5.04は完成版のx.0リリースである」と聞いたときに不信の表情を浮かべたり、WINE 20041019とWINE 20050111のどちらをインストールすべきかという論争が起きたりする現状を嘆かわしく思う。さらに、もうこれ以上事態が悪くなることはないだろうと思った矢先に、Anjuta IDEプロジェクトが「1.2.3」という安定版リリースと「2.0.0」という開発版リリースを同時に発表した。とうとう話がまったく逆になったわけである。
バージョン番号の規則はすべて灰燼に帰した。今やx.0.0リリースは、盲目的に信頼してもらえないだけでなく、「ユーザが安心して実行できる製品」という意味すら持たなくなったのだ。
何が問題か
もちろん、ここまでの説明は少々オーバーである。私は前述のプロジェクトをいずれもよく知っているので、こうしたバージョン番号の乱れのせいで本当に混乱したことはない。しかし、私がこのような乱れたバージョン番号の意味を理解できるのは、単に以前からこれらのプロジェクトを個人的に知っているからにすぎない。新しいユーザならば間違いなく混乱するだろう。
これは、バージョン番号のような非技術的な要素でも、予想外の望ましくない副作用を引き起こす可能性があることを示唆している。たとえば、奇妙で変てこなプロジェクト名を選べば新しいユーザに敬遠されるだろうし、新しいXboxの店頭発売と同じ日にメジャーリリースを出せばマスコミに取り上げてもらいにくくなる。既に確立されているバージョン番号方式をやめれば、同じ質問内容のメールが山ほど送られてくるだろう。
私の最大の疑問は、オープンソースの方がクローズドソースの商業ベンダよりもこの種の「病気」にかかりやすいのだろうかという点である。私は近いうちに、この疑問について広くコメントを求めようと思っている。
私の直感では、オープンソースプロジェクトの方が、このような非技術的な落とし穴にはまりやすいのではないかと思う。というのは、オープンソースプロジェクトはもともと技術系の人々が開始し、運営しているものだからだ。コーダーをプロジェクトに引きつけるのは簡単なことではないが、非技術的な作業（バグの優先順位決め、文書整備、視覚的デザインなど）をしてくれるボランティアを見つけるのはもっと難しい。オープンソースコミュニティは、その性質上、ほとんどがプログラマで占められているからだ。それに対して、商用製品は経営戦略と市場調査と流行への条件反射によって作られており、製品の名前やリリーススケジュールといった非技術的な部分（そして遺憾ながら技術的な部分も）の決定は非技術者によって下されている。
しかし、逆の結論を想起させる要素もある。つまり、カーネルのバージョン番号付け方式の変化は、カーネル開発への企業支援と相互に関係しているように見えるのだ。開発用ブランチに奇数番号を付けるという方式が消滅したのは、LinusがBitKeeperを採用したことに主な原因があるとされているが、番号付け方式の変化は実はもっと前から始まっていた。特に、企業資本がカーネル開発に投下され、開発者に給与が支払われるようになるにつれて、新しいx.0.0リリースの前に「-testX」や「pre-」といったリリースが数多く発表されるようになった。
この説は理にかなっているように見える。クローズドソースベンダがベータ段階の製品をうかつに販売することはないが、それと同様に、深刻なバグがあるパッケージを慌てて公開しようとするオープンソースベンダはない。そのため、オープンソースベンダは開発チームとのQAサイクルを経て改良を重ね、それが「pre-」リリースや「-testX」リリースという形で公開される。
Googleで検索してみたところ、商用のLinuxディストリビューションでは、パッケージ販売製品へのx.0.0カーネルの採用時期がどんどん遅くなる傾向にあるようだ（[1]、[2]）。これはもちろん、x.0.0リリースを作成するためのテストサイクルが長くなったことによる。テスト期間を長く取れば、完成したときの信頼性が高まるからだ。
リリース番号に関する三原則
では、企業が介入したせいでLinuxカーネルのリリース番号の付け方が台無しになったのだろうか？ 可能性は否定できない。しかし、ここで私が問題にしたいのは、企業の介入がその他のオープンソースプロジェクトの非技術的な要素に与える波及効果のことである。
番号付け方式の混乱はユーザ側の混乱につながるという点は既に指摘した。たとえば、あるソフトウェアプロジェクトの新しいリリースを評価するために実際に使ってみるとしよう。バージョン番号は、アプリケーションやライブラリのリリースを識別するための唯一の手がかりである。バージョン番号付け方式のせいで人々が混乱したり、ソフトウェア本体よりもバージョン番号についての質問の方がサポートフォーラムに多く寄せられたりするようでは、明らかに問題である。
ここで、私が「リリース番号に関するWillisの三原則」と呼んでいるものを紹介したいと思う。この原則に従えば、ユーザの感謝と世間の賞賛と仲間の尊敬を一身に受けることになるだろう。
第一原則：番号付け方式を決めたら絶対に変更しない。 元はといえば、バージョン番号の唯一の目的とは、バージョン間の相対的な優位性を明らかにすることである。商業ソフトウェアベンダは定期的に「製品名＋文字」という形で名称を変更しようとするのだが（歴史的な例としては「RealPlayer G2」、まもなく歴史の仲間入りをするだろう例としてはAdobeの「Photoshop CS」がある）、いつも結局は、顧客アンケートのとある質問の回答が90％に達したときに、古き良き番号制度に後退せざるを得ない。これは、番号の方が優位性を比較しやすいからである。
この原則は、大幅な改訂の際にマイナー番号を増やす代わりにメジャー番号を増やすよう決定できないという意味ではない。ここで言いたいのは、既に確立されている偶数／奇数の方式から、奇数／偶数の方式や、特定のツールキットの番号付け方式に直接結びついた新方式に切り替えてはならないということだ。元々「安定版」を意味していたx.0リリースを、勝手に「開発版」の意味にしてはならない。
第二原則：数学をもてあそばない。 言い換えると、既に確立されている番号付け規則に違反するような方式を採用してはならないということだ。数字が大きいほど新しいバージョンを示す、というのが基本的な決まりである。数字を使うメリットは、ソートできるという点だ。FTPアーカイブは何らかの意味のある方法でソートしなければならない（そうしなければ非難轟々である）。「-testX」、「-alpha」、「-beta」などを付けると各リリースが正しくソートされなくなる可能性があるので、こうした接尾辞は避けること。
また、メジャー番号とマイナー番号の区切り文字に小数点を使っている場合は、ユーザから「なぜ
「あれは小数点じゃないぞ」と抗議のメールを書こうとしている読者の姿が目に浮かぶようだが、先を続けることにしよう。選択肢は3つある。つまり、（a）番号付け方式の意図を毎回説明し直す、（b）OpenBSDがしているように2.8の次は3.0にする（これが一番楽）、（c）その他のASCII文字の中から別の区切り文字を選ぶ、の3つである。
第三原則：大きな番号を恐れない。 言い換えると、番号を増やすのをためらわないということである。数字を使い尽くすことはあり得ない。数学者はいつも、より大きな新しい数字を求めて日夜研究にいそしんでいるものである。プログラマはバージョン番号を増やすことを恐れるあまり、後発リリースに「.x.x」という形でさらなる小数点を付加するという大罪を犯している。これが行き過ぎると「小数点症候群」になり、バージョン番号はしだいに有限極限に近付いていくが、バージョン番号の長さは無限に伸びていく。理論上は、バージョン番号だけですべてのシステムリソースを消費してしまって実行できないプログラムすら考えられる。
しかし実際の世界では、そこまでは行かずに適当なところでバージョン番号を上げることになる。たとえば、SunがSolaris 2.6からSolaris 7へバージョンを上げたときのことを思い出してほしい。これも、ソフトウェア業界の他企業が製品のバージョン番号をもっと速いペースで上げていて、追いつくまでにはかなりの差があると気付いたときにようやく実現したのである。私はオープンソースプロジェクトでも、これと同じように「この改訂はマイナー番号を増やすだけの価値があるものか？」と考えすぎて麻痺状態に陥ってしまったものを数多く見たことがある。私に言わせれば、2.4から2.6への改訂箇所が2.2から2.4への改訂箇所より少なくても何ら問題はない。重要なのは、どれが最新リリースかをその番号がきちんと表していることである。リリース番号の上がり方が遅いと、部外者には開発速度が遅いように見えてしまい、その誤解がユーザベースを損なうおそれもある。
明日はどうなる？
かつての世界は理にかなっていた。地平線に朝日が昇る頃、畑では農民が季節の作物を収穫し、建物の一室ではプログラマが連夜のコーディング成果を完璧なx.0リリースとしてパッケージ化し、それがインターネットに送り出されてミラーサーバに複製されるのを感慨深げな様子で見守っていた。あの頃は誰もが幸せだった。
しかし、バージョン番号の体系は崩壊し、混乱がやってきた。ある番号はどんどん長くなり、またあるものは文字や単語、あるいは日付になった。バージョン番号の本当の意味がわかる人は誰もいなくなってしまった。人々はバージョン番号の意味を聞くことを怖がり、バージョン番号そのものを恐れるようになった。
次は何が起きるだろうか？ 街角で暴動が起きたり、地区が封鎖されたり、抗議者が企業本社の壁にスプレーでバージョン番号を落書きしたりするのだろうか？ それとも、無知の闇が晴れ、数字的に調和の取れた世界的意識が徐々に目覚めてくるのだろうか？ 私としては、どちらの可能性も薄いと思う。しかし、次世代のプログラマがこの黙示録を経てソフトウェア業界を復興させるときには、一から正しい道を歩んでくれるのではないかと期待している。友よ、そのときを待とうではないか。
原文
