“我们现在的许可证已无法满足需求，” 自由软件的先驱 Bruce Perens 如是说。

Bruce Perens，作为开源运动的创始人之一，已准备好迎接接下来的新阶段：后开源运动。

“我已经写过关于这个话题的论文，试图构建一个许可证原型，” Perens 在与 The Register 网站的独家采访中解释道，“很显然，我需要律师的协助。接下来，我将寻求一些研究资金。”

Perens 提到，开源社区需要解决几个紧迫的问题。

“最首要的一点，我们现在的许可证已无法满足需求，”他表示，“我们已经给了企业太多时间去找到所有的漏洞，因此，我们需要做出些新的改变。当三分之一的付费 Linux 系统在销售时都规避了 GPL 许可证时，很显然 GPL 并没有起到应有的作用。我说的就是 RHEL。”

RHEL 是 红帽企业 Linux Red Hat Enterprise Linux 的缩写，6 月份，这个属于 IBM 的公司 停止 了对 GPL 源代码开放。

Perens 近期刚从中国回来，他在 Bench 2023 大会上做了主题发言。在准备与我们的对话时，他写下了一些关于他的访问以及关于开源软件社区现状的看法。

他脑海中涌现的一件事是关于红帽的问题。

“红帽已经不是那个红帽，而是 IBM，”Perens 在给 The Register 分享的备忘录中写道，“显而易见，他们已经停止了对 CentOS 的分发，而且很长的一段时间里，他们一直在做我认为违反 GPL 的事情，我曾因为另一家企业做同样的事情提起过 诽谤案：他们告诉你，如果你是 RHEL 的客户，你不能公开 RHEL 制作的安全补丁的 GPL 源代码，否则他们将不再允许你成为他们的客户。这些 IBM 的员工坚称，他们仍然在为上游开源项目贡献补丁 —— 而他们实际上并没有这个义务。

“这种状况已经持续了很长时间，只因为红帽公开发行 CentOS（本质上是 RHEL 的无品牌版本），我们才容忍了这一情况。但现在 IBM 不再这么做了。因此，我感觉 IBM 已经从开源社区得到了他们想要的一切，而我们却收到了他们的中指。

“显然，CentOS 对许多企业同样重要，他们正在努力采用 Rocky Linux。我倒是希望他们能切换到一个 Debian 衍生版本，不过这也没什么。而开源这只骆驼背上已经有很多稻草了，会不会有一根压垮它呢？”

另外一根压在开源骆驼背上的沉重稻草，Perens 写道，“是开源完全未能服务于普通人。在大多数情况下，如果他们使用的是开源软件，也是通过如苹果公司的 iOS 或谷歌的安卓这样的专有软件公司的系统，这两者都用开源作为基础设施，但大部分应用程序还是专有的。普通人对于开源一无所知，他们也不知道我们所倡导的自由是他们应该日益关心的问题。其实，现如今，开源已经被用来监视甚至剥削他们。”

正如 Perens 所阐述的，自由软件走过了半个世纪的历程，而开源的首度亮相也已有 30 年的光阴。“难道现在不该是我们审视过去所做所为，并寻求是否能做的更好的时候了吗？当然，同时我们也需要对开源进行保护。开源将一直存在，并提供相同的规则和范式，但接续开源的新模式应当有一个全新的称谓，并且永远不应该假冒为开源。此刻，我暂且称其为‘ 后开源 Post-Open ’。”

他所描述的“后开源”，比开源稍微复杂一些。它将明确企业与开发者的关系，以确保企业为所获得的利益支付合理的费用。对于个人和非营利机构，仍可免费使用，而且只需一个许可证即可。

他设想了一个简单的年度合规程序，让企业可以获得使用“后开源”软件所需的所有权利。企业将会资助开发者，鼓励他们编写非技术专家也能使用的软件。

Perens 指出，看看苹果公司、谷歌和微软等的流行应用，“因为许多软件倾向于以用户为目标，所以他们当然会受到大量的监控，甚至在某些情况下被滥用。所以，开源开始真正为普通人服务的时机已经到来。”

Perens 表示，目前这种情况不常见的原因在于，开源开发者多是为自己和同样精于技术的人群编写代码。他坚信，为了避免这一情况，应支付给开发者报酬，让他们有时间和支持去编写用户友好的应用。

