“Debian 章程有毒”

作者：lola   策划：h4cd

1996年，Bruce Perens 接下了 Debian 创始人 Ian Murdock 的接力棒，成为 Debian 社区历史上第二位当家人。也就在这一年，不满20岁的 Joey Hess 为了满足自己打包游戏的爱好成为了 Debian 成员之一。

某天，加利福尼亚州的阳光正好，旧金山湾区（硅谷所在地）的某一角落，Bruce Perens 敲响了 Joey —— 这位刚来此地工作的年轻人的大门。

“I’m going to take you on a tour of the Bay Area. ”

他们开着车随意地在湾区闲逛，当经过各大科技公司时，也会聊上两句。这次兜风是 Joey 第一次和社区的人面基，从此开启了 Joey 通往这个全新世界的大门，而 Bruce Perens 这位大人物的上门，也让 Joey 觉得非常不可思议。

年轻时的 Joey Hess 穿着 Debian 文化衫

可惜的是，1997年12月，Bruce Perens 就从 Debian 当家的位置退了下来，与另一位声名显赫的人物 Eric Raymond 一起创立了 OSI （Open Source Initiative），成为了开源的开拓者。

当时，Debian 社区内有一些争议声音表示，Bruce Perens 是个独裁者，一手包揽了所有事情。因此，Bruce Perens 离开之后，Debian 开始制定 Debian 章程（Debian Constitution），来制约领导人的权利。

2014年，针对是否采用 systemd 这种 init 进程，Debian 内部开始一场持久且激烈的争吵，Joey 也在这时离开了他贡献18年之久的 Debian。

If I have one regret for my 18 years in Debian, it’s that when the Debian constitution was originally proposed, despite seeming dubious, I had neglected to speak out. It’s clear to me now that it’s a toxic document that has slowly but surely led Debian in very unhealthy directions.

如果说我在 Debian 的18年有什么遗憾的话，那就是在 Debian 章程最初制定的时候，尽管感觉到了不妥，但我没有发声。我很清楚，这份有毒的章程正在缓慢且坚定地引导 Debian 走向病态。

在2021年11月的一次访谈中，Joey 直言 “Debian 章程有毒”。在 Debian 章程的框架下，Joey 感到紧张，因为这些章程正在拖延着所有的决策。

同样是在2014年，同样是因为这场旷日持久的 syetemd 论战，当年的 Debian 技术委员会成员 Colin Watson 和 Russ Allbery 先后在 Debian 邮件列表上宣布了辞职声明。在 Russ Allbery 的辞职信中，他提到了 Joey：

Finally, I’ve been thinking hard about Debian project governance in the light of Joey’s resignation, as I’m sure many of us have been.

Joey 的离职让我不住去想 Debian 的管理出了什么问题，我相信我们其中许多人也一样。

当时，Russ 已经在 Debian 技术委员会里待了6个年头，但他没能熬过2014年那场论战。他表示，委员会几乎每一个决策都受到巨大的压力，他感到没有精力来处理这些事情，他也觉得自己在技术委员会的工作对整个项目没什么帮助。

2019年，Debian 开发者 Michael Stapelberg 在离职 Debian 时留下一篇长文，里面细数了 Debian 内部的各种问题，引起各方热议。

在写下这篇文章的几个星期前，Michael 在苏黎世 Debian 聚会上遇见了一些多年未见的老朋友，在这场谈话中，他们谈到了一个话题—— Debian 的民主以及他们在理论和实践上的失败。

作为最古老的 Linux 发行版本之一，Debian 系几乎占据 Linux 系统家族里的半壁江山；作为老牌的开源社区，Debian 运行了近30年依旧香火不断；但是，作为一个统筹几百个开发者协作的社会组织，Debian 为什么却让这些人失望了？

01 不吃香的 DPL

Bruce Perens 走后，DPL（Debian Project Leader）这个词被 Debian 章程定义了出来。DPL 由 Debian 社区选举出来，一年一届，每年春天都会有一个 Debian 开发者竞选成功，接受这个组织的“加冕”。

2019年的春天，Debian 的这一选举却“轮空”了。3月11日，Debian 邮件列表出现了一封标题为“Leaderless Debian”的公开信，文章表示，这年的3月3日-10日是候选人提名阶段，然而，截至公开信发出，还没有一位符合资格的 Debian 开发者提交申请。

此前的 Debian 领导人 Chris Lamb 一直被寄予厚望，他已经连任了两年，但是今年他公开表示因为一些 Debian 相关的，以及一些私人的原因不参与竞选。由此，Debian 不得不根据章程延长提名时间，直至有人提交申请为止。

当然，最后还是有人跳了出来参加竞选。这里要指出的是，这一尴尬事件非常直观地反映出一个事实 —— DPL 并不吃香。

准确来说，在 Debian 章程的制约下，DPL 是一个没有绝对权利的虚席。

首先，DPL 并不接触具体业务，他可以任命某人执行专门的任务，而这些代表有权力在考虑技术标准和共识的情况下做出他们认为最佳的决定。

至于 Debian 社区的项目层面，DPL 更是无权过问，每个项目的开发者都对项目有百分百的决定权。比如，个别开发者几乎可以完全控制他们维护的软件包；开发人员之间的技术分歧很大的时候，将由项目技术委员会处理；发布管理者与 FTP 主人有权最终决定项目实际发布的内容，以及何时发布；项目秘书负责确保遵循必要的程序；政策团队处理项目的大部分总体设计。

其次，DPL 是可以随时进行更换的，因为有一般决议（General Resolution）这样的通道，开发者们可以重新选举另外的 DPL、撤销 DPL 或代表的决定、修改基本文件并做出其他有约束力的决定。（如下图所示）

那么，DPL 到底是干什么的呢？主要分为两个方面：

在对外职能中，DPL 代表 Debian 项目去进行关于 Debian 的演讲和演示、参加贸易展览、与其他组织和公司建立良好的关系以及处理一些法律相关问题。也就是说，他是一个形象代表和官方发言人。

在内部，DPL应该与其他 Debian 开发人员交谈，尤其是与代表交谈，以了解他们如何协助开发者的工作。此外就是一些批准预算的财务事宜。也就是一些行政事务。

在多数的公司或组织中，对外品牌和行政都不是核心业务部门，非常边缘化，这些职能常常会面临没有价值感、陷入繁杂琐事的困境。与此同时，DPL 花费时间与精力并不少，却没有任何薪水回报。

这就不难理解为什么会有 DPL 不愿连任。比如，2019年那次轮空事件中接盘的 Sam Hartman，就在 2020年的竞选季中表示不再参选。

02 开发者们的“共同意志”

那么，谁才是 Debian 中的权威呢？

在 Debian 社区中只有两种官方角色：Debian 开发者（DD）和 Debian 维护人员（DM）。DD 由 Debian 章程所定义，而 Debian 维护人员则是在2007年的总决议中才做的定义。

其中，DM 是一个没有多少权限的角色，他们只能为那些在 Maintainer 或 Uploaders 字段里包含他们的名字、并已经被 DD 指定了 DM-Upload-Allowed: yes 标记（意思为允许 DM 上传）的包执行上传的工作，除此之外他们没有别的权利，而他们访问 Debian 资源的权限也十分有限。

在 Debian 章程的定义中，Debian 开发者（DD）的主要职能是提交代码以及维护自己负责的包。他们具有进入 Debian 服务器的权限，并可以参与社区投票（比如一年一次的选举等）。

一方面，DD 完全掌握自己的工作，可以做任何技术性和非技术性的决定，几乎不受任何限制。也就是说，Debian 社区里没有领导。

另一方面，这些拥有投票权的 DD 们，通过一般决议流程（General Resolution），成为了 Debian 群体中的权力主体。他们可以任命或者罢免 DPL；对于 DPL 或者代表的任何决定觉得不爽都可以推翻；可以用 3:1 的多数票修改 Debian 章程；还可以处置 Debian 的信托财产等等。

除此之外，为了保障所有的开发者声音都被尊重，Debian 章程还特立独行地将“None Of The Above”（以上都不是）设为默认选项。也就是说，当你觉得以上的选项你都不想投票，你可以另开一栏，写上你的选项，参与投票。

与此同时，Debian 采取 Condorcet 方法（也就是孔多塞标准）来进行投票，这种投票方式需要“两两对决”来选出赢得多数选票的一方，而不是在众多候选人中一次性投票，再去挑出票数最多的。

总的来说，给予个人开发者最大程度的权限，以谋求最大程度上群体的“共同意志”，是一件政治正确的事。但是，最大程度的“同意”真的存在吗？Joey Hess 表示，这是不存在的，总是会有人不高兴。

