技術的な観点からプロジェクトのウェブサイトを立ち上げることについては、 それほど語ることはありません。ウェブサーバを起動し、 ウェブページを書くことはかなり単純な仕事ですし、 ページの配置や設計に関して重要なことはほとんど以前の章で述べました。 ウェブサイトの主な機能は、明快にプロジェクトの概要を提供し、 (バージョン管理システム, バグ追跡システムなどの)他のツールをウェブサイトと結びつけることです。 たとえあなたにウェブサーバを設定して起動する技量がなくても、 その作業を喜んでやってくれる人を探すことは普通難しくありません。 とはいえ、時間と労力を節約するために、 プロジェクトを運営するためのツールが一通り揃っているホスティングサイトがよく好んで使われます。
一通りのものが揃ったホスティングサイトには、主に二つの利点があります。 ひとつめは、サーバのディスク容量とネットワーク帯域の太さです。つまり、 超高速なネットワーク上に、複数のサーバマシンが巨大なラックに収納されているのです。 プロジェクトがどれだけ成功しても、ディスク容量を使い切ったり、 ネットワーク接続が使い物にならなくなることはないでしょう。 ふたつめは、サイトの維持が簡単なことです。 ホスティングサイトは、バグ追跡システム、バージョン管理システム、 メーリングリスト管理システム、アーカイバや、 プロジェクトのウェブサイトを運営するのに必要ものを全て選んでくれています。 また、それらは既に設定済みであり、蓄積される全てのデータのバックアップにも注意を払ってくれます。 多くの決断をする必要はありません。フォームに入力し、ボタンを押しさえすればよいのです。 そうすれば巨大なプロジェクト用ウェブサイトが突然手に入ることでしょう。
これらはとても重要な利点です。勿論、他のツールでよいものがあったとしても、 ホスティングサイトが 選択したツールや設定を受け入れなければならないという欠点があります。 ホスティングサイトは、設定できるパラメータの範囲を普通狭くしているので柔軟性がありません。 自前でウェブサイトを立ち上げてサーバへの完全な管理権限を持っていた場合にできる、 きめの細かい制御は決してできないでしょう。
このことのよい例が、自動生成されるファイルの扱いです。 あるプロジェクトのウェブページは、自動生成されたファイルかもしれません — たとえば、FAQのデータを編集しやすいマスターフォーマットに保存し、それからHTMLやPDF、 その他表示用のフォーマットを生成するシステムがあるとします。 この章の すべてをバージョン管理する項 で説明したとおり、 あなたは自動生成されたフォーマットではなく、 マスターファイルだけをバージョン管理したいと考えるでしょう。 しかしウェブサイトが他人のサーバに置いてある場合は、 マスターファイルが変更された場合にFAQのHTML版を再生成するカスタムフックを設定できないかもしれません。 唯一の回避策は、ウェブサイトで表示できるように自動生成されたフォーマットもバージョン管理することです。
もっと大きな影響があるかもしれません。 あなたが望むほどウェブサイトの見た目を変える権限がないかもしれません。 ホスティングサイトの中には、ウェブページをカスタマイズすることを許可してはいますが、 結局はデフォルトの配置がうんざりするようなやり方で表示されてしまうものもあります。 たとえば、SourceForge がホスティングしているプロジェクトの中には、 完全にカスタマイズしたホームページがあるけれども、 詳しい情報を参照させるために "Sourceforge上のページ" に開発者を誘導しているものがあります。 SourceForge のページは、プロジェクトのホームページになるはずのものでしたが、 ユーザーに自前のホームページを使わせないようにしています。 SourceForge のページには、バグ追跡システムやCVSリポジトリ、ダウンロードサイトへのリンクなどがあります。 不幸なことに、SourceForge のページにはたくさんのプロジェクトとは無関係なリンクも含まれているのです。 ページの一番上部にはバナー広告がありますが、アニメーション画像であることもよくあります。 左側にはプロジェクトに興味がある人には殆ど関係がないリンクが垂直に配置されています。 右側には別の広告がよく配置されています。 ページの中央部分だけが本当にプロジェクトに特有の事項に専用の場所になっていますが、 これらもわかりにくい方法で配置されているので、 訪問者が次にどこをクリックしたらいいのかわからなくなってしまうことがよくあります。
SourceForge のページ設計の裏には、きっと — 広告のように、 SourceForge の立場からすれば尤もな理由があるのでしょう。しかし、 プロジェクトの立場から見れば、その結果が理想のウェブページとはかけ離れたものになるかもしれません。 私は SourceForge を非難するつもりで言っているのではありません。 似たような懸念は多くのホスティングサイトにも当てはまります。 重要なのは、トレードオフが存在するということです。 プロジェクトのウェブサイトを維持するための技術的な重荷から解放されますが、 他人のやり方を受け入れることとひきかえにはじめて恩恵を受けられるのです。
ホスティングサイトがプロジェクトに最適かどうかを決められるのはあなただけです。 仮にホスティングサイトを選んだ場合、プロジェクトの"ホームとなるURL"に自前のドメインを使うことで、 自前のサーバに移行する余地を残しておくようにしましょう。 自前のURLをホスティングサイトに転送することもできますし、 公開されているURLに完全に手を加えたホームページを置くことで、 ユーザーを洗練された機能を持ったホスティングサイトに誘導することもできます。 ウェブサイトのホスティングについて後に別の解を選んだとしても、 プロジェクトのURLは変えないように確実に準備をしておくようにしましょう。
最も規模が大きく、有名なホスティングサイトは SourceForge です。 他には、savannah.gnu.org と BerliOS.de の二つが SourceForge と同様または類似のサービスを提供しています。 Apache Software Foundation や Tigris.org[25] のような組織は、自分達の任務と既にあるプロジェクトのコミュニティーにうまく合っているオープンソースプロジェクトを無料でホスティングしています。
厳密にはホスティングサイトに限った問題ではないのですが、 ホスティングサイトで最もよく見られるのが、ユーザーログインの機能に関する苦情です。 ログイン機能自体は十分単純です。 ウェブサイトでは、訪問者が自分のユーザー名とパスワードを登録することができるのです。 登録するとユーザーのプロフィールが保存され、 プロジェクトの管理者は、ユーザーにリポジトリへのコミット権限のような特定の権限を与えることができます。
この機能は非常に有用で、ホスティングサイトの主な利点のひとつです。 問題は、未登録のユーザーにも許可されるべきタスク、 特にバグ追跡システム内のファイルアップロードや、既存の問題にコメントをつけるときに、 往々にしてログインが必要になってしまっている点にあります。 こうしたタスクにログインを必要としてしまうと、 本来迅速で便利であるべきタスクに参加する敷居が高くなってしまいます。 勿論、バグ追跡システムにデータを登録した人に連絡を取りたい人もいますが、 その場合は(本人が望んだ場合に)電子メールアドレスを入力できるフィールドを設けておけば十分です。 新しいユーザーがバグを発見して報告したいと思ったとして、 バグ追跡システムに入力する前にアカウント作成フォームを入力しないといけないとわかればうんざりするでしょう。 そのユーザーは結局バグを登録しないかもしれません。
ユーザーを管理する利点は、通常は欠点に勝るものです。 しかしユーザーを匿名で行動させる選択肢があるなら、 全ての 読み取り専用のアクションだけでなく、 特にバグ追跡システムや、持っているならwikiページのデータ入力についても、 ログインしていないユーザーに許可するようにしましょう。