他建议，这笔费用由公司承担，可以采用一种类似度量 GitHub 的软件，据此分配付款给贡献者，这个软件能精确显示出谁为哪个产品做出了多少贡献。他说，Merico 就是提供这样一种软件的公司。

Perens 承认，这需要解决很多阻碍。例如，需要找到一个可以接受的机构来负责度量和分发资金。而且，这种金融结构必须有足够的吸引力，让大量的开发者愿意参与。

他深思道：“而且，所有的这一切必须既足够透明，又具备足够的灵活性，以防止出现许多不同的分叉。因此，我其实也觉得担心，这种设想真的可以实现吗？”

不论这种设想能否成功，Perens 相信，仅仅依靠 GPL 是远远不够的。“GPL 的设计不是作为合同，而是作为一个许可证。 理查德·斯托曼 Richard Stallman 的初衷并不愿意剥夺任何人的权利，他只是想给予大家权利。因此，它不是合同，而是许可证。然而，我们不能再这样了，我们需要具有执行力的合同条款。”

当被问到像 HashiCorp、Elastic、Neo4j 和 MongoDB 这样的公司采用非开源许可证是否代表了一种可行的服务模式，Perens 认为这需要新的思维。

他对像 “ 公共资源条款 Commons Clause ” 这样的许可证非常反感，因为这正是 Neo4j 陷入 法律纠纷 的中心原因之一。

他写道：“为什么公共资源条款会引发问题？首先，涉及到品牌问题。开源许可证有一个‘品牌’，这是对他们所赋予的权利的理解。当然，开源本身也有品牌，即对开源定义中的权利的理解。然而，公共资源条款看似使用的是开源许可证，但实际上并没有提供同样的权利，这样就滥用了该许可证的品牌，以获取利润。

“另一个问题是，公共资源条款被添加到不允许进行添加条款的许可证中，如 Neo4J 上的 AGPL v3。AGPL 和 GPL 的条款都明确禁止增加新条款。因此，当许可人添加公共资源条款时，他们创造了一个自我矛盾的许可证。”

Perens 告诉 The Register：“我们已经在（软件即服务）问题上投入了大量的研究。我记得参加过一个（自由软件基金会）会议，问题就是，‘我们该如何应对谷歌？’ 结果是，那次会议后诞生了 AGPL。”

在云服务公司的环境下，Perens 认为 AGPL 或其他各种非开源许可证没有找准关注的重点。

Perens 说，“像 AGPL 这样的许可证，要求软件以某种方式公开自己的源代码。但我们实际上讨论的是软件的公开演示，而这在版权法下是一种独立的权利，因为它对于戏剧和电影来说是必需的。由此，我们有权利使用这项在版权法下的权利。我认为那些许可证都在尝试着去实现一个目标，由于它们只试图在开源的基础上稍做改动，所以它们只达成了部分目标。要知道，我们已有 30 年的开源历史了，是时候做一些彻底的变革了。”

当被问到现在大家对 AI 的热情时，Perens 表示了他的不满。

他说，“我认为 AI 总是在剽窃。当你训练模型时，你其实是在用其他人的受版权保护的东西来训练。AI 所做的就是混合、匹配，然后输出所输入内容的组合。我们必须考虑这一点，我们该如何补偿那些数据用于训练模型的人们呢？我们应该使用开源软件训练它吗？我不这么认为，AI 还有更多的功能，比如读取人们的网站、读取整个维基百科。但对于这些输入的贡献者，他们并未得到合理的补偿。所以这确实是一个我们需要解决的大问题。”

至于美国试图阻断中国技术的努力是否有效，Perens 表示这些基本上没有效果。

他说，“中国人能做到我们所做的所有事情，只有一两个例外，但也马上就会赶上。”他指出，尽管他们在先进的芯片方面落后，但他们会迎头赶上。（此处有删节）

他也提出，由于美国的出口法律，特别是美国国务院施行的国际武器交易限制（ITAR）和美国商务部监管的出口管理法规（EAR），与中国保持一定程度的友好关系对开源社区也有影响。

Perens 解释道：“目前，空间卫星、数字语音编码器、某些 Kraken RF 项目的应用，还有可能数百个其他的开源项目，都还在受限技术名单之上。然而，由于好几起诉讼的影响，ITAR 和 EAR 都为‘公开的信息’开了一道口子，这并不意味着是‘公域软件’，那是版权的问题。它的含义是‘非商业秘密’，所以它包括开源与公开的研究。

