Skip to content
Published on

巴士系数不是懂代码的人数，而是能拍板的人数

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 —— 仓库还在，领导层没了

2026 年 8 月 7 日，NixOS Discourse 上发出了一篇宣布 Nixpkgs 核心团队解散的帖子。由 qyliss 代表 @alyssais 和 @emilazy 撰写；同一天，NixOS/org 仓库的 PR #277 被合并，@NixOS/nixpkgs-core 这个团队定义本身也被删除了。

Nixpkgs 是一个装着十万多个软件包的仓库。我在 2026 年 8 月 9 日用 GitHub API 亲自数了一下，最近两周左右(2026 年 7 月 24 日之后)被合并的 PR 是 4,468 个。

curl -s "https://api.github.com/search/issues?q=repo:NixOS/nixpkgs+is:pr+is:merged+merged:>=2026-07-24&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"
# 4468

可是，承担这个仓库被授权的技术领导职责的团队，人数是两位。这两位退出时，公告是这么写的：曾属于我们管辖范围的事项，如今处于没有直接主人的状态。

这篇文章不是在劝你用 Nix 或者别用 Nix。它讲的是你所依赖的项目，风险该从哪里去量。

巴士系数是权限的数量，不是知识的数量

巴士系数通常这样解释：「核心人员被巴士撞了几个，项目就停了？」而且大多被解读成知识问题：文档不够、某个模块只有一个人懂。

Nixpkgs 这个案例展示的是另一个维度。Nixpkgs 并不是知识集中的项目。它有数千名贡献者，提交者也在持续增加。核心团队在这十个月里做的事情之一，恰恰就是改革提交者授权流程并引入了 19 位新提交者。

即便如此，团队里两个人一走，就出现了空缺。因为那两个人握着的不是代码知识，而是决策权。公告引用的宪章授权事项是：在与 Nixpkgs 相关的范围内的项目方向、决策、与 NixOS 基金会理事会的协调，以及团队的设立与管理。

写代码的人有很多。有资格说「我们朝这个方向走」的人只有两位。这是完全不同的两个数字，而我们通常只数前一个。

公告实际上说了什么

在叠加解读之前，先把原文的事实原样搬过来。

  • 团队活动了十个月。
  • 列出的成果包括：改革提交者授权流程并引入 19 位新提交者，通过扩展合并机器人强化维护者权限，重塑与 GitHub 的关系并争取到 Enterprise Cloud 赞助，协助对安全公告 GHSA-67f2-674w-6g63 做分类处置，制定初期的自动化与 AI 政策。
  • 退出的直接原因是健康。原文写道：这个角色并没有像预想那样轻到能与积极的技术贡献并行，两周前他们得出结论 —— 退出对自己的健康是必要的。
  • 关于招募新成员，他们透露「真正提出申请的只有一人」，而对外邀约得到的反馈也参差不齐。
  • 关于指导委员会，他们的诊断是：它在制度上缺乏宪章所设想的那种「授权出去」的本能，同时又没有参与到、也没有凝聚到能自己处理那个层级的具体决策的程度。结果就是对下属团队不必要的微观管理，以及长期的沟通不畅。
  • 最后明确写道：这个决定不是因为某一件事，而是长期模式的必然结果。

以上是原文的内容。哪里都没有说 Nixpkgs 本身要停摆或者开发要中断。仓库照常在转。

当授权只剩下名义时，崩掉的是什么

公告里最能推广的部分，是它对授权的诊断。

设计治理结构时，常见的做法是这样：最上层放一个代议机构，下面按领域设团队，然后在宪章或者规程里写上「这个领域授权给那个团队」。在文档上，这就闭环了。

问题在于，授权是一个行为。不是写进文档就算授权了，而是上层机构真的撒手，才算授权。公告列举的那些失败形态，正是落在这个点上。

  • 指导委员会成员发言时，分不清是个人意见还是集体立场
  • 事项传下来时已经附带了想要的结论
  • 完全属于授权范围内的事项，委员会绕开相关团队直接处理
  • 对提出的疑虑，回应不充分且拖延

最后一句是决定性的：「对于我们是否被信任在自身权限范围内自主做决定，存在全面的不确定性。」

没有权限的责任就是这样产生的。被授权的团队要为结果负责，却不掌握决定的终局性。这种状态会很快把人耗干。如果你运营过公司内部的平台团队或者架构评审组，这个结构应该不陌生。

十个月的成果清单，也就是如今失去主人的功能清单

把公告里的成果清单当成炫耀来读，只读了一半。换个读法，它是如今没有主人的功能清单。

