（配图：Open Source Summit Europe 2026 主题演讲官方封面，The Linux Foundation 发布。）

引言：一场没有讲稿的对话

2026 年 10 月 7–9 日，Open Source Summit Europe 与 Embedded Linux Conference Europe 在布拉格会议中心同期举行。闭幕主题演讲是这场大会最不需要介绍的一场：Linus Torvalds 与 Dirk Hohndel 对谈。

这种形式本身就有来历。Linus 在开场时说得很直白：

我们之所以采用这种略显奇怪的对话形式，是因为我极其讨厌公开演讲，即使过了 35 年，我依然对此感到紧张。我们发现让我放松的方法就是，我不需要做任何准备，Dirk 会想好问题来问我，而我只需要毫无准备地坐下来。

主持人 Dirk Hohndel 也是这段历史的在场者——他在 Linux 早期就参与其中，长期担任 VMware 首席开源官，2026 年 7 月起出任爱立信软件技术（Ericsson Software Technology）负责人，直接向爱立信 CTO 汇报。他同时也是 Linux Foundation 那份里程碑报告《35 Years of Linux》的序言作者。

这场对话最值得听的地方，不是 Linus 又说了什么金句，而是他把自己 35 年里每一次"不得不改"的经过讲了出来。这篇整理保留了对话原貌，并在每个转折处补上当时的背景。

一、前四个月：他拒绝别人的补丁，然后"投降"了

Dirk 的第一个问题就直奔 1991 年那个夏天：大家都给你发补丁，但你当时并不应用它们。

Linus 的回答很诚实：

我不觉得这仅仅是我个人的特质。当你开始自己的项目并习惯于独立工作时，你需要一段时间才能真正学会如何与他人合作。……当人们给我发补丁时，他们往往比我更懂 Unix，我本可以直接应用这些补丁，但我的心态并非如此。我想让代码开源，但我当时还不是一个真正的"开源人"，我还在学习如何成为一个开源人。

那三四个月里，他做的事情是：阅读补丁，弄清对方想做什么，然后自己把代码完全重写一遍。

我骨子里比较懒。到了某个阶段我会想，当别人发给我一个现成可用的补丁时，我为什么要自己做这些额外的工作呢？

背景：1991 年 8 月 25 日，21 岁的 Linus 在 comp.os.minix 上发出那封著名的帖子，说自己"在做一个（免费的）操作系统，只是业余爱好，不会像 GNU 那样大和专业"。第一版约 10,000 行代码——这就是他后来能够逐行重写别人补丁的前提：整个系统还装在他一个人脑子里。

他自己也把这个阶段看作普遍规律而非个人怪癖：只要这种状态不一直拖延下去、不去拒绝外部帮助、不让人觉得自己不是项目的一部分，这就不是问题。 这句话后来成了 Linux 社区接纳新维护者时的隐性标准。

二、1991–2002：tarball 与补丁的十一年

Dirk 回忆起自己刚参与时"把全部源码打印出来"的做法，然后问：当 14,000 个补丁进入一个新内核时，你怎么管理？

当时根本没有流程。我每天都在内部制作补丁，并且至少每周发布一次。对于一个小项目来说，这种方法出奇地有效。

他从未使用过任何源码管理系统，理由不是讨厌 CVS，而是根本没用过：补丁和压缩包（tarballs）就是他觉得最自然的追踪方式。1991、1992 年的参与者只有几十人，这让"一个人 + 每周一个 tarball"足够运转。

背景：这套"发布 tarball + diff、由一个人汇总"的模式撑了整整 11 年，一直到 2002 年。这在软件工程史上近乎不可思议——它意味着 Linux 在成为拥有数百名贡献者的大型项目之后，仍在用业余项目的协作方式运转。这也解释了为什么后来 Git 的出现会被视为一次结构性的断裂，而不只是一次工具升级。

