3.17 冲突及其化解

我们已经看到，在项目内部，日益复杂的角色分工体现为设计权威和部分产权的分配。虽然这是一种有效的激励分配方式，但它也稀释了项目负责人的权威——尤其是削弱其压制潜在冲突的能力。

尽管围绕设计的技术争论看似最易引发内部冲突，但它们很少成为交火的真正原因。这类争论通常相对容易通过前文“权威跟着责任走”的领地归属规则（territorial rule）来解决。

解决冲突的另一种方式是依据贡献资历（seniority）——如果两位或两组贡献者之间发生争议，且争议无法客观解决，同时任何一方都不拥有争议所涉领地的产权，那么对项目整体投入最多的一方（即在整个项目中拥有最多产权的一方）获胜。

（等价地，投入最少的一方落败。有趣的是，这与许多关系型数据库引擎用于解决死锁的启发式方法恰好相同。当两个线程因资源发生死锁时，投入当前事务较少的一方会被选为死锁牺牲者并终止执行。这种策略通常让运行时间最长的事务，也就是资历更深的一方胜出。）

这些规则通常足以解决大多数项目争议。当它们不起作用时，项目负责人拍板定夺通常也能够解决。两类规则都无法摆平的争议则十分少见。

通常，冲突不会变得严重，除非以下两个标准（“权威跟随责任”和“资历深厚者胜”）指向不同的方向，并且项目负责人的权威薄弱或缺失。这种情况最可能发生的明显案例，是项目负责人消失后出现的继任权之争。我曾亲身经历过一次这样的争斗。它丑陋、痛苦、旷日持久，直到所有当事方都精疲力竭、同意将控制权交给外部人士才得以解决，我由衷希望自己再也不要卷入类似的事情。

归根结底，所有这些冲突解决机制，都有赖于全体黑客社群执行它们的意愿。可用的执行机制只有两种：公开抨击（flaming）和社群孤立（shunning）——即公开谴责那些破坏惯例的人，并拒绝与其合作。