第 13 章

裁定者的座椅

里奇·希基创造Clojure语言的时候，并没有打算建造一把椅子。这个判断需要解释。在大多数开源项目的叙事中，创建者与社区的关系是后设的——先有代码，然后有人聚集，然后才有治理结构。但Clojure的情况有所不同。希基在两年半的独自开发期间，已经做出了一系列无可撤回的设计选择：Lisp-1的命名空间、不可变数据结构、与Java平台的共生关系。

这些选择不是选项，而是前提。当2007年秋天他向Common Lisp社区的朋友们发出那封宣布新语言完成的邮件时，Clojure不仅是可运行的代码，还是一个已经完成了基本自我定义的系统。后来的社区成员可以讨论、扩展、甚至在某些边缘地带偏离这些定义，但他们无法重新打开那些最初的决定。

在这种意义上，椅子在房间被建造之前就已经在那里了。但“椅子”这个词是后来的发明。在2008年谷歌网上论坛开始热闹起来的时候，没有人谈论治理模式。

早期的邮件列表是技术性的，讨论的是宏的展开顺序、惰性序列的实现细节、与Java集合类的互操作。如果有人提出一个特性建议，希基会直接回复，解释为什么它不符合语言的设计方向。这些回复是技术论证，不是权力声明。它们引用的是不可变性的原理、简单性的优先、对宿主平台的尊重——那些在语言诞生之前就已经确立的原则。阅读那个时期的邮件，你会注意到一种特殊的气氛：争论很激烈，但很少升级为治理争议。原因很简单：原则足够清晰，以至于大多数技术讨论可以在原则的框架内自行解决。

转折发生在社区开始扩大的时候。不是某个具体的日期，而是某种质的变化。当新的使用者不再来自希基的个人网络，当他们没有参与过早期邮件列表上的判例积累，当他们带着其他语言社区的经验和期望进入Clojure——这时，相同的原则开始产生不同的理解。一个来自Ruby社区的开发者眼中的“简单性”，与一个阅读过希基所有邮件的人眼中的“简单性”，可能指向完全不同的设计选择。

原则没有变，但共识的基础变薄了。正是在这个时刻，那把椅子开始变得可见。在开源世界里，仁慈的终身独裁者这个判断需要解释。在大多数开源项目的叙事中，创建者与社区的关系是后设的——先有代码，然后有人聚集，然后才有治理结构。但Clojure的情况有所不同。

希基在两年半的独自开发期间，已经做出了一系列无可撤回的设计选择：Lisp-1的命名空间、不可变数据结构、与Java平台的共生关系。这些选择不是选项，而是前提。当2007年秋天他向Common Lisp社区的朋友们发出那封宣布新语言完成的邮件时，Clojure不仅是可运行的代码，还是一个已经完成了基本自我定义的系统。

后来的社区成员可以讨论、扩展、甚至在某些边缘地带偏离这些定义，但他们无法重新打开那些最初的决定。在这种意义上，椅子在房间被建造之前就已经在那里了。但“椅子”这个词是后来的发明。在2008年谷歌网上论坛开始热闹起来的时候，没有人谈论治理模式。

原则没有变，但共识的基础变薄了。正是在这个时刻，那把椅子开始变得可见。在开源世界里，仁慈的终身独裁者并非罕见模式。Python的Guido van Rossum、Linux的Linus Torvalds、Perl的Larry Wall——这些名字与他们的作品之间的关系，构成了开源治理中最古老也最持久的一种安排。BDFL模式的核心是一个从未被正式签署的交换：社区给予创建者最终决定权，创建者承诺以项目的长期利益为准则。这个交换存在于每一次争议被平息的方式中，存在于每一次有人援引创建者的意见作为讨论的终点。

但Clojure的做法有其特殊之处。Rich Hickey及其紧密合作者所掌握的，并非单纯的代码合并权。在大多数开源项目中，BDFL的权力集中在代码库的最终控制上——哪些补丁被接受，哪些功能被包含在下一个版本中。这是可见的、可操作的、有明确记录的决定。