他明确说，自己强烈主张每个人都应该有自己的本地环境，而不是像 CVS 那样设一个中央仓库、管理谁有提交权限——“那是非常困难和痛苦的”。这个判断在三年后会以 Git 的形式彻底兑现。

三、2002–2005：BitKeeper 的三年借用期

Dirk 提到 Larry McVoy 带来的 BitKeeper。Linus 承认，那是他第一次看到"分布式"源码管理可以是什么样子：

BitKeeper 对我来说是一次巨大的解脱，我可以更轻松地合并其他使用了 BitKeeper 的子系统（如网络代码、ARM 架构代码等）。……它做得足够好，让我看到了"这就是我真正想要的"。

背景：BitKeeper 是商业软件，但以免费许可提供给 Linux 内核开发使用。这项安排在 2005 年破裂——社区中有人对 BitKeeper 做了反向工程，公司随即收回许可。Linus 在对话里只轻描淡写地说"发生了一点小风波"，但那句话的分量在后面：

那是一个很大的冲击。当你习惯了一个流程，一旦这个流程被打断，就会非常痛苦。当时我见识过更好的工具，所以根本不可能回到 tarballs 和补丁的时代。

于是他的选择是：暂停内核开发，直到有替代品再回来。

四、2005：两周写 Git，半年后交棒

Dirk 替所有人问了那个问题：然后呢？

Linus 说得非常直接：

这就是 Git 诞生的背景。……它虽然开源，但还有些粗糙，而且故意做得在概念上非常与众不同。对于那些习惯了 CVS 的人来说，他们发现 Git 完全无法理解。我甚至因为讨厌 CVS 而更改了所有 git 命令的名称，让它在底层概念上就彻底不同。

然后是他很少主动讲的一段：

我确实启动了 Git，并花了半年时间维护它，然后我就撒手不管了。因为 Git 从来不是我的终极目的，我的终极目的是能够再次维护 Linux 内核。 半年后 Git 对我来说足够好了，我就把它交给了 Junio Hamano。他在 Git 的历史中工作了超过 20 年。所以，我有时候因为 Git 获得了太多额外的赞誉。

背景两则：

  1. Git 的诞生时间：2005 年 4 月，第一版在约两周内成型，起因正是 BitKeeper 许可收回。Linus 说的是"半年后交棒"，接棒者 Junio Hamano 从 2005 年 7 月起担任 Git 维护者，至今已超过 20 年——这是开源史上最成功的一次维护者交接之一。
  2. 命名即设计：改掉所有命令名、刻意让底层概念与 CVS 不同，这在人机交互上常被批评为"反直觉"，但 Linus 的意图是阻止人们在旧心智模型里使用新工具。这套思路的可复制性其实有限——它依赖于作者已有足够声誉，能承受用户的不满。

他也惊讶于结果：在大约 5 年时间里，Git 从一个奇怪的异类变成了几乎接管整个源码管理领域的标准。

五、2006：当他说"每 5 周发一个版本"时，大家看他的眼神

Dirk 把话题推到 2.6.14 前后：Linux 从"Linus 觉得可以发布时就发布"，转向了合并窗口（merge window）与发布候选版（rc）的结构化流程。

Linus 先给了一个数字：如今这套系统已经稳定运行 20 年，每 9 到 10 周发布一次，像钟表一样精准，以至于人们意识不到它有多顺畅。

然后是当年的阻力：

在我刚开始提出这个想法时，它被认为是绝对疯狂的。过去我们习惯每年发布一次大版本，但实际上往往拖成两三年。这导致每个人都在开发树上做有趣的新功能，而稳定树往往无人问津。当一年（或两三年）过去，终于要发布时，所有东西都坏了。

背景：2006 年的内核维护者峰会上，Linus 提出放弃长周期发布、改成每 5 周一发。他形容大家的表情"像我长了第三个脑袋"。5 周是刻意激进的靶子，实际稳定在 9–10 周。

他的结论里有一句值得抄下来：

