What is open core licensing (and what isn’t) UPDATED

This is an updated version of a post that was originally published in July 2009. It has been updated in response to ongoing confusion about open core licensing.

There has been a significant amount of interest in the open core licensing strategy since Andrew Lampitt articulated it and its benefits for combining open source and closed source licensing.

There remains considerable confusion about exactly what the open core licensing strategy is, however, which is strange since the term arrived fully packaged with a specific definition, courtesy of Andrew. Recently I have begun to wonder whether many of the people that use the term open core regularly have even read Andrew’s post.

I feel somewhat responsible for this given that our Open Source is Not a Business Model report was partly responsible for the increased use of the term open core, and since I remembered that it was this post about commercial open source strategies that prompted Andrew to define open core in the first place.

Additionally, since business models related to open source are evolving constantly, I thought it was worth revisiting the definition of open core and putting it in some context.

What is open core?
According to Andrew’s original post it is a licensing strategy whereby a vendor combines proprietary code with open source code, where “the commercial license is a super-set of the open source product, i.e., it offers premium product features that you will not see in the GPL license”.

At first Andrew was very specific about the use of the GPL license and a development model dominated by a single vendor. However, it quickly became clear that a company like EnterpriseDB, which provides proprietary extensions on top of the community-developed, BSD-licensed PostgreSQL database, also fits the general model.

Therefore, Andrew clarified that there were Vendor Controlled (VC) and Community Controlled (CC) variants on open core.

Incidentally, Andrew did not create the open core strategy. As he himself admitted, he “invented nothing, just articulated it”. Credit goes to Barry Klawans and Paul Doscher (Jaspersoft co-founders), as Andrew noted.

In fact our research indicates that the formation of companies using the open core licensing strategy had already peaked by the time the term was coined – but more on that another day.

What isn’t open core
Sometimes it is easier to define what something is by explaining what it isn’t. Open core is a commercial open source strategy, but just as “all of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan”, not all commercial open source strategies are open core (and more specifically, given recent statements, not all strategies that involve copyright agreements are open core – more on that another day as well).

So, to clear up some apparent confusion:

  • Red Hat’s strategy is not open core

Red Hat reserves support and features for paying customers, but it does not do so using closed source licensing (a prerequisite of open core). Instead Red Hat gives away the source code but withholds the compiled, binary version for paying customers.

(N.B. Beware companies claiming to be following “The Red Hat model” as they invariably aren’t – most often I find they mean that they use a subscription revenue model. Very few companies have copied Red Hat’s model for a variety of reasons – a subject I’ll leave for another post.)

  • Dual licensing is not open core

In fact, as Andrew Lampitt explained in his definition, open core is a variant of dual licensing (or proprietary relicesing, as some like to call it, or indeed “selling exceptions”). The important thing to note is that in the dual license strategy a single code base is available under an open source or closed license, while with open core the closed source licensed code is a superset of the open source code. Both result in closed source software, but only in the open core strategy is the closed source version functionally different from the open source version.

  • The MySQL strategy is not open core (yet)

One of the reasons for the confusion is that MySQL originally started out with a dual license model but changed over time to the subscription revenue model, and flirted with open core. At this point the strategy for MySQL remains dual licensing. It remains to be seen whether the MySQL Server code for Enterprise Edition 5.5 will be different from Community Edition with the inclusion of MySQL Enterprise Backup (which would make it open core) or if the new capabilities will be delivered as a subscription service.

  • Subscription strategies are not open core

Although they are a step in that direction. The subscription model provides vendors with a mechanism to distribute value-added features to paying customers. Until now the additional capabilities in MySQL Enterprise (such as Enterprise Monitor) have been delivered as a service via the MySQL Enterprise subscription. Although the code for Enterprise Monitor has not been made available, we would see this strategy as distinct from open core since open core results in a product with a different code base, where as the MySQL Server code in Enterprise and Community is the same. To differentiate from regular support subscriptions I have used the term value-added subscription to refer to this type of subscription. Other examples include Canonical’s Ubuntu Advantage and Nuxeo’s Connect. I would also put Red Hat Network and JBoss Operations Network in this category, although the source code for those value-added services was originally closed, it has now been made available as open source (as previously discussed).

  • Open foundation is not open core