但希基在Clojure社区中占据的位置涉及一些更根本的东西：一种对语言设计哲学的最终解释权。当社区成员争论一个特性是否符合Clojure的设计方向时，他们不是在争论代码的正确性，而是在争论一个更抽象的问题：这个特性是否与语言的基本原则一致。而那个问题的最终答案，不在测试套件里，不在用户调查里，不在投票结果里。它在希基的邮件里，在核心团队成员的回复里，在那些被反复引用的设计原则的原始表述里。

这种权力很少以命令的形式出现。更多时候，它像一把放在房间中央的座椅，平时无人提及，但每当社区争论进入僵局，所有人的目光都会不自觉地转向它。没有人被要求看向那把椅子，没有规程规定必须征询椅子的意见，但目光的转向是一个经过多年重复而变得自然的动作。就像人们在辩论中引用某段经典文本，就像他们在邮件中附上某个关键的JIRA工单链接。这是一种刻在社区身体记忆中的姿态，它的力量不在于它被使用时的权威，而在于它不被使用时仍然在场。

要理解这把椅子是如何被放置在那里的，需要回到社区最早期的一个制度安排：贡献者协议的签署。当一个开发者在Clojure的JIRA上提交补丁时，他们需要首先签署一份协议，将代码的版权转让给希基。这在开源世界中并非没有先例——自由软件基金会要求版权转让，而Apache软件基金会则使用贡献者许可协议，只授予项目使用代码的权利，不要求转让所有权。Clojure的选择更接近前者。这意味着，从法律上讲，Clojure的代码库属于希基个人。社区成员贡献代码，但代码的所有权最终归于创建者。

椅子在那里，但坐下去的行为从来不是通过法律文件来证明的。法律权力存在，但它被搁置了。这种搁置本身就是一种选择——一种通过不使用来维持权力的艺术。

这引向一个更深的谜团：如果法律权力从未被使用，那么裁定权实际上是如何运作的？为什么那些签署了贡献者协议、将自己的代码转让出去的开发者，仍然感到他们的参与是真实的、他们的声音被倾听了？

答案藏在裁定发生的方式中。在Clojure社区，核心团队的决定很少以否决的形式出现。更常见的模式是，当一个提议被提出时，如果它触及了语言设计的核心原则，回应不会说“不”。回应会说：让我们看看这个想法如何与既有的设计保持一致。这是一种将讨论从“该不该做”转向“如何做”的技术。它不是关闭对话，而是改变对话的框架。提议者没有被拒绝，而是被邀请进入一个不同的思维空间——一个原则已经设定的空间，在这个空间里，问题不再是“我们是否应该添加这个特性”，而是“这个特性如何表达我们已经同意的原则”。

2010年代中期的一次漫长讨论展示了这种运作的完整过程。那时Clojure已经发布了1.0版本，社区规模正在扩大，新的使用场景不断涌现。一个关于语言特性取舍的提议被发到了谷歌网上论坛。发帖者是一位有经验的开发者，他的论证很仔细：他描述了一个具体的痛点，展示了其他语言中类似特性的实现方式，并提供了初步的设计草图。这不是一个草率的请求，而是一个经过深思熟虑的提案。讨论持续了数周。邮件来来回回，参与者越来越多。有人支持，列举了使用场景。有人反对，担心复杂性。有人提出折中方案。讨论的质量很高——这是Clojure社区邮件列表的特点，技术论证往往深入而具体，很少退化为人身攻击。但讨论也在重复自己。相同的论点以不同的措辞出现，相同的担忧被多次表达。几周后，参与者开始感到疲惫。有人问出了那个问题——我们能否就这个做出决定？

这就是目光转向的时刻。没有投票。没有粗略的共识。邮件列表的讨论就这样悬在那里，像一根没有拉紧的绳子。然后，一封邮件出现了。

