第2章 さあ始めましょう

目次

手持ちのもので始めよう
名前の決定
明確な目標を掲げる
フリーであることを宣言する
機能一覧・要件一覧
開発の進捗状況
ダウンロード
バージョン管理システムやバグ追跡システムへのアクセス
連絡手段
開発者向けのガイドライン
ドキュメント
ドキュメントの公開方法
開発者向けドキュメント
使用例とスクリーンショット
公開場所
ライセンスの選択と適用
「何でもできる」ライセンス
GPL
ライセンスを適用する方法
うまく引っ張っていく
個人的な議論を避ける
炎上を阻止する
きちんとしたコードレビューの習慣
もともと非公開だったプロジェクトをオープンにするときには、 変化の大きさに気をつけよう
広報

フリーソフトウェアプロジェクトがどのようにして始まるのかについては、 Eric Raymond が説明しています。彼は、今や超有名になった文書 「伽藍とバザール (The Cathedral and the Bazaar)」 の中で次のように述べています。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

(http://www.catb.org/~esr/writings/cathedral-bazaar/ より引用。日本語訳は http://www.tlug.jp/docs/cathedral-bazaar/cathedral-paper-jp.html)

Raymond は、決して「開発者の個人的な悩み解決」 だけがオープンソースプロジェクトの始まるきっかけだとは言っていないことに注意しましょう。 というよりは、プログラマー自身が問題の解決に関心を持っているときに よいソフトウェアが出来上がることが多いと言っているのです。 フリーソフトウェアを作り始める動機としていちばん多いのが 「個人的な悩み解決」だったということでしょう。

現在でも同じ理由で始まるフリーソフトウェアプロジェクトは多いでしょうが、Raymond がこの文章を書いた 1997 年当時に比べるとその割合は少なくなっています。 現在では、巨大な中央管理型のオープンソースプロジェクト (営利団体が管理するものも含む) を最初から作ろうとする空気があります。 一匹狼のプログラマーが個人的な問題を解決するためにガシガシ書いたコードが 結果として広く受け入れられるということは今でもあるでしょうが、 いまやそれだけではなくなったということです。

しかし、Raymond の指摘は今でも洞察に満ちています。 ソフトウェアの作者自身がその成功に直接的な興味を持っている、 なぜなら彼らは自分自身でそれを使うことになるから、というのが本質的な条件です。 もしそのソフトウェアが期待通りに動かなければ、 日々それを使用している作者は不満に思うことになるでしょう。 たとえば OpenAdapter プロジェクト (http://www.openadapter.org/) を考えてみましょう。これは投資銀行 Dresdner Kleinwort Wasserstein が始めたオープンソースのフレームワークで、 さまざまな金融情報システムを統合するためのものです。 どう考えても、これは「開発者の個人的な悩み解決」 のために作られたものとはいえないでしょう。 これは「機関の悩み解決」をするためのものです。 しかし、この悩みはその機関とパートナーの経験から直接くるものです。 したがって、もしこのプロジェクトがうまくいっていなければ、それと気づくことができるでしょう。 このようなプロジェクトは、よりよいソフトウェアを産み出すでしょう。 なぜなら、フィードバックループが正しい方向に流れるからです。 そのプログラムは、見知らぬ誰かに売りつけて、彼らの問題を解決できるよう書かれるのではありません。 最初は自分たち自身の問題を解決するために書かれます。 そしてそれがみんなと共有されるようになります。 「問題」を病気にたとえると、ソフトウェアは薬のようなものです。 流行病を完全に根絶するために薬をばらまくのと同じように、ソフトウェアを配布するようになります。

本章では、新しいフリーソフトウェアプロジェクトをスタートさせる方法を扱います。 しかし、本章にかかれている内容の多くは、 保健機関が薬を配布するときの方法と似ていることでしょう。 両者の目標はよく似ています。薬の効能ははっきり示さないといけないでしょうし、 それを本当に必要とする人に手渡さないといけないでしょうし、 またそれを受け取った人は薬の扱い方を知っていなければなりません。 しかしソフトウェアの場合はさらに、 薬を改良するための研究に参加してもらうように患者を勧誘するという作業もあります。

フリーソフトウェアの配布作業は、2つの側面を有しています。 ソフトウェアのユーザーを獲得すると同時に、開発者も獲得しなければならないからです。 これら2つは必ずしも競合するものではありません。 しかし、プロジェクトを初めにどのように見せるかを考えると、これは少々複雑な話になります。 ユーザーと開発者の両方に対して有用な情報もあれば、 そのどちらか一方にしか役立たない情報もあります。 どちらの情報もスケールするプレゼンテーション (scaled presentation) の原則にしたがっていなければなりません。すなわち、 読み手が時間をかけて熱心に読めば読むほど、 それにあわせた詳細な情報が得られるようになっていなければなりません。 努力すればするほど、それに対する見返りが得られるべきです。 両者がきちんと相関していなければ、 人はすぐ信頼する心を失い、努力を注ぎ込むのをやめてしまうでしょう。

この系として言えるのが、見栄えは重要である ということです。 とりわけプログラマーという人種は、これを信じようとしません。 形式を差し置いた本質に対する彼らのこだわりは、ほとんど職人的プライドの域に達しています。 多くのプログラマーはマーケティングや広報活動を毛嫌いしているようだし、 プロのグラフィックデザイナも「プログラマーって人たちはいったい何を考えているのか」 と恐れているようですが、これは全く不思議なことではありません。

これは残念な話です。状況によっては形式こそが本質であり、 プロジェクトの見栄えの問題はその状況の1つだからです。 たとえば、あるプロジェクトの存在を知った人が最初に目にするのは、 そのプロジェクトのウェブサイトの見た目です。 実際に何が書かれているかとかどこにリンクされているとかよりも前に、 まずそのウェブサイトがどんな感じかということが目に入るわけです。 おかしな話だと思われるかもしれませんが、 人は第一印象の形成を抑制することができないものなのです。 サイトの見た目は、そのプロジェクトの見栄えの構成に配慮が払われたか否かという情報を発信します。 そして人間は、配慮の投資を検知するためのおそろしく感度のよいアンテナを備えているのです。 たいていの人は、そのサイトが片手間に作られたものか よく練りこまれているものかを一目見て判断することができます。 そのプロジェクトを世に出すにあたって最初に見てもらうところがウェブサイトなのですから、 その印象は連想によってプロジェクト全体に持ち越されるのです。

したがって、一方で本章では主にプロジェクトを開始するにあたり用意しておくべき内容について取り扱っているのですが、 その見栄えも重要であるということは忘れないでください。 プロジェクトのウェブサイトは (エンドユーザーと開発者の) 2種類の人たちが利用するものなので、 どちらを対象としたものなのかをはっきりさせる必要があります。 本書はウェブデザインの専門書ではありませんが、 ひとつだけ重要な法則を示しておきます。 このようにさまざまな相手 (部分的に重複することもあるでしょう) を対象とするときは特に重要なことです。 それは、リンク先に何があるのかが、リンクをクリックしなくても大まかにわかるようにしておく、ということです。 たとえば、ユーザー向けのドキュメントなのか開発者向けのドキュメントなのかが、 リンク先ではなくリンクそのものを見ただけで 判断できるようにしておくべきです。 プロジェクト運営には、情報を提供するという側面が一部にはあります。 しかしまた、安心感を提供するという側面もあるのです。 期待した場所に決まりきったものが提供されているというだけで、 そのプロジェクトに関わるか否か決めようとしているユーザーや開発者は安心します。 「このプロジェクトはやるべきことを行い、想定される質問に対応し、 その質問に対する答えをできるだけ簡単に得られるようにしている」という努力が見えるからです。 このような気合を見せることで「このプロジェクトに関わってもあなたの時間は無駄にならない」 というメッセージを送ることができます。それこそが皆が聞きたいメッセージです。

まずは周りを見渡すことから

オープンソースプロジェクトを始める前に、ひとつ忠告しておきます。

まずは周りを見渡して、同じようなプロジェクトが既に存在しないかどうかを確認しましょう。 あなたが今まさに解決しようと思っている問題を、 あなたよりも前に別の誰かが解決しようと思っていた可能性は大いにあります。 そして彼らが実際にその問題を解決し、コードをフリーなライセンスで公開しているのなら、 あなたがこれから車輪の再発明をする理由はありません。 もちろん、例外もあります。自分の勉強のためにプロジェクトを開始するのなら、 既存のコードは助けにならないでしょう。あるいは これからはじめようとしているプロジェクトがあまりにも特定の分野に特化したものであり、 他の人が同じことをしている可能性がゼロに等しい場合などもあるでしょう。 しかし通常は、あえて周りを見渡さない理由はありません。 見渡すことで得られる利益はかなりのものになるでしょう。 一般的なサーチエンジンで結果が得られなければ、 http://freecode.com/ (オープンソースプロジェクトに関するニュースサイト。 詳細は後ほど説明します) や http://www.sourceforge.net/、 そして Free Software Foundation のフリーソフトウェアディレクトリ (http://directory.fsf.org/) を調べてみましょう。

そのものずばりのものが見つからなかったとしても、 よく似たものが見つかるかもしれません。 そんな場合は、そのプロジェクトに合流して必要な機能を追加するほうが、 1から作り直すよりもいいでしょう。

手持ちのもので始めよう

まわりを見渡してみたけれど望みどおりのものが見つかりませんでした。 ということで、結局新しいプロジェクトを始めることになりました。

さて何をしたらいいのでしょう?

フリーソフトウェアプロジェクトの立ち上げ時に最も厄介なのは、 個人的なビジョンをみんなにわかる形に置き換えることです。 あなた (あるいはあなたの属する組織) にとっては何がやりたいのかは明白でしょう。 しかし、そのプロジェクトの目標が何なのかを一般にもわかるように表明することは、 それなりに大変な作業です。しかし、 かならず時間を割いてそれをやらなければなりません。 あなた (そして共同でプロジェクトを立ち上げた他のメンバー) は、まず「プロジェクトが実際何なのか」、すなわち、 「何をやるのか」と同時に 「何をやらないのか」という限界を決定し、 ミッションステートメントを書き上げなければなりません。 普通は、これはそれほど困難なことではありません。 しかし、この作業によって、プロジェクトの本質に関する暗黙の了解やさらには意見の相違まで浮かび上がってくるかもしれません。 それでいいんです。後になってからそれが判明するよりも、 早いうちに見つけてしまったほうが解決しやすくなります。 この作業が終われば、次にすることは 一般公開用のパッケージを作成することです。 これは、ぶっちゃけて言うと単純でつまらない純然たる骨折り仕事です。

何がそんなに面倒くさいのかというと、その作業の大半が、既にみんなが知っている —ここでいう「みんな」とは、これまでずっとプロジェクトにかかわってきた人のことです— ことをまとめ上げて文書化するということだからです。 つまり、その作業を実際に行う人には直接的なメリットは何もないのです。 彼らにとっては「このプロジェクトは……」というような README ファイルは不要ですし、もちろん設計文書やユーザーマニュアルなんかも不要です。 ソフトウェアをソースで配布するときにみんなが標準的に使っているような コードツリーを構成する必要も感じていないでしょう。 別にディレクトリ構成がどうであっても彼らは気にしません。 だってもうそのコードの内容を熟知しているのだし、 コードが動き出せば、あとはどう使えばいいのかも知っているわけですから。 彼らにとっては、そのプロジェクトの基本的な設計方針が文書化されていなくても平気です。 だってそれは彼らの頭の中にちゃんとあるのですから。

一方、新参者にとってはそのようなドキュメントは必須です。 とはいえ、幸いなことにすべてのドキュメントが一度に必要となるわけではありません。 プロジェクトを公開する前に、あらゆるリソースを提供できるようにしておく必要はありません。 理想を言えば、新しいオープンソースプロジェクトを始めるときには 設計文書や完全なユーザーマニュアル (今後実装予定の機能についての説明も含む)、 複数プラットフォームで動作するきれいにパッケージされたコードなどがそろっているといいのでしょう。 しかし現実的には、これらをばっちりそろえることは手間がかかりすぎます。 それになにより、ひとたびプロジェクトが動き出せば、 これらの作業に対するボランティアの協力を正当に期待できるのです。

しかし、何が本当に必要なのかといえば、 見栄えの調整に十分に力をいれ、 新入りさんが不慣れという名の最初の障壁を乗り越えられるようにすることです。 この作業をブートストラップ過程の第一段階、 プロジェクトをいわば活性化エネルギー最小の状態に持っていくことだと考えてください。 新入りさんが「このプロジェクトに対して何らかのかかわりと持とう」 と考えるために必要なエネルギーの閾値のことを、どこかの誰かが ハクティベーション (hacktivation) [12] エネルギー と呼んでいました。ハクティベーションエネルギーが低ければ低いほどいい、 というわけです。あなたが最初に行う作業は、 プロジェクトのハクティベーションエネルギーを下げて いろいろな人たちがプロジェクトに参加しやすくすることとなります。

以下の各項では、新しいプロジェクトをはじめるにあたって重要となる内容について個別に説明します。 そのプロジェクトをはじめて知った人が遭遇するであろう順に並べていますが、 もちろんこのとおりの順で作成しなければならないというわけではありません。 これらの項目を、チェックリストとして用いるといいでしょう。 プロジェクトをはじめる際にはこれらの各項目が網羅されていることを確認するか、 あるいはもし省略した項目がある場合は、 せめて予想される結果が満足のいくものであることを確認しましょう。

名前の決定

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

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

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

  • そのプロジェクトのやることが多少なりとも分かること、 あるいは少なくとも明らかな形でそれと関連があること。 そうすることで、名前とやることを知ってもらったあと、 その名前をすぐ思い出してもらえるようにするのです。

  • 覚えやすいこと。 ここで、インターネットのデフォルト言語が英語となっている という事実を無視することはできません。つまり「覚えやすい」 とは「英語が読める人にとって覚えやすい」ということです。 英語のネイティブスピーカーの発音に基づくだじゃれを用いた名前などは、 英語を母国語としない多くの人たちにとってはわかりにくいものとなるでしょう。 ただ、それが人の心をひきつけるほど印象的なものならば だじゃれを使用する価値もあるでしょう。 英語を母国語としない人たちからみると、 だじゃれを用いたプロジェクト名を見てもその読み方を想像しにくくなる ということを覚えておきましょう。

  • 既存の別のプロジェクト名と重複しない、 そして商標権を侵害しないものであること。 これは、礼儀の問題であると同時に法的にもよい考えです。 別のプロジェクトと混同されてしまうようなことは望ましくないでしょう。 別々のものが同じ名前を持っていなかったとしても、 ネットで手に入るものすべてを追跡するのは既に十分困難なことなのです。

    あなたが考えているのと同じ名前のプロジェクトが既に存在するかどうかを調べるには、 まずは周りを見渡すことから項 で示したリソースを使用するといいでしょう。 登録商標に関する検索は http://www.nameprotect.org/http://www.uspto.gov/ で行えます。

  • できれば、.com.net.org のようなトップレベルドメインが利用できる名前を選びましょう。 この中のいずれか1つ (おそらく .org でしょう) を選び、プロジェクトの公式サイトとして宣伝します。 他の2つのトップレベルドメインについては単純に プロジェクトのサイトに転送させるだけにしておきます。 これにより、第三者にそのドメインを悪用される心配をなくします。 仮にそのプロジェクトのサイトを別の場所 (公開場所項 を参照してください) におくとしても、プロジェクト名のドメインは取得しておくべきです。 そして、それらのサイトからプロジェクトの本来のページに転送させるようにしましょう。 そうすることで、覚えやすいシンプルな URL を提供することができます。

明確な目標を掲げる

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

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

To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. (コミュニティーとして、国際的な最先端のオフィススイートを作成します。 すべての主要なプラットフォーム上で動作し、 そのすべての機能やデータに対して オープンコンポーネントベースの API と XML ベースのファイルフォーマットでのアクセス機能を提供します)

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

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

フリーであることを宣言する

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

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

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

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

機能一覧・要件一覧

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

豊富な API を備えた全文インデクサー・サーチエンジンを作成します。 大量のテキストファイルに対する検索サービスを準備するプログラマーの利用を想定しています。

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

機能

  • プレーンテキスト、HTML および XML の検索

  • 単語あるいはフレーズによる検索

  • (予定) あいまい検索

  • (予定) インデックスの差分更新

  • (予定) リモートのウェブサイトのインデックス化

要件

  • Python 2.2 以降

  • インデックス作成用のディスク領域 (元のデータの約2倍の大きさ)

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

開発の進捗状況

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

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

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

ダウンロード

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

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

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

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

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

バージョン管理システムやバグ追跡システムへのアクセス

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

バグ追跡システムについても同じです。 バグ追跡システムの意義は、開発者に対する有用性だけでなく、 それがプロジェクトの観察者に対して発している暗黙のメッセージにも存在します。 多くの人は、バグデータベースが公開されていると 「熱心に開発が進められているようだ」と感じます。 さらに、バグデータベースにたくさんのバグが登録されていればいるほど、 そのプロジェクトの見栄えはよくなります。 ちょっと直感に反しているように思われるかもしれません。でも考えてもみてください。 バグデータベースに登録されたバグの数が実際何に依存しているかというと、 それは次の3つです。まず、そのソフトウェアに存在するバグの絶対数。 次に、そのソフトウェアを使用しているユーザー数。 そして最後に、ユーザーが新規のバグを登録できるための利便性です。 このうち最初の1つよりも後ろの2つの方が重要な要素になります。 ある程度の規模と複雑さを持つソフトウェアには、 基本的にバグが含まれているものです。本当の問題は、 それらのバグをいかにして見つけ、どのように優先順位を設定するかというところにあります。 したがって、よく整備された (バグに対する対応がすばやく、 重複したバグ報告はきちんと統一されているなど) 大規模なバグデータベースがあると、 バグデータベースがなかったりほとんど機能していなかったりするプロジェクトより ずっと印象がよくなります。

もちろん、そのプロジェクトが本当に始まったばかりなのなら バグデータベースに登録される内容はほんのちょっとだけになるでしょう。 それについてはどうにもしようがありません。 しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、 かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、 プロジェクトのバグ登録が健全な比率を保っている、 ということを読み取ることができます。 彼らはバグ登録の絶対数が小さいことを不当に警戒することはないでしょう。

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

連絡手段

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

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

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

開発者向けのガイドライン

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

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

  • 他の開発者とのやり取りのためのフォーラムの場所

  • バグ報告やパッチの投稿の方法

  • 開発の基本方針— 「慈悲深い独裁者」式でいくのか「民主主義」式でいくのか、 あるいはそれ以外の手法をとるのか

ところで、「独裁者」という言い方には、特にそれを批判する意図はありません。 特定の開発者だけがすべての変更に対する拒否権を行使できる というような専制政治を行ってもまったく問題はありません。 実際、多くのプロジェクトはこの方式で成功しています。 大事なのは、そのプロジェクトがそういう方針で運営されているとはっきり示しておくことです。 実際には独裁型なのに無理に民主主義っぽく見せようとすると、 人は離れていってしまいます。きちんと独裁型であることを宣言しておけば、 少なくともその独裁者が有能で信頼できる人である限りはうまく進みます。

開発者向けガイドラインの実例は http://subversion.apache.org/docs/community-guide/ をご覧ください。また、http://www.openoffice.org/dev_docs/guidelines.html には、より一般的なガイドラインがあります。こちらは、 技術的な話題よりもプロジェクトの管理体制やプロジェクトへの参加方法に重点を置いています。

プログラマー向けにソフトウェアについての説明を行うことについては、 本章の後半開発者向けドキュメント項 で取り上げます。

ドキュメント

ドキュメントは必要不可欠です。 何か読んでもらうものが必要です。 たとえそれがごく簡単な未完成のものであってもかまいません。 この作業はまさに、先ほど言及した「骨折り仕事」の範疇に属するものです。 新しいオープンソースプロジェクトがしばしば最初につまづくのがこの分野です。 ミッションステートメントや機能一覧を作成するとか、 ライセンスを選択するとか、開発状況をまとめるとかいったことはどれも比較的小規模な作業です。 しかも「ここまでできたら完了」という点がはっきりしており、 通常は一度作成すればそれ以降は手を加える必要のないものです。 ドキュメント作成はこれらとは異なり、 決して終わることのない作業です。 みんながドキュメント作成を嫌がるひとつの理由がここにあります。

ドキュメント作成において最も注意すべき点は、 ドキュメントの書き手にとって有用な内容と読み手にとって有用な内容とは まったく正反対であるということです。 はじめて使用するユーザーにとって必要なドキュメントは、 基本をまとめたものです。ソフトウェアを手っ取り早くセットアップする方法や 動作の概要、そして一般的な作業をするための手引きなどが必要でしょう。 しかし、これらの内容はまさに、ドキュメントの書き手 があまりにもよく知りすぎていることです。 そのためかえって、物事を読者の視点から眺めたり、また、 (ドキュメントの書き手にとっては) 言及に値しないほど明白な手順を、 骨を折って詳細に説明するのが困難になる可能性があります。

この問題を解決するためのマル秘手段は存在しません。 誰かが腰を落ち着けてそれを書かなければならないのです。 そして、初心者にそれを見せて内容をチェックしてもらわなければなりません。 ドキュメントの書式は、 たとえば HTML やプレーンテキスト、Texinfo あるいは各種 XML といったような、 シンプルで編集しやすいものにしましょう。 すなわち、ふと思ったときお手軽かつ迅速に更新するのに適した書式です。 これらを使用すると、ドキュメントの作成者があとからそれを更新する際の手間も少なくなります。 また、後からプロジェクトに合流した人にとっても、作業に参加しやすくなるでしょう。

基本ドキュメントをきちんと整備できるようにするためのひとつの方法としては、 ドキュメントで網羅する範囲を事前に限定してしまうというものがあります。 このようにしてしまうと、少なくともドキュメントの作成が 果てしない作業に思えてしまうことはなくなるでしょう。 実際的な目安としては、以下に挙げる最低限の基準は満たすようにすべきです。

  • 読者に対して、ソフトウェアを使用するために必要となる 技術的な前提知識を明確に示す。

  • そのソフトウェアのセットアップ手順を、 明確かつ完全に説明する。 そしてドキュメントの最初のほうで 簡単な動作テストの方法や基本的なコマンドを説明し、 セットアップが正常に完了したのかを確認できるようにする。 導入に関するドキュメントは、 ある意味実際の使用法のドキュメントよりも重要です。 ソフトウェアをインストールして起動するためにより多くの努力を注ぎ込んでいればいるほど、 そのユーザーはより粘り強く、 ドキュメントが不十分な高度な機能を理解しようとするのです。 ユーザーが諦めるとしたら、それは初期であることが多くなります。 つまり、最も初期の段階であるインストール時にこそ最大のサポートが必要となるわけです。

  • チュートリアル形式の例を用いて、一般的な作業の方法を示すこと、 もちろんさまざまな作業に対するたくさんの例があるにこしたことはありませんが、 時間が限られている場合は、どれかひとつに絞ってそれを完璧にするようにしましょう。 そのソフトウェアがなにかひとつの場面で 使えることがわかれば、 あとは自分自身で他の使い方を見つけてくれるようになります。 また、もしかしたら「残りのドキュメントを書いてあげようか?」 なんていう幸運なことになるかもしれません。 これについては次のポイントで取り上げます。

  • ドキュメントがまだ出来上がっていないところについては、 それを示しておくこと。 読者に対し、足りていない部分があることを認識していますよ、 ということを示すことにより、 あなたは読者の視線に合わせることになります。 読者に共感を示すことにより、読者に対し、 重要なことをプロジェクトに納得してもらうための苦闘に直面することはない、 ということを再保証することになるのです。 別に「いつまでにこのドキュメントを仕上げる」と表明する必要はありません。 ボランティアの助けを広く求めるものとして取り扱うのも同程度に正当なことです。

この最後に述べた点は、実のところ、より広範囲の重要性があり、 単にドキュメントだけに限らずプロジェクト全体にあてはまることです。 既知の足りていない部分を正確に会計することは、 オープンソースの世界においては当たり前のことだということです。 そのプロジェクトの欠点を必要以上に誇張する必要はありません。 単に、事情がそれを要求する場合 (ドキュメントやバグ追跡データベース、あるいはメーリングリストにおける議論など) に、それを厳正かつ私情を交えずに明らかにするだけのことです。 それを負け犬根性だという人はいないでしょうし、 明示的に示さない限りは「いつまでにこれを解決する」という公約だと受け取る人もいないでしょう。 ソフトウェアを使用していると、だれでもそのソフトウェアの欠陥を発見してしまうものです。 彼らが心の準備をできるようにしておいてあげましょう。 すると、そのプロジェクトは自分たちのことがよくわかっているとみなされるようになります。

ドキュメントの公開方法

ドキュメントは2通りの方法で公開しなければなりません。オンライン (ウェブサイト上で直接公開するもの)、そして ソフトウェアの配布物としてダウンロード可能なもの (章 7. パッケージの作成、リリース、日々の開発パッケージング項 を参照してください) の2通りです。 オンラインで公開しなければならない理由は、 人は普通そのソフトウェアをダウンロードする 前に ドキュメントを読むことが多いからです。 ダウンロードに値するかどうかを、ドキュメントの内容で判断するわけです。 しかし、それだけでなくソフトウェアにも同梱しておく必要があります。 これは、ダウンロードすることでそのパッケージを使用するために必要なものがすべて手に入る (すなわち、ローカルにアクセス可能になる) ようにすべきである、 という原則に従ったものです。

ドキュメントをオンラインで提供する際には、ドキュメント 全体を単一の HTML ページにまとめたものへのリンクを用意しておくようにしましょう (このページへのリンクには、"完全版" や "すべてをひとまとめにしたもの"、 あるいは "単一の大きなページ" といった説明をつけておきます。 これによって、そのページの読み込みに時間がかかることを示します)。 これは、ドキュメント全体から特定の単語やフレーズを検索したいといった用途において便利です。 一般に、そのような場合は何を探したいのかが既にわかっています。 単に、それが第何章にあるのかが思い出せないだけなのです。 そんな人たちにとっては、あるページには目次だけ、次のページには導入だけ、 その次のページにはインストール方法だけ、…… といったドキュメントほどストレスが溜まるものはありません。 こんな形式のページ構成だと、ブラウザの検索機能が無意味になってしまいます。 個別に分割した形式が便利なのは、必要な内容が第何章にあるのかが事前にわかっている場合です。 あるいは、ドキュメント全体を頭から最後まで順に読んでいきたい人にとっても便利でしょう。 しかし、ドキュメントにアクセスする人の多くは、このパターンには 当てはまりません。 よくあるパターンは、そのソフトウェアの基本的な内容をある程度理解している人が、 特定の単語やフレーズを検索するといった使い方です。 そんな人たちに対して単一の検索可能なドキュメントを提供しなければ、 彼らにとっては非常に生きにくい世界になってしまいます。

開発者向けドキュメント

開発者向けドキュメントを書く目的は、 プログラマーがコードを理解するのを助けること、 そしてコードの修正や拡張ができるようになるのを助けることです。 先ほど説明した 開発者向けガイドライン は技術的というよりも社会的な内容でしたが、 今回説明するドキュメントはこれとは少々異なります。 開発者向けガイドラインは、 プログラマー同士がお互いうまくやっていくための方法をまとめたものです。 一方、開発者向けドキュメントはコードそのものとうまくやっていくための方法を示すものとなります。 利便性のためにこれらの2つのドキュメントがひとつにまとめられていることもあります (先ほど例でしめした http://subversion.apache.org/docs/community-guide/ のように) が、そうしなければならないというわけではありません。

開発者ドキュメントがいかに有用なものであったとしても、 それが原因でリリースを遅らせるようなことがあってはなりません。 そのプログラムの作者自身がコードに関する質問に答えられる (そして答える気がある) のなら、当面はそれで十分です。 実際のところ、何度も何度も同じ質問に答える羽目になるっていうことが ドキュメント作成の動機となることもあります。 しかし、ドキュメントを書き始める前であっても、 プロジェクトに協力することを決心した人たちは 何とかコードと格闘しようとするものです。 何が人をそこまでさせるのかといえば、 そのコードがきっと何か自分の役に立つだろうと考えているからです。 人がそれを信じていれば、自分自身で何とかしようとするでしょう。 信じていなければ、大量の開発者向けドキュメントがあったとしてもあまり役立たないでしょう。

なので、もしどちらか一方に向けたドキュメントしか書く時間がないのであれば、 まずユーザー向けのドキュメントを作成しましょう。 ユーザー向けのドキュメントは、事実上 開発者向けのドキュメントでもあります。 そのソフトウェアの開発に参加しようとしているプログラマーは、 まずそのソフトウェアの使い方を身に着けなければならないからです。 後になって他のプログラマーが同じような質問を 何度も何度も繰り返すようになったときに、 あらためて時間をとってドキュメントを作成すればいいでしょう。

プロジェクトによっては wiki を用いてドキュメントを書き始めるところもあります。 それどころか、wiki をメインのドキュメントとしているところもあります。 私の経験上、これはあまりうまくいかないものです。 もしうまくいくとすれば、それはドキュメントの構成をしっかり把握し、 そこに何を書くべきかを熟知した数人の人間が頻繁に wiki を更新している場合のみでしょう。 詳細は、章 3. 技術的な問題Wiki項 をご覧ください。

使用例とスクリーンショット

そのプロジェクトがグラフィカルなユーザーインターフェイスを持っていたり、 グラフィカルあるいはそうでない特徴的な出力を行ったりする場合は、 そのサンプルをプロジェクトのウェブサイトに公開しておきましょう。 インターフェイスの場合は、スクリーンショットがこれにあたります。 出力の場合は、同じくスクリーンショットか、 あるいは実際の出力ファイルとなります。 これはどちらも、即座の満足感に対するユーザーの欲求を満たすものです。 長々とした説明やメーリングリストでのやりとりよりも、 ほんの一枚のスクリーンショットのほうが説得力を持つこともあります。 なぜなら、スクリーンショットはまさにそのソフトウェアが 動作した結果であることに疑いの余地がないからです。 バグだらけかもしれません。インストールが難しいかもしれません。 ドキュメントが足りないかもしれません。 でも、スクリーンショットさえあれば、 何とかがんばれば動かすことができるんだということの証明になります。

プロジェクトのウェブサイトに置くことのできる情報は、これら以外にもたくさんあります。 最新情報のページやプロジェクトの歴史のページ、関連サイトへのリンク、 サイト内検索の機能、寄付の受付などです。 もし時間が許したり何か特別な理由があるのなら、これらを作成してもよいでしょうが、 プロジェクトの立ち上げ時には通常はどれも不要です。 しかし、将来のために心に留めておきましょう。

公開場所

オープンソースプロジェクトのために、 ウェブサイト用の領域やバージョン管理機能、バグ追跡システム、ダウンロードエリア、 掲示板、バックアップなどの機能を無料で提供するサイトがいくつかあります。 詳細はサイトによって異なりますが、基本的な機能はどこでも同じようなものです。 これらのサイトのいずれかを使用すると、無料で多くのものを手に入れることができます。 ただ、ユーザーへの見せ方をきめ細かく調整するといったことはあきらめなければなりません。 そのサイトでどんなソフトウェアを用いるのかを決めるのはホスティング業者であり、 プロジェクトのウェブページの見た目はその業者に多少なりとも左右されることになります。

あらかじめ用意されているホスティングサイトを使うことの利点と欠点、 ホスティングサイトの一覧などについての詳細は、 章 3. 技術的な問題ツールが一通り揃ったホスティングサイト項 をご覧ください。



[12] hack と activation を組み合わせた造語? おそらく http://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Programming-Overview.html からの引用だと思われます。