第1章 導入

ほとんどのフリーソフトウェアプロジェクトは失敗します。

しかし、失敗例について聞くことはあまりありません。 みんなの気を引くのは成功したプロジェクトだけだからです。 世の中には途方もない数のフリーソフトウェアプロジェクトが存在する ^[4] ので、たとえ成功するプロジェクトがその中のごく一部に過ぎなかったとしても、 多くのプロジェクトが成功しているように見えてしまうのです。 また、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのも 私たちが失敗について聞くことがない理由のひとつでしょう。 「そのプロジェクトが消滅した瞬間」というのを特定することはできません。 参加者が少しずつ他へ移っていき、プロジェクトで作業するのをやめるだけなのです。 「プロジェクトに対して最後に変更が加えられたとき」を知ることはできますが、 実際にその変更を加えた人は「それがプロジェクトに対する最後のコミットとなる」 とは決して思っていなかったことでしょう。 また、どれぐらい動きがなければ「止まってしまった」 とみなすのかについてもはっきりした定義がありません。 目だった動きが半年間なかったとき？ ユーザー数の伸びが止まってしまい、結局開発者の数を超えることがなかったとき？ 自分の参加しているプロジェクトが結局他のプロジェクトの焼き直しであることに気づいた開発者が、 現在参加しているプロジェクトを捨ててもうひとつのほうに移動したとしましょう。 そして移った先のプロジェクトをどんどん成長させていきました。 この場合、元のプロジェクトは「消滅した」のでしょうか？ それとも「あるべき場所に移動しただけ」なのでしょうか？

このように複雑な側面があるので、 いったいどの程度の割合でプロジェクトが失敗しているのかを正確に知るのは不可能です。 しかし、過去10年を超えるオープンソース界での経験や SourceForge.net のデータからの推測、 そしてちょっとググってみた結果はどれも同じような結果となりました。 プロジェクトが失敗に終わる可能性は非常に高く、 おそらく90–95%くらいと見ていいでしょう。 かろうじて生き残ってはいるが、まともに機能していないプロジェクトも含めると、 この数字はさらに上がるでしょう。ここでいう「まともに機能していない」とは、 とりあえず動くコートは存在するが満足に使える代物ではなく、 開発が進んでいるようには見えないという状態のことです。

本書の目的は、そのような失敗を避けることです。 本書では、「どうやったらうまくいくか」だけではなく 「どうやったら失敗するか」についても説明します。 それを知ることで、問題が発生したときに軌道修正ができるようになるでしょう。 本書を読み終えられた皆さんは、オープンソース開発において陥りがちな 落とし穴を避けるさまざまなテクニックだけでなく、 成功しているプロジェクトの巨大化や保守をうまく扱うためのテクニックも身に着けていることでしょう。 成功というものはゼロサムゲームではありません。本書では、 いかにして競合プロジェクトを出し抜くかといったことは扱いません。 実際のところ、オープンソースプロジェクトを運営する上では 他の関連するプロジェクトとの協調が重要となります。 長い目で見れば、どのプロジェクトが成功しても フリーソフトウェア界全体の利益になることでしょう。

フリーソフトウェアプロジェクトが失敗に終わる原因は 独占ソフトウェアプロジェクトの場合と同じだと言い切ってしまえれば話は簡単です。 実際のところ、ソフトウェア産業におけるよく知られた問題 (たとえば非現実的な要件、あいまいな仕様、 まずいリソース管理、不十分な設計フェーズなど) はフリーソフトウェアでも起こりうることです。 これらのトピックに関しては既に大量の書物が存在するので、 本書ではそれと重複するような内容は避けるつもりです。 その代わりに、フリーソフトウェアに特有の問題について説明していきます。 フリーソフトウェアプロジェクトが行き詰まる原因としてよくあるのが、 開発者 (あるいはマネージャ) が オープンソースのソフトウェア開発に固有の問題を正しく認識していなかったことです。 彼らはクローズドソースな開発における問題への対応は慣れていたかもしれません。 でもそれだけではだめだったのです。

