↖  Linux操作系统30周年专访创始人Linus Torvalds..

[编按： 转载于 新浪微博/程序员编辑部, 2021-08-25. 原标题为“Linus：“免费”不是最重要的，“源代码公开”才是，Linux 30岁生日”。]

【编者按】1991年8月25日，21岁的Linus Torvalds（以下简称Linus）做了一个免费的操作系统“Linux”，并在这一天向外界公布这个由“业余爱好”主导的个人项目；如今，全球超级计算机500强和超过70%的智能手机都在运行Linux，因此，8月25日也被许多Linux的爱好者视为Linux真正的诞生日期。

30年来，Linus一直领导着Linux内核开发，并在2005年创建Git。在Linux 30周年之际，Linus接受了Tag Consulting创始人&首席执行官Jeremy Andrews（以下简称Jeremy）的采访，深入谈起30年来管理如此大型开源项目的经验与思考。

Linux与Git

1.Linux内核之旅

Jeremy：今天，Linux将迎来它的30周年纪念日。在这段旅程中，你是在什么时候意识到自己所做的Linux并不仅仅“只是一个爱好”的？

Linus：我很早就意识到这一点。在1991年末（以及1992年初），Linux已经比我预想的要大很多。那时可能只有几百个用户（甚至都不能算是“用户”，人们只是在不断地对其进行修补），虽然当时还不至于考虑将Linux发扬光大，但就个人而言，最大的转折点是当我意识到真有人在使用它，并对它感兴趣时，它开始有了自己的生命。人们开始发送补丁，而且我渐渐发现这个系统能够完成的事情远比预想的要多。

Linux 30周年官方海报

在我的记忆中，X11大概是在1992年4月被移植到Linux上的，这可以算是又一里程碑式的大动作：GUI以及一套全新的功能横空问世。从这个角度来看，我最初并没有什么高期望的大计划。它只是个人项目，也并非出于什么创造新的操作系统的伟大梦想，只是由我对新PC硬件的深入学习而逐渐发展演变形成的。

因此，第一版实际上更像在说“快来看！我做了一个新东西”。我当然希望大家会觉得它很有趣，但那时它并不是一个真正严谨且可用的OS。它的存在更像是为了证明概念的可行性，是仅用几个月完成的个人项目罢了。

从个人项目到有人使用、发送反馈及偶尔的补丁，这对我来说是一个巨大的转变。

举一个最基本的例子：在原始版本中，可以用源代码的形式发布，但不能盈利。因为对当时还是学生的我来说，商业UNIX太贵了。对我而言，源代码可用是非常重要的，只有这样人们才能对其进行修补，而且我希望它能对像我这样负担不起其他选择的人开放。

我在1991年底（或1992年初）把许可证改成了GPLv2，因为有人想把它以软盘的形式分发给本地UNIX用户组，同时希望能至少收回软盘成本和时间成本，而这个诉求其实是完全合理的。“免费”不是最重要的，“源代码公开”才是。

最终的结果是：人们不仅在UNIX用户组会议上进行了发行，而且在短短的几个月内便出现了SLS（Softlanding Linux System）和Slackware等早期软盘发行版。

除了那些最初的根本性变化，其他一切都是“渐进式”的。当然，有些渐进变化是相当大的（IBM的加入、Oracle DB移植、Red Hat的首次公开募股、Android在手机上的应用发展等等），但对我而言，这些变化都不如最初发现有很多人都在使用Linux那么具有革命性。

Jeremy：你是否曾为自己的许可证选择后悔过？或者曾为其他人/公司从你创造的系统上赚了多少钱而后悔？

Linus：从未后悔过。首先，我过得还不错。虽然并不算特别富有，但作为一名高薪的软件工程师，我可以按照自己的节奏做喜欢做的事，保持一个相对舒适的状态。

与此同时，我100%地相信许可证是Linux（以及Git）成功的重要组成部分。我始终坚信要让大家都知道自己具有平等的权利且没有人在许可方面享有特权，这对所有人来说都是一件好事。

现在，有非常多的“双许可证”项目：原始所有者保留了商业许可证（支付许可证费用便可在自己的专利产品中使用它），但另一方面，该项目也可以在GPL（通用公共许可证）等情况下开源。

我认为要想在这种情况下建立社区是非常困难的，因为开源的一方总是知道自己的“二等公民”身份。另外，要想让享有特权的一方始终保持其特殊权利，必然需要大量的许可文件，这给项目增加了很多额外的阻力。

另一方面，我见过许多BSD（或MIT等）许可的开源项目，当其规模逐渐扩大到具有商业重要性时，就会走向四分五裂的局面，相关公司必然会把属于自己的部分变成专有的部分。

我认为GPLv2能够实现“所有人都在相同规则下工作”与“要求人们回馈社区”的完美平衡，大家都受同样的规则约束，非常公平公正。

同样，你的投入也会得到相应的回报。你可以当项目的“旁观者”，但也就失去了项目的控制权；也可以只把Linux当做一个基本的操作系统；但如果你有特殊要求，那么能对项目产生真正影响的唯一方法就是参与进来。

在这种情况下，包括我在内的所有人都要保持诚实。任何人都可以对项目进行分叉，走自己的路，然后接管自己的Linux版本维护。我的特别仅仅在于人们相信我能把工作做好，而这本就是理所当然的事情。

“任何人都可以维护自己的版本”这一点让一些人对GPLv2产生了怀疑，但我认为这是一种优势。正是这一点保护Linux逃过了分裂的结局：每个人都可以完成自己的项目分支。事实上，这也是“Git”的核心设计原则之一——存储库的每个克隆都是自己的小分支，开发者（或公司）要想真正完成项目开发的话，则需要从中分叉出去。

所以分叉本身不是问题，只要你能把好的部分合并回来即可，这就是GPLv2的意义所在。要保障大家具备进行分叉并实现个人项目的权利，但与此同时，也要保证当分叉成功时，大家也有权利能再次将其融合回来。

另一个问题是，大家都想拥有能够支持项目生产的工具，与此同时，心态也一定要强大。将分叉融合回来的障碍，不仅是许可证，还有“Bad Blood”的问题。如果两个分叉从根本上就非常对立的话，那么要想将它们融合是非常困难的——并不是因为许可证或技术原因，而是由于分叉过于尖锐对立。同样，我认为Linux很好地避免了这一点，主要是因为我们一直认为分叉是一件非常正常且自然的事情；当其证明了自身的成功后，自然也要合并回来。

虽然这个答案或许有些跑题，但我认为这一点非常重要——我从未后悔过自己的许可证选择，因为我真心认为GPLv2是Linux能够取得成功的重要原因。

金钱其实并不是一个很好的激励方式，因为它并不能将人们团结在一起。我认为，真正能够起到激励作用的是：人们参与到一个共同的项目中来，并真正感觉到自己可以成为这个项目的全面合作伙伴。

Jeremy：如今人们在GPLv2下发布源代码，通常都是因为Linux。你是如何寻找许可证的？在审查现有许可证上投入了多少时间和精力？

Linus：当时，人们仍对BSD和GPL有较大争论，我会在浏览各Usenet新闻组时看到一些有关许可证的讨论。

但最主要途径的有两个：一是GCC。它对Linux的发展起了很大作用；二是Lars Wirzenius（昵称Lasu），他是当年我大学里另一个说瑞典语的CS同学。Lasu比我更喜欢讨论许可证之类的事情。

对我来说，选择GPLv2并不是什么重大原则性决定，主要是因为我原来的临时许可证亟待更新，我很感激GCC，但GPLv2更符合我“你需要把源代码还回来”的期望。因此，与其设立新的许可证（或者只对旧的许可证进行修改），我更希望能挑选一个已经为人所熟知，且有律师参与的许可证。

Jeremy：人们通过Linux内核邮件列表进行公开的内核开发，而且流量非常大。你如何兼顾这么多邮件？有没有探索过邮件列表之外的其他合作沟通解决方案？还是说简洁的邮件列表对你的工作而言就是完美的？

Linus：我已经很多年没有直接阅读过内核邮件列表了，实在是太多了。内核邮件列表的意义在于可以将内容抄送给所有人。当有新人加入讨论时，可以通过查看内核邮件列表来了解历史沟通记录。

我之前订阅了列表，设置将所有没私人抄送的LKML邮件都自动归档，默认不显示。当有问题需要处理时，我也能找到所有的相关讨论。所有内容都储存在电子邮件中，但只有在需要时才会出现在收件箱。

最近，我一直都在用lore.kernel.org的功能，它非常好用，而且我们还有一些围绕其构建的工具。因此，邮件讨论内容就不必自动归档在邮箱里，可以用另一种方式呈现，但其基本的工作流程是相同的。

