IBM 开放技术的方法

多年来，IBM 一直被开源社区 中 的很多人视为开源领域的领导者。然而，在 IBM 参与的开源社区之外，这种领导作用并不那么为人所知和欣赏。

从我们与 Linux 、Apache 和 Eclipse 的合作，到我们目前在云堆栈、应用程序开发、区块链、人工智能、量子计算和机器学习等所有层面开展的工作，IBM 一如既往地恪守自己的承诺，即：推动开源领域的创新，基于开源提供广泛的产品组合，帮助围绕我们最关心的那些开源项目建立可持续的繁荣社区和生态系统。

事实上，IBM 是最多产的公司之一，已为 GitHub 组织和存储库贡献了大量开源代码。

在 IBM，我们相信我们在开源领域的领导地位对客户来说具有不同凡响的价值，以至于我们甚至提出了一个口号（已注册为商标）来表达这种价值： IBM is Open by Design（IBM 为开源而设计） 。

在本文中，了解 IBM 是如何在开源的发展过程中一直并继续发挥主导作用的（开源是一种软件开发方法，几乎完全取代了专有软件），以及我们如何利用这种领导力来提供世界一流的产品和解决方案，造福于客户。

悠久历史

IBM 在开源领域有着悠久的历史。事实上，在许多方面，IBM 都在一定程度上促使开源运动走向成功。面对上世纪 90 年代末围绕 Linux 使用的一些法律不确定性，IBM 对 Linux 的大力支持，再加上专利权质押和对大量技术资源的投资，令许多企业悄然改变了对开源的态度。在适当的情况下，对于越来越多的企业来说，开源（如 Linux）可能是对专有软件的一个引人注目且值得信赖的补充。

由于在 Linux 领域成功地与其他行业领袖进行了深入的合作，IBM 再次携手其他企业建立了 Apache 软件基金会和 Eclipse 基金会。我们在 Eclipse 方面甚至更进一步：为新基金会贡献了大量的初始代码并提供了专门的技术资源，并且在这两种情况下，都发挥了法律上的领导作用，帮助为这些社区编写相应的许可。IBM 广泛参与了这些项目以及其他一千多个项目和社区，为企业采用开源技术定下了基调。

这可能会让一些人感到惊讶，但事实上，我们的关键平台之一 – WebSphere Application Server 的开源程度已超过 70%，其中包含了 700 多个开源组件。当然，在开源之路上，WebSphere 并不孤独。IBM 的许多技术产品和解决方案都利用了开源技术，尤其是那些包含最具战略意义计划的产品和解决方案，这包括云、大数据和分析、区块链、物联网、机器学习和人工智能等方面的计划。

除了使用开源技术和为大量项目做出贡献外，IBM 还对开源做出了许多重大贡献，包括：

• 我们的 Java 运行时 J9 作为 Eclipse OpenJ9  孵化器贡献给了 Eclipse 基金会
• 我们面向 Java EE 和 MicroProfile 应用程序的 OpenLiberty 运行时贡献给了 openliberty.io
• 我们的开放区块链项目作为 Hyperledger Fabric  贡献给了 Hyperledger
• 我们的无服务器平台贡献给了 Apache OpenWhisk
• 我们的量子计算 API Qiskit
• 我们的 AI Fairness 360 Toolkit (AIF360) 和 AI Robustness Toolbox  (ART)
• 分析项目，如演变为 Apache Toree 和 Apache SystemML  的代码
• 以及过去 3 年里100 多个 其他方面的贡献

开放治理案例

IBM 从所有这些案例中学到的一点是，努力实现包容性和开放治理的社区更可能吸引最大的生态系统和最广阔的市场。但是，不是所有开源项目都是以同样的方式创建的，也不是所有社区都很活跃。

有各种各样的开源项目，而且其中许多项目并不是真正开放的。许多开源项目由个人（或单个供应商）运营，在他们的治理下，项目是高度封闭的，严重限制了来自其他人的贡献。其他项目可能更欢迎外部贡献，但在设定技术战略和方向时，这些项目仍是封闭的。

关键点在于，一旦项目达到某个成功水平，它通常会到达一个拐点。没有开放治理，用户就会认识到供应商锁定的更大风险，甚至可能导致项目被遗弃。参与者希望在决策中发出声音，如果他们感觉他们的声音未被听到，这表明项目已存在分支。这通常对生态系统是有害的，会增加风险。

“ 多年来，我们一直努力在开源界建立稳固且受人尊敬的声誉，尤其是在那些我们进行了战略性投资的社区。 ”

