2004年2月，IBM向Sun递送了一份公开信，建议Sun开放Java技术源代码，这一事件预示着计算机行业可能揭开一个新的篇章。对于Java技术的创始者Sun来说，这份公开信的含义不亚于一个“特洛伊木马”。
这封公开信是由IBM负责新兴技术的副总裁Rod Smith向Sun的总工程师Rob Gingell递交的。
从表面看，Smith好像是在要求Gingell兑现Sun一直在鼓吹的公开源代码的承诺。这封信引用了Sun的首席技术专家Simon Phipps在最近的一次Eclipse拥护者集会中的话："为什么IBM不向公开源代码社团提供它的Java实现？"在公开信里，Smith反复强调Phipps的观点，他说："Simon的建议将推动我们一起努力实现这一共同目标。"但我确信这不是他建议的主旨，尽管没有亲耳听到这句话，但我还是怀疑这和Phipps在给Smith信中提到的问题所说的并不是一回事。到目前为止，Sun还没有对这一建议表态。
让我们暂时忘记Gingell在Sun公司的地位（他负责全面的技术体系结构和Sun产品线的发展方向），像这样的商业决策不可能由Gingell一个人完成。这封信显露了IBM向Java领域扩张的野心，如果Sun不这么做，就会被Java和开放源代码社团所抵触。
这封公开信里能证明IBM毫无合作诚意的地方，是它包含了Gingell的电子邮件地址。这样的失礼发生在不熟悉电子邮件的网络新手身上并不奇怪的，但发生在堂堂IBM公司的Smith身上就有点说不过去了。毫无疑问，Gingell的电子邮箱已经淹没在质问的狂潮里了。作为IBM对Sun公司近4年追击的延续，这实在是IBM的一步妙棋。
Gingell和Sun的沉默（正如IBM所预期的那样）正中IBM的下怀。各种各样反对Sun的言论开始出现。一部分人表示，Sun正在阻碍Java真正意义上的开放化。Rick Ross是一名Java开发者，他说Sun仅占有Java行业的5%的业务，然而它却控制了平台定位权，这对促进Java的发展没有任何帮助。
Sun除了成为罪人，几乎没有其他选择。而我认为幕后真正的策划者却是IBM。
自2000年5月以来（当时IBM在名为openserver.org组织的支持下，在Sun一年一度的JavaOne大会前组织了一场轰轰烈烈的Java许可证运动），蓝色巨人已曾无情地阻击Java的自由。
对于IBM来说，Java在它的WebSphere产品线上扮演着至关重要的角色，这个产品的目标是在任何时间任何地点提供实时数据，并能减少成本和多系统集成的复杂性。粘合所有分散的组件能够为领先的提供商带来可观的利润，对于IBM来说Java就是胶水。
对于微软来说，.net就是胶水。由于IBM和微软在Web服务领域的协同工作是Sun不乐意看到的，这两种不同类型胶水的相同发展道路让它们的相互替代成为可能。微软正在试图用基于.Net的系统排挤IBM，IBM也不能让另一家公司掌握自己的命运。我们知道IBM上一次和微软的OS/2之争，让自己陷入不稳定的局面，而那次重伤几乎毁掉了整个公司。
在openserver.org几近瓦解之后（Oracle在最后时间退出），IBM使用了各种武器，试图和在Java上和Sun分庭抗争。迄今为止，其最成功的举动是适时的推出了Eclipse。IBM将Java的集成开发环境（IDE）开放源代码，这让Sun愤怒。大批当时支持IDE NetBeans的第三方工具制造商转而支持IBM阵营。这一行动为IBM避免了Java许可冲突，成功笼络Java社团打下了坚实的基础。
除了Eclipse以外，蓝色巨人还与BEA一起借助Java的应用服务器（J2EE）的扩展对Sun展开了又一次沉重的打击。在JCP发布3个J2EE扩展集后，IBM和BEA在基于市场将展开J2EE方面的合作。在扩展集被移交给JCP做最后的合并之后，Sun的软件技术副总裁将这次运动形容为，这是与Sun提供的免费基于J2EE应用服务器的殊死搏斗。
在我看来，这封IBM给Sun的公开信的目的昭然若揭：如果Sun不想让IBM在Java上分一杯羹，那么IBM就会想尽一切手段给它造成麻烦。Smith的信狡猾地暗示Sun，只有一条解决分歧的路，就是将Java的许可权让出。
IBM公开Java源代码的要求让很多人十分困惑。IBM最近几年一直抱怨：IBM必须为Java付费，而即使付费也没有任何保证。Sun已经控制了Java规范的一票否决权（JSR，全称是Java Specification Requests），这对IBM来说是最大的威胁与麻烦。
不过，IBM的抱怨似乎有点不太站得住脚。毕竟，2003年是IBM自己将J2EE市场份额老大的位置拱手让给了BEA。而头上挂着世界头号知识产权大户的称号，IBM也没有理由对向其他公司付费产生异议。
直到否决权被开始关注，还没有一个JCP成员自告奋勇地向Sun否决权以身试法。也就是说，还有许多Java的新概念没有公诸于世，因为Sun统治的世界并不允许它们被公布。
在2002年对Sun的Gingell进行的采访中，能隐约地察觉到IBM病痛的根源。当谈到开放Java源代码的时候，Gingell说："我们实际上已经开始开放源代码了，JVM许可和开放源代码惟一的区别就是我们假定的兼容，开放源代码并不需要兼容许可假定，而兼容性正是Java社团担心的。因此如果你准备使用我们的产品，你就不得不重视兼容性。除此以外，它和开放源代码许可的区别是：开放源代码狂热者不喜欢Sun社团源代码许可的原因是它需要你重视兼容性，当他们要求去掉这一部分的时候，我们惟一能做的就是对他们说不。"
为了理解兼容性斗争的缘由，以及谁是斗争的仲裁者，让我们看看Linux社团里发生的事情吧。正如Gingell所说，由于Linux的不同分类，在开放源代码世界里，已经没有任何兼容性需求了。尽管Linux内核是单一的，但是在不同类别的Linux下还是有许多不可调和的地方，也就是说它们不仅是不兼容的，而且互相替代基本是不可能的。
我在LinuxWorld 对来自西部银行的巨人Northern Trust的两位IT高级主管进行访问的时候，了解到这家公司已经在Red Hat Linux投入太深，无法回头，即使其他提供商例如Novell（SuSE）能提供更好的安全网（Red Hat则没有提供）。Northern Trust的境遇证明了至少在美国，Linux兼容性并没有被公开源代码社团定义，而是被拥有高市场占有率的厂商提供。这一境遇令其他部署难以完成，而更重要的是，会给需要更自由选择的客户造成阻碍。
兼容性正是IBM期望看到Java源代码公开化的原因，但是Sun到目前为止还拒绝做出回应。作为Sun社团源代码的受许可方，IBM除了有责任让WebSphere兼容其他的J2EE执行以外，还需要警告程序员。
如果因为开放Java源代码就意味着Sun放弃了兼容性仲裁者的控制权，那么就等于为IBM的WebSphere敞开大门，让它成为J2EE世界里的Red Hat Linux，广泛承认的J2EE事实标准。和Red Hat一样，WebSphere将因此确立市场统治地位，无论它的竞争对手提出何种新概念。对IBM更重要的是，它能立即对.Net世界做出反应而几乎没有冲突，因为用不着考虑兼容性。
当包括IBM的所有受许可方必须遵照的正式标准出现后，没有一家单独的厂商能锁住J2EE大门，也不能建立包含私有技术的事实标准（这种私有技术事实标准不能被竞争对手免费利用，正如Linux市场一样）。
尽管这场"标准效应"是IBM自己领导的，但本身却给蓝色巨人带来不少威胁，特别是像JBOSS和Sun自己的Application Server 8.0这样的免费版J2EE应用服务器充斥着市场，IBM面对着新的挑战。
你可以着眼于JBOSS来理解Simon Phipps最初向Eclipse支持者发问的真实语境。正如大多数Java关注者知道的那样，JBOSS是J2EE的一个开放源代码实现。尽管它可能是微妙的，但像J2EE这样的Java规范的开放和移交这些规格的开发是两回事，这点开放源代码社团必须认清。仔细推敲Phipps的问题，不难发现他正在向IBM提出挑战，让IBM将WebSphere背后的源代码向开源代码社团公开。基于JBOSS的先例，IBM绝不会让这样的事情发生。
自2002年起，Sun已经开始逐步地为JSR的开放源代码实现铺平道路。在2002年8月，Sun利用Apache Software Foundation打破了开放源代码的僵局，此后，Sun就一直在向开放源代码社团妥协。在Gingell看来，开放Java规范的源代码并不是像打开开关，然后魔法般的宣布Java现在正式公开源代码了这么简单的。因为大多数现有的Java规范包含其他厂商的贡献，JCP先前的知识产权政策不允许公开源代码，所以Sun并没有权利将所有的Java规范公开源代码，他们只有权利公开Solaris的源代码。在2002年的采访中，Gingell就表达过这种想法，他说："Java的发展进程和一套有效阻止任何人使用开放源代码的条款是分不开的，但是这并不是我们的意图。JCP存在的作用是决定谁有资格让其成为现实。开放所有的源代码，开放一部分源代码或是根本不开放源代码，只要Java社团不拒绝，他们可以做任何决定。我们最近做出的改变是让这些选项中的一个开放源代码化。"这一改变为现有的规范开放源代码铺平了道路。
Sun兑现这一承诺的迹象出现在11月，J2EE JSR 1.4版被JCP认可之后，Apache Software Foundation和JBOSS Group得到信号，不仅仅是提供Geronimo和JBOSS 的J2EE 1.4表示，还要寻找兼容性证明。既然箭已离弦，无论IBM是否愿意公开WebSphere源代码，Sun都根本没办法防止。
我怀疑Smith对Phipps在Eclipse拥护者集会中言论的反应另有目的原因是：Smith知道没人会将"向开放源代码社团移交Java规范"和"允许开放源代码社团实施这些Java规范"之间的微妙区别联系起来，因此他小心的在信中引用了Phipps的言论，使得读到这封信的媒体误认为："为什么IBM不向公开源代码社团提供它的Java实现？"尽管Smith试图揭露伪善的Sun，但同时他也揭露了一个伪善的IBM。
最后有一点值得怀疑，IBM和Smith的野心是众所周知的。如果这封信真是橄榄枝，完全可以用电话来完成，而媒体是绝对不会知道的。
在接下来的几年中我们可能看到JCP发生的一系列变化。但是，我还是非常怀疑他们其中的人会因Sun的兼容性和可移植性的承诺欢欣鼓舞。它不仅仅保护了其他Java许可获得者，还保护了你。
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
休息区 → 『 最新动态 & 业界新闻 』 → 开放Java源代码意味着什么
(订阅本版)
2004/5/8 11:44:00
新浪微博
开放Java源代码意味着什么
