Debian 向左：或将迎来根本性改革

文 | lola  

策划 | h4cd

出品 | OSC开源社区（ID：oschina2013）

开源社区是个独特的存在。它虽然结构松散但却又切实有效，为社会提供便利好用的产品却不以利益为目的，将志趣相同的人们聚集在一起但又完整地保存了每一个个体的独特性...... 这些开源社区就像是一场场风格迥异的社会实验。

其中，Debian 社区是一个典型代表。作为 Linux 最早的发行版本之一，诞生于1993年的 Debian 可以算是开源社区中的“活化石”。这也令 Debian 在机制、行事和文化等方面都体现出了一定的“古典”特质。

最近，Debian 社区正在酝酿一件大事 —— 改革自己的决策机制。一直以来，Debian 的决策机制都饱受诟病，不少优秀的开发者因此离开，这样的变革或许不可避免。

01 离开

“长久以来，Debian 都难以作出改变。”

2014年的时候，Joey Hess 决定离开贡献18年之久的 Debian。促使他离开的直接原因是，Debian 社区对于是否接受 systemd（一种 init 进程）争执不下。这件事引起了 Debian 内部长达数年的争论，至今仍然没有定论。

当然，systemd 事件仅仅是一个引子，Joey 已经感受到了 Debian 社区背后所隐藏的某种“病态”。 

“ 我第一次感觉到 Debian 的这种（病态），是在 Debian 改变‘ /usr/doc’这一错误的文件保存路径（系统文件的标准要求被保存在‘usr/share/doc’中）的时候，完成这样一个再简单不过的操作更改，Debian 居然花了6年之久。” 在 Joey Hess 看来，这实在太荒诞了。

要知道，Joey 并不是为此离开的第一位前辈。此前，Matthew Garrett 在2006年就指出了 Debian 决策效率低下的痛点，而他曾任 Debian Project Leader（简称 DPL，是 Debian 的项目负责人）。

Joey Hess 是 Debian 中的元老，颇具影响力 

不过话说回来，Debian 毕竟是个志愿者组织，社区的事情会被成员放在较后的优先级上，效率自然低下。况且，Debian 组织庞大，事情也不像只有十余名维护者的开源社区一样好解决。

但是，同样的问题引来了更多的人离开。2019年3月，一位名为 Michael Stapelberg 的 Debian 包维护者在其个人博客发表了一篇长文，宣布退出 Debian 的维护。他的文章引起了 Debian 社区内外的广泛关注。

Stapelberg 提到了几个星期前参加 Debian 聚会时的感受，他表示这次聚会讨论的主题和几年前基本一样，这使得他开始反思自己是否仍适合留在 Debian 继续参与维护。

除此之外，Stapelberg 还在博客中抱怨了 Debian 糟糕的开发流程，认为 Debian 整个开发评估流程都非常迟钝，比如：补丁的评估没有截止日期，有时候他会收到通知说几年前递交的补丁现在合并了。

事不过三，这些开发者的离开足以警醒 Debian 内部。

02 改变

2021年9月28日，Debian 技术委员会（Technical Committee）资深成员 Russ Allbery 站了出来： 

我认为（社区的）章程建立在了一个错误的基础之上，它太过于追求“控制想法”（minds of the governed），而章程应该关注的是“流程性细节”（procedural details）。当抉择艰难时，我们需要创造出一个能够消弭分歧的机制。这个机制甚至能够在我们失去立场的时候，发挥作用。 

在 Allbery 看来，Debian 之前走错了方向。在这一层上，Allbery 聚焦在“机制”上。而从 Debian的现存机制上来看，Debian 为项目个人提供了极大的自由。

Debian 把决定权交给了个人开发者，开发者可以按照他们认为合适的方式来进行管理。这种自由被 Debian 章程（consitution）和 Debian policy manual 限制，主要是为了确保开发者和他们创建的软件包都能共存并且和睦相处。

当大家分歧不大的时候，这个机制基本上都是可行（不然 Debian 也不会有效运行这么多年）。而面对一些特殊情况，Debian 社区的机制主要有两个：

1、技术委员会。技术委员会有权对技术相关的政策做出决定，在最极端的情况下，如果开发者的行为被判定为对发行版具有很大的破坏性，那么委员会可以推翻 Debian 开发者的决定。

但是，技术委员会的决策能力权威在过去的一些争论中受到了损害，比如委员会被个人开发者控诉不公平。

可能，委员会在操作中的确存在不透明的地方，然而 Debian 社区中过于鲜明的个体性，或许也难逃其究。正如 Stapelberg 所言，Debian 的一些维护者出于个人喜好拒绝合作，维护者给予的个人自由度太高对 Debian 构成了严重影响。

 2、一般决议流程（general-resolution process）。也就是投票，项目成员可以通过投票来改变或推翻技术委员会（或其他人）的决定、制定新的政策、或者修改章程。

