We noted last week that 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 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, covering 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 SOA platform, but there’s less to the announcement than met the eye because JBoss already had some of the pieces. The SOA platform announcement was that its ESB (enterprise service bus) was now ready enough to be bundled with JBoss’ existing JBPM (business process management) offering. We emphasize “ready enough,” because the ESB is stil 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 sales drops 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 and Cape Clear – who obviously should 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’s 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.
CTO and Fleury contemporary 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 for 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 side, where it’s frozen in an image.
To paraphrase Stephen Colbert, some open source technologies have more open sourciness than others.