34 如果内核不是由 Linus 创建和维护，会怎样？

本节是一首歌颂Linux内核贡献者的打油诗，小方翻译时，雅致谈不上，只能尽量表达其原意。

​ ——译者：张小方

到 20 世纪 90 年代初，相关理念已初具雏形。

GPL（通用公共许可证）为软件自由奠定了法律框架。

UNIX 展现了可组合系统的强大力量。

自由软件工具正广泛传播。

但理念无法自行构成一个系统，

更无法形成一个持久的系统。

接下来发生的不只是一个项目，

而是一系列清晰、务实且悄然激进的决策。

Linus 将内核按 GPL 发布，

此举并非为了发表声明，而是为了让所有人的贡献都能安全纳入。

他选择 C 语言，

并非出于怀旧，而是因为它能提供精确性、可预测性以及对每个字节的控制。

他构建了具有模块化边界的单体内核，

在性能与灵活性、简洁性与可扩展性之间取得平衡。

当内核发展超出原有工具的支持范围时，

他没有等待解决方案，

而是自己编写了一个。

Git 不仅仅是工具，更是大规模信任的基础设施。

最重要的是，他创建了一种变革需肩负责任的流程：

子系统有所有者，

所有权意味着审查，

审查意味着信任。

代码并非通过共识在 kernel 中流动，

而是通过信任链流转：

从贡献者到维护者，从维护者到集成树，

再通过拉取请求到达 Linus。

每一步的把关依据并非头衔，而是赢得并维持的信任。

这种信任成为了结构，

而这种结构得以存续。

这并非由某个基金会设计，

也不是从委员会中产生，

更不是为速度而优化。

它由约束塑造，

源于在不丧失可靠性的前提下管理复杂性的需求。

这正是它得以扩展的原因，

得以吸纳新架构、驱动程序、文件系统、调度器，

得以引入成千上万的贡献者，

同时不损害系统的完整性。

不难想象另一种起源：

由企业发起，

由委员会驱动的标准，

为某产品线构建的内核，仅维护至下一个产品发布。

或许它会附带保密协议而非邮件列表，

或许补丁需通过审批链而非公开审查，

或许开发速度会更快——直到某一天无法继续。

它可能更早被采用，

可能发布时功能更多，

但不会像现在这样持久。

内核的持久力不仅仅源于清晰的抽象或巧妙的代码，

更是关于如何接受变革、如何分担责任、如何赢得并维护信任等决策的结果。

这些决策早早做出，

始终如一地执行，

历经时间考验。

没有任何部分是必然的，

它的存续并非与生俱来，

而是通过纪律、结构和信任得以维护。

它仍在运行，

不是因为一成不变，

而是因为它被设计为可谨慎变革，

因为信任从未被视为事后考虑。

而这，同样是一个决策。