Weighing options when going the open source J2EE route

Weighing options when going the open source J2EE route

Summary: In my last blog entry, triggered by a correction request from a member of ObjectWeb's executive committee, I descended into the netherworld of open source Java -- a world that few people understand and even fewer know what to do about should they be considering J2EE as the basis for all or part of their software infrastructure.

SHARE:
TOPICS: Software
0

In my last blog entry, triggered by a correction request from a member of ObjectWeb's executive committee, I descended into the netherworld of open source Java -- a world that few people understand and even fewer know what to do about should they be considering J2EE as the basis for all or part of their software infrastructure.  Here's one big reason that it's confusing: Before investing in an open source Java 2 Enterprise Edition application server (J2EE), you need a good sense of at least three intersecting worlds: (1) certification of a particular J2EE offering for perfect conformance to the Java specification, (2) certification of a particular J2EE offering for compatibility with other parts of the software stack (ie: operating systems, databases, other applications, etc.), and (3) Sun's licensing terms (particularly if you're thinking about redistributing some J2EE-based solution).

Where as the first blog dealt with issues #1 and #3, this blog deals with #2 -- stack compatibility -- and what your options are.  Enterprises basically have two choices when it comes to using open source J2EE app servers -- insource or outsource. If you ask me, you're much better off outsourcing than insourcing because it can save money and qualifying stacks does not contribute to your competitive advantage.

For enterprises, insourcing means relying on themselves to come up with a "qualified stack."  In other words, you do all of your own regression testing to arrive at a "stack" of software (combination of specific versions of operating systems, application servers, databases, enterprise applications, etc.) that you know and trust to be stable enough that it can rolled out anywhere in your enterprise.  Those enterprises could be spending those resources solving a problem that contributes to competitive advantage instead.  You could be creating something unique instead of covering the ground already covered by many others.

Apart from completely turning your solution over to an outfit like IBM Global Services, outsourcing (in this context) means finding a third party that is willing to say that a certain stack is stable and to stand behind that by offering support.  Except for a few brave companies, the majority of businesses are willing to pay for the luxury of the latter rather than taking on the significant burden of the former.  Unlike enterprises that decide to take the full cost of stack qualification on themselves, third parties can spread the cost of stack qualification across multiple customers.  This is how companies like JBOSS make their money.  

If you're going to outsource, then the question becomes: To whom?  As best as I can tell (from ObjectWeb's Web site), stack qualification and ongoing support cannot be outsourced to ObjectWeb (although it appears as though one benefit of membership is a collegium that could be informally tapped for help, if need be).  When J2EE is involved, you could turn to JBOSS since that's the company's business model.  But for more broadly applicable stacks of open source, the better choices might be outfits like SpikeSource and SourceLabs, both of which specialize in open source stack qualification and support.  For example, according to SourceLabs' home page:

SourceLabs sells support and maintenance subscriptions for tested, certified "stacks" of open source infrastructure software, which we provide free of charge. Rather than simply repackaging the unit tests produced by open source communities, the company's rigorous CERT7 testing framework produces a documented, reproducible certification for functionality, scalability, stress response, fail-over and security.

Recently SourceLabs hired open source luminary Bruce Perens (see/listen to my interview of Perens from earlier this year).   SpikeSource's Web site offers a similar statement:

SpikeSource offers integrated, validated, and certified open source stacks with ongoing maintenance and enterprise-class support services.

In an interview with me earlier this year, SpikeSource's CEO Kim Polese discussed how the company was just emerging from its beta phase.  Part of SpikeSource's business model is provide the services for software developers as well.  To wit, according to a SpikeSource press release, the company is working with ISVs such as ObjectWeb and SugarCRM to make sure those applications integrate well with SpikeSource-certified stacks.  Perhaps as an indicator of popularity, a search of SpikeSource's site reveals awareness and support for J2EE servers such as JBOSS and Pramati, but nothing for JOnAS.  As with just about any other technology, this popularity factor -- particularly in the enterprise support arena -- will and should play a role in which technologies enterprises choose to depend on.

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

0 comments
Log in or register to start the discussion