目次
フリーソフトウェアについて人々がよくする最初の質問は、 "プロジェクトはどういう仕組みで動くの？ プロジェクトを維持しているものは何？ 誰に決定権があるの？" といったものです。 私は、実力主義や、協力の精神、読めば何をやっているかわかるコード、 などについて当たり障りなく答えて、 いつも釈然としない思いがします。 実のところ、こうした質問に答えるのは簡単ではありません。 実力主義、協力、そして動くコードは全て答えの一部ではありますが、 日々の単位でプロジェクトがどう動いているかについて殆ど説明していませんし、 プロジェクト内で起こる衝突をどうやって解決するのかについては何も触れていません。
この章では、成功しているオープンソースプロジェクトに共通している、 基本的な仕組みを説明します。 "成功している" というのは、ただ技術的に質が高いだけでなく、 プロジェクトが健全に運営されており、生き残る力が強いことを言います。 新しいコードや開発者を受け入れたり、 バグレポートに素早く反応することを継続できていれば、 プロジェクトは健全に運営されているといえます。 特定の個人やスポンサーに依存しなくてもプロジェクトを続けられれば、 生き残る力が強いといえます。 — プロジェクトを立ち上げたメンバー全員が他に移ったとしても、 プロジェクトが生き残る可能性があるかを考えてみてください。 [24] 技術的に成功することは難しくありません。 しかし開発者の層が薄かったり、社会的な基盤が弱かったりすると、 プロジェクトが初期段階で成功して膨張したり、 カリスマ的な人がいなくなったときに、対応できないかもしれません。
オープンソースプロジェクトを成功させる方法はたくさんあります。 議論をまとめたり、新しい開発者を勧誘したり（時には追い出したり）、 新しい機能を企画するなどの、 型にはまった統治の仕組みもあれば、 形になって表れないものとして、 メンバーが信頼し、事実上プロジェクトを支配する公平な雰囲気を作り出すために、 より意識的に自制することも含まれます。 プロジェクトは、 参加する人達がよく理解している習慣や手続きに支えられて存続するという意味で、 どちらも行き着くところは同じです。 これらの方法は、中央集権的なプロジェクトより、 自発的に成長するプロジェクトで重要になります。 自発的に成長するプロジェクトでは、少なくともしばらくは、 よくないことが全体に影響することを参加する人が意識しているからです。
開発者をフリーソフトウェアプロジェクトに繋ぎ止め、 必要な時に妥協してもらうのに不可欠な要素は、 コードが 派生する ことです。つまり、 誰かがソースコードのコピーを使って、 新しい競合プロジェクトを立ち上げることです。これは フォーク という用語でも知られています。 逆説的なのは、プロジェクトが分裂する 可能性 の方が、 まれながら実際に分裂することよりも、 フリーソフトウェアプロジェクトにとって大きな力になるということです。 プロジェクトが分裂することは万人にとってよくないことなので、 (詳細な理由は、8章ボランティアの管理 の 「プロジェクトの分裂」 で述べています。) その恐れが大きくなればなるほど、 人々はそれを避けようとして妥協する可能性が大きくなります。
プロジェクトが分裂すること、いやむしろその可能性と言った方がよいでしょう。 この可能性こそが、フリーソフトウェアプロジェクトに本当の意味での独裁者が存在しない理由になっています。 これはオープンソースプロジェクトで "独裁者" とか "暴君" と呼ばれる人がいるとよく聞くことを思えば、突飛な主張かもしれません。 しかし、この手の "暴政" という言葉は特別なもので、伝統的に理解されている暴政の意味とは違うものです。 いつでも自分の王国をコピーでき、 いいように支配するためにそのコピーを持ち歩ける家来がいる王様を想像してみてください。 そんな王様が、自分が何をしようと家来が自分の支配下にいると決まっている王様と同じ振舞いをするでしょうか？ するはずがないですよね。
そんなわけで、民主主義に従って組織化されていないプロジェクトでさえ、 重要な決定をする段になると民主主義の仕組みを使います。 コードを複製できるということは、それを使って競合プロジェクトを立ち上げ、プロジェクトを分裂させられるということです。 プロジェクトが分裂させられるということは、 それを避けるために合意が形成されることを意味しています。 全員がひとりのリーダーに従うこと（もっとも有名な例が、Linux kernel 開発の Linus Torvalds です）もあるかもしれませんが、 これは 完全にひねくれているわけでもなく、悪意があるわけでもなく、彼らがそうすることを 選んでいる からです。 独裁者がプロジェクトを魔法のように支配しているわけではないのです。 全てのオープンソースライセンスに当てはまる、鍵となる性質は、 コードの変更のしかたや、使用方法について、特定の集団を差別しないということです。 仮に独裁者が突然よくない決断をしはじめたとしましょう。 その場合不穏な空気が漂い、結局反乱が起きてプロジェクトが分裂してしまいます。 もちろん、そこまでひどくなることは滅多にありません。 そうなる前に独裁者のほうが譲歩するでしょうから。
しかし、 プロジェクトが分裂することがプロジェクトで権力を行使することに歯止めをかけているからといって、 プロジェクトを統率するやり方に重大な違いがあるわけではありません。 決断をするたびに、競合プロジェクトを立ち上げようと思ってる人いる？ と質問したくはないはずです。 そんなことをすればすぐに疲れてしまい、仕事をする活力が失われていきます。 次のふたつのセクションでは、 ほとんどの決断を円滑に行えるようにプロジェクトを統率する方法を調べていきます。 そこではふたつ例をあげていますが、いささか極度に理想的なものです。 多くのプロジェクトは、ふたつの状態の間のどこかに位置しているのです。
優しい独裁者(Benevolent Dictator) モデルとは、 正確には次のようなものです。 つまり、最終的な決断を行う権限が、 人格や経験が優れているという理由で、 賢明に権限を行使できるひとりの人に委ねられていることです。
"優しい独裁者" （略して BD ともいいます）という言葉は、 こうした役割に対して標準的に使われる用語ですが、 むしろ "コミュニティーが認めた調停者" もしくは "審判" と考えた方がいいでしょう。 一般的には、優しい独裁者が実際に全ての、 もしくはほとんどの決定を行っているわけではありません。 ある人がプロジェクトの全ての領域に渡って、 優れた決断を一貫して行う十分な技能があることはまれです。 そして優れた開発者は、プロジェクトの方向性に影響を与えられなければ、 結局プロジェクトから去ってしまいます。 よって、優しい独裁者は普通多く指示を出したりはしません。 むしろいつでも可能な限り、議論や実験を行う作業を開発者に任せておきます。 優しい独裁者は議論そのものには参加しますが、普通の開発者として、 自分より優れた技能を持つメンテナーの領域では、たびたび彼らに従います。 結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に 望んでいる 場合だけ、 彼らは敢えて異を唱えてこういうのです。「これがあるべき方向性だ」と。 命令することで決定するのを我慢するのは、 成功している優しい独裁者に事実上共通する特性です。 これが、彼らが優しい独裁者という役割を維持している理由のひとつなのです。
優しい独裁者になるには複数の特性が必要です。 まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、 これは言い替えれば自制を働かせるということです。 議論の最初の段階では、 自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。 人々には、たとえ馬鹿げたアイディアであっても自由に述べさせなければいけません。 もちろん、優しい独裁者であっても必ず愚かな考えを述べることがあります。 だから、自分が悪い決断を下したときに、それを認識し、 受け入れる能力も必要になるのです。— ですが、この資質は優れた開発者であれば、 特にプロジェクトに長い間留まっている人であればなおさら 誰でも 持っているはずの資質にすぎません。 しかし、優しい独裁者が違うのは、 自分の信頼に長い間傷が付いてしまうんじゃないかと恐れることなく、 たびたび間違いを犯す余裕があることです。 年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。 だからこそ優しい独裁者は、 技術的な面でも精神的な面でも、自分の言葉が伝える重みに敏感になって、 批判をしたり反対意見を述べるべきなのです。
優しい独裁者は、 プロジェクトにいる誰よりも技術的なスキルが優れている必要は ありません。 コードを書く能力に十分優れ、 コードに加えられたあらゆる変更を理解し、 思いやりをもってそれにコメントしなければいけませんが、それだけです。 優しい独裁者の立場は、誰かから教わって得たものではありませんし、 コードを書くスキルが恐ろしくあるという理由で得たものでもありません。 重要なのは 経験と総合的な設計センスです。— 必要に応じて優れた設計を生み出す能力ではなく、 優れた設計をソースコードから認識する能力なのです。
優しい独裁者は、プロジェクトの創始者であることが普通です。 しかし創始者であることは、優しい独裁者となる原因以上の相関関係はありません。 正確にいうと、プロジェクトをうまく始められる資質 — 技術的なスキル、 他の人をプロジェクトに参加するよう説得できること、などなど — が、優しい独裁者になるのに必要な資質です。 そしてもちろん、創始者は自動的にプロジェクトの古株としてスタートするので、 そのことで優しい独裁者への道が殆ど抵抗なしに開かれることは往々にしてあり得ます。
プロジェクトが分裂する可能性が二つあることを忘れないでください。 優しい独裁者は他の人と同様、容易にプロジェクトを分裂させられますし、 大多数の開発者が望んでいるプロジェクトの方向性が、 自分が望むものと違っていると感じたときは、 時折優しい独裁者以外の人もそうすることがあります。 コードはコピーできるので、 優しい独裁者がプロジェクトのメインサーバの root 権限（システム管理者の権限）を持っているかどうかは問題になりません。 人によっては、サーバの管理権限を持っていることがプロジェクトの最終的な権限の源であるかのように話すひとがいますが、実際は無関係です。 ある特定のサーバで開発者のコミットパスワードを追加したり、削除したりできる権限は、 そのサーバにあるプロジェクトのコピーにのみ影響します。 そうした権限に関する苦情が、優しい独裁者や他の開発者かどうかに関係なく長期間続くと、 単に開発が他のサーバに移っていくだけです。
プロジェクトに優しい独裁者がいる方がうまくいくか、 中央集権をいくらか緩めた仕組みの方がうまくいくかは、 役割を果たす人達がどれだけいるかにかかっています。 一般的なルールとして、優しい独裁者に誰がなってもいいことが明らかな場合は、 そうするとよいでしょう。しかし、誰もなり手がいないのが明らかな場合は、 次のセクションで述べる分権的な決定プロセスを使うべきでしょう。
[24] バス係数 という用語が知られています。これは、(たとえて言うと)どれくらいの人がバスに轢かれたらプロジェクトが破綻するかを示す数です。 https://en.wikipedia.org/wiki/Bus_factor も参照してください