作者：Philip Estes 和 Doug Davis

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

* 接上篇：https://www.jianshu.com/p/2fc8c00d95e2 *

开放治理： 基金会模式‍

超越开源

我们已经看到开源不再是被孤立的集体或与世无争的了：开源的商业化和普及化引来了一些公司和大企业的投资和参与。但随之而来的问题就是，在这些项目中商业化和社区的兴趣之间的冲突日益的计划，尽管开源有太多精明的参与者。

“在开源和商业利益的十字路口，问题日益严峻的是有关权威、真实性和文化的问题。——Nathen Harvey, Information Week”

Nathen Harvey 在 Information Week 中的文章中指出了三个问题：“项目应该由商业的赞助商驱动还是外围的贡献者驱动？商业利益是否应该凌驾于社区的意愿之上？该如何以及在哪里为商业实体和开源社区之间划上一个明确的界线？”

这三个问题确实是异常的尖锐，回答起来就显得非常的关键，但通过基金会的模式，开放的治理可以解决大多数的问题。

不过，首先还是让我们来了解一下开源软件世界的基金会的历史和崛起，这将更加的有助于我们的理解。

基金会的崛起

让我们先来看几个较为著名的基金会，以及在特定社区所扮演的角色。通过对这些基金会的快速遍历，希望可以更好的理解他们，看他们如何通过开放基金会的模式来分享愿景以及是如何开展工作的。

1    Apache 软件基金会

Apache 基金会（ASF）创立于1999年，创立时主要的工作时围绕 Apache HTTPD web服务的项目进行开发、资金和治理的协调工作。发展到今天，ASF 已经是世界上最为著名和成功的托管开源项目的基金会之一了，在它的管辖下有超过300多个项目。ASF 通过定义法律和协作框架来为开源项目托管和协作开发铺平了道路，现在已经是基金会的标杆，很多后期的基金会都在效仿 ASF 的做法。举例来说，Apache 许可证，Apache 旗下所有的项目都是使用的 Apache 许可证，同时也是今天很多项目使用及最受欢迎的许可证之一，当然这不仅仅是指在 ASF 的托管之下的。尽管 ASF 最初是从项目 Apache web 服务起家的，但是经过了这么多年的发展，ASF 已经在项目上覆盖了很多技术，有编程语言、云计算平台、甚至还有办公效率套件。

ASF 采用的是精英主义路线，所有的事项都是通过受欢迎的社交技术——公开的邮件列表、WIki、代码仓库等来进行的。有一些 ASF 下所开发的项目成为了非常受欢迎的项目，甚至成为了事实上的标准，但是 ASF 本身并非是一个制定标准的组织，而且也不会像 W3C 那样的组织去专门的制定、生产标准。

2    Linux 基金会

Linux 基金会在2007年成立，由原开源开发实验室（OSDL）和 自由标准协会（FSG）合并而成。目的是提供发行版中立的发展和加强 Linux 操作系统及其相关的技术。据其官方网站的说法：

Linux 基金会旨在保护和激励自由的理念，通过 Linux 开发来加强合作。而且要分享这些理念来加强和巩固，目的是让我们生活的地方未来更加的美好。

Linux 基金会最初成立的目标之一就是为 Linux 的创始人不受任何厂商的影响保持中立，因为这些厂商可能会影响内核开发的优先级。这个规定在今天仍然生效，即使是有了诸如 Linux 内核维护人 Greg Kroah Hartman 这样受雇于 Linux 基金会的人的参与。除此之外，Linux 还旨在推动 Linux 全球会议的管理、保护 Linux 的商标、以及处理法律和许可证的问题、并且还会在规范上出一把力，如 Linux 标准工作组制定的 Linux 标准接口。

3    Linux 基金会合作项目

