在 GitHub 上做贡献，像不像捐精？
Published:
这里有一个不太登大雅之堂、却抓住了开源工作某些真相的类比：
在 GitHub 上到处开 issue、提 pull request，出奇地像捐精——而不是太像捐卵。
这个类比是刻意挑衅的。它不是对性别或两种捐献形式价值的论断。它描述的是复制的成本、贡献的数量和选择三方面的不对称。
为什么这个类比成立
一个 issue 或 PR 携带作者的一小片信息：一个问题定义、一个设计偏好、一个编码模式、一套关于系统应该如何运作的想法。这份信息进入别人的项目，与别人的想法相遇。
于是有几条结构性上的相似：
- 贡献者可以大规模贡献。 一个人可以给很多仓库开 issue 或提交补丁。
- 复制的边际成本很低。 一旦一个想法被表述出来，它就能被改编、并在别处提出。
- 过程是开放的。 贡献者通常不需要雇佣合同、机构归属，也不需要对维护者事先认识。
- 接收方做选择。 维护者决定是拒绝、修改、合并还是忽略这份贡献。
- 大多数贡献不会传播。 很多 issue 得不到任何行动。很多 PR 永远不会被合并。少数进入项目历史、影响后来的版本。
- 贡献者与一个更大的基因库交换信息。 评审把贡献者的假设与仓库的架构、标准、积累的知识结合起来。
- 署名存续，控制变弱。 Git 记录着作者身份，但维护者可能修改、重构、回退、或最终替换这份贡献。
这个过程里也有愉悦。你注意到一个问题、构想一个干预、把它送进世界，然后等着看它是否连上了。当它连上时，你的想法就成了一个比自己更大的系统的一部分。
为什么它更像捐精、而不是捐卵
关键区别是经济与生物层面的，不是道德层面的。
捐卵涉及有限的数量、医疗干预、恢复时间、筛查和可观的身体成本。精子则能以大得多、边际成本低得多的数量被生产与捐献。
大多数 GitHub 贡献属于第二种成本结构。想法和文字可以被复制。issue 可以很快提交。一个补丁有时可以跨仓库改编。平台允许高数量贡献，几乎没有正式障碍。
这并不表示贡献没有成本。理解一个代码库、复现一个 bug、设计一个兼容的修复、写测试、回应评审，可能耗费数天甚至数月。这个类比更适合随手开 issue，而不是深度的工程工作。
issue 和 PR 不是同一种贡献
当我们不再把所有 GitHub 活动归为一类时，这个隐喻就更有用。
| GitHub 动作 | 实际贡献了什么 |
|---|---|
| 开一个 issue | 一个问题、观察或请求 |
| 写一份提案 | 一个问题模型和一条可能的方向 |
| 提交一个 PR | 一份请求进入代码库的实现 |
| 评审代码 | 选择、纠正和重组 |
| 合并 | 被接纳进入项目的谱系 |
| 维护 | 对贡献能否存续负责 |
| 分叉 | 一条有着不同选择压力的新谱系 |
| 回退 | 移除一个在其环境中失败的特征 |
一个 issue 接近于把一个想法释放进一个群体。一个 PR 携带得更多：它把想法打包成一个必须与既有生物体交互的产物。
但一个认真的 PR 仍然不能只是被描述为捐献。一旦作者研究仓库、谈判设计选择、修订补丁、添加测试、并在合并后仍保持在场，这种关系就变成了合作开发。
类比在哪里失灵
软件不是生物学。
第一，代码允许精确复制。生物遗传不允许一个捐献者以几乎为零的成本把同一份完整贡献送进成千上万个环境。
第二，GitHub 贡献保持着可编辑性。作者可以在评审后修订补丁、把它拆成更小的改动、撤回它、或者几个月后带着更好的设计回来。
第三，项目可以逆转合并。一次合并可以回退。一个仓库可以被分叉。一个实现可以在提交仍留在历史里时被替换。
第四，维护者做的远不只是选择。他们解释本地约束、引导工作方向、补上缺失的上下文、有时合著最终方案。在贡献改变项目之前，接收项目先改变那份贡献。
最后，成功不是繁衍。一个没人用、产生了维护成本、或者在下个版本里被移除的合并 PR，几乎一无所成。更强的检验是：这份贡献是否继续在解决一个问题。
让人不舒服的教训：充裕让小择事变更重要
当贡献变得便宜时，注意力就变得稀缺。
开源平台让大规模分发想法成为可能。同样的机制也带来了模糊的 feature 请求、重复的 issue、路过打一枪的补丁、AI 生成的 PR，以及把验证成本转移给维护者的工作。
这改变了核心问题。它不再是：
我贡献过多少个仓库？
而是：
我的贡献为那些对项目负责的人，消除了多少不确定性？
一个有用的 issue 证明问题存在、界定其范围、并与已知案例区分开来。一个有用的 PR 贴合架构、通过测试、解释其取舍，并减少而非输出维护负担。
高数量产生曝光。它本身并不产生影响。
从传播基因到养育后代
这个类比在开源最零承诺的那一端最有趣、也最准确：开很多 issue、提出很多想法、把小块补丁送进陌生的项目。
随着责任增加，它变得越来越不准确。
提交一个想法是传播。让它通过评审是选择。让它被合并是继承。在未来的版本里持续维护它，则是另一回事：养育。
这正是”在 GitHub 上只留下一串痕迹”与”和别人一起建造东西”之间的分界线。最出色的开源贡献者不只是广泛地分发自己的想法。他们待得足够久，帮助那些想法在与现实的接触中活下来。
相关文章：