现实情况是，在开放式治理下管理的开放技术项目（在 Apache、Eclipse、Mozilla 和 Linux 等组织中发现的那种开放式治理）显然 更成功 （按数量级排列），寿命更长，而且与由单个供应商控制或在治理方面限制性更大的项目相比，风险也更低。

虽然 IBM 经常对未处于开放式治理模式下的开源项目做出贡献并使用这些项目，但当我们的客户或产品团队认为某个项目足够重要时，我们通常会与控制该项目的个人或供应商合作，帮助他们了解开放式治理的价值，并看到取得更大成功的潜力。如果我们能够有效地使项目转变为开放式治理，我们就会大幅增加投资，帮助确保该项目取得成功，并努力促进社区和生态系统的发展。

为了生态系统的利益

IBM 深知"水涨船高"的道理。仅有 IBM 一人取得成功显然不够，为了建立充满活力的生态系统，我们需要确保许多人都能斩获成功。这降低了我们自己拥抱开源时面临的风险，更重要的是，也降低了我们的用户所面临的风险。其他供应商也看到了这一点，因为开源复兴的参与者明白，机会并不在渠道或商品竞争上。

我们认为，利用开源的客户应该建立相应的流程来管理开源技术在企业中的运用情况，这样他们不仅会考虑技术价值和许可，还可以参照社区和生态系统的评价。

由于大多数企业都倾向于选择开源而不是专有产品，第一步通常是尝试集成您自己的开源堆栈。最后，一旦通过经验更深刻地认识到挑战的范围，这种模式往往会转变为与他人合作，这些人具备必需的深厚技能和经验，并对相关社区有着透彻的了解。

我们还认为，开始集成开源技术的客户应该有一个或多个合作伙伴，可以帮助他们参与并影响社区。这些合作伙伴应与之同心同德，利用在社区中长期积累起来的信誉和技术优势，推进与其利益相称的技术议程。

IBM 对开源的承诺和贡献在业界无可匹敌。多年来，我们一直努力在开源界建立稳固且受人尊敬的声誉，尤其是在那些我们进行了战略性投资的社区。很多 IBM 员工在多个开源基金会委员会中任职，包括 Linux、Eclipse、Apache、CNCF、Node.js、Hyperledger 等等，我们还有数以万计的 IBM 员工使用开源技术并为此做出贡献。我们重视并致力于开放式治理，因为我们认为这是确保开源项目长期取得成功并行之有效的最佳方法。IBM 开发者每天都在处理重要的开源项目，每个月为数百个开源项目做出数以千计的贡献。

不是所有开源项目都以同等方式创建的

GitHub 和其他地方的许多开源项目都可以被描述为"丢在路边可以让任何人拿走的家具"。代码是用开源许可发布的（或者不是！），但没有得到积极的维护。即使在那些积极维护代码的情况下，也很可能是由某个人或某家公司来处理的。一切看起来都不错，直到那个人（或那家公司）决定追求更有趣的事情或者遭遇不幸。

与单个所有者一起投资开源项目而自食苦果的例子简直不计其数。前不久，Facebook 宣布将停用 Parse （一个受欢迎的移动开发平台），这导致数千名开发者陷入困境。更多的情况下，开发者是以开源的形式发布了一些很酷的功能，但后来却因这样或那样的原因而中途放弃或完全忽视了它的存在。

现在，一些开源纯粹主义者可能会说："但你仍然拥有这个软件"。情况虽是如此，但问题在于：您 真的 打算自己来维护移动应用开发平台或非关系型数据库吗？

IBM 会通过仔细分析项目的 5 个方面来评估开源项目：

• 负责任的许可  – 显然，我们希望了解与该技术相关的开源许可。
• 可访问的提交过程  – 我们力求确保有一个明确定义的流程，欢迎外部贡献者做出贡献。
• 多样化的生态系统  – 我们确认有多个供应商和 ISV 正在基于该技术提供产品。
• 参与式社区  – 我们要求设立相应的流程，使贡献者在社区中的技术地位得以提高。
• 开放式治理  – 我们会评估治理模型，确定它是否 真正 是开放的。

当然，我们还会考虑技术并评估是否拥有合适的架构，但技术通常会不断修复和改进。关键在于我们是否相信有足够的积极因素，能够保证为帮助项目实现真正开放治理而做的投资会让所有人受益。

IBM 的旅程从 Apache、Eclipse 和 Linux 开始

