作者：Philip Estes 和 Doug Davis

翻译：适兕（“开源社”翻译组成员）

精心布局的开源（上）：https://www.jianshu.com/p/2fc8c00d95e2

精心布局的开源（中）：https://www.jianshu.com/p/8bd8c576be02

开放云的合作

鉴于我们之前所讨论过的有关开源的流行和商业化问题，我们知道在可预见的未来合作和竞争将会共存。我们也过了一遍几家基金会，他们都成功的让很多公司和独立成员共同遵守精英式的开发、技术规划、以及决策的模式，带来了厂商中立的竞争环境。在这一章中，我们会更加详尽的去了解关于云计算开源项目成功的指标。我们也会尽可能的为未来的项目提出向导性的建议，当然这均基于我们在深挖过去的和当下的、成功的和不成功的开源项目和标准的时候所证实的。首先，我们来总结一下上一章看到的治理模式。

1    通过开放治理促成的成功合作

“是什么成就了优秀的治理模式？” 这是一个让我们竭尽全力去努力回答的问题。通过研究过去和现在都很成功的项目——举例，Apache 软件基金会或 W3C —— 我们发现了一个通用的有关项目的文化的关键的方面，即“透明度”：无论是人员的组织，还是管理和开发的流程。“透明度”在此上下文中有多种不同的涵义，举例如下：

-- 社区的运营是否支持这样的一种方式：哪怕是来自社区外部的人们都可以关注社区的讨论和进度？举例来说，所有的文档（会议时间、问题列表、未来工作项等等）都会在网站上让人们访问，而且是以非常快捷、方便的方式。

-- 是否欢迎来自社区外部的成员？是否针对成员和非成员的反馈、提问、以及建议提供相应的机制？

-- 是否提供知识产权机制来鼓励分享想法？很明确的是，有一些开源项目的许可证是对于商业公司产品中使用是提出挑战的，反过来的话，如果有知识产权政策并不要求贡献，而是由社区自由自配并可重复利用，（没有，举例如支付特许权使用费），然后严格限制交换想法，这么就可以说社区成功了。

可以确定的是治理模式可能会包含成员的不同的等级制度（举例如根据年度贡献），必须保证所有成员拥有平等的机会获得晋升的公平流程。举例来说，如“付钱玩”的模式，其中一个公司可以通过简单地写一张支票获得了关键的领导作用，伤害了组织的感知客观性。通常，对于技术社区领导力来说，优点／贡献模型的效果最好。在众多我们所覆盖的开源项目中，只有那些提交了显著数量的有意义的代码的贡献者方会被认为是代码的提交者、审核者、或者是维护者等角色。

我们还注意到了，一个活跃的、开放的、友好的社区是项目极为重要的部分。成功的项目能够利用到我们前面所提及的要创造一个能够对新老成员一视同仁的公平环境。一个老的成员如何对待新进成员是衡量一个社区是否开放的重要标准。肯花时间去回答“菜鸟”的问题，而且会帮助新手们对于开发步骤、初始提交变更中的任何相关问题，而且也乐意帮助社区的成长、希望社区的成功，这样会鼓励更多的开发者，并因此而获得更广泛的专业知识和贡献。随着一个项目的成熟，我们注意到，现有的开发人员倾向于开始更具挑战性的新任务，因此，能够让新进社区的人络绎不绝是一个项目保持健康和成功的重要因素。如果让感兴趣的新人感到沮丧或被忽视，那么他们就会倾向于去寻找能够让他们觉得舒服的环境去付出时间和努力。

案例 01

封闭标准以及私有的API

在本小结中，我们来简要的看两个反例，这绝对是开源和开放标准治理模式的反其道而行之道典范，也是真正的开放协作的云项目失败的典型。

封闭标准：云基础设施管理接口

我们已经花了太多的时间和笔墨来讨论开源项目和开放基金会了，仅仅简单的提及了一些基于非代码的合作，诸如 W3C 的”Papaer 标准”工作。其中一个云计算的例子就是云基础设施管理接口（CIMI）。这样的一组关于云计算的规范正是在 DMTF 的主持下开发的，意图是将 IaaS 的用于管理虚拟化的资源 API 给标准化了。