和 ASF 类似，伴随着 Linux 基金会渐渐的成熟，也开始孵化一些和 Linux 相关的开源项目了，但是项目并不会特定于和 Linux 操作系统开发有关。通过合作项目的促进，已有的 Linux 基金会流程，管理员支持，以及可以直接利用的治理程序，可快速而有效的生成新的合作项目。近年来，Linux 基金会合作项目的名单日益渐长，其中包括开放大型机项目、汽车应用，乃至现在的云计算平台项目诸如 OpenDaylight、OPNFV，以及 Cloud Foundry 基金会、开放容器促进会、云原生计算基金会等。

为了能够更为透彻的了解在云计算的世界这些合作的项目基金会究竟又何特别之处，让我们来一同探究一下近来进入 Linux 基金会合作项目羽翼之下的四个子基金会。

4    Cloud Foundry 基金会

Cloud Foundry 是一款提供 PaaS（平台即服务）环境的开源项目，PaaS 是可以为开发者有效的提高交付应用的能力，而且还是跨范围的运行时环境的，从 Java 到 Node.js 再到 Python、Ruby、PHP、乃至于 基于 Go 的应用。Cloud Foundry 最初是由 VMware 发起的项目，后来交付给了有 VMware、ECM 和 通用电气 联合成立的新公司 Pivotal 软件全权接管。

当 Cloud Foundry 成为 Pivotal 的一个开源项目时，Pivotal 则基于开源的代码库来为客户提供免费的和商业的产品。很明显，Pivotal 是控制着项目和社区的。为了解决这样的一个单一厂商控制的局面，在2014年12月成立了 Cloud Foundry 基金会，隶属于 Linux 基金会合作项目成员，这个新的组织目的是防止有那个单一的厂商将项目控制，而且将 Cloud Foundry 转变为一个真正的开放治理模式下的项目。

5    开放容器促进会

我们将会在开放云的合作一章更加详细的谈论开放容器促进会（OCI），但这里必须提及的一点是 OCI 是托管在 Linux 基金会合作项目之下的。在2015年6月，OCI 的组建就是为了让应用程序的容器化在两个竞争的运行层面标准化和协调性。众所周知，Linux 容器在过去的几年里可谓是非常火的技术，这一切都得归功于 Docker 在应用程序容器运行时和生态环境的构建和实现。但是这里面，有一个现象值得大家注意下，那就是 Docker 是近年来才出现，并段时间崛起的技术，但是称之为 Linux 的核心技术之一的 “容器”已经出现了十多年了。随着容器技术的不断升温，Docker 也开始有了一些批评的声音甚至出现了强有力的竞争者。在2014年12月，CoreOS，一直以来都是 Docker 的盟友，发布了容器的运行时环境——Rocket。OCI 的设立就是协调这两个竞争者的规范和实现，即 Docker 所提交的 libcontainer ，也就是 Docker 的核心容器运行时组件；和 一个新的用户运行时环境，名称叫做 runC ，基于规范的实现，是 OCI 治理和控制的。

目前来说，OCI 仍然处于形成阶段，但是不论是 CoreOS 还是 Docker，（甚至是 Google、红帽、IBM、华为、以及其它）均是最初的创始成员。目标都是为最终用户建立一个可移植的、标准化的运行时的规范实现，共同构建容器创新的生态环境。

6    Node.Js 基金会

在2009年由 Ryan Dahl 和他在 Joyent 的工程师团队所发明的 Node.js，在短短的几年证明了这是一个用于 web 应用程序开发的服务端，基于 JavaScripts 语言实现。Node.js 从诞生之日起就是开源的项目，许可证协议采用的是 MIT 许可证。Joyent 引领此项目的开发好多年，从最初的仅支持 Linux 平台下，最后移植到微软的 Windows、Apple 的 OS X、乃至于如 IBM Power 和 Z 系列的架构平台之上。在2014年末，Joyent 的治理下开始出现了一些分歧，有一部分工程师开始以全新的分支——io.js，这对于 Node.js 可谓是一件不好的事情，io.js 的发布周期短时间就拥有了更多的用户。