Vendors such as IBM, Cisco, Oracle and SAP (in fact just about every software vendor) include open source code within larger closed source software packages and hardware products. There is a fine line between the two, but as I previously explained while open core involves offering proprietary extensions targeted at a segment of the open source project user base, open foundation involves using open source software to create entirely new products, targeted at a different user base.

  • Microsoft’s open source strategy is not open core

Microsoft is undoubtedly making use of more open source and encouraging open source development on its platforms, but its strategy is by definition not open core since it is extremely unlikely the core will ever be open source. In fact, as previously discussed, Microsoft’s strategy turns the open core strategy on its head by encouraging open source development around a commercial core, and has been described by Microsoft as open edge, and by Andrew Lampitt (more amusingly) as open crust. We have adopted the term open edge to describe this strategy and have seen it adopted by a small number of players beyond Microsoft.

Embedded open source spreading, opening

The action continues around Linux and open source in the embedded software space, where this week we are hearing that MIPS Technologies, a provider of processor technology for a range of networking, mobile, consumer and other devices, is open sourcing its port of the Linux-based Android OS software. MIPS announced its port of Android, a product of Google and the Open Handset Alliance, two months ago, and now says it is making source code available under the open source Apache 2.0 license. It is also initiating an Early Access Program of hardware and code optimizations for a few key customers, which will be announced later. This last part may seem somewhat antithetical to open source, but it may also serve to provide the early direction and structure to foster a useful open source software community, provided the source code is actually publicly available under an OSI-approved open source license.

Why is MIPS Technologies doing this? We can look largely to its giant processor competition, Intel, which also expanded its footprint in the embedded software and device market with its $884m acquisition of Wind River in June 2009. The MIPS move is also another instance of a hardware player becoming more empowered and in control of its own destiny, devices and applications by using open source software as the vehicle (which is another big part of this market). As Linux and other open source software and development free these vendors from the OS licensing, roadmap and development constraints of proprietary software, we should expect to see more of this kind of consolidation and code.

Indeed it is part of closer partnerships, consolidation, mergers and acquisitions we see happening in this space, largely as a result of Intel-Wind River and momentum for Android and other Linux and open source software. The recent acquisition of Linux specialist Embedded Alley by Mentor Graphics only serves to reinforce the idea that although Linux continues to be somewhat fragmented, it is also currently serving as a federating force in embedded software.

We do expect continued uptake and traction for Linux and open source software in mobile and embedded devices — which range from mobile devices to industrial uses to the wired home, to which MIPS makes reference. We also applaud the move from MIPS Technologies. However, we would add the caveat that mixed licensing, commercial licensing and the need for both revenue and control of software and devices in embedded markets often results in code that is closed or practically closed to users, as detailed in our CAOS report, Mobility Matters.

Also, while embedded Linux, Android, Maemo, Moblin and other open source software efforts are attracting the attention, partnership and investment of larger vendors that have long played and succeeded in embedded device markets, it also continues to hold implications, and perhaps opportunities, for Linux and open source savvy players, particularly IBM, Novell and Red Hat.

We will be staying tuned to this space and what’s happening with Linux and open source software, which continues to play a bigger role in the latest and greatest devices.

On open source business strategies (again)

I mentioned last week that the debate about open source business strategies had reared its head again thanks to posts by Dave Rosenberg and Michael Coté (twice) – not to mention Matt Asay and Tarus Balog.

While I am at risk of repeating myself, there are a couple of points I wanted to make.

In our report, Open Source is Not a Business Model, we noted that there are over 300 different theoretical combinations of development model, vendor licensing strategy and revenue trigger associated with open source business strategies and that the 114 vendors assessed were utilizing 88 different combinations.

I believe that in order to properly assess a company’s business model as it relates to open source it is necessary to examine its strategies in this level of detail. However. for the purposes of this debate it is possible to group the vendors together into three broad categories (and while it should perhaps go without saying I will say it anyway: I am generalising here):

Pure open source
These vendors use only open source software licenses and generate their revenue via services, support (both ad hoc and subscription-based), customisation, and training. The rejection of traditional licensing is based either on the philosophical position or because it suits the overall business goals (or a combination of the two).