CIMI 的成果代表了传统的标准开发方式，由一些开放的组织和过去的团体来具体制定。虽然这些机构的标准，比如 POSIX ，在今天依然是有很高的价值的，在大多数情况下他们的工作是在私下完成的，成员付费，并没有开放给公众来监督。他们所进行的讨论是不透明的，没有邮件列表、没有缺陷跟踪、也没有功能特性计划。虽然 CIMI 的规范也有几个业界的主要厂商参与进来了——比如 IBM 参与的 CADF规范工作，结果是它被 OpenStack 的审计和日志功能所采用，即它们使用的标准 CADF 消息格式——他们通常会集中在“规范第一”的方法。虽然还能体现一点点价值，但是这些规范的开发是没有考虑到实际情况的场景和实现的，而且会忽略掉那些没有付费的提供的有价值的部分，以及开放社区的专家们：普遍在开源界的 “多只眼睛” 所看到的。

非常遗憾，这就意味着所开发的参考实现严格限制了测试规范的目的，并且和真实世界中的软件系统没有关联起来。这也就是说此规范是——凭空想象来制造的——无法满足最终用户和运维人员的需要，这更加的证明开放的和透明的社区开发出的开放标准或开源实现更具优越性。

CIMI 的规范制定工作仍然在进行中，目前有多少云计算的社区采用了它还不得而知。由于DMTF天生就是创造规范的，但是其缺乏一个类似开放社区的反馈闭环，云计算产业作为一个整体都在向标准的 IaaS 层 API 倾斜，比如 OpenStack。

私有 API：Eucalyptus

Eucalyptus 是在2008年就发布的一款开源项目，那时还是第一款 IaaS 平台的开源版，在当时的一段时间，还算在云计算社区，获得了一定的发展。但是，现在再看，Eucalyptus 在社区几乎无人问津，在2014年被当时还没有拆分的惠普收购。我们无法得知为何 Eucalyptus 在 IaaS 项目中失败的全部原因，但是我们从一些事情上是可以看出一些端倪的。

首先，Eucalyptus 是特别针对兼容亚马逊的 IaaS 云产品——AWS 而写就的，其是直接实现了亚马逊的云 API。鉴于 AWS 作为公有云市场的领先地位，它似乎有可能成为替代基于亚马逊托管的解决方案的不错的选择。这个API的一致性将允许通过 Eucalyptus 私有或内部部署云的实现，将和市场领先的AWS公共云的用户完全兼容。然后，我们可以注意到此方法有两大问题。第一，作为一个和 AWS 兼容的解决方案，Eucalyptus 就得推迟自己的设计、功能集、以及潜在的成功赶上亚马逊 AWS 云平台——AWS 的功能可谓是日新月异（也就意味着更多的API），这也就意味着 Eucalyptus 将永远是以“追赶”模式来尝试迎合亚马逊随时心血来潮的功能和API的变化。Eucalyptus 等于被亚马逊牵着鼻子走。

另外，或是是更为重要的，亚马逊的 API 和云基础设施的管理是闭源的、专有的实现。亚马逊对其 API 并未提供任何的许可指导，这就留下了对于其它公司是否可以自由的实现其 API 集的法律风险，Eucalyptus 依赖于 AWS 的API 能力，将其作为核心，也是唯一能够为最终用户提供的，这可能是一个危险的势头。虽然我们也看到其它的开源 IaaS 项目提供 AWS 兼容的API，但它们通常也只是兼容可用，而且可迁移，还不是为最终用户提供的核心功能。