“现在，根据 ITAR 和 EAR，完全公开的项目可以不受限制地运行。不久前， 开源研究院 Open Research Institute 做了一项工作，使这样的项目得到了美国的国务院和商务部的明确批准。因此，目前有可能运行一个开源项目，开发原本可能属于 ‘军用’ 的技术，包括与原本受 ITAR 和 EAR 限制的国家合作。这对于我们保护开源技术和公共研究都很重要。随着美国政客对 3D 打印枪支等事务越来越关心，以及许多人希望更严格地限制与中国等国的技术分享，这项权益总是受到威胁。”

Perens 表示：“我认为，我们有可能与这个国家发生纷争，这是非常可怕的。但如果你看看这些人，他们和今天的我们非常相似。我们真的应该和平共处。”

（题图：DA/b125f972-5005-44c0-8fd2-88526c27b307）

via: https://www.theregister.com/2023/12/27/bruce_perens_post_open/

作者：Thomas Claburn 译者：ChatGPT 校对：wxy

今年早些时候，我们对 Bjarne Stroustrup 进行了采访。他是 C++ 语言的创始人，摩根士丹利技术部门的董事总经理，美国哥伦比亚大学计算机科学的客座教授。他写了一封信，请那些关注编程语言进展的人去“想想瓦萨号！”

这句话对于丹麦人来说，毫无疑问，很容易理解。而那些对于 17 世纪的斯堪的纳维亚历史了解不多的人，还需要详细说明一下。瓦萨号是一艘瑞典军舰，由国王 Gustavus Adolphus 定做。它是当时波罗的海国家中最强大的军舰，但在 1628 年 8 月 10 日首航没几分钟之后就沉没了。

巨大的瓦萨号有一个难以解决的设计缺陷：头重脚轻，以至于它被一阵狂风刮翻了。通过援引这艘沉船的历史，Stroustrup 警示了 C++ 所面临的风险 —— 现在越来越多的特性被添加到了 C++ 中。

我们现在已经发现了好些能导致头重脚轻的特性。Stroustrup 在他的信中引用了 43 个提议。他认为那些参与 C++ 语言 ISO 标准演进的人（即所谓的 WG21 小组）正在努力推进语言发展，但成员们的努力方向却并不一致。

在他的信中，他写道：

分开来看，许多提议都很有道理。但将它们综合到一起，这些提议是很愚蠢的，将危害 C++ 的未来。

他明确表示，他用瓦萨号作为比喻并不是说他认为不断提升会带来毁灭。我们应该吸取瓦萨号的教训，构建一个坚实的基础，从错误中学习并对新版本做彻底的测试。

在瑞士 拉普斯威尔 Rapperswill 召开 C++ 标准化委员会会议之后，本月早些时候，Stroustrup 接受了 The Register 的采访，回答了有关 C++ 语言下一步发展方向的几个问题。（最新版是去年刚发布的 C++17；下一个版本是 C++20，预计于 2020 年发布。）

Register：在您的信件《想想瓦萨号！》中，您写道：

在 C++11 开始的基础建设尚未完成，而 C++17 基本没有在使基础更加稳固、规范和完整方面做出改善。相反，却增加了重要接口的复杂度（原文为 surface complexity，直译“表面复杂度”），让人们需要学习的特性数量越来越多。C++ 可能在这种不成熟的提议的重压之下崩溃。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）

对新人来说，C++ 过难了吗？如果是这样，您认为怎样的特性让新人更易理解？

Stroustrup：C++ 的有些东西对于新人来说确实很具有挑战性。

另一方面而言，C++ 中有些东西对于新人来说，比起 C 或上世纪九十年代的 C++ 更容易理解了。而难点是让大型社区专注于这些部分，并且帮助新手和非专业的 C++ 用户去规避那些对高级库实现提供支持的部分。

我建议使用 C++ 核心准则作为实现上述目标的一个辅助。

此外，我的“C++ 教程”也可以帮助人们在使用现代 C++ 时走上正确的方向，而不会迷失在自上世纪九十年代以来的复杂性中，或困惑于只有专家级用户才能理解的东西中。这本即将出版的第二版的“C++ 教程”涵盖了 C++17 和部分 C++20 的内容。