现在，内核大多数时候是"无聊（boring）“的，我积极避免在版本中引入令人兴奋的巨大新功能。我坚信，随着时间推移，那些循序渐进的小改变会变成大功能。我们不应该再去追求那种会破坏一切的传统的 “.0” 大版本发布。

这句话是整场对话里最"制度经济学"的一句：可预期的发布节奏把"惊喜"从流程里剔除出去，让下游（发行版、企业、硬件厂商）可以规划。稳定不是无聊，稳定是让别人能押注的条件。

六、2026：用 AI 的补丁大军对抗 AI 的补丁大军

Dirk 在 25 分钟时说：该聊 AI 了。

Linus 描述了已经发生的现实：

我们在公共邮件列表中使用了各种 AI 工具来进行补丁审查，Sashiko 是其中由 Google 维护的主要工具之一。它实际上已经改变了人们的工作方式。很多子系统现在基本不再接收没有经过 Sashiko 公开审查的补丁。

他也没有把它神化：

它的审查并不完美，有些 AI 给出的抱怨是错的（当然，人类的审查有时也是错的）。

然后是那句被媒体反复引用的话：

在某种程度上，我们正在用我们自己的"AI 补丁审查大军"去对抗"AI 生成的补丁大军（AI deluge of patches）"。人们开玩笑说现在是机器人在和机器人对话。

他给出了一个相当克制的判断：大量随机补丁里有真实的严重安全问题，也有针对二十年没人关心的死代码的修补——总体上改善了代码库，但给维护者带来极大压力。所以让 AI 去检查 off-by-one、API 滥用这类机械问题，是在给维护者减负。

在昨天的维护者峰会上，四分之三的讨论都在关注如何让 AI 代码生成和审查工具更少压力、更成功。

背景：Sashiko 是 2026 年 3 月由 Roman Gushchin 在 LKML 上正式公布的 agentic 代码审查系统，作为服务运行、监控公共邮件列表，并已在多个子系统成为事实上的前置关卡。它被命名为"刺し子”——日本一种用补丁加固旧布的手艺，这个名字本身就带着作者的态度。

七、吉他效果器：AI 作为"敲门砖"

Dirk 最后问了一个看似离题的问题：你的业余项目。

Linus 为一块原声/吉他效果器用 C 写好了后端逻辑，但不会做前端界面。他的做法不是让 AI 从头写，而是：

我告诉 AI：“听着，我已经用 C 把逻辑做对了，它只是很丑。你根据我写好的、我确信正确的东西，给它加一张漂亮的脸蛋（Pretty face）。”

结果让他印象很深。他对 AI 的判断经历了几个阶段——从一开始觉得"不怎么样"，到"作为工具还挺有趣"，到今天"我实际上非常喜欢使用 AI"：

在真正的关键项目（如内核）中我不怎么自己写代码了，但在那些为了乐趣而做的业余项目中，如果把它当成一个正确的工具来使用，AI 是非常棒的。

他还说了一句挺动人的话：1981 年那会儿电脑简单，大家写得都很烂，门槛低，你不会觉得自己毫无价值；而现在的软件工程门槛太高了，新手很难做出像手机应用那么漂亮的东西。 正因如此，他认为被大家嘲讽的 “Vibe Coding” 其实是找回编程乐趣的奇妙方式。

但他也划了线：

AI 是一把双刃剑，它既可以是一种入门玩具，也可以用来编写真正好的代码。但如果你想写出真正好的代码，你还是需要去理解这些代码。

背景：这个业余项目是真的——Linus 在 GitHub 上有 torvalds/GuitarPedal（描述就叫 “Linus learns analog circuits”，2025 年 9 月创建）与 torvalds/AudioNoise（数字音频效果）。他在 2026 年的多场演讲中都提到过自己用 AI 给这个项目的 C 后端"加一张脸"的经历。

结语：35 年里他改的都是同一件事