此外，Debian 最大限度保持个体自由的同时，也使得个体显得个性十足、难以妥协；一旦缺乏强大的聚合力将他们拢在一起，就会出现“分裂”的情况。

“如果有人坚持拒绝合作，那么你做出的变更很容易就会被一拖再拖。我举一个典型的例子： rsync，其维护者完全出于个人的喜好拒绝我的补丁包使用 debhelper。赋予个人维护者如此大的自由，导致我们无法开展提高构建 Debian 软件包抽象级别的项目，这反过来又让工具更加困难。”Michael Stapelberg 在自己的文章中探讨了 Debian 中过大的个人自由。

“我认为 Debian 社区的管理存在一个很大问题 —— 社区正在被一些特定问题深深地分裂成很多不同阵营。” Russ Allbery 曾表示。

或许，这也成就了 Debian 如今的“儿孙满堂”——不少软件从 Debian 衍生出来。就拿2014 年systemd 事件为例，那场争议导致 Debian 阵营开始分裂 —— 反对者创建了一个不使用 systemd 的分支 Devuan。此外，基于 Debian 的衍生产品还有很多，比如 Ubuntu、Deepin、Kali Linux、MX Linux等等。

03 技术当道，管理缺失

除了“超标”的个体自由之外，Debian 还从骨子里存在一种“唯技术倾向”。

当初，Debian 创始人 Ian Murdock 之所以开始做 Linux 新版本，是因为他十分不满 SLS（Softlanding Linux System，被称为最古老的 Linux 发行版），就对 SLS 进行改进，结果改进了太多东西，足够发布一个新的版本了。

这一出发点就非常极客 —— 用技术去创造自己想要的东西。因此，尽管 Debian 内部因为 systemd 吵得不可开交，但多数争论都是围绕技术本身。

从基因上，Debian 社区基本就是一个技术构建的空间，关于技术的道德契约才是凝聚 Debian 的核心力量，而这也注定了Debian 内部的平衡非常棘手。这让 Debian 技术委员会（Technical Committee）不堪重负。

Debian 章程中写明，技术委员会（TC）是决定所有技术相关事宜的权威，其中包括任何开发者拿不准主意的事情都会交到技术委员会那里。比如：开发者之间关于指令名称归属权的争议、冲突包之间的分歧、哪个包应该对现有的 bug 负责等等。

同时，技术委员会还需要就社区内有争议的事情发表正式的声明。比如 2014年的 systemd 之争，Debian 技术委员会就曾站出来说：接受 systemd（但是依旧有很多人不买帐）。

除此之外，Debian 章程中还在技术委员会的职责中写了这么一项：Make a decision when asked to do so（只要有需求就要做出决定），任何一个人的任何需求，都可以向技术委员会寻求建议。

在 Russ Allbery 2014年的辞职信中，他说了许多“累觉不爱”的话：

技术委员会的工作和相关话题已经成为我在 Debian 工作的绝大部分。这并不有趣。我太低估这份工作所需要的情感和注意力了，这比时间投入更加糟糕。

几乎技术委员会的每一个决定都充斥着不愉快，在现有的框架下，技术委员会每做一个决定都需要更多的技巧、关心、注意力和小心翼翼，这些使我心理压力巨大。

同时，他还认为管理是必须的，他相信一个大团体的机制中需要更多的管理，这个组织才不会因为分歧而陷入瘫痪。

而 Debian 现在最主要的问题，就是管理缺失。当初，Debian 开发者们通过章程最大程度上架空了 DPL 这一角色，但管理的需求仍在，于是技术委员会就不得不发挥一定的管理作用。

因此，职能角色的分工不均衡，再加上个人角色的过度自由，使得 Debian 章程变成了 Joey 口中的那份“有毒文件”。

我想敏捷哲学中的一些事情是对的：想办法减少因为改变而产生的成本，去赋能一些个体决策的权利、去行动，而不是在事前就害怕失败、畏首畏尾。近来，我越来越怀疑 Debian 现行的决策机制（特别是技术委员会）是否真的合适。

敲下这几句话的几年后，Russ Allbery 再次成为了 Debian 技术委员会的成员。这次，他没有坐以待毙，而是提出了一份根本性的改革草案。