Because start-up and development costs are low these vendors can quickly achieve break-even, although scaling the model is tough and revenue growth levels are likely to be below those delivered by traditional software licensing methods. Because of this many venture-backed vendors building open source support businesses have looked to hybrid models to deliver the returns they are looking for.

This does not mean that the pure open source model is broken or that it has failed, but it does mean that, for the most part, it is incompatible with venture capital investment strategies. (I have a great statistic that backs this up, but you’ll have to wait for the next CAOS report, due in April).

As Tarus Balog notes, “For those companies trying to make billions of dollars on software quickly… the only way to do that in today’s market is with the hybrid model where much of the revenue comes from closed software licenses.”

Hybrid open source/commercial licensing

Many vendors trying to build fast-growing businesses based around open source software have turned to commercial licensing, either via dual licensing strategies that see proprietary licenses used for ISV and SI partners, as well as wary corporate clients, or via the Open-Core approach, making additional services, features and functionality available to paying customers using SaaS or proprietary licensing.

As the underlying software is open source, I personally would consider these vendors to be “open source vendors” although I do also have a lot of sympathy with people like Tarus Balog who consider it a misuse of the term “open source” given that the software and services that drive revenue are traditionally licensed.

The term “Open-Core” has been widely adopted since being coined by Andrew Lampitt in August last year to describe the use of proprietary extensions around an open source core, not least since it enabled vendors to avoid terms such as “bait and switch”. However, one of the issues related to hybrid approaches is that vendors often talk up the benefits of open source licensing in delivering freedom from vendor lock-in while all the while the core enterprise features customers are paying for are delivered using the same proprietary licenses they are supposedly trying to avoid.

I do believe that the Open-Core vendors have the best intentions, and the model does effectively separate community users from commercial customers enabling vendors to focus on the needs of each. However, it also brings its own problems, such as balancing what functionality will be available in the enterprise or community versions, and means that the vendor does not enjoy the full benefit of open source lower development and sales costs. And it can be confusing.

The Open-Core approach is mostly (though not exclusively) used by vendors that dominate their own development communities. While this provides benefits in terms of controlling the direction of development and benefiting from the open source distribution model there are also risks involved with promoting and managing community development – or not. In fact, many of these companies employ the majority of the developers on the project, so they are actually missing out on many of the benefits of the open source development model (more eyeballs, lower costs etc).

Additionally, by providing revenue-generating features on top of open source code, Open-Core vendors are attempting to both disrupt their segment and profit from that disruption. I previously argued that “it is probably easier in the long-term to generate profit from adjacent proprietary products than it is to generate profit from proprietary features deployed on top of the commoditized product.”

While Open-Core is definitely the commercial open source strategy of the day and is effective in building the revenue growth required to fuel an exit strategy, I have my doubts as to whether it is sustainable in the long-term due to a combination of the issues noted above.

Embedded open source

I was recently asked to explain the difference between the terms Open-Core and Embedded Open Source as used in Open Source is Not a Business Model. I’m the first to admit that there is a fine line between the two and it isn’t always to distinguish, but essentially Open-Core sees proprietary extensions build on top of open source code, while Embedded sees open source code embedded in a larger proprietary product – be it hardware or software. Prime examples of the software approach are IBM’s use of Apache within WebSphere and Actuate’s use of BIRT within the Actuate 10 portfolio.

To my mind this is a cleaner distinction than the Open-Core approach and one that is more sustainable in the long-term. If a user wants the freedom and flexibility of the open source approach then BIRT is freely available, and Actuate will gladly sell you support services to help, but it is not out there trying to sell adoption of the open source approach in order to sell Actuate 10.

Likewise IBM’s support for Apache helped to disrupt its competitors in the web server market but IBM wasn’t trying to sell customers value-added Apache services – it was selling other products and services that made use of the web server.

As previously mentioned, just about every software vendor in the industry in benefiting to some extent from the use of open source software. The trick is to maximise the benefits while reducing the risks and in my opinion the embedded model does this better than the Open-Core approach.

One of the reasons for this is that it sees vendors engaging with existing development communities (such as Apache and Postgres) or starting vendor-based communities (such as Eclipse and Symbian) which enables them to benefit from lower development costs, shared resources, many eyeballs etc for non-differentiating features while focusing their attention on value-add features and functionality. This can be done in a vendor-owned open source project, but it is much easier to be part of an existing community.