它来自核心团队的一位成员。措辞是克制的，语气是平静的。邮件没有引用任何人的发言，没有逐条反驳支持或反对的论点，没有宣布任何最终决定。它只是平静地重申了语言创建时的几条基本原则——那些希基在Clojure设计之初就写下的原则：简单性、专注性、对既有抽象的尊重。

邮件没有说“不”。但它让讨论的性质变了。在接下来的几天里，邮件的语调从“我们是否应该添加这个特性”转向了“在这个框架内，我们如何做得更好”。提议者没有放弃——他继续参与讨论，但方向变了。争论并未立即平息，但轴心已经偏移。从“该不该做”转向了“在这个框架内做得更好”。这不是一个戏剧性的时刻。没有宣布，没有裁决，没有“我决定”的声明。但每一个参与讨论的人都感觉到了那个转向。椅子的存在被确认了，但确认的方式不是通过坐下去的权威，而是通过重申那把椅子最初被放置时所依据的原则。裁定者没有说“我有权决定”。他说的是：这些是我们都同意的原则，让我们看看它们在这里意味着什么。

这揭示了Clojure社区精英治理的一个核心特征：裁定不是权力的展示，而是对共识的一次重申。当核心团队介入争议时，他们很少动用个人权威。他们援引的是原则，而原则的权威来自社区的选择——当开发者选择使用Clojure时，他们就已经接受了那些原则。裁定者的工作不是创造新的约束，而是提醒社区他们自己曾经做出的选择。这是一个循环：原则是创建者制定的，但社区通过选择加入而接受了它们。当裁定者援引原则时，他们不是在动用外部权力，而是在激活社区内部的共识。

这个循环是脆弱的。它要求原则本身保持稳定——如果原则每次争议都被重新解释，那么援引原则就失去了意义。它也要求裁定者保持克制——如果每次介入都动用否决权，那么共识的基础就会磨损。但正是这种脆弱性使机制得以持续运转。因为每一次裁定都是对共识的重新测试：如果社区不再接受那些原则，那么椅子的存在就会变得可疑。裁定者坐下去的时候，他必须证明这把椅子仍然值得存在。

证明的方式不是展示力量，而是展示原则在新情况下的解释力。在Clojure社区的历史中，这种测试发生过不止一次。每一次，争论的焦点都不是代码本身，而是原则的边界。当社区成员提出一个特性请求时，他们通常不是在挑战原则，而是在问：这个特性是否在原则的框架内？而裁定者的回应——无论来自希基本人还是核心团队的其他成员——本质上是在绘制边界。他们不创造新原则，他们解释旧原则在新问题上的应用。

这是一项解释工作，而不是立法工作。在开源BDFL模式中，创建者经常行使立法权——他们添加新特性，改变语言的方向，对项目进行根本性的重新设计。但Clojure的模式不同。希基对语言设计的核心原则——不可变性、简单性、对宿主平台的共生——保持了一种近乎固执的坚持。这些原则不是在社区发展过程中逐步形成的，它们在语言诞生之前就已经存在了。社区的角色不是参与原则的制定，而是在原则的应用上贡献智慧。原则本身是不可变的，就像语言中的不可变数据结构一样。

这就解释了为什么那把椅子能够放在房间中央而很少被碰触。因为椅子的存在不是为了被使用，而是为了被参照。它的功能不是提供最终的答案，而是提供一个稳定的坐标系统，让社区的讨论在其中找到方向。当争论进入僵局时，人们看向椅子，不是期待有人坐上去宣布结果，而是期待那个方向上的原则被重新阐明。椅子是一种提醒：在所有这些讨论发生之前，有些东西已经被决定了。不是被投票决定，不是被协商决定，而是被设计决定。

但这种安排也有代价。当原则拒绝扩展时，一些使用场景会被排除在核心语言之外。那些希望Clojure朝某个特定方向发展的开发者，有时会感到他们的需求被忽视了。他们的声音没有被压制——邮件列表上的讨论是开放的，论点被认真对待——但他们的方向不在原则的框架内。这不是否决，而是方向上的不匹配。否决是“你的想法不好”。不匹配是“你的想法有道理，但它不属于这里”。两者之间的区别微妙，但重要。否决是对提议的判断，不匹配是对范畴的划定。

在2010年代中后期，随着Clojure用户群体的扩大，这种不匹配变得更加频繁。企业用户带来了不同的需求，新领域的开发者带来了不同的期望。他们进入Clojure社区时，发现了一个已经建立的话语框架——关于什么是适合这门语言的特性，关于什么是对设计哲学的忠实。这个框架不是在排斥他们，但它确实在塑造讨论的边界。那些边界不是由某个人的命令划定的，而是由多年积累的原则解释所沉淀的。

沉淀的机制值得仔细审视。每一次裁定都不是孤立的——它们被记录在邮件列表档案中，被后来的讨论引用，被社区成员消化为关于这门语言的常识的一部分。一个新的社区成员可能从未阅读过原始讨论，但他们通过参与社区，吸收了那些讨论的结论。裁定变成了一种口头传统，通过邮件列表、会议演讲、博客文章和私下对话传递。一个开发者可能从来没有听过希基的名字，但他在写代码时，会不自觉地遵循那些通过传统传递下来的设计选择。那些选择已经变成了语言的语法本身——不是语法的语法，而是设计的语法。

这种传递方式有一个后果：原则的原始理由有时会在传递中丢失。当社区成员说“这不符合这门语言的设计方向”时，他们可能无法追溯到希基最初的论证。他们重复的是裁定的结论，而不是裁定的理由。这在社区中创造了一种特殊的权威结构——不是个人权威，而是传统权威。裁定者的座椅之所以存在，不仅因为希基创造了语言，也因为社区自身在重复和强化那些裁定的结果。权威的来源不是一个人的意愿，而是一个传统的自我维持。

这听起来像是一个悖论：社区的共识机制在巩固创建者的权威。但仔细看，这个悖论是真实的。在Clojure社区，共识不是通过投票或协商达成的，而是通过在接受原则的前提下运作而实现的。当开发者选择使用Clojure时，他们就已经接受了某些东西——不可变数据结构、对函数式编程的强调、对宿主平台的尊重。这些不是民主决策的结果，它们是在加入之前就已经存在的条件。共识不是在社区内部形成的，而是通过选择加入社区来表达的。

这不是一种民主共识，而是一种入门共识——你进门的时候，已经同意了房子的结构。这种模式的稳定性取决于一个条件：原则必须足够清晰，以至于加入者知道他们正在接受什么。如果原则模糊不清，那么“接受原则”就变成了一个空洞的姿态。在Clojure的案例中，原则的清晰性来自希基的高度明确的表达。从2008年第一个邮件列表开始，希基对语言设计哲学的阐述就异常清晰——不是通过宣言或文档，而是通过邮件列表上对具体问题的回应。每一个回应都是一个判例，每一个判例都在加深原则的清晰度。原则不是被写在一个文件里，而是被分布在数百个技术讨论中。

这种分散的清晰性有一个好处：它不容易被概括为口号，但每一个深入阅读的人都能感受到它的连贯性。到2010年代中期，这些判例已经积累成了一套体系。一个开发者提出一个特性请求，可以从邮件列表档案中找到类似的讨论，看到核心团队如何回应，判断自己的提议是否在原则的框架内。

这是一种自我调节——许多争议在到达核心团队之前就已经被社区自己解决了。有人会说“我记得之前有过类似的讨论”，然后贴出链接。讨论的参与者阅读链接，然后调整方向。裁定者的座椅通过档案的积累实现了某种远程在场。希基不需要亲自出现，因为他的论证已经沉积在档案中，可以被任何愿意搜索的人找到。

