Cutting into open source business models with a sharp knife and a squeeze

There was a guy on TV (and unfortunately I've forgotten his name) who does crisis management and peace negotiations. You know, mediating when two countries or tribes have been at war. At the opening of peace negotiations he would usually tell the following story:

Imagine that you're in the middle of a big fight between women from two villages. The fight is about the fact that they've found one orange, and they are arguing about how to split the orange. You can come up with many rational rules for how to split. The simplest is to divide it en two equal halves. But then, maybe the other village has more children so therefore they'd like a larger piece, so all children get an equal slice. Maybe the woman who originally found the orange wants to claim a larger share. So between all these conflicting views, they try to reach a compromise. In the end, nobody is really happy, but they split the orange, go home, and just wait for the next conflict to arise.

But suppose instead that a young girl comes by, suggests that instead of splitting the orange in two parts, they'd rather squeeze the orange into juice, add water and tea leaves and spices to make a nice coctail in a large bowl, then take the peels and smash them to make marmelade, and finally use the seeds to plant new orange trees! All the older women agree that this is a great idea and work together on the coctails, marmelade and trees.

Matt Aslett yesterday returned to the theme of "Control and community" - the title of the 451 Group report on open source business models last year. It's a great and insightful report which I recommend you to read.

As much as I think Matt is correct in his analysis of where the problems are, I think his advice focuses on where the businesses engaging with open source communities should split the orange. And for the uninitiated: the background to the whole problem is (mostly, but not only) the desire of many startups to practice the so called open core model, trying to appeal to the open source community, while actually wanting to sell closed source software. It's easy to see how such conflicting goals will result in a very narrow margin of "window of opportunity". If one is to be found at all!

Usually when I've adviced startups, while I've never actually used the story above, my advice is the same: Try to rethink what you're really trying to do. Closed source software is the model of the 80's. It worked out great for Apple, Microsoft and Oracle and they are still today the most profitable software companies in the world. But if you want to pursue a closed source strategy, then don't make open source communities your primary target market! Even if closed source software has been going out of fashion as a megatrend, if you want to do just that, there are still plenty of small and large niches where that strategy seems to work just fine: Industrial automation and control, game consoles and other gaming... and I don't know... space travel?

But if you want to engage with the open source community - and there are good reasons you should - then my advice is to rethink your strategy. Trying to pass as open source when you're not, will be even more of a disaster than the gay guy trying to look straight. (In fact, I kind of understand those guys, especially if you live in some parts of the US or Asia.)

When the answer is to "think different", then of course "different" can mean different things for different businesses. But to just give the most obvious example: data. Google was launched in 1998 and ever since the value has not been in the code, it's been in the data. Sure, Google's code is also proprietary, patented and secret, but really: If you had a copy of Google's or Facebook's source code, would that make you successful? And speaking about control and community: These guys can both see and control vast areas of the private and most intimate aspects of my life. Keeping some small piece of your software code secret is nothing compared to this!

Unfortunately when the young girl opens her mouth, it isn't always the case that the elderly women, the executives and business angels listen. You'd think that 13 years into the era of Google, people would understand what she's saying. Even Matt, who is one of the (or just "the"?) leading and most up to date analysts on open source business models, will advice them to just find a sharp knife and listen to his advice on where to cut.

Luckily there are exceptions. Recently I was helping out a startup and even if we had to repeat this discussion a couple times, at least they were willing to listen. In the end they realized that the strategy and new features I was suggesting had really nothing to do with open source or open core, but were in fact great improvements in usability of their services, quality of advice they could give to customers, and level of automation (and hence: profit margin) of their product. It even resulted in rethinking services to potentially involve less travel - a big plus for employee satisfaction!

Understanding how to derive value from data is perhaps still a bit too scientific, and maybe that's the reason such companies are the exception rather than rule. But it's nice to know they exist. Most startups fail anyway - my bet is always that those that have a clue are the ones to succeed.

Update: I got inspired to create my own version of Aslett's diagram to illustrate my point of avoiding the narrow window and focusing on bigger and less controversial opportunities:

Hi Ingo,

Great post - interesting analogy and thanks for your kind words. One thing though:

"Even Matt... will advice them to just find a sharp knife and listen to his advice on where to cut."

Actually I wouldn't. Contrary to what what people seem to think I do not recommend the open core model (although I don't dismiss it out of hand either). To use your analogy I see the vendor as the girl - who is trying to corral the various people in certain direction to everyone's benefit.

The story above relies on the assumption that everyone agrees that making a cocktail is a great idea, and just gets on and does it. It seems more likely that there will be disagreement about what ingredients should be used to make the cocktail - who is responsible for the cocktail, the marmalade and planting the seeds.

So it is finding agreement on all these issues that is the small window of opportunity - not deciding where to cut the orange. I do not see finding that window of opportunity as an adversarial issue - it is something to be negotiated between all parties.

Where the window of opportunity is missed - as critics of open core rightly point out - is when the vendor is more interested in its own benefit than the the community as a whole (or does not see that helping the community also benefits itself).


Actually, even if I bypass that in this post, I have taken note you don't recommend or even talk about open core much in your recent post or even generally. I think the more general framework of "Control and Community" is quite relevant and not only specific to open core. As an example, yes, OpenStack was created much in response to Eucalyptus being open core. While OpenStack is not open core, it has suffered from its own issues about control, unfulfilled promises in that area, and conflicts in its community.

Still, the narrow window of opportunity in the graphic in your post provoked me to drum my countering (or maybe complementing?) message once again. In fact, it inspires me to draw my own picture, hold on...

Add new comment

The content of this field is kept private and will not be shown publicly. Cookie & Privacy Policy
  • No HTML tags allowed.
  • External and mailto links in content links have an icon.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Each email address will be obfuscated in a human readable fashion or, if JavaScript is enabled, replaced with a spam resistent clickable link. Email addresses will get the default web form unless specified. If replacement text (a persons name) is required a webform is also required. Separate each part with the "|" pipe symbol. Replace spaces in names with "_".
About the bookAbout this siteAcademicAmazonBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube