Open source strategies
From time to time I advise a software vendor on how, whether, or to what extent it should offer its technology in open source. In summary, I believe:
- The formal differences between “open source” and “closed source” strategies are of secondary importance.
- The attitudinal and emotional differences between “open source” and “closed source” approaches can be large.
- A pure closed source strategy can make sense.
- A closed source strategy with important open source aspects can make sense.
- A pure open source strategy will only rarely win.
Here’s why.
An “open source software” business model and strategy might include:
- Software given away for free.
- Demand generation to encourage people to use the free version of the software.
- Subscription pricing for additional proprietary software and support.
- Direct sales, and further marketing, to encourage users of the free stuff to upgrade to a paid version.
A “closed source software” business model and strategy might include:
- Demand generation.
- Free-download versions of the software.
- Subscription pricing for software (increasingly common) and support (always).
- Direct sales, and associated marketing.
Those look pretty similar to me.
Of course, there can still be differences between open and closed source. In particular:
- Open source can help with sales to enterprises that don’t trust a new vendor to keep progressing.
- Open source can hurt with sales to enterprises that jump at the opportunity to do what they want, themselves, for “free” and — which in some cases is important to them — in secret.
- Open source has fewer pricing options than closed.
Summing up the story so far, then, closed source is a superior strategy to open, except and to the extent that your are forced down the open route. More precisely, any advantages to an open source strategy can also be captured by having a hybrid open/closed strategy that emphasizes the closed part.
So what part of the story haven’t I told yet? Mainly, it’s open source marketing. Open source can seem virtuous and/or cool — to users, influencers, or even your own engineers. But while that’s true of people, it’s less true of companies, which are unlikely to spend a lot of money on the basis of coolness or virtue. Rather, the strictest believers in acquiring open source software do so precisely because it’s something for which they don’t have to pay, or pay much.
Further, some people think pro bono is a business strategy, because if you build up enough users, monetization can eventually follow. In the cases of more-or-less explicit advertising, pro bono really does work. I give away the content of this blog; in return, people contact me from time to time and offer to buy my services — with “sales cycles” so short as to be unworthy of the name. Fun ensues, and profit. The connection is even clearer in the case of traditional mass media, or of internet services such as Twitter and Facebook. But when what you’re selling and giving away are both technology, the pro bono story has to be something like “We’ll get you hooked on the free stuff, then charge you for the rest.”
That may be great for games, but how does it work for professional software? There are some special cases, mainly:
- Your product can be used by awesomely impressive internet companies that, while refusing to pay for software themselves, validate it for adoption by lesser organizations that indeed are willing to pay. This has worked for multiple projects started by those companies themselves, such as Hadoop and memcached, but only one I can think of that wasn’t — MySQL.
- You can let users gain attachment to your free stuff, then sell your whole company to somebody who now wants to sell them other stuff, presumably closed source (or hardware), or who just is impressed by the awesomeness of your technology. This strategy has produced a very small number of great exits — XenSource, arguably Nicira (although Nicira itself disagrees), maybe a couple of others.
But in most cases, the strategy loops back to what I described at the top of this post:
- A free core product, which may be genuinely valuable to some/most users, and which certainly offers them a great opportunity to test the technology, plus …
- … a chargeable/proprietary add-on, which is required for the most serious work, …
- … or else just support.
There aren’t actually a lot of major examples in the “just support” camp* — the main ones who come to mind are Red Hat, 10gen, and Hortonworks, and two of those three are for products that were open source projects long before the respective companies were founded. And so we’re right back to an Enterprise Edition/Community Edition split.
*Or “mainly just support” — as per my recent post on Hadoop distributions, almost everybody offers SOMETHING proprietary.
This all still leaves an attitudinal distinction among (in decreasing order of open source rah-rah virtue):
- Build and promote a great free product. One of these years, get around to building and promoting a great chargeable one as well.
- Build and promote both a great free product and a great chargeable one.
- Build and promote a great chargeable product, and give a subset of it away for free. That subset should be good too.
- Build and promote a great chargeable product, and give a crappy subset away for free.
I think #3 makes the most sense. #4 is bad because I don’t believe in promoting or distributing crappy products even for free. #2 is too big a challenge to tackle, in technology and marketing alike. And #1 is only for the most patient vendors with the deepest of pockets.
There’s also the possibility of open sourcing software and then making your main revenue from being the best hosting company for it. But to date that has worked mainly for Automattic.
Finally — what about open source as a development strategy? Well, there are indeed some projects with multiple sets of major contributors — Linux, R, Hadoop, Postgres and so on. But for projects that originate with a single sponsoring vendor, my general observation still stands:
- Open source software commonly gets community contributions for connectors, adapters, and (national) language translations.
- But useful contributions in other areas are much rarer.
Related links
- The open/closed source distinction is central to only a few of the issues on our strategy and execution worksheets, mainly the ones influenced by pricing. However, it is at least slightly relevant to a considerable fraction of them.
- I glossed over the free-like-speech/free-like-beer distinction a bit; hopefully my usage was clear in context.
Comments
8 Responses to “Open source strategies”
Leave a Reply
The blog is generic, the consulting is specific.
Software works the same way: companies can open the generic but should keep the specific private.
Good article. I think there is another open source key, ontology. Closed source, funded, software tends to come from two sources:
– funded startups based on a perceived need and the ability to convince investors to pull the trigger
– software build for purpose spun out of companies or built and kept by consultants
Both with high bars to entry.
This creates huge gaps in what is built and supported. Open source fills part of the gap with things that developers want or think is important (e.g., VC yawned when Axmark came to visit – even with a mature product, MySQL.)
So, the primary reason for open source seems to be “the other stuff”: things for political reasons, things where the product might be a diversion from mission….
Once something is open source and has a market, there is an interesting question about what next….
[…] Open source strategies: From time to time I advise a software vendor on how, whether, or to what extent it should offer its technology in open source. In summary, I believe: […]
I think your analysis does not take vendor equity value fully into consideration. There have been a number of very lucrative sales of more or less pure open source vendors including JBoss, SpringSource, and Gluster. Gluster alone sold for something north of $130M. I would think that these vendors were all quite happy with the outcome.
Perhaps one reason the open source strategy for DBMS vendors does not look so great is that up until recently there have been relatively few of them. The current wave of innovation around Hadoop and NoSQL has a lot of open source entrants. I would bet we’ll see more MySQL-sized acquisitions in the next few years for this reason.
My last company tried a closed-source model and it should have gone open-source. We sold an embedded device database in the traditional enterprise way, with guys in suits manning phones and making pitches. The problem was that our product was deeply technical, and development engineers were the decision-makers as far as the buy decision was concerned. Engineers hate suits in general, and salespeople bothering them over the phone in particular, so getting engineers working on an embedded app to evaluate our product was almost as hard as actually closing a high-dollar sale. This up-front time and cost overhead severely gated our ability to grow and acquire customers.
Being in embedded, there were numerous products and services (porting to new chipsets, adapting to new drivers, adding app-specific indexes and datatypes, connectors to remote-hosted db’s, general consulting, etc) we could have sold around an open-source core. Sadly, our senior management was devoted to an enterprise inside-sales model, so the company didn’t make it.
My take-away from this is you have to know who the buyers actually are and what their culture happens to be. If the buyers are techies, open source allows them to download and try the product without excessive bureaucratic hoohah or unwanted human interaction. If the buyers are more senior management types, inside sales and closed source may make sense. (My current company does do inside-sales as it markets a hosted analytics product to a very different type of buyer in the financial sector, and things are going well.)
Hi Curt,
I’d like to share some thoughts since I’ve lived through a range of models (spanning fully open source, fully commercial, and open core with commercial extensions) at Princeton Softech (i.e. IBM’s Optim software), JBoss, Red Hat, SpringSource, and VMware.
Quick point is: There’s no “right” choice. The choice really depends on the software/technology and market dynamics involved among other things.
Three points you don’t touch on enough are:
1. Distribution: you mention marketing, but my point is different. At the end of the day, open source is about unencumbered distribution and access to software; so (depending on the software) pure open source will be able to be distributed and used much more than closed alternatives (by a factor of 100X and more). ALSO, you need to consider accessibility to BOTH DIRECT AND INDIRECT distribution channels.
2. Pervasiveness/Market Reach: different than distribution, this nets out to be a question of “how important will this software actually be?”. Again, you need to consider BOTH DIRECT AND INDIRECT impact on the market. The Hadoop market, for example, is projected to be large AND Hadoop’s impact on the broader big data market (hardware, software, services) has been projected by some to reach 50% influence. That’s important.
3. Clearly Distinguishing Between Pre-Chasm and Post-Chasm Adopters: You point out the risk of companies self-supporting. I do not view this as a risk at all. It’s simply the nature of the adoption curve (a la Geoffrey Moore’s Crossing the Chasm). Left-side, pre-chasm early adopters and tech enthusiasts will build and self-support. Right-side, mainstream adopters typically want to focus on their own business needs and rely on someone else to help them.
At Hortonworks, we’ve chosen a 100% open source strategy because Hadoop represents a next-generation data platform with sizable DIRECT AND INDIRECT market opportunity.
Our thesis is if we can enable the market to form (avoid fracture) AND enable a pull market with respected enterprise players (ex. Microsoft, Teradata, etc.), then the market can reach its potential.
As I said in the beginning, choosing a model/approach needs to map well to the things I point out above (and more).
The Hortonworks approach is described at:
http://hortonworks.com/community-driven-enterprise-hadoop/
Regards,
Shaun
The discussion is interesting in terms of positioning – especially for a well funded startup trying to create a strategy. My take is that for most companies it is more interesting to look at state. If you are a single person unfunded start up focusing on tech vs. marketing, there is one set of drivers that differs from whether IBM should open source zOS.
There are likely different drivers for:
– tiny, unfunded
– small (e.g., <5M revenue or <1M funding)
etc.
The other state question is where are you now. If RedHat or Hortonworks attempts to close source their product set (or MS chose to open source), it would have ownership issues, legal issues, cultural issues, as well as the marketing and sales pivot.
Fap Turbo – How Much Money Can You Make With This Robot?…
MongoDB and 10gen | DBMS 2 : DataBase Management System Services…