技術的な観点からプロジェクトのウェブサイトを立ち上げることについては、 それほど語ることはありません。ウェブサーバを起動し、 ウェブページを書くことはかなり単純な仕事ですし、 ページの配置や設計に関して重要なことはほとんど以前の章で述べました。 ウェブサイトの主な機能は、明快にプロジェクトの概要を提供し、 (バージョン管理システム, バグ追跡システムなどの)他のツールをウェブサイトと結びつけることです。 たとえあなたにウェブサーバを設定して起動する技量がなくても、 その作業を喜んでやってくれる人を探すことは普通難しくありません。 とはいえ、時間と労力を節約するために、 プロジェクトを運営するためのツールが一通り揃っているホスティングサイトがよく好んで使われます。
一通りのものが揃ったホスティングサイトには、主に二つの利点があります。 ひとつめは、サーバのディスク容量とネットワーク帯域の太さです。つまり、 超高速なネットワーク上に、複数のサーバマシンが巨大なラックに収納されているのです。 プロジェクトがどれだけ成功しても、ディスク容量を使い切ったり、 ネットワーク接続が使い物にならなくなることはないでしょう。 ふたつめは、サイトの維持が簡単なことです。 ホスティングサイトは、バグ追跡システム、バージョン管理システム、 メーリングリスト管理システム、アーカイバや、 プロジェクトのウェブサイトを運営するのに必要ものを全て選んでくれています。 また、それらは既に設定済みであり、蓄積される全てのデータのバックアップにも注意を払ってくれます。 多くの決断をする必要はありません。フォームに入力し、ボタンを押しさえすればよいのです。 そうすれば巨大なプロジェクト用ウェブサイトが突然手に入ることでしょう。
これらはとても重要な利点です。勿論、他のツールでよいものがあったとしても、 ホスティングサイトが 選択したツールや設定を受け入れなければならないという欠点があります。 ホスティングサイトは、設定できるパラメータの範囲を普通狭くしているので柔軟性がありません。 自前でウェブサイトを立ち上げてサーバへの完全な管理権限を持っていた場合にできる、 きめの細かい制御は決してできないでしょう。
このことのよい例が、自動生成されるファイルの扱いです。 あるプロジェクトのウェブページは、自動生成されたファイルかもしれません — たとえば、FAQのデータを編集しやすいマスターフォーマットに保存し、それからHTMLやPDF、 その他表示用のフォーマットを生成するシステムがあるとします。 この章の 「すべてをバージョン管理する」 で説明したとおり、 あなたは自動生成されたフォーマットではなく、 マスターファイルだけをバージョン管理したいと考えるでしょう。 しかしウェブサイトが他人のサーバに置いてある場合は、 マスターファイルが変更された場合にFAQのHTML版を再生成するカスタムフックを設定できないかもしれません。 唯一の回避策は、ウェブサイトで表示できるように自動生成されたフォーマットもバージョン管理することです。
もっと大きな影響があるかもしれません。 あなたが望むほどウェブサイトの見た目を変える権限がないかもしれません。 ホスティングサイトの中には、ウェブページをカスタマイズすることを許可してはいますが、 結局はデフォルトの配置がうんざりするようなやり方で表示されてしまうものもあります。 たとえば、SourceForge がホスティングしているプロジェクトの中には、 完全にカスタマイズしたホームページがあるけれども、 詳しい情報を参照させるために "Sourceforge上のページ" に開発者を誘導しているものがあります。 SourceForge のページは、プロジェクトのホームページになるはずのものでしたが、 ユーザーに自前のホームページを使わせないようにしています。 SourceForge のページには、バグ追跡システムやCVSリポジトリ、ダウンロードサイトへのリンクなどがあります。 不幸なことに、SourceForge のページにはたくさんのプロジェクトとは無関係なリンクも含まれているのです。 ページの一番上部にはバナー広告がありますが、アニメーション画像であることもよくあります。 左側にはプロジェクトに興味がある人には殆ど関係がないリンクが垂直に配置されています。 右側には別の広告がよく配置されています。 ページの中央部分だけが本当にプロジェクトに特有の事項に専用の場所になっていますが、 これらもわかりにくい方法で配置されているので、 訪問者が次にどこをクリックしたらいいのかわからなくなってしまうことがよくあります。
SourceForge のページ設計の裏には、きっと — 広告のように、 SourceForge の立場からすれば尤もな理由があるのでしょう。しかし、 プロジェクトの立場から見れば、その結果が理想のウェブページとはかけ離れたものになるかもしれません。 私は SourceForge を非難するつもりで言っているのではありません。 似たような懸念は多くのホスティングサイトにも当てはまります。 重要なのは、トレードオフが存在するということです。 プロジェクトのウェブサイトを維持するための技術的な重荷から解放されますが、 他人のやり方を受け入れることとひきかえにはじめて恩恵を受けられるのです。
ホスティングサイトがプロジェクトに最適かどうかを決められるのはあなただけです。 仮にホスティングサイトを選んだ場合、プロジェクトの"ホームとなるURL"に自前のドメインを使うことで、 自前のサーバに移行する余地を残しておくようにしましょう。 自前のURLをホスティングサイトに転送することもできますし、 公開されているURLに完全に手を加えたホームページを置くことで、 ユーザーを洗練された機能を持ったホスティングサイトに誘導することもできます。 ウェブサイトのホスティングについて後に別の解を選んだとしても、 プロジェクトのURLは変えないように確実に準備をしておくようにしましょう。
2011年が始まった現時点で、自由につかえるホスティングサイトとして定評のあるのは次の三つです。 これらはすべて、オープンソースライセンスで公開するプロジェクト用に無料で使うことができます。 また、バージョン管理システムやバグ追跡システム、そして Wiki も用意されています (バイナリのダウンロード機能など、その他の機能を用意しているところもあります)。
GitHub 対応しているバージョン管理システムは Git だけですが、もし自分のプロジェクトで Git を使っているのならここを選ぶのが適切でしょう。GitHub は Git を使ったプロジェクトの世界の中心となっており、 各種サービスも Git と統合されています。 また GitHub には、プログラムからそのサービスを利用するための API も完備されています。 メーリングリストはありませんが、メーリングリストのサービスは他にもいろいろあるので たいした問題にはならないでしょう。
Google Code Hosting 対応しているバージョン管理システムは Subversion と Mercurial (少なくとも現時点では Git は未対応) で、 Wiki やダウンロードエリア、そしてよくできたバグ追跡システムも用意されています。 また、API もあります。バージョン管理システムには当然ながらそれ自身の API があり、問題追跡システムにも 専用の API があります。Wiki のコンテンツは バージョン管理システムと連動 しているので、スクリプトから編集することができます。 また、ダウンロードエリアにも スクリプトによるアップロード という名の API が用意されています。 また、メーリングリストとして Google Groups が使えます。
SourceForge これは最も古くからあるホスティングサイトで、古くからあるだけあって今でも規模が最大です。 他の二つのサイトが用意する機能をすべて備えており、インターフェイスも非常に使いやすいものです。 しかし、プロジェクトのページに表示される広告ブロックが気になるという人もいます。 現時点では、ホスティングサイトの三巨頭の中で唯一、主要なバージョン管理システム (Git、Subversion、Mercurial そして CVS) のすべてに対応しています。 SourceForge にはメーリングリストサービスも用意されていますが、 もちろん他のメーリングリストサービスを使うこともできます。
Apache Software Foundation のように、自分達の任務と既にあるプロジェクトのコミュニティーにうまく合っているオープンソースプロジェクトを無料でホスティングしている組織もあります。
どれにすればいいかわからない場合は、これら三巨頭のいずれかを選ぶことを強くおすすめします。 もう少し詳しく言うと、もしバージョン管理システムに Git を使っているのなら GitHub を、 それ以外を使っているのなら Google Code Hosting を使うといいでしょう。 SourceForge も悪くありませんが、現時点で敢えて SourceForge を選ぶ特筆すべき理由はありません。 また広告も気になります。
お気づきの人も多いでしょうが、フリーなホスティングサイトの多くは、 そのサイト自身を構成するソフトウェアをフリーソフトウェアのライセンスで公開していません (公開しているサイトとしては Launchpad や Gitorious そして GNU Savannah があります)。 個人的には、サイト自身を構成するソフトウェアのすべてのコードにもアクセスできるのが理想だと考えます。 自分のデータをエクスポートしたり、自分のデータの操作を自動化させたりできるということが重要だからです。 そのようなサイトであれば決してそこにロックインされることがなくなり、 さらにプログラムを通じて拡張可能になります。 ホスティングサイトを動かすためのすべてのコードをオープンソースで入手することにはそれなりの価値があります。 とはいえ、実際にそのコードを運用するということはほとんどのユーザーにとって無理な話です。 これらのサイトには何台ものサーバーやカスタマイズしたネットワーク、 そして専任スタッフが必要になります。いずれにせよ、単にコードを持っているだけでは、 サービスを複製したり「フォーク」したりするのは無理なのです。 大事なのは、自分のデータがしばられてしまわないのを確実にするということです。
Wikipedia に ホスティングサービスの比較 (日本語) の記事があります。オープンソースプロジェクトのホスティング環境の最新情報については、まずここを見るとよいでしょう。 また、Haggen So は、博士論文 Construction of an Evaluation Model for Free/Open Source Project Hosting (FOSPHost) sites の研究の一環としてさまざまなホスティングサイトを評価しました。 発表されたのは 2005 年ですが、2007 年に更新されています。 この評価基準は今後も長く使えるでしょう。彼の調査結果は http://www.ibiblio.org/fosphost/ にあり、 比較結果の表は http://www.ibiblio.org/fosphost/exhost.htm です。
possv2 24 March 2013: If you're reading this note, then you've encountered this chapter while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note the possibility of mixing services from different canned hosting sites. Also, talk about the importance of APIs for an exit export. Mention the Google Groups conundrum. Maybe replace some of the above commentary with a reference to 付録A Canned Hosting Sites.
厳密にはホスティングサイトに限った問題ではないのですが、 ホスティングサイトで最もよく見られるのが、ユーザーログインの機能に関する苦情です。 ログイン機能自体は十分単純です。 ウェブサイトでは、訪問者が自分のユーザー名とパスワードを登録することができるのです。 登録するとユーザーのプロフィールが保存され、 プロジェクトの管理者は、ユーザーにリポジトリへのコミット権限のような特定の権限を与えることができます。
この機能は非常に有用で、ホスティングサイトの主な利点のひとつです。 問題は、未登録のユーザーにも許可されるべきタスク、 特にバグ追跡システム内のファイルアップロードや、既存の問題にコメントをつけるときに、 往々にしてログインが必要になってしまっている点にあります。 こうしたタスクにログインを必要としてしまうと、 本来迅速で便利であるべきタスクに参加する敷居が高くなってしまいます。 勿論、バグ追跡システムにデータを登録した人に連絡を取りたい人もいますが、 その場合は(本人が望んだ場合に)電子メールアドレスを入力できるフィールドを設けておけば十分です。 新しいユーザーがバグを発見して報告したいと思ったとして、 バグ追跡システムに入力する前にアカウント作成フォームを入力しないといけないとわかればうんざりするでしょう。 そのユーザーは結局バグを登録しないかもしれません。
ユーザーを管理する利点は、通常は欠点に勝るものです。 しかしユーザーを匿名で行動させる選択肢があるなら、 全ての 読み取り専用のアクションだけでなく、 特にバグ追跡システムや、持っているならwikiページのデータ入力についても、 ログインしていないユーザーに許可するようにしましょう。