プロジェクトをバス問題から守るためにできることで一番大切なのは、強力な開発者コミュニティをプロジェクトに呼び込むことだ。普通、オープンソースの開発者は最初にユーザとしてプロジェクトに関わるので、まずはプロジェクトにユーザを呼び込む必要がある。そのためには、人々に使ってみたいと思わせるほどのものを作り上げ、ユーザからのフィードバックに注意深く耳を傾けなければならない。今日のユーザは明日のリリースマネージャかもしれないのだ。
では、人々がぜひ使いたいと思うものを作り出すことから始めるとしよう。ある特定の問題に対処するためのプロジェクトを作れば、数名の協力者が集まるかもしれないが、実際に人々が使えるものに仕上げなければ、最初のバージョンが出たきり活動が縮小し、消滅することになるだろう。作り上げた成果物に対して自分自身が強い関心を持っている場合に限り、プロジェクトは存続できる。
人々（主に自分自身）が使いたいと思うものを日頃から手がけていれば、プロジェクトの周りにはユーザや開発者のコミュニティが形成され、人々は不具合の修正や新たな提案をしてくれるようになる。こうしたユーザをプロジェクトにつなぎ留めておきたければ、プロジェクトの活動を適切な状態で続けていく必要がある。つまり、不具合報告を入念に調べてバグを修正しつつ、新しい機能に取り組んでいかなければならないのだ。ユーザの技術的なレベルには関係なく、たいていはユーザとメンバーとでプロジェクトのとらえ方が異なっているので、ユーザからのバグ報告や機能要求を理解するには十分な対話が必要になる可能性がある。ユーザからのフィードバックを開発者が納得できる形に変換するために多大な手間を要することもある。しかし、ユーザの声に耳を傾け、ユーザから報告されたバグを修正し、ユーザが要求する機能に注目することによって、ユーザはプロジェクトのソフトウェアを使い続けてくれるわけで、このようにしてユーザがプロジェクトの大いなる支持者になっていく場合も少なくない。やがてこうしたユーザが ― もうおわかりだろうが ― さらに多くのユーザを呼び寄せることになるのだ。
ここではっきりと断っておくが、私は貴重な時間のすべてを些細なバグの修正や気まぐれにユーザが要求してくる機能の実装に費やすように薦めているわけではない。しかし、プロジェクトが10～15名の開発者を擁する規模に成長するまでは、少なくともユーザからの報告や提案にしっかりと目を通していることをユーザに知らせるのが得策だろう。たとえユーザの望んでいる機能を実装できそうにないことを知らせるものであっても、そうした電子メールを返すこと（そしてその要望を忘れないように懸案事項のリストに加えること）でユーザの意見をしっかりと受け止めていることをわかってもらえるのだ。
プロジェクトに関心を持つユーザが増えるにつれ、プロジェクト周辺で構築を進めているコミュニティ内に風変わりな開発者がいることに必然的に気が付くようになる（開発者の中には一風変わった人物がいるものだ）。通常、新たなメンバー候補として期待される開発者からまず届くのが ― コードのバグであれドキュメント上の誤りであれ ― 既存の不具合（たいていは些細なもの）を修正するパッチである。開発について議論するメーリングリストにパッチを携えて現れるユーザに対しては、入念な配慮をするだけの価値がある。というのも、そうしたパッチが優れたものだとわかってそれをすぐに適用すれば、他のプロジェクトに貢献している開発者からも関心が集まるからである。オープンソースの世界では、開発者への配慮が共通の価値基準なのだ。こうしたパッチの適用をきっかけに、プロジェクトの内容とその目指す方向性をよく理解し、引き続きパッチを作成していく新規開発者がいれば、きっと独自の仕事をまかせたいと考えるようになるだろう。優れたチームメンバーになると判断してすぐにプロジェクトへのコミットアクセス権を与えれば、しばらくはプロジェクトのために貢献してくれるはずだ。
かくしてプロジェクトは、盛況なユーザのコミュニティと小規模な開発者のコミュニティの支援を受けるに至る。意のままに動かせるメンバーを配下に従え、プロジェクトリーダとしての尊敬を集め、Amazon.comのウィッシュリスト・アイテムやPayPalの寄付をメンバーから受け取る、そんな一国一城の主への夢に向かって歩み始めるわけだ。
だがちょっと待ってほしい。本当にそれでいいのだろうか。
権力をふりかざしてプロジェクトを運営しても、プロジェクトのバス問題 ― 特にプロジェクトリーダたるあなた自身のバス問題 ― は決して解決しない。
また私生活の変化は、プロジェクトの活動に割くことができる時間に大きな影響を及ぼす可能性がある。結婚するかもしれないし、子供が生まれるかもしれない。まだ就職する前なら定職に就くことになるかもしれない。万が一、プロジェクトのリーダがバスに轢かれたり（または隕石に当たったり）、重い病気にかかったり、あるいはこんなことはあってはならないが、プロジェクトに対する関心をなくしたりすることもないとは言い切れない。
そんなことにならないうちに支配権を手放すことだ。
合意による意思決定を進める開発者のコミュニティを構築すれば、不測の事態でメンバーの誰か1人が欠けても大丈夫なのはもちろん、一時的にせよ恒久的にせよ複数のメンバーがいなくなっても柔軟に対応可能なプロジェクトになる。こうしたコミュニティのおかげで、複数の開発者が（合意によってプロジェクトを推進できる限り）交代でプロジェクトを主導していくことも可能であり、開発者がプロジェクトを離れた後も時間ができれば戻って来られるので、非常に頑強な組織が出来上がる。これこそが建設的かつ息の長いオープンソースプロジェクトの特徴である。
オープンソースプロジェクトを成功に導く要素は他にも数多くあるが、強い関心の維持、ユーザの意見の重視、強力なコミュニティの構築によって、今後何年間も成長し続けるであろうプロジェクトを順調に発展させていくことができる。何よりも、ランチに向かう途中でバスを見かけるたびにおびえる必要がなくなるのだ。
謝辞：本稿の草稿に目を通してくれたKarl Fogel氏とC. Michael Pilato氏に感謝の意を表したい。
Brian W. Fitzpatrick氏はGoogleの上級ソフトウェア技術者であり、Google Codeなどのオープンソースプロジェクトに従事している。以前はCollabNetでSubversionやcvs2svn、AppleではさまざまなWebアプリケーションに携わっていた。Apache Software FoundationメンバーにしてSubversion開発者（2000年～）、そして『Version Control with Subversion（Subversionによるバージョン管理）』（O'Reilly刊）の共著者であり、多数の講演経験を持つ。
オープンソースプロジェクトを予期せぬ事態から守る方法
2006年10月11日 09:52
Brian-W.-Fitzpatrick（2006年10月5日（木））
ソフトウェアプロジェクトではバス問題 ― プロジェクトのメンバーが何人バスに轢かれたらコードベースを熟知する人間がいなくなるか ―がよく取り沙汰される。オープンソースの世界では、事前に備えをしておかなければ、開発者がたった1人いなくなるだけでプロジェクトが壊滅に陥る可能性さえあるのだ。
関連トピック
（最終更新：2007年07月01日 19:05）