Sifting open-source wheat from the chaff

BusinessWeek is asking an important question of open-source companies: despite the rapid growth of some open-source businesses (e.g., Red Hat, Novell Suse, Alfresco, SugarCRM, and others), it's still very much an open question as to whether open source can deliver outsized returns for investors.

"A pure service business is not particularly defensible," says [Red Hat CEO Jim] Whitehurst. "Some open-source companies have not truly figured that out." If the open-source movement, now in its second decade, is to realize its promise for vendors and investors, more of its purveyors will need to get the message soon.

Savio Rodrigues of IBM has been beating this drum for some time, suggesting that pure open-source business models have a built-in glass ceiling. While I think this is a bit overstated, I 100 percent concur that any business must figure out a "proprietary" differentiator that tells a customer, "This is why you buy from me rather than my competitor, and rather than taking it from me for free."

Support, as Jim Whitehurst suggests, is not a compelling enough argument for most would-be buyers.

This is why I've argued for a phased approach to open source. It's inefficient to try to "reap" every prospective customer in the early stages of a business: making the code open source lets a company sow a wide field of prospective buyers.

But it's also inefficient to rely on faith and goodwill to reap customers later in a company's growth and revenue trajectory. There must be a compelling reason to buy. This is where many in the open-source world lose their way. But what should that reason be? That is the nettlesome question.

BusinessWeek calls out Red Hat as headed for trouble, but I don't see that. I think the company has already figured out considerable proprietary value, which model it simply needs to accentuate by adding more and more value higher up the stack, value that would-be buyers can't have for free--at least not in the same form as the code Red Hat gives away.

I like the way that SugarCRM, Zimbra, and others have been settling this question. In SugarCRM's case, you pay to scale true enterprise use. There is some technology that only a company with serious, large-scale production plans needs to run your software. It is fair to make such technology (e.g., clustering) available only to paid subscribers. Doing so doesn't slow down their ability to trial your software.

Yes, the company must forfeit some community involvement in these bits, as MySQL's Marten Mickos has suggested MySQL may consider, but that's a considered, prudent risk.

In Zimbra's case, if you want to connect it with proprietary software, you pay. Or if you want advanced administration features, you pay. Both seem like fair policies (and fair trade-offs) to me.

A time to reap, a time to sow. Early on, you want as much access to your product as possible, as the intent is to drive adoption first, then revenue. It is critical, however, to not paint yourself into a corner wherein you have little option to provide commercial extensions. The code and company policy must be malleable to this end, even if you ultimately decide not to do it.

In my own experience, I believe the first thing to offer after the open-source core project is an add-on "network" that provides administration, facilitated deployment, and perhaps the first hint of commercial extensions. It's a service that complements the code and, while it may help make deployment easier, deployment is not dependent on it.

However you choose to do it, you need to be looking three to four years out when building your open-source business, and providing for a life after a pure support model. That is, if you want to deliver the returns your investors expect.