大图书馆 #2 大教堂与集市

| 设计：苏子馨

历时五天，我总算把《大教堂与集市》^[1]这本经典的开源文化著作认真读了一遍，真是酣畅淋漓。

在进入具体的内容讨论之前，必须着重提到译者卫剑钒对中译本创造的价值。翻译是对原内容的二次创作，软件开发领域外文著作众多，大部分译本都让原文表意有明显的损失。卫剑钒翻译的《大教堂与集市》，阮一峰翻译的《黑客与画家》^[2]，以及云风翻译的《程序员修炼之道（第二版）》^[3]是我近一年来读过的本领域最佳译作。

开源软件的传承

《开垦心智层》一章讨论开源共同体的发展，以及发展过程中开源软件的所有权及转让的问题。

所有权

原文提到，开源软件的所有权获取有三种形式。

第一种也是最显然的，就是去创建这个项目，当这个项目在开始时就只有一个维护者而且这个维护者仍然起作用的时候，所有权问题是连提都不该提的。

第二种方式是获取前任对所有权的移交（有点像“接力棒传递”）。这在 区中很容易理解，当项目“所有者”不愿意或者不能在开发和维护中投入必要的时间时，他（她）有义务将项目移交给一个有能力的继任者。

第三种方式是一个项目需要维护但项目所有者已经消失或失去兴趣了。如果你想维护该项目，你的责任是努力找到这个“所有者”，如果找不到，你可以在相关场所（比如 Usenet 上专注于该应用领域的新闻组）声明该项目似乎是一个“孤儿”，而你想为之负责。

我在协助处理 TiDB 里两个合并子项目的工作的时候，实质上就遵循了这里的原则。原来的项目由多名 contributor 参与完成，在当时的 CLA 设置下，要求每位 contributor 都必须和 TiDB 项目签 CLA 才能合并。比起强硬的改变 commit author 绕过 CLA 检查，我建议尝试联系未签署 CLA 的参与者补上。这些参与者被 at 以后很快响应并且解决了问题。

其实参与开源开发的人不是坏人，在项目没有发展出多样性之前，不要擅自以“内部”“外部”这种二元视角界定参与者的属性，也不要假设“外部”是邪恶的。

分化

原文将分化行为列为开源文化当中的禁忌。分化指的是派生出一个随后不能交换代码的竞争项目，并导致开发者群体的分裂。

黑客厌恶项目分化的另一个原因是，他们惋惜那些被浪费的重复工作分化后的两个子项目总是有着或多或少平行的演化路线。他们也会注意到分支倾向于分裂合作开发者 区，使得两个子项目的人手都比父项目的人手更少。

近年来雨后春笋般冒出来的开源项目，在分支和合作问题上起码有两点值得关注。

第一点是对合作的漠视。相当部分项目， 称开源，实则核心成员还是都来自同一个公司团队，规模往往超不出十几人。他们有很强的领地意识，拒绝其他人的参与，或者将其他人的贡献打包进项目整体说成都是该公司的贡献。这样做，使得不同组织的参与者失去动力甚至有种被驱逐出去的意味，实质上只是源码可得的传统项目开发模式。

当然，也有好的案例，且大多来自公司背景不强的项目。例如 SeaTunnel^[8] 还叫 WaterDrop 的时候，就吸引了不同组织成员的关注和参与，现在又被 Apache 成员关注到，合作进入 Apache 孵化器孵化。

第二点是对分支的痴迷。也就是公司喜欢 fork 出来搞个魔改版本，从不考虑 contributing back 还以为自己占了便宜。且不说这种行为禁锢了原本可以参与共同体的成员，代码分化带来的兼容性问题魔改版本从来不能解决。回过头来把魔改版本抛头换面又煞有介事的“开源”，应该被整个黑客 会所唾弃。

如果说还有一点，那就是那些所谓的“开源技术公司”，如果试图对开源共同体实施某种形式的管控，让商业公司凌驾于志愿者之上，那么这样的项目实际上更容易分化。Elastic 和 OpenSearch^[9] 就是一个典型的例子。

对于相对开放的民主制度而言，它的一个主要优势在于，绝大多数潜在的革命者发现通过在系统中工作比攻击该系统更容易让自己向目标前进。但如果既有政党联合起来“提高门槛”，导致那些较小的不满意团体觉得更难实现自己目标的话，这种优势就很容易被侵蚀破坏。

准入门槛不高的开放过程鼓励参与而非分裂，因为参与者能从中获得成果，而不用付出分裂所需的高昂成本。尽管这种成果可能不像分裂所得成果那样令人印象深刻，但其成本较低，且大多数人都能接受这种折衷。

冲突与解决

原文提到，项目当中的冲突与解决主要围绕三个问题展开

1. 谁来负责做设计决策/p>

2. 如何决定哪个贡献者应该被授予荣誉，如何授予/p>

3. 如何保持项目团队和产品不被分裂为多个分支br>

第一个问题由上述所有权问题回答。关于分支的问题在上一节已经讨论过了。现在看第二个问题。

无论采用独裁者模型还是委员会模型，黑客的荣誉都跟他创造的价值相关。也就是说，黑客的声誉在礼物文化的大背景下，由他的贡献即赠与开源共同体的礼物的价值所决定。对于独裁者模型来说，独裁者本人需要能够践行这样的规则，否则高水平的参与者就会选择离开。对于委员会模型来说，还有一个额外的问题是委员会自身应该避免冲突。原文质疑委员会模型难以避免冲突

在这种形式中，我们很难看到内部边界，并因此很难避免冲突，除非委员会内部享有极高水平的和谐与信任。

但是，今天的软件复杂度越来越不支持独裁者模式。如果独裁者本人已经把部分决策权交给参与者，那么他在运行上就类似于委员会的模式。即使独裁者名义上拥有最终决定权，他与维护某一模块的核心成员仍然需要保持高水平的信任以减少项目当中的摩擦。

结合如今一部分商业公司创建或大规模参与开源项目的背景，如果项目建立的是同侪共同体（community of peers），也就是说成员的角色与个体相关，而不是与他在某个组织的职位相关，在这种情况下依然把委员会的人员增加与企业员工入离职挂钩，这种组织形式就是非常危险的。

具体地说，部分项目照猫画虎地搬来了 Apache 软件基金会式的同侪共同体设计，在决定项目 PMC 成员和 committer 人选时，却变成了公司同事入职，“理应”有 commit 权限，就稀里糊涂的成了什么 committer 或 PMC 成员。一旦离职，则完全不理会项目的发展，甚至出于不愉快恶意捣乱项目的日常事务。这就是没有基于项目的需要和个体对项目的认可和贡献选择委员会成员的弊病。

这是说缺乏多样性的项目中，单一公司的员工需要避嫌吗然不是。实际上，成为大力投资该项目的公司的雇员，能够尽可能多的时间投入到项目发展上，公司的员工确实有更大的可能性成为核心成员。但是必须注意的是他的推举应该是客观的，基于项目的需要和个体对项目的认可和贡献来选择。只有这样，才能努力做到委员会内部有极高水平的和谐与信任，这才是这种组织形式下项目长久发展的根基。

2021中国开源先锋33人评选启动，快来推荐你心尖上的开源先锋吧!

2021中国技术先锋年度评选启动，新增新锐技术先锋企业榜

开源 简介

开源 成立于 2014 年，是由志愿贡献于开源事业的个人成员，依 “贡献、共识、共治” 原则所组成，始终维持厂商中立、公益、非营利的特点，是最早以 “开源治理、国际接轨、 区发展、开源项目” 为使命的开源 区联合体。开源 积极与支持开源的 区、企业以及政府相关单位紧密合作，以 “立足中国、贡献全球” 为愿景，旨在共创健康可持续发展的开源生态，推动中国开源 区成为全球开源体系的积极参与及贡献者。

2017 年，开源 转型为完全由个人成员组成，参照 ASF 等国际顶级开源基金会的治理模式运作。近七年来，链接了数万名开源人，集聚了上千名 区成员及志愿者、海内外数百位讲师，合作了近百家赞助、媒体、 区伙伴。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8589 人正在系统学习中