Sun Frees…Well…Everything in its Software Stack

What was it I said before – you heard it here last? Such is the case with Sun’s recent announcement that it would make its middleware stack first free, and eventually open source. For specifics on the announcement, you can head over to Sun software chief Johny’s blog here [1]. Sun’s open source head honcho Mr. Phipps seems enthused, my colleague seems relatively on board, and even IBM’s Bob Sutor gave it a brief mention. Here’s my Q&A on the subject:

Q: Disclosures?
A: Sun is a client of ours, and I have consulted on both the products involved and this particular decision.

Q: So, having had the opportunity to discuss the move in some detail with Sun, what, in your opinion, is the motivating factor here?
A: Well, I don’t know that there is one, single motivating factor. Certainly the question of marketshare – Sun lags vendors like BEA and IBM in categories such as application servers by a significant margin – is top of mind. But Sun also – despite reports to the contrary – has gotten Free and Open Source (FOSS) religion in a major way. When Jonathan is saying things like “betting against FOSS is like betting against gravity,” you can be relatively confident that this is more than a mere marketing gimmick.

Q: What does this do to address the marketshare consideration?
A: Well, as much as I’m reluctant to bang my “barriers to entry” drum again, that’s the explanation. Prior to this announcement, anyone wishing to run on top of JES faced (at a minimum) two significant barriers:

1. License Costs
2. Lack of Source Code

While the second problem has not been addressed yet, Sun is now officially committed to it, and the first barrier has been removed entirely. What does this mean, practically speaking? People who could not run on JES previously – for financial reasons or otherwise – now can. Whether they will or not is a matter of some debate, but they can. The lowering or elimination of these sorts of barriers to entry is, IMO, a strategy that has been proven effective with the success that products like JBoss and MySQL have had at the expense of market incumbents.

Q: So removing the barriers to entry generally leads to slam dunk successes?
A: Not quite. First, the technology itself has to be credible. If I developed in my spare time the sogBoss application server or the sogSQL relational database and made them available with no barriers to entry, I can assure that you no one in their right mind would use them because they’d be terrible, terrible products. Eliminating barriers to entry merely opens the door; someone has to want to walk through it. Sun fortunately does not have that sort of problem; while some of the individual components of JES have better reputations (identity, for example) than others, I haven’t talked to many people who say they’re not credible – at least now that the app server has been completely rewritten as opposed to the mishmash it used to be.

But the next step for any successful project or product is continuing to eliminate barriers to entry beyond the obvious macro licensing cost/source access questions. Those are important, but that’s the equivalent of getting across the moat in a castle – there are still all sorts of obstacles that need to be addressed. Some are sexy (APIs), some are not (documentation), but all are important. Because at the end of the day what you want is to have a developer be able to pick up and run with what you’ve developed, and get something online in minutes or hours, not weeks or months.

Why, for example, is Ruby so phenomenally popular? Because the language is elegant and easy to learn? Not in my book. It’s instead because Hansson and the other RoR guys have made significant choices for the developer, eschewing configuation in favor of convention. This limits flexibility, but dramatically lowers the barriers to entry.

So Sun’s taken an important first step towards lowering the castle walls, but it’s but the first of many.

Q: So I’ve got a question about the economics: what’s the deal with the economics? How do you make money giving things away?
A: Again, I’ll fall back on an overutilized analogy of mine – the one that says that you have three types of customers: those that will pay you, those that might pay you, and those that will never pay you.

I’ll apologize in advance for the somewhat offtopic digression into our business, but I do think it’s germane becase we get asked that same question all the time. We give things away, like this piece itself, and yet we get by fine financially – how is that? Because there were sufficient folks in the first category for us to get off the ground as a business, and enough in the second to grow the business. How did we do that? By leveraging the third category – the folks who will never pay us. I’ll do anything and everything in my power to help the individual developers in my world for absolutely no money, because they give us relevance to the folks that will or might pay us. It really is that simple. Nor do we give everything away: the ability to give our name to the media during product launches, for example, is something we only grant to subscribers. Ditto for quotes for press releases. Like SugarCRM, most of what we do is free and available, but some isn’t. To sum up: giving things away can easily grow your revenue opportunities, rather than undermine it.

Q: But how does this apply to Sun? Their business is slightly different from yours, after all, in that the capital expense required to run a hardware and software business is significantly different than a business that consists essentially just of idea.
A: True enough, but it’s not so different that the same principles discussed above don’t apply. In his latest entry, Jonathan relates an interesting customer anecdote. One of their customers, used to having Jonathan’s home # for support, suddenly discovers that the software he’d been paying for is now available for free, and says “HA! I’m not paying you $500K for something that’s free!” The punchline, of course, is that upon discovering that they’d essentially be on their own not if – but when – something goes wrong, they add it right back on the PO.

Distilled down, this says that the value in Sun’s software is shifting from the bits to the services and support layered on top of it. That’s a bet that a lot of folks within the software world are making right now. Is it the only way to make money in software? Nope. Is it going to be the dominant pricing format? Not in the next year or two, probably, but longer term? Maybe.

My short answer is that just because the economics are different, doesn’t mean that they won’t work.

Q: Do you have concerns about that model, basing a big component of a revenue stream on service/support?
A: Certainly. Anyone who’s worked with or in the support/service business understands that it’s hard. Really hard. Gavin’s got more on that here. There’s nothing I used to hate more (apart from travel) in my SI days than having to call commercial software support. Having people available 24 hours a day, 365 days a year does not come cheap – unless the customer is willing to help themselves a bit as is often the case in open source. Throw in the fact that I’ve been hearing persistent rumors that some of the startups in the FOSS service/support arena are having a difficult time actually monetizing customers – to the extent that one or more may need to raise more cash – and I certainly have concerns.

But I’m a firm believer that in the world of software there are enough customers in the “will pay” and “might pay” categories to make the changing economics viable for the players that are able to provide support services in an efficient, automated-as-possible fashion. I don’t know if it’s literally true that Sun does not have a customer in the world that runs an unsupported product in their datacenter, but figuratively the point is made: enterprises want problems with the software to be someone else’s problem. Therein lies opportunity, as they say.

What remains to be determined, I think, are a.) which brands will gain equity as strong in the support/service categories, and b.) what do the margins, tiers etc look like in support service if the bits themselves are free. In other words, who’s going to be running the next generation software business model, and what does it look like?

Q: What does this move mean for competitors in the middleware space?
A: It’s another straw on the camel’s back, but not the one that breaks it. The middleware space was already facing significant pressure from free and open source packages, and the Sun software – while important – is not so revolutionary as to overturn the commercial ISVs businesses overnight. But I do believe that the rising tide of open source middleware and databases will put pressure on the market incumbents. In some respects, we’ve already seen that with the IBM acquisition of GlueCode.

Q: What’s the most interesting aspect of the announcement?
A: Well, I do think it’s rather interesting that an enterprise software provider that’s made the investments that Sun has in its software portfolio sees the light on F/OSS to the degree that they promise to open source everything, but that’s more strategic. Tactically, I’m most interested in the SeeBeyond piece, as is, apparently, JBoss’s Mark Fleury. Why is that? Well, certainly because integration’s been a big bucks business for lots of commercial vendors over time, but also because I think the open source world lacks a top of mind integration player. In most of the other application categories you can think of one or two packages that are the most universally accepted, whether that’s application servers, relational databases, HTTP servers, IDEs, etc. Not so – IMO – for integration software. There’s a lot of open source options, to be sure, but when I think open source integration nothing springs to mind as, say, MySQL might if I think open source databases. This same line of thinking applies to identity, incidentally.

Q: Speaking of open sourcing, why does it take so long for the actual code to be opened up?
A: I didn’t use to understand this that well either, because coming from the perspective of an end user or systems integrator it seemed simple: take your bits, pick a license, and you’re off and running. But the fact of the matter is that the vast majority of major enterprise software products are anything but a single pile of bits: they are instead a collection of application code, drivers, repositories, OEMed software, etc. Tracing the implications of all of these individual pieces from a licensing standpoint is both costly and time-consuming. Unfortunately.

Q: How long can Sun afford to be patient, given their financials?
A: As I’ve told a couple of reporters already, I’m the wrong guy to be asking that question, as I leave the financial health of the institutions in question to the professionals. You won’t ever see, I don’t think, an open letter from RedMonk to one of the major software vendors advising them on how to spend their money or restructure their organization operationally. That said, what Sun can not afford to do is continue to take on market incumbents without leveraging the distribution advantages that FOSS offers. The bundling and employee based pricing was a bold move, but open source has really changed the game – and this announcement confirms that Sun gets that. Sun will have to be patient here, no question, because building communities around products time – lots of it.

[1] As a side note to Johnny, I’m curious as to whether your kids have seen Hunt more than my brother. He’s at the point where he can recite the Russian lines word for word, despite not speaking the language. Yes, we’ve told him to get help 😉