接受外部贡献，就是接受一项长期维护责任 Pull Requests Are Free Puppies
以下内容与我的工作无关，仅为个人感想与学习笔记，不代表任何公司或机构的立场。
These notes are unrelated to my work. They are personal reflections and study notes only, and do not represent the views of any company or organization.
本文是对以下内容的阅读笔记：Lobsters 讨论帖《Pull Requests Are Free Puppies》（经阮一峰《科技爱好者周刊》读到） These are reading notes on: the Lobsters thread “Pull Requests Are Free Puppies” (found via Ruan Yifeng’s Weekly, 《科技爱好者周刊》)
摘要
Pull Request 不是一份免费的代码礼物，而是把一项功能未来的维护责任转交给项目所有者。判断是否接受外部贡献，不能只看它现在增加了什么功能，还要估算未来在审查、测试、文档、兼容、安全和认知负担上的持续成本。
核心判断
一个 PR 的真实净价值可以粗略表示为：
PR净价值 = 新增功能价值 - 生命周期维护成本
代码合并只是责任的起点。进入主干以后，项目维护者通常需要长期承担：
- 审查实现是否符合项目方向与质量标准
- 为功能补充或维护测试、文档和示例
- 处理后续缺陷、安全问题与用户支持
- 在架构演进时维持兼容性
- 理解并记住新增的概念、接口和例外情况
- 在原贡献者离开后继续维护
因此，“代码已经有人写好了”不等于“这个功能值得进入核心代码库”。
合并前的决策清单
- 这项功能是否服务项目的核心使命？
- 如果贡献者明天消失，我们仍愿意维护它吗？
- 它是否扩大了公开 API、兼容性或安全承诺？
- 测试、文档和失败路径是否足够完整？
- 新增价值能否覆盖未来数年的维护成本？
- 是否可以通过插件、扩展或独立项目实现，避免进入核心？
- 项目中是否有明确的长期责任人？
“免费小狗”比喻
SQLite 作者 Richard Hipp 将外部 PR 比作别人送来的一只免费小狗：获得它不需要付钱，但从接收的那一刻起，就必须喂养、照顾并为它的整个生命周期负责。
提交一个 Pull Request，就相当于有人送你一只免费的小狗。
这个比喻提醒我们：开发成本只是显性成本，维护责任才是更长久的成本。
适用边界
SQLite 追求极高稳定性，并由小型核心团队长期维护，因此可以选择拒绝所有外部 PR。其他开源项目不必照搬这一政策；更通用的做法是建立清晰的准入标准、模块边界和代码所有权。
外部贡献仍然可以带来创新、修复和社区活力。关键不是“拒绝 PR”，而是不要把贡献者的一次性开发投入，误认为项目的零成本收益。