综上所述，Eucalyptus 的案例告诉我们应该注意到，作为一个开源项目不应违反事实——只能作受限的合作活动，以及近乎为零的开放治理，还是围绕这一个封闭的、单一厂商 IAAS API 去实现的。我们暂时不去考虑 Eucalyptus 在云计算的世界中受到的其它影响，我们至少可以明白，一个开源的云计算需要跨整个生态系统来进行开放的协作和开放的治理——从 API 的定义再到实现——应该提供更加友好的，厂商中立的社区，方能吸引到更多独立的个人贡献者和公司参与，从而产生更大的动能。

案例 02

开源构建的开放云

在看完两个有关开放协作和开放治理模式的反例之后，我们该重温一下我们在第二章所讨论的基于基金会的三大主要的云计算开源项目了，所有的这三个项目—— OpenStack、Cloud Foundry、以及 Docker——均拥有大型的社区，由众多的参与者，都是开放的生态系统，完全实现或者是正在进行中的开放治理，在现实的世界中影响力正在增长，从创业公司到大型企业，整个如此的跨度都可以提供生产就绪的云计算产品。

OpenStack

正如我们在上一章，开放的治理：基金会模式，所提到的，OpenStack 已经是一家大型的、快速成长的开源项目，主要的目的是提供一个全面的 AIP 和 IAAS 层的云计算技术栈的实现；它主要集中在计算、存储、网络等资源的管理上。OpenStack 基金会成立的目的就是对 OpenStack 项目承担起管理和推广、责任治理、商标和法律监督等。

但是值得注意的是，虽然 OpenStack 受到广泛的业内支持以及很多顶级供应商的支持，其开放源代码所实现的 API 规范（它是以 OpenStack 独特的模式“blueprint”开始的）并非是按照传统意义上的“paper 标准”去实现的。因此，额外的规章制度的变化，以及伴随着新的项目的增多和成长，OpenStack 基金会在应对供应商之间的互操作性实现显得非常的乏力。RedStack 社区项目和 Defcore 委员会就是为了补救 OpenStack 的情况而成立的，若是供应商有意使用 OpenStack 的商标和兼容性认证的话，它们通过提供测试套件以及要求“核心”软件代码的实现的验证。虽然这种方式在如此巨大而多样的社区会遇到各种坎坷，但是 OpenStack 基金会的治理和精英化的发展模式为社区的积极的协作和发展途径提供了一个坚实的框架。

OpenStack 在很多方面还显得有些稚嫩，但是随着基于 OpenStack 的云计算平台的增多，以及来自诸如IT大鳄 IBM、HP、Rackspace、华为、和思科（Piston）等重量级公司的参与，按照其目前的成长势头，势必在将来的一段时间内在开放云协作方面显示它举足轻重的作用。

Cloud Foundry

Cloud Foundry（CF）开源项目为用户提供了 PaaS 环境，致力于为应用程序的开发者们提供能够掌控运行时参数、可扩展性、应用的生命周期的部署框架，例如监控和自动重启。CF 还自动化了管理负载均衡和来自用户的路由请求，消除了许多通常与应用管理为开发和运维双方都有关的繁琐的任务。

正如我们在第二章：开放治理：基金会模式 所提到的一样，Pivotal 将 CF 项目的治理移交给了 Cloud Foundry 基金会，自2014年末都是以开放治理和厂商中立的精英型模式来运营的。

从一开始 CF 成为开源项目算起，再加上开放的治理，造就了健康的生态系统，有厂商持续不断的加入，且拥有广泛的业界云计算参与。基于 Cloud Foundry 的 PaaS 云平台产品有 IBM、惠普、ActiveState、Pivotal、以及CenturyLink均已上市，CF 仍然保持着增长的趋势，其虽然还很年轻，但是通过开放基金会形成的坚实的治理结构会给 CF 带来光明的未来，以及围绕整个行业的PaaS解决方案的合作。

Docker

