新しいフリーソフトウェアプロジェクトをスタートさせる方法――概論：オープンソースソフトウェアの育て方（1/2 ページ）

新しいフリーソフトウェアプロジェクトをスタートさせる方法は、保健機関が薬を配布するときの方法と似ています。フリーソフトウェアプロジェクトの立ち上げ時の注意点を解説します。

[Karl Fogel， ]

本連載の想定読者

　本稿は、「オープンソースソフトウェアの育て方〜フリーソフトウェアプロジェクトを成功させるコツ」（Karl Fogel著、高木正弘、Yoshinari Takaoka訳）をCreativeCommons Attribution-ShareAlike licenseの下で改変、提供しています。

　本連載が対象としている読者は、これからオープンソースプロジェクトを始めようと思っている、あるいは始めてはみたもののどうすればいいのか分からないというソフトウェア開発者や管理者たちです。「オープンソースのプロジェクトに参加したいんだけれど、どうしたらいいんだろう？」という人たちにも役立つことでしょう。

さあ始めましょう

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

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

（The Cathedral and the Bazaarより引用。日本語訳はこちら）

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

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

　しかし、レイモンドの指摘は今でも洞察に満ちています。ソフトウェアの作者自身がその成功に直接的な興味を持っている、なぜなら彼らは自分自身でそれを使うことになるから、というのが本質的な条件です。もしそのソフトウェアが期待通りに動かなければ、日々それを使用している作者は不満に思うことになるでしょう。例えばOpenAdapterプロジェクトを考えてみましょう。これは投資銀行Dresdner Kleinwort Wassersteinが始めたオープンソースのフレームワークで、さまざまな金融情報システムを統合するためのものです。

　どう考えても、これは「開発者の個人的な悩み解決」のために作られたものとはいえないでしょう。これは「機関の悩み解決」をするためのものです。しかし、この悩みはその機関とパートナーの経験から直接くるものです。従って、もしこのプロジェクトがうまくいっていなければ、それと気付くことができるでしょう。このようなプロジェクトは、よりよいソフトウェアを産み出すでしょう。なぜなら、フィードバックループが正しい方向に流れるからです。そのプログラムは、見知らぬ誰かに売りつけて、彼らの問題を解決できるよう書かれるのではありません。最初は自分たち自身の問題を解決するために書かれます。そしてそれがみんなと共有されるようになります。「問題」を病気に例えると、ソフトウェアは薬のようなものです。流行病を完全に根絶するために薬をばらまくのと同じように、ソフトウェアを配布するようになります。

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

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

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

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

　従って、一方で本章では主にプロジェクトを開始するに当たり用意しておくべき内容について取り扱っているのですが、その見栄えも重要であるということは忘れないでください。プロジェクトのWebサイトは（エンドユーザーと開発者の）2種類の人たちが利用するものなので、どちらを対象としたものなのかをはっきりさせる必要があります。

　本稿はWebデザインの専門書ではありませんが、1つだけ重要な法則を示しておきます。このようにさまざまな相手（部分的に重複することもあるでしょう）を対象とするときは特に重要なことです。それは、リンク先に何があるのかが、リンクをクリックしなくても大まかに分かるようにしておく、ということです。例えば、ユーザー向けのドキュメントなのか開発者向けのドキュメントなのかが、リンク先ではなくリンクそのものを見ただけで判断できるようにしておくべきです。プロジェクト運営には、情報を提供するという側面が一部にはあります。しかしまた、安心感を提供するという側面もあるのです。期待した場所に決まりきったものが提供されているというだけで、そのプロジェクトにかかわるか否か決めようとしているユーザーや開発者は安心します。「このプロジェクトはやるべきことを行い、想定される質問に対応し、その質問に対する答えをできるだけ簡単に得られるようにしている」という努力が見えるからです。このような気合を見せることで「このプロジェクトにかかわってもあなたの時間は無駄にならない」というメッセージを送ることができます。それこそが皆が聞きたいメッセージです。

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

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

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

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