在 GitHub 到处提 Issue 和 PR，为什么像“捐精”而不像“捐卵”
Published:
我提一个不太恰当、但确实抓住了开源协作某种结构的比喻：
在 GitHub 到处提 issue 和 PR，非常像“捐精”，但不太像“捐卵”。
这个比喻故意带有冒犯性。它不讨论性别，也不评价两种捐赠的价值。它描述的是一种关于复制成本、贡献数量与筛选权的不对称。
为什么这个比喻成立
一个 issue 或 PR 携带了作者的一小段信息：问题定义、设计偏好、代码模式，以及对一个系统应该如何运行的判断。这段信息进入别人的项目，与其他人的思想发生接触。
两者因此呈现出一些相似结构：
- 贡献者可以大量贡献。 一个人可以向许多仓库提交 issue 或 patch。
- 复制的边际成本低。 一个想法形成以后，可以被修改、复制并投向其他场景。
- 过程开放。 贡献者通常不需要劳动合同、机构身份或与 maintainer 的既有关系。
- 接收方掌握筛选权。 Maintainer 决定拒绝、修改、合并，还是不作回应。
- 大多数贡献不会传播。 很多 issue 没有后续，很多 PR 永远不会 merge；只有少数会进入项目历史，影响未来版本。
- 贡献者进入了更大的“基因池”。 Review 会把个人判断与仓库的架构、规范和积累的知识重新组合。
- 署名保留，但控制权下降。 Git 记录作者，但 maintainer 可以修改、重构、revert，或者最终替换这项贡献。
这个过程还会带来一种直接的快感：你发现问题，形成干预，把它发送到世界上，然后等待它能否与某个项目发生连接。如果连接成功，你的思想就成为一个更大系统的一部分。
为什么更像“捐精”，而不是“捐卵”
这里相关的区别来自成本结构，而不是道德判断。
捐卵面对有限供给、医疗干预、恢复时间、严格筛选和身体成本。精子则能够以更大的数量和更低的边际成本产生与捐赠。
多数 GitHub 贡献采用后一种成本结构。思想和文本可以复制，issue 可以快速提交，一个 patch 有时也可以迁移到多个仓库。平台允许贡献者在很少的正式限制下进行大规模传播。
这不代表贡献没有成本。理解代码库、复现 bug、设计兼容方案、编写测试和回应 review，可能消耗几天甚至几个月。因此，这个比喻更适合随手提交的 issue，而不完全适合深度工程贡献。
Issue 和 PR 不是同一种贡献
如果不再把所有 GitHub 活动混在一起，这个比喻会更有解释力。
| GitHub 行为 | 实际贡献的东西 |
|---|---|
| 提交 issue | 问题、观察或需求 |
| 撰写 proposal | 问题模型与可能路线 |
| 提交 PR | 请求进入代码库的实现 |
| Code review | 筛选、纠错与重组 |
| Merge | 进入项目谱系 |
| 持续维护 | 对贡献能否存活承担责任 |
| Fork | 在不同选择压力下形成新谱系 |
| Revert | 移除未能适应环境的性状 |
Issue 接近向一个群体释放思想。PR 携带了更多东西：它把思想包装成一个必须与既有系统发生作用的实现。
但严肃的 PR 也不能只用“捐赠”描述。当作者理解仓库、协商设计、修改 patch、补充测试，并在 merge 之后继续维护时，双方已经进入共同开发关系。
这个比喻在哪里失效
软件不是生物。
第一，代码允许精确复制。生物遗传无法让同一位捐赠者以接近零成本，把同一份完整贡献发送到数千个环境。
第二，GitHub 贡献可以持续编辑。作者可以根据 review 修改 patch，把它拆分成更小的变更，撤回它，或者几个月后带着新方案回来。
第三，项目可以逆转合并。Merge 可以被 revert，仓库可以被 fork，实现可以被替换，而原始 commit 仍留在历史中。
第四，maintainer 不只进行筛选。他们还会解释局部约束、调整工作方向、补充缺失信息，有时会与贡献者共同完成最终方案。接收项目先改变贡献，然后贡献才改变项目。
最后，merge 不等于成功。一个无人使用、制造维护成本或在下个版本就被删除的 PR，并没有产生多少作用。更严格的检验是：这项贡献是否持续解决了一个问题。
一个令人不适的结论：贡献越充足，筛选越重要
当贡献变得便宜，注意力就会成为稀缺资源。
开源平台让思想可以被大规模传播。同一套机制也会制造模糊的功能请求、重复 issue、一次性 patch、AI 批量生成的 PR，以及把验证成本转嫁给 maintainer 的“贡献”。
因此，核心问题不能再是：
我向多少个仓库贡献过？
而应该是：
我的贡献替项目负责人消除了多少不确定性？
一个有用的 issue 需要证明问题存在、界定问题范围，并把它与已知情况区分开。一个有用的 PR 需要适配架构、通过测试、解释取舍，并减少维护负担，而不是把负担转交给别人。
大量传播能够提高曝光，但不会自动产生影响。
从传播基因到共同养育
这个比喻在开源协作中承诺最低的那一端最准确，也最好笑：到处提 issue、到处表达想法、向不熟悉的项目提交小 patch。
随着责任增加，它会越来越不准确。
发送一个想法是传播，接受 review 是筛选，被 merge 是遗传，跨越多个版本继续维护则是另一件事：共同养育。
这条线区分了两种行为：在 GitHub 到处留下痕迹，和真正与别人共同建造系统。最强的开源贡献者不只让思想广泛传播。他们还会留下来，帮助这些思想经受现实的检验。
相关文章：