当然，我仍会收到非常多的Email，但这些年来情况已经在逐步转好。其中很大一部分原因是Git及内核发布流的完美运作，不会再遇到像本世纪初那时一样的各种代码流和工具方面的问题。

附带工具的邮件列表确实非常好用。并不是说所有人都只用电子邮件或者线下见面沟通，也有人喜欢各种实时聊天设置（当时还有IRC）。但“邮件列表存档”模式非常好用，并且能无缝衔接“开发者之间以邮件方式发送补丁”和“以邮件方式发送问题报告”。

因此，电子邮件仍是主要的沟通渠道，补丁可以被嵌入同一媒介，简化了技术讨论流程。而且它能实现跨时区工作，当大家在异地工作时，这一点就显得尤为重要了。

Jeremy：3.0内核与之前的2.6.x版发布之间隔了整整八年。自3.0版本发布以来，内核有没有发生什么更有趣的事情呢？

Linus：3.0距今也有十年了，在这十年中我们的技术发生了很大变化。ARM发展成熟了，ARM64也已成为主要架构之一，拥有很多新的驱动程序和核心功能。过去十年的有趣之处在于“我们是如何保持实际开发模型平稳”的，以及“什么东西没有变”。

几十年来，我们推出过许多不同的版本方案以及多个开发模式，但3.0版本最终确定了我们一直以来使用的模式。它真正实现了“基于时间，版本号只是数字，不依附于任何功能”的说法。在2.6版本中，就具备合并窗口的“基于时间”的概念，因此这并不稀奇，但3.0是“最后一片拼图”。

我们有随机编号方案（主要是在1.0之前），其规则是：小数点后奇数表示开发内核，偶数表示稳定的生产内核。在2.6中，我们开始做基于时间的发布模式。但仍然存在“何时增加主版本号”的问题。而3.0的正式出现表示，主版本号并没有什么特殊意义，只是为了尽量简化数字，不要让它太长太繁琐。

因此，在过去的十年里，我们做了非常大的改变。但开发模式本身其实一直都相当平稳。

事实上，内核开发的前二十年中，开发模式一路走来经历了很多坎坷，只是在过去十年里，发布的可预测性才大大提高了。

Jeremy：最新版本Linux 5.14即将来临。发布过程的标准化程度如何？例如，什么样的变化会进入RC1、RC2等等？你是在什么时候才会决定特定版本是否可以正式发布？如果版本有错误，在版本发布后宣布撤回的话会发生什么？这种情况的发生频率高吗？这一过程多年来是如何演变的？

Linus：这个过程本身是有一定标准的，并且在过去十年一直如此。它曾经历过几次剧变，但实际上从3.0开始其运转就如时钟般稳定了（甚至还会更早一些，因为人们要适应Git还要一定的时间）。

因此，我们形成了相对固定的节奏：在最终版本发布之前，有约两周的合并窗口时间，然后每周约6-8个候选版本，到现在已经有近15年了。

规则没有变过，但不一定完全严格执行：合并窗口是为假定“已经过测试和准备好”的新代码准备的，然后在接下来的约两个月里进行修改，确保所有问题都能得到妥善解决。但有时在发布之前，那些“已经准备好”的代码也会被禁用或彻底推翻，然后从头再来，所以我们大约每10周左右就有一次发布。

发布标准是我自身要对该版本有足够的信心，而这种信心要建立在递交上来的问题报告的基础上。如果某部分在RC后期仍出问题的话，我们会积极修改，并牢记不再犯，但总体而言，这种情况是相当罕见的。

发布了就一定会取得成功么？当然不是。内核一经发布，就会产生新的用户，其中不乏没有参与开发测试的人，而他们常常会发现一些我们在RC中没有发现的问题，这种情况无法避免。这也是我们需要“稳定内核树”的原因之一，它能够在发布后继续添加修复。一些稳定内核的维护时间比其他内核更长，因此也被称为LTS（Long-term support）内核。

所有这些在过去的十年里都没有什么变化，只是有了更完善的自动化流程。一般来说，内核测试的自动化是很困难的，部分原因是：很多内核都是驱动程序，这依赖于硬件的可用性。但有几个测试场同时进行启动和性能测试，并进行各种随机负载测试，所以近年来情况已经有了很大改善。

本页Url