主题：【原创】开源的Eclipse（一） Eclipse的历史 -- 可爱的中国

如果我要写Netbeans，第一是因为我喜欢他，第二是我要能讲清楚。。。最少要能比那些tutorial讲的清楚，给大家写个example我才好意思放上来。。。

你写我就花和宝推

如果河里有人在2003年前使用Java IDE 开发，大概就会知道当时的IDE是多么的难用。

以JBuilder 为代表的基于Swing 的IDE 是如此之吃内存，运行的是如此之慢，是如此的频繁崩溃。似乎有那么一些非主流的IDE 据说不错，不过我没有用过，也不打算用。自从尝试过 JBuilder 以后，我就决定使用停留在使用文本编辑器开发的方式。

所以，当2003年第一次有人给我演示Eclipse2.1 的时候，我的第一个念头是，这个是C／C++写的吧？ 否则不可能这么快，而且界面和Swing 绝无相似之处。

俗话说，好的开始是成功的一半。 Eclipse 2.0 于2002 年发布，可以说是开始了Eclipse 的辉煌。 当时Eclipse 还主要是一个IDE，但是它提供了可以和C／C++ 的性能和稳定性媲美的性能 一下就抓住了大批Java开发人员的目光。

其实SWT 并没有什么特别的地方，从本质上和AWT是一致的，都是对都是通过JNI和对系统的图形组件的封装。 但是显然，SWT 的实现比AWT 更好，更可靠。

而Sun AWT／SWing 由于缺乏竞争或者其他原因，一直没有在性能和稳定性方面有很大的提升。这就给了Eclipse 机会一举占领了Java IDE的市场，我大概记得2005年当时的一个统计Eclipse JavaIDE的占有率超过70％ （不确定，但是超过50％是肯定的）。

有了庞大的用户群以后，并利用Eclipse 优秀的可扩展的插件机制，IBM 就开始推销Eclipse 作为桌面应用的平台，并在2004 年通过Eclipse 基金会建立了多个和IDE 无关的Eclipse 项目，包括IBM早以开始的图形编辑器框架GEF，自动模型项目EMF，和随后加入的数据工具项目DTP， 智能报表项目BIRT，内置的SVN支持，网络开发工具WTP， 嵌入开发项目DSDP 等等。

在2005 年3.1 版本发布后， Eclipse 完成了底层对OSGi的整合工作， 从一个IDE 正式演变成为一个全面的桌面系统开发平台，它的项目已经几乎覆盖了大多数的开发领域。 建模可以使用UML2 和EMF， 商业应用有DTP 和BIRT，嵌入开发有DSDP， 测试和优化调试工具有TPTP， 对语言的支持则覆盖了从C／C++， AJax/JavaScript, PHP, Cobol, Ruby 等几乎所有的常用语言。

这个时候，实际上Eclipse 已经不再拥有，或者说它也不再只关注于它起家的优势，速度和稳定。 但是由于大量的商业公司的加入，Eclipse 作为一个统一的开发平台的价值已经远远超越了它作为一个优秀的IDE 价值。 而这个时候，Sun 的第一个有实际竞争力的NebBean IDE 版本还在路上，尚未发布。

当Sun 在2006年开始大规模宣传Netbean 比Eclipse 更快，更稳定的时候，已经有大量的商业公司使用Eclipse 作为公司的基础铲平平台推出了商业产品，比如WindRiver, BEA, Actuate, Sybase, IBM 等等。这个时候，这些商用公司已经被绑在IBM的Eclipse 战车上，不可能脱身了。

Eclipse 对自己的定义已经修改成：

Eclipse 是一个开源社区，它关注于提供可扩展的开发平台，运行和应用框架。用户可以把Eclipse应用到整个软件开发生命周期，来构建，发布和管理软件的开发。很多人因为Eclipse 是一个IDE而知道我们，但是Eclipse 可以提供的远远多于Java IDE。

根据2006 年数据 （现在更多）“到现在为止Eclipse已经有了12个战略开发会员，每一个承诺至少提供8个全职开发人员和至少每年25万美元的投资给Eclipse基金会。 Eclipse基金会有四个战略用户也提供经济上的支持。有69个公司作为插件提供者，另外还有13个合作会员公司。如果你仔细的研究软件业，你会发现成百上千的Eclipse的商用插件和产品。Eclipse现在是业内主要的非微软软件工具平台。” ［1］。

更为关键的是，Eclipse 项目除了基础平台外，大多不是由IBM主导的，而是由其他像Actuate, WindRiver, Sybase这样的商业公司在主导，这无疑提高了参与公司的积极性和忠诚度，实际上这些公司主导的项目无一例外都成为他们推出的商业产品的基础。

而目前其主要竞争者Netbean 仍然是一个以Sun 独家开发为主的IDE 工具。 也许现在的Netbean 比 Eclipse 更快，更稳定，更好，可是Sun 又一次失却了大好的商业机会。 你无法想象那些已经在Eclipse 上投入大量资源的公司现在会应为Netbean 的改善而转移他们的平台。尽管事实上有大量的开发人员又回流到Netbean， 可惜这些人员大多是单纯的IDE用户，他们无法给Sun 带来实际的商业利润。

比较Netbean 和 Eclipse 的历史，它们几乎同时与2001年起步， 如果Sun及时的改善它的AWT/Swing的性能, 如果Sun及早的开发Netbean开发社区，而不是紧抓着不放，如果Sun 在2006 年同意与 Eclipse 合并，那么Sun还会沦落到被Oracle 收购的地步么？ 没有人知道答案，软件开发领域永远都上演这一幕幕同样的剧目，拥有好的技术的公司如果没有合适的商业策略很难活到最后。 不知道Sun在卖给Oracle 以后，能不能从新崛起，希望Sun还能回来，毕竟有竞争的市场是技术进步的催化剂。

感谢 yueyu 提出了Netbean 和 Eclipse 的比较，否则我的确没有仔细的研究过为什么Netbean 没有能够和Eclipse 展开足够的竞争。 也欢迎yueyu能够写一个NetBean 系列，毕竟我对Netbean 的了解不够深刻。

［1］ http://tech.it168.com/j/n/2006-12-15/200612150934050.shtml

喝水，顺便考虑一下是否继续。

哈哈

河里以前有篇文章，很精彩的，可以找找。

大意是这样的：SWT与AWT/Swing之争，源头在Smalltalk时代图形界面的开发，那时有三家公司，分成两帮人马。

美女（是真正的美女，SUN网站上有图）一帮进了sun，先废了已经存在的AWT，重新搞了Swing，他们的哲学是一支画笔绘天下，只从底层操作系统要来Graphic对象，至于按扭、下拉等全是自己画，这样达到跨平台的目的。这是轻量级实现。

另一帮进了IBM，搞了SWT，其实AWT也是这一路的。SWT的哲学是求出各操作系统平台的图形界面的公约数（AWT也是这么干的），但如果求不出公约数，就自己给它补一个（这是AWT没作到的，也是SWT比AWT强的地方）。这是重量级实现。

结果就是基于SWT的ECLIPSE，具有本地操作系统的外观，即在windows是windows的样子，在Linux下是Linux的样子。而不是SWING界面在哪个操作系统都怪怪的样子、一嘴的外地口音。而且速度快，还有金山词霸能取词（因为它是用本地API生成的）。

这两种哲学，各有各的道理，无须捧谁灭谁。这就是JAVA世界精彩所在。而且这是微软独大的C#世界里永远不会出现的。

谢谢反馈。我写的目的不在于讨论技术优劣，

AWT/Swing 和 SWT 本身就不单纯是技术路线的优劣，事实上Sun 已经证明在有竞争压力的情况下，它可以把Swing改的足够快，赶上SWT。

真正的问题是， Netbean在商业推广上落后与Eclipse的事实是什么造成的，是个很有意思的问题。

广泛么。感觉Python方面用这个写程序的不多啊，不知道是Python可用还是.Net平台上面的IronPython专用。

抓紧写吧，我们现在的主力IDE就是netbeans，等着看好文呢。先上花！

Eclipse社区是一个由主要的软件供应商，解决方案提供商，企业，教育和研究机构以及个人共同创建的一个生态系统。 因此Eclipse社区有别于一些其他的开源项目，它的初始目的就是建立一个可以盈利的生态系统。

这种开源的模式使的开源项目不再是一种单纯的免费的项目，而是可以提供给用户一种更好的创新模式，和盈利的商业模式。

参与Eclipse 的商业组织或者个人的商业模式大概包括

1)服务器端平台提供商

这些公司的核心产品是服务器平台。 比如操作系统， J2EE服务器，报表数据处理器。 对这些公司来说，他们的参与Eclipse的主要兴趣在于

首先，利用Eclipse 框架开发成服务器平台的开发工具。 比如J2EE 开发工具，报表开发工具，等等。

其次，吸引其他的小软件公司开发针对他们服务器端产品的第三方工具。

比较典型的公式包括BEA, IBM, Wind River, QNX,Actuate等等。

2)桌面应用平台提供商

