As discussed previously, yesterday was a day dominated by talk of the JBoss/Red Hat announcement, which if you’re tuning late is this: Red Hat is acquiring for JBoss for a minimum of $350 million, with an additional $70 million available depending on performance.
While the acquisition of JBoss is certainly not unexpected, as rumors have been circulating for months, it does qualify as big news. Most of those rumors centered on Oracle, however, rather than Red Hat, as the potential acquirer. But as of yesterday, Red Hat is the proud new owner of a popular open source middleware business, and as promised, here’s the Q&A:
Q: Before we get the actual deal, what can you tell me about the deal that didn’t happen – what happened to Oracle in all of this?
A: Well, I can’t claim any special insight here – we’re not as tight w/ Oracle as we’d like to be (the Sleepycat folks excepted), but my feeling is that the deal with Oracle was undone by two factors: personalities and cost. On the first, I’m told that Oracle was concerned about the possibility of transplanting Fleury – a very outspoken CEO, as we’ll see in a bit – into the Oracle organization. But the larger concern was cost; if you believe some of the numbers in the article cited above, the base figure that Red Hat paid is $30 million above where Oracle was willing to go.
Q: What do you think about that?
A: Well, I’m more focused on technology so I do not have a great sense of how financially sound Oracle’s reasoning was, but it might be reflective of the difference in how Oracle and Red Hat would use the technologies.
Q: How do you mean?
A: Well, it seems clear that Red Hat has ambitions for JBoss as a real revenue driver, and perhaps that was the case with Oracle, but I’m more inclined to agree with what my colleague has stated in the past, which is that Oracle was much more likely to use JBoss as a loss leader – a cheap application server to game the basic metrics of enterprise software license costs. Here’s how I explained that previously:
For any given project, there’s a software cost, a hardware cost, and a services cost. Over the past few years, there’s been a lot of downward price pressure on all three due to a variety of factors, but the software cost in particular. So if Oracle wants to continue to make good money on the database component of that overall software cost, it’s in their best interests to ensure that the other components of the software sale cost less. Pitching JBoss as the middleware is one way to accomplish that.
So could it be that Oracle was slightly more price sensitive than JBoss simply because they viewed the strategic opportunity that JBoss represented differently? Seems possible. But some believe that Oracle should have just ponied up the cash: Brad Feld, for one, believes that Oracle should have “stretched a little harder”.
Q: Ok, back to the deal at hand; let’s look at what it means for the folks directly involved. Let’s start w/ JBoss – why is this in their best interests?
A: Well, apart from the $350M reasons, to me this about resources. JBoss has, like MySQL, had a great deal of success building a community. In many shops, it’s the de facto choice for non-production (i.e. development) deployments, and it’s won a fair share of the production business as well – often at the expense of the category’s long time market leaders, WebLogic and WebSphere. There’s a critical difference between MySQL and JBoss, however, and that’s potential market size. MySQL can continue to grow in ways that JBoss could not, simply because it can go after markets such as that of dynamic languages that the likes of IBM and Oracle have not invested heavily in, while JBoss sells into a market that is not only smaller than that of relational databases but highly competitive. MySQL, in other words, can sell to those building on Java, but is equally applicable those on Ruby, C#, PHP, Python, Perl, or literally a couple of dozen other languages. JBoss, on the other hand, is a Java play; a sizable market in its own right, to be sure, but not the same thing.
What’s worked for JBoss in the past – having no barrier to entry offerings, a vibrant community, and low cost offerings – was no guarantee for future success, particularly as some of the larger players begin to learn the lessons that JBoss’ success can teach, as IBM has done with WebSphere CE. So it seemed clear to me that JBoss needed to grow, and grow quickly, to capitalize on the community size and open source advantages (such as being present in package management systems) that it currently enjoys, because that window might not be open forever. The simplest ways to grow that quickly are M&A and IPO, probably in that order.
By joining Red Hat, JBoss now has access to resources it didn’t have previously, and more importantly a direct in to Red Hat’s installed base, which includes truly massive financial institutions that from previous conversations would be only too happy to write one check rather than two. That’s a big deal.
Q: Ok, what about from the Red Hat side?
A: Well, that’s a bit more complicated, but basically I see it as twofold: first, it’s a recognition that for real growth, they need to sell something besides an operating system, and two, a reaction to past criticisms (some from Fleury, interestingly – but I’ll come back to that) that Red Hat doesn’t innovate – they’re nothing more than a service and support shop.
Q: Let’s focus on the first point: opportunities beyond the operating system – what’s the play there from where Red Hat sits?
A: Well, this is nothing new from Red Hat – they’ve had inclinations in this direction for some time. In the same space that JBoss occupies, they’ve made investments and commitments to JOnAS, and slightly more recently they acquired some of the old Netscape identity assets. It’s obvious from those investments that Red Hat has believed for some time that selling their own version of Linux along with support and maintenance, while a credible business in its own right, was not likely to grow their business at the speed or breadth that they felt necessary.
If one assumes that Red Hat was indeed fixated on the idea of expanding its product portfolio as a vehicle for growth, JBoss becomes the obvious choice. There are other purer support and service businesses they could have consumed, such as Covalent, OpenLogic, SourceLabs, or Spikesource – but JBoss is differentiated from those offerings by its community and the traction it represents. JBoss is one of the larger commercially oriented open source projects out there, and as such is a logical choice – at the right price. And before you ask, I’m not particularly qualified to answer whether $350 million is the right price, though I will say that they definitely paid a premium.
Q: Well then, what about the second point: the contention that Red Hat doesn’t innovate?
A: This is one that I hear a lot from Red Hat competitors such as Microsoft or Sun, and while I certainly can see the argument, I don’t really buy it. First, just because Red Hat is not responsible for many of the innovations within the Linux kernel does not mean that they cannot benefit from them; they can, and have, for years. More importantly, bearing sole responsibility for innovation can be difficult – Red Hat instead is able to ammortize the cost of their development over multiple organizations. But more importantly, Red Hat does have some very good developers, and they’ve done some excellent work in and around the Linux ecosystem.
The interesting thing, as mentioned above, is that Fleury himself has made the argument that Red Hat doesn’t innovate. As Dave Johnson was the first I saw to note, Fleury has said in the past – in entries I’m positive he now regrets (they’ve since been removed, as Ashlee Vance notes here) – the following:
RH is a packager, it doesn’t create JACK, it doesn’t create Linux, it wraps it up in proprietary shit. And no the contributions that they make don’t really count. Linus Torvalds creates Linux
So again, while it’s an opinion that I might not share, many folks have knocked Red Hat for being uninnovative and largely dependent on the contributions of others. JBoss, on the other hand, employs some very strong developers and will bring a lot to Red Hat in that regard.
Q: Other upside to the deal? Anything worth noting?
A: Well, it wouldn’t be an M&A analysis without some discussion of synergies ;), so let’s explore that. We’ve talked in abstract terms about some of the benefits for both firms, but here’s one very basic, pragmatic reality: Red Hat was competing with vendors who offered and owned their own middleware stack. Whatever you think of the Java Enterprise System that’s become part of Solaris or the transactional platform embedded within Windows, Sun and Microsoft could walk into customers with a stack they owned lock, stock and barrel. While I’m skeptical of such claims (see commentary below on support options), because I personally don’t see too many don’t know of too many operating system decisions that are made on the basis of having an integrating application platform, I’ve been told by both Microsofties and their competitors that there are instances where it’s helpful to be able to pitch a unified stack. Further, Sun certainly seems to be moving in this direction with Solaris. The synergy, then, is the prospect of a relatively complete stack that customers can buy from one vendor. What will be interesting is how heavily Red Hat pushes – or doesn’t – a bundled offering.
Q: So given that every deal comes with questions, what are the outstanding ones in your mind?
A: Well, there are many. But let’s start with the first one I look at in any acquisition: culture. As noted above, Fleury is not only outspoken but has been pretty solidly critical of his new employer in the past. His past characterization of Red Hat as an “open source wannabee” or “open source girly man” doesn’t seem to augur well for the relationship going forward. But with so much at stake financially for Fleury, it seems likely that he’ll play along at least for the medium term.
Of greater concern for Red Hat should probably be the developers they’re acquiring, because it’s they more than Fleury that are what’s being bought and paid for. As Alfresco’s (ex-Novell) Matt Asay noted in a post from a few days ago (that predicted that Novell would acquire JBoss), the JBoss employees are the wild card here:
The real question is what a move like this would mean for JBoss’ employees. Marc owns 50%+ of the company. I believe VCs (Matrix and Accel) own another 30% or so. That leaves very little for the employees, who likely won’t see much from a deal. Will they stay? Do they have the incentive to do so?
I don’t know the answer to that, and I doubt that anyone else does yet – but stay tuned. I have to think that Red Hat’s given this a lot of thought, and is doing what they can to make Red Hat a good home for the JBoss developers, but it wouldn’t be the first time that developers got overlooked.
Q: What about the partnerships and corporate relationships here? IBM can’t be pleased right now.
A: Ah, now we come to it – this is where it gets complicated. To answer the question, no, I doubt that IBM is blissfully happy at the moment. This is hardly a disaster for them, and execs on both sides are saying all the right things (IBM most notably is touting this as a validation of JEE (AKA J2EE)), but it should make the field sales rep relationships between IBM and RH folks considerably more interesting. Here’s how James put it yesterday:
JBoss is already being used as a negotiating lever by BEA and IBM customers to lower their WebSphere and WebLogic license fees. The RedHat deal will dramatically increase the trend, and puts RedHat in a very interesting position with respect to IBM customer relations. It now 0wns a surprisingly high proportion of corporate software expenditures at some joint customers. IBM’s decision to work with third parties that negotiate their own software licensing terms with IT shops could prove costly.
From a grassroots developer perspective JBoss just gained another potential advantage over IBM WebSphere Community Edition. Its all about the package, rather than the download.
All true, from where I sit. IBM’s WebSphere and WebSphere CE businesses both face implications from this decision.
Q: So what does IBM do from here?
A: Well, that’s the million dollar question. Initial speculation had them cozying up to Novell, and while that’s certainly possible I was at BrainShare last year when they announced a tightened relationship with JBoss that included code donations from Extend. Combine that with the fact that Novell was nearly fawning over JBoss at the time, and it seems that while Novell is likely to distance themselves from JBoss in future, they may have trouble doing so in the present. I believe, however, that Novell also has some sort of bundling arrangement with the WebSphere CE folks, so look for that to be expanded and/or better emphasized. Either way, IBM will need to reconsider it’s relationship with both Novell and Red Hat, and possibly its dependencies on them.
Q: And do what?
A: Well, one of the “What If” scenarios that came up during yesterday’s Gillmor Daily – and indeed is floated increasingly often – is what if Novell and/or Red Hat are themselves acquired by larger players – what would that mean for IBM? And the answer is too complicated to get into here, as there are lots of different ways that could play out – not to mention the fact that IBM is not exactly cash poor and could certainly bid competitively if their platform was at stake. But ultimately, it’s interesting to consider whether or not IBM might begin to explore in more detail a route I discussed way back in December of 2004: supporting Debian.
Q: You really think that Debian is going to justify the massive investment of supporting (yet) another operating system?
A: Well, the community is immense and growing ever more quickly thanks to Debian derivations such as Ubuntu – but to the real point, what if supporting Linux was easier than it is today? What if, for the sake of argument, the LSB became less of a trailing standard and more of a proactive, real time standard? What if the LSB solved, say, 97 or 98 percent of the support issues for a given application running on top of it, meaning that a vast majority of the support effort would be common to Red Hat, SuSE and then Debian? That might change the game considerably, and I’m beginning to get the sense that many different parties within the Linux distribution and application businesses are perceiving both the long term ramifications of the problem, and the potential opportunity there is if it can be solved. Either way, while, the question of what IBM’s Linux platform strategy is will have to wait for another day, Red Hat’s acquisition of JBoss does represent – in my mind – an opportunity for Debian. If any of the Debian (or Ubuntu) folks happen across this, drop me a line and I’d be happy to discuss it with you, and if I get to it I’ll write that up next.
Q: Any other issues you see with JBoss and Red Hat?
A: Not an issue, per se, but an observation: Red Hat is now in the business of supporting Windows applications. At the time that JBoss signed its controversial partnership agreement with Microsoft, Fleury was quoting numbers like 50% of our users (not customers, please note – thanks to Stephe for the clarification) are on Windows. While I very much doubt that Red Hat will do something dramatic like refuse to support those customers, they now have a major application package to support on another operating system. Maybe that’s good, maybe it’s bad, but it should be interesting.
Q: How about a quick comment on the support/service players mentioned above; Covalent, OpenLogic, Sourcelabs, and SpikeSource – is the beginning of the end for them?
A: I don’t see that at all. If their businesses were pure JBoss on top of Red Hat models, then yes, I’d say it’d be pretty much over. But they’re not; they’re about providing mission critical support to a diverse set of open source products. As much as stack vendors – whether we’re talking JBoss or IBM and Oracle – would prefer to sell customers on a single source stack, we are still seeing a lot of mixing and matching of components out there. Enterprises that we speak with and track are freely mixing a variety of open source products in with their commercial packages, in combinations that disregard single vendor stack boundaries. As long as this continues to be the case, it seems evident that there will be a services and support economic model that’s independent of the single vendor stack.
Q: Any last thoughts?
A: Just one follow up on a comment from yesterday. Dana Gardner’s analysis here was really pretty strong, but there was one bit I didn’t and still don’t agree with:
Greenfield Web 2.0-type ISVs and startups have a no-brainer now for an expanded, solution-oriented stack partner in Red Hat.
Very few of the startups, let alone Web 2.0 types, that I speak with are running the RH / JBoss combo. The vast majority I speak with are running alternative distros such as CentOS (a RH equivalent), Debian, Fedora, etc. Even fewer are basing their applications on Java, and the ones that I know that are doing so run a simple container like Tomcat, not JBoss. At MashupCamp, for example, the really pretty cool WeatherBonk was – as far as I could tell – the only Java based app there. PHP dominated Mashup Camp, and I’ve obviously been impressed with the traction around Ruby in other startup type areas. So while this deal has a lot of significance to enterprise Java buyers, I’m not convinced it’s all that relevant to the startup/Web 2.0 crowd.
Disclaimer: Let’s see, BEA, IBM, Microsoft, Oracle (Sleepycat), SourceLabs and Sun are RedMonk customers, while Covalent, JBoss, MySQL, Novell, Open Logic, Red Hat, and Spikesource are not.
