Linux 内核开发 25 年的 9 个教训

9 Lessons from 25 Years of Linux Kernel development

图片来源：

Internet Archive Book Images。由 Opensource.com 修改。CC BY-SA 4.0

因为 Linux 内核社区在 2016 年庆祝了四分之一个世纪的开发历程，许多人向我们询问该项目长寿和成功的秘诀。我通常会笑着开玩笑说，我们真的不知道我们是怎么走到今天的。这个项目一路走来面临着许多分歧和挑战。但说真的，我们能够走到今天，很大程度上与社区的反思和变革能力有关。

大约 16 年前，大多数内核开发人员从未见过面——我们只通过电子邮件互动——因此 Ted T'so 提出了内核峰会的想法。现在，每年内核开发人员都会聚在一起，解决技术问题，更重要的是，回顾我们在过去一年中做对了什么，做错了什么。开发人员可以公开诚实地讨论他们如何相互互动以及开发过程如何运作。然后我们做出改进流程的改变。我们开发新的工具，例如 Git，并不断改变我们合作的方式。

随着时间的推移，这种演变创造了一种韧性，使该项目能够从一个优势走向另一个优势，同时避免了那些分裂竞争项目资源的 forks。可能需要很多年我们才能完全理解 Linux 内核成功的关键，但即使现在也有一些经验教训脱颖而出。

1. 短发布周期很重要。

在 Linux 项目的早期，一个新的主要内核版本每隔几年才发布一次。这意味着将新功能提供给用户会产生相当大的延迟，这让用户和发行商都感到沮丧。但是，更重要的是，如此长的周期意味着必须一次集成大量的代码，并且即使代码尚未准备好，也存在将代码纳入下一个版本的巨大压力。

短周期解决了所有这些问题。新代码很快在稳定版本中可用。几乎持续不断地集成新代码使得即使是根本性的更改也可以在最小的干扰下引入。开发人员知道，如果他们错过一个发布周期，两个月后还会有另一个发布周期，因此几乎没有动力尝试过早合并代码。

2. 流程可扩展性需要分布式、分层开发模型。

很久以前，所有更改都直接发送给 Linus Torvalds，但这很快就被证明是笨拙的，因为没有人能够跟上像操作系统内核这样多样化的项目。很早的时候就出现了内核不同领域维护者的想法，其中内核一部分的责任被分配给熟悉该领域的个人。这方面的例子包括网络、无线、不同的驱动程序子系统（如 PCI 或 USB）或不同的单个文件系统（如 ext2 或 vfat）。将代码审查和集成的责任分散到数百名维护人员身上，使项目拥有资源来应对每个版本数以万计的更改，而不会牺牲审查或质量。

如果没有合适的工具，像内核这样的项目将根本无法在自身重压下正常运行。

3. 工具很重要。

在 BitKeeper 源代码管理系统出现并几乎在一夜之间改变了社区的实践之前，内核开发一直难以扩展；切换到 Git 带来了又一次飞跃。如果没有合适的工具，像内核这样的项目将根本无法在自身重压下正常运行。

4. 内核强大的共识导向模型非常重要。

作为一般规则，如果一位受人尊敬的开发人员反对，则提出的更改将不会被合并。这对于那些发现他们投入数月时间编写的代码在邮件列表中被阻止的开发人员来说，可能会非常令人沮丧。但它也确保了内核仍然适用于广泛的用户和问题。没有任何特定的用户社区能够以牺牲其他群体为代价进行更改。因此，我们拥有一个单一的代码库，可以从小型系统扩展到超级计算机，并且适用于广泛的用途。

5. 内核强大的“无回归”规则也很重要。

十多年前，内核开发人员社区承诺，如果给定的内核在特定设置中工作，则所有后续内核也将在那里工作。如果社区发现更改导致回归，他们会非常迅速地解决问题。该规则让用户确信升级不会破坏他们的系统；因此，他们愿意跟随内核开发新功能。

6. 企业参与该过程至关重要，但没有一家公司主导内核开发。

自 2014 年 12 月 3.18 版本发布以来，约有 5,062 名代表近 500 家公司的个人开发人员为 Linux 内核做出了贡献。大多数开发人员的工作都是有报酬的——他们所做的更改为他们工作的公司服务。但是，尽管任何公司都可以根据其特定需求改进内核，但没有一家公司可以推动开发朝着损害其他公司或限制内核功能的方向发展。