フリーソフトウェアプロジェクトはなぜ失敗するのか：オープンソースソフトウェアの育て方（1/2 ページ）

これからオープンソースプロジェクトを始めようと思っている、あるいは始めてはみたもののどうすればいいのか分からないソフトウェア開発者や管理者必読の本連載。オープンソースそしてフリーソフトウェアプロジェクトについて余すところなく解説します。

[Karl Fogel， ]

本連載の想定読者

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

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

　プログラミングに関する知識は必須ではありません。ただ、ソースコードやコンパイラ、パッチといったソフトウェア工学の概念の基本は知っておく必要があります。

　オープンソースソフトウェアを開発したり使用したりといった経験の有無は問いません。過去にフリーソフトウェアプロジェクトに参加した経験がある人にとっては、本連載の内容の中に「そんなの当たり前じゃん」と思われる個所が幾つも見つかることでしょう。そのように読者の経験に大きな差があるので、各セクションのタイトルはできるだけわかりやすいものにすることを心がけています。また、既によく知っている場合に読み飛ばしてもかまわない箇所についてはそれを明記しています。

フリーソフトウェアプロジェクトはなぜ失敗するのか

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

　しかし、失敗例について聞くことはあまりありません。みんなの気を引くのは成功したプロジェクトだけだからです。世の中には途方もない数のフリーソフトウェアプロジェクトが存在する*1ので、たとえ成功するプロジェクトがその中のごく一部に過ぎなかったとしても、多くのプロジェクトが成功しているように見えてしまうのです。また、いつ「プロジェクトが失敗した」と判断するのかがはっきりしないのもわたしたちが失敗について聞くことがない理由の1つでしょう。

　「そのプロジェクトが消滅した瞬間」というのを特定することはできません。参加者が少しずつほかへ移っていき、プロジェクトで作業するのをやめるだけなのです。「プロジェクトに対して最後に変更が加えられたとき」を知ることはできますが、実際にその変更を加えた人は「それがプロジェクトに対する最後のコミットとなる」とは決して思っていなかったことでしょう。また、どれぐらい動きがなければ「止まってしまった」と見なすのかについてもはっきりした定義がありません。目立った動きが半年間なかったとき？　ユーザー数の伸びが止まってしまい、結局開発者の数を超えることがなかったとき？　自分の参加しているプロジェクトが結局ほかのプロジェクトの焼き直しであることに気づいた開発者が、現在参加しているプロジェクトを捨ててもう1つの方に移動したとしましょう。そして移った先のプロジェクトをどんどん成長させていきました。この場合、元のプロジェクトは「消滅した」のでしょうか？　それとも「あるべき場所に移動しただけ」なのでしょうか？

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

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

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

　一番よくある間違いは、オープンソース自体でひともうけしようと非現実的な期待をしてしまうことです。オープンソースにしたからといって、必ずボランティアの開発者が集結してくれるとは限りません。また、すでに問題を抱えているプロジェクトをオープンソースにしたところで、その問題が自然に解決するわけでもありません。実際のところ、まったく正反対になります。オープンソースプロジェクトをはじめると、これまで自分たちだけでやっていたときと比べていろいろ複雑なことを考えなければならなくなります。また、短期的には費用もかさむことでしょう。

　オープンにするということは、見知らぬ他人が読んでも分かりやすくなるようなコードを書くということです。また開発者用のWebサイトやメーリングリストを整備したりする必要もありますし、最低限のドキュメントも書くことになるでしょう。これらはどれも大変な作業です。仮にどこかの開発者が「手伝ってあげようか？」と声をかけてきたとしましょう。まだその人がどれほど協力してくれそうか分からない時点でも、その人に対してプロジェクトについての説明をしたり質問に答えたりといった作業をすることになります。ジェイミー・ザウィンスキーは、Mozillaプロジェクトの初期に発生した問題について次のように述べています。

オープンソースはうまく働くものである。しかし、最も大切なことは、何にでも効くような特効薬ではないということだ。もし、ここに教訓があるとすれば、死にかけたプロジェクトをつかまえて、オープンソースという魔法の妖精の粉をふりかけて、すべてが魔法のようにうまく行くなどということはない、ということだ。ソフトウェアは難しい。問題はそんなに簡単なものじゃない。

（http://www.jwz.org/gruntle/nomo.htmlより引用。日本語訳はこちら）

　それに関連する間違いとしては、見栄えの調整やパッケージ作成に手を抜くというものがあります。「そんなのいつでもできるし、もう少しプロジェクトが落ち着いてからでいいよ」というような考えです。見栄えの調整やパッケージ作成といってもいろいろな内容が含まれますが、どれも結局はプロジェクトへの参入障壁を下げることにかかわってきます。新参者がプロジェクトに参加しやすくするには、ユーザー向けドキュメントや開発者向けドキュメントを整備したり、Webサイトを開いて初心者向け情報を掲載したり、ソフトウェアのコンパイルやインストールをできるだけお手軽に行えるようにしたりといった作業が必要となります。

※1　有名なホスティングサイトの1つであるSourceForge.netには、2004年4月中旬の時点で7万9225件のプロジェクトが登録されています。もちろん、これがインターネット上のフリーソフトウェアプロジェクトの総数であるというわけではありません。これは単に、その時点でSourceForgeを選択したプロジェクトの数に過ぎません。