“優しい独裁者”はこんな仕事に追われている：オープンソースソフトウェアの育て方（1/2 ページ）

オープンソースプロジェクトの世界では「優しい独裁者」と呼ばれる存在がプロジェクトを成功に導いているケースがたびたび見られます。では、彼らはどんな方法でプロジェクトを運営しているのでしょうか。優しい独裁者の特性を考えます。

[Karl Fogel， ]

　フリーソフトウェアについて人々がよくする最初の質問は、「プロジェクトはどういう仕組みで動くの？」「プロジェクトを維持しているものは何？」「誰に決定権があるの？」といったものです。わたしは、実力主義や、協力の精神、読めば何をやっているか分かるコード、などについて当たり障りなく答え、いつも釈然としない思いがします。

　実のところ、こうした質問に答えるのは簡単ではありません。実力主義、協力、そして動くコードはすべて答えの一部ではありますが、日々の単位でプロジェクトがどう動いているかについてほとんど説明していませんし、プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。

　ここからは、成功しているオープンソースプロジェクトに共通している、基本的な仕組みを説明します。“成功している”というのは、ただ技術的に質が高いだけでなく、プロジェクトが健全に運営され、生き残る力が強いことを指します。新しいコードや開発者を受け入れたり、バグリポートに素早く反応することを継続できていれば、プロジェクトは健全に運営されているといえます。

　特定の個人やスポンサーに依存しなくてもプロジェクトを続けられれば、生き残る力が強いといえます――プロジェクトを立ち上げたメンバー全員がほかに移ったとしても、プロジェクトが生き残る可能性があるかを考えてみてください。技術的に成功することは難しくありません。しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、プロジェクトが初期段階で成功して膨張したり、カリスマ的な人がいなくなったときに、対応できないかもしれません。

　オープンソースプロジェクトを成功させる方法はたくさんあります。議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、新しい機能を企画するなどの、型にはまった統治の仕組みもあれば、形になって表れないものとして、メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、より意識的に自制することも含まれます。

　プロジェクトは、参加する人たちがよく理解している習慣や手続きに支えられて存続するという意味で、どちらも行き着くところは同じです。これらの方法は、中央集権的なプロジェクトより、自発的に成長するプロジェクトで重要になります。自発的に成長するプロジェクトでは、少なくともしばらくは、よくないことが全体に影響することを参加する人が意識しているからです。

プロジェクトが分裂する可能性

　開発者をフリーソフトウェアプロジェクトにつなぎ止め、必要なときに妥協してもらうのに不可欠な要素は、コードが派生することです。つまり、誰かがソースコードのコピーを使って、新しい競合プロジェクトを立ち上げることです。これはフォークという用語でも知られています。逆説的なのは、プロジェクトが分裂する可能性の方が、まれながら実際に分裂することよりも、フリーソフトウェアプロジェクトにとって大きな力になるということです。

　プロジェクトが分裂することは万人にとってよくないことなので（詳細な理由は、章8.ボランティアの管理のプロジェクトの分裂項で述べています）、その恐れが大きくなればなるほど、人々はそれを避けようとして妥協する可能性が大きくなります。

　プロジェクトが分裂すること、いやむしろその可能性といった方がよいでしょう。この可能性こそ、フリーソフトウェアプロジェクトに本当の意味での独裁者が存在しない理由です。これはオープンソースプロジェクトで“独裁者”とか“暴君”と呼ばれる人がいるとよく聞くことを思えば、とっぴな主張かもしれません。

　しかし、この手の「暴政」という言葉は特別なもので、伝統的に理解されている暴政の意味とは異なります。いつでも自分の王国をコピーでき、いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振る舞いをするでしょうか？　するはずがないですよね。

　そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、重要な決定をする段になると民主主義の仕組みを使います。コードを複製できるということは、それを使って競合プロジェクトを立ち上げ、プロジェクトを分裂させられるということです。プロジェクトが分裂させられるということは、それを避けるために合意が形成されることを意味します。全員が1人のリーダーに従うこと（最も有名な例が、Linuxカーネル開発のリーナス・トーバルズです）もあるかもしれませんが、これは完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを選んでいるからです。独裁者がプロジェクトを魔法のように支配しているわけではないのです。

　すべてのオープンソースライセンスに当てはまる、鍵となる性質は、コードの変更の仕方や使用方法について、特定の集団を差別しないことです。仮に独裁者が突然よくない決断をし始めたとしましょう。その場合不穏な空気が漂い、結局反乱が起きてプロジェクトが分裂します。もちろん、そこまでひどくなることはめったにありません。そうなる前に独裁者の方が譲歩するでしょうから。

　しかし、プロジェクトが分裂することがプロジェクトで権力を行使することに歯止めをかけているからといって、プロジェクトを統率するやり方に重大な違いがあるわけではありません。決断をするたびに、「競合プロジェクトを立ち上げようと思ってる人いる？」と質問したくはないはずです。そんなことをすればすぐに疲弊し、仕事をする活力が失われていきます。

　これ以降のセクションでは、ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。そこでは2つ例を挙げていますが、いささか極度に理想的なものです。多くのプロジェクトは、2つの状態の間のどこかに位置しているのです。