無秩序なバージョン番号
しかし、複数の番号体系が使われていることが問題なのではない。種々の方式があることさえ知っていれば、GNOMEの奇数番号リリースが開発ビルドであり偶数が公式リリースであることを調べるのは造作ないことだからだ。また、KOffice 1.9.95-4をKOffice 1.0の後続バージョンかと一瞬誤解することはあっても、すぐにバージョン2.0の初期ビルドであることに気づくからだ。そもそも、フリーソフトウェアの最新ビルドを使おうというほどの人なら、大規模プロジェクトの開発者全員の合意を取り付けるのはMicrosoftに対する不信以外のことでは不可能であることを知っているはずだし、互いの違いを許容することを理解しているはずだ。
問題は、どの方式かではなく、そのリリースがソフトウェア開発のどの段階にあるのかがほとんどわからない点にある。OpenOffice.orgのように、最終リリースを除いてバージョン番号を付けず、単にビルドとしているだけのところもある。しかし、多くのプロジェクトでは、「firefox3.0-rc1」といった名称を使っているFirefoxのように、伝統的な3桁のバージョン番号と「ベータ」や「アルファ」や「リリース候補」などの用語を併用している。その使い方があまりにも無頓着なため、バージョン番号の意味がほとんど失われているのだ。
本来のバージョン番号
もちろん、バージョン番号には判断の問題という一面はある。これは、Linus Torvalds氏が新しいカーネルを発表するときしばしば強調していることだ。たとえば、5年前、長らく待たれていた2.6.0を発表したとき「リストの面々にとってはさほど驚くようなことではない。これまで長い時間をかけて積み上げてきたものなのだ。ともあれ、2.6.0をリリースする」と語っている。この発言は、バージョン番号をどう付けるかは任意だということ、そしておそらくは開発者より利用者の関心が強いものだということをこれ以上ないくらいハッキリと示している。
とは言え長年の間に、リリース・サイクルについて、次のような一般的理解が定着している。まず開発リリースあるいは夜ごとのビルドがあり、次にバージョン0.2か0.3当たりでリリースが宣言される（ないこともある）。これがアルファ・リリースだ。フリーソフトウェアの世界では、主要な機能は多少とも使える状態になっているリリースという意味になる。次に、0.6～0.8当たりでベータ・リリースが宣言される。これは、来るべきメジャー・リリースに搭載されるはずのすべての機能を備え、インタフェースもほぼ完成しているが、まだ改修すべきバグが残っているという意味。リリースに差し支えるような大きな問題がすべて解消すると1つまたは複数のリリース候補がリリースされ、小さなバグを改修するとメジャー・リリース1.0が出てサイクルが閉じる。このメジャー・リリースでもバグが残っていることはあるが、それは主としてハードウェアのあらゆる組み合わせでテストするのは困難だからであり、ほとんどの利用者には十分機能するはずだ。
これが、利用者が一般に了解しているリリース・サイクルだ。しかし、昨今は少々状況が異なっており、主要な機能を実装している最中に整数に近いバージョンでリリースされる例が増えている。シェルをカスタマイズするデスクトップ・ユーティリティーBashStyle-NGのレビューでは、第3リリース候補を使っていたにもかかわらずインタフェースの多くがまだ不安定だった。さらに極端な例は、KDEが発表した4.0だ。これが日常作業に利用されていることを知った開発チームは驚きを表明し、苦情が殺到するとバージョン4.1を待てと慌てて釈明した。
また、第4アルファをリリースしたForesightディストリビューションの例もある。この「アルファ」という言葉にほとんど意味がないことは明らかだ。プロジェクトが大規模でまったく異なる種類のモジュールから構成されている点を考慮しても酌量の余地はない。そもそも、第4アルファが存在するということ自体が、アルファとしたことが間違いだったことを明確に示している。
KOffice 2.0も同様だ。第8アルファがリリースされたことについて、開発者のCyrille Berger氏はプロジェクトが大きく複雑なためだと説明している。「プロジェクトがまだ活動中で進行していることを示すには」多数の「アルファ」を出すほかなく「2.0のリリース後は、リリース・サイクルを大幅に短縮しアルファを少なくしたい」と言うが、それまでの代価は利用者の混乱なのだ。
結論と対策
同じバージョン番号の乱れでも、逆の場合はほとんど問題は生じない。たとえば、フォント・マネージャーFontMatrixのリリース0.1は機能を完備していたが、これは嬉しい驚きだった。まだ開発中なのにクラッシュを我慢したり回避策でしのいだりすることなく使うことができただけでなく、初期段階のリリースでさえこれほどの仕上がりであれば公式リリースではどれほどだろうと思わずにいられなかった。
これに対して、実態以上に大きいバージョン番号は大問題だ。そうしたリリースをダウンロードしてコンパイルすると、期待は大きく裏切られることになる。そして、裏切られた人々はプロジェクトに参加しバグを報告して開発を支援するのではなく、愛想を尽かして見切ってしまい何年も戻ってくることはないだろう。それは、プロジェクトがコミュニティーを作る機会を失ったということなのだ。
適切なバージョン番号を付けるということは管理あるいはマーケティング上の意思決定という面もあるだろう。しかし、フリーソフトウェア・プロジェクトの場合、マーケティングは自分で行うのだから、マーケティングにももう少し時間を割くべきだ。詰まるところ、プロジェクト自身が実態を偽っているというのに、そとの人たちがプロジェクトを正確に理解してくれることをどうして期待できようか。一般の人の目には、リビジョン・コントロール・ソフトウェアが割り当てた番号を無視しているとしか映らない。
問題の一端は、おそらく、バージョン番号がビジネスとして行われる開発の伝統あるいは要請だということにもあるだろう。「早いリリース、頻繁なリリース」を信条とするフリーソフトウェアではバージョン番号は無意味だという人もいるだろうが、今日のフリーソフトウェアはますますビジネス色を強めている。定期的なリリース・スケジュールを持つほどのビジネス的なプロジェクトなら、バージョン番号を適切に付けよと求めても決して無理な相談ではないだろう。
もし、バージョン番号を適切に付けるということが実用的でないと言うなら、Debianのカスケード・リポジトリーのように、大きな分類、つまり不安定、試験中、安定というカテゴリーを採用する方法もある。これでも、その趣旨は利用者に十分伝わるだろう。そして、公式リリースではそれなりの方法で命名すればよい。Debianは従来そうしてきたのだ。
どのような対策をとるにしろ、フリーソフトウェア・プロジェクトはバージョン番号をもっと真剣に扱う必要がある。すべての人々のために。
Bruce Byfield コンピューター・ジャーナリスト。Linux.comの常連。