Debian的投票方式几乎是独一无二的。Debian 开发者不是简单地提供一个选项列表，而是自己创造所有这些选项，通常会有大量的选项，而且经常会引入许多相关讨论。

这个方案的初衷是希望能创造出尽可能反映整个 project 意愿的结果，因此Debian 的投票方案允许一张选票中包含许多差异不大的选项。

但是，这也是一个再拖沓不过的方案。比如，在2019 年关于一场 systemd 辩论中，当时采用的是一般决议流程。投票一直没能开始，当时的 DPL Sam Hartman 就要求尽快对决议进行投票。

这让一些参与者感到很不满意。有人试图拒绝这个提前投票，但没有成功，于是对七个选项的投票就正常完成了。一些开发者认为这个过程又一次被滥用了，也对整个项目造成了损害。

“这种面临决定时的怯步，是不健康的。Debian 在一些时候想要得到最大程度上的‘同意’，但百分百的一致是不可能实现的，总是会有人不满意。” Joey Hess 认为，Debian 缓慢的决策机制是结构性的。

2021年10月5日，Russ Allbery 为改革决策机制拿出了一个提案：

 首先，为了技术委员会更加透明、公平，Allbery 提议了一个新流程。新流程将允许任一位成员要求对一项公开决议进行表决，并立即开始投票。但是，如果有任何一位其他成员在 24 小时内对投票提出反对，那么这次投票将被取消。（如果这条规则在 systemd 的争论期间就已经存在的话，那么就不会产生让决议匆忙作出的投票了。）

其次，投票需要在这个决议首次被提出的两周后开始，如果到那时还没有人能成功地发起投票，则自动开始投票。这样一来，发起表决就不会拖得太久。

其中，实际投票前的讨论期长度是由项目负责人决定的（这一点没有变化），但新的规则是将这个时期的时长限制在两到三周。

对选票的任何实质性修改（例如增加新的选项）将会使得讨论期至少再增加一周，但这个时长仍然不能超过最长期限。如果讨论期能继续延长的时长少于 24 小时了，就不能再进行这类实质性修改了。

项目负责人有权将讨论期缩短或延长一周，但缩短讨论期的情况下也必须要确保能至少还有 48 小时的时间。

如此一来，无论是哪个流程，都为讨论时间设置了一个上限。同时，也准备了一些机制来防止被迫投票的情况。

“如果人们在这个过程中不觉得自己被人欺负了，那么他就会更容易接受一个不符合他意愿的决策。” Allbery表示。

03 行动

尽管离开了 Debian，Joey 还是在今年11月的一场访谈中表达了自己对 Debian 的不舍和热爱。

“如果说我在 Debian 的18年有什么遗憾的话，那就是在 Debian 章程最初制定的时候，尽管感觉到了不妥，但我没有发声。”

同样地，当初 Michael Stapelberg 离开 Debian 也没有“脱粉回踩”，他只是希望自己的文章能激励 Debian 做出改变，继而改进开发者参与维护的体验。

因此，他在博客中苦口婆心地列举出 Debian 的问题（包括包的上传问题、bug追踪问题、邮件列表归档问题等等），然后再给出自己的解决方案。比如他认为，项目应该努力实现更多的统一；Debian 文化需要从“这个包归我管，你不能碰”转变为共同的所有权意识等等。

1993年9月15日，Debian 0.01版发布至今，Debian 已经经历了近三十个春秋。一个完全没有盈利组织支援，由来自世界各地的志愿者通过互联网协调完成工作的组织，能够存在这么久是了不起的事情。

这么多年来，Debian 就是凭借这样的模式，给用户提供了超过25,000个软件，超过50,000个软件包，并正式支持10个计算机系统结构。

或许，就是这些开发者与 Debian 之间的这种“羁绊”，促使他们采取了行动。

2019年当选为DPL的 Sam Hartman 表示，他的首要任务之一就是改善决策过程。Hartman 也确实将大部分精力都放在了决策制定上，而且从结果来看，Hartman 成功了，他推动了许多基于共识的讨论，在这些讨论中 Debian 社区成员探讨了各种选择并得出结论。

Russ Allbery 在9月提出倡议时，Debian 内部也开始了激烈的讨论，大家几乎没有什么反对意见。进一步，Allbery 在10月给出提案，的确获得了社区内的多数同意。但是，这一举措需要进行一般性决议投票（根据之前的规则），而且决议必须以 3：1 的超级多数通过。

目前，Allbery 不希望匆忙提出一般性决议的要求，而是希望等到他觉得有很大可能性能获得超级多数支持之后再发起，因此他请求所有那些不支持现有提案的人解释一下原因。

无论如何，我们可以期待这些举措的进一步落地，希望这一改革真的能够改善 Debian 决策缓慢的弊病。

END

觉得不错，请点个在看呀