結論と対策
同じバージョン番号の乱れでも、逆の場合はほとんど問題は生じない。たとえば、フォント・マネージャーFontMatrixのリリース0.1は機能を完備していたが、これは嬉しい驚きだった。まだ開発中なのにクラッシュを我慢したり回避策でしのいだりすることなく使うことができただけでなく、初期段階のリリースでさえこれほどの仕上がりであれば公式リリースではどれほどだろうと思わずにいられなかった。
これに対して、実態以上に大きいバージョン番号は大問題だ。そうしたリリースをダウンロードしてコンパイルすると、期待は大きく裏切られることになる。そして、裏切られた人々はプロジェクトに参加しバグを報告して開発を支援するのではなく、愛想を尽かして見切ってしまい何年も戻ってくることはないだろう。それは、プロジェクトがコミュニティーを作る機会を失ったということなのだ。
適切なバージョン番号を付けるということは管理あるいはマーケティング上の意思決定という面もあるだろう。しかし、フリーソフトウェア・プロジェクトの場合、マーケティングは自分で行うのだから、マーケティングにももう少し時間を割くべきだ。詰まるところ、プロジェクト自身が実態を偽っているというのに、そとの人たちがプロジェクトを正確に理解してくれることをどうして期待できようか。一般の人の目には、リビジョン・コントロール・ソフトウェアが割り当てた番号を無視しているとしか映らない。
問題の一端は、おそらく、バージョン番号がビジネスとして行われる開発の伝統あるいは要請だということにもあるだろう。「早いリリース、頻繁なリリース」を信条とするフリーソフトウェアではバージョン番号は無意味だという人もいるだろうが、今日のフリーソフトウェアはますますビジネス色を強めている。定期的なリリース・スケジュールを持つほどのビジネス的なプロジェクトなら、バージョン番号を適切に付けよと求めても決して無理な相談ではないだろう。
もし、バージョン番号を適切に付けるということが実用的でないと言うなら、Debianのカスケード・リポジトリーのように、大きな分類、つまり不安定、試験中、安定というカテゴリーを採用する方法もある。これでも、その趣旨は利用者に十分伝わるだろう。そして、公式リリースではそれなりの方法で命名すればよい。Debianは従来そうしてきたのだ。
どのような対策をとるにしろ、フリーソフトウェア・プロジェクトはバージョン番号をもっと真剣に扱う必要がある。すべての人々のために。
Bruce Byfield コンピューター・ジャーナリスト。Linux.comの常連。