一番よくある間違いは、オープンソース自体で一儲けしようと非現実的な期待をしてしまうことです。 オープンソースにしたからといって、必ずボランティアの開発者が集結してくれるとは限りません。 また、すでに問題を抱えているプロジェクトをオープンソースにしたところで、 その問題が自然に解決するわけでもありません。 実際のところ、まったく正反対になります。オープンソースプロジェクトをはじめると、 これまで自分たちだけでやっていたときと比べて いろいろ複雑なことを考えなければならなくなります。 また、短期的には 費用もかさむ ことでしょう。 オープンにするということは、見知らぬ他人が読んでもわかりやすくなるようなコードを書くということです。 また開発者用のウェブサイトやメーリングリストを整備したりする必要もありますし、 最低限のドキュメントも書くことになるでしょう。 これらはどれも大変な作業です。 仮にどこかの開発者が「手伝ってあげようか？」と声をかけてきたとしましょう。 まだその人がどれほど協力してくれそうかわからない時点でも、 その人に対してプロジェクトについての説明をしたり質問に答えたりといった作業をすることになります。 Jamie Zawinski は、Mozilla プロジェクトの初期に発生した問題について次のように述べています。

それに関連する間違いとしては、見栄えの調整やパッケージ作成に手を抜くというものがあります。 「そんなのいつでもできるし、もうちょっとプロジェクトが落ち着いてからでいいよ」 というような考えです。 見栄えの調整やパッケージ作成といってもいろいろな内容が含まれますが、 どれも結局はプロジェクトへの参入障壁を下げることにかかわってきます。 新参者がプロジェクトに参加しやすくするには、 ユーザー向けドキュメントや開発者向けドキュメントを整備したり ウェブサイトを開いて初心者向け情報を掲載したり ソフトウェアのコンパイルやインストールをできるだけお手軽に行えるようにしたりといった作業が必要となります。 残念ながら、世の多くのプログラマーは これらの作業を二の次にしてコードだけに注力しがちです。 理由はいくつかあります。 まず、それが彼らにとってあまり重要な作業ではないということです。 それが役に立つのはこれまでプロジェクトにほとんどかかわってこなかった人たちであり、 今までプロジェクトに参加してきた人たちにとってはあまり意味のない作業だと感じられることでしょう。 結局のところ、実際にコードを書いている人にとってはパッケージなんて不要なのです。 彼らはそのインストール方法も管理方法も熟知しています。 だって自分自身でそれを書いているんですから。 次に、見栄えをよくしたり使いやすくパッケージ化したりするのに必要なスキルは、 コードを書くスキルとはまったく異なるものだということです。 人はみな、自分の得意なところに力を入れたがるものです。 苦手なことにちょっと取り組むだけでプロジェクトがよりよいものになるかもしれないとしても。 2章さあ始めましょう では、 見栄えをよくしたりパッケージを作成したりする方法について詳しく説明します。 そして、それをプロジェクトの最初期から行うべきである理由についても説明します。