但档案的积累也带来了新的问题。随着判例的增加，原则的应用变得越来越复杂。早期的裁定是清晰的——因为早期的问题往往触及原则的核心。后来的裁定不得不处理边界情况：一个特性请求可能部分符合原则，部分违背。在这些情况下，核心团队的回应需要更精细的区分。他们需要解释为什么某个特性被接受而另一个看似相似的特性被拒绝。每一次这样的解释都在增加系统的复杂性。原则本身没有变，但原则的边界线变得越来越曲折，越来越难以一眼看穿。

这种复杂性对社区产生了筛选效应。要有效参与语言设计方向的讨论，一个新成员需要熟悉大量的判例。他们需要理解原则不仅是抽象的陈述，还是具体的应用历史。

这就创造了一个知识门槛——不是有意设置的，而是随着社区历史自然积累的。那些愿意投入时间阅读邮件列表档案、理解历史争议的成员，更容易在讨论中发出有影响力的声音。而那些没有时间或意愿的人，会发现自己经常被引向档案，被告知这个问题之前讨论过。

这就是编辑器界面之后更深层的边界。前一章探讨了语法高亮和编辑器工具如何在知识传递中划出界线——那些被自动补全和智能重构排除在知识传递路径之外的人，他们的归属感在哪里。这里出现了另一个层次的界线：那些不理解裁定历史的人，在语言设计讨论中的参与感在何处。工具的可及性是一层边界，历史知识的可及性是另一层。两者叠加，塑造了谁能够接近那把椅子——不是坐上去，而只是走近到可以被听见的距离。一个人可能精通Emacs的所有快捷键，能够熟练地书写宏，但如果他不理解社区历史中关于宏设计的那些判例，他在讨论宏的设计方向时，他的声音可能不会被认真对待。这并不是说Clojure社区有意在排斥任何人。

相反，邮件列表的开放性——任何人都可以发帖，任何人都可以提出特性请求——是社区引以为傲的传统。但开放的门不等于平坦的路。门里面是十五年的讨论档案，是一个已经形成的论证传统，是一套通过反复引用而变得不言自明的原则语言。新来者站在门口，面对的不是禁令，而是历史。历史本身不是障碍，但历史的厚度是一种梯度。走过那条走廊的人，和刚进门的人，在讨论中占据的位置不同。这不是权力的有意分配，而是知识不平等的自然结果。

历史的重负在2018年前后变得尤为明显。那时Clojure已经走过了十个年头，邮件列表的档案从几个月变成了几年，从几年变成了超过十年。判例的积累如此丰富，以至于几乎任何新问题都可以在档案中找到某种先例。这既是资源也是负担。对于那些愿意钻研的开发者，丰富的判例提供了指导。但对于那些希望快速参与讨论的人，判例的规模构成了一个隐形的门槛。

他们可能有一个很好的想法，但如果他们不知道如何用原则语言表达这个想法，如果他们的表述方式与社区的历史判例不协调，他们的想法可能被忽视——不是因为内容不好，而是因为形式不匹配。

核心团队本身也在经历变化。Clojure的开发过程在2010年代后期逐渐转向社区驱动，但驱动的方式不是通过民主化决策，而是通过扩大核心团队。更多的开发者获得了提交权限，更多的声音在裁定时被听到。但原则的框架没有改变——那些加入核心团队的成员，是因为他们已经深入理解并接受了Clojure的设计哲学。他们不是作为外部声音的代表加入的，而是作为传统继承者加入的。他们被选中，不是因为他们代表了不同的意见，而是因为他们已经证明了他们对原则的忠诚和理解。这是继承，不是代表。

这揭示了一个微妙的事实：在Clojure社区，裁定者的座椅不是一个人的座位，而是一个原则的守护者席位。

