Open Sources | Rodrigues & Urlocker » A downside to open source: leakage

May 10, 2006 | Comments: (0)

A downside to open source: leakage

TAGS: Business, Business, Open Source

A friend from a large enterprise (buy side of open source) sent me an email today. I had asked for his opinion on how to improve the Open Source Business Conference, a show I and a few friends founded a few years back. He said something in the course of his email that I found very interesting, if difficult to deliver:

[You need to show] [h]ow to decide which OpenSource product is really cool and does what it says on the tin and which is vapourware\aspirational.

What Open Source products have my competitors used? Successfully. And unsuccessfully....

I like the panels - especially when they disagree. One of the things I find a bit discomfiting at conferences is when all the shiny, happy people on a panel agree...

... the core thing that I try and get through to my senior, senior management is the understanding that Open Source is NOT a panacea; is not totally free; and can sometimes be complete [junk]. I think that representing that as a truth would gain a lot of credibility among IT professionals.

In short? He wants to see the reality of open source, and not the shimmering, sparkly side that we vendors constantly trumpet (myself definitely included).

So, what's the biggest downside to open source (for vendors)? Its inefficiency at converting usage into revenues.

For many of you (especially those on the development side), this is a hollow whine. After all, many of you primarily are concerned with seeing your product used and people benefiting from it. Fair enough.

For those responsible for turning your work into your salary, however, and by this I mean the greedy, narrow-minded pointy-haired boss salespeople (like me :-), "use" is not always as happy a thing as one would suppose. It is brutally difficult to see, as I did today, for example, a Fortune 500 company eagerly, happily using your software.

And not paying you a dime, franc, or ruble. Nada.

Get enough of these customers, and you neither have a business nor a means to fund the development of more code.

Ask Red Hat now if they are fine with Google using their distribution without paying for more than one copy (as the folklore goes - which folklore I believe was true as of a few years ago, though it might have changed since), and I'm sure they'd say, "Of course! It's a testament to the code we certify/test/etc. that such a great company would use ours as a starting point."

When I sat in a room in 2002 and heard that question asked of a senior Red Hat executive, however, he grimaced and didn't respond.

The difference? Red Hat today can afford "leakage," and, funny enough, gets less of it now that its brand commands respect which commands cash. Red Hat back then could scarcely afford salaries (unprofitable as it was), much less leakage.

Lest you take this wrong, let me state clearly: I believe in open source software. I believe great businesses have been built with it and will continue to be so (my own, included, I hope).

But it is not for the faint of heart. You have to be prepared to watch would-be customers, big and small, derive immense value from your software without paying you. Value that they'd gladly pay for in a proprietary world. Value that they would have to pay for.

Why do they freeload? Not because they're evil, but because they can. Their business is making money while spending as little as they can. Who can fault them for using free software whenever they can?

And, if you're honest with yourself, you'll recognize that you probably use a lot of free software, too. In Alfresco's case, we richly benefit from Lucene, the Spring Framework, and various other open source components. All software that we didn't have to write, and for which we don't pay anyone.

How do you prevent leakage and make open source more "sales-efficient" in the short-term? I've discovered a few means, and would love to hear yours, as well:

1. "Proprietary" Incentive. You must have a hook that convinces would-be customers to buy, and not merely use. Free downloads invite use, but only some proprietary (pardon the word) hook effectively closes sales. For MySQL (which, I believe, derives a massive percentage of its revenues from OEM/embedded sales), this means that it offers a clean way out of the GPL. For SugarCRM, it's the additional functionality that is commercially licensed. For Red Hat (and Alfresco now, too), it's the testing, packaging, third-party application certification, etc. that only comes with the Enterprise product.

   If you lack a hook, you may well get many users, but it will be extraordinarily difficult to beg and cajole users into becoming buyers. You don't want that fight. You want an appreciable difference between your "community" product and your "professional" product, whether that difference is in functionality, stability, or whatever.

2. Source of Code. You must have control over the code. I don't mean copyright here, but rather developers. Source of code rather than source code. Customers buy from those that write the software.

3. Partner Alignment. You must have your partners aligned with your vision. Systems integrators and others who make their money on professional services - in the proprietary and open worlds - always have an incentive to drive the cost of software to zero to make their services more appealing/less expensive. This is normal and natural. It's not, however, good for the creators of the software. Software startups don't need a huge swath of partners - they need a few hyper-committed partners with expertise and the shared vision of driving software sales (as well as their professional services engagements). The two need not be mutually exclusive. Despite #2 above, having partners support your free product erodes your ability to charge for it.

4. References. Customers talk to each other. They want to know who is paying for what. Convince one financial institution to pay and odds are that others will follow. This is not new advice - it's very much what Geoffrey Moore has been teaching for years. But it's critical in a different way in open source: you don't just want marquee buyers using your product - you want them buying your product. There's a huge difference between the two.

There are more, of course. I don't claim to have all the answers. Open source as a business is a work in progress, one that I'm very happy in which to play a part. I'd love to hear your insight.

Posted by Matt Asay on May 10, 2006 08:07 PM

RATE THIS ARTICLE: