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

[Karl Fogel， ]

優しい独裁者

　優しい独裁者（Benevolent Dictator）モデルとは、正確には次のようなものです。つまり、最終的な決断を行う権限が、人格や経験が優れているという理由で、賢明に権限を行使できる1人の人に委ねられていることです。

　「優しい独裁者」（略してBDともいいます）という言葉は、こうした役割に対して標準的に使われる用語ですが、むしろ「コミュニティーが認めた調停者」もしくは「審判」と考えた方がいいでしょう。一般的には、優しい独裁者が実際にすべての、もしくはほとんどの決定を行っているわけではありません。ある人がプロジェクトのすべての領域に渡って、優れた決断を一貫して行う十分な技能があることはまれです。

　そして優れた開発者は、プロジェクトの方向性に影響を与えられなければ、結局プロジェクトから去ってしまいます。よって、優しい独裁者は通常多く指示を出したりはしません。むしろいつでも可能な限り、議論や実験を行う作業を開発者に任せておきます。

　優しい独裁者は議論そのものには参加しますが、普通の開発者として、自分より優れた技能を持つメンテナーの領域では、たびたび彼らに従います。結論が出ず、ほとんどのグループが開発を続けるために誰かが判断の指針を示すことを明確に望んでいる場合だけ、彼らはあえて異を唱えてこういうのです。「これがあるべき方向性だ」と。命令することで決定するのを我慢するのは、成功している優しい独裁者に事実上共通する特性です。これが、彼らが優しい独裁者という役割を維持している理由の1つなのです。

誰がよき「優しい独裁者」になれるか？

　優しい独裁者になるには複数の特性が必要です。まず第一に、自分自身がプロジェクトに及ぼす影響について感覚を研ぎ澄ますこと、これは言い換えれば自制を働かせるということです。議論の最初の段階では、自分の意見に反対するのは的外れだと確信して意見や結論を述べてはいけません。人々には、たとえ馬鹿げたアイデアでも自由に述べさせなければいけません。もちろん、優しい独裁者であっても必ず愚かな考えを述べることがあります。だから、自分が悪い決断を下したときに、それを認識し、受け入れる能力も必要になるのです。

　――ですが、この資質は優れた開発者であれば、特にプロジェクトに長い間留まっている人であればなおさら誰でも持っているはずの資質にすぎません。しかし、優しい独裁者が違うのは、自分の信頼に長い間傷がついてしまうのではないかと恐れることなく、たびたび間違いを犯す余裕があることです。年季が入っていない開発者は、自分が保護されていないと感じているかもしれません。だからこそ優しい独裁者は、技術的な面でも精神的な面でも、自分の言葉が伝える重みに敏感になり、批判をしたり反対意見を述べるべきなのです。

　優しい独裁者は、プロジェクトにいる誰よりも技術的なスキルが優れている必要はありません。コードを書く能力に十分優れ、コードに加えられたあらゆる変更を理解し、思いやりをもってそれにコメントしなければいけませんが、それだけです。優しい独裁者の立場は、誰かから教わって得たものではありませんし、コードを書くスキルが恐ろしく備わっているという理由で得たものでもありません。重要なのは経験と総合的な設計センスです――必要に応じて優れた設計を生み出す能力ではなく、優れた設計をソースコードから認識する能力なのです。

　優しい独裁者は、プロジェクトの創始者であることが普通です。しかし創始者であることは、優しい独裁者となる原因以上の相関関係はありません。正確にいうと、プロジェクトをうまく始められる資質――技術的なスキル、ほかの人をプロジェクトに参加するよう説得できること、などなど――が、優しい独裁者になるのに必要な資質です。そしてもちろん、創始者は自動的にプロジェクトの古株としてスタートするので、そのことで優しい独裁者への道がほとんど抵抗なしに開かれることは往々にしてあり得ます。

　プロジェクトが分裂する可能性が2つあることを忘れないでください。優しい独裁者はほかの人と同様、容易にプロジェクトを分裂させられますし、大多数の開発者が望んでいるプロジェクトの方向性が、自分が望むものと違っていると感じたときは、ときおり優しい独裁者以外の人もそうすることがあります。

　コードはコピーできるので、優しい独裁者がプロジェクトのメインサーバのroot権限（システム管理者の権限）を持っているかどうかは問題になりません。サーバの管理権限を持っていることがプロジェクトの最終的な権限の源であるかのように話す人がいますが、実際は無関係です。ある特定のサーバで開発者のコミットパスワードを追加したり、削除したりできる権限は、そのサーバにあるプロジェクトのコピーにのみ影響します。そうした権限に関する苦情が、優しい独裁者やほかの開発者かどうかに関係なく長期間続くと、単に開発がほかのサーバに移っていくだけです。

　プロジェクトに優しい独裁者がいる方がうまくいくか、中央集権を幾らか緩めた仕組みの方がうまくいくかは、役割を果たす人たちがどれだけいるかにかかっています。一般的なルールとして、優しい独裁者に誰がなってもいいことが明らかな場合は、そうするとよいでしょう。しかし、誰もなり手がいないのが明らかな場合は、別に述べる分権的な決定プロセスを使うべきでしょう。

著者：Fogel Karl

翻訳者：高木 正弘

翻訳者：Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。

原文へのリンク