偶尔坐上去的人可能不同——希基本人，或者核心团队的其他成员——但坐上去之后说出的，是同一套原则语言。椅子的权威来自它象征的原则，而不是坐在上面的人的个人威望。这解释了为什么即使在希基减少公开露面、减少邮件列表参与的那些年份，椅子的存在感并没有减弱。因为原则已经被社区内化，裁定者的功能已经部分地扩散到了社区本身。当希基不说话时，档案替他说话。当核心团队不说话时，那些熟悉原则的社区成员替他们说话。但这并不意味着权威消失了。权威只是变得更加隐蔽，更难以定位。当一个社区成员在邮件列表中引用设计哲学时，他们是在行使某种权威——不是他们自己的权威，而是那个内化了的传统的权威。这种引用在社区中很常见，它既是共识的表达，也是共识的再生产。每一次成功的引用，都在加固那把椅子的存在，即使椅子本身没有被任何人触碰。

权威不是被某个人掌握，而是被分散在社区的语言中，被储存在那些被反复引用的原则陈述中，被激活在每一次技术讨论中。

这种权威的隐蔽性使其难以被挑战。如果有人不同意一个具体的裁定，他们可以提出异议，引发讨论，甚至在极端情况下离开社区。但如果有人不同意原则本身，他们面对的就不是一个可以反驳的论点，而是一个弥漫在社区日常中的氛围。他们可能会发现自己的异议无法被准确翻译——因为社区的语言已经预设了原则的框架。异议听起来不是“我不同意”，而是“我不属于这里”。这不是压制，而是翻译失败。社区的语言是一种方言，而方言的词汇表是原则的词汇表。如果你不用那些词汇说话，你的话可能不会被理解。

这正是Clojure社区治理中最深层的张力所在。精英治理——由创建者和核心团队掌握最终解释权——之所以能够持续运转，不是因为权威的不容置疑，而是因为每一次行使裁定权时，权威都必须重新赢得共识。但赢得共识的过程不是一个中立的程序。它依赖于原则的共享理解，依赖于判例的积累，依赖于参与者的历史知识。这些条件的分布是不均匀的。

社区中那些最接近原则核心的人——那些深入研究过设计哲学、熟悉邮件列表历史、能够用原则语言论证的成员——在共识形成过程中拥有更大的影响力。这不是权力的有意集中，而是知识不平等的自然结果。那些知道更多判例的人，能够更好地论证他们的立场。那些能够更好地论证的人，在讨论中拥有更大的权重。

2019年，社区中出现了一次关于某个库设计选择的讨论。这个库的作者采用了与核心语言略有不同的风格，一种更实用、更少教条的风格。讨论在邮件列表上展开，有人为这种创新辩护，有人则用设计哲学来批评。讨论的语调是文明的，但底层的紧张是明显的：谁有权定义这门语言的设计方向？是语言的创建者？是核心团队？是社区中的资深成员？还是每一个使用这门语言的开发者？

这个问题没有被直接回答——在Clojure社区，这类元问题很少被直接回答。但讨论的过程本身揭示了答案。那些能够引用历史判例、能够将当前争议与过去的裁定联系起来的参与者，自然地主导了讨论。

他们的论证不是因为更有力而胜出，而是因为更符合既有的论证框架而被认真对待。而那些无法或不使用这种框架的参与者，他们的论证虽然也被听取，却难以在讨论中积累重量。最终，库的作者没有改变他的设计，社区也没有将他驱逐。讨论就这样平息了，留下一个悬而未决的模糊地带——既不是原则的胜利，也不是创新的失败。

模糊地带本身是一种裁定：核心团队没有介入，这意味着这个库的设计不在核心关注范围内。这是一种沉默的裁决。这种模糊地带是Clojure社区的一个特征，不是缺陷。它允许社区在原则上保持明确，在实践上保持灵活。库的作者可以在自己的项目中偏离核心语言的风格，只要他不声称自己的做法是这门语言的设计方向。核心语言的维护者可以坚持原则，只要他们不试图管制每一个库的设计。社区可以在两者之间找到一个临时的平衡，这个平衡不是通过裁定达成的，而是通过避免裁定达成的。避免裁定本身就是一种裁定——它告诉社区：这个问题不重要到需要动用椅子。