Docker 是一款最新的开源项目，更准确点说是现在站在云计算的“风口”。Docker 的核心，是容器技术，不过其重新发明了轮子，目标是替代已有的容器技术—— LXC。容器技术是一种操作系统级的虚拟化技术，在用户空间的表现是看起来像拥有一套独立的系统一样。Docker 还希望通过改进用户体验，简单而易用的来在任何地方“构建、交付、运行” 应用程序的代码，甚至想取代传统的虚拟机或者是 PaaS 的某些应用场景。如果要对过去两年的 Docker 有什么要说的话，Docker 以非常成功的方式应证了开源！近来，Enterprise Technology Research （ETR）调查了 685家的CIO们，询问他们是否有意在接下来的一年里使用 Docker 相关的付费产品，令人颇为惊奇的结果是：97%的 CIO们说会！这是 ETR 创始以来得分最高的调查。另外一个可以佐证 Docker 的成功以及其庞大的影响力的是，亚马逊近期通过其 AWS ec2 的容器服务来支持 Docker 的API。尽管亚马逊通过其 AWS 平台支持了很多传统的开发标准，但是采取其它非标准的 API 定义尚属罕见。这就非常明确的承认了 Docker 在容器化世界的领导者地位——正如我们经常所看到的，很多厂商为了迎合 AWS 这个 IaaS 市场领导者地位，将自家的产品做的和 AWS API 兼容。

一如我们前面所讨论的其它的云计算的开源社区刚刚起步的时候，Docker 这个开源项目当面面临的问题，由一个单一的商业实体发起并控制，且名称都是一样的。Docker 有限责任公司在整个开源项目中是关键角色且是维护的主要力量。Docker 和我们前面讨论过的一样，拥有多个积极有利的一面，几乎所有的 Docker 的开源社区方面的工作、计划、和讨论都是在公共的论坛上进行的。Docker 的员工，也是开源社区的成员，对于新的成员表现出非常好的态度；事实上，我们的经验是他们（很多开源项目均是）到处去招徕新的成员加入，不管他们的经验如何、或是对于项目本身的了解。尽管 Docker 并非是一个理想的开源项目，因为它有着最为致命的——单一厂商的控制，其实正如我们所一路看过来的，这对于一个刚刚创立不久的项目是非常正常的。我们有理由相信，Docker 会在其下一个成熟的周期会确保项目的长期成功，包括如何治理和监督。

伴随着 Docker 的成功，Docker 也开始承受来自业界其它的角逐者的竞争压力，因为这是云计算应用交付的未来，只渐趋白热化的技术焦点。还有的压力是来自社区的分裂：最为显著的就是 CoreOS ，一直以来都是 Docker 的支持者，其实现了一套容器运行时环境，叫做“Rocket”，是 2014年12月发布的容器运行时规范“appc”的实现，这样公开的撕逼和社区分裂行为让 Docker 项目着实不太好过（希望不会太久）。大家最初的反应都是第一步先找一个就容器技术的开放治理组织，以及解决 Docker 运行时的核心规范。

在2015年6月，Docker 将其核心的容器运行时代码库贡献出来了，以 Docker 的子项目的形式出现，名称叫做“libcontainer”，以及针对开放容器促进会所要求实现的“runC”的新的容器运行时接口。关于开放容器促进会，我们将会稍后专门进行讨论。随着时间的推移，我们期望容器的开放治理和开放协作逐渐的成熟起来。这将对于商业和开源合作来进行创新和产品提供是有益处的，这对于目前对于消费者的热点技术来说，是消除他们担心厂商锁定，增强可操作性、可移植性的最好契机。

案例 03

开放基金会扩展了云的协作

我们所看过的所有的开源云项目都有自己所擅长的地方，并在自己所属的领域内找到内在的价值，但是我们所看到也只是起点，在未来会有更多的规范，那就是开放基金会所创建的合作多个开源项目。这些云计算的基金会将会将特定的技术领域如标准化接口、定义跨项目的合作等，且未来会比我们今天所看到更加的宽广。这些都是尝试解决下一代云计算挑战的令人激动的时刻，但是我们这里要特别讲述的是新近成立的基金会，它们更加的能够让我们感觉到开放云协作的新的时代。

开放容器促进会

