商业公司主导下的非营利开源软件基金会之 ———

点击上方蓝字关注开源之道

成为由个人和组织所组成的共同体通力协作打造商业友好的开源项目的领导者。

———— Eclipse 愿景

Eclipse Theia 1.0 发布，剑指微软 VS Code

前一阵子，Eclipse 基金会高调发布了一个新的可用的项目—— Theia 1.0，而且PR 直接称：一款可以替代VS Code的开源云 IDE，并且使出了杀手锏：VS Code 的插件可以无缝直接使用。

技术如何我们暂且不论，这是否是一种似曾相识的感觉？VS Code 是否像极了GitHub 的Atom？如果你是身处软件行业多年的老兵，不妨回忆一下二十多年以来，为了讨好开发者，各个商家争先创新、降低价格、投其所好，无所不用其极的各类做法。

如果忘记的话，这里简单提示一下：java 与.Net , JBuild 与 Visual studio……

商家从未放弃过在赢得开发者这块宝地上的竞争！

什么是501©(6) ？

在进一步了解之前，笔者想先介绍一下和具体的IT技术无关的一件事，准确点说是关于合法机构的法律文件解读，过程显然是有点无聊和乏味，但是耐心的了解一番，对你总是有益而无害的，而这篇文章也为另外一篇:商业公司主导下的非营利开源软件基金会之 ———— Cloud Foundry 基金会简史，也需要同样的背景知识。

因为我们前面介绍的很多组织都是501©(3)类型的，也就是说是慈善机构，基于人道主义也好，或者是行最大的善也罢，这类组织的目的只有一个：为了人类本身！然而，这也不是唯一的组织机构，这个世界上有形形色色的由人所组成的团体，这些团体的性质也各异，有可能所做的事情完全相同，但是通过社会属性：伦理、经济、法律、文化等等解读，就有了完全不同的色彩。

试图通过介绍一个基金会，而将一个法律实体的来龙去脉完全展开来讨论是不现实，比如追溯 501©(6)的非营利商业机构是美国1913年的Tariff 法案，以及后来逐步细化和添加条款的变更，有兴趣的读者可以详细阅读公开的文件： IRC 501©(6) Organizations ，其最为基本的7条要求如下：

必须是商业组织共性所组成的个人联盟，而且其目的也必须是推动这些商业组织的共性。
成员必须是组织机构，且要有意的去扩展成员
必须是非营利性的
任何私人股东或独立个人均不能从净收益中获得好处
它的活动必须针对改善一项或多项业务状况，以区别于为个人提供的特定服务。
它的主要活动不包括为个人提供特定服务
该机构绝对不能从事任何的常规性盈利业务，即使是为了生存需要而和企业合作，也是不可以的。

也就是说，是公司化运营，但是不能营利，只供组织的相关个人日常开销。在国内的语境下，就作者本人而言，是一脸懵逼，没亲眼见过这样的组织啊！最最让人眼羡的是：免税！这样的组织，恐怕要等祖国改革几次之后才可能有的吧？

作为第三代开源软件非营利组织的机构，501©(6) 无论从哪个角度看，都是有利于开源项目本身的发展的，当然，某种程度上也有利于具有匠人精神的开发者们专注于自身能力的自由发展。

那么从公司的角度讲，权衡之余，既希望是自己信任的人担任执行总监，又希望做到公开、透明，而不仅仅是一个慈善的组织，那么这样性质的机构无疑是最为合适的了。

Eclipse 作为 IDE 项目

谈到 Eclipse ，我们不得不回顾一下当年的IT技术大势，年轻的读者可以类比一下现在的Go语言、VS Code、以及云原生等技术领域的厂家、机构等的激烈角逐。

Java VS .Net

得平台者得天下，这是有识之士，或者说是商界精英的常见战略，2000左右，是互联网爆发如日中天的年代，以Wintel为代表的个人桌面，Windows 开发C#语言和.Net平台，是Java的最主要的竞争对手，正如浏览器方面，微软的以操作系统捆绑这个大招简直所向披靡。

那么就看谁能打动用户的心思了。这是商界的主要语言之争。IBM 押注Java，很早就在大量的产品中使用Java语言来开发。Eclipse 既是其中的参与者，也是其中的创造者。

微软 Visual Studio 打遍天下无敌手

有了语言的背书，接下来就是工具了。当时能够提供 IDE的厂家其实并不多，微软作为PC 操作系统的霸主，当然有天然的先天优势，要知道当时的集成开发环境还是备受商界青睐的产品。

IBM 后来想要居上，祭出开源这张王牌，正如后来的Sun 将Java 开源一样，通过免费来将高深的技术产品大众化，当然，作为用户，没有人能够拒绝的了免费，Google利用免费打败了很多的优秀的搜索引擎公司，淘宝在中国也利用免费（收取卖方租金）的做法打败了e-Bay，在软件开发这个细分的领域，通过免费来抢占开发者的习惯和技能，也同样有效。

Eclipse 的技术设计

有了以上的背景，我们可以简单聊聊 Eclipse 在技术上做的现在回看起来做的无比正确的事情，有心的读者一定可以看得出来，Eclipse 的设计是和Linux完全无心的技术完全不同的，Eclipse 从一开始就非常注重技术架构。

Eclipse 的起源

Eclipse 并不是如很多开源项目那样，在诞生之初就是开源的，如GNU、Linux、Python、Perl 等，而最初来自于公司的专有项目，来自于 IBM 子公司 —— Object Technology International (OTI)，研究和开发 IDE 初衷则是：

IBM希望减少向其客户提供大量然而又不兼容的开发环境，并提高这些环境中通用组件的重用性，希望通过使用相同的通用框架，开发团队可以利用彼此的组件，进行高度集成，并允许开发人员在项目之间共享。

这就是我们常常谈到的避免重复制造轮子 的做法。当然，Eclipse 也不是从头开始做起的，而是基于IBM 长期累积的开发产品线重构，可以追溯到 IBM VisualAge for Smalltalk™ 和 IBM VisualAge for Java™，这两款产品都是用 Smalltalk 语言编写的。IBM VisualAge Micro Edition™ 产品是用 Java 编写整个IDE的第一个较正式的实验项目，并且实际上相当的成功。Eclipse 继承了其中的最佳做法。

就在 IBM VisualAge 遇到瓶颈之时（对于第三方来说，非常难以扩展），IBM 另外成立了一个小型的专家团队（类似《人月神话》中的S360项目），基于之前的经验，进行全新的设计，采用全新的插件机制，让合作伙伴可以轻松的扩展。

如此的架构设计，也为以后的开源铺平了道路。

趣闻：Eclipse 的名称由来，很多人认为这个名字是针对当年的SUN公司，也就是开发Java的公司，但是据时任 Rational 部门的 CTO Lee Nackman 说，Eclipse 针对的主要是其竞争对手：微软的 Visual Studio，使用的是英语中的成语：*Eclipse* was to eclipse.

架构概述

Eclipse 的技术设计如下:

Eclipse 采用的是一种叫做富客户端平台（RCP）的设计，从图中我们可以看到如下组件构成了这个核心：

Equinox OSGi ——标准的bunding 框架
核心平台 ——— 启动Eclipse、运行插件
标准Widget 工具包（SWT）
JFace ——
Eclipse 工作台 —— 视图，编辑器，透视图，向导

采用了插件化的思想，这样的思想虽然在操作系统上，如GNU Hurd 上没有在软件工程上战胜，但是在IDE这样相对要弱上好几个级别的软件上还是得到了很好的实现。

战略性开源

经历过90年代的 Linux 和 Apache 的洗礼，IBM 在开源的认识上已经上升了一个层次，对于开源共同体的理解和认识也非同凡响，更何况经历互联网爆发时期的几家案例，IBM 在这个时候选择将 Eclipse 开源，以对抗微软，并利用Sun 对于Java的犹豫，基于商业上的目的，以及当时的IDE 市场，战略性开源，可谓是条件充足。

于是，在2001年采用联合多家类似公司的方式，声明开源，基于Eclipse项目结成联盟，其中参与的厂商有：Borland、IBM、Merant、QNX 软件系统、Rational软件、Red Hat、SuSE、TogetherSoft 和 WebGain 九家厂商。显然，由于Java的良好基础，以及架构上的天然优势，许可协议的商业友好，等等，一出手便获得了众多厂商的青睐和关注，两年之后，2003年就达到了80家。（这样火箭般的速度，还有Open Computer Project 和Kubernetes，作者注）。

开源项目的技术设计

Eclipse 除了可扩展这一天生的优势之外，（这可以吸引众多的下游独立供应商的加入），在架构设计上也着重考虑了如下三点内容：

模块化
可伸缩
稳定的API

具体的更细的内容，笔者就不给大家浪费笔墨了，详情请参考 Eclipse 的文档。

基金会的建立

在2001年将 Eclipse 开源，以几家公司联合治理的方式运作，显然已经无法平衡所有个人或组织，IBM 显然具有绝对的控制权，当然这也是IBM 想要的结果，项目欣欣向荣的发展，对于自己的商业产品也有着非常好的补充，然而，天下没有这么好的事情，如果再按照较为非正式的方式发展的话，面临着项目分叉的、各种衍生项目无处安身、各家利益抽风的严重问题。

于是，经历了一段时间的犹豫、探讨、妥协之后，在2004年成立了非营利的基金会501©(6)，总部设在加拿大的渥太华，IBM 当年提供了4千万美金当做启动，或许是有充足的资金，雇佣专业的人员，Eclipse 的组织架构相当的清晰，相应的文档也是非常的齐全：

首先，Eclipse 共同体由来自众多行业的独立个人和组织组成，然后，基金会会雇佣专业的全职人员来为共同体提供服务和支持，基金会的日常运转来自于成员机构的捐赠，治理则是通过董事会，战略开发人员和战略消费者在该委员会中占有席位，插件提供者和开放源代码提交者选出的代表也拥有相应的席位。Eclipse 的提交者通常某商业公司的雇员，当然也有的独立开发人员，他们才是Eclipse 的真正核心。

相关 Eclipse 基金会治理方面的文档材料，如章程、EPL协议、行为准则等，请移步：https://www.eclipse.org/org/documents/，有非常详细的记录。如章程部分，事无巨细，值得细细阅读和学习。

价值观

关于 Eclipse 基金会的使命，大可以总结为：

推进和鼓励旗下的开源项目，并为这些项目培养相应的共同体，以及商业生态。

正式这样，使得 Eclipse 是独一无二的，并定位于自身亦是由这些开源项目所组成的大的共同体，Eclipse 不仅致力于打造卓越的开源代码和共同体，也在基于这些项目在商业上寻找可以立足的地方，如此的兼顾于二者，也是Eclipse 能够获得成功的巨大原因。

WorkGroup式服务

基金会的角色是服务，那么基金会相应的工作组也有其自身的定位，Eclipse 按照自身的需求和理解，将其WorkGroup区分为5类，同时这5类也是Eclipse 基金会可以提供的服务：

中立的治理

作为一家非营利性质的中立机构，良好的治理是最起码的条件，所谓良好的治理，定性的内容可能占据的更大，如如何制定决策、政策制定、冲突解决等。

那么 Eclipse 治理 WorkGroup 就是解决这些问题的：通过研究和制定一系列的章程、协议、以及政策等，来确保基金会的良好运作。

另外，该工作组和代码的开发保持一致，参与的人员以贡献为选拔条件，没有任何个人或组织具有任何特殊地位或否决权。

知识产权管理

让来自不同机构/组织的人进行协作，那么共同开发的成果的知识产权归属问题要清晰明了，这是基金会之所以存在的理由之一。

该工作组就是为 Eclipse 基金会制定相应的知识产权政策，从而确保在Eclipse项目中创建的任何开源软件都可以供任何人使用，包括商业软件产品的开发人员。

Eclipse基金会对于促进和鼓励软件供应商使用Eclipse技术来构建其商业软件产品和服务是持积极鼓励的态度的。当然这不是简单的口头承诺，而是实际的法律条款落地的，那就是：基金会会要求进入 Eclipse 的项目遵循 Eclipse 公共许可证（EPL）的许可，EPL 是 OSI 获批的开源许可证，和 Apache 许可证、GPL 、MIT等齐名。

第二步则是要求所有在 Eclipse 开发流程之外所要贡献的源代码都要经过Eclipse 基金会知识产权的审批流程，这个过程包括分析选定的代码，从而确定代码的来源以及与EPL 许可证的兼容性等。一旦发现代码中含有与 EPL 不兼容的贡献，则需将这些代码过滤掉，是不可以成为 Eclipse 项目中的一部分的。

当然，知识产权的重要职责就是要确保：Eclipse 项目是可以被安全地分发到商业产品中的。

IT基础设施

作为开源的开放式开发方法，需要相应的技术支撑，那么也需要相应的工具，Eclipse 的基础设施提供如下：

基于 Git 的代码托管平台
Bugzilla 问题跟踪系统
基于 Hudson 的持续集成服务
邮件列表
新闻列表（Newsgroup）
下载分发站点
以及网站托管

这些都是通用的 Open Development Method 的常见平台。

开发流程

Eclipse 共同体已经有一套较为成功的开发流程了，涉及如此之多的不同组织的大规模分布式开发也算是业内典范，Eclipse 的开发流程核心哲学思想：开放、透明、meritocracy，和通用的开放式开发方式原则没有差别，该工作组的任务就是确保项目是在基于这个核心原则。

生态系统发展

这是 Eclipse 基金会的重点工作，也是支持开源共同体的重要方式，主要就是积极的营销和推广。

Eclipse 基金会有众多形式的活动，包括：

合办的市场活动
共同体技术会议（EclipseCon, Eclipse Day等）
在线资源（Eclipse Marketplace）
半年一次的会员会议
其他计划

旨在推动整个Eclipse共同体。

以上便是 Eclipse 基金会相关的内容，笔者以后会陆续的为大家介绍更加详细的内容，比如Eclipse 的开发流程，和Apache的开发一样，Eclipse 也有非常明确的角色、等级、贡献机制、议事决策方式等。

写到这里，可能看官有点不耐烦了：”你题目明明写的是成长与发展，怎么写了这么多了，还只是介绍Eclipse基金会是啥？“，是的，笔者也确实陷入了困境，如果说介绍Eclipse项目的变化的话，那么就顺着Eclipse的版本开发逐一介绍即可，从主流技术的趋势来看IDE 的发展，从小巧而趋于庞大；如果说介绍Eclipse 基金会的变化的话，那么从其加入会员数量和公司成员，以及每年的收到的捐赠数量上来看就好了，毕竟一直以来都是个成长的过程。这似乎都不是大家想要的，正如我们在介绍SPI的时候，选择了历届年度报告之 SPI 主席序言一样，Eclipse 基金会的成长，笔者采用同样的思路，那就是看其在年度报告中所展示的：

历年 Eclipse 的战略变化（敬请期待下篇）

扫码关注我们

更多精彩等待你发现

点击此处“阅读全文”查看更多内容