合意と投票で構築されるOSS開発の社会構造：オープンソースソフトウェアの育て方（1/4 ページ）

プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、より開かれた民主主義的なプロセスに移行します。これはグループ主体の統治の方が、“進化的に安定している”からです。このプロセスに移行すると、グループはほとんどいつも合意に基づいて動き、合意に達しないときは投票の仕組みを用いるようになります。

[Karl Fogel， ]

合意に基づく民主主義

　プロジェクトが続いていくと、プロジェクトは優しい独裁者モデルから離れ、より開かれた民主主義的なプロセスに移行します。これは特定の優しい独裁者に必ずしも満足していないからではありません。単にグループ主体の統治の方が、生物学のメタファーを借りて言えば“進化的に安定している”からです。

　優しい独裁者が身を引いたり、決定する権限を多くの人に平等に与えようとするときはいつでも、グループが新しい、独裁的でない仕組みに移行する機会になります――これは言ってみれば組織化を行うということです。開発者のグループは最初の1、2回はこの機会を利用しませんが、結局は利用することになります。

　いったんそうしてしまえば、元の仕組みに戻ることはありません。何故かは常識で分かることです。仮にN人からなるグループが、ある人に特別な権限を与えていると仮定すると、N-1人が自分の影響力を弱めることに合意していることになります。独裁的でない仕組みでは、普通特別な権限を特定の人に与えたいとは思いません。たとえ望んだとしても、結果として行使できる権力は条件付きのものになります。優しい独裁者を任命しても、これは明らかなことですが、グループが後に辞めさせてしまうことができるからです。それ故に、プロジェクトがいったんカリスマ的な人のリーダーシップを取る仕組みから、より型にはまったグループベースの仕組みに移行すれば、めったに元に戻ることはないのです。

　こうした仕組みがどう機能するかを詳細に見ていくと、中身は変化に富んでいますが、共通した要素が2つあります。1つは、グループはほとんどいつも合意に基づいて動くこと。2つ目は、合意に達しないときに投票の仕組みを使うことです。

　合意とは、皆が受け入れようと一致することです。これはあいまいな状態ではありません。誰かが合意に達したんじゃないかと提案し、それに対して誰も反対を表明しない場合、あるグループは合意に達したといえます。合意に達したんじゃないかと提案する人は、合意とは何かということと、仮に明らかでない場合は、合意の結果どのような行動を取るのかを具体的に述べるべきです。

　プロジェクトで交わされるほとんどの会話は技術的な話題です。例えば、正しくバグを直す方法とか、ある機能を追加するか、しないか、プログラムのインタフェースをどの程度厳密に文書化するか、などです。合意を基本とした統治は、技術的な議論そのものとよく合うのでうまくいきます。議論が終わるまでに、どの方向性を取るかについて合意がよく成立します。通常は議論を終了するという投稿をし、同時に何が決まるのかをまとめた上で、合意に達したよねと暗に提案します。これが「待った！　俺は反対だ。もう少し徹底的に話し合う必要があるね」といえる最後の機会を与えているのです。

　規模が小さく、議論に値しない事柄を決めるときは、合意に達したという提案も暗黙に行われます。例えば、開発者がバグ修正を自発的にコミットした場合、そのコミット自体が合意に達したことを提案することになります。つまり、「このバグは直す必要があり、この修正が正しいやり方だと皆が合意したと見なすよ」といっているのです。もちろん、開発者は実際にそんなことを言っていません。彼はただ修正をコミットしただけですし、ほかの開発者はわざわざ同意すると口に出して言ったりしません。なぜなら黙っていることは合意することだからです。コミットされた修正が、合意を得られないと判明した場合、プロジェクトではそれがまだコミットされていないかのように議論されます。このやり方がうまく行く理由は次のセクションで述べていきます。

バージョン管理を行うと堅くならずに済む

　プロジェクトのソースコードがバージョン管理されているということは、ほとんどの決定が元に戻せることを意味します。変更を元に戻す原因としてよくあるのが、皆にとって良いものだと間違って思い込み、変更をコミットするというものですが、これは結局コミットした後に反対意見が出てくることになります。

　こうした反対意見は決まって、以前の議論を見逃したことをわびることから始まりますが、反対する人がメーリングリストのアーカイブにこれに当たる議論を見つけられなかった場合は省略されます。どちらにせよ、変更がコミットされる前と後とで議論の口調を変える理由はありません。少なくとも、あるコミットに依存する変更が行われた時点（i.e.もともと加えられていた変更が突然削除され、新しい変更がそれを壊していた場合）まで、変更は取り消すことができます。

　バージョン管理システムは、プロジェクトにとってよくない、または性急な判断から生じた結果を元に戻す手段を与えているのです。言い換えれば、開発者が何かをする前にどのくらいのフィードバックが必要かということを、自分の直感を信頼して判断してよい、ということでもあります。

　このことは、合意を得る手続きを型にはめる必要がないということでもあります。ほとんどのプロジェクトはこの手続きを感覚で扱っています。小さな変更は、議論をしないか、最小限の議論だけして、2、3の賛成があった後に行われます。より重要な変更、特に多くのコードを不安定にさせる変更は、開発者たちは合意に達した、つまり単にメールを頻繁にチェックしていなかっただけの理由で重要な議論をないがしろにしたヤツはいないはずだ、という合理的な根拠があると見なす前に、1日か2日の間を置くべきです。

　というわけで、自分がやるべきことを理解しているのなら、単に作業を進めてやり遂げるべきです。これはソフトウェアの修正だけでなく、Webサイトの更新、ドキュメントの変更、そして議論になりそうにないほかのあらゆることに当てはまります。通常、取られたアクションを元に戻す必要がある事例はわずかですし、そうした事例はケースバイケースで扱えます。

　もちろん、聞く耳を持たないことを奨励すべきではありません。議論中の事項と、既に実行されて効果が表れている決定事項の間には、いくら技術的に元に戻せるとはいっても精神的な差があります。開発者たちは勢いが行動につながるといつも思っていますし、実際に行われた変更を元に戻すのは、はじめに変更するのをやめさせるほど、気が進まないものです。ある開発者がこの事実を悪用し、議論が必要かもしれない変更を急いでコミットする場合、ほかの開発者たちは文句を言えますし、言うべきです。そして事態が好転するまで、より厳しい基準をその開発者に守らせるべきでしょう。