在2015年2月的 Node.js 研讨会上，有人提议需要一个厂商中立的基金会。没过多久，在那个夏天来临时，Node.js 和 io.js 两个项目宣布合并，成立 Node.js 基金会，放在 Linux 基金会合作项目之下。就这点来说，Node.js 基金会可谓是开放治理模式的成功典范，是厂商中立的基金会实现。和其它我们讨论到的其它基金会相类似，它会采用业务（董事会）委员会混合技术指导委员会的方式，而后者则是技术决策的精英主义。

node.js 基金会有6位铂金创始，其中也包括了 node.js 的创始者——Joyent，以及16位黄金和白银成员。Node.js 基金会致力于为其开发提供向导，希望node.js 能够在迅猛的发展道路上稳步前进。

7    云原生计算基金会

我们在前面讨论过的 OCI，是针对应用容器化的底层的运行时的规范所成立的组织。但是越来越多的云厂商开始意识到 OCI 的工作还远远不够能涵盖所有的一切，虽然对于基本的单个容器运行时很重要，但是更高级别的管理结构也需要一个全行业的标准。在2015年的8月，仍然是在 Linux 基金会的合作项目羽翼之下，成立了云原生计算基金会，在本文写作的时候，CNCF 的工作确切范围仍在商讨中，但是已经聚焦于数据中心内的容器集群的编排、分发、发现、以及生命周期管理。这些技术的集合统称为“数据中心操作系统”（DCOS）。

和 OCI 一样，CNCF 也会采取代码加规范的做法，在开发 DCOS 架构规范的同时会实现它。目前，Google 的 Kubernetes 和 Apache Mesos 项目已经开始讨论实现 CNCF 的规范。

和 Node.js 基金会类似，CNCF 是由一些云计算业界的几家企业共同发起的：在本文写作的时候共有22家公司支持CNCF，其中包括一些大型的企业诸如 IBM、Intel、Huawei、Google以及 AT&T等。这里有一个有趣的现象。我们已经能够看到开源和开放治理跨界的合作，在云计算的环境中，在支持的成员公司中还包括 Docker、Cloud Foundry、Weaveworks、以及 CoreOS——所有的这些公司都是开源项目，都对于云计算的未来编排和管理有着合作的意愿。我们将会在后面的章节中接着讨论这点。

8    OpenStack 基金会

OpenStack 项目发起时间是2010年，由 NASA 和 Rackspace 联合，目的是想为数据中心的基础设施管理创建一个可编程的、基于 API 的 IaaS（基础设施即服务）层。在2012年又有很多厂商参与进来，这时并一起创建了 OpenStack 基金会，也就是现在运营着OpenStack项目开发的法律、技术和行政治理。

OpenStack 项目最初是致力于计算、存储和网络资源的管理，但是随着项目的成长，包含了大范围的 IaaS 相关的项目，每个项目都有特定的名称；最初均是处于孵化，一旦成熟之后就会进入 OpenStack 官方的半年发布一次的版本。目前，2015年发布的 Liberty 版本有 16个独立的子组件交付。

(N.B.:译者注：翻译本文的时候，OpenStack 已经发布 Mitaka 拥有19个子项目 。)

基金会本身由多个社区组成，有运维、有用户、也有开发者社区，以非常健壮的治理模式快速的成长着，治理模式有各自的章程，用于指导其管理和开发的流程。并由董事会和技术委员会进行监督。OpenStack 现在拥有8家白金赞助商，（对应8位董事会的代表）17家黄金赞助商，以及120家企业赞助商。

若是没有这样的正式的治理和开发流程，就不会有如此多的云计算供应商一起工作在 IaaS 层和 API。但是有了基金会的结构，一些公司，诸如 IBM、HP、RackSpace、Intel、以及其它共同协作来开发核心的技术，然后再去基于 OpenStack 平台之上创新和差异化自己的产品，我们会在本文后面花笔墨讲解更多的这样的合作，以及“合作竞争”的模式。

9    其它开源的基金会

