After the recent news about SpikeSource, and listening to Fleury’s comment about JBoss being “professional open source” (vs. all those loser, he all but says, who just work on stuff at night. Yeah, there’s that Fleury ‘tude that makes him so lovable!), I’ve been interested in the recent idea of paying a third company to “certify” and support your open source code. SourceLabs is another one of these companies.

First, here’s some links about SpikeSource:

• 
  Article on SpikeSource: “The startup pledges to provide “validated and certified open source stacks” as well as “pure and commercial hybrids” to enable faster implementation, improved application management and lower cost of ownership.”
• A counter view from Om Malik.
• Notes from the Web 2.0 SpikeSource announcement.
• Red Monk/Stephen O’Grady’s comments.
• Technorati search for “spikesource”.
• The Gillmor Gang talks about SpikeSource this week, for the entire show. “What we want to do, in essence, is make open source safe for IT,” Kim Polese.
• TSS Thread on SourceLabs.

It’s the idea in that last quote that peaks my interest the most. When I initially thought about this, I come at it from a programmer’s perspective. That is, my thinking is, “these ‘professional open source’ companies are going to help us coders use these open source thing.” But, then I realized all this wasn’t really for programmers at all: it’s for IT/IS people. That is, they’re going to help out people who are installing and using open source apps.

Sure, they’ll be willing to help out programmers who’ll pay, and certainly in-house app development of smaller applications that are more “fitting components together” instead of “building with components.” But, I suspect, their primary customer isn’t the second group of developers who are using open source. Maybe I’m be an egotistical coder, but figuring out how to use, and make “safe,” open source code (as with commercial code), is a large part of what programming is.

In all the chatter surrounding this Dell comes up a lot as well. I’m not really sure what the comparison is, but one that stands out is Dell’s famous near-zero inventory system. That is, Dell keeps as little inventory on hand as possible, assembling computers on demand. (As snarky folks like to point out, they just shift that cost down the chain to their suppliers.) And, of course, Dell doesn’t really manufacture every component, they buy ones from manufactures that work together, and just manufacture the final product: the computer.

Similarly, these professional open source companies (SpikeSource and SourceLabs, not JBoss) don’t actually create the different components (apache, php, JBoss, etc.), they just assemble them at the end: they package up all these disparate things into one package. Indeed, that’s another large part of the chatter, something along the lines of, “there’s so many open source projects/components, and it’s confusing and tedious for IT people to pick which ones to use. We’ll help them.”

Here’s the problems I can think of for the “open source service company” business model:

• Cash Money. The primary problem that still sticks out in my mind is the money. For all the ballyhoo about open source being high quality, delivering features faster, etc., a huge part of open source’s advantage over commercial software is the cost: open source is free, commercial software isn’t. As I’ve pointed out before, one of the “side effect” advantages of “free,” in the context of acquiring software in a company, is that you don’t have to go up the chain to get budget approval for the commercial software. With open source/free software, you just download it, and install it.

  So, getting back to these open source service companies, as O’Grady pointed out so much of their success will ride on price. If it’s cheaper for a company to just have their IT people figure it all out, they’ll do that instead of hire on an open source service company. Worse, once you take away that “easy to install ’cause it don’t need budget approval” advantage, open source looses part of it’s edge, and you start to ask, “why don’t we just buy a WebSphere license?”

• Vendors Ship Source. If commercial vendors start shipping their source, remaining commercial, the difference between them and open source will blur. That’s a crazy thing to imagine — can you imagine if WebLogic shipping with all it’s source? — but if big vendors feel like they’re backed into a corner, they’ll start considering anything to keep the quarterly numbers up. Better to have your source in the open than your ass out the door.
• The TLA Wars. Whether it’s TCO, ROI, or whatever TLA of the day means “is option X cheaper/make more cash than option Y?”, there could be a successful marketing campaign to convince the customers that given you have to pay for open source now (with these companies), it actually costs the same to just get commercial software…and don’t you feel better just snuggling up with a vendor?
• It’s Still Hard to Use. After signing the contract with your open source service company, using all that open source is still an onerous task, so why renew the contract next year? This would be the “never leaves the trough of disillusionment” problem.
• The Open Source Community Rebels. Geeks hate feeling like they’re being taken advantage of, and when someone makes money off work you’ve done, and you don’t get a cut, it starts to seem like you’re being taken advantage of. Geeks are also the ones who write open source software. Part of open source service company’s message, implicit or explicit, purposefully or accidently, is that the open source community isn’t doing a good enough job. You pay these companies to help finish that job. If the open source community takes this the wrong way, things could go sour, licenses could be re-written, and nastyness a la “why don’t you open source Java?” could start happening.

Anyhow, it’ll be interesting to how this “second generation” of open source companies pans out.

Update: after listening to a panel of CIO’s talk about their desire for support for their open source apps, I can better understand the viability of these “open source service companies.” Indeed, “open source support company” would be a better phrase.The above risks still apply, but the question of whether there’s a desire for it seems pretty well addressed: many large companies really like having support contracts, whether it’s for commercial, or open source software.