次によくある誤解は「オープンソースではプロジェクト管理にあまり気を使わなくていい」 とか、逆に「社内開発の場合と同じようにプロジェクト管理をしておけば、 オープンソースプロジェクトも問題なく動くだろう」というものです。 オープンソースプロジェクトにおいてはプロジェクト管理があまり表に出ることはありません。 しかし、成功しているプロジェクトの舞台裏では、何らかのプロジェクト管理が行われています。 なぜ？理由を説明するため、ここでちょっとした思考実験をしてみましょう。 オープンソースプロジェクトに参加するプログラマーは、いろいろな意味でバラバラです —よく知られているように、一匹狼的な人種です—彼らはお互いに顔をあわせることもなく、 そのプロジェクトで何を達成したいのかという目標も個々に異なります。 このような集団で、何も管理をしなかったらどんなことになるでしょうか？ 奇跡でも起こらない限り、すぐにバラバラになってしまうか明後日の方向に向かってしまうことでしょう。 私たちが思っているほど物事はうまく進みません。 それでは、いったい何を管理すべきなのでしょうか。 管理はおおっぴらにやるものではなく、 非公式に控えめに行うことになるでしょう。 開発者たちを結びつける唯一の理由は、 個別にやるよりも協調したほうがよりよいものができるという共通認識です。 したがって、管理者の目標は、開発者たちがこの考えを信じ続けられるようにすることとなります。 そのためには、標準的なコミュニケーション手段を定めることが大切です。 また、有能な開発者が「周りと違う」というだけで仲間はずれにされることのないように注意が必要です。 要するに、開発者たちにとって「またここに戻ってきたい」と思わせるようにしようということです。 そのための具体的なテクニックについて、本書でこれから説明していきます。

最後に「文化的な導き方の失敗 (failures of cultural navigation)」 と言われる一般的な問題について説明しましょう。 ほんの10年前くらいまで、いや５年前くらいまでは、 フリーソフトウェア文化について語るだなんて時期尚早だといわれていました。 でも今はもう違います。 徐々にフリーソフトウェア文化が目に付くようになってきました。 確かにそれは一枚岩のものではありません— 少なくともごく普通の文化と同様に意見の相違や派閥争いなどが起こりがちです —が、コアとなる部分は一貫しています。 うまくいっているオープンソースプロジェクトの大半は、 このコアとなる考えかたの一部あるいはすべてを持ち備えています。 彼らはよい振る舞いに対しては賞賛し、そうでないものについては非難します。 彼らは誰でもプロジェクトに参加しやすくなるような雰囲気作りを心がけています。 たとえ時にはそれが現在のメンバー間の連携を乱すことになったとしても。 彼らは何が失礼で何がそうでないのかをきちんとわかっています。 その基準は他の文化におけるものとは大きく異なっているかもしれません。 最も重要なのは、長年そのプロジェクトに参加している人たちがこれらの考えを身に着けており、 プロジェクトがどうあるべきかという指針を大雑把につかんでいることです。 うまくいっていないプロジェクトはたいてい、無意識のうちにこの基本から逸脱しています。 また、デフォルトの振る舞いがどうあるべきかという共通認識を持っていないことが多いです。 こうなると、いざ何か問題が起こったときに状態が急速に悪化してしまうようになります。 争いを解決するためのよりどころとなるべき確立された文化的行動様式を参加者が持ち合わせていないからです。

本書は実用的なガイドブックであり、 人類学や歴史学を扱う学術書ではありません。 しかし、こんにちのフリーソフトウェア文化の始まった背景についての 基本的な知識を身に着けておくと、本書での実用的なアドバイスがよりわかりやすくなるでしょう。 背景となる文化を知っておくと、オープンソースの世界をより広く深く歩き回れるようになります。 プロジェクトによっては独特の習慣や方言があったりするでしょうが、 そんな場合も気にせずに仲間入りできるようになるでしょう。 反対に、そのような背景を知らない人は、 プロジェクトを作成したりプロジェクトに参加したりする手続きを見て 非常に難しくてびっくりすることばかりだと感じられるでしょう。 フリーソフトウェアの開発にかかわる人は依然として飛躍的に増えつづけています。 したがって、後者に属する人 (つまり背景を知らない人) がたくさんいるのです。 つまり、主として新しい移民による文化だということです。 この傾向はもうしばらくは続くことでしょう。 もし自分も「背景を知らない人」のひとりだと思われるなら、 ぜひ次のセクションを読んでください。ここでは、 今後本書やインターネット上で登場することになる さまざまな議論の背景について説明しています (一方、すでにオープンソースの世界での活動経験があり、 その歴史についてもよく知っているという方は、 次のセクションは読み飛ばしていただいてけっこうです)。