What about Red Hat?
So where does Red Hat fit in to all this? Surely it disproves the contention that pure open source doesn’t scale, or that the hybrid model is the most appropriate for achieving exit-strategy revenue growth, or that embedding open source within proprietary products is the long-term future of commercial open source.

Well yes and no. The more you look at open source business strategies the more you realise that Red Hat is the exception rather than the rule. If you talk to any open source related vendor they will praise Red Hat’s pure open source strategy but how many of them are attempting to replicate it? Very few.

I believe the success of Red Hat’s strategy may be unique to the Linux distribution business based on a combination of complementary factors including: the fact that the company engages in both an existing developer communities (Linux kernel, GNU, et al) and its own (Fedora); the fact that the company’s products appeal both to technology-loving individuals and huge corporates; brand; customer services; good leadership; pioneering entrepreneurs; the impact of the dot com boom; and a clever licensing tactic that is the closest you can get to proprietary while remaining true to the GNU GPL.

Making money from open source

So how do you make money from open source? Support and services will get you so far, and for many vendors that is far enough to build a long-term sustainable business. Proprietary services and features will get you a lot further, and will provide the growth necessary to reward investors via a lucrative merger or acquisition (and potentially IPO although that’s largely unproven at this stage). In the longer-term my suspicion is that the vendor-dominated hybrid model will give way to the vendor community-dominated embedded approach.

Commercial open source business strategies in 2009 and beyond

The future of commercial open source software lies in commercial licensing strategies, but which are the strategies that are more likely to deliver the results vendors are looking for?

Much of the open source blog chatter over the Christmas period was related to open source business models/strategies, largely triggered by a post written by Dave Rosenberg in which he declared that commercial licensing, and specifically open core licensing will be all the rage in 2009:

    “Typically we now see an “open core” freely available with “exclusive” or proprietary features only available when you pay. If you are trying to build a commercial business on top of an open source project, this is likely the right answer.”

During 2008 it became clear that the open core approach – in which the core software is open source while an enterprise version is also available with proprietary extensions – has many benefits for vendors of open source software, including providing up-front revenue and in balancing the requirements of community and enterprise users.

As Matt Asay wrote recently, the result is that the line between open source and proprietary vendors is beginning to blur:

    “Open source needs some hook – however mild – to encourage prospects to pay, thereby earning a reasonable return and justifying further open-source development. Proprietary companies, for their parts, are looking to open source as a new distribution channel for their products, plus want to tap into the development benefits open source can afford.”

Proprietary vendors tapping into the benefits of open source development tend to generate revenue from other products or embed open source within larger commercial products, rather than building proprietary extensions on top of open source (think of IBM’s use of Apache within WebSphere).

Clearly there is a fine line between the two (one takes a bottom-up approach to commercialization, the other is top-down), but the two commercial open source business strategies that I expect to show significant growth in terms of usage in the next couple of years are Open-Core and Embedded open source.

    Note: That does not mean that support and subscription-based strategies are going away any time soon. Subscription remains one of the most popular open source revenue drivers and will continue to be the bedrock of open source revenue, while ad hoc support will remain the long tail of open source revenue and will continue to drive good revenue for smaller open source support specialists.

    The move towards more commercial revenue strategies should also not be seen as some kind of failure. Open source is not broken, and has not failed, but success has been redefined based on commercial reality rather than theoretical ideals. In fact the growth of embedded strategies around open source software shows how pervasively successful open source has been as a development model.

Open-Core
As we saw in our report, “Open Source is Not a Business Model“, Open-Core licensing is already a popular licensing strategy – used by 23.7% of the 114 vendors we covered.

It is more likely to be used by vendors that dominate their own open source projects (such as Talend, xTuple and Zenoss) although EnterpriseDB is an example of Open-Core built around community-developed open source software.

I previously noted that Open-Core licensing was a key element in the Extension Age, the fourth of five ages of vendor-led open source revenue strategies.

Given that there are a large number of smaller vendors making their way through these five ages we can expect Open-Core to be a significant strategy for vendors that dominate their own project communities for the next few years.

