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.