Red Hat's JBoss conundrum
JBoss seems to be undergoing some generational pains as it strives to morph from an open source products company to an enterprise open source products company. So its recent formal announcements covered the enterprise tack: something called Enterprise Acceleration that performs the basic blocking an tackling to show enterprises, ISVs, and systems integrators alike that nobody will get fired for buying JBoss. And then there were the pronouncements to the faithful that, while JBoss is trying to go enterprise, that it won't forget its roots.
First, the enterprise stuff. So-called Enterprise Acceleration is a new bunch of consulting services, testbeds, benchmarks and best practices for reducing the risk of migration, which cover migration, interoperability, and performance tuning. Plus, for ISVs and systems integrators, a center that formally certifies that third-party applications indeed run properly on JBoss.
There's little startling about the announcement. Given that JBoss has always pitched itself as the challenger, and that its product has cultivated a reputation as a compact, flexible body of code that just actually works, the burden of proof is on JBoss to document that it can scale up and won't jeopardize security.
JBoss also announced its new service oriented architecture (SOA) platform, but there's less to the announcement than meets the eye because JBoss already had some of the pieces. The SOA platform announcement was that its enterprise service bus (ESB) was now ready enough to be bundled with JBoss' existing business process management (JBPM) offering. We emphasize "ready enough," because the ESB is still technically in beta. According to Crag Muzilla, vice president of the middleware business, the core is in place, but still lacks some tooling.
But back to the growing pains. Although the acquisition by Red Hat is almost two years old, as we noted last week, the move has not gone down smoothly with the customer base. At first blush, the concerns are over licensing and support, but they belie a general feeling that Red Hat is trying to tame JBoss's culture. Muzilla likened it to sibling rivalry, where the younger brother resents the older one for growing up too quickly.
Addressing questions about whether the deal was good business for JBoss, Muzilla admits that a drop in sales following the deal were the result of turnover in the sales teams and inadequate cross training of Red Hat reps, who didn't fully understand the JBoss business. But he claimed that JBoss is on the upswing, with business increasing for each of the last three quarters, and that the accounts teams have been repopulated with salespeople from the likes of BEA Systems and Cape Clear - who obviously should help the business.
Although both began and still conduct business as open source product companies, arguably, Red Hat was around commercializing a support model for external innovation around Linux, whereas JBoss' open-source model is more about what we have called in the past the captive model, in that it was largely about its own project - or projects such as Hibernate where it hired the leaders and brought them in house.
Chief technology officer, and the contemporary of former JBoss chief executive Marc Fleury, Sacha Labourey apologized for "a complete shutdown of communications" that exacerbated the problem with JBoss faithful, admitting that JBoss management was too preoccupied with integration into Red Hat. When it came to communications, JBoss swung from one extreme to another. He conceded that when JBoss spilt off the enterprise product from the core open source project on JBoss.org, that many of its best customers were not even aware of the split. Admittedly, the turning down of the volume reflected a move to make the company more enterprise-friendly, where customers with large deals value product stability over nightly innovation.
And, with the splitting of JBoss.org, the goal was to align JBoss' open source business with that of Red Hat, which has two separate streams: one that stabilizes code for enterprise licenses, and the other the purer open-source model where source code is updated nightly. Labourey took pains to point out to us that, although JBoss was trying to align itself more closely to the Red Hat business model, that JBoss would retain its uniqueness. Admittedly, the differences were a bit subtle to our ears: while Red Hat Enterprise Linux is only publicly available in binary, for JBoss, you can get access to the source code if you go to the JBoss.org site, where it's frozen in an image.
To paraphrase Stephen Colbert, some open source technologies have more open sourciness than others.
This article originally appeared in onStrategies.
Copyright (c) 2007, onStrategies.com
Tony Baer is the principal with analyst onStrategies. With 15 years in enterprise systems and manufacturing, Tony specialises in application development, data warehousing and business applications, and is the author of several books on Java and .NET.