どこかの誰かがあなたのプロジェクトのことを聞きつけたとしましょう。 おそらく、何かの問題を解決するためのソフトウェアを検索しているときに見つけたのでしょう。 彼らが真っ先に目にするのは、そのプロジェクトの名前です。

すばらしい名前をつけたからといって、 そのプロジェクトの成功が約束されるわけではありません。 また、変な名前をつけたからといって それだけの理由でプロジェクトが失敗するというわけでもありません —もちろん、あまりにも マズい名前をつけてしまったら悪影響があるかもしれません。 しかし、わざわざプロジェクトを失敗に持っていくようなことはしないだろう という前提の下で話を進めます。 ただ、(あまりにも不真面目だったり覚えにくかったりといった) 変な名前をつけてしまうと、そのプロジェクトの利用に踏み切るまでに 時間がかかってしまうかもしれません。

よい名前とは、次のような条件を満たすものです。

プロジェクトのウェブサイトを訪れた人たちが次に見るものは、 そのプロジェクトについての簡単な説明や目標などのメッセージです。 それらを見て (たいていは 30 秒程度で)、人は そこから先に進むか引き返すかを決断します。 このメッセージは、トップページの目立つ場所に配置しなければなりません。 プロジェクト名のすぐ下に置くといいでしょう。

この声明は、具体的で内容を絞り込み、そしてなによりも簡潔でなければなりません。 たとえば、以下に引用した http://www.openoffice.org/ の記述などがよい例です。

たったこれだけの文章ですが、訪問者に予備知識を与えるという意味ではこれで十分です。 "コミュニティとして (as a community)" と明記することにより、 どこかの企業が開発するものではないことを表しています。また "国際的な (international)" という言葉によって、 このソフトウェアが複数の言語や地域で動作することを示しています。 そして "すべての主要なプラットフォーム (all major platforms)" とあることから、おそらく Unix、Macintosh そして Windows で動作するであろうことが読み取れます。 その他の箇所からは、インターフェイスが公開されていることや ファイルのフォーマットが一般的なものであることなどがわかるでしょう。 彼らが Microsoft Office の代わりとなるフリーソフトウェアを作ろうとしているとはどこにも書かれていません。 しかし、たいていの人は行間からその気持ちを読み取ることができるでしょう。 この声明はかなり大風呂敷を広げているように見えますが、 事実上これらは密接に絡み合っています。 また "オフィススイート (office suite)" という言葉を使用することで、その手のソフトウェアになじみがある人たちにとって かなり具体的な印象を与えることができます。つまり、 訪問者が持っているであろうと思われる前提知識 (この場合は MS Office に関するもの) を利用して、この声明を簡潔にまとめているのです。

この声明の本質は、それが対象としているソフトウェアだけではなく 「だれがそれを書いたか」にも依存します。 たとえば、OpenOffice.org があえて "コミュニティとして (as a community)" と書いているのがいい例です。 このプロジェクトはもともと Sun Microsystems が始めたものであり、 現在も同社が主なスポンサーとなっているからです。 あえてこの文言を含めることで Sun は「開発プロセスを 支配するようなつもりはない」ということを示しているわけです。 このように「そのような懸念があることを認識している」 ということを示すだけでも、あとで問題が発生する 可能性を減らすことができます。 一方、特定の企業の支援を受けているわけではないプロジェクトについては このような文言は不要でしょう。結局のところ、 普通はコミュニティベースの開発になるわけですから、 それをわざわざ示す必要はないわけです。

プロジェクトの目標についての説明 (ミッションステートメント) を読んで興味を持ったひとたちは、もっと詳細な情報を知りたくなることでしょう。 たとえばユーザ向けドキュメントや開発者向けドキュメントなど。 そして、何かをダウンロードしたくなるでしょうね。 でもその前に、まずはそれがオープンソースなのかどうかを知る必要があります。

プロジェクトのトップページで、 それがオープンソースであることを明記しておかなければなりません。 当然のことだとお考えかもしれません。しかし、 世の中にはそれができていないオープンソースプロジェクトが山ほどあります。 私がかつて見たとあるフリーソフトウェアプロジェクトのウェブサイトのトップページでは、 そのソフトウェアの配布時にどのライセンスを適用するかが示されておらず、 さらにそのソフトウェアがフリーなのかどうかさえ書かれていませんでした。 また、このような重要な情報が ダウンロードページや開発者向けページなどにしか存在しないというページもよくあります。 このような場合は、重要な情報を得るためにさらにマウスクリックが必要となってしまいます。 最もひどかった例では、ウェブサイト上のどこにもライセンスが示されていなかったものもありました。 ソフトウェアをダウンロードしてその中身を見ない限り、ライセンスの内容がわからなかったのです。

同じようなミスはしないでください。 そんなことをすると、せっかくの開発者候補やユーザ候補の多くを失うことになります。 トップページのミッションステートメント部の次に、そのプロジェクトが 「フリーソフトウェア」あるいは「オープンソース」であることを示し、 さらに具体的なライセンスについても記しておきましょう。 どのライセンスを適用すればいいかについては ライセンスの選択と適用項で説明します。 また、ライセンスに関するさまざまな問題については 章 9. ライセンス、著作権、そして特許 で詳しく説明します。

ここまでの情報を見るのに、訪問者が要する時間は１分かそれ以下でしょう。 これらの内容をもとに、彼/彼女 らがさらに次を読み進めるかどうかを決断するわけです。 次のセクションでは、最初の５分間で訪問者が見るであろう内容について扱います。

そのソフトウェアのちょっとした機能一覧 (まだ完成していない機能を一覧に含めてもかまいません。しかしその場合は "予定" とか "開発中" などとはっきり示して置くようにしましょう)、 そしてそれを動かすために必要な要件についての説明が必要です。 機能一覧/要件一覧は、そのプロジェクトについて誰かに聞かれたときに 答えるためにまとめたものと考えるといいでしょう。 これは、単にミッションステートメントの内容をより深く掘り下げたものと考えてもかまいません。 たとえば、ミッションステートメントで次のように説明したとすると、

機能一覧、要件一覧でその詳細を説明することによって ミッションステートメントの範囲を明確にします。

これらの情報によって、訪問者はそのソフトウェアが自分の希望を満たすものかどうかを判断します。 また場合によっては開発者としてプロジェクトに参加することを検討してくれるかもしれません。

そのプロジェクトがいったい何をやっているのか、訪問者たちはきっと気になることでしょう。 特に新しいプロジェクトの場合は、 そのプロジェクトが掲げている目標のうち 現在どれくらいが達成されているのかが気になるところです。 十分に成熟したプロジェクトの場合に気になるのは、 「そのプロジェクトが現在活発に保守されているのか」 「どれくらいの頻度で新しいバージョンがリリースされているのか」 「バグレポートに対する反応の速さはどれくらいか」 などとなります。

これらの質問に答えるために、開発状況を示すページを作らなければなりません。 ここには、直近の目標とそれを達成するために必要なもの (たとえば「ある特定の分野に強い開発者を募集しています」など) を表示します。また、過去のリリース履歴や機能一覧などもここに掲載するといいでしょう。 そうすることで、そのプロジェクトの「進捗状況」がわかりやすくなります。

まだできあがっていないことを恐れる必要はありません。 できあがってもいないことを変にごまかすこともやめましょう。 ソフトウェアの開発にはいくつかの段階があることを、みんな知っています。 "このソフトウェアはアルファ版です。まだバグが存在します。 とりあえずは動作するでしょう。しかし、自己責任のもとで使用するようにしてください" と言ったところで、何も恥ずかしいことはありません。 そのような段階でプロジェクトが必要としている開発者は、 「アルファ版」という説明なんかではおびえたりしません。対エンドユーザという面では、 まだできあがってもいないソフトウェアにユーザが群がってしまうほどまずいことはありません。 いったん「不安定」だとか「バグだらけだ」だとかいう評判が出てしまうと、 それを払拭するのは大変な話になります。 結局のところ、多少保守的なほうがうまくいきます。 そのソフトウェアが「ユーザが期待しているよりも安定していた」 ほうが、期待はずれだった場合よりもずっといいでしょう。 そしてそのほうが、口コミによる広がりが期待できます。

