これまで見てきたのは、プロジェクト内部では役割がますます複雑化し、 それがデザイン決定権の配分と部分的な所有権によって表現されるということだった。 これはインセンティブを配分する効率のよい方法だけれど、 プロジェクトリーダーの権威を弱めるものでもある —— いちばん大事な点として、 リーダーが紛争をおさえこむための権威を弱めてしまうんだ。

　設計にかかわる技術的な論争こそが、一見すると血を見るような争いにいたる 一番の原因になりそうだと思うかもしれないけれど、でもこれは深刻な もめごとの原因にはめったにならない。こういうのは、権威は責任に伴うという なわばりのルールによってそこそこ簡単に解決がつく。

　紛争解決手段としてもう一つあるのは、序列によるものだ —— もし貢献者二人、または貢献者集団二つが争いを始めて、それが客観的に 解決できず、どちらもその争いのなわばりを所有はしていないとき、 そのプロジェクト全体につぎ込んだ作業量の多いほう （つまり、プロジェクト全体の中で地役権を最大に持つ側）が勝つ。

　（同じように、投入したものが少ない方が負ける。おもしろいことに、 これは多くのリレーショナルデータベース・エンジンが、デッドロックを 解決するヒューリスティクとまったく同じだ。二つのスレッドが、 あるリソースをめぐってデッドロックになったら、現在のトランザクションに 投入したものがいちばん少ないほうが、デッドロックの犠牲者として選ばれて、 終了させられる。これはつまり通常は、いちばん長く走っているトランザクション、 あるいはいちばんｈじょういのトランザクションが、勝者となるということだ。）

　こういうルールだけで、ほとんどのプロジェクト上の争いを解決するには十分だ。 十分でない場合にも、リーダの采配でだいたいなんとかなる。 この二重のフィルタを越えるほどの紛争はほとんどない。

　紛争は原則的に、こうした二つの基準（「権威は責任にともなう」 「序列の高いほうが勝つ」）が矛盾する結果を出して、しかも そのプロジェクトリーダの権利が弱かったり不在だったりするときにしか 生き延びない。これが起きるいちばんはっきりした例は、プロジェクトの リーダが消えたあとで、その後継をめぐる争いだ。ぼくは一度、この種の争いに 加わっていたことがある。みにくくて苦痛で、長引いて、最終的に解決されたのも、 関係者がみんな疲れ切って、コントロールを外部の人に任せようと決めたから 可能になった。もう二度とあの種のものには近づかずにすみますように、 と心から願わずにはいられない。

　最終的には、こういう紛争解決メカニズムは、ハッカーコミュニティが それを強制しようという意志をもっているかどうかにかかってくる。そして 唯一の強制メカニズムは、フレーミングと黙殺だ —— 慣習を破る者たちに対する公開糾弾と、破った者たちとは もう協力しないということだ。