提交者引入、通过合并机器人下放维护者权限、GitHub 组织所有权改革、安全公告分类处置、自动化与 AI 政策、被升级上来的争议的调解。

其中相当一部分属于「平时没人觉得需要，一旦需要就立刻需要」的那类工作。安全公告的分类处置尤其如此。提交者引入停了，几个月后会以吞吐量的形式显现；争议调解停了，冲突会以帖子长度的形式显现。因为不会立刻出故障，风险就在无声中累积。

公告本身也承认了这一点。它写道：仅仅是「可以请核心团队来调解」这个事实本身，就在很多情况下缓和了紧张、把事情导向了能够达成共识的结论。而那条通道，现在没有了。

从使用者角度看这意味着什么

那么，用 Nixpkgs 的团队该做什么？不夸大也不缩小地整理一下，是这样。

眼下没有任何东西会改变。软件包会继续更新，channel 也会继续发布。

变了的是升级路径。以前，遇到政策层面的事项(比如 LLM 生成的贡献该怎么处理、组织所有权归谁)，是有地方可问的。现在按公告的说法，指导委员会只是「一如既往地作为最终的兜底」留在那里。兜底不是通道。

而且按公告所说，两个人都打算减少在 Nixpkgs 的参与，也无意竞选指导委员会。也就是说，这个空缺会一直保持到有别人坐上那个位置为止。

在实务上这样应对：如果有对政策变化敏感的依赖，重新盘一遍 channel 固定和自有 overlay 的比重；安全公告不要只指望上游协调，确认一下自己的漏洞扫描路径；把迁移成本现在就算出来，写进文档。这不是说现在就搬，而是说要知道真到了非搬不可的时候，代价是多少。

怎样真正测量一个依赖的治理状况

星标数是人气指标，不是风险指标。但确实有能数的东西。下面的命令是可以真正跑起来的形式；GitHub 搜索 API 在不带认证时每分钟的请求限额很低，所以最好带上 token。

# 最近 90 天被合并的 PR 数 —— 吞吐量
OWNER_REPO="NixOS/nixpkgs"
SINCE="2026-05-11"
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/search/issues?q=repo:${OWNER_REPO}+is:pr+is:merged+merged:>=${SINCE}&per_page=1" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['total_count'])"

# 最近 100 个已合并 PR 实际由谁合并的分布 —— 权限的集中度
curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  "https://api.github.com/repos/${OWNER_REPO}/pulls?state=closed&per_page=100" \
  | python3 -c "
import sys, json, collections
prs = json.load(sys.stdin)
c = collections.Counter(p['merged_by']['login'] for p in prs if p.get('merged_by'))
for who, n in c.most_common(15):
    print(f'{n:4d}  {who}')
print('distinct mergers:', len(c))
"

第二条命令才是关键。如果贡献者很多，合并者却集中在少数几个人手里，那这少数几个人就是巴士系数。反过来，如果合并者分布很广，对个别成员离开的耐受度就高。

数字量不到的东西，就靠文档确认。决策机构有没有文档化，授权领域有没有写明，争议该往哪里升级有没有写，以及最近有没有这条路径真正生效过的案例。最后这一项最重要，却没法自动化。你得亲自去读 issue 追踪器和论坛。

耗竭是流程的产物，不是性格的产物

最后，把公告里我个人印象最深的一段搬过来。

公告承认社区里存在对治理的普遍不信任，并写道，这种不信任助长了对抗式的、零和式的冲突方式。接着它说：这种方式在面对领导层真空或者不作声的治理时也许有效，但面对一个愿意善意参与的领导团队时，它制造的是耗竭。

其结果，它诊断道：「不听的一方」反而得到回报；有时间也有意愿参与治理的资深贡献者池子进一步缩小；而「靠僵局和流失来做决定」这一历史现象则有固化的风险。

这个诊断并不局限于开源。它同样适用于公司内部的架构评审、代码所有者制度和平台团队。当被授权的团队实际上没有决策权，又没有正式的渠道来化解冲突时，冲突就会以最累的那个人先走的方式被化解。而以这种方式化解掉的冲突不会留下记录，所以下一次还会以同样的方式化解。

降低巴士系数，光靠多写文档是做不到的。把「谁能拍板什么」讲清楚，并且真正尊重这个拍板，占了一半。

参考资料

4,468 个已合并 PR 是 2026 年 8 月 9 日通过 GitHub 搜索 API 直接查询得到的值，而搜索 API 的结果会随查询时点而变化。

Discuss on Twitter • View on GitHub