正如我们在上一章所提到的，开放容器促进会（OCI）一款托管在 Linux 基金会的项目，旨在使用 Docker 的 libcontainer 组件作为实现容器运行时模式的标准化工作。除了以 libcontainer 作为参考起点之外，OCI 被指定为 CoreOS 已经开始的 appc 的统一来开发规范，Rocket 和 Docker 事实上的实现。目前的 OCI 项目还处于起草最终的批准章程阶段，项目的范围也在商讨当中，预计至少要标准化容器打包或 bundle 格式的定义、运行规范，以及通过容器如何被管理的生命周期所决定的API。bundle 或打包代表了容器文件系统的内容以及所有运行时执行所需要的元数据配置。生命周期的定义将会定义如何管理容器的运行时，即启动、定制、暂停、和恢复容器。

OCS 是下一代开发标准和跨项目合作的标杆。正如前面我们所讨论过的，过去都是有标准的组织来开发“paper标准”的，然后在要求所有的实现者来测试其所定义的规范。相反，现在很多的开源项目均是专心的用代码来实现，以及它的 API ，当积累到足够的人气的时候，已经成为事实上的标准，毋需任何的规范、互操作性测试、以及所有感兴趣的参与者们的联合通过。

OCI 在这两者之间都会做一些尝试：规范或标准，将会以开源的实现为参考进行开发。而模式是不需要追求过新，Docker 同意使用这些参考的实现作为 Docker 自身的一部分，Docker除了消化社区定义的参考实现之外，我们还看到 Cloud Foundry 开发社区的建议是使用 runC 的参考实现，来作为 Cloud Foundry 的应用框架内的容器运行时标准。这是 OCI 刚成立就表现出来的亮点，说明这些参考的实现不仅是规范的精确表示，而且还会立即在现实世界的场景得到使用和测试，来自实际的客户体验，帮助云计算社区确保该规范是满足实际需求的。另外，我们还看到 OCI 规范的多个实现都在开发当中。这确保了没有一个特定的实现是非必要的编纂实现。此注意力集中在将标准与真实世界的代码库链接起来，在多个云厂商的共同开发下，这是标准化流程很自然的下一步的走向，这与我们所一直以来所坚称的开放治理模式是开源项目成功的基石是吻合的。

云原生计算基金会

在2015年6月所创立了 OCI 之后不久，一些云计算市场上关键的角色开始意识到需要在 OCI 所提供的运行时环境之上建立一些标准。尽管在单个容器的核心管理上的重要性已经达成一致，但是在这之上更高层次的容器管理也非常的有必要。于是，在2015年8月，在 Linux 基金会合作项目的羽翼之下，云原生计算基金会（CNCF）成立了。，在本文写作的时候，CNCF 的工作确切范围仍在商讨中，但是已经聚焦于数据中心内的容器集群的编排、分发、发现、以及生命周期管理。这些技术的集合统称为“数据中心操作系统”（DCOS）。

虽然我们现在还无法明确的描述 CNCF 目前的工作范围，但是我们有理由相信，如此众多的业界大腕们联手通过开放式的精诚合作，能够为 OCI 所铺垫的标准化交上一份满意的答卷的。尤为重要的是，在这个高级别的如编排、生命周期的层次中，我们希望看到围绕分发、发现、和管理特性的通用性，能够增进各个供应商之间的互操作性，尤其是在开放和混合云解决方案的开发上。

2    请在开放云中站稳您的脚跟

到现在为止，我们已经捋过了多个开源项目、多种开放治理方式、以及一些基金会的模式，且可以看到对于云计算的技术来讲，真正的开放才是未来，才是真正有价值的，即协作的创新和合作竞争这条道路。我们也已经注意到了，其中主要的云计算的倡议和项目，越来越明显的感觉到，要完成很多的跨项目的合作才能解决云计算日益临近的挑战。

我们也可以看到，在运维人员、开发者、生产者和消费者之间的界线越来越模糊，而且代码、社区、和开源文化的性质正在悄然发生着变化，已经超出了传统的涵义。这就必然导致一个任何人只要有兴趣就可以成为开源项目的开发者和贡献者的扁平化时代的到来，至于方式，无论是为最终用户完善文档还是为开发者提出新的特性的建议，已经不是需要特别提醒的常识。

对于感兴趣的最终用户来说，这意味着再也不是站在纯粹的消费者一边的了：可以投入到自己感兴趣的项目，根据自身的需要在项目未来的发展方向上发出自己的声音。对于开发云计算平台的公司或者是运营云服务的公司来说，投入到开源中来，既可以受益于社区，又可以加速进入市场的准入门槛，以及不仅能够实现自己的利基专长，还能够吸收其它的来自开放社区的能力。参与到围绕关键云计算项目的基金会开放治理中来，还有助于提供公平的竞争环境，作为更为广泛的参与提供发出更多的声音以影响厂商中立的决策制定。

如果你正在考虑将自己的内部使用的技术开源，又或者是通过创建独立或企业领导引导的新社区项目，请记住，请选择将项目开放，以获得在整个生态系统的长期的生命力。一如我们所看到的那些成功的开源项目一样。你需要让其他各方的人们参与进来，并成为一些领导的角色。由健康的开放治理模式来引导。基于精英主义的技术发展路线，这在开始的时候是蛮困难的——因为没有人乐意将自己的想法或项目放弃控制权的。然而，正如我们所列举出来的，这条途径在云计算中是最为有利的，真正的协作！

3    总结

我们相信开源软件项目通过健康的开放治理原则的治理下，以及厂商中立的基金会的交付实践，会缔造一个成功的云计算相关技术的未来的！我们已经看到一些大型的项目如 OpenStack、Cloud Foundry、Docker ，以及我们在前面讨论过的围绕它们的每个基金会，强强联手蓄势待发、企业的赞助和参与，引来了一大堆大大小小的厂商参与。这些开源和开放治理的项目，既允许广大社区协作，也允许独特的创新，这就可以让传统的厂商和初创公司基于开放的技术交付云的产品都可受益。

另外，我们也相信，在不久的将来，开放云的的跨项目合作将是趋势，通过一些基金会的庇护，在云计算的底层和应用层的编排和管理组件寻找一些标准的关键组件。对于 IaaS 或 PaaS 来说，客户最为需要的不是一个项目就能满足所有需求的所谓的产品，而是会覆盖多个潜在开源项目和产品的全面途径。跨多个云基础架构类型的编排、集群管理、以及分布式／部署的标准接口——举例来说，虚拟机和容器——在下一次的变革中，谁将是云计算中的王者？在这些关键的概念上的一些通用性和互操作性都是跨多个厂商和多个相关的开源项目的协作的。这就带来了众多的机会，一个潜在的新的利基厂商的实现，将带来新的收入、新的产品。

我们深信开放云的未来就是将开源精心的规划。

作者简介

⊙Philip Estes：

Philip 在 IBM 开放云技术团队担任高级技术组成员的职位，目前代表 IBM 在 Docker 开源社区，亦是 Docker 的核心维护者。Philip 还和 IBM 的产品团队以及客户管理一起共事过，将开源的云技术转化为实际的产品、解决方案和 IT 项目。Phil 的成员团队均工作在关键的开源云项目的上游，如 OpenStack 、Cloud Foundry 、Docke 等。在 Phil 加入开放云团队之前，Phil 是 IBM Linux 技术中心的首席架构师。

⊙Doug Davis

Doug Davis 在 IBM 的开源云和标准部门工作。他在开源和标准这个细分的领域内有超过15年的工作经验，曾经参与过过个现下非常流行的研究标准，诸如 Apache SOAP & Axis 、围绕 Web 服务／SOAP 的 W3C 和 OASIS 标准、OpenStack 、Cloud Foundry 、以及最近参与的 Docker 、OCI 、和 CNCF 。他还是 WSTF 的创始人，WSTF 是基于 Web Service 的内部操作机制的实现，地址是 http://soaphub.org，并有多个企业使用此实现来做他们的实时协作。