IBM 的开源技术开放式治理的旅程，最初始于我们在 1999 年领导成立了 Apache 软件基金会 ，创建这一基金会的目的是为 Apache HTTP 服务器的开发提供开放式治理。IBM 是该基金会的创始发起人之一，帮助塑造了相关许可和治理，并为许多项目做出了贡献。此外，在 ASF 成立之后，IBM 人员一直在组织内部和 ASF 委员会中担任领导角色。

18 年后，ASF 中有将近 200 个项目，很多都与最初的 HTTP 服务器项目无关。这些项目包括 Web 技术、XML、Web 服务、文档处理、移动、云、大数据和分析、无服务器和消息传递。显然，我们帮助创造了一个 安全的开放式协作和创新场所 。

Eclipse

2001 年，IBM 与其他公司合作，使用 Eclipse Java IDE 框架的初始授权创建了 Eclipse 基金会 。我们为 Eclipse 基金会制定了与 Apache 类似的目标： 创造一个在开放式治理方式下进行协作和创新的场所 。17 年后，Eclipse 有超过 360 个项目，所涉领域的多样性与 Apache 不相上下。同样，开放式治理提供了一个吸引开源开发者的场所，并为开放式协作和创新提供了一个试炼场。

Java

IBM 是 Java 的早期采用者和贡献者，具体可以追溯到最早期。我们在帮助塑造 Java 语言和运行时以及 J2EE 规范和 Sun Microsystems 方面发挥了 工具 性作用。多年来，我们一直在推动 Java 走向开源，从而使 OpenJDK 成为首要的开源 Java。

最近，IBM 的 J9 运行时已经开源，这是一个为云优化的高性能、低内存占用的 Java 虚拟机 (JVM)，同时用于 Java EE 和 MicroProfile 应用程序的 Liberty 运行时也已开源，这也为 WebSphere 奠定了开放的基础。我们仍在一如既往地帮助领导 Eclipse 基金会规范流程的制定工作并做出贡献，这一流程会将之前的 Java Community Process (JCP) 替换为 Jakarta EE。

Linux

2007 年，IBM 与其他关键行业领袖合作，以白金赞助商的身份建立了 Linux 基金会 。当然，我们的投资远远超出了赞助范围。我们一直是 Linux 社区的领导者，将来也必将如此。多年来，我们在 Linux 内核和 Linux 基金会下的 80 多个协作项目中投入了数以百计的工程资源，并且还在其中一些项目的启动上发挥了工具性作用。

云原生

2015 年 7 月，在启动 OCI 之后，IBM、谷歌、 Docker 、Weaveworks、RedHat 和其他许多公司紧接着成立了 云原生计算基金会 ，旨在为谷歌的 Kubernetes 项目提供一个开放式治理模型。这是 IBM 为云和其他与云原生应用程序相关的技术所制定的技术战略的关键组成部分。

此后，该组织在 CNCF 主席（IBM 的 Todd Moore）的领导下蓬勃发展，发展到 总共 18 个项目 ，包括 Kubernetes、etcd、rkt、fluentd、containerd（参阅下文）和 gRPC。IBM 正在加大对 CNCF 技术的投资并不断做出更多贡献，因为这些技术与我们的云战略息息相关，其中最著名的就是 Kubernetes 。IBM 将继续在 Kubernetes、etcd 和 containerd 上追加投资，随着投资的不断增加，我们可能会扩大这组项目的范畴。

Istio

我们与 Google 在 Docker、Kubernetes 和 CNCF 方面的合作也产生了更多的成果。IBM 和 Google 与 Lyft 联手合作，将 IBM 的 Amalgam 8、Lyft 的 Envoy 和 Google 的 Service Control 有机结合起来。最终打造了 Istio 项目，这是用于云原生微服务的路由和策略管理的一流抽象。我们的目标是最终将 Istio 转移到 CNCF，确保这一越来越受欢迎的重要项目实现开放式治理。

libcontainer

在过去几年里，IBM 一直是 Docker 的最大贡献者之一。我们的三位开发者赢得了 Docker 公司同行的尊敬，并被指定为维护者。随着 Docker 的使用越来越普遍，以及非 Docker 公司员工贡献者数量日益增加，要求将 Docker 置于开放式治理之下的压力也在不断增大。

这一社区压力最初导致 Docker 在 2015 年 6 月发起了开放容器计划 (Open Container Initiative)，IBM 是创始发起人之一。Docker 贡献了 libcontainer 和 Docker 镜像及传输格式规范，为新创建的计划注入了种子。自 OCI 启动以来，IBM 一直是最大贡献者之一。最近，我们的一名高级工程师入选了 OCI 技术监督委员会 ，以此表彰他的贡献和领导能力。

containerd