但避免裁定本身也是一种权力行使。核心团队选择不介入某个争议，和选择介入一样，都会塑造社区的发展。沉默是一种裁决，它告诉社区：这个问题不在核心关注范围内，你们可以自行解决。这种沉默的裁决在Clojure社区中很常见，它既是原则专注性的体现——核心团队只关注语言本身，不试图控制生态系统的每一个角落——也是权威边界的一种划定。

椅子在房间中央，但它面对的只是房间的一部分。在椅子的视野之外，库和工具的自由发展创造了一个与核心语言不同的生态空间。这个空间有自己的规则，自己的争议，自己的解决方式。它不依赖于那把椅子，但它也不能挑战那把椅子。

这就勾勒出了Clojure社区治理的完整图景。在中心，是那把裁定者的座椅，象征着一个稳定的原则框架。围绕座椅，是那些深入理解原则、能够参与判例讨论的社区成员，他们在共识形成中扮演着不成比例的角色。

在更外围，是那些使用Clojure但很少参与语言设计讨论的开发者，他们通过选择加入社区而接受了原则，但他们的日常实践可能偏离那些原则——他们使用库，他们写代码，他们解决实际问题，但他们不参与关于语言方向的讨论。在最外围，是那些离开了Clojure的人——那些发现原则与他们的需求不匹配，或者无法跨越知识门槛的开发者。他们来过，他们用过，他们离开了。

这不是一个同心圆，因为边界是模糊的。一个开发者可能在某一天只是外围的使用者，另一天因为一个特性请求而进入了讨论的中心。一个核心团队的成员可能在某些问题上保持沉默，让社区自行解决。

椅子在房间中央，但房间的墙壁是透明的，门是开着的。只是，进门需要走过一条长长的走廊，走廊的墙上挂满了历史判例。走完这条走廊的人，和刚进门的人，听到椅子的声音不会一样。走廊的长度是知识的历史，是判例的积累，是那些被反复引用的原则陈述。

走过走廊不是不可能，但它需要时间，需要精力，需要一种特定的学习方式。

这也许就是Clojure社区治理中最诚实的真相：共识不是平等的，但它是开放的。开放性在于，任何愿意走那条走廊的人都可以获得参与讨论所需的资源。不平等在于，走完那条走廊所需要的投入——时间、精力、技术熟悉、对原则的认同——分布是不均匀的。那些拥有更多时间、更深的兴趣、更接近社区文化背景的人，在共识形成中拥有更大的能力。

这不是一个被设计的结果，而是任何依赖历史和原则的社区都难以避免的倾向。当裁定者的座椅通过原则语言和判例积累来运作时，那些无法掌握这门语言的历史语法的人，他们的参与感面临着一重挑战。这不是工具的问题，也不是权力的结构问题——这是知识在社区中如何分布、如何传递、如何被某些人熟练掌握而另一些人却感到陌生的问题。在Clojure社区第十五年的某个时刻，如果有人在邮件列表中提起这把椅子，大多数人会知道它指的是什么。但不同的人会看到不同的东西。

有人看到的是权威的象征，有人看到的是稳定的保障，有人看到的是一个需要被质疑的遗留物，有人看到的是他们之所以选择这门语言的理由。椅子本身没有说话，它只是在那里，被目光反复转向，被原则不断重申，被邀请加入社区的人选择接受或绕开。它存在的唯一证明，是每当目光转向那个方向时，有什么东西回应了那种注视——不是一个人的声音，而是十五年判例积累的沉默回响。那些回应注视的东西，不是权威，而是历史的重量。