限于篇幅和时间关系，我们无法做到涵盖所有的开源基金会，以及他们所支持的开放管理和相关的流程，以及围绕和商业的合作等等。但是，仍然有一些事值得我们为之写上他们的名字的，正式因为他们，才能够让整个的开源更加的健康。他们有：

自由软件基金会（FSF）

Creative Commons

Eclipse 基金会

Internet Systems Consortium (ISC)

Mozilla 基金会

开源促进会（OSI）

软件自由法律中心（SFLC）

还有我们无法在这里一一列出的，他们都在相应的开源项目和促进中扮演着各自的角色，尤其是在商业和独立兴趣之间的平衡。

“其它”的开源：开放标准

在我们结束讨论开源和开放治理之前，还有值得一提的就是，在开源软件项目中目前还有一股商业参与的潮流，很多的业界公司都在使用非源代码的基础来实现类似的厂商中立的合作，通过使用标准来达到合作的竞争。

若想忽略掉软件产业，哪怕是一小会，只需要简单想一下你每天的日常生活即可，你会发现非常多的例子，如企业、某些情况下的政府机构等，他们会联手创建一些标准的设计或组件，这对于所有人都是有好处的——无论是作为生产者，还是作为消费者。这些标准或者是标准的设计，例如 USB 端口 或国家的插头类型等，是产品在一定程度上能够达到制造厂商之间的互操作性、可移植性、以及重用性。商定的标准仍然允许基于这个共同的基础之上进行开发创新和突出个性；每个制造商或生产商都可以通过一个共同的标准来受益。

在软件的世界中，我们依然能够看到这种合作竞争的局面。举例来说，这如原先所提到的一样，Apache web 服务通过开源项目的合作取得了巨大的成功，但是Apache的项目最初并不是在web 服务的核心技术上去创建一个共享的标准；更确切地说，它是关于使用源代码作为协作的基础。还有一些组织，诸如 W3C（由著名的万维网创始人 Tim Berners-Lee 在1994年创立）和 IETF，IETF 创建的初衷就是开发协议的标准，是今天互联网能够成功的的重要基石。但是这些标准若没有诸如Apache这样成功的项目就不能实现。

这些标准的成员是由组织和公司组成的，他们一致的认为没有这些跨越计算机和人沟通的协议的话，互联网是不可能发展起来的。举例来说，想象一下没有 HTML 标准的 Web，每个站点都是以自己的语言来实现的页面布局！互联网——尤其是 Web，作为接近无限的资源，轻易可获取的信息，——我们今天所拥有的一切也就不存在了，这都得归功于多年以前所建立起来的核心标准。

即使是在今天，开放标准仍然在业界占有举足轻重的地位，当然变化还是有的，我们已经看到从过去的“on-paper-standard”转变为以代码为标准或者是参考实现的规范，我们前面讨论过的开放容器促进会即是很好的例子。鉴于这种变化，我们发现，负责开放源代码项目的开放基金会的模型是未来工作的一个更令人信服的模型。当然，未来的云计算的活动会由新的开放标准来保驾护航，然后在以开源的方式实现，但我们相信，这将是由供应商中立的行业联盟领导的情况下，逐案决定，为开放标准和开源软件再次提供一个公平的竞争环境。

开放治理：合作的重要性

在本章的开始我们考虑了在开源软件项目中商业参与相关的重要问题。正如我们已经检验过的通过基金会模式的开放治理实现那样，我们注意到了，开放的治理实践回答了有关开源中的影响、所有权、领导力、以及制定决策。每一个项目都会在独立和商业贡献者参与的纠结成长之路，我们相信通过厂商中立的开放治理，能够打造一个精英式的技术开发实践，都会让开源作为事实上的开发模式而持续有力发展，无论对于商业的还是非商业的实体。

在接下来的一章，我们会更加的实际一些，来看利弊之处，社区如何运营、并举例说明和指导在开源的革命的实现飞跃，尽可能的包含到在未来可能会计划启动一个合作的项目的细节。

作者简介

⊙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，并有多个企业使用此实现来做他们的实时协作。