The downside of open source (business)
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.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).
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.
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:
- "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. - 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.
- 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.
- 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.
6 comments:
I think "leakage" and "freeloaders" are the wrong terms to be using and the wrong way to think about it. Leakage implies waste, which doesn't accurately describe the situation. Users who aren't paying are not wasting the software, they just represent an opportunity the vendor hasn't capitalized on yet. If Google doesn't buy anything from Red Hat it isn't because they are "freeloading", it is because Red Hat doesn't have an offering that Google needs.
I think the best thing vendors can do, in addition to the 4 things you listed, is to sell their offering, not the software. The users are already convinced they want to use the software so its more important to focus on what value-add they are going to get when they spend money. Alfresco does a better job of this than a lot of OSS vendors where all of the focus is on the features of the software.
I know the terms "leakage" and "freeloader" have negative connotations, but the baseline denotation of them is probably accurate. I'm a freeloader on various open source projects, but happily pay for others (like Handbrake), including those that I'm not obligated to pay for. My conscience got to me. :-)
If Google didn't buy from Red Hat because "Red Hat doesn't have an offering that Google needs," then why did Google use Red Hat's code? Obviously, Google needed Red Hat. What they didn't recognize was all the work that went into creating the software (and testing it/etc.) in the first place. If Microsoft were to give away Office for free, I almost certainly wouldn't pay for it (or for support on it), despite very much needing the product. People generally won't pay for something they're not made to pay for. Human nature. It has nothing to do with value, but rather restricted access to value. (Same phenomenon in the music and movie industries right now. No one would argue that the musicians aren't providing value. But lots of people steal that value because they can.
Anyway, I think we mostly agree. It was just a hard day for me yesterday. Hard to watch a marquee customer not paying...at the end of your quarter. ;-)
Maybe Google used RadHat's code because there was little other choice - maybe they always wanted a RadHat like system, but not a Redhat like service.
I'm told that Google have now replaced alot of RH with Ubuntu, and that Google were one of Canonical's first customers (even before the rest of use knew about Warty). Google paid Canonical to port kickstart to Warty as they had a pretty complex kickstart setup for deployment.
Just a bit a techie / gossipy detail but I think it points at a potential danger in pure community project (like Linux) as opposed to company / community projects (like MySQL, Alfresco). That is you can collect custmers because your the first / biggest / 'best' but can lose them when people work out want they actually want and other companies work out how to supply it.
(If the above gossip is true) RedHat lost Google to Canonical, because Canonical offered them almost the exact same code (Linux + kickstart) for just the cost of customisation. Presuming Google and Canonical have an ongoing relationship (I don't know) it's going to be around customisation and prioritisation of components and features. That's not the business that RH are in - even though they have exactly the same (more or less) codebase.
I think that's less likely to happen where the code is controlled / managed more directly by one company (as is the case with MySQL, etc).
Oh, and sort of on the subject of helping IT managers decide how to pick amongst Open Source projects I wrote this article a couple of years ago for the NCC, and they gave me permission to publish it on our website
http://www.openadvantage.org/articles/oadocument.2005-03-10.5941460159
Paul
I view Red Hat as another example of what is called the "Gellette" or the "Epson" business model; give away the base product to hook the consumer, then charge a lot for the add-ons and consumables. Ever notice how Gellette razors are dirt cheap, but the replacement blades cost almost as much as the razor? Ever wonder how Epson could sell it's inkjet printers for practically pennies... check out the price of the replacement ink cartridges.
Businesses like Red Had and Novell which sell Open Source software operate in a similar way. They are required to provide free and convenient access to all the sourcecode of the software they market. Companies which have large and talented IT departments possess the capability of "rolling their own"... to download the sourcecode, set up a server to compile it, build all the resulting RPM's (in the case of Red Hat), and then go ahead and do the actual installations. And in the beginning, a number of companies actually did this, and got hooked on the finished product. But doing all of that work requires resources, and leaves the business with systems that have no access to any meaningful outside support.
It becomes a question of what makes good business sense. Do I want to devote staff and other resources to constantly trying to keep up to date by downloading, compiling and building new RPM's, or would I rather use those high-value resources for other tasks when I can obtain the same results (and have access to vendor support in the bargain) for the cost of acquiring a support contract? Businesses use Linux and Open Source not only because they can freely download the sourcecode. They use it for adherence to standards, arguably better security and stability, robustness, etc. Purchasing pre-packaged Linux and the included vendor support is often seen as a better decision than trying to "roll your own" when seen in the light of an overall business strategy than viewed as an isolated activity. I suspect the same holds true in the SMB space, where small and medium businesses don't have the technical resources of a Google, and can't or won't pay the Microsoft tax. Shrinkwraped Linux neatly fills the void between the two.
I was going to comment here, but it got long, so I blogged it myself.
http://stephesblog.blogs.com/my_weblog/2006/05/the_upside_of_o.html
Post a Comment