高昂的PR,开源的困惑

我是个急性子，所以没怎么成功给社区提过PR，除非那个项目是我自己的，或者社区让我有直接Merge的权限。好比之前吐槽完SDL开发太慢后，自己直接fork了一份，然后在上面加功能。

PR是开源社区的基石，正真实践了开源的益处：“人人贡献，人人受益”。

一个PR提出后的历程还是比较长的。如果很多人关注和讨论，可能促使你的PR早日受到项目维护者的关注，尽快合并进去。大家会不停地给意见，你根据意见不断的调整，在这个期间，可能还有新的代码合入，这个时候你可能需要反复修正冲突。

在项目CodeBase还不大的情况下，一切看起来很美好。但是项目一旦到大到一定程度后，合并PR的代价就会变得极为的高昂。因为项目大到一定程度，质量要求会变得很高，否则是没办法继续下去的。如果不控制好质量，很可能就需要重构才能让项目继续走下去。而PR天生来源复杂，质量参差不齐，光review的成本就已经很高了，更别说反复的交流修改碰撞带来的时间代价，很多情况甚至review的人相当于重写了一遍。第二个是，新的PR极容易造成regression,以前修好的问题又出现了，或者出现新的问题。所以这个时候合并一个新的PR基本已经很困难了，或者说远远已经超过了专门维护人员的成本。

通常PR无非是：

1. Bug 修复
2. 新特性添加
3. 原有功能增强

最终社区会区别对待（感谢smilegator提供的信息）：

1. Bug Fix 会有限确认并且merge
2. 新特性会首先确定Risk和Impact,而不是这个feature本身的价值
3. 好而且大的feature 一般还是会offline 去讨论的，并且会提出design doc

所以我们看到，此时你提的PR，价值已经很小了，顶多是给个示例。这或许也是一个困境，我们总是希望人人都能够贡献，然而接受这种贡献的成本在到某个阶段就变得高昂了，这可能违反了我们的直觉。这和开源一样，最终还是需要商业的回馈，方能开花结果。

哦，对了，所以维护自己重度使用的私有版本的开源项目，会变成一个必然的选择。