和第一类厂商类似，该类型的厂商一般提供某些桌面的应用或者开发框架，或者工具。 但是这些厂商的括框架需要一个好的图形工具来吸引用户。

比如 Sonatype 主导的 Maven Integration 项目就是一个典型。 Sonatype 通过将Maven 和Eclipse 整合来吸引大量的Java 开发人员使用Maven 作为编译和发布工具。就像M2E 项目说的那样 “Maven helps Eclipse build, and Eclipse helps people use Maven. ”

其他类似的还包括SAP 主导的Memory Analyzer项目等。

目前大多数Eclipse的项目由上述两类组织在主导运行，上述两类成员可以说是Eclipse社区的核心成员。

这些公司的主要盈利产品是他们的服务器端平台，或者是客户端应用框架，而不是客户端图形开发工具。 但是，向用户提供一个便利的开发工具，对于这些公司来说也是必须的。与其写一个闭源的，极少用户的，不太开能盈利的自有开发工具，还不如投靠Eclipse。

通过参与Eclipse，既可以减少自有开发的成本，又可以在Eclipse 庞大的用户群众起到宣传作用。 这些公司往往在项目开发上比较积极，倾向与提供一个优秀的，简单易用的图形开发工具。只要这个图形开发工具的功能不会影响到他们的后端产品的出售，他们就不介意向客户提供这些功能。

3)第三方插件提供商

这类厂商往往自己推出基于Eclipse扩展的开发工具。 由于他们依赖于Eclipse 的某些项目。为了更好的参与，影响这些项目的开发朝对自己有利的一面发展，这些厂商往往会积极的加入到这些项目中去，作为积极的开发者来使自己的产品能够更好的利用Eclipse的功能。

比如 Genuitec就是一个典型。 它的产品MyEclipse 可以说是目前最好的Java IDE 之一。同时Genuitec 作为Eclipse的“Strategic Developer Member” 积极参与到多个Eclipse 项目中。

其他例子包括 Instantiations，Apatana等。

这些公司往往和Eclipse 在某种程度上是竞争的，应此他们不会在Eclipse的项目中向客户提供一些高级功能。他们的重点在于使得项目的基础平台更模块化，更容易扩展和客户化，这样他们才能在此基础上扩展和开发自己的产品。

比如Zend 主导的PDT就因为不提供很多相对比较复杂的 IDE 的功能而为人诟病。

这些厂商也是Eclipse的主要用户，他们往往会在自己的产品中集成Eclipse的其他项目。比如Zend 就集成了BIRT 项目作为它的报表模块。

这些厂商也往往是报告Bug和修改Bug的积极分子，因为很多 Bug 很可能来自于他们在开发自由产品的过程，并影响他们的产品的进度。

4)服务和支持厂商

这些公司提供针对Eclipse 开发的服务。 包括外包服务，Eclipse 开发培训和认证等等。

比较典型的包括AvantSoft, Espirity 等。

这类公司加入Eclipse的目的是为了深入了解Eclipse的内部机制，同时有可以获得Eclipse Memember 这个金子招牌来吸引外包和需要培训的客户。相对而言，这些厂商往往不是项目的主导者，而是以参与为主。

5)独立的Eclipse 顾问

很多个人开发者也积极的参与Eclipse项目的开发。 他们利用这样的身份来帮助他们作为Eclipse 开发顾问而获得收益。

总的来说，Eclipse的基本商业模式就是通过提供Eclipse 这么一个优秀的，而又是免费的平台来大量吸引开发人员和用户。在拥有庞大的用户群的基础上，Eclipse 的参与者通过提供个性化的服务和产品来盈利。

关于Eclipse 的历史和商业模式的系列差不多结束了，欢迎大家拍砖。

也许考虑另写一个关于Eclipse 技术框架的系列，看时间吧。

怎么没有他的身影

如果没记错的话:)

所以抱歉，我是比较不了了，据说不错。不过IDE的好坏也是见仁见智的事情。 也有不少说NetBeans 好的。

整体来说Eclipse已经不靠IDE吸引人了。 一般如果使用Eclipse的项目作为技术框架，那么必然选择Eclipse作为IDE。

Erich Gamma现在还是JDT的成员。

"Erich is still active in JDT space, helping improving the UI, suggesting enhancements, challenging us in interesting ways. Though he is not contributing code changes right now..."

不过要说erich是总设计师也成，因为3.0 前Eclipse主要也就是JDT， plug-in 的基本结构应该也是和这位老大有关。

这个系列主要不是讲技术的，就没有他的分了，以后有时间再写个技术系列。

不过之前Eclipse的核心代码的确是漂亮，绝对是OO的典范，现在什么公司都加进来，差多了。