Linux内核社区于2016年迎来了其二十五岁生日，很多朋友询问我们实现项目长久发展及成功的秘诀。对于这样的问题，我通常会以笑话回应——因为说实话，我也不知道这一切是怎样实现的。不过重要的是，我们之所以能够这样摸索向前，是因为社区自身拥有着强大的反省与变革能力。 　　大约十六年前，大多数内核开发者彼此从未谋面——大家只是通过邮件沟通。为了解决这个问题，随后出现了内核峰会。如今，Linux内核开发者们每年都会齐聚一堂，共同探讨技术问题并反思自己过去一年中哪些事做得对、而哪些事做得不够理想。我们会开发Git这类新型工具，从而不断改变彼此间协作的方式。 　　随着时间推移，这种演变带来了弹性，使得Linux项目能够不断迈上新的台阶，同时避免由fork带来的力量分散问题。也许其中确实有着一些重要的成功关键，下面我将试着阐述其中的9项启示。 　　1.保持较短发布周期非常重要。 　　在Linux项目发展早期，每套新的内核大版本往往需要数年才能发布一次。这意味着用户需要拿出大量时间等待新功能的加入，这对于使用者以及发行商而言都相当令人沮丧。不过更重要的是，如此漫长的周期意味着我们需要一次性整合大量代码，甚至不得不将很多尚未就绪的代码匆匆加入新版本。 　　较短的发布周期能够解决此类问题。新代码可快速被纳入稳定版本。以几乎即时的方式集成新代码使得最为重大的变更也几乎不会产生破坏性影响。开发者很清楚，即使他们错过了一个版本，那么再等两个月又会有新的版本，因此他们不必急于将不成熟的代码合并进来。 　　2.需要利用分布式分层开发模型实现流程可扩展性。 　　很久以前，一切变更都直接由林纳斯-托瓦兹负责，但这种作法很快被证明并不科学——毕竟没有任何一个人能够独力支撑起像操作系统内核这种多样的项目。因此，我们想到应该将内核中不同领域的事务交由不同且掌握对应专业知识的维护者处理。其中包括网络、无线网络、各类驱动程序子系统——例如CPI或USB——乃至ext2或vfat等独立文件系统。将代码审查与集成的任务交付至数百名维护者手中，最终使得Linux项目能够快速实现各个版本中的数万次变更，而不会影响审查或者成品质量。 　　没有正确的工具，内核这样的项目将随着自身体积的扩张而崩溃。 　　3. 工具很重要。 　　内核开发工作在规模方面一直面临挑战，直到BitKeeper源代码管理系统的出现——其几乎在一夜之间改变了社区的实践方式。而Git无疑是另一种飞跃。没有正确的工具，内核这样的项目将随着自身体积的扩张而崩溃。 　　4.内核的共识性判断模式非常重要。 　　作为一项基本原则，如果某位极具份量的开发者表示反对，那么提出的更改建议将不会被纳入项目当中。但是，这对于该代码的贡献者来说则是一种沉重的打击，毕竟他们已经耗费了数月时间用于相关工作。但这一举措亦确保了我们的内核能够适应广泛的用户需求与实际问题。没有哪个用户社区能够牺牲整体利益执行变更。因此，我们利用这种共识性关注保证项目只具备单一代码库，其能够涵盖由小型系统到超级计算机的各类应用场景。 　　5.内核的“无退化”原则同样重要。 　　十年之前，内核开发者社区曾经承诺如果特定内核可在特定设置下运作，那么全部后续内核也必须契合同样的条件。如果社区发现某项变更会导致退化，则必须快速解决这一问题。该原则向用户保证任何升级活动都不致破坏其系统，这样他们才乐于在开发新功能时采用我们的内核方案。 　　6.企业参与至关重要，但内核开发不会由任何单一企业所操纵。 　　自2014年12月发布的3.18版本以来，来自近500家企业的5062名个人开发者为Linux内核作出了贡献。大多数开发者能够从相关工作中获得酬劳，而他们做出的变更则可为其所在企业提供助益。然而，尽管任何企业都能够参与到内核的改进工作中来，但内核的发展方向绝不会为任何单一企业所操纵。 　　7.项目之内不应存在内部边界。 　　内核开发者必须专注于内核中的特定部分，但任何开发者都能够对内核的任意部分进行变更——只要这一变更存在合理性。这意味着问题将始终存在于其起源处，而非令人难以定位，而开发者则可对内核拥有更为全面的了解，甚至最为顽固的维护者也无法无限期地阻止任何针对特定子系统的改进。 　　8. Linux内核项目证明，大规模开发工作完全可以从小处起步。 　　最初的0.01版本内核仅包含1万行代码; 如今其每两天的代码增量就已经超过1万行。开发者目前添加的一些基本甚至微小的功能，未来都有可能发展成重要的子系统。 　　9. 25年的内核发展历程表明，持续合作可以带来任何单一机构都无法实现的辉煌成果。 　　自2005年以来，来自超过1300家企业的约14000名个人开发者为Linux内核作出贡献。正因为如此，Linux内核已经成为各类企业进行市场竞争时频繁使用的重要资源。