随着开源文化的日益普及，“参与开源”似乎也变成了一种时尚。一时间，似乎大家都乐于把自己的代码拿出来分享了。就在新年前夕，我的一位老朋友、一位向来对开源嗤之以鼻的J2EE架构师竟然也发布了一个开源的J2EE应用框架（姑且称之为“X框架”），不得不令我赞叹开源文化的影响力之强大。
可惜开源并非免费的午餐，把源码公开就意味着要承受众目睽睽的审阅。仅仅几天之后，国内几位资深的J2EE架构师就得出一个结论：细看之下，X框架不管从哪个角度都只能算一个失败的开源项目。究竟是什么原因让一个良好的愿望最终只能得到一个失败的结果？本文便以X框架为例，点评初涉开源的项目领导者常犯的一些错误，指出投身开源应当遵循的一些原则，为后来的开源爱好者扫清些许障碍。
成熟度
打开X框架在SourceForge的项目站点，我们马上可以看到：在“Development Status”一栏赫然写着“5 ? PRodUCtion/Stable”。也就是说，作者认为X框架已经成熟稳定，可以交付用户使用。那么，现在对其进行评估便不应该有为时过早之嫌。可是，X框架真的已经做好预备了吗？
打开从SourceForge下载的X框架的源码包，笔者不禁大吃一惊：压缩包里真的只有源码??编译、运行整个项目所需的库文件全都不在其中。从作者自己的论坛得知，该项目需要依靠JBoss、JDOM、Castor、Hibernate等诸多开源项目，笔者只好自己动手下载了这些项目，好一番折腾总算是在Eclipse中成功编译了整个项目。
不需要对开源文化有多么深刻的了解，只要曾经用过一些主流的开源产品，你就应该知道：一个开源软件至少应该同时提供源码发布包和二进制发布包，源码包中至少应该有所有必需的依靠库文件（或者把依靠库单独打包发布）、完整的单元测试用例（对于java项目通常是Junit测试套件）、以及执行编译构建的脚本（对于Java项目通常是Ant脚本或者Maven脚本），但这些内容在X框架的发布包中全都不见踪影。用户假如想要使用这个框架，就必须像笔者一样手工下载所有的依靠库，然后手工完成编译和构建，而且构建完成之后也无从知晓其中是否有错误存在（因为没有单元测试）。这样的发布形式，算得上是“Production/Stable”吗？
开源必读：便捷构建
开源软件应该提供最便捷的构建方式，让用户可以只输入一条命令就完成整个项目的编译、构建和测试，并得到可运行的二进制程序。对于Java项目，这通常意味着提供完整的JUnit测试套件和Ant脚本。你的潜在用户可能会在一天之内试用所有类似的开源软件，假如一个软件需要他用半天时间才能完成构建、而且还无从验证正确性、无从着手编写他自己的测试用例，这个软件很可能在第一时间被扔到墙角。
从SourceForge的项目页面可以看到，X框架的授权协议是Apache License V2.0（APL）。然而在它的发布包中，笔者没有看到任何形式的正式授权协议文本。众所周知，SourceForge的项目描述是可以随时修改的（X框架本身的授权协议就曾经是GPL），假如发布包中没有一份正式的授权协议文本，一旦作者修改了SourceForge的项目描述，用户又该到哪里去寻找证据支持自己的合法使用呢？
在X框架的源码中，大部分源文件在开始处加上了APL的授权声明，但有一部分源码很是令人担心。例如UtilCache这个类，开始处没有任何授权声明，而JavaDoc中则这样声明作者信息：
@author <a href="mailto:jonesde@ofbiz.org"David E. Jones</a
也就是说，这个类的源码来自另一个开源项目Ofbiz。值得一提的是，Ofbiz一直是“商业开源”的倡导者，它的授权协议相当严格。凡是使用Ofbiz源码，必须将它的授权协议一并全文复制。像X框架这样复制Ofbiz源码、却删掉了授权协议的行为，实际上已经构成了对Ofbiz的侵权。
另外，作者打包用的压缩格式是RAR，而这个压缩格式对于商业用户是收费的。对于一个希望在商业项目中应用的框架项目来说，选择这样一个压缩格式实在算不得明智。而且笔者在源码包中还看到了好几个.jbx文件，这是JBuilder的项目描述文件。把这些JBuilder专用的文件放在源码包中，又怎能让那些买不起或是不想买JBuilder的用户放心呢？更何况，出于朋友的关心，笔者还不得不担心X框架的作者是否会收到Borland公司的律师信呢。
开源必读：授权先行
在启动一个开源项目时，第一件大事就是要确定自己的授权协议，并在最醒目的地方用最正式的方式向所有人声明??当然，在此之前你必须首先了解各种开源授权协议。譬如说，GPL（linux采用的授权协议）要求在软件之上的扩展和衍生也必须继续GPL，因此这种协议对软件的商业化应用很不友好；相反，APL则答应用户将软件的扩展产物私有化，便于商业应用，却不利于开发者社群的发展。作为一个开源项目的领导者，对于各种授权协议的利弊是不可不知的。
除了源码本身的授权协议之外，软件需要使用的类库、IDE、解压工具等等都需要考虑授权问题。开源绝对不仅仅意味着“免费使用”，开源社群的人们有着更加强烈的版权意识和法律意识。假如你的开源软件会给用户带来潜在的法律麻烦，它离着被抛弃的命运也就不远了。
可以看到，不管从法律的角度还是从发布形式的角度，X框架都远够不上“Production/Stable”的水准??说实在的，以它的成熟度，顶多只能算是一个尚未计划周全的开源项目。虽然作者在自己的网站上大肆宣传，但作为一个潜在的用户，我不得不冷静地说：即便X框架的技术真的能够吸引我，但它远未成熟的项目形态决定了它根本无法在任何有实际意义的项目中运用。要让商业用户对它产生爱好，作者需要做的工作还很多。
我刚才说“即便X框架的技术真的能够吸引我”，这算得上是一个合理的假设吗？下面，就让我们进入这个被作者寄予厚望的框架内部，看看它的技术水平吧。
整体架构
在X框架的宣传页面上，我们看到了这样的宣传词：
X框架解决了以往J2EE开发存在的诸多问题：EJB难用、J2EE层次复杂、DTO太乱、Struts绕人、缓存难做性能低等。X框架是Aop/Ico[注：应为“IoC”，此处疑似笔误]的实现，优异的缓存性能是其优点。
下面是X框架的整体架构图：
可以看到，在作者推荐的架构中，EJB被作为业务逻辑实现的场所，而POJO被用于实现Fa?ade。这是一个好的技术架构吗？笔者曾在一篇Blog中这样评价它[1]：
让我们先回想一下，使用EJB的理由是什么？常见的答案有：可分布的业务对象；声明性的基础设施服务（例如事务治理）。那么，假如在EJB的上面再加上一 层POJO的Fa?ade，显然你不能再使用EJB的基础设施了，因为完整的业务操作（也就是事务边界）将位于POJO Fa?ade的方法这里，所以你必须重新??以声明性的方式??实现事务治理、安全性治理、remoting、缓存等基础设施服务。换句话说，你失去了 session bean的一半好处。另一方面，“可分布的业务对象”也不复存在，因为POJO本身是不能??像EJB那样??分布的，这样你又失去了session bean的另一半好处。
继续回想，使用基于POJO的轻量级架构的理由是什么？常见的答案有：易于测试；便于移植；“开发-发布”周期短。而假如仅仅把POJO作为一层Fa?ade，把业务逻辑放在下面的EJB，那么你仍然无法轻易地测试业务逻辑，移植自然也无从谈起了，并且每次修改EJB之后必须忍受漫长的发布周期。 即便是仅仅把EJB作为O/R mapping，而不是业务逻辑的居所，你最多只能通过DAO封装获得比较好的业务可测性，但“修改-发布”的周期仍然很长，因为仍然有entity bean存在。也就是说，即使是往最好的方面来说，这个架构至少损失了轻量级架构的一半优点。
作为一个总结，X框架即便是在使用得最恰当的情况下，它仍然不具备轻量级架构的全部优点，至少会对小步前进的灵敏开发造成损害（因为EJB的存在），并且没有Spring框架已经实现的基础设施（例如事务治理、remoting 等），必须重新发明这些轮子；另一方面，它也不具备EJB的任何优点，EJB的声明性基础设施、可分布业务对象等能力它全都不能利用。因此，可以简单地总结说，X框架是一个这样的架构：它结合了EJB和轻量级架构两者各自的短处，却抛弃了两者各自的优点。
在不得不使用EJB的时候，一种常见的架构模式是：用session bean作为Fa?ade，用POJO实现可移植、可测试的业务逻辑。这种模式可以结合EJB和POJO两者的优点。而X框架推荐的架构模式，虽然乍看起来也是依葫芦画瓢，效果却恰恰相反，正可谓是“取其糟粕、去其精华”。
开源必读：架构必须正确
在开源软件的初始阶段，功能可以不完善，代码可以不漂亮，但架构思路必须是正确的。即使你没有完美的实现，参与开源的其他人可以帮助你；但假如架构思路有严重失误，谁都帮不了你。从近两年容器项目的更迭就可以看出端倪：PicoContainer本身只有20个类、数百行代码，但它有清楚而优雅的架构，因此有很多人为它贡献外围的功能；Avalon容器尽管提供了完备的功能，但架构的落伍迫使Apache基金会只能将其全盘废弃。
所以假如你有志于启动一个开源项目（尤其是框架性的项目），务必先把架构思路拿出来给整个社群讨论。只要大家都认可你的架构，你就有机会得到很多的帮助；反之，恐怕你就只能得到无尽的嘲讽了。
技术细节
既然整体架构已经无甚可取之处，那么X框架的实现是否又像它所宣称的那样，能够解决诸多问题呢？既然X框架号称是“AOP/IoC的实现”，我们就选中这两项技术，看看它们在X框架中的实现和应用情况。
IoC
X框架宣称自己是一个
