さあ始めましょう
フリーソフトウェアプロジェクトがどのようにして始まるのかについては、
Eric Raymond が説明しています。彼は、今や超有名になった文書
「伽藍とバザール (The Cathedral and the Bazaar)」
の中で次のように述べています。
よいソフトはすべて、開発者の個人的な悩み解決から始まる。
(
より引用。日本語訳は )
Raymond は、決して「開発者の個人的な悩み解決」
だけがオープンソースプロジェクトの始まるきっかけだとは言っていないことに注意しましょう。
というよりは、プログラマー自身が問題の解決に関心を持っているときに
よいソフトウェアが出来上がることが多いと言っているのです。
フリーソフトウェアを作り始める動機としていちばん多いのが
「個人的な悩み解決」だったということでしょう。
現在でも同じ理由で始まるフリーソフトウェアプロジェクトは多いでしょうが、Raymond
がこの文章を書いた 1997 年当時に比べるとその割合は少なくなっています。
現在では、巨大な中央管理型のオープンソースプロジェクト
(営利団体が管理するものも含む) を最初から作ろうとする空気があります。
一匹狼のプログラマーが個人的な問題を解決するためにガシガシ書いたコードが
結果として広く受け入れられるということは今でもあるでしょうが、
いまやそれだけではなくなったということです。
しかし、Raymond の指摘は今でも洞察に満ちています。
ソフトウェアの作者自身がその成功に直接的な興味を持っている、
なぜなら彼らは自分自身でそれを使うことになるから、というのが本質的な条件です。
もしそのソフトウェアが期待通りに動かなければ、
日々それを使用している作者は不満に思うことになるでしょう。
たとえば OpenAdapter プロジェクト ()
を考えてみましょう。これは投資銀行 Dresdner Kleinwort Wasserstein
が始めたオープンソースのフレームワークで、
さまざまな金融情報システムを統合するためのものです。
どう考えても、これは「開発者の個人的な悩み解決」
のために作られたものとはいえないでしょう。
これは「機関の悩み解決」をするためのものです。
しかし、この悩みはその機関とパートナーの経験から直接くるものです。
したがって、もしこのプロジェクトがうまくいっていなければ、それと気づくことができるでしょう。
このようなプロジェクトは、よりよいソフトウェアを産み出すでしょう。
なぜなら、フィードバックループが正しい方向に流れるからです。
そのプログラムは、見知らぬ誰かに売りつけて、彼らの問題を解決できるよう書かれるのではありません。
最初は自分たち自身の問題を解決するために書かれます。
そしてそれがみんなと共有されるようになります。
「問題」を病気にたとえると、ソフトウェアは薬のようなものです。
流行病を完全に根絶するために薬をばらまくのと同じように、ソフトウェアを配布するようになります。
本章では、新しいフリーソフトウェアプロジェクトをスタートさせる方法を扱います。
しかし、本章にかかれている内容の多くは、
保健機関が薬を配布するときの方法と似ていることでしょう。
両者の目標はよく似ています。薬の効能ははっきり示さないといけないでしょうし、
それを本当に必要とする人に手渡さないといけないでしょうし、
またそれを受け取った人は薬の扱い方を知っていなければなりません。
しかしソフトウェアの場合はさらに、
薬を改良するための研究に参加してもらうように患者を勧誘するという作業もあります。
フリーソフトウェアの配布作業は、２つの側面を有しています。
ソフトウェアのユーザーを獲得すると同時に、開発者も獲得しなければならないからです。
これら２つは必ずしも競合するものではありません。
しかし、プロジェクトを初めにどのように見せるかを考えると、これは少々複雑な話になります。
ユーザーと開発者の両方に対して有用な情報もあれば、
そのどちらか一方にしか役立たない情報もあります。
どちらの情報もスケールするプレゼンテーション (scaled presentation) の原則にしたがっていなければなりません。すなわち、
読み手が時間をかけて熱心に読めば読むほど、
それにあわせた詳細な情報が得られるようになっていなければなりません。
努力すればするほど、それに対する見返りが得られるべきです。
両者がきちんと相関していなければ、
人はすぐ信頼する心を失い、努力を注ぎ込むのをやめてしまうでしょう。
この系として言えるのが、見栄えは重要である ということです。
とりわけプログラマーという人種は、これを信じようとしません。
形式を差し置いた本質に対する彼らのこだわりは、ほとんど職人的プライドの域に達しています。
多くのプログラマーはマーケティングや広報活動を毛嫌いしているようだし、
プロのグラフィックデザイナも「プログラマーって人たちはいったい何を考えているのか」
と恐れているようですが、これは全く不思議なことではありません。
これは残念な話です。状況によっては形式こそが本質であり、
プロジェクトの見栄えの問題はその状況の１つだからです。
たとえば、あるプロジェクトの存在を知った人が最初に目にするのは、
そのプロジェクトのウェブサイトの見た目です。
実際に何が書かれているかとかどこにリンクされているとかよりも前に、
まずそのウェブサイトがどんな感じかということが目に入るわけです。
おかしな話だと思われるかもしれませんが、
人は第一印象の形成を抑制することができないものなのです。
サイトの見た目は、そのプロジェクトの見栄えの構成に配慮が払われたか否かという情報を発信します。
そして人間は、配慮の投資を検知するためのおそろしく感度のよいアンテナを備えているのです。
たいていの人は、そのサイトが片手間に作られたものか
よく練りこまれているものかを一目見て判断することができます。
そのプロジェクトを世に出すにあたって最初に見てもらうところがウェブサイトなのですから、
その印象は連想によってプロジェクト全体に持ち越されるのです。
したがって、一方で本章では主にプロジェクトを開始するにあたり用意しておくべき内容について取り扱っているのですが、
その見栄えも重要であるということは忘れないでください。
プロジェクトのウェブサイトは (エンドユーザーと開発者の) ２種類の人たちが利用するものなので、
どちらを対象としたものなのかをはっきりさせる必要があります。
本書はウェブデザインの専門書ではありませんが、
ひとつだけ重要な法則を示しておきます。
このようにさまざまな相手 (部分的に重複することもあるでしょう)
を対象とするときは特に重要なことです。
それは、リンク先に何があるのかが、リンクをクリックしなくても大まかにわかるようにしておく、ということです。
たとえば、ユーザー向けのドキュメントなのか開発者向けのドキュメントなのかが、
リンク先ではなくリンクそのものを見ただけで
判断できるようにしておくべきです。
プロジェクト運営には、情報を提供するという側面が一部にはあります。
しかしまた、安心感を提供するという側面もあるのです。
期待した場所に決まりきったものが提供されているというだけで、
そのプロジェクトに関わるか否か決めようとしているユーザーや開発者は安心します。
「このプロジェクトはやるべきことを行い、想定される質問に対応し、
その質問に対する答えをできるだけ簡単に得られるようにしている」という努力が見えるからです。
このような気合を見せることで「このプロジェクトに関わってもあなたの時間は無駄にならない」
というメッセージを送ることができます。それこそが皆が聞きたいメッセージです。
まずは周りを見渡すことから
オープンソースプロジェクトを始める前に、ひとつ忠告しておきます。
まずは周りを見渡して、同じようなプロジェクトが既に存在しないかどうかを確認しましょう。
あなたが今まさに解決しようと思っている問題を、
あなたよりも前に別の誰かが解決しようと思っていた可能性は大いにあります。
そして彼らが実際にその問題を解決し、コードをフリーなライセンスで公開しているのなら、
あなたがこれから車輪の再発明をする理由はありません。
もちろん、例外もあります。自分の勉強のためにプロジェクトを開始するのなら、
既存のコードは助けにならないでしょう。あるいは
これからはじめようとしているプロジェクトがあまりにも特定の分野に特化したものであり、
他の人が同じことをしている可能性がゼロに等しい場合などもあるでしょう。
しかし通常は、あえて周りを見渡さない理由はありません。
見渡すことで得られる利益はかなりのものになるでしょう。
一般的なサーチエンジンで結果が得られなければ、
(オープンソースプロジェクトに関するニュースサイト。
詳細は後ほど説明します)
や 、
そして Free Software Foundation のフリーソフトウェアディレクトリ
() を調べてみましょう。
そのものずばりのものが見つからなかったとしても、
よく似たものが見つかるかもしれません。
そんな場合は、そのプロジェクトに合流して必要な機能を追加するほうが、
１から作り直すよりもいいでしょう。
手持ちのもので始めよう
まわりを見渡してみたけれど望みどおりのものが見つかりませんでした。
ということで、結局新しいプロジェクトを始めることになりました。
さて何をしたらいいのでしょう？
フリーソフトウェアプロジェクトの立ち上げ時に最も厄介なのは、
個人的なビジョンをみんなにわかる形に置き換えることです。
あなた (あるいはあなたの属する組織) にとっては何がやりたいのかは明白でしょう。
しかし、そのプロジェクトの目標が何なのかを一般にもわかるように表明することは、
それなりに大変な作業です。しかし、
かならず時間を割いてそれをやらなければなりません。
あなた (そして共同でプロジェクトを立ち上げた他のメンバー)
は、まず「プロジェクトが実際何なのか」、すなわち、
「何をやるのか」と同時に
「何をやらないのか」という限界を決定し、
ミッションステートメントを書き上げなければなりません。
普通は、これはそれほど困難なことではありません。
しかし、この作業によって、プロジェクトの本質に関する暗黙の了解やさらには意見の相違まで浮かび上がってくるかもしれません。
それでいいんです。後になってからそれが判明するよりも、
早いうちに見つけてしまったほうが解決しやすくなります。
この作業が終われば、次にすることは
一般公開用のパッケージを作成することです。
これは、ぶっちゃけて言うと単純でつまらない純然たる骨折り仕事です。
何がそんなに面倒くさいのかというと、その作業の大半が、既にみんなが知っている
—ここでいう「みんな」とは、これまでずっとプロジェクトにかかわってきた人のことです—
ことをまとめ上げて文書化するということだからです。
つまり、その作業を実際に行う人には直接的なメリットは何もないのです。
彼らにとっては「このプロジェクトは……」というような README
ファイルは不要ですし、もちろん設計文書やユーザーマニュアルなんかも不要です。
ソフトウェアをソースで配布するときにみんなが標準的に使っているような
コードツリーを構成する必要も感じていないでしょう。
別にディレクトリ構成がどうであっても彼らは気にしません。
だってもうそのコードの内容を熟知しているのだし、
コードが動き出せば、あとはどう使えばいいのかも知っているわけですから。
彼らにとっては、そのプロジェクトの基本的な設計方針が文書化されていなくても平気です。
だってそれは彼らの頭の中にちゃんとあるのですから。
一方、新参者にとってはそのようなドキュメントは必須です。
とはいえ、幸いなことにすべてのドキュメントが一度に必要となるわけではありません。
プロジェクトを公開する前に、あらゆるリソースを提供できるようにしておく必要はありません。
理想を言えば、新しいオープンソースプロジェクトを始めるときには
設計文書や完全なユーザーマニュアル (今後実装予定の機能についての説明も含む)、
複数プラットフォームで動作するきれいにパッケージされたコードなどがそろっているといいのでしょう。
しかし現実的には、これらをばっちりそろえることは手間がかかりすぎます。
それになにより、ひとたびプロジェクトが動き出せば、
これらの作業に対するボランティアの協力を正当に期待できるのです。
しかし、何が本当に必要なのかといえば、
見栄えの調整に十分に力をいれ、
新入りさんが不慣れという名の最初の障壁を乗り越えられるようにすることです。
この作業をブートストラップ過程の第一段階、
プロジェクトをいわば活性化エネルギー最小の状態に持っていくことだと考えてください。
新入りさんが「このプロジェクトに対して何らかのかかわりと持とう」
と考えるために必要なエネルギーの閾値のことを、どこかの誰かが
ハクティベーション (hacktivation)
hack と activation を組み合わせた造語？
おそらく
からの引用だと思われます。
エネルギー
と呼んでいました。ハクティベーションエネルギーが低ければ低いほどいい、
というわけです。あなたが最初に行う作業は、
プロジェクトのハクティベーションエネルギーを下げて
いろいろな人たちがプロジェクトに参加しやすくすることとなります。
以下の各項では、新しいプロジェクトをはじめるにあたって重要となる内容について個別に説明します。
そのプロジェクトをはじめて知った人が遭遇するであろう順に並べていますが、
もちろんこのとおりの順で作成しなければならないというわけではありません。
これらの項目を、チェックリストとして用いるといいでしょう。
プロジェクトをはじめる際にはこれらの各項目が網羅されていることを確認するか、
あるいはもし省略した項目がある場合は、
せめて予想される結果が満足のいくものであることを確認しましょう。
名前の決定
どこかの誰かがあなたのプロジェクトのことを聞きつけたとしましょう。
おそらく、何かの問題を解決するためのソフトウェアを検索しているときに見つけたのでしょう。
彼らが真っ先に目にするのは、そのプロジェクトの名前です。
すばらしい名前をつけたからといって、
そのプロジェクトの成功が約束されるわけではありません。
また、変な名前をつけたからといって
それだけの理由でプロジェクトが失敗するというわけでもありません
—もちろん、あまりにも
マズい名前をつけてしまったら悪影響があるかもしれません。
しかし、わざわざプロジェクトを失敗に持っていくようなことはしないだろう
という前提の下で話を進めます。
ただ、変な名前をつけてしまうと、
真剣に受け止めてもらえなかったり覚えてもらいにくかったりして、
そのプロジェクトの利用が低下してしまうかもしれません。
よい名前とは、次のような条件を満たすものです。
そのプロジェクトのやることが多少なりとも分かること、
あるいは少なくとも明らかな形でそれと関連があること。
そうすることで、名前とやることを知ってもらったあと、
その名前をすぐ思い出してもらえるようにするのです。
覚えやすいこと。
ここで、インターネットのデフォルト言語が英語となっている
という事実を無視することはできません。つまり「覚えやすい」
とは「英語が読める人にとって覚えやすい」ということです。
英語のネイティブスピーカーの発音に基づくだじゃれを用いた名前などは、
英語を母国語としない多くの人たちにとってはわかりにくいものとなるでしょう。
ただ、それが人の心をひきつけるほど印象的なものならば
だじゃれを使用する価値もあるでしょう。
英語を母国語としない人たちからみると、
だじゃれを用いたプロジェクト名を見てもその読み方を想像しにくくなる
ということを覚えておきましょう。
既存の別のプロジェクト名と重複しない、
そして商標権を侵害しないものであること。
これは、礼儀の問題であると同時に法的にもよい考えです。
別のプロジェクトと混同されてしまうようなことは望ましくないでしょう。
別々のものが同じ名前を持っていなかったとしても、
ネットで手に入るものすべてを追跡するのは既に十分困難なことなのです。
あなたが考えているのと同じ名前のプロジェクトが既に存在するかどうかを調べるには、
で示したリソースを使用するといいでしょう。
登録商標に関する検索は
や で行えます。
できれば、.com や
.net、.org
のようなトップレベルドメインが利用できる名前を選びましょう。
この中のいずれか１つ (おそらく .org
でしょう) を選び、プロジェクトの公式サイトとして宣伝します。
他の２つのトップレベルドメインについては単純に
プロジェクトのサイトに転送させるだけにしておきます。
これにより、第三者にそのドメインを悪用される心配をなくします。
仮にそのプロジェクトのサイトを別の場所
( を参照してください)
におくとしても、プロジェクト名のドメインは取得しておくべきです。
そして、それらのサイトからプロジェクトの本来のページに転送させるようにしましょう。
そうすることで、覚えやすいシンプルな URL を提供することができます。
明確な目標を掲げる
プロジェクトのウェブサイトを訪れた人たちが次に見るものは、
そのプロジェクトについての簡単な説明や目標などのメッセージです。
それらを見て (たいていは 30 秒程度で)、人は
そこから先に進むか引き返すかを決断します。
このメッセージは、トップページの目立つ場所に配置しなければなりません。
プロジェクト名のすぐ下に置くといいでしょう。
この声明は、具体的で内容を絞り込み、そしてなによりも簡潔でなければなりません。
たとえば、以下に引用した
の記述などがよい例です。
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)" と明記することにより、
どこか１つの企業が開発を支配するものではないことを表しています。また
"国際的な (international)" という言葉によって、
このソフトウェアが複数の言語や地域で動作することを示しています。
そして "すべての主要なプラットフォーム (all major platforms)"
とあることから、おそらく Unix、Macintosh そして Windows で動作するであろうことが読み取れます。
その他の箇所からは、インターフェイスが公開されていることや
ファイルのフォーマットが一般的なものであることなどがわかるでしょう。
彼らが Microsoft Office の代わりとなるフリーソフトウェアを作ろうとしているとはどこにも書かれていません。
しかし、たいていの人は行間からその気持ちを読み取ることができるでしょう。
この声明は一見したところ大雑把なようですが、
実際にはきわめて絞り込まれたものです。
また "オフィススイート (office suite)"
という言葉を使用することで、その手のソフトウェアになじみがある人たちにとって
かなり具体的な印象を与えることができます。
ここでも声明を簡潔なものとするため、
訪問者が持っているであろうと思われる前提知識 (この場合は MS Office に関するもの)
を利用しているのです。
この声明の本質は、それが対象としているソフトウェアだけではなく
「だれがそれを書いたか」にも依存します。
たとえば、OpenOffice.org があえて "コミュニティーとして
(as a community)" と書いているのがいい例です。
このプロジェクトはもともと Sun Microsystems が始めたものであり、
現在も同社が主なスポンサーとなっているからです。
あえてこの文言を含めることで Sun は「開発プロセスを
支配するようなつもりはない」ということを示しているわけです。
このように「問題が起こる可能性を認識している」
ということを示すだけでも、問題の発生を回避するのに大いに効果があるのです。
一方、特定の企業の支援を受けているわけではないプロジェクトについては
このような文言は不要でしょう。結局のところ、
普通はコミュニティーベースの開発になるわけですから、
それをわざわざ示す必要はないわけです。
フリーであることを宣言する
プロジェクトの目標についての説明 (ミッションステートメント)
を読んで興味が残っているひとたちは、もっと詳細な情報を知りたくなることでしょう。
たとえばユーザー向けドキュメントや開発者向けドキュメントなど。
そして、何かをダウンロードしたくなるでしょうね。
でもその前に、まずはそれがオープンソースなのかどうかを知る必要があります。
プロジェクトのトップページで、
それがオープンソースであることを明記しておかなければなりません。
当然のことだとお考えかもしれません。しかし、
世の中にはそれができていないオープンソースプロジェクトが山ほどあります。
私がかつて見たとあるフリーソフトウェアプロジェクトのウェブサイトのトップページでは、
そのソフトウェアの配布時にどのライセンスを適用するかが示されておらず、
さらにそのソフトウェアがフリーなのかどうかさえ書かれていませんでした。
また、このような重要な情報が
ダウンロードページや開発者向けページなどにしか存在しないというページもよくあります。
このような場合は、重要な情報を得るためにさらにマウスクリックが必要となってしまいます。
最もひどかった例では、ウェブサイト上のどこにもライセンスが示されていなかったものもありました。
ソフトウェアをダウンロードしてその中身を見ない限り、ライセンスの内容がわからなかったのです。
同じようなミスはしないでください。
そんなことをすると、せっかくの開発者候補やユーザー候補の多くを失うことになります。
トップページのミッションステートメント部の次に、そのプロジェクトが
「フリーソフトウェア」あるいは「オープンソース」であることを示し、
さらに具体的なライセンスについても記しておきましょう。
どのライセンスを適用すればいいかについては
で説明します。
また、ライセンスに関するさまざまな問題については
で詳しく説明します。
ここまでの情報を見るのに、訪問者が要する時間は１分かそれ以下でしょう。
これらの内容をもとに、彼/彼女 らがさらに次を読み進めるかどうかを決断するわけです。
次のセクションでは、最初の５分間で訪問者が見るであろう内容について扱います。
機能一覧・要件一覧
そのソフトウェアのちょっとした機能一覧
(まだ完成していない機能を一覧に含めてもかまいません。しかしその場合は
"予定" とか "開発中"
などとはっきり示して置くようにしましょう)、
そしてそれを動かすために必要な要件についての説明が必要です。
機能一覧/要件一覧は、そのプロジェクトについて誰かに聞かれたときに
答えるためにまとめたものと考えるといいでしょう。
これは、単にミッションステートメントの内容をより深く掘り下げたものと考えてもかまいません。
たとえば、ミッションステートメントで次のように説明したとすると、
豊富な API を備えた全文インデクサー・サーチエンジンを作成します。
大量のテキストファイルに対する検索サービスを準備するプログラマーの利用を想定しています。
機能一覧、要件一覧でその詳細を説明することによって
ミッションステートメントの範囲を明確にします。
機能
プレーンテキスト、HTML および XML
の検索
単語あるいはフレーズによる検索
(予定) あいまい検索
(予定) インデックスの差分更新
(予定) リモートのウェブサイトのインデックス化
要件
Python 2.2 以降
インデックス作成用のディスク領域
(元のデータの約２倍の大きさ)
これらの情報によって、訪問者はそのソフトウェアが自分の希望を満たすものかどうかを判断します。
また場合によっては開発者としてプロジェクトに参加することを検討してくれるかもしれません。
開発の進捗状況
そのプロジェクトがいったい何をやっているのか、訪問者たちはきっと気になることでしょう。
特に新しいプロジェクトの場合は、
そのプロジェクトが掲げている目標のうち
現在どれくらいが達成されているのかが気になるところです。
十分に成熟したプロジェクトの場合に気になるのは、
「そのプロジェクトが現在活発に保守されているのか」
「どれくらいの頻度で新しいバージョンがリリースされているのか」
「バグレポートに対する反応の速さはどれくらいか」
などとなります。
これらの質問に答えるために、開発状況を示すページを作らなければなりません。
ここには、直近の目標とそれを達成するために必要なもの
(たとえば「ある特定の分野に強い開発者を募集しています」など)
を表示します。また、過去のリリース履歴や機能一覧などもここに掲載するといいでしょう。
そうすることで、そのプロジェクトが「進捗」というものをどのように定義し、
その定義にしたがってどのくらい速く前進しているのか、
ということが訪問者にわかるようにしておきます。
まだできあがっていないことを恐れる必要はありません。
できあがってもいないことを変にごまかすこともやめましょう。
ソフトウェアの開発にはいくつかの段階があることを、みんな知っています。
"このソフトウェアはアルファ版です。既知のバグが存在します。
とりあえずは動作するでしょう。しかし、自己責任のもとで使用するようにしてください"
と言ったところで、何も恥ずかしいことはありません。
そのような段階でプロジェクトが必要としている開発者は、
「アルファ版」という説明なんかではおびえたりしません。対エンドユーザーという面では、
まだできあがってもいないソフトウェアにユーザーが群がってしまうほどまずいことはありません。
いったん「不安定」だとか「バグだらけだ」だとかいう評判が出てしまうと、
それを払拭するのは大変な話になります。
結局のところ、多少保守的なほうがうまくいきます。
そのソフトウェアが「ユーザーが期待しているよりも安定していた」
ほうが、期待はずれだった場合よりもずっといいでしょう。
そしてそのほうが、口コミによる広がりが期待できます。
アルファ版/ベータ版
アルファ版 とは、通常は一番最初のリリースのことを指します。
とりあえずは動かすことができ、ひととおりの機能はそろっていますが、
まだバグが残っている状態です。アルファ版の主な目的は、
利用者からのフィードバックを得ることです。それによって開発者は、
何に取り組むべきかを知ることができます。
その次の段階となるのがベータ版です。
これは、致命的なバグはすべて修正済みとなっていますが、
まだリリースに向けての十分なテストが行われていない状態です。
ベータ版の目的には２種類あります。
１つには、バグが見つからない場合にそれをそのまま公式リリースとすることです。
もう１つには、公式リリースを早く行うため、
開発者が詳細なフィードバックを受け取れるようにすることです。
アルファ版とベータ版の差をどこにおくかは、あなたしだいです。
ダウンロード
標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要があります。
プロジェクトを立ち上げた最初のうちは、バイナリ (実行可能) パッケージはなくてもかまわないでしょう。
ただし、ビルド手順が面倒だったり依存性が複雑だったりして、
ただ動かせるようにするだけでも多くの人にとって骨が折れるような場合は、
バイナリ版も必要です (でも、
そんなプロジェクトは開発者にとってはあまり魅力的ではありません)。
配布形態は、できるだけ便利で標準的かつ余計な負担の少ないものを選びましょう。
あなたがある病気の撲滅を狙っているなら、
薬を配る際に独自の注射器が必要となるような面倒な手段はとらないでしょう。
同様に、ソフトウェアについても標準的な手順で
ビルド・インストールできるようにしておきましょう。
標準から外れれば外れるほど、
ユーザー候補や開発者候補は狼狽してそのプロジェクトから離れてしまいます。
当然のことだと思われるかもしれません。
しかし、多くのプロジェクトは本当に切羽詰るまで
インストール手順を標準化しようとはしないものです。
"ま、リリースに近づいたら
そのときにやろうよ。そんなことはいつでもできるんだから。"
といった言い訳をしてしまいがちです。
彼らはわかっていないのですが、そういった作業を後回しにしてしまうと、
結果的にリリースに近づくまで余計に時間がかかってしまうのです。
なぜならば、さもなくばコードを貢献してくれたかもしれない開発者たちの意欲を削いでしまうからです。
もっとも悪いことに、彼らはそのような開発者を失いつつあることに気づきません。
なぜならば、この過程は
「誰かがウェブサイトを訪れた→ソフトウェアをダウンロードした
→ビルドしようとした→失敗した→あきらめた」
という、イベントが発生しなかったことの積み重ねだからです。
あきらめた本人以外には、そんなことがあったということはわかりません。
もともとあなたのプロジェクトに興味を持っていてくれたはずの人が黙って立ち去ってしまった、
そしてそれをプロジェクトのメンバーは誰も気づかないのです。
面倒だが見返りの大きい作業は、できるだけ早めに済ませてしまいましょう。
パッケージをきちんと作成すると、
プロジェクトへの参加障壁を劇的におろすことができ、
結果として大きな見返りを得ることになります。
ダウンロード用のパッケージをリリースするときは、それに対して
一意なバージョン番号を与えることが大切です。
それによって人は、２つのリリースのうちどちらが新しいのかを知ることになるのです。
バージョン番号のつけかたについては
の
で、
そしてビルド手順やインストール手順の標準化については同じ章の
でそれぞれ詳しく説明します。
バージョン管理システムやバグ追跡システムへのアクセス
単にそのソフトをインストールして使いたいだけという人にとっては、
ソースパッケージで十分でしょう。しかし、デバッグをしたり
機能追加をしたりしたい人たちにとってはそれだけでは不十分です。
毎晩最新ソースのスナップショットを作成するという手もありますが、
開発が活発に行われているコミュニティーではまだこれでも完璧だとはいえません。
常にその時点の最新のソースにアクセスしたいという人たちにその手段を提供するのが、
バージョン管理システムです。
バージョン管理システム上のソースに匿名でアクセスできるようにしておくと、
「このプロジェクトは、新しいメンバーの参加を歓迎しています」
というメッセージをユーザーと開発者の両方に送ることになります。
もし今すぐにバージョン管理システムを用意できない場合は、
近々公開予定であるというメッセージを書いておくようにしましょう。
バージョン管理システムについては
の で詳しく説明します。
バグ追跡システムについても同じです。
バグ追跡システムの意義は、開発者に対する有用性だけでなく、
それがプロジェクトの観察者に対して発している暗黙のメッセージにも存在します。
多くの人は、バグデータベースが公開されていると
「熱心に開発が進められているようだ」と感じます。
さらに、バグデータベースにたくさんのバグが登録されていればいるほど、
そのプロジェクトの見栄えはよくなります。
ちょっと直感に反しているように思われるかもしれません。でも考えてもみてください。
バグデータベースに登録されたバグの数が実際何に依存しているかというと、
それは次の３つです。まず、そのソフトウェアに存在するバグの絶対数。
次に、そのソフトウェアを使用しているユーザー数。
そして最後に、ユーザーが新規のバグを登録できるための利便性です。
このうち最初の１つよりも後ろの２つの方が重要な要素になります。
ある程度の規模と複雑さを持つソフトウェアには、
基本的にバグが含まれているものです。本当の問題は、
それらのバグをいかにして見つけ、どのように優先順位を設定するかというところにあります。
したがって、よく整備された (バグに対する対応がすばやく、
重複したバグ報告はきちんと統一されているなど) 大規模なバグデータベースがあると、
バグデータベースがなかったりほとんど機能していなかったりするプロジェクトより
ずっと印象がよくなります。
もちろん、そのプロジェクトが本当に始まったばかりなのなら
バグデータベースに登録される内容はほんのちょっとだけになるでしょう。
それについてはどうにもしようがありません。
しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、
かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、
プロジェクトのバグ登録が健全な比率を保っている、
ということを読み取ることができます。
彼らはバグ登録の絶対数が小さいことを不当に警戒することはないでしょう。
バグ追跡システムに登録されるのはソフトウェアのバグだけではありません。
機能追加の要望やドキュメントの変更、
とりあえず保留になっている作業などが登録されることも多々あります。
バグ追跡システムの運用方法については
の で詳しく説明するので、
ここでは深く立ち入りません。プロジェクトの見栄えという観点から見て大切なのは、
まずバグ追跡システムが 存在する ということ。
そしてそれがプロジェクトのトップページからたどれる場所にあるということです。
連絡手段
プロジェクトの関係者の連絡先を知りたいという人もあらわれることでしょう。
関係者と連絡を取れるように、メーリングリストのアドレスや
チャットルーム、IRC チャンネル、掲示板などの場所を示しておきましょう。
あなた、あるいはその他のプロジェクト関係者がこのメーリングリストに参加していることも明記しておきましょう。
そうすることで、「そこに行けば開発者と話すことができる」ということが伝わります。
あなたがメーリングリストに参加しているからといって、
すべての質問に答えなければならないとか
すべての要望に答えなければならないとかいった義務が発生するわけではありません。
長い目で見れば、ユーザーのほとんどはこのようなメーリングリストや掲示板には参加しません。
とはいえ、必要ならいつでも参加できるということを示すだけで、
安心感を与えることができます。
プロジェクトを立ち上げたばかりのころは、
エンドユーザー向けと開発者向けにフォーラムを分ける必要はありません。
それよりも、プロジェクトにかかわる人たちが１つの「部屋」
に集まってわいわいがやがや話をするほうがずっといいでしょう。
アーリーアダプター層においては、開発者とユーザーの区別はあいまいです。
あえて分類するとしても、プロジェクトの初期には開発者の比率がかなり高くなります。
アーリーアダプターのすべてがそのソフトウェアをハックしたいと思っているとは限りません。
しかし、少なくともそのプロジェクトの今後の方向性に関する議論には
興味を持っていることでしょう。
本章では「プロジェクトをどのように立ち上げるか」についてのみを扱っています。
この段階では「とりあえずコミュニケーション用の場所が必要だ」というくらいで十分でしょう。
後で、
の においてさらに詳しく説明します。
ここでは、掲示板の設置や管理の方法について扱います。
また、いつかユーザー向け会議室と開発者向け会議室を分割することになったときに、
両者の間に溝を生じさせないための方法も説明します。
開発者向けのガイドライン
開発者としてプロジェクトに参加しようと考えた人は、
まず開発者向けのガイドラインを探すことになるでしょう。
このガイドラインは、技術的なものというよりもむしろ社会的なものとなります。
たとえば開発者同士のやりとりの方法、ユーザーとのやりとりの方法、
プロジェクトをうまく進めるためにどのようにしていくかなどです。
このトピックについては
の で詳しく説明します。
ここでは、そこに含める基本的な内容だけをまとめておきます。
他の開発者とのやり取りのためのフォーラムの場所
バグ報告やパッチの投稿の方法
開発の基本方針—
「慈悲深い独裁者」式でいくのか「民主主義」式でいくのか、
あるいはそれ以外の手法をとるのか
ところで、「独裁者」という言い方には、特にそれを批判する意図はありません。
特定の開発者だけがすべての変更に対する拒否権を行使できる
というような専制政治を行ってもまったく問題はありません。
実際、多くのプロジェクトはこの方式で成功しています。
大事なのは、そのプロジェクトがそういう方針で運営されているとはっきり示しておくことです。
実際には独裁型なのに無理に民主主義っぽく見せようとすると、
人は離れていってしまいます。きちんと独裁型であることを宣言しておけば、
少なくともその独裁者が有能で信頼できる人である限りはうまく進みます。
開発者向けガイドラインの実例は
をご覧ください。また、
には、より一般的なガイドラインがあります。こちらは、
技術的な話題よりもプロジェクトの管理体制やプロジェクトへの参加方法に重点を置いています。
プログラマー向けにソフトウェアについての説明を行うことについては、
本章の後半の
で取り上げます。
ドキュメント
ドキュメントは必要不可欠です。
何か読んでもらうものが必要です。
たとえそれがごく簡単な未完成のものであってもかまいません。
この作業はまさに、先ほど言及した「骨折り仕事」の範疇に属するものです。
新しいオープンソースプロジェクトがしばしば最初につまづくのがこの分野です。
ミッションステートメントや機能一覧を作成するとか、
ライセンスを選択するとか、開発状況をまとめるとかいったことはどれも比較的小規模な作業です。
しかも「ここまでできたら完了」という点がはっきりしており、
通常は一度作成すればそれ以降は手を加える必要のないものです。
ドキュメント作成はこれらとは異なり、
決して終わることのない作業です。
みんながドキュメント作成を嫌がるひとつの理由がここにあります。
ドキュメント作成において最も注意すべき点は、
ドキュメントの書き手にとって有用な内容と読み手にとって有用な内容とは
まったく正反対であるということです。
はじめて使用するユーザーにとって必要なドキュメントは、
基本をまとめたものです。ソフトウェアを手っ取り早くセットアップする方法や
動作の概要、そして一般的な作業をするための手引きなどが必要でしょう。
しかし、これらの内容はまさに、ドキュメントの書き手
があまりにもよく知りすぎていることです。
そのためかえって、物事を読者の視点から眺めたり、また、
(ドキュメントの書き手にとっては) 言及に値しないほど明白な手順を、
骨を折って詳細に説明するのが困難になる可能性があります。
この問題を解決するためのマル秘手段は存在しません。
誰かが腰を落ち着けてそれを書かなければならないのです。
そして、初心者にそれを見せて内容をチェックしてもらわなければなりません。
ドキュメントの書式は、
たとえば HTML やプレーンテキスト、Texinfo あるいは各種 XML といったような、
シンプルで編集しやすいものにしましょう。
すなわち、ふと思ったときお手軽かつ迅速に更新するのに適した書式です。
これらを使用すると、ドキュメントの作成者があとからそれを更新する際の手間も少なくなります。
また、後からプロジェクトに合流した人にとっても、作業に参加しやすくなるでしょう。
基本ドキュメントをきちんと整備できるようにするためのひとつの方法としては、
ドキュメントで網羅する範囲を事前に限定してしまうというものがあります。
このようにしてしまうと、少なくともドキュメントの作成が
果てしない作業に思えてしまうことはなくなるでしょう。
実際的な目安としては、以下に挙げる最低限の基準は満たすようにすべきです。
読者に対して、ソフトウェアを使用するために必要となる
技術的な前提知識を明確に示す。
そのソフトウェアのセットアップ手順を、
明確かつ完全に説明する。
そしてドキュメントの最初のほうで
簡単な動作テストの方法や基本的なコマンドを説明し、
セットアップが正常に完了したのかを確認できるようにする。
導入に関するドキュメントは、
ある意味実際の使用法のドキュメントよりも重要です。
ソフトウェアをインストールして起動するためにより多くの努力を注ぎ込んでいればいるほど、
そのユーザーはより粘り強く、
ドキュメントが不十分な高度な機能を理解しようとするのです。
ユーザーが諦めるとしたら、それは初期であることが多くなります。
つまり、最も初期の段階であるインストール時にこそ最大のサポートが必要となるわけです。
チュートリアル形式の例を用いて、一般的な作業の方法を示すこと、
もちろんさまざまな作業に対するたくさんの例があるにこしたことはありませんが、
時間が限られている場合は、どれかひとつに絞ってそれを完璧にするようにしましょう。
そのソフトウェアがなにかひとつの場面で
使えることがわかれば、
あとは自分自身で他の使い方を見つけてくれるようになります。
また、もしかしたら「残りのドキュメントを書いてあげようか？」
なんていう幸運なことになるかもしれません。
これについては次のポイントで取り上げます。
ドキュメントがまだ出来上がっていないところについては、
それを示しておくこと。
読者に対し、足りていない部分があることを認識していますよ、
ということを示すことにより、
あなたは読者の視線に合わせることになります。
読者に共感を示すことにより、読者に対し、
重要なことをプロジェクトに納得してもらうための苦闘に直面することはない、
ということを再保証することになるのです。
別に「いつまでにこのドキュメントを仕上げる」と表明する必要はありません。
ボランティアの助けを広く求めるものとして取り扱うのも同程度に正当なことです。
この最後に述べた点は、実のところ、より広範囲の重要性があり、
単にドキュメントだけに限らずプロジェクト全体にあてはまることです。
既知の足りていない部分を正確に会計することは、
オープンソースの世界においては当たり前のことだということです。
そのプロジェクトの欠点を必要以上に誇張する必要はありません。
単に、事情がそれを要求する場合
(ドキュメントやバグ追跡データベース、あるいはメーリングリストにおける議論など)
に、それを厳正かつ私情を交えずに明らかにするだけのことです。
それを負け犬根性だという人はいないでしょうし、
明示的に示さない限りは「いつまでにこれを解決する」という公約だと受け取る人もいないでしょう。
ソフトウェアを使用していると、だれでもそのソフトウェアの欠陥を発見してしまうものです。
彼らが心の準備をできるようにしておいてあげましょう。
すると、そのプロジェクトは自分たちのことがよくわかっているとみなされるようになります。
FAQ の管理
FAQ ("Frequently Asked Questions"、
つまり "よくある質問集") は、教育という観点において投資効果の最も高いものの１つです。
FAQ は、ユーザーや開発者が実際に質問する内容
—彼らが質問することをあなたが 期待した
内容ではありません—にチューニングされています。
その結果、よくメンテナンスされている FAQ
を探した人はたいてい、まさに欲しかった回答が見つけられるようになります。
ユーザーは、何か問題に出くわすとまず FAQ を調べます。
公式マニュアルよりも FAQ のほうを先に見ることも多いでしょう。
そして、他のサイトから最も多くリンクされることになるのも
FAQ となるでしょう。
残念なことに、プロジェクトが始まったばかりのころは
FAQ を用意することはできません。FAQ は誰かが書くものではなく、
徐々に成長していくものだからです。FAQ は、
その名前からして反応的なドキュメントであり、
多くの人が日々ソフトウェアを使っていくにしたがって成長するものです。
これから受けることになるであろう質問を正確に予測することなど不可能なので、
有用な FAQ を腰を据えてゼロから書き上げることなどできないのです。
したがって、FAQ を書こうとして時間を浪費することは避けましょう。
しかし、ほとんど空っぽの FAQ のテンプレートを用意しておくことは良い考えかもしれません。
そうすることによって、プロジェクトが動き始めた後に
ユーザーが質問と回答を投稿してくれるかもしれません。
この段階で大事なのは、完全性ではなく利便性です。
FAQ が追加しやすいようになっていれば、皆がそこに追加してくれるでしょう
(FAQ を適切に管理するという作業は決して簡単なものではなく、
興味をそそる問題です。これについては、
の でより詳しく説明します)。
ドキュメントの公開方法
ドキュメントは２通りの方法で公開しなければなりません。オンライン
(ウェブサイト上で直接公開するもの)、そして
ソフトウェアの配布物としてダウンロード可能なもの
(
の を参照してください) の２通りです。
オンラインで公開しなければならない理由は、
人は普通そのソフトウェアをダウンロードする 前に
ドキュメントを読むことが多いからです。
ダウンロードに値するかどうかを、ドキュメントの内容で判断するわけです。
しかし、それだけでなくソフトウェアにも同梱しておく必要があります。
これは、ダウンロードすることでそのパッケージを使用するために必要なものがすべて手に入る
(すなわち、ローカルにアクセス可能になる) ようにすべきである、
という原則に従ったものです。
ドキュメントをオンラインで提供する際には、ドキュメント
全体を単一の HTML
ページにまとめたものへのリンクを用意しておくようにしましょう
(このページへのリンクには、"完全版" や "すべてをひとまとめにしたもの"、
あるいは "単一の大きなページ" といった説明をつけておきます。
これによって、そのページの読み込みに時間がかかることを示します)。
これは、ドキュメント全体から特定の単語やフレーズを検索したいといった用途において便利です。
一般に、そのような場合は何を探したいのかが既にわかっています。
単に、それが第何章にあるのかが思い出せないだけなのです。
そんな人たちにとっては、あるページには目次だけ、次のページには導入だけ、
その次のページにはインストール方法だけ、……
といったドキュメントほどストレスが溜まるものはありません。
こんな形式のページ構成だと、ブラウザの検索機能が無意味になってしまいます。
個別に分割した形式が便利なのは、必要な内容が第何章にあるのかが事前にわかっている場合です。
あるいは、ドキュメント全体を頭から最後まで順に読んでいきたい人にとっても便利でしょう。
しかし、ドキュメントにアクセスする人の多くは、このパターンには
当てはまりません。
よくあるパターンは、そのソフトウェアの基本的な内容をある程度理解している人が、
特定の単語やフレーズを検索するといった使い方です。
そんな人たちに対して単一の検索可能なドキュメントを提供しなければ、
彼らにとっては非常に生きにくい世界になってしまいます。
開発者向けドキュメント
開発者向けドキュメントを書く目的は、
プログラマーがコードを理解するのを助けること、
そしてコードの修正や拡張ができるようになるのを助けることです。
先ほど説明した 開発者向けガイドライン
は技術的というよりも社会的な内容でしたが、
今回説明するドキュメントはこれとは少々異なります。
開発者向けガイドラインは、
プログラマー同士がお互いうまくやっていくための方法をまとめたものです。
一方、開発者向けドキュメントはコードそのものとうまくやっていくための方法を示すものとなります。
利便性のためにこれらの２つのドキュメントがひとつにまとめられていることもあります
(先ほど例でしめした
のように) が、そうしなければならないというわけではありません。
開発者ドキュメントがいかに有用なものであったとしても、
それが原因でリリースを遅らせるようなことがあってはなりません。
そのプログラムの作者自身がコードに関する質問に答えられる
(そして答える気がある) のなら、当面はそれで十分です。
実際のところ、何度も何度も同じ質問に答える羽目になるっていうことが
ドキュメント作成の動機となることもあります。
しかし、ドキュメントを書き始める前であっても、
プロジェクトに協力することを決心した人たちは
何とかコードと格闘しようとするものです。
何が人をそこまでさせるのかといえば、
そのコードがきっと何か自分の役に立つだろうと考えているからです。
人がそれを信じていれば、自分自身で何とかしようとするでしょう。
信じていなければ、大量の開発者向けドキュメントがあったとしてもあまり役立たないでしょう。
なので、もしどちらか一方に向けたドキュメントしか書く時間がないのであれば、
まずユーザー向けのドキュメントを作成しましょう。
ユーザー向けのドキュメントは、事実上
開発者向けのドキュメントでもあります。
そのソフトウェアの開発に参加しようとしているプログラマーは、
まずそのソフトウェアの使い方を身に着けなければならないからです。
後になって他のプログラマーが同じような質問を
何度も何度も繰り返すようになったときに、
あらためて時間をとってドキュメントを作成すればいいでしょう。
プロジェクトによっては wiki を用いてドキュメントを書き始めるところもあります。
それどころか、wiki をメインのドキュメントとしているところもあります。
私の経験上、これはあまりうまくいかないものです。
もしうまくいくとすれば、それはドキュメントの構成をしっかり把握し、
そこに何を書くべきかを熟知した数人の人間が頻繁に wiki を更新している場合のみでしょう。
詳細は、
の をご覧ください。
使用例とスクリーンショット
そのプロジェクトがグラフィカルなユーザーインターフェイスを持っていたり、
グラフィカルあるいはそうでない特徴的な出力を行ったりする場合は、
そのサンプルをプロジェクトのウェブサイトに公開しておきましょう。
インターフェイスの場合は、スクリーンショットがこれにあたります。
出力の場合は、同じくスクリーンショットか、
あるいは実際の出力ファイルとなります。
これはどちらも、即座の満足感に対するユーザーの欲求を満たすものです。
長々とした説明やメーリングリストでのやりとりよりも、
ほんの一枚のスクリーンショットのほうが説得力を持つこともあります。
なぜなら、スクリーンショットはまさにそのソフトウェアが
動作した結果であることに疑いの余地がないからです。
バグだらけかもしれません。インストールが難しいかもしれません。
ドキュメントが足りないかもしれません。
でも、スクリーンショットさえあれば、
何とかがんばれば動かすことができるんだということの証明になります。
スクリーンショット
作ったことがない人にとっては、スクリーンショットの作成は大変なものに感じられるかもしれません。
そこで、ここではその基本的な方法を説明します。Gimp ()
を立ち上げて、メニューから
File->Acquire->Screenshot
を選び、Single Window あるいは
Whole Screen のいずれかを指定して
OK をクリックします。
その次にマウスでクリックしたウィンドウあるいはスクリーンが、
Gimp に画像として取り込まれます。あとは、必要に応じて画像の一部を切り出したり
サイズを変更したりします。その方法は
で説明されています。
プロジェクトのウェブサイトに置くことのできる情報は、これら以外にもたくさんあります。
最新情報のページやプロジェクトの歴史のページ、関連サイトへのリンク、
サイト内検索の機能、寄付の受付などです。
もし時間が許したり何か特別な理由があるのなら、これらを作成してもよいでしょうが、
プロジェクトの立ち上げ時には通常はどれも不要です。
しかし、将来のために心に留めておきましょう。
公開場所
オープンソースプロジェクトのために、
ウェブサイト用の領域やバージョン管理機能、バグ追跡システム、ダウンロードエリア、
掲示板、バックアップなどの機能を無料で提供するサイトがいくつかあります。
詳細はサイトによって異なりますが、基本的な機能はどこでも同じようなものです。
これらのサイトのいずれかを使用すると、無料で多くのものを手に入れることができます。
ただ、ユーザーへの見せ方をきめ細かく調整するといったことはあきらめなければなりません。
そのサイトでどんなソフトウェアを用いるのかを決めるのはホスティング業者であり、
プロジェクトのウェブページの見た目はその業者に多少なりとも左右されることになります。
あらかじめ用意されているホスティングサイトを使うことの利点と欠点、
ホスティングサイトの一覧などについての詳細は、
の をご覧ください。
ライセンスの選択と適用
このセクションでは、ライセンスの選択方法について
手っ取り早く大雑把に説明します。
個々のライセンスについての法的な意味合いや
他のフリーソフトウェアと組み合わせて使用する際に出てくる影響などについての詳細は
をご覧ください。
世の中には、フリーソフトウェア用の優れたライセンスがたくさんあります。
ここでは、そのほとんどについては取り上げません。
なぜならそれらは特定の人や組織の法的な需要を満たすためだけに書かれたものだったり
あなたのプロジェクトには適切でないものだったりするからです。
ここで取り上げるのは、よく用いられているものに限定します。
ほとんどの場合は、ここで取り上げたものの中からライセンスを選択することになるでしょう。
「何でもできる」ライセンス
あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にならないのなら、
MIT/X スタイル のライセンスを使用しましょう。
これは必要最小限のことのみを記したライセンスです。
このライセンスは、名目上の著作権 (実際には複製を制限しません)
と無保証であるということだけを明記するシンプルなものです。
詳細は を参照してください。
GPL
あなたプロジェクトのコードが独占的ソフトウェアに流用されることが気にいらないのなら、
GNU General Public License
() を使用しましょう。
GPL は、おそらく現在世界中でいちばんよく知られているフリーソフトウェアライセンスです。
これは最大の利点です。というのも、
プロジェクトに参加しようと考えているユーザーの多くはこのライセンスを知っており、
そのライセンスについて学習する手間が省けるからです。
詳細は、
の を参照してください。
ユーザーがあなたのコードとネットワーク越しにやりとりする場合 —
つまり、ソフトウェアがネットワーク上でホストされたサービスの一部である場合は —
GNU Affero GPL の利用を検討してください。
詳しくは、 の
を参照してください。
ライセンスを適用する方法
ライセンスを決めたら、それをソフトウェアに適用しなければなりません。
まず最初にすべきことは、プロジェクトのトップページにライセンスを明記することです。
実際のライセンスの本文をここで示す必要はありません。単にライセンスの名前を示すだけにしておき、
ライセンスの本文は別のページに置いてそこにリンクするようにしましょう。
これにより、そのソフトウェアをどのようなライセンスのもとで提供
するつもり なのかを示すことはできます。
しかし、法的な側面からみるとこれだけではちょっと不十分です。
さらに、ソフトウェア自身にライセンスが含まれていなければなりません。
標準的な方法は、ライセンスの全文を含んだテキストファイル COPYING
(あるいは LICENSE) をソフトウェアのソースコードに同梱し、
それと同時に各ソースファイルの先頭に、簡単な説明をコメントとして付加します。
この説明に含めるのは、著作権の発生した日付や著作権の保持者、
ライセンス名、そしてライセンスの全文がどこで取得できるかなどです。
これにはさまざまなパターンがあります。ここでは、ひとつの例として
GNU GPL を見てみましょう。各ソースファイルの先頭には、次のような説明を付加します。
Copyright (C) <年> <作者名>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>
この文面では、ライセンスの全文がプログラムに同梱されているファイル COPYING
あるいは LICENSE
に存在することは明記されていません。しかし、通常はこの名前のファイルを使用することになります
(上の文面を変更して、このファイル名を明記するようにしてもかまいません)。
このテンプレートには、ライセンスのコピーを取得するための手紙の宛先も記載されています。
これ以外の一般的な方法としては、ライセンスの本文を記載したウェブページへのリンクを用意するというものもあります。
弁護士の助言にしたがって (そんな金銭的余裕がなければあなたの自己判断で)、
ライセンスのコピーが最も恒常的に存在すると思われる場所を使用するようにしましょう。
たとえば、あなたのプロジェクトのウェブサイト上のどこかでもかまいません。
一般的には、各ソースファイル中に含める注意書きは上のものと全く同じである必要はありません。
著作権保有者と日付、ライセンスの名前、そしてライセンスの全文がどこで取得できるのか
といったことが含まれていればいいのです。
うまく引っ張っていく
ここまで取り上げてきたのは、プロジェクトの立ち上げ時に一度だけ必要となる作業でした。
ライセンスの選択や最初のウェブサイトの作成などです。
しかし、プロジェクト開始時に最も大切なのは、それ以外の動的な作業です。
メーリングリストのアドレスを決めるなんていうのは簡単なことです。
でも、そのメーリングリストでのやり取りを有益で前向きなものに保つのは
それとはまったく別の話となります。
これまで何年にもわたって社内の閉じた環境で開発が進められてきたものをオープンにすると、
その開発プロセスはこれまでとはかわります。これまでの開発者たちに対して、
その変更に対応できるように準備をさせなければなりません。
最も困難なのが、はじめの一歩です。なぜなら、今後の方向性に関する先例もなければ
今後どのようになっていくのかもまだはっきりわからないからです。
プロジェクトの安定性は、形式張った方針からくるものではなく、
開発者の間で徐々にできあがっていく集合知によってもたらされるものです。
そして、これはしっかりとらえにくいものです。
明文化された規則があることもありますが、それはたいてい、
プロジェクトを本当に動かしているこれらの無形の合意をまとめあげたものにすぎません。
明文化された方針によってプロジェクトの文化を定義することはできませんし、
それに近づくことさえできません。
このようになるには、いくつかの理由があります。
成長と変化の速さは、人が考えるほどには文化の蓄積に影響を与えません。
変化の速度があまりにも高速にならない限り、新入りさんがそれを学ぶ時間はあります。
そして学び終えた後は、自分自身でそのやりかたを補強してくれるでしょう。
童謡が、いったいどのようにして何百年も歌い継がれるようになったのかを考えてみましょう。
現在の子どもたちが歌っている童謡は、基本的には数百年前の子どもたちの歌っているものと同じです。
もちろん、昔の子どもたちが童謡を歌っていた頃には現在の子どもたちはまだ産まれていません。
子どもたちはその歌を年長者から聞いて覚えます。そして子どもたちが成長すると、
年少者の前でそれを歌って聞かせるわけです。もちろん、
子どもたちは意識的にそうするよう指示されているわけではありません。
しかし、何百年も同じ歌が歌い継がれているという事実は、
このような伝承が常に繰り返し行われていることを示しています。
フリーソフトウェアプロジェクトの歴史が今後何百年も続くかどうかはわかりません
(どうなるかはまだわかりません) が、この仕組みは似たり寄ったりでしょう。
しかし、その回転率はより高速になるので、
より活発かつ慎重に伝承を行うようにしなければなりません。
この動きは、人が基本的に社会規範を求めているという性質があるので成功しやすくなります。
それこそが人が存在する理由なのですから。
一般的な方法でまとめあげられた集団なら、そこに参加しようとする人々は
本能的にその集団の一員として振る舞うためのやりかたを見つけようとするものです。
より早い時期に先例を確立するには、そのプロジェクトに役立つ
「グループとしての」振る舞いを作ることです。いったんできあがってしまえば、
あとは勝手にそれが広まっていきます。
以下に示すいくつかの例は、
よりよい先例を作るためにできる具体的なことをまとめたものです。
これだけを行えば完全だというものではありません。単に、
「早いうちに協力的なムードを作り上げておくとプロジェクトを運営しやすくなりますよ」
ということを説明するためだけのものです。
物理的には、個々の開発者がそれぞれ別の場所で作業をしているのかもしれません。
しかし、まるで同じ部屋で一緒に開発しているかのように 感じさせる
ために、いろいろなことができます。
彼らがこのように感じてくれればくれるほど、プロジェクトに対してより時間をさきたいと思うようになるでしょう。
以下の例は、Subversion プロジェクト ()
から選びました。私は、開始当時からこのプロジェクトに参加しています。
しかし、これらの例は決して Subversion 独特のものではありません。
同様の状況は大半のオープンソースプロジェクトで起こりえるでしょう。
また、プロジェクトに片足を突っ込む際には意識しておく必要があることばかりです。
個人的な議論を避ける
プロジェクトを一般に向けて公開した後でも、難しい問題についての話し合いは
内輪の関係者たちだけで行いたいと考えることもあるでしょう。
これは、プロジェクトが始まったばかりのときにはあり得ることです。
話し合うべきことは山ほどありますし、通常は
その話し合いに参加する資格のある外部の協力者はほとんどいないからです。
公開されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことでしょう。
メールでのやりとりに特有ののんびりした速度、
合意を形成するのにかかる時間、本当は何もわかっていないのに
「自分はすべてわかっている」と勘違いしているボランティアへの対応
(どんなプロジェクトでもこの手の人がいます。彼らのうち何人かは将来すばらしい貢献をしてくれることになるでしょうが、
中にはずっと勘違いしたままの人だっています)、ある問題 X がより大きい問題 Y の一部であるときに、
なぜ問題 Y ではなく問題 X だけを解決したいのかを理解してくれない人たち、
などなど。こんなときに、密室の話し合いで決めた内容を "既成事実 (faits accomplis)"、
あるいは少なくとも有力な選択肢として提示できればどんなに楽なことでしょう。
でも、そんなことをしてはいけません。
たとえ公開の場での議論の進行が遅くて厄介だとしても、
長い目で見ればそれが一番望ましい方法です。
重要な決定を内輪でこっそり行うのは、まるでそのプロジェクトに
「貢献者よけスプレー」を振りまくようなものです。
秘密の協議会がすべての重要な決定を行うというような環境では、
やる気のあるボランティアは決してついてこないでしょう。
さらに、公開の場での議論にはよい副作用もあります。
その議論が、新しく参加する開発者の訓練や教育に役立ちます。
その議論をいったいどれだけの人が注目しているかは決してわかりません。
大半の人たちは単なる傍観者として見ているだけで、
黙ってそのソフトウェアについての情報を追いかけているのです。
その議論は、あなた自身 の訓練にもなります。
技術的な問題を、そのソフトウェアにあまり詳しくない人たちにもわかるように説明するという技術を磨くことができます。
これは実際に必要となる技術であり、
すでにそのソフトウェアについて熟知している人たちと話しているだけでは身につけることができません。
議論の内容とその結論が公開されたアーカイブに残るようになります。
後に同じような問題が発生したときに、同じ議論を繰り返す必要がなくなります。
詳細は
の を参照してください。
最後に、メーリングリスト上の誰かがそのやり取りに対して真の貢献をしてくれるかもしれません。
つまり、あなたが思いもしなかった新たな考え方を示してくれるということです。
これがどのくらいの頻度で起こるのかは断言できません。
そのコードの複雑さがどれくらいか、そしてどの程度の専門知識を要するかによっても異なります。
ただ、私のこれまでの経験上、その頻度はみなさんが思っているよりもかなり高くなります。
Subversion プロジェクトで、私たち (プロジェクトを開始した当時のメンバー)
は深く複雑なさまざまな問題に直面していました。私たちは何ヶ月も悩み続けました。
そして、率直に言って、当時できたてのメーリングリストにいるメンバーがこの手の議論に貢献してくれるとは期待していませんでした。
そこで私たちは安易な方法をとることにしました。技術的なアイデアについての議論を個人的なメールのやりとりで行うようにしだしたのです。
その様子を嗅ぎ付けた人
ここまではまだ個人の名前を挙げることはありませんでしたが、
これ以降では必要に応じて名前を挙げていきます。ここでいう「嗅ぎ付けた人」
とは Brian Behlendorf のことです。彼は、
プライバシーの侵害の恐れがない議論はすべて公開の場で行うべきだという一般論を指摘してくれました。
から「議論は公開されたメーリングリストでしてくれ」
と言われるまで、その状態が続きました。私たちはそれを受け入れ、その話題をメーリングリストに移動しました。
そのとたん、数々の洞察に満ちた意見や提案が寄せられるようになり、私たちは驚きました。
寄せられた意見の多くは、これまで私たちが考えもしなかったものでした。
メーリングリスト上には、非常に 優秀な人間がいたのです。
彼らはただ、メーリングリスト上にネタが投下されるのを待ちわびていたのです。
確かに、すべて密室の議論ですませるのに比べれば時間はかかりました。
しかし、時間をかけたのに十分見合うだけの成果が得られました。
"三人寄れば文殊の知恵" だとか "個人よりも集団のほうが常によい判断ができる"
とかいうように一般化して逃げてしまうのではなく、
集団のほうがよい結果がでる活動としてはどんなものがあるのかを知っておきましょう。
大規模なピア-レビューなどがその例のひとつです。
あるいは、とにかくたくさんの案を手早く出していくといった作業もそれにあたります。
もちろんアイデアの質はそれを考えた人たちの質に依存しますが、
困難な問題を皆にぶつけてみるまで、誰がどのような案を持っているかはわからないものです。
当然、内容によっては個人的に議論しなければならないものもあります。
本書の中でもそのような例がいくつか登場します。
しかし、基本方針として、隠す必要がないものは、すべて公開すべきである
ということは常に心においておきましょう。
そのためには何らかのアクションが必要です。
あなた自身が常に公開のメーリングリストに投稿しようと心がけるだけでは不十分です。
隠す必要がない内容のメールを他の人から受け取ったら、
それをメーリングリストにも流すようにしなければなりません。
誰かが個人的に議論を始めようとしているとき、もしそれが個人的にする必要のないものなら、
それを個人的に行うのか公開で行うのかに関する議論をすぐに始める責任があります。
首尾よくその議論を公開の場に持ち出すか、
あるいは個人的に話し合うのが適切であることがわかるまで、
元の話題にはコメントしないでください。
常にこのようにすることを心がければ、
人はやがてデフォルトで公開の場を使用することになるでしょう。
炎上を阻止する
プロジェクトを一般に公開したら、
フォーラムにおける失礼な振る舞いや侮辱的な発言にはゼロトレランスで (情け容赦なく)
対処しなければなりません。「ゼロトレランスで」とは、
何か技術的に特別なことをしなければならないという意味ではありません。
別の参加者を罵倒した参加者をメーリングリストから強制退会させる必要はありませんし、
人を傷つけるようなコメントをしたからといってその人のコミット権を剥奪する必要もありません
(理屈上は、結局のところそういった措置をとらざるを得ないことになるかもしれません。
しかし、それはさまざまな対策がすべて失敗したときの最後の手段とすべきです。
つまり、プロジェクトの開始当初にはそのようなことは起こりません)。
ここで言うゼロトレランスとは、そんな振る舞いを決して見過ごさないということです。
たとえば、技術的なコメントといっしょに
プロジェクトの他の開発者に対する個人攻撃 (ad hominem)
を含むコメントが投稿されたとしましょう。そんな場合は、まず
その個人攻撃に対する指摘をしたうえで、技術的な内容についてはそれとは分けて返答するようにしましょう。
残念ながら、これは易しいことではありません。
そして、たいていは建設的な議論が不毛な罵倒合戦に陥ってしまいます。
人は、面と向かっては決して言えないことでもメールでは平気で言ってしまうものです。
また、議論の内容もこの傾向に拍車をかけます。
技術的な問題に関して、多くの人は「ほとんどの質問には正解がひとつしかない」
と考えがちです。そしてその答えに同意しない人のことを無知で愚かな人だと思ってしまうのです。
誰かの技術的な提案を否定すると、その人自身の人格を否定したように受け取られることもあります。
実際、技術的な議論が人格攻撃に切り替わる瞬間を見極めるのは非常に難しいものです。
厳しめの返答や処罰がいい考えではないひとつの理由がここにあります。
そのかわりに、ちょっと雰囲気が怪しくなってきたなと感じたら、
議論を友好的に進めるように促す投稿をするようにしましょう。
その際に、特定の人物が意図的にそんなことをしているように非難することは避けなければいけません。
しかし、そのような "町のおまわりさん" 的な投稿は、
時として園児をしつける幼稚園の先生のように見えてしまうという傾向があります。
まず最初にひとこと。個人攻撃につながる (あるいはその恐れのある)
コメントは控えてください。たとえば、J が設計したセキュリティ層について
"コンピュータのセキュリティに関する基礎知識に欠ける無能な設計だ"
と語るようなことです。それが正しいかどうかは別にして、
これは議論の進め方としては間違っています。
J は信念を持ってこの提案をしたわけです。
もし問題があるならその問題を指摘しましょう。
そして皆でそれを修正するか、新しく設計をやりなおせばいいじゃないですか。
M は決して J を個人攻撃するつもりがないことは知っています。
でも、その言い方はちょっとまずかった。もっと建設的な議論を進めましょう。
さて、提案内容に話を戻しましょう。
私は、M の言うことはもっともだと思います……
ちょっと堅苦しく感じるかも知れませんが、これはかなりの効果があります。
何かあったら必ず口を出すが、決して攻撃側に謝罪を要求したり落ち度を認めさせたりしない。
そうではなく、そのまま放っておいて次回はよりおだやかに振舞うように促すのです。
そうすれば彼らはきっとそれに従ってくれます。
これをうまく行う秘訣のひとつは、どっちが悪いかとかどうすべきかといった
メタ議論を主題にしてしまわないことです。そうではなく、
本題に入る前の前置き程度の扱いにしておくべきです。
「ここではそんな振る舞いはやめてください」と指摘した後はすぐに本題に移ります。
そうすることで、相手側にも本題に返答する機会を与えることができるのです。
もしそれでも「あなたに非難されるいわれはない」といったことを言われたら、
もうそれ以上その話題を引きずるのはやめましょう。
単にその話題に関する返信をやめておく (単に彼らは自分の主張を振りかざしているだけであり、
返事を求めているわけではなさそうな場合) か、あるいは
「出すぎたまねをしてしまってごめんなさい。メールではなかなかニュアンスが伝わりにくいので」
と謝ったうえで本題に戻ればいいのです。
不適切な振る舞いをした人たちの主張は、公開の場であるか否かにかかわらず
決して認めないでください。もしかれらの方から謝罪があればすばらしいことですが、
こちらから謝罪を要求しても相手をさらに怒らせるだけでしょう。
最終的な目標は、その集団に「礼儀をわきまえる」という空気を作り上げることです。
これは、プロジェクトにとって大きな助けとなります。なぜなら、開発者が
(自分が好んでサポートしようとしている) プロジェクトで罵倒合戦に巻き込まれる心配がなくなるからです。
そんなことが原因で開発者候補がプロジェクトが離れていることに、あなたは気づかないかもしれません。
誰かがメーリングリストにひっそり参加してそのプロジェクトの状況を観察し、
参加するための障壁が厚いことがわかり、結局参加することをあきらめるということがあるかもしれません。
フォーラムを友好的な雰囲気にしておくことが、長期的に生き残るための作戦として有効です。
また、これはプロジェクトが小さいうちから心がけておいたほうが実現しやすいことです。
いちどそんな文化ができあがってしまえば、あなたひとりがいちいちそれを主張して回る必要もなくなるでしょう。
皆がそういうふうに持って行ってくれるからです。
きちんとしたコードレビューの習慣
開発コミュニティーをうまく育てていくために最適な方法は、
開発者どうしがお互いのコードを見せ合うことです。
これを効率的に行うには、技術的な支援が効果的です。特に便利なのが、コミット時のメール通知です。
これについては で詳しく説明します。
コミットメールとは、誰かがソースコードに加えた変更をコミットするたびに
そのログメッセージと変更内容をメールで送る機能のことです
( の を参照してください)。
コードレビュー とは、コミットメールがやってくるたびにその内容を確認し、
バグや改善点がないかどうかを探す作業を指します。
これは、オープンソースプロジェクトでごく一般的に行われているコードレビューの方法を示したものです。
より中央集権的なプロジェクトでは、複数の人が集まってソースコードのプリントアウトを見つめ、
特定の問題やパターンを探すことを称して "コードレビュー" という場合もあります。
コードレビューは、さまざまな点で役立ちます。
オープンソースの世界におけるコードレビューの最大の効果は、
ソフトウェアの品質を一定に保つことです。
ソフトウェアにバグが含まれる原因は、
コミットされたコードをきちんとチェックしなかったことにあります。
コミットの内容を多くの目でチェックすることで、
バグを残したまま公開してしまう危険性を減らすことになります。
しかし、コードレビューの目的はこのような直接的なものだけではありません。
コードレビューによって、自分たちの作業の内容を確認させることができます。
コミットの内容をレビューするには、その作業についてよく知っておく必要があるからです。
他の人が自分の作業を評価すると知っていれば、
人は最善を尽くして作業を行うようになります。
レビューは公開の場で行わなければなりません。
開発者同士が物理的に同じ部屋にいる場合であっても、
誰かがコミットしたときにそのレビューを部屋の中だけで済ませてしまってはいけません。
面倒でも開発者用のメーリングリストに投稿するようにしましょう。
そのレビューを見ることで、参加者全員が何かを得ることになります。
レビューの結果、何らかのコメントをしたり、
場合によっては不具合を見つけたりすることもあります。
レビューは日常の作業のひとつととらえましょう。
そう。ちょうど皿洗いや芝生の手入れと同じような感覚です。
Subversion プロジェクトの開始当初は、日常的なコードレビューの習慣はありませんでした。
すべてのコミットがレビューの対象になるという保証はありませんでしたが、
変更されたコードの内容に興味のある人がそれを眺めるということはありました。
当時のコードに紛れ込んでいたバグは発見可能でしたし見つけられるべきでした。
当時の開発者のひとりである Greg Stein は、
過去の経験からコードレビューが役立つことを知っていました。
彼は、リポジトリへの すべてのコミット
の１行１行の内容を詳細にまでわたってレビューするようになりました。
誰かがコミットするたびにそのコミットについての Greg からのメールが
開発者用メーリングリストに流れました。メールの内容は、
コミットの内容を細かく切り刻んで分析し、起こりうる問題を指摘するといったものです。
時には、優れたコードに対して賞賛を送ることもありました。
コミットがあるたびに、バグを見つけたり
注意しないとつまづくく恐れのあるあまりよい書き方ではないコードを見つけたりしていたのです。
彼は、コミットの内容をレビューするのが自分ひとりであることについて、
表立っては不平を述べることはありませんでした。
かなりの時間をレビューに費やしていたにもかかわらずです。
その代わりに、ことあるごとにコードレビューのすばらしさについて発言していました。
やがて、私を含めた他のメンバーもコミットの内容を定期的にレビューするようになりました。
何がそうさせたのでしょう? 決して Greg が私たちにそれを強制したわけではありません。
彼は「コードのレビューが時間をかけるだけの価値のあるものである」こと、そして
「他人のコードをレビューすることは新しいコードを書くのと同じくらいに重要である」
ことを自身の行動をもって証明したのです。
いざそういう習慣が身につくと、自分のコミットに何の反応もなければ逆に不安になります。
開発者用メーリングリストで「誰か私のコードをレビューしてくれないかな?」
と聞いてみたりなんかして。後に、Greg は別の仕事を得ることになり、
Subversion にあまり時間をかけられないようになってしまいました。
彼は定期的なレビューをあきらめざるを得なくなったのです。
しかし、そのときにはすでにレビューの習慣が私たちにも深く根付いていました。
まるで太古の昔からそれが当たり前であったかのように。
コードのレビューは、最初のコミットの時点から始めましょう。
差分を見れば簡単に発見できる問題としては次のようなものがあります。
たとえばセキュリティ上の脆弱性やメモリリーク、
コメントや API ドキュメントの不足、「ひとつずれちゃった (off-by-one)
エラー」、呼び出し元と呼び出し先の規約の不一致などです。
また差分の前後を確認することで発見できる問題もあります。
しかし、より規模の大きい問題、
たとえば繰り返し登場するパターンを一か所にまとめていないことなどは、
定期的なレビューをしていないと見つけにくいものです。
過去の更新の履歴の記憶を今回の差分と組み合わせることで、
このようなの問題も見つけやすくなるのです。
何もコメントすべき点が見つからないんじゃないかとか、
すべてのコードについて熟知しているわけじゃないとかいったことを気にしないでください。
あらゆるコミットには何かしら言うべきことがあるはずです。
何も疑問点が見つからなかった場合は、何か賞賛の言葉を贈ればいいだけのことです。
大事なのは、すべてのコミッターに対して
「あなたの作業内容を見ているし、理解もしている」というメッセージを伝えることです。
もちろん「後でほかの人にレビューしてもらえるから、コミット前のチェックやテストは不要」
というわけではありません。本来自分自身で発見すべき問題を、
他人のレビューに頼ってはいけません。
もともと非公開だったプロジェクトをオープンにするときには、
変化の大きさに気をつけよう
既存のプロジェクトをオープンにする場合は、
クローズド環境での開発に慣れきった既存の開発者がいることに注意しましょう。
環境が大きく変わることを彼らに理解してもらうこと、
また、彼ら側の視点で考えた場合に何がどのように変わるのかを
あなた自身が理解することが大切です。
彼らにとってその状況がどのようなものかを想像してください。
これまでは、どのような設計でどのようなコードを書くのかを決めるのは
特定のプログラマーの集団でした。また、彼らは同じ管理者のもとで働き、
同じような重圧を受けていました。
そしてお互いのスキルや弱点もよくわかっていました。
今やそうではありません。自分の書いたコードをチェックしてもらうために
どこの誰ともわからない人に向かって公開しなければならないのです。
彼らは純粋にコードの内容だけをもとにして判断を下します。
それ以外のビジネス上の問題などは考慮しません。
自分のコードについて、見知らぬ人からさまざまな質問が寄せられることになります。
あんなに苦労して作ったドキュメントが、まだ
不十分であることが判明して (お決まりのパターンです)
衝撃を受ける瞬間です。
新入りさんは、みんな誰も知らない得体の知れない人たちばかりです。
もし既存の開発者の中に自分のスキルに不安のある人がいたとしましょう。
新入りさんが何も考えずに彼のコードの問題を指摘したら、
彼にどのような悪影響を及ぼすでしょうか。特に、
彼の同僚の目の前でそのようなことが起こったら、さらに状況は悪くなります。
完全無欠のプログラマーが集まったチームでもない限り、
このような問題が起こることは避けられません。
実際、すべてのメンバーが一度はこのような経験をすることになるでしょう。
これは、決して彼らがプログラマーとして劣っているからではありません。
ある程度以上のサイズのプログラムには、必ずバグが含まれるものです。
そして、コードのレビューによってそれが見つかることになります
(本章の前半にある
をご覧ください)。
と同時に、新入りさん自身は最初のうちは自分のコードをレビューされることはないでしょう。
というのも、そのプロジェクトにある程度なじむまではコードを書くことができないからです。
既存の開発者にとっては「奴らからさんざん批判されるだけで、
こちらからは言い返すことができない」という状況になるわけです。
そのため、古株の開発者たちに対する総攻撃状態になる危険性があります。
これを避ける最良の方法は、これから何が起こるのかを彼らに説明することです。
最初のうちは不快に感じるかもしれないがそれは当然の心理であること、
そしていつかはうまくいくようになることを説明しましょう。
これらの警告は、プロジェクトをオープンにする前に
閉じた場所で行わなければなりません。
また、公開されたメーリングリスト上で
「プロジェクトの開発方式が新しくなった」「なれるには少々時間がかかる」
ということを知らせるのも効果的です。
一番いいのは、なにか例を示すことです。
既存の開発者たちがあまり初心者の質問に答えていないようなら、
彼らに「もっと返事を書いてあげてよ」といってもあまり意味がありません。
彼らは単に、どう答えればいいのかがわからないだけかもしれません。
あるいは、他人の質問に答えるよりも
実際にコードを書くほうが大切だと思っているのかも知れません。
彼らを質問に答えさせるようにするには、まずあなた自身がお手本を見せましょう。
公開されているメーリングリスト上で、誰かの質問に対して答えてみましょう。
その質問をうまくさばくだけの専門知識がない場合は、
それに対応できる開発者に明示的に対応を依頼するようにしましょう。
そして、彼が確かに答えを返すこと、
あるいは少なくとも何らかの返事をすることを確認しましょう。
長年プロジェクトにかかわってきた開発者にとっては
どうしても閉じた場での議論のほうがやりやすく感じられることでしょう。
これまではずっとそうしてきたのですから。
そんなことが起こらないように内輪のメーリングリストの動きもチェックし、
必要な議論は公開の場で行うように彼らを誘導しましょう。
これまでは閉じた環境にあったプロジェクトをオープンにするにあたっては、
これら以外にも長期的な懸案事項があります。
では、給料をもらって開発に参加している人たちと
無償で開発に参加している人たちとをうまく共存させる方法を考えます。また
では、法的な努力の必要性について考えます。
他の団体が書いた、あるいは "所有している" コードを含むかもしれないソフトウェアを公開する場合は、
それなりの注意が必要となります。
広報
プロジェクトが人に見せられる状態 (完全なものではなく、
単にとりあえず見せられるという程度) になったら、
それを全世界に向けて公開しましょう。
これは、実際には非常に簡単なことです。まず
に行ってナビゲーションバーの Submit をクリックし、
フォームに内容を入力しさえすれば新しいプロジェクトを宣伝できるのです。
Freecode (以前は Freshmeat.net と呼ばれていましたが、2011 年 10 月に名前が変わりました)
は、新しいプロジェクトが気になる数多くの人が見ているところです。
あなたのプロジェクトに関するニュースがその中の何人かの目にとまれば、
後は口コミでその情報が広まっていくでしょう。
あなたのプロジェクトに関するお知らせを投稿するのに適したメーリングリストや
ニューズグループがあるのなら、そこに投稿するのもいいでしょう。
しかし、投稿するのはそれぞれの場所で一度ずつだけにしておきましょう。
その後の議論は、(Reply-to ヘッダを設定して)
自分のプロジェクトの会議室で続ければいいのです。
投稿内容は、要点をまとめた短いものにしなければなりません。
To: discuss@lists.example.org
Subject: [ANN] Scanley 全文インデックス化プロジェクト
Reply-to: dev@scanley.org
Scanley プロジェクトが立ち上がったことをお知らせします。
これはオープンソースの全文インデックス作成器およびサーチエンジンで、
豊富な API を持っています。プログラマーは、大きなテキストファイルを
対象とした全文検索機能を自分のプログラムに組み込めるようになります。
Scanley はようやくまともに動くようになった状態のもので、現在も活発に
開発が進められています。開発やテストに参加してくださる方を募集しています。
ホームページ: http://www.scanley.org/
機能:
- プレーンテキスト、HTML および XML の検索
- 単語あるいはフレーズによる検索
- (予定) あいまい検索
- (予定) インデックスの差分更新
- (予定) リモートのウェブサイトのインデックス化
Requirements:
- Python 2.2 以降
- インデックス作成用のディスク領域
(元のデータの約２倍の大きさ)
詳細な情報は、scanley.org をご覧ください。
それでは。
-J. Random
(公開のお知らせやプロジェクトのイベントに関するお知らせの詳細については、
の をご覧ください)
フリーソフトウェアの公開を開始する時期について、
ある程度動くものができあがった時点で公開すべきなのか、
あるいは設計段階から公開してしまうべきなのかについての議論は、
まだ結論が出ていません。私は、
これまでは「実際に動くコードがあること」が最も重要だと考えていました。
それこそが成功するプロジェクトと単なるおもちゃとを区別するものだと思ったからです。
そして、具体的に動くものがないと他の開発者をひきつけられないと思っていたのです。
最近、この考えが変わってきました。Subversion プロジェクトを開始したときにあったのは、
設計ドキュメントと何人かの気心の知れた開発者、
そして大げさなファンファーレだけでした。実際に動くコードは
一切 なかったのです。
驚いたことに、このプロジェクトは開始当初からアクティブな参加者を獲得することに成功しました。
そして実際に動くものができはじめたころには、かなり多くのボランティア開発者が
コードの内部まで深く知り尽くしているという状態になっていました。
Subversion だけが例外的な存在だというわけではありません。
Mozilla プロジェクトも実際に動くものがない状態から始まりました。
そして今や人気のあるウェブブラウザとして大成功を収めています。
これらの事例を前にして、私は「実際に動くコードこそがプロジェクトの立ち上げに必要だ」
という主張を曲げざるを得なくなりました。
動くコードがあることは成功のひとつの要素ではあります。そして、経験上は、
動くものができあがるまではプロジェクトの公開を控えたほうがよいと思います。
しかし、とりあえず先に公開してしまったほうがいいこともあります。
最低限、しっかりした設計ドキュメントか何らかのコード基盤は必要です
—もちろん、これは公開後のフィードバックを受けて改版することになるでしょう。
しかし、それだけではなく何か具体的なもの、
実際に触って試せるものが必要です。
プロジェクトを公開したからといって、大量のボランティアが
すぐにプロジェクトに参加したがるとは思わないでください。
普通は、公開した後の反応といえばもっとおとなしいものです。
何人かはたいしたことのない問い合わせをくれるでしょう。
何人かはメーリングリストに参加してくれるかもしれません。
しかし、それ以外の大半の人たちにとっては、
そのプロジェクトが公開されたことなんて気にもしていないでしょう。
しかし時間がたつにつれて、開発者として参加してくれる人や
実際にソフトウェアを利用してくれる人が徐々に増えていくことに気づくでしょう。
公開の発表は、種まきのようなものです。
そのニュースが広まるには、長い時間がかかります。
プロジェクトに参加した人たちが何らかの利益を得ることになると、
ニュースがより広まるようになります。自分が見つけたすばらしいものを、
周りにも知らせてあげようという気持ちが働くからです。
すべてがうまくいけば、そのプロジェクトは指数関数的に大きくなり、
複雑なコミュニティーに成長するでしょう。
そこまで来れば、もはや個々のメンバーの名前を知っている必要もなくなります。
また、メンバー間の会話の内容をすべて追いかけることも不可能となります。
次の章では、このような環境を運営する方法を説明します。