しかし、複数の番号体系が使われていることが問題なのではない。種々の方式があることさえ知っていれば、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のリリース後は、リリース・サイクルを大幅に短縮しアルファを少なくしたい」と言うが、それまでの代価は利用者の混乱なのだ。