Open Source -versus- Commercial J2EE Containers

by Kevin Bedell

It was only a question. I didn't expect a fight to break out.

But at the Thursday afternoon keynote on 'The Future of Java' at SYS-CON's Web Services Edge 2003 East Conference in Boston, that's almost what happened.

The keynote was a panel discussion with some of the best people in the world when it comes to understanding the future of Enterprise Java. On the panel were:

Simon Phipps

Chief Technology Evangelist - Sun Microsystems

Marc Fleury, Ph.D.

founder and president of JBoss Group

Dave Chappell

VP, Chief Technology Evangelist - Sonic Software

Dr. Jeff Capone

CTO - Aligo

Tyler Jewell

Director, Technical Evangelism - BEA

After about 30 minutes of general discussion the floor opened to questions. I figured this would be a great chance to get some insight as to why companies should adopt either Open Source or commercially-developed J2EE application servers. So I raised my hand and asked:

"Can you as a panel compare the difference in the value propositions of open source and commercially-developed J2EE application servers?"

At first there was just silence as they looked at each other. Then Marc Fluery said, "I wouldn't touch that question with a ten-foot pole!" - though true to his style, he immediately followed with "no, actually of course I'll answer it".

And Marc then rattled off a series of pretty impressive reasons for Open Source, including:

  • Because of their cost structure and the international reach of JBoss Group, they literally have some of the best developers in the world working on the project.
  • They support the J2EE standard, though they are not tied to it for marketing or business reasons, and they have implemented features not mandated by the J2EE standard in order to build a better product.
  • Because they have such great developers and are driven by nothing other than technical reasons, they are actually able to innovate and extend the capabilities of J2EE containers. He gave examples where some of their research is considered as being world class. Others on the panel agreed with Marc on this point.

But both Simon Phipps (from Sun) and Tyler Jewell (of BEA) cited sources indicating that the actual license costs were only a part of the total cost for developing applications. Tyler indicated 1) that companies usually spent about 6 times what they spent for licensing on support and services, and 2) that BEA's professional services rates were actually cheaper than those of the JBoss Group anyway.

Tyler then ask Marc if the JBoss Group would consider setting their professional service rates to be 6 times their license costs (which, of course, was a joke since JBoss is Open Source and free...).

Simon Phipps spent some time describing Sun's commitment to Open Source technologies (which I agree have been very significant). Upon hearing Simon describe the Net Beans technologies that Sun has been supporting, Marc Fleury lifted his hand to his mouth and made a funny sound not unlike a sick duck quacking.

One of the points that Simon (from Sun) made in support of commercial products is that they were more likely to be certified as supporting the J2EE standards. (Commercial companies generally pay Sun to license the tools used to 'certify' products as 'J2EE-compliant'.) With Open Source projects it was likely that they didn't do so - and that since Open Source projects were developed by a team of developers for whom "standard compliance" may not be as important as performance or other technical features, it was possible that the Open Source project may diverge from the standard and leave users as locked in to a single platform "as if they'd used .NET".

Simon also mentioned that Sun had offered to make the toolset for J2EE certification available to JBoss and challenged Marc on-stage to get JBoss certified as compliant.

Marc discussed how JBoss was actually hoping to feed some of their extentions back into the J2EE standard. He said that improvements to performance and capabilities were important - and that standards compliance for its own sake didn't always result in the best products ("remember CORBA?", he asked).

Tyler (from BEA) also added that his company provides phone support 24 hours a day all around the world (and generally in the local language).

As time ran out on the session and people began filing out of the auditorium bound for other sessions and tutorials, the panel discussion stayed heated. I heard people calling for them to 'take it off-line!.

I guess in the end I took from it that while software being free and open source is good, that may or may not mean that it's the most cost-effective solution for your company. But I also walked away certain that innovation in the industry was as likely to come from the Open Source sector as it was from anywhere else - if not more likely.

In the end, you need to compare the options for yourself and make the decision based on all the needs of your business.

If you have questions, though, I'd recommend not asking this group. You might end up having to pull them apart.


2003-03-21 09:41:18
Whats JBoss problem with Netbeans?
2003-03-21 10:56:40
Whats JBoss problem with Netbeans?
Nothing specific was articulated. It was really just a classic Marc Fleury commentary on NetBeans (and potentially a mini-swipe at Sun in general).

It may have something to do with the Sun/IBM rivalry over Netbeans -versus- Eclipse in general. Marc had good things to say about Eclipse.

Remember, Sun and JBoss are competitors. Sun's influence on the J2EE Spec and The JBoss Group's complaints about the spec (and their desire to extend and improve it) are bound to cause conflict.

In the end, both Sun and the JBoss community (and the JBoss Group, specifically) want to influence the direction of the J2EE standard - and both for good reasons I believe. They both want to make sure it survives and leads .NET.

I think the JBoss Group have a technical vision and can lead J2EE to a better place, but they see Sun as influencing it greatly and moving at the pace of a large, company concerned with their own interests.

On the other hand, I think Sun sees the JBoss group as a threat to their revenue (rightly so) and thinks that the JBoss Group are likely to move the standard in an uncontrolled way - potentially leading it in the wrong direction. The JBoss community just moves and innovates too fast for Sun to feel 'in control'.

I'd say the ideal solution would be for Sun to learn to work with the JBoss group in a way that allowed them to harness the innovation they offer, while having the JBoss community learn to compromise with Sun to take advantage of the stability and 'big name' they bring to the party.

In some ways, the relationship reminds me of the IBM/Microsoft relationship of about 15 years ago. Both need each other, but both want control and have different definitions of success.

2003-03-25 08:36:15
Standards compliance and lock-in
Marc Fleury already pointed out the standards compliance for compliance's sake doesn't always result in the best products but the commercial vendors (BEA, IBM) and Sun still use it as a powerful marketing tool. And businesses buy into it.

Just as they buy into the "avoid vendor lock-in" ploy. I find it difficult to believe that BEA sincerely expends engineering resources to ensure that customers can easily move from WebLogic to WebSphere, or that IBM does the same in reverse. Yet many a BEA sales person has walked through these and other halls touting "portability" and lack of "vendor lock-in." And who is to say that it would be any more difficult to move from JBoss to one of the commercial application servers than it would be from one commercial server to another?

How did "vendor lock-in" become such a frightening beast to businesses? Part of it is Sun propaganda aimed to belittle Microsoft, of course. More rationally, a company wants to be able to find and hire workers trained on a particular platform, so they need not train them themselves on a technology potentially headed for obsolescence. This fear is mitigated by two points: First, a better designed and planned architecture than J2EE could be learner in less time than J2EE. Second, JBoss is still J2EE based (even if not, currently, J2EE certified), so it is on fairly equal footing here.

Businesses "locked into" Microsoft products have been stung by that company. If you're not locked into a vendor, the argument goes, you don't need to succomb to their endless forced upgrades and the associated costs. Yet can anyone using BEA's (or IBM's) products honestly say that they have broken free from the paid upgrade cycle? Upgrading to a new version of JBoss does take time (migration, testing, etc.) and therefore is not truly free, but at least these upgrades are free, and intended to add real value or fix bugs, rather than as an excuse to separate you from more of your money.

The final argument using given for avoid vendor lock-in is, "What if the company goes under and we are stuck with an obsolent technology?" Again, the J2EE commonality puts the servers, open source and commercial, on more or less equal footing. And an open source community of volunteer developers can continue on, unaffected by the demise of a commercial entity.

And if Sun, the J2EE custodian for the present, goes out of business (which is a very real possibility) then BEA and IBM are no safer than JBoss.

2003-03-25 16:57:15
Whats JBoss problem with Netbeans?
JBoss is as much a threat to Sun revenue as BEA is, yet BEA and Sun are much more chummy.

The BEA guy was quite correct that the value in these products to their makers is the inroads for services against the product.

Sun is giving away their J2EE server. They're bundling it with Solaris, and they're giving it away for Linux and Windows.

Software breeds services, but services is where the money is.

2004-02-29 12:10:35
Bob Bickel (JBoss) on "middleware commodization"
Bob Bickel, VP of Strategy and Corporate Development at JBoss, discussed Open Source and the "commodization" of middleware in a just-released video interview.

Bickel discusses Open Source and Linux, .NET vs. J2EE, and aspect-oriented programming with Java and C#. This URL has links for watching (Real Video, Windows Media) or listening (MP3) to Bob's comments. Running time: 6:11.