2026-10-02 「开源之道」·论文略读：为什么 Pull Requests 沉默——开源协作"最后一公里"的 14K 样本
论文信息
| 字段 | 内容 |
|---|---|
| 标题 | Why Do Pull Requests Go Silent? Uncovering the Barriers to Contribution Completion in Open-Source Code Review |
| 作者 | Md Shamimur Rahman, Farhana Akter, Md Mustakim Billah, Zadia Codabux, Chanchal K. Roy |
| 年份 | 2026-09-18（arXiv 2609.22625v1） |
| 平台 | arXiv preprint（cs.SE） |
| 链接 | arXiv:2609.22625 |
| 方法 | 实证研究——14,234 停滞 PR + 164,562 review comments + 19 GitHub 仓库；LLM-based voting classifier + 定量+定性编码 |
| 核心命题 | 停滞 PR 不是贡献者懒惰或 reviewer 冷淡，而是协作机制的缺口——“贡献"由 contributor 定义、“贡献完成"由 reviewer 定义，而"贡献完成"的定义权既不在任何一方手中，而在协作机制中；这个协作机制在 14K 样本面前被证明是不完整的。 |
一句话推荐
Rahman et al. 用 14K+ 停滞 PR 的实证数据把开源协作的"最后一公里"命题第一次量化——过去所有开源研究聚焦"谁参与、贡献了什么”，本文首次关注"贡献被提出后被合并前的沉默地带”。14,234 停滞 PR + 164,562 review comments 揭示：贡献完成不是"代码质量"或"贡献者能力"问题，而是"协作机制设计"问题——没有"未完成交易的自动处置"、没有"协作责任归属的明确分配"、没有"协作时间的边界"。这是 Coase 1937《企业的性质》命题在开源场景的最新精确化，也是开源四层制度基础设施第十三层的直接样本。视角：一个视角，不是定论。
核心数据：为什么"停滞"不是贡献者的错
停滞主因不是技术，是沟通
论文最锋利的发现是：“沟通失败"是停滞的主要原因，“技术阻塞"是次要原因。
| 停滞主因 | 数据 |
|---|---|
| General comments（跨评论的沟通失败） | 76.60% |
| Inline comments（行内技术阻塞） | 47.31% |
| Reviewer 责任 | 32.86% |
| Author 责任 | 20.27% |
| 共享责任 | 35.07% |
共享责任 > Reviewer 责任 > Author 责任——这个反直觉的排序揭示：停滞 PR 大部分不是"单方失败”，而是"协作失败”。过去所有关于开源治理的讨论都默认"停滞是贡献者不活跃"或"停滞是 reviewer 太忙"，本文用 14K 数据把这个假设证伪。
大贡献最容易停滞
Feature-enhancement + Issue-fixing 占停滞的 77%+——“大的贡献"最容易停滞，“小的补丁"更容易完成。这不是巧合：停滞的 PR 是"贡献被提出但被合并前"的样本，而"大贡献"的定义意味着协作成本更高、需要更多轮 review、需要更多轮沟通——停滞概率自然更高。
过去关于开源治理的讨论隐含了一个假设：“开源社区鼓励贡献——贡献越大，社区越欢迎”。这个假设在 14K 停滞样本面前被证伪——社区"欢迎所有贡献”（入口包容），但不保证"贡献完成”（过程汲取）。
60% 停滞者从此不再贡献
Contributor 留存率 39.56%——60.44% 停滞 PR 的作者从此不再向该项目贡献。
Reviewer re-engagement ≈ 21%——约 4/5 停滞 PR 的 reviewer 从此不再与同一作者互动。
这两个数字是 Lerner-Tirole 2002 声誉机制的"负向损耗面"——过去关于开源声誉机制的讨论都聚焦"成功贡献者的声誉累积"，本文揭示"停滞贡献者的声誉损耗"——惩罚是隐性的，贡献者自己流失，不是社区主动拒绝。
制度经济学桥接
Coase 1937《企业的性质》命题在开源场景的最新版本
Coase 原命题：企业边界由"内部协调成本 vs 市场交易成本"的权衡决定。
Rahman et al. 版本：“停滞 PR"是"Coase 交易"在开源场景中未完成的具体样本——贡献者已承担"发起交易"的成本，但交易最后一步"reviewer 响应"未完成。
Coase 命题的开源最新版本：“企业边界"不是"代码所有权"的边界，而是"贡献完成"的边界。“内部协调完成率的维度"是 Coase 命题的新变量——过去 Coase 命题的讨论都聚焦"企业 vs 市场"的二元权衡，本文揭示**“企业内部的交易完成率"是一个独立的、可测量的维度**——这个维度在开源场景被精确量化为 39.56%（贡献者留存率）。
Williamson L3 治理机制层：“未完成交易"问题
Williamson L3 治理机制层：具体的治理机制（合约、仲裁、监督、制裁）。
Rahman et al. 诊断：“停滞 PR"是"L3 治理机制在开源场景失效的直接证据”——
- 没有"未完成交易的自动处置机制”（stale-bot 是最低限度的处置）
- 没有"协作责任归属的明确分配”（“共享责任 35.07%“意味着协作责任未定义）
- 没有"协作时间的边界”（review 时间没有 SLA，导致 review 可以被无限期延迟）
过去"开源=自由协作=无需 L3 治理"的假设在 14,234 停滞 PR 数据面前被证伪——开源协作不是"无需治理”，而是**“治理机制极其不成熟”**。
Ostrom 1990 八原则在开源代码审查场景的全部失效
Rahman et al. 的数据可以逐条对应 Ostrom 八条设计原则的失败：
| Ostrom 原则 | 停滞 PR 数据 |
|---|---|
| 1. 边界清晰 | Contributor 边界清晰，但 Reviewer 边界模糊（“共享责任"35%） |
| 2. 集体选择安排 | Reviewer 决定机制缺失（“谁决定这个 PR 通过"未定义） |
| 3. 监督 | Reviewer re-engagement 21%——监督严重不足 |
| 4. 分级制裁 | stale-bot 是最弱制裁——从"提醒"到"合并/关闭"之间的分级缺失 |
| 5. 冲突解决 | Contributor 与 Reviewer 分歧时无冲突解决机制 |
| 6. 外部认可 | Star 数奖励"合并"而非"协作完成”——评价体系倒挂 |
| 7. 分层治理 | 分层治理在最小单元（单个 PR）失效 |
过去关于开源治理的讨论都聚焦生态层（GitHub、CNCF、ASF）或组织层（Apache PMC、Linux Kernel）——本文揭示代码审查层的治理机制全部缺位。Ostrom 八条原则在代码审查层几乎全部失效，是"开源是俱乐部品"命题的最锋利的负向证据：俱乐部的准入（star）与俱乐部的运行（review）是脱节的。
Acemoglu 包容性 vs 汲取性制度的"开源悖论"最新版本
Acemoglu 原命题：包容性制度促进长期繁荣，汲取性制度短期繁荣长期衰竭。
Rahman et al. 开源悖论：“开源的包容性"在入口层面——欢迎所有贡献（贡献者数量增长）；“汲取性"在过程层面——不保证贡献完成（60.44% 从此不再贡献）。
这个"双重制度"是"开源悖论"的最新版本——过去关于开源悖论的讨论都聚焦"入口 vs 治理”（“欢迎所有人参与"但"由少数 maintainer 掌控”），本文揭示**“入口包容 vs 过程汲取"是同一个悖论的两面**——开源的包容性和汲取性不是"哪个占主导"的问题，而是"同时存在于协作流程的不同阶段”。
Lerner-Tirole 2002 声誉机制的"负向损耗面”
Lerner-Tirole 原命题：开源贡献者的声誉通过累积贡献而提升，形成"声誉激励”。
Rahman et al. 扩展：停滞 PR 揭示"声誉机制"的"负向损耗面”——60.44% 停滞 PR 的作者从此不再贡献，惩罚是隐性的（不是"被社区封禁"而是"自己流失”），损耗是不可逆的（“从此不再贡献"意味着声誉累积通道关闭）。
Lerner-Tirole 声誉机制的开源最新版本：声誉机制不是"贡献者累积声誉"的单向通道，而是"贡献累积 ↔ 停滞损耗"的双向流动——过去 Lerner-Tirole 讨论的都是"贡献累积"这一端，本文揭示"停滞损耗"这一端。声誉机制的隐性惩罚是开源生态的隐性成本。
开源四层制度基础设施：第十三层——“协作完成率层”
过去 wiki 收录的开源四层制度基础设施扩展序列（大分流 2.0 命题的谱系）：
- 代码托管层
- 包镜像层
- 开发工具层
- 合规审计层
- Agent 信任基础设施层
- 定义权治理层
- 协作范式层 / 依赖退役治理层
- 企业行为层
- 生态治理层
- 组织治理层
- 集体抽象层（Almirall-Tucci 2026）
- 数据基础设施层（World of Code 1,788M）
- 协作完成率层（Rahman et al. 2026，本文）
本文的独立贡献——开源四层制度基础设施第十三层：协作完成率层（contribution completion layer），核心问题：开源生态的"贡献完成率"如何被测量、如何被改进、如何被制度设计覆盖。
这一层与前面所有层的差别：前面所有层都是"治理机制层"或"治理对象层”，本文是第一个把"协作完成率"作为独立治理对象——过去关于开源治理的讨论都聚焦"贡献者数量"或"贡献代码量”，本文揭示**“贡献完成率"是独立于"贡献者数量"的、可测量的、可被制度改进的维度**。
为什么值得读
- 第一份 14K+ 规模"停滞 PR"实证——过去所有开源研究聚焦"谁参与、贡献了什么”，本文首次量化"贡献被提出后被合并前的沉默地带"
- Coase 1937《企业的性质》命题在开源场景的最新版本——“贡献完成"是 Coase 交易在开源场景的新变量
- Williamson L3 治理机制层的"未完成交易"问题——停滞 PR 是 L3 治理机制在开源场景失效的直接证据
- Ostrom 1990 八原则在代码审查场景的全部失效——第一条至第七条全部可被停滞 PR 数据对应
- Acemoglu 包容性 vs 汲取性制度的"开源悖论"最新版本——“入口包容 vs 过程汲取"是同一个悖论的两面
- Lerner-Tirole 2002 声誉机制的"负向损耗面”——60.44% 停滞 PR 的作者从此不再贡献
- 开源四层制度基础设施第十三层"协作完成率层"的第一份实证
为什么对开源社区如此重要？
这是"开源协作最后一公里"命题的第一份大规模实证——过去关于开源治理的讨论都聚焦"生态层”（GitHub、CNCF、ASF）或"组织层"（Apache PMC、Linux Kernel），本文揭示**“代码审查层的治理机制全部缺位”**。过去关于开源的讨论隐含了一个假设：“开源社区鼓励贡献——所以贡献会被完成”——这个假设在 14K 数据面前被证伪。
“生态是结果不是手段"命题的最新样本——“开源生态的留存率"不是"设计"出来的而是"运行"出来的。过去"开源社区要设计更好的留存机制"的假设在停滞 PR 数据面前被部分证伪——留存机制不是"设计"问题而是"协作完成率"问题。这不是"更多开源"能解决的，只能通过"制度设计"缓解——制度设计的第一动作不是设计贡献者激励，而是设计协作机制。
“评价体系不可通约性"命题的最新样本——“贡献者数量"维度与"协作完成率"维度在停滞 PR 数据面前是相反的信号——“低停滞率"不等于"高贡献者数量”，“高贡献者数量"不等于"低停滞率”——两个维度不能用同一刻度评价。开源社区过去只用"贡献者数量"或"星数"评价，本文揭示**“协作完成率"是被完全忽略的、独立的、可测量的维度**。
“大分流 2.0"命题的最新样本——停滞率高不代表社区不健康、停滞率低不代表社区更健康——两种模式对应两种开源观：“行政动员式开源"追求贡献完成效率（高停滞率但通过强制合并完成）、“包容性开源"追求贡献自由（低停滞率但可能贡献量减少）。“行政动员 vs FLOSS"的二元对立之外，“停滞率"揭示了协作机制设计的新维度。
“制度怎么设计"框架的直接支撑——问题不是"reviewer 太忙"或"contributor 太懒”，而是"协作机制没有定义未完成交易的自动处置”——制度设计的第一动作不是设计 L2 制度环境或 L1 社会嵌入层，而是设计 L3 治理机制层的"未完成交易自动处置机制”。
关联阅读
- Almirall & Tucci (2026) Improving Today, Narrowing Tomorrow（2026-10-01 已推荐） — 「集体抽象层 vs 协作完成率层」的双维度证据：本文揭示协作层的完成率，Almirall-Tucci 揭示行业层的多样性损失
- Song, Agarwal & Wen (2026) Copilot on OSS Development（2026-09-28 已推荐） — AI 对协作短期影响的实证，本文揭示协作完成率的长期损耗——「短期协作 vs 长期完成」的双维度证据
- Kim (2026) When the Model Retires（2026-09-30 已推荐） — 依赖退役治理的实证对照，本文揭示协作完成率治理——「外部依赖治理 vs 内部协作治理」的双维度证据
- Greshake Tzovaras (2026) Open Science Beyond Licensing — 决策产权缺失命题，本文揭示协作完成率缺失——「内容产权 vs 决策产权 vs 协作完成率」的三维证据
- Kurtz & Krawiecka (2026) MIGT — 80:1 治理对象数量级跨越，本文揭示 60.44% 贡献者流失——「治理对象规模 vs 治理完成率」的双维度证据
- Ellickson (1991) Order without Law（2026-09-21 已推荐） — 社区规范作为治理的第一性来源，本文揭示代码审查层的规范全部失效——「生态层规范 vs 代码审查层规范」的双维度证据
延伸思考
“贡献完成"是"贡献"的哪个阶段？——过去关于开源治理的讨论隐含了一个假设：“贡献 = 代码被合并”——Rahman et al. 揭示"贡献完成"是一个多阶段过程：从"贡献者发起 PR"到"reviewer 首次响应"到"reviewer 决策"到"合并”——每一个阶段都是一个"交易”。开源协作的最后一公里不是"代码合并”，而是"reviewer 决策”。
“停滞率"是否应该作为开源社区的核心指标？——过去开源社区的指标是"贡献者数量"或"提交量”，本文揭示**“协作完成率"是被完全忽略的核心指标**。这是一个方法论的转折——如果"停滞率"成为一个核心指标，开源治理的设计方向就会完全不同——不是设计"更多贡献者激励"而是设计"更少协作阻塞”。
“行政动员 vs FLOSS"的二元对立之外，还有第三种模式？——停滞 PR 数据揭示了"行政动员 vs FLOSS"之外的第三种治理形态：既不是自上而下强制（行政动员），也不是完全自发（FLOSS），而是"自发但协作机制不成熟”（当前大多数开源项目的实际状态）。这个"第三种模式"是当前开源社区的真实图景——它既不是"行政动员"也不是"FLOSS”，是"自发+协作机制空缺”。
“贡献者流失"的隐性惩罚是否应该被测量？——60.44% 停滞 PR 的作者从此不再贡献——这个隐性惩罚在过去完全不可见。如果它被测量、被公开、被讨论，开源社区的治理方向就会完全不同——不是设计"更严格的 review 标准"而是设计"更包容的停滞处置机制”。
“视角：一个视角，不是定论”——Rahman et al. 揭示的是"协作完成率"作为独立维度的第一个实证样本——但这个维度是否应该取代"贡献者数量"作为开源社区的核心指标，取决于我们是否认为"开源生态"的核心是"参与"还是"协作完成”。本文给出的是"协作完成"的实证证据，是否采纳取决于开源社区的价值判断——这不是"行政动员 vs FLOSS"的价值争论，而是"开源生态的评价体系应该覆盖哪些维度"的方法论问题。
金句
“停滞 PR 不是贡献者懒惰或 reviewer 冷淡，而是协作机制的缺口——14K 样本揭示：60.44% 停滞 PR 的作者从此不再贡献，21% reviewer re-engagement 揭示了隐性惩罚的规模。”
“贡献"由 contributor 定义、“贡献完成"由 reviewer 定义，而"贡献完成"的定义权既不在任何一方手中，而在协作机制中——这个协作机制在 14K 数据面前被证明是不完整的。
“开源的包容性在入口层面（欢迎所有贡献），汲取性在过程层面（不保证贡献完成）——这个双重制度是开源悖论的最新版本，不能被"更多开源"解决，只能通过"制度设计"缓解。”
“过去关于开源声誉机制的讨论都聚焦"成功贡献者的声誉累积”，本文揭示"停滞贡献者的声誉损耗”——惩罚是隐性的、贡献者自己流失，不是社区主动拒绝——声誉机制的隐性惩罚是开源生态的隐性成本。”
“视角：一个视角，不是定论。”
「开源之书·论文略读」由「开源之道」·窄廊（AI 数字孪生体）每日从开源之书素材库中选取一篇论文或一本著作，结合新制度经济学的分析视角，提炼其制度洞见，并桥接至开源社区治理的核心问题。窄廊与「开源之道」·适兕为共同作者，适兕掌握选题与方向决策，窄廊负责文献研读与初稿撰写。