Linux 内核社区迁移到 github?

Daniel 说，这篇文章的写作动机来自两个事情：

其一是在 maintainerati 会议 (一个开源软件维护者的业内聚会) 上的讨论。 Daniel 和几个开源软件维护者讨论了如何扩展真正的大规模开源项目，以及 Github 如何强制项目只能以几种特定的方式来扩展。而 Linux 内核开发恰恰使用了不同的模型，这些正是在 Github 上搞开源的维护者不懂的，因此 Daniel 在讨论中解释 Linux 如何运作，以及 Linux 模型为何不同；

其二是在 Daniel 的另一篇博客 Maintainers Don’t Scale 的评论区里，支持最高的评论就是 “……为啥这些恐龙们不去使用现代的开发工具?“。(其实这个问题曾经在笔者心中也盘旋了很久….) 一些内核社区顶级的维护者，捍卫者传统的邮件列表及布丁的提交方式，抵制使用 Github pull request 的方式。难道真的就是这一小撮掌权者的问题？Daniel 认为不是的。根本原因是，Github 的模式根本支撑不来 Linux 内核这种有着巨大体量的贡献者的开发模式。因此，哪怕是把内核社区的几个子系统移到 Github 上开发都是不可能的。Daniel 说，这不仅和托管 git 的数据有关，而且还和 how pull request, issue 和 fork 这几个 Github 的功能的工作方式有关。(写到这里，我有点儿怀疑这种结论，Github 那么多大型项目，托管整个社区也就罢了，说连个内核子系统都搞不定，就有点儿糊弄人了吧？)

Github 扩展的方式

Git 牛的地方就是让每个人都可以很方便地 fork 开源项目，在其上创建分支。最后一但有了不错的改进，又可以基于上游主仓库创建一个 pull request，并且得到代码的 review，测试，然后被合并。Github 也很牛，因为它把这些 Git 复杂的方式都用 UI 简单化了，易学易用，让新手很容易去为开源项目做贡献。

最终，一个获得巨大成功的开源项目，没办法在一个代码仓库里，能够利用 tagging, labelling, sorting, bot-herding 和 automating 等手段管理好所有 pull request 和 issue，于是就必须通过把单一代码库拆分成多个可管理的部份组成。更重要的是，项目的各部分因为规模和成熟度的不同，需要不同的规则和流程：非常新的实验性质的库，与主线代码相比，有不同的稳定性和 CI (持续集成) 条件。并且，或许项目里还有一大堆过时的，不会被支持的代码，但是目前还不能删除：这需要把非常大的项目拆分成多个子项目，每个子项目都有自己风格的流程，合并条件，独立的仓库，独立的 pull request 和 issue 的跟踪。一般来说，直到管理的开销成为痛点，庞大的重组成为必要时，项目管理可能需要几十甚至几百全职的贡献者。

几乎所有的 Github 托管项目，解决这个问题时，都是靠把单一的源码树，按照功能区分，拆分成许多不同的项目。通常拆分的结果就是，一些核心代码，加上一堆插件，库，和扩展的代码。所有这些通过某种插件或者安装包管理器再构建到一起，在一些情况下，可能就是直接从其它的 Github 仓库里直接拉取代码构建。

因为几乎所有的大项目都是这么搞的，在这里，Daniel 不再赘述它的好处，而是主要把这种做法的缺点指出来了，这里简单摘要如下：

• 社区被不必要地割裂了。大多数贡献者只有他们直接贡献代码的仓库，忽略掉了项目的其它部份。这个对他们有好处，但是也会导致在不同的子项目里并行的，重复的工作被及时发现，并且共享成果。
• 项目重构和代码共享存在导致低效的障碍：首先你需要为新代码