However, just because Open-Core is a popular answer, does not mean it will be easy. As previously noted, it does bring its own problems, such as balancing what functionality will be available in the enterprise or community versions.

As Carlo Daffara put it:

    “The model has the intrinsic downside that the FLOSS product must be valuable to be attractive for the users, but must also be not complete enough to prevent competition with the commercial one. This balance is difficult to achieve and maintain over time; also, if the software is of large interest, developers may try to complete the missing functionality in a purely open source way, thus reducing the attractiveness of the commercial version.”

To put it another way, I previously noted that with the Open-Core approach the open source disruptor is disrupted by its own disruption and that in the context of Christensen’s law of Conservation of Attractive Profits it is probably easier in the long-term to generate profit from adjacent proprietary products than it is to generate profit from proprietary features deployed on top of the commoditized product.

Open-Core also theoretically contradicts one of the claimed benefits of open source software: that of eliminating the upfront licensing cost while replacing the ongoing maintenance cost with a subscription-based support contract.

This is evidently not much of an issue for CTOs in practice, however, if Matt Asay’s recent experience at New York CTO Club is anything to go by. What he heard from the assembled CTOs indicates that are happier to make a monetary contribution than a code contribution to the underlying open source software:

    “Many indicated that it’s too hard to contribute back to open-source projects due to internal legal issues and the high bar to knowing how to contribute. They suggested that they would instead prefer to pay the open-source companies to do that work for them.”

However, the vendor misses out on the benefits of lower development costs and wider testing enabled by open source development while Open-Core is also potentially confusing to both the vendor and its customers.

That is why I placed the Embedded Age further along the evolutionary scale as a potential fifth age of vendor-led open source revenue strategies in the diagram above.

Embedded open source
An embedded open source strategy is often used by proprietary vendors to lower development costs while tapping into the experience and expertise of a wider community. Examples include IBM’s use of Apache and Actuate’s use of Eclipse BIRT. In Open Source is Not a Business Model, 11.4% of the 114 vendors covered were using embedded software as a revenue strategy (while 13.3% were using open source embedded in hardware products).

However, that report just looked at open source specialists, and the use of this strategy is more widespread. Almost every proprietary vendor in the technology industry is somewhere on the five stages of community open source engagement.


(Based on a graphic used by The Eclipse Foundation and research done by Carleton University and Nortel. For more see this post).

It is based on the widespread use of open source code beyond open source specialists that I believe the Embedded strategy may well be more significant than Open-Core in the long-term. To put it another way, if Open-Core was a significant revenue strategy of open source 3.0 (vendor-dominated open source projects such as MySQL, JasperSoft), then Embedded is one of the commercial open source strategies of open source 4.0 (vendor-dominated open source communities such as Eclipse, Symbian).

Glyn Moody predicts the increased influence of open source foundations in 2009, although refers to the likes of Mozilla and Gnome. I believe we will see the increased use of foundations that follow the Eclipse model in 2009 and beyond as vendors look to collaborate on the creation of nondifferentiating code in order to cut development costs while focusing their research dollars and euros on value-add products and services.

Matt Asay (again) recently speculated whether open source foundations might provide a potential exit for open source specialists.

    “What would happen… if the industry had a mechanism for allowing interested corporate parties to provide an exit for Project X’s (or Company X’s) core team? Instead of selling to one company, in other words, Project or Company X would sell to the industry, as it were, and would become Foundation X, with its value would becoming industry property.”

Matt points out that it would seem unlikely that an industry sector would spontaneously coordinate such a transaction. However, as Nokia’s purchase of Symbian and the creation of the Symbian Foundation has shown, it only takes one vendor to act as a catalyst.

Although The Acquisition Age is offered as an alternative to The Embedded Age in the chart above, the fifth age of vendor-led open source revenue strategies may well be a combination of the two.

I certainly expect to see more vendor-dominated communities created as vendors seek to use “The Law of Conservation of Attractive Profits” as a strategic competitive weapon with which to undermine rivals and boost revenue generation opportunities.

While larger vendors have tended to form foundations around previously-proprietary code it is not unreasonable to think that open source specialists could also provide attractive acquisition targets for the same purpose.