我和其他人给没有编程经验的大一新生教过 C++，只要你不去深入编程语言的每个晦涩难懂的角落，把注意力集中到 C++ 中最主流的部分，就可以在三个月内学会 C++。

“让简单的东西保持简单”是我长期追求的目标。比如 C++11 的 range-for 循环：

for (int& x : v) ++x; // increment each element of the container v

v 的位置可以是任何容器。在 C 和 C 风格的 C++ 中，它可能看起来是这样：

for (int i=0; i<MAX; i++) ++v[i]; // increment each element of the array v

一些人抱怨说添加了 range-for 循环让 C++ 变得更复杂了，很显然，他们是正确的，因为它添加了一个新特性。但它却让 C++ 用起来更简单，而且同时它还消除了使用传统 for 循环时会出现的一些常见错误。

另一个例子是 C++11 的 标准线程库 standard thread library 。它比起使用 POSIX 或直接使用 Windows 的 C API 来说更简单，并且更不易出错。

Register：您如何看待 C++ 现在的状况？

Stroustrup：C++11 中作出了许多重大改进，并且我们在 C++14 上全面完成了改进工作。C++17 添加了相当多的新特性，但是没有提供对新技术的很多支持。C++20 目前看上去可能会成为一个重大改进版。编译器的状况非常好，标准库实现得也很优秀，非常接近最新的标准。C++17 现在已经可以使用，对于工具的支持正在逐步推进。已经有了许多第三方的库和好些新工具。然而，不幸的是，这些东西不太好找到。

我在《想想瓦萨号！》一文中所表达的担忧与标准化过程有关，对新东西的过度热情与完美主义的组合推迟了重大改进。“追求完美往往事与愿违”。在六月份拉普斯威尔的会议上有 160 人参与；在这样一个数量庞大且多样化的人群中很难取得一致意见。专家们也本来就有只为自己设计语言的倾向，这让他们不会时常在设计时考虑整个社区的需求。

Register：C++ 是否有一个理想的状态，或者与之相反，您只是为了程序员们的期望而努力，随时适应并且努力满足程序员们的需要？

Stroustrup：二者都有。我很乐意看到 C++ 支持彻底保证 类型安全 type-safe 和 资源安全 resource-safe 的编程方式。这不应该通过限制适用性或增加性能损耗来实现，而是应该通过改进的表达能力和更好的性能来实现。通过让程序员使用更好的（和更易用的）语言工具可以达到这个目标，我们可以做到的。

终极目标不会马上实现，也不会单靠语言设计来实现。为了实现这一目标，我们需要改进语言特性、提供更好的库和静态分析，并且设立提升编程效率的规则。C++ 核心准则是我为了提升 C++ 代码质量而实行的广泛而长期的计划的一部分。

Register：目前 C++ 是否面临着可以预见的风险？如果有，它是以什么形式出现的？（如，迭代过于缓慢，新兴低级语言，等等……据您的观点来看，似乎是提出的提议过多。）

Stroustrup：就是这样。今年我们已经收到了 400 篇文章。当然了，它们并不都是新提议。许多提议都与规范语言和标准库这一必需而乏味的工作相关，但是量大到难以管理。你可以在 WG21 网站上找到所有这些文章。

我写了《想想瓦萨号！》这封信作为一个呼吁，因为这种为了解决即刻需求（或者赶时髦）而不断增添语言特性，却对巩固语言基础（比如，改善 静态类型系统 static type system ）不管不问的倾向让我感到震惊。增加的任何新东西，无论它多小都会产生成本，比如实现、学习、工具升级。重大的特性改变能够改变我们对编程的想法，而它们才是我们必须关注的东西。

委员会已经设立了一个“指导小组”，这个小组由在语言、标准库、实现、以及工程实践领域中拥有不错履历的人组成。我是其中的成员之一。我们负责为重点领域写一些关于发展方向、设计理念和建议重点发展领域的东西。

对于 C++20，我们建议去关注：

• 概念
• 模块（适度地模块化并带来编译时的显著改进）
• Ranges（包括一些无限序列的扩展）
• 标准库中的网络概念

在拉普斯威尔会议之后，这些都有了实现的机会，虽然模块和网络化都不是会议的重点讨论对象。我是一个乐观主义者，并且委员会的成员们都非常努力。