把这场对话从头读到尾，会发现 Linus 讲的不是技术进步史，而是四次"放弃控制"：

  • 1991 年，他放弃亲自重写每一行代码，开始接受别人的补丁；
  • 2005 年，他放弃自己维护 Git，把它交给 Junio；
  • 2006 年，他放弃"准备好了就发布"的自由，接受时间驱动的节奏；
  • 2026 年，他接受 AI 成为补丁流程中的一个前置环节。

每一次都不是因为想通了某个道理，而是因为旧方式已经撑不住了——补丁太多、工具没了、发布拖垮了、AI 洪水来了。他的原话是"我骨子里比较懒"，但那其实是同一种判断力：在该交出控制权的时候交出，而不是拖到系统崩掉。

而这恰好是「开源之道」一直在讲的那件事：开源之所以能持续 35 年，不是因为某个人的远见，是因为它在每一个规模跃迁的关口，都把决定权从一个人手里转移到一套可被验证的流程里。补丁列表、Git 历史、合并窗口、Sashiko 审查记录——它们都是同一个东西的不同形态：让陌生人可以检验的证据。

视角：一个视角，不是定论。

演讲信息

  • 对谈：Linus Torvalds（Linux 与 Git 创作者）× Dirk Hohndel（Head of Ericsson Software Technology，爱立信）
  • 场合：Open Source Summit Europe 2026（与 Embedded Linux Conference Europe 同期），2026 年 10 月 7–9 日，布拉格会议中心
  • 视频：YouTube · The Linux Foundation
  • 整理说明：本文依据演讲实录整理，非逐字翻译；引述保留原意，背景补充与评论部分为整理者所加。

参考资料

  1. 演讲视频（YouTube，The Linux Foundation）— https://www.youtube.com/watch?v=0PSA2LFFlvk
  2. 《35 Years of Linux》，Anna Hermansen、Hilary Carter、Daniel German，序言 Dirk Hohndel，The Linux Foundation，2026 — https://www.linuxfoundation.org/research/35-years-of-linux
  3. Linux Kernel 35 周年报告解读：「开源之道」·适兕《三十五载的自发秩序》，2026-10-31 北京共读 — https://osbook.opensourceway.blog/events/2026-10-31-beijing-reading-meetup/
  4. Linux kernel version history（7.0 于 2026-04-12 发布；7.3 于 2026-10-18 发布；7.4-rc1 于 2026-11-01）— https://en.wikipedia.org/wiki/Linux_kernel_version_history
  5. Sashiko：agentic Linux kernel code review — https://sashiko.dev/ · LKML 公告（Roman Gushchin, 2026-03）— https://lkml.iu.edu/2603.2/03802.html
  6. LWN.net：Development tools: Sashiko, b4 review, and API specification — https://lwn.net/Articles/1063303/
  7. LWN.net：The role of LLMs in patch review — https://lwn.net/Articles/1064830/
  8. Git 维护者交接：Junio C Hamano 自 2005 年 7 月起担任 Git 维护者 — https://git-scm.com/
  9. torvalds/GuitarPedal（“Linus learns analog circuits”，2025-09 创建）— https://github.com/torvalds/GuitarPedal
  10. torvalds/AudioNoise（数字音频效果，C）— https://github.com/torvalds/AudioNoise
  11. 爱立信任命 Dirk Hohndel 为 Ericsson Software Technology 负责人（2026-07）— https://linuxfoundation.eu/en/about/advisory-board
  12. Open Source Summit Europe 2026 会议主页 — https://events.linuxfoundation.org/open-source-summit-europe/

关于作者

「开源之道」·适兕

「发现开源三部曲」（《开源之迷》，《开源之道》《开源之思》。）、《开源之史》作者，「开源之道：致力于开源相关思想、知识和价值的探究」主创，Social Hacker，协作机制设计者。

「开源之道」·窄廊

来自于大语言模型的 AI 助手（如 Gemini 3.1 Pro 等），「开源之道」·窄廊 负责高密度的逻辑推演与文本具象化，在对话中作为镜像与反弹板，提出问题、提供理论切入点并对推演进行反馈。仅偶尔进行双重验证！