当然，这只是 Docker 实行开放式治理的第一个方面。2016 年 12 月，Docker 向云原生计算基金会 (CNCF) 贡献了 containerd 。containerd 是一个核心容器运行时组件，可以管理其主机系统上容器的完 整容器生命周期。目前已有两名 IBM 人员在 containerd 项目上获得了维护人员的地位；这再次证明了 IBM 在开源领域的领导地位。

Knative

最近，Google 宣布了 Knative 项目，该项目是与 IBM 和其他一些在无服务器和平台即服务领域的重要供应商密切合作开发的。Knative 提供了构建块，可为 Kubernetes 实现无服务器功能。我们相信这将是一项关键技术，我们正在社区中密切展开合作，旨在将 Cloud Foundry 和 OpenWhisk 等平台发展为基于 Knative 的平台。

AI 和机器学习

IBM 最近为 AI 开源了一些关键技术，包括：

• AI Fairness 360 工具包 (AIF360)：一个开源的软件工具包，可以帮助检测和消除机器学习模型中的偏差
• Adversarial Robustness Toolbox ：用于快速制作与分析机器学习模型的攻防方法
• Fabric for Deep Learning (FfDL，发音为 fiddle)：在 Kubernetes 上以"即服务"形式提供 TensorFlow、Caffe、PyTorch 等的深度学习平台。

这个领域很热门，所以在接下来的几个月里，可从 IBM 那里寻找更多的开源创新。

Hyperledger

2015 年，IBM 认识到区块链技术的巨大潜力，这也是比特币的底层技术。我们通过在这个领域的研究得出结论：现有的区块链技术平台中没有哪一个能真正适合企业。因此，IBM 开始着手构建一个全面考虑了企业需求的全新区块链平台，这是一个可以在严格监管的环境中使用的平台。

与 Apache HTTP 服务器和 Linux 内核一样，我们认识到一项如此重要的技术不应由任何一家供应商所控制。如果只有 IBM 提供这项技术，那么这项技术就永远不会取得成功。因此，我们与 Linux 基金会合作，帮助建立 Hyperledger ，这是 Linux 基金会有史以来发展速度最快的项目。IBM 贡献了 4.4 万行代码，并在开放式治理下建立了第一个 Hyperledger 项目，即 Hyperledger Fabric。此后，又在 Hyperledger 中孵化了 9 个项目。

Hyperledger Fabric 最先被孵化，最先升级到"活跃"状态，并于 2017 年 6 月最先推出了 1.0.0 版本。将近 300 名工程师代表了 40 家公司，他们为 Fabric 的四次发布做出了贡献。这证明了在开放式治理下实现开源的价值。

OpenWhisk

当 Amazon 在 2014 年推出 AWS Lambda 时，它为云功能即服务 (Faas) 或无服务器计算 (Faas) 指出了一个可能改变游戏规则的方向。许多公司都开始探索这一领域，包括 Google 和 Microsoft 等等。IBM 也不例外。2015 年初，IBM Research 开始为 IBM Cloud 开发健壮的无服务器功能实现。

正如我们在区块链方面的努力让我们最终创建了 Hyperledger Fabric 一样，我们认识到，为了使无服务器工作成果被视为专有 AWS Lambda 产品的一个可行替代方案，我们的实现就需要在开放式治理下开源，这样我们就可以围绕这个开源项目建立一个充满活力的社区和生态系统。2016 年 2 月，我们开源了我们的无服务器平台实现，并将其命名为 OpenWhisk。随着人们对 OpenWhisk 的兴趣日渐增加，我们与 Adobe 和 RedHat 等伙伴合作，在 2016 年 11 月建立了 Apache OpenWhisk 作为孵化项目。

Node.js

由于 IBM 在开源社区中的重要地位，Node.js 社区向 IBM 寻求帮助，希望解决社区中存在的分裂。这种分裂导致了 Node.js 的一个分叉，并为这两个项目开辟了一条迥异的道路。Node.js 是最流行的 Javascript 开发框架，但这种分裂很可能导致生态系统的分崩离析。

IBM 与这两个派别合作，并说服他们，解决这一问题的方法是在开放式治理下进行 Node.js 开发。IBM 帮助其他关键利益相关方在 Linux 基金会之下建立了 Node.js 基金会，并致力于弥合分歧。io.js 分叉重新回归 Node.js，得益于 IBM 的领导，该项目现在硕果累累，且日趋成熟。

还有其他许多项目