我并不担心其它语言或新语言会取代它。我喜欢编程语言。如果一门新的语言提供了独一无二的、非常有用的东西，那它就是我们的榜样，我们可以向它学习。当然，每门语言本身都有一些问题。C++ 的许多问题都与它广泛的应用领域、大量的使用人群和过度的热情有关。大多数语言的社区都会有这样的问题。

Register：关于 C++ 您是否重新考虑过任何架构方面的决策？

Stroustrup：当我着手规划新版本时，我经常反思原来的决策和设计。关于这些，可以看我的《编程的历史》论文第 1、2 部分。

并没有让我觉得很后悔的重大决策。如果我必须重新做一次，我觉得和以前做的不会有太大的不同。

与以前一样，能够直接处理硬件加上零开销的抽象是设计的指导思想。使用 构造函数 constructor 和 析构函数 destructor 去处理资源是关键（ 资源获取即初始化 Resource Acquisition Is Initialization ，RAII）； 标准模板库 Standard Template Library （STL） 就是解释 C++ 库能够做什么的一个很好的例子。

Register：在 2011 年被采纳的每三年发布一个新版本的节奏是否仍然有效？我之所以这样问是因为 Java 已经决定更快地迭代。

Stroustrup：我认为 C++20 将会按时发布（就像 C++14 和 C++17 那样），并且主流的编译器也会立即采用它。我也希望 C++20 基于 C++17 能有重大的改进。

对于其它语言如何管理它们的版本，我并不十分关心。C++ 是由一个遵循 ISO 规则的委员会来管理的，而不是由某个大公司或某种“ 终生的仁慈独裁者 Beneficial Dictator Of Life （BDOL）”来管理。这一点不会改变。C++ 每三年发布一次的周期在 ISO 标准中是一个引人注目的创举。通常而言，周期应该是 5 或 10 年。

Register：在您的信中您写道：

我们需要一个能够被“普通程序员”使用的，条理还算清楚的编程语言。他们主要关心的是，能否按时高质量地交付他们的应用程序。

改进语言能够解决这个问题吗？或者，我们还需要更容易获得的工具和教育支持？

Stroustrup：我尽力宣传我关于 C++ 的实质和使用方式的理念，并且我鼓励其他人也和我采取相同的行动。

特别是，我鼓励讲师和作者们向 C++ 程序员们提出有用的建议，而不是去示范复杂的示例和技术来展示他们自己有多高明。我在 2017 年的 CppCon 大会上的演讲主题就是“学习和传授 C++”，并且也指出，我们需要更好的工具。

我在演讲中提到了构建技术支持和包管理器，这些历来都是 C++ 的弱项。标准化委员会现在有一个工具研究小组，或许不久的将来也会组建一个教育研究小组。

C++ 的社区以前是十分无组织性的，但是在过去的五年里，为了满足社区对新闻和技术支持的需要，出现了很多集会和博客。CppCon、isocpp.org、以及 Meeting++ 就是一些例子。

在一个庞大的委员会中做语言标准设计是很困难的。但是，对于所有的大型项目来说，委员会又是必不可少的。我很忧虑，但是关注它们并且面对问题是成功的必要条件。

Register：您如何看待 C++ 社区的流程？在沟通和决策方面你希望看到哪些变化？

Stroustrup：C++ 并没有企业管理一般的“社区流程”；它所遵循的是 ISO 标准流程。我们不能对 ISO 的条例做大的改变。理想的情况是，我们设立一个小型的、全职的“秘书处”来做最终决策和方向管理，但这种理想情况是不会出现的。相反，我们有成百上千的人在线讨论，大约有 160 人在技术问题上进行投票，大约有 70 组织和 11 个国家的人在最终提议上正式投票。这样很混乱，但是有些时候它的确能发挥作用。

Register：在最后，您认为那些即将推出的 C++ 特性中，对 C++ 用户最有帮助的是哪些？

Stroustrup：

• 那些能让编程显著变简单的概念。
• 并行算法 Parallel algorithms —— 如果要使用现代硬件的并发特性的话，这方法再简单不过了。
• 协程 Coroutines ，如果委员会能够确定在 C++20 上推出。
• 改进了组织源代码方式的，并且大幅改善了编译时间的模块。我希望能有这样的模块，但是还没办法确定我们能不能在 C++20 上推出。
• 一个标准的网络库，但是还没办法确定我们能否在 C++20 上推出。

