Open Core is the New Dual Licensing

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Which is to say an open source business model that will generate marginal revenue improvement for firms that employ it, at the cost of developer goodwill and participation. And, potentially, distribution. What open core is not is a model that will mitigate the commercial limitations of the model sufficiently to produce outsized returns similar to historical software producers. Nor is it a model that ideally aligns customer and vendor interests.

Which is not to say that there is much profit in debating its relative merits. Curiously, precisely zero of the model’s critics – smart people, all of them – have put forward potential remedies for the threat they perceive in open core. This is because none exist.

There are precisely zero mechanisms in either copyright or licensing to aid those who would oppose the open-core model. Leaving, as far as I can determine, proselytization and competition as the two main avenues for dissent.

Those who would pursue the first course, and ride like Paul Revere warning would be consumers of the dangers of open core are unlikely to be successful. The subtle nuances of open core versus pure open source are more likely than not to be lost in translation for customers, many of whom still struggle to understand that merely deploying GPL software does not mean they need to immediately open source their internal application catalog. Worse, warnings aimed at one type of open source software are likely to be misinterpreted as dangers to all open source software. Consequently, it would be no surprise to see anti-open core consumer campaigns that produced substantial collateral damage, counterintuitively benefiting closed source software.

Nor is it reasonable to expect, even should they be able to accurately and consistently perceive the distinctions between open core and pure play projects, that customers would care particularly. Call me a cynic, but in my experience, users of commercial open source software generally care more about whether or not software solves their problem than precisely how it solves their problem. Even if their open source software isn’t really, truly open source software.

We can and do argue, of course, whether or not they should care about things like software freedoms, but they don’t, by and large. If you doubt that, ask yourself what the most popular operating systems are in the world. Or the most popular browser. Or the most popular office software. Users have shown, time and time again, very little inclination to advantage software adoption on moral, ethical or – most problematically – practical grounds. Enterprises, like governments that run up massive deficits, are ever willing to trade a problem tomorrow for a solution today.

This is lamentable, admittedly. But it is also reality.

Those who would compete against the open core model, then, would be best served by doing what they have always done: competing. The open core model, as its critics are well aware, is no panacea for open source software revenue generation. It gains an edge, to be sure – the “unfair advantage” open core defender Mårten Mickos referred to – by introducing artificial purchasing triggers. But in replicating the revenue generating mechanisms of closed source software they inevitably carry forward the model’s disadvantages versus pure play alternatives.

Historically, remember, the largest open source projects in the world have been neither open core nor dual licensed. As popular as the dual licensed MySQL database is, Linux is yet more popular still. And as commercially prevalent as open core is today, none of the products sold in that fashion are remotely as popular as the Apache web server. The largest open source commercial institution, Red Hat, employs neither the open core model, nor the dual license. All things being equal, enterprises would typically prefer the more open alternative. The trick is getting to the point at which “all things” are “equal.”

Pure play open source software is today, and always has been, more popular. Which is why I categorically reject arguments that assert that open core-style mechanisms are necessary for the production of open source software. That they are beneficial from a revenue standpoint to organizations built to monetize open source software is indisputable; but open source is, of course, not strictly or even primarily authored for purposes of sale (coverage).

The key is, as it has always been, to more correctly align the revenue generating models with the greatest strength of open source software: its distribution and ubiquity. Mårten and other open core advocates – which include many of RedMonk’s own clients, it’s worth noting – are doing little more than seeking to run the most profitable businesses they can. Which, while I do not care for the open core model, I see no reason to quarrel with, so long as its advocates respect the boundaries of the licenses they operate under. More, I would strongly defend the right for those who build open source software to pursue this model so long as customers continue to choose it, even as I personally disapprove. Because that is what software freedom means to me: the right to select the model you believe best, even I don’t happen to agree with it. As in so many areas, in this I am laissez-faire, inclined to let the market make its own bed.

