四年后，他显然已经小有成就。Fluery与同事一起开发出来的JBoss软件吸引了许多Java开发人员的注意。

Fleury目前则希望借着他所成立的JBoss Group进军企业领域。他不仅希望工程师用JBoss来撰写应用，更希望企业也能在JBoss服务器上执行生产系统，替JBoss Group带进服务营收。

不过多数CIO 在现阶段尚未考虑采用JBoss，毕竟JBoss Group还只是一家小公司，只有100名开发人员在维护程序代码，公司雇用的全职开发人员也只有30名。不过来自巴黎的Fleury充满信心，他预言JBoss取代商用Java服务器软件的速度将比Linux席卷操作系统市场的速度来得快。

JBoss与Linux开放源代码所采取的手法有何不同？

两者最大的差别在于Linux并不真正具备商业结构，Linus Torvalds本身还有其它正职，Red Hat也只是第三方包装厂商。我们则是一开始便以获利为目标，跟Linux相比，我们在中间件上可提供许多服务。

中间件会有许多顾问需求产生，我们的顾问团队有完整的开发人员，业务相当赚钱，我们拥有自己的团队，公司也不断由此壮大，这是相当不同的模式。我们的架构完全走商业路线，只是研发与人才招聘都会以开放源代码为基础。

一群由开放源代码开发人员组成的团队怎么跟真正商业化的企业做竞争？

我们本身就是一个商业化的团队，不过你也问到一个重点：开放源代码是否能养活自己？一般来说，没赚钱就养不活自己，我非常重视我们的公司必须获利，让开发人员都能自给自足，这是我们的模式。

不过JBoss的开发人员规模还相当小？

开发社区不会一夜之间就暴增到1000人，因为我们是采用开放源代码，JBoss目前有30名正职开发人员，以纯开发角度而言，这算相当庞大了，就开发角度而言，我们并不需要再继续扩充。

跟J2EE标准的兼容性问题呢？你们的作法是否会导至规格的分裂？

SUN 的规格可从两方面来看。一是品牌，一是兼容性。品牌方面是由SUN 所有，并负责授权，因此SUN 可大权独揽。但问题是SUN 不愿承认兼容应用服务器也可以是免费的。因为这么一来，若有两种产品都合乎规格，你要怎么选？大家当然都选免费的了。

另一个问题是是否遵循标准。JBoss Group有加入SUN 支持的JCP小组(Java Community Process)，我们的开发人员也兼任JCP专家委员会成员。 因此我们也将许多应用服务器方面的记数回馈给委员会，这种模式是可行的。(编按：SUN 最近已同意授权JBoss使用J2EE兼容测试软件。)

所以你一方面会遵循基本规格，但另一方面又希望自行增加其它功能？

是的，我们称之为“J2EE以外的部分”。我们会自行推出规格之外的功能，若以后规格有做统一规定后，我们在来进行标准化，但这需要一点时间。

客户是否会等到你们取得兼容认证后才购买JBoss产品呢？因为这样才有办法作应用程序的转移。

是的，我们并无意破坏兼容性。我们的产品可算是业界中最守规矩的了。像BEA自行推出的功能就很多，我们顶多是老二而已。IBM在规格上甚至比我们还不遵守规定。因此我们非常支持统一的应用服务器市场，我们也相信部分客户会希望看到认证品牌。

你觉得价格是JBoss最客户决定采用的大优势吗？

在目前的环境下，价格绝对是一大因素。但若你去问一些大企业，成本通常并非最大考虑，这些客户通常是以稳定性及已运作时间(uptime)为第一考虑。因此部分情况，稳定性是一大因素，而开放源代码的稳定性通常很好。

市场的看法是服务与支持成本会比软件授权来得重要，比如有些客户可能想直接选择IBM，因为整体成本可能比较低，你觉得这会是一大挑战吗？

不，这正是我们的优势之一。但我们得扭转外界的观感，所以还要一点时间，我们的长处就在于我们的服务，因此本身就是专家，因此再提供二级或三级服务的能力很强。比如我们最近去了WorldCom，他们也是很担心支持问题，但他们试过以后非常满意，因为他们还不习惯直接跟源头做沟通，因此可说是全新的经验。

当初怎么会想创立JBoss？

这可回溯到1999年Linux刚好窜红的时候。Linux在客户端市场其实意义不大，因为泰半市场都给Windows拿下了，且也是个非常好用的PC操作系统。但Linux在伺服端却有莫大优势，当时我便决定要在伺服端作点开放源代码的事情，目前许多开放源代码在商业市场上的成功也都来自于此。

你说过你喜欢微软.Net的作法，你会怎么仿效呢？

我最喜欢也觉得最值得师法之处在于将交易、安全等服务透过一种正交(orthogonal)模式带给对象。意思是，开发人员可直接利用这些操作系统服务直不需要学习J2EE，他们只需要撰写简单的Java对象即可，就像.Net一样。这点是跟J2EE看法最大差异之处。开发人员已经知道怎么写对象，他们只需再下一个XML文件来作命令，比方说，“系统，提供这对象某某服务。”这样写程序会简单许多，也比较直觉，因为老实说，J2EE是有点太过大而无当了。

因此问题在于创造更好的工具吗？

不，这不是重点，比方说，BEA目前就为了改善工具亲和性而大伤脑筋。以微软来说，我们知道那是一种基础架构的构造，你不需要重新学习额外的API或界面，自己还得重新编写应用。你只需要调整服务器，让它能跟既有的对象兼容，如此就可把旧应用移植过来。这是很简单的技术观点。