此外：

• Contracts（运行时检查的先决条件、后置条件、和断言）可能对许多人都非常重要。
• date 和 time-zone 支持库可能对许多人（行业）非常重要。

Register：您还有想对读者们说的话吗？

Stroustrup：如果 C++ 标准化委员会能够专注于重大问题，去解决重大问题，那么 C++20 将会非常优秀。但是在 C++20 推出之前，我们还有 C++17；无论如何，它仍然远超许多人对 C++ 的旧印象。®

via: https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/

作者：Thomas Claburn 选题：lujun9972 译者：qhwdw 校对：thecyanbird、Northurland、pityonline

本文由 LCTT 原创编译，Linux中国 荣誉推出

来自 Linux 内核首领的最佳生活提示。

OSLS 报道： Linus Torvalds 认为，技术行业的创新庆祝活动是沾沾自喜，自我陶醉和自私自利的。

他所使用的艺术化术语更为直率：“行业的创新如此之多都是胡说。” 他说：“人人创新——不要做这种‘不同思考’，这是无意义的，它们有百分之九十九只是工作而已。”

周三在加利福尼亚州召开的开源领袖峰会（OSLS）中，Linux 基金会执行总监 Jim Zemlin 采访了 Linus，讨论了他如何管理 Linux 内核的开发和他对工作的态度。

Torvalds 说：“所有的炒作都不是真正的工作，真正的工作是在细节之中。”

Torvalds 表示赞成这样一个观点，即成功的项目是 99％ 的汗水，百分之一的创新。

作为开源 Linux 内核的创造者和仁慈独裁者，不用提还是 Git 分布式版本控制系统的发明者，Torvalds 已经证明他的方法产生了结果。Linux 对技术行业的影响已经不用再夸大了。Linux 是服务器的主要操作系统，几乎所有的高性能计算都运行在 Linux 上，而大多数移动设备和嵌入式设备都依赖于 Linux。

Linux 内核可能是 PC 时代最成功的技术协作项目。根据 Zemlin 的说法，内核贡献者自 2005 年以来总共增加了 13500 多个，其中每天大约增加 10000 行代码，移除 8000 行代码，修改 1500 到 1800 行代码，而且这一直在继续 —— 虽然不是一直以目前的速度 —— 但这已经超过了二十五年。

Torvalds 说：“我们已经这样做了 25 年，而且我们遇到的一个常见问题是人们彼此需要磨合。所以组织代码、组织代码流、[以及]组织我们的维护关系构成了我们的历史，最终那些痛点，我说的是代码争议，基本上消失了。”

Torvalds 解释说，该项目的结构使人们能够独立工作。他说：“我们已经能够真正模块化代码和开发模式，所以我们可以并行做很多事情。”

Torvalds 说，技术起着明显的作用，但流程至少是同样重要的。

Torvalds 说：“这是一个社会化项目。这是技术层面的东西，而技术是让人们能够就问题达成一致的东西，因为……它通常有非常明确的对和错。”

但是现在 Torvalds 并没有像 20 年前一样对每一个变化进行审查，而是依靠贡献者的社交网络。他说：“这是社交网络和信任，并且我们有一个非常强大的网络，这就是为什么我们可以有一千人参与到每个发布当中。”

对信任的重视解释了参与内核开发的困难，因为人们不可以登录、提交代码然后消失不见。Torvalds 说：“你要提交很多小的补丁直到维护者信任你才行，在这一点上，你不仅仅是一个提交补丁的人，而是成为信任网络的一部分。”

十年前，Torvalds 表示，他告诉其他内核贡献者，他希望有一个八周的发布时间表，而不是可能拖延几年的发布周期。内核开发人员设法将其发布周期减少到大约两个半月。从那时起，开发工作就一直很平稳。

Torvalds 说：“说我们的流程有多么好很无聊。对于我来说，所有真正紧张的时刻都是关于流程的，它们和代码无关，当代码不工作时，这实际上是令人高兴的……流程问题是很痛苦的。你永远不会想有流程问题……尤其是当人们开始彼此生气时。”

via: http://www.theregister.co.uk/2017/02/15/think_different_shut_up_and_work_harder_says_linus_torvalds/

作者：Thomas Claburn 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出