My hope, and to a certain extent, my expectation, is that we will shortly see firms begin to perceive the latent opportunities Spiceworks and others have identified and profited from; the value that accrues from massive distribution. That those seeking to make money from open source software, as opposed to making money with it (coverage), will transition to mutually beneficial revenue mechanisms such as telemetry (coverage) – that we have been suggesting since 2007 or so – over asymmetric models such as open core. That we will, in short, ultimately see a decline in the usage of open core much as we’ve seen a decline in the employment of dual licensing.

In the meantime, however, I see little point in long term debate on the subject. Regardless of one’s opinions on open core, there is little that can be done to prevent it. So even those that would wish it away may as well get back to proving the superiority of their model with code, because the only people inclined to listen to debates on the viability of the model have likely already made up their minds one way or the other.


  1. […] the debate about open core, as Stephen O’Grady rightly points out, is futile. We have been over the debates about freedom many times before but ultimately, as I […]

  2. […] Core is Bad For You Open-Core: The Emperor’s New Clothes While lies beyond the open core debate? Open Core is the New Dual License The Road to Closed Source Software, Eucalyptus Marten Mickos says open source doesn’t have to […]

  3. Feels like open core is like open source with a little less trust involved – trust from the founders in letting open development happen on the core, and trust in the community that founders won’t keep back from bits that should rightfully be core. I think you’re right though, the end user probably won’t care – unfortunately the real innovation in terms of extension will likely come (along with the founders) from the community around that core and those folks are likely to be a bit more cautious.

    (btw, having had a look back through various posts on your blog, Twitter had led to a total void of good discusison – pity!)

  4. […] to be no hope of it ever reaching conclusion. This is partly because, as Stephen O’Grady notes, the anti-open core brigade have not put forward any potential remedies. Stephen argues that this […]

  5. Coming late to this discussion but I’m glad to see open core being advanced, as I believe it’s the future. I wrote an essay a little while back about the hybrid approach that I think will win out. While I was unaware of open core when I wrote it, I anticipated possible unwillingness from open source developers to participate in hybrid projects, so I put in a time limit for source to be released in my hybrid model. As for moral or ethical freedoms, that’s all hogwash and businesses are right to ignore such silliness.

  6. […] Open Core is the New Dual Licensing (redmonk.com) More Resources from TwitterBlogger:Java Server Pages: Best Choice For Web DevelopersWhat is Web Development?Behind the Scenes at Salesforce.com: Delivering 3 Major Releases a YearLamp: Adaptable And Affordable Tool For Web DevelopmentWeb Development Specialized Skills And Interacts With The Customer At All StagesPowered by Contextual Related PostsSHARETHIS.addEntry({ title: "Open Source Web Development Solutions: Complete Cover for All Your Web Development Needs", url: "http://twitterblogger.net/twittblogger-posts/open-source-web-development-solutions-complete-cover-for-all-your-web-development-needs" }); […]

  7. […] going about open core with several good insights and arguments: Simon Phipps, Daniel Radcliffe, Stephen O’Grady and our own Matt Aslett to name a […]

  8. […] The open-core muck-bucket gets tipped over. Tarus’ recent post on the topic, and also RedMonk’s Stephen O’Grady has written on it recently. […]

  9. […] have a nicely evolved open source warm-and-fuzzy feeling, at the same time being unashamedly open core. They’re all nicely earnest. (And, hey, it’s always nice to be in California to get one […]

  10. […] have a nicely evolved open source warm-and-fuzzy feeling, at the same time being unashamedly open core. They’re all nicely earnest. (And, hey, it’s always nice to be in California to get one of […]

  11. […] Core is Bad For You Open-Core: The Emperor’s New Clothes While lies beyond the open core debate? Open Core is the New Dual License The Road to Closed Source Software, Eucalyptus Marten Mickos says open source doesn’t have to […]

  12. […] with the downside of having a small to nonexistant community. (See for instance Matthew Aslett, Stephen O'Grady, or myself.) So you might think that once you just point to this statistical evidence, your future […]

Leave a Reply

Your email address will not be published. Required fields are marked *