オープンソースプロジェクトが、歴史的に独占的なソフトウェアのプロジェクトと異なる点は、 リリースの計画に関するものです。 独占的なソフトウェアのプロジェクトでは、確固とした〆切があるのが普通です。 その理由は、顧客にある時点でアップグレードを提供すると約束している場合もあれば、 新しいリリースをマーケティング上の理由から他の仕事と連携させる必要があったりとか、 プロジェクトにお金を出しているベンチャーキャピタルの人が、 さらに投資をする前に成果を見る必要がある場合もあります。 一方、フリーソフトウェアプロジェクトでは、 ほとんど文字通りの意味での「道楽」が最近までほとんどの動機付けとなってきました。: つまり、好きだからコードを書いてきたのです。 全ての機能が揃う前にリリースする必要性を感じる人はいませんし、 そもそもなぜそうすべきなのでしょう？ フリーソフトウェアプロジェクトでは、皆の仕事がひとつの生産ラインに乗っているわけではないのです。

最近では、多くのオープンソースプロジェクトが企業からお金を出してもらうようになり、 それに伴って企業の〆切文化の影響をより多く受けるようになってきています。 これは多くの点では良いことなのですが、 お金を貰って雇われている開発者とボランティアの開発者の間で、 優先順位の衝突が起きる可能性があります。 こうした衝突はリリーススケジュールをいつ、どのようにするかという問題でよく発生します。 プレッシャーが強い雇われ開発者は、当然リリースする日程を決めたがりますが、 ボランティアの開発者は他の問題意識の方が強いかもしれません — それは自分たちが求める機能や、仕上げておきたいテストであったりします — よって、ボランティアの開発者達はリリースを待つべきだと感じることになります。

もちろんこの問題については、議論し、妥協する以外に一般的な解決策はありません。 しかし、提案されているリリースの 存在 から、 日付を切り離すことで、衝突の頻度や度合いを最小限にすることができます。 つまり、はじめはざっくりとした見積り^[29] 以外は日付について触れず、 直近から中期的な段階で、プロジェクトはどういった形のリリースができるか、 そしてそのリリースにどんな機能を含めるのか、という方向に議論を誘導してみるのです。 機能について早期に確定しておくことで、 個々のリリースに関する議論が複雑になる度合いを減らすことができ、 予測可能性を高めることができます。 また、新機能や他の複雑なことをリリースに追加することで、 リリースの定義を拡大解釈する提案に反対させるある種の先入観を植え付けることができます。 たとえリリースの日取りが決まっていなくても、 その内容がうまく決まっていれば、 リリースの内容を拡大するのを正当化するのはそれを提案する人の責任になります。

トマス・ジェファーソン の伝記 Jefferson and His Time では、 Dumas Malone が、バージニア大学の組織を決めるための初ミーティングを彼がどのように進めたかについて語っています。 大学を設立するというアイディアはもともとジェファーソンのアイディアでしたが、 (オープンソースプロジェクトに限らず、どこででもあることですが) 他の多くの関係者が、自分たちの興味があることや議題を持って会議に乗り込んできたのです。 彼らがミーティングに集まってそれらを徹底的に議論していると、 ジェファーソンは周到に準備した建築図面や、その予算や実作業、提案されているカリキュラム、 そして自分がヨーロッパから輸入したいと考えていた特別な学部の名前を示して見せたのです。 会議室にいた人の中に、彼以外でそうした議題についてほんのわずかでも準備にした人はいませんでした。 つまり、彼らはそうした議題についてはジェファーソンのビジョンに従わざるを得ません。結局、 バージニア大学設立は多かれ少なかれ彼の計画通りに進んだのです。 建築費が予算をオーバーしていたり、彼のアイディアの多くは様々な理由で実現しなかったりしましたが、 ジェファーソンはそれらすべてが起こることをあらかじめ完全に予想していたのでしょう。 彼の狙いは戦略的でした。ミーティングで他の人が修正を提案せざるをえないような現実的な路線を提示するようにしたのです。 その結果、全体の枠組み、そしてプロジェクトのスケジュールも、だいたい彼が望むものになったのです。

フリーソフトウェアプロジェクトの場合、"ミーティング" はありませんが、 小さな提案の積み重ねは、そのほとんどがバグ追跡システムで行われます。 プロジェクトであなたがちょっと信頼されていて、 いろいろな新機能や改善やバグ修正をターゲットとなるリリースに割り当てはじめれば、 アナウンスした全体のプランに従って、人々はあなたについてくるでしょう。 いったんそれらが多かれ少なかれあなたの思い通りに進めば、 実際のリリース 時期 に関する議論もより進みやすくなるでしょう。

もちろん、個々の決定をまるで文書で確定したかのように示さないのが重要です。 特定のリリースで問題の解決をすると決めるときには、 コメントで議論に参加してもらい、反対意見を述べてもらったりし、 可能な時はいつでも、真摯に説得に応じましょう。 単に権力を行使するために、力を振りかざしてはいけません。 リリース計画を立てる過程で他の人が議論に参加すればするほど (8章ボランティアの管理 の 「技術的な作業だけでなく管理作業もみんなで」 を参照してください) 、 自分が本当に重視している問題の優先度を高めることに賛同するよう説得することも容易になるのです。

リリース計画を立てるときに緊張を緩める別の方法として、 リリースを頻繁に行うことがあります。リリースする間隔が長期間空くと、 それぞれのリリースの重要性がメンバーの中で増してしまいます。 つまり、自分たちのコードが取り込まれなかったときのショックが大きくなってしまうのです。 なぜなら、次に取り込まれるチャンスまでどれくらい時間がかかるかがわかってしまうからです。 リリースプロセスの複雑さと、プロジェクトの性質にもよりますが、 3ヶ月から6ヶ月の間くらいが、普通は適切なリリース間隔です。しかし、 安定版のリリースラインは、もうすこし早い間隔でマイクロリリースを出した方がよいかもしれません。