オープンソース・ソフトをめぐる紛争の理由としては、次の４つの大きな問題を指摘できる：

• だれがプロジェクトについて決定力のある決断をくだすのか？
• だれがなにについて、評価や非難を受けるのか？
• 二度手間をさけて、非公式版がでてバグ追跡をややこしくするのを止めるにはどうするか？
• 技術的に見たら、なにが正しいことだったのか？

　でもこの「技術的な正しさ」という点についてよく考えてみると、 これは問題にはならない。この手の問題には必ず、万人が納得する客観的な 決定方法があるか、あるいはないかのどっちかだからだ。もしそれがあれば、 話はそこでおしまいでみんな勝つ。もしないのなら、それは「だれが決めるんだ？」 という話に還元される。

　同じように、紛争解決理論がプロジェクトについて解決しなくてはならない 三つの問題は (A) 設計上の決断を下すときに最終的な采配を下すのはだれか、(B) どの貢献者がどのようにクレジットされるかをどう決めるか、 (C) プロジェクトグループやその成果物が複数に枝分かれして分裂するのをどう防ぐか、 となる。

　問題 (A) と (C) の解決のために所有権慣習の果たす役割ははっきりしている。 習慣により、プロジェクトの所有者こそが方向を左右する決定を下すことが 認められる。そしてプロジェクト分裂による勢力の希薄化に対しては、 慣習が強い圧力をかけることはこれまで見た通り。

　ここで、評判ゲームは忘れてこれをハッカー文化についての純粋な「職人気質」 モデルから見た場合にも、こうした慣習は筋が通っていることは認識しておくと いいだろう。この見方では、こうした慣習は評判インセンティブの希薄化よりは むしろ、職人が自分のビジョンを自分の選ぶ形で実行するという職人の権利を 守ることを重視していることになる。

　職人モデルは、問題 (B)「だれがなにについてクレジットを与えられるか」 についてのハッカー慣習を説明するには十分ではない（だって、純粋な職人は 評判ゲームなんか気にしないから、そんなことを気にする動機がない）。 これを分析するには、ロック理論をもう一歩進めて、所有権上の抗争や運用が どう行われているかをプロジェクト同士だけでなく、 プロジェクト内部から見てやらなくてはならない。