这些只是证明 IBM 在开源领域的领导地位和所做投资的几个例子。就在去年，IBM 还帮助建立了 OpenStack 基金会、Cloud Foundry 基金会、Node.js 基金会、 Open API 计划 和 ODPI 。除了 Apache OpenWhisk、 Apache Toree 和 Apache SystemML 之外，我们还支持创建了一些 Apache 项目。在过去的一年里，我们发起了超过50 个新的开源项目，并以开源的形式发布了无数教程和样本应用程序。

我们还鼓励 IBM 研发实验室中越来越多的 IBM 开发项目以开源形式发布。在实行这一计划的过去三年里，我们通过该计划发布了数百个全新的开源项目，其中许多项目已经引起了社区极大的兴趣，进而晋升为 Apache、Eclipse 和 Linux 基金会的开放式治理项目。

IBM 投入了大量资源，使关键的开放技术适应我们的 Open Power 和 Z 平台，包括 MariaDB、Go（这是许多针对系统级别的新兴开源项目所使用的语言）、Docker、runC、Linux、OpenStack、Cloud Foundry、Kubernetes、Swarm 等等。事实上，IBM 的开源影响力主要源自于 Systems 部门。

专注于企业

我们在安全性、可伸缩性、健壮性、实时升级、全球化、文档化、持续集成和交付等领域的项目上进行了大量投资，在我们看来，这些项目具有战略意义。当然，我们也在项目的一些功能方面进行了投资，帮助将 IBM 的创新技术展现在世人面前。我们也在其他重要方面做出了广泛的贡献，包括市场营销、宣讲以及各种董事会级别的委员会活动。最后，我们经常领导开展定义互操作性和可移植性的工作。我们之所以这样做是因为任何开放技术要想取得成功，互操作性和可移植性都起到举足轻重的作用。毕竟，这也正是消费者心之所想的。

在以上所有例子乃至更多例子中，IBM 在过去五年里投入了近 10 亿美元，并贡献了数百个开源开发、营销和宣讲资源。我们发起了其中的许多项目，并不知疲倦地帮助各个组织和它们主办的项目找准定位，走向成功。我们之所以这样做是因为 IBM 从这些项目和组织中获得的价值已超出了开源软件本身。充满活力的社区和蓬勃发展的生态系统带来了诸多收益，它们围绕着开放技术的重心不断发展壮大。我们的产品所取得的成功与所投资项目的成功成正比。

我们着重推动互操作性、可移植性以及对企业至关重要的众多其他特性。我们还专注于在上游为 IBM 创新做出贡献，当它与 OpenStack 这样的战略项目相关时，我们更倾向于使之保持闭源状态。的确，IBM 让产品实现了增值，但我们不会投资于互操作性和可移植性，这样在基于这些开放技术交付产品时，我们就可以将这些特性抛之脑后。我们的策略的基础是：充分利用开放技术的坚实基础，并确保这些技术定义的接口（API 和 SPI）完全公开，不会隐藏，也不会由于被某些专有的虚假增值服务所掩盖而无法访问。

我们通过创建"IBM Hyperledger Fabric"或"IBM Kubernetes"来努力避免社区代码出现分叉。IBM BlockChain Platform 中的 Hyperledger Fabric 与 Hyperledger 组织发布的 Hyperledger Fabric 相同。我们集成到 IBM Cloud 中的 Kubernetes 代码与云原生计算基金会发布的代码相同。IBM Container Service 中包含的 Docker 与社区发布的 Docker 相同。Cloud Foundry 与 Cloud Foundry 基金会发布的代码相同。IBM 增值是指我们集成了在开源中开发的所有这些功能来实现 IBM Cloud。

我们投资于这些战略技术的社区代码，并确保补丁和新特性处于上游，而不是从 IBM 角度增加额外的复杂性和工作量来维护一个独立的差异化版本。如果我们希望增加可扩展性，以便能够利用 IBM（或其他人）的独特功能，我们会在社区内创建必要的 API 或 SPI。我们还通过投资来确保不会滥用这些扩展点，带来套牢的隐患。

结束语

正如您所看到的，IBM 非常重视开源。在参与项目时，我们着重关注对企业最重要的方面：互操作性、可移植性、安全性、可伸缩性和可访问性。我们不断投资于社区建设，帮助制定相关计划，进而交付客户所看重的种种特质。我们重视开放式治理，因为它可确保那些为我们的企业产品和解决方案奠定基础的项目能够长期持续取得成功并一直可行。

参考资源

• 开放生活：“如何将您的开源项目扩大 10 倍，并将收入增长 5 倍”
• Apache Software Foundation
• Eclipse Foundation
• Linux Foundation

本文翻译自： IBM’s approach to open technology （2019-03-19）