A: The difference is that Linux is not really structured commercially, meaning Linus Torvalds is off doing something else. And there is Red Hat as a third-party packager. Whereas we are very much for profit. There is a lot of services in middleware, as compared to Linux, where you do not have so much that you do and consult around. Middleware is very consulting-intensive. We have a profitable consulting operation that has all the developers in it. The company grows from inside the group, which is a different model. We're highly structured and commercially focused. We just use open source as R&D and recruitment if you will. How can a group of open-source developers stay ahead of commercial companies?
Make no mistakes: we're commercial, meaning I put food on the table for all my developers. It's a good question that you're posing, though, which is can open source sustain itself? By and large, if you don't make money, no, you're not going to sustain it. I'm very focused on making a profit to make sure my developers can pay their bills. That's our model. In terms of whether we innovate, the Middleware 2003 conference had papers submitted from academics all over the world for the most exclusive conference related to middleware. And of the papers accepted, we made it to the top ten and they're inviting us to the keynote. To me, that's very significant. JBoss has a relatively small number of developers, though, doesn't it?
The size of the real developer community is not 1,000 people overnight, because we're open source, but have 30 guys who are making a living at JBoss. From a pure development standpoint, it's a fairly big group. I don't need to get bigger from a development standpoint. What about compliance with the J2EE standard? Is there a danger of going off the path and splintering the specification?
There are two aspects to the Sun specification. One is the brand and one is the compliance. The brand is Sun and is owned by Sun and licensed by Sun. So Sun controls it. The bottom line there is that Sun doesn't really want to acknowledge that a compliant app server is free. Because then which one are you going to choose if both are compliant? You're going to choose the free one. The other part is adherence to the standard. We participate as JBoss Group, our developers work on expert committees at (the Sun-backed Java Community Process). Expert committees write the app server specification. So JBoss actually puts a lot of what we do in our app server back into the committees. It's a model that works. (Editor's note: Since this interview, Sun has extended an offer for JBoss to license J2EE compliance testing suites.) So you're committed to be compliant to the base specification, but you're adding your own features above and beyond?
Yes, we call it beyond J2EE... We are putting these features forward without waiting for the specification. As the specification moves forward, we'll standardise but that takes time. Is that certification of compliance important before customers are going to buy off on a JBoss to make sure they can port the application?
Oh, it definitely is. We're not saying we're going to break compliance. In fact, we're known in the market as one the most compliant servers. BEA is fast at bringing out new features, and we're usually second in line. IBM usually trails our own release in terms of spec adherence. So we believe strongly in one unified application server market and yes, we know for some people it's really important to have that brand of certification. You've said that one of your challenges is to go from developer popularity to widespread production usage. How do you want to do that?
We're going to stick with what's a winning formula for us, which is a bottom-up approach...meaning we have almost cult status with the developers. And even if they don't know us, they just try the server and it just works. So the developers keep pushing that and that's a very strong base. I think right now open source, in general, suffers from a perception problem. What we need to do is for the decision makers higher up to be more comfortable with an open-source approach. I think right now open source, in general, suffers from a perception problem. The perception is that open source is not supported. So our strategy is first of all to execute on our services. And we're good at services. We know our server. We are experts on our server. We wrote it. So we can do that service with good quality. And just communicate clearly that one of best services for app servers comes from the open-source community. Do you think price is the primary reason for using JBoss?
Definitely price is a big factor -- particularly these days. But if you talk to Corporate Express, which is a $5bn company, cost was No. 5 on the list. Usually, you will see uptime -- rock solid stability -- as the No. 1 criteria. So in some instances, stability is a big factor and open source is usually good at stabilising the code base. What about the argument that services and support cost is more important for software licences? Is that a challenge because someone might just go with IBM reasoning that the overall cost will be lower?
No, that is one of our advantages. But we are fighting against perception, so give it time. Our strength is actually the service. We are experts on our stuff, so we work very well in second line, third line support capacity. What that means for a large IT corporation -- in fact I was at WorldCom recently, and they said what tipped the decision was the support. They were worried about support and thought that there is no support. And I agree with you that's the perception, therefore that's the reality. But in fact, they tried it. They were blown away because they are not used to talking directly to the source. For them it was a brand new thing. Why did you start JBoss in the first place?
The reason I started it really is back in '99 the explosion was Linux. Linux didn't make a lot of sense on the client side because Windows is so entrenched and is a great PC operating system. But it made a lot of sense on the server side. I really said I want to do the open source for the server side. That's where the most of the commercial success of open source is today. You said you like Microsoft's .Net approach. What are you trying to emulate?
What I like about them and really try to emulate -- and that's a departure from the J2EE vision -- we want to bring the services of transaction, security, persistence, etc., in an orthogonal fashion to objects. What that really means is for a developer to leverage these operating system services, instead of having to learn J2EE, they just write simple Java objects, like in .Net. Just a straight object they already know how to write. And they give an XML file that says, "System, provide this service for my object." It's a much simpler way to program, and a much more intuitive way to program because it is true that J2EE has gotten bloated. So it's a question of creating better tools?
No, no, no, that's the point. BEA, for example, is trying to solve the usability with the tools. Like Microsoft, we realised that it's a fundamental framework construct... Instead of learning additional APIs and interfaces that make you reprogram applications, you want to take existing applications and just configure the server to work with existing objects. It's a simple technical point.
ZDNet UK's Developer News Section delivers the latest headlines together with the best UK jobs, right to your browser.
Let the editors know what you think in the Mailroom.