標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要があります。 プロジェクトを立ち上げた最初のうちは、バイナリ (実行可能) パッケージはなくてもかまわないでしょう。 ただし、ビルド手順が面倒だったり依存性が複雑だったりする場合は バイナリ版も必要です (でも、 そんなプロジェクトは開発者にとってはあまり魅力的ではありません)。

配布形態は、便利で標準的なものにしましょう。 また、できるだけ利用者の負担を減らすべきです。 あなたがある病気の撲滅を狙っているなら、 薬を配る際に独自の注射器が必要となるような面倒な手段はとらないでしょう。 同様に、ソフトウェアについても標準的な手順で ビルド・インストールできるようにしておきましょう。 標準から外れれば外れるほど、 ユーザ候補や開発者候補はそのプロジェクトから離れてしまいます。

当然のことだと思われるかもしれません。 しかし、多くのプロジェクトは本当に切羽詰るまで インストール手順を標準化しようとはしないものです。 "ま、リリース予定日が迫ってきたら、 そのときにやろうよ。そんなことはいつでもできるんだから。" といった言い訳をしてしまいがちです。 彼らはわかっていないのです。そういった作業を後回しにしてしまうと、 結果的に余計に時間がかかってしまうということを。 また、それによって多くの開発者を失っていることにも気づいていないでしょう。 「誰かがウェブサイトを訪れた→ソフトウェアをダウンロードした →ビルドしようとした→失敗した→あきらめた」 ということがあちこちで積み重なっているはずです。 あきらめた本人以外には、そんなことがあったということはわかりません。 もともとあなたのプロジェクトに興味を持っていてくれたはずの人が黙って立ち去ってしまった、 そしてそれをプロジェクトのメンバーは誰も気づかないのです。

面倒だが見返りの大きい作業は、できるだけ早めに済ませてしまいましょう。 パッケージをきちんと作成すると、 プロジェクトへの参加障壁を劇的におろすことができ、 結果として大きな見返りを得ることになります。

ダウンロード用のパッケージを作成したら、それに対して 一意なバージョン番号を与えることが大切です。 それによって人は、２つのリリースのうちどちらが新しいのかを知ることになるのです。 バージョン番号のつけかたについては 章 7. パッケージの作成、リリース、日々の開発 の リリースに番号を付ける項 で、 そしてビルド手順やインストール手順の標準化については同じ章の パッケージング項 でそれぞれ詳しく説明します。

単にそのソフトをインストールして使いたいだけという人にとっては、 ソースパッケージで十分でしょう。しかし、デバッグをしたり 機能追加をしたりしたい人たちにとってはそれだけでは不十分です。 毎晩最新ソースのスナップショットを作成するという手もありますが、 開発が活発に行われているコミュニティではまだこれでも完璧だとはいえません。 常にその時点の最新のソースにアクセスしたいという人たちにその手段を提供するのが、 バージョン管理システムです。 バージョン管理システム上のソースに匿名でアクセスできるようにしておくと、 「このプロジェクトは、新しいメンバーの参加を歓迎しています」 というメッセージをユーザと開発者の両方に送ることになります。 もし今すぐにバージョン管理システムを用意できない場合は、 近々公開予定であるというメッセージを書いておくようにしましょう。 バージョン管理システムについては 章 3. 技術的な問題 の バージョン管理項 で詳しく説明します。

バグトラッカーについても同じです。 バグ追跡システムは、単に開発者たちにとって便利であるだけではなく、 周りでそのプロジェクトの進み具合を見守っている人たちにとっても便利なものなのです。 多くの人は、バグデータベースが公開されていると 「熱心に開発が進められているようだ」と感じます。 さらに、バグデータベースにたくさんのバグが登録されていればいるほど、 そのプロジェクトの見栄えはよくなります。 ちょっと直感に反しているように思われるかもしれません。でも考えてもみてください。 バグデータベースにたくさんのバグが報告されているということからわかるのは、 次の３つの事実です。まず、そのソフトウェアにたくさんのバグが存在すること。 次に、多くのユーザがそのソフトウェアを使用しているということ。 そして最後に、ユーザが気軽にバグを登録できるということ。 最初の１つはともかく、残りの２つは特に重要です。 ある程度の規模と複雑さを持つソフトウェアには、 基本的にバグが含まれているものです。本当の問題は、 それらのバグをいかにして見つけ、どのように優先順位を設定するかというところにあります。 したがって、よく整備された (バグに対する対応がすばやく、 重複したバグ報告はきちんと統一されているなど) 大規模なバグデータベースがあると、 バグデータベースがなかったりほとんど機能していなかったりするプロジェクトより ずっと印象がよくなります。

もちろん、そのプロジェクトが本当に始まったばかりなのなら バグデータベースに登録される内容はほんのちょっとだけになるでしょう。 それについてはどうにもしようがありません。 しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、 かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、 訪問者はそのプロジェクトがちゃんと運営されていることを読み取ってくれるでしょう。 バグの登録数があまりにも少ないからといって、心配されることはありません。

バグトラッカーに登録されるのはソフトウェアのバグだけではありません。 機能追加の要望やドキュメントの変更、 とりあえず保留になっている作業などが登録されることも多々あります。 バグトラッカーの運用方法については 章 3. 技術的な問題 の バグ追跡システム項 で詳しく説明するので、 ここでは深く立ち入りません。プロジェクトの見栄えという観点から見て大切なのは、 まずバグトラッカーが 存在する ということ。 そしてそれがプロジェクトのトップページからたどれる場所にあるということです。

プロジェクトの関係者の連絡先を知りたいという人もあらわれることでしょう。 関係者と連絡を取れるように、メーリングリストのアドレスや チャットルーム、IRC チャンネル、掲示板などの場所を示しておきましょう。 あなた、あるいはその他のプロジェクト関係者がこのメーリングリストに参加していることも明記しておきましょう。 そうすることで、「そこに行けば開発者と話すことができる」ということが伝わります。 あなたがメーリングリストに参加しているからといって、 すべての質問に答えなければならないとか すべての要望に答えなければならないとかいった義務が発生するわけではありません。 長い目で見れば、ユーザのほとんどはこのようなメーリングリストや掲示板には参加しません。 とはいえ、必要ならいつでも参加できるということを示すだけで、 安心感を与えることができます。

プロジェクトを立ち上げたばかりのころは、 エンドユーザ向けと開発者向けにフォーラムを分ける必要はありません。 それよりも、プロジェクトにかかわる人たちが１つの「部屋」 に集まってわいわいがやがや話をするほうがずっといいでしょう。 アーリーアダプター層においては、開発者とユーザの区別はあいまいです。 あえて分類するとしても、プロジェクトの初期には開発者の比率がかなり高くなります。 アーリーアダプターのすべてがそのソフトウェアをハックしたいと思っているとは限りません。 しかし、少なくともそのプロジェクトの今後の方向性に関する議論には 興味を持っていることでしょう。

本章では「プロジェクトをどのように立ち上げるか」についてのみを扱っています。 この段階では「とりあえずコミュニケーション用の場所が必要だ」というくらいで十分でしょう。 後で、章 6. コミュニケーション の 巨大化への対応項 においてさらに詳しく説明します。 ここでは、掲示板の設置や管理の方法について扱います。 また、いつかユーザ向け会議室と開発者向け会議室を分割することになったときに、 両者の間に溝を生じさせないための方法も説明します。

開発者としてプロジェクトに参加しようと考えた人は、 まず開発者向けのガイドラインを探すことになるでしょう。 このガイドラインは、技術的なものというよりもむしろ社会的なものとなります。 たとえば開発者同士のやりとりの方法、ユーザとのやりとりの方法、 プロジェクトをうまく進めるためにどのようにしていくかなどです。

このトピックについては 章 4. プロジェクトの政治構造と社会構造 の 全てを記録しておく項 で詳しく説明します。 ここでは、そこに含める基本的な内容だけをまとめておきます。