2001 年 11 月，IBM 向开源社区捐献了 Eclipse 代码，自此 Eclipse 在开发者社区得到飞速发展。2006 年 1月19日，Eclipse 国际高峰论坛也首次登陆中国，在清华大学信息科学技术大楼举行。在这次 Eclipse 大会上 developerWorks 编辑团队与 IBM 的 Eclipse 策略经理 John Kellerman 进行了座谈，聆听了他对 Eclipse 历史的追溯、对 Eclipse 架构的分析、对 Eclipse 现状分析、对未来发展的展望。
John Kellerman，IBM 软件部 Rational 产品总经理，与 1984 年加入 IBM, 一直从事应用开发工作。2000 年初，John 开始加入了 Eclipse 项目，现在任职 IBM Eclipse 策略部总经理。他现在的主要工作是在 Eclipse 基金会、Eclipse 社区中代表 IBM 的利益，与 Eclipse 成员公司合作。
developerWorks: IBM 开发工具的发展经历了从最初的 Visual Age到今天基于 Eclipse 3.0 的产品, 可以说是非常大的飞跃，您可否给我们谈一下这其中的历史？
John: 我在加入 Eclipse 项目之前，是 IBM Visual Age for SmallTalk 的产品经理。Eclipse 起源的一个非常重要的原因是，当时IBM 面临着一些挑战需要去解决，即 IBM 开发工具 Visual Age for Java 和 WebSphere Studio 很难集成到一起，而且底层的技术比较脆弱，因此进一步发展非常艰难，无法满足业界应用开发的需求。
因此，1998 年，我们开始了下一代开发工具技术探索之路，成立了一个项目开发小组，经过两年的发展，2000年，我们决定给新一代开发工具项目命名为 Eclipse，Eclipse 叫法当时只是内部使用的名称。这时候的商业目标就是希望 Eclipse 项目能够吸引开发人员，能发展起一个强大而又充满活力的商业合作伙伴（独立软件供应商）社区。同时我们意识到需要用它来对抗 Microsoft Visual Studio 的发展，因此从商业目标考虑，通过开源的方式我们最有机会达到目的。此外，IBM 推出了 Eclipse 试用计划，允许 IBM 以外的开发人员使用 Eclipse。结果证明我们的决策非常正确，Eclipse 从此在开发社区广为流传。Eclipse 也就成为这个项目的正式名称。
我们认为开源 Eclipse 不能只是简单地贡献出源码，创建一个开源项目然后放在开源许可证下；我们需要建立起多家公司的合作关系，否则就不足信服，不是真正的开源项目，而只是 IBM 的一个项目。因此在 2000 年到 2001 年之间，我做的主要工作就是去拜访一些公司，与他们谈论 Eclipse,邀请他们加入 Eclipse 项目。 您可以想象，这是非常有趣的谈话，最终，我们与 8 家公司达成了一致，其中包括一些 IBM 的竞争对手 WebGain、Borland, 还有一些盟友如 Rational（Rational 当时还没有被 IBM 收购）。
2001 年 12 月，IBM 向世界宣布了两件事，第一件是创建开源项目，既 IBM 捐赠价值 4 千万美元的源码给开源社区；另外一件事是成立 Eclipse 协会（Eclipse Consortium）,这个协会由一些成员公司组成，主要任务是支持并促进 Eclipse 开源项目。
从此，我们看到了 Eclipse 本身、会员、插件（plug-in）和 Eclipse 社区飞速成长。2003 年，我们意识到这种会员模式很难进一步扩展，有些事务操作起来很困难，比如无法筹集赠款、无法成立合法理事会，这主要是因为 Eclipse 协会不是一个法律上的实体；此外，尽管 Eclipse 成功有目共睹，但仍然有些业界成员没有加入，他们认为是 Eclipse 的真正领导者是 IBM。因此我们认识到创建一个独立于 IBM 的 Eclipse 将会对 Eclipse 的发展非常有利, 于是 IBM 与其他成员公司合作起草了管理条例，准备成立 Eclipse 基金会（Eclipse Foundation）。2004 年初，Eclipse 基金会正式成立。
developerWorks: Eclipse 由一个很小的核心和核心之上的大量插件组成，这种插件式架构给当时的开发社区带来耳目一新的冲击。您能给我们介绍一下 Eclipse 插件架构吗？
John: 对于 Eclipse 插件架构，一个很好的比喻是 Web 浏览器，它也有插件，Eclipse 插件和浏览器相似，都是要解决扩展性问题。对于一个 Web 浏览器，如果你想既能浏览多媒体动画，又想浏览 PDF 文件，那么你就需要两个不同的插件，才能保证两种内容都能在 Web 浏览器中显示。 Eclipse 也一样，通过它的插件模式我们可以安装不同的插件来进行 HTML 的编辑、数据库的设计、Java 开发、C++ 开发等等，所有这些开发工作完全在一个 Eclipse 安装平台上进行。而且 Eclipse 模型所能做的远超过了这些，理解 Eclipse 插件的关键是首先要理解 Eclipse 扩展点，正是这个扩展点帮您在 Eclipse 中添加新功能。例如，如果希望在菜单中添加一项，就是通过 Eclipse 扩展点实现的。
所以当 Eclipse 插件实现了一个扩展点，就创建了一个扩展，此外，扩展还可以创建自己的扩展点。这种插件模式的扩展和扩展点是递归的，而且被证明是非常灵活的。记得当我们着手对 Eclipse 开发进行区域性调查时，最初的决定之一是："We will eat our own dog food"（编者注：谚语，指一个公司在日常运行中使用自己的产品），即 Eclipse 团队要使用 Eclipse 进行 Eclipse 的开发。事实上，Eclipse 本身是一个核心的运行时绑定了一些在插件之上构建的插件，换句话说，Eclipse 本身就是一系列的插件。这样随着使用 Eclipse 构建 Eclipse 的经验累积，这种插件模式就变得日臻成熟。
developerWorks: IBM 对 Eclipse 已经投入了非常多的资源，IBM 在 Eclipse 的将来会扮演什么角色呢？
John: 目前 Eclipse 项目有 100 多个，IBM 参与了其中超过一半的项目，有 3 个主管在主持 Eclipse 相关的工作。2005 年我们还赞助了一些 Eclipse 创新基金和 Eclipse 奖学金。IBM 承诺在未来的几年内会一如既往地参与 Eclipse 研究，我们将会看到 IBM 研发出新项目，而在某些 Eclipse 项目上减少参与，这要看 IBM 的商业目标。最近我们提议了一个项目叫 Beacon, 是关于 Eclipse 流程框架的。我们将捐献一些 Rational Unified Process (RUP) 技术，基本上这个提议是要提供流程方面的内容。IBM 现在与一家叫做 Zend 的公司合作，希望在 Eclipse 上开发出用于 PHP 的开发工具。从商业方面看 IBM, 您会发现 Eclipse 是 Rational 软件开发平台的基础。此外由于 Eclipse 的插件模式、扩展性、集成性，我们为Rational, WebSphere, Lotus 和 Tivoli 构建了统一的平台。
developerWorks: 目前 IBM 的五大旗舰品牌都有基于 Eclipse 的产品, 这对 IBM 有什么好处？
John: 我们的目标是创建集成统一平台，我们有基于 Eclipse 构建的 DB2, Rational, WebSphere 等工具，这样客户就可以共同使用这些工具，有统一的界面风格，使用起来非常方便。对 IBM 自身来说，各个开发部门就可以关注于软件的核心性能开发，而不必要浪费资源做一些重新实现的工作，从而 DB2 开发部门就专注于数据库开发、WebSphere 专注应用服务器的开发、Rational 专注于建模、源代码管理，至于其他方面的辅助开发对于 Eclipse 来说是共同的。
developerWorks: Eclipse 是一个开源 IDE, 那如何通过 Eclipse 创造商业利益呢？
John: 对于 IBM, 在 Eclipse 技术开发方面与上百家公司合作，因为 IBM 看到了 Eclipse 作为通用的、开放的、标准的技术基础，其价值日益成长。当然，这种基础技术是不会带来创收的，没有人可以使用 Eclipse 技术来赚钱，但这并不重要，就像 Borland, Sybase 等公司都在花费钱做同样的构建工作，当然我们在这方面还有合作，但是我们还专注于将我们的核心功能组件构建在 Eclipse 平台上，例如，IBM 的 Rational Application Developer, 它是使用 Eclipse 作为基础，然后在这基础上添加了建模插件、Web 开发插件，还有其它更有价值的插件，这些插件我们是收费的。这就是使用 Eclipse 进行商业创收的模式之一。
此外，人们还可以直接为 Eclipse 构建插件，然后出售这些插件来赚钱，因为插件可以使用商业许可证发行。事实上我们建立 Eclipse 公共许可证，就是为了让 Eclipse 能很好的被商业采用，从而可以用它来赚钱，Eclipse 的所有成员公司基本都是商业软件提供商。目前全球有上百万开发人员在使用 Eclipse, 因此中国开发人员完全可以构建有价值的插件和工具，然后进行销售。同时 IBM 有一个合作伙伴计划，帮助合作伙伴宣传在 IBM 基于 Eclipse 的产品之上构建的应用。
developerWorks: 富客户端平台(RCP)目前是比较流行的应用开发模式，请谈一下 Eclipse 是如何支持富客户端的？
John: 在 Eclipse 的早期，有些用户试图除了将 Eclipse用于开发工具基础平台外，还用作更普遍的商业应用基础。他们认为一个 IDE 就是一个特殊的富客户端应用。这就是开放源码开发的魅力所在，当这些用户试着用 Eclipse 作为通用富客户端时，他们就把这些想法建议反馈给 Eclipse 开发小组。就这样 Eclipse 经过了 2.0 到 2.1 的发展，不断收到来自社区的建议和反馈，终于到了一个通用化的阶段。在3.0 版发行时，我们觉得时机成熟，于是正式声明将 Eclipse 作为通用的富客户端和 IDE。
其实最早的反馈是来自我们的 Lotus 开发小组，他们在 Eclipse 3.0 之前就意识到可以使用 Eclipse 来提供他们 Workplace 客户端的富客户端版本。从 Eclipse 3.0 到 3.1 再到 3.2, 我们看到富客户端平台应用的快速增长，同时也收到越来越多反馈帮我们完善提高。
我最欣赏的 RCP 应用之一是在EclipseCon 2005 上的一个演示，演示的是美国国家航空航天管理局(NASA)的一个项目，当时 NASA 在加利福尼亚州有个实验室叫 Jet Propulsion Laboratory (JPL)，负责火星探测计划，他们的管理用户界面就是一个 Eclipse RCP 应用，通过这个应用，加利福尼亚州的工作人员就可以控制在火星上运行的火星车。在演示过程中，有人问为什么使用 Eclipse, 回答是，使用 Eclipse 这门技术，他们不用担心，而且还节省了不少纳税人的钱，因为他们只需要集中资源开发控制火星车的应用就可以了。
developerWorks: Eclipse 现在非常热门，您认为从微软的开发平台转到 Eclipse 上容易吗？
John: 这个问题可以从两方面来说明，一是软件提供商从 Visual Studio 移到 Eclipse 上，另一方面是微软平台上开发的程序的移植。
Eclipse 提供了不同的集成方法，可以是非常轻量级的集成，即只是简单的调用和返回。Eclipse可以处理 ActiveX 控件，这样 Word, Excel 就可以在 Eclipse 里打开，这是另一种集成模式。有些供应商选择把他们的工具封装在 Java 层，即保留 C/C++ 工具，封装在 Java 里与 Eclipse 进行通信。如果软件供应商希望将工具构建成 Eclipse 插件，那么我们通常建议在 Eclipse 中用 Java 重新实现，因为几乎所有的微软工具都是 C/C++ 工具。因此工具的迁移可以分三步走：轻量级集成、重量级集成和重新实现。
如果要迁移程序，Eclipse 提供了一些设施。但难易程度取决于程序是用什么工具开发的，因为最重要的部分是（版本控制系统的）代码库本身，如果代码库同时支持 Visual Studio 和 Eclipse, 那就容易的多。此外有一些公司提供了迁移系统，在 Eclipse 网站的社区部分中可以查看这些公司列表。
developerWorks: 对个体开发人员，他们如何能够参与 Eclipse 项目？
John: Eclipse 是完全开放的，任何人都可以参与，参与的最简单方法是关注它的新闻组，选择一个感兴趣的技术领域，然后下载代码，自己做些实验，并在新闻组上回答一些问题，这样随着技术的提高，就可以向 Bugzilla 提交 bug 和修复包，或去修复其他 bug。如果得到项目工作组的认可，便可以承担项目的一些义务，成为项目开发组的真正成员。此外还可以写一些文章发送到 Eclipse 组织，参加本地的 Eclipse 用户组等等方式。
如果有兴趣成立一个 Eclipse 开源项目，Eclipse 上有一个文档"Eclipse Development Process",描述了如何操作。
developerWorks: 最后请给我们谈谈 Eclipse 下个版本的情况？
John: Eclipse 3.2 计划于今年 6 月面世，名称是 Callisto, 选择 Callisto 作为名称是按社区要求的，因为这次目标是同时发布 10 个主要的 Eclipse 项目，以支持成员公司生态系统需求，他们将要把 Eclipse 框架集成到各自的软件产品中。
developerWorks: 感谢您接受我们的采访。