Like FOSS fog, cloud confusion may not matter

The general public knows little about the true technology fundamentals of cloud computing, suggests a recent survey commissioned by IT vendor Citrix. Almost a third of the roughly 1,000 U.S. adults polled thought cloud computing was related to weather.

However, the ascendance of Linux and open source software 10 years ago demonstrated that everyday people do not have to understand, appreciate or knowingly participate in a technology in order to leverage it in their lives.

Read the full article at LinuxInsider.

Economy up or down, can open source come out on top?

We’ve written about how a bad economy is indeed good for open source software. We’ve also recognized that with open source software’s maturity and place at the enterprise software table, a bad economy can be a double-edged sword for open source since the failure or fade of large enterprise customers, say big banks, hurts open source vendors right alongside traditional software providers.

What is interesting is that after a couple of years of economic rebuilding, we’ve seen recently how open source is being driven by innovation, particularly in cloud computing, where open source is prevalent and disruptive, and also mobile computing, which continues to be impacted by openness.

Given recent economic developments around the globe, I’m wondering whether we may see a return of cost as the main driver and benefit of open source software in the enterprise. Recent conversations with vendors and customers illustrates the fact that the motivation for adopting open source is not always the main benefit from open source. For example, open source users and customers identified cost as the main reason for adopting open source when we asked more than 1,700 of them two years ago. However, when the same group was asked what was the main benefit from open source, the top pick was flexibility. We also saw dramatic increases in factors such as performance and reliability when comparing drivers for adoption and benefits from adoption. Still, just as we’ve seen unpaid community Linux lead to paid subscription Linux and also paid Linux lead to more unpaid community Linux use, it can go both ways with open source advantages, as well. One recent conversation with an up-and-coming, open source-centered vendor in the NoSQL space highlighted how many large enterprise customers are deploying open source in divisional, departmental, pilot and other limited form to replace traditional databases primarily for flexibility, performance and similar reasons, but finding the cost savings to be significant and worthy of wider deployment.

This begs the question whether open source software, driven by its myriad of advantages for different contexts, finds a way to win regardless of whether economic conditions are good or bad? There’s no question open source has displayed staying power throughout both. We should also point out that these advantages and factors end up putting a lot of pressure on open source software development and projects, given there are inherent expectations of cost-savings, flexibility, speed, performance, scalability, etc. As we’ve highlighted recently, open source is not always the correct route for enterprise ogranizations. However, we do believe that if done properly, open source projects and communities can and do deliver benefits that enable both providers and consumers of technology.

Similar to sales and marketing, longevity, economic and developer opportunity, open core, etc., it all boils down to the community, which in a good economy tends to drive innovation and value or in a bad economy serves as a source of cost efficiency, savings and survival. That is, of course, if the community is properly supported in code, cash, contributions and stewardship that still allows open source to do its thing.

Control and Community – and the future of commercial open source strategies

Based on our ongoing analysis of open source-related business strategies it has become clear that maintaining a balance between control and community is the key issue facing vendors attempting to generate revenue from open source software.

That is why we chose Control and Community as the title of our latest CAOS report on the evolution of open-source related business strategies.

The report is the culmination of two years’ worth of analysis and research following the publication of Open Source is Not a Business Model in 2008 and builds on that report with an expanded analysis of the five elements influencing open source-related business strategies: software license, development model, copyright ownership, product licensing, and revenue generator.

The report includes the analysis of the open source-related strategies of 300 software vendors and subsidiaries, as well as a survey of 286 open source software users, evaluating their perspectives on the various open-source-related strategies. It also provides the evidence to support our recent assertions about the arrival of the fourth stage of commercial open source.

By plotting the strategies used by the vendors analyzed in this report against the year in which they first began to engage with open source projects we are able to get an approximate view of open source-related strategy changes over time. The results are intriguing.

We found, for example, that the formation of vendors using key strategies of vendor-led open source projects has declined in recent years, while vendors using strategies associated with community-led open source projects have been increasing since 2002.

Specifically, we discovered that the formation of companies using vendor-owned copyright and open core licensing peaked in 2005 and the formation of vendors using strong copyleft licensing, cathedral development, vendor-led development, dual licensing, closed source licenses peaked in 2006.

In comparison, the formation of vendors using the strategies associated with multi-participant open source projects has been increasing since 2002 (non-copyleft licences, distributed copyright ownership), 2004 (single open source licensing), 2006 (community development model), and 2007 (bazaar development model).

By grouping the 300 vendors assessed into three groups representing open source distributors, single-vendor open source and multi-vendor open source/proprietary distributors, it is possible to get an overall picture of commercial open source strategy usage over time.

(A companion chart showing absolute numbers on the Y axis for context, is here).

As can be seen, while the strategies associated with open source distributors dominate among companies formed between 1992 and 1999, the strategies associated with single-vendor open source are dominant among companies formed between 2000 and 2005. We have seen an increase in the formation of vendors using the strategies
associated with multi-vendor open source and proprietary distributors since then.

Our analysis also enabled us to compare open source-strategy usage with the strategy preferences of open source software users, proving some assumptions, such as the fact that vendor-led development, cathedral-style development, vendor-owned copyright, strong copyleft licenses, closed source software and open core licensing are all over-utilized by open-source-related vendors.

In comparison open foundation and open complement licensing strategies are relatively underutilized, along with non-copyleft licensing, bazaar development, foundational copyright ownership, and single- and multiple-open source licensing, as well as support subscriptions, value-added subscriptions, service/support and custom development.

The report also examines how proprietary software vendors have recognized that the true benefit of open source software is not only in disrupting markets through open source software licensing, but also through collaborating with partners, customers, and even competitors on non-differentiating features (something that many so-called open source specialists have failed to do) while continuing to generate profits from complementary products elsewhere in the value chain and also retaining their influence with those responsible for software purchasing.

Our conclusion, based on all the evidence, is that the software industry has entered the fourth stage of commercial open source business strategies, characterized by a shift away from projects controlled by a single vendor and back toward community and collaboration.

There is an increased focus on open source as a development model for the creation of software to be monetized indirectly, rather than a licensing strategy to spread adoption for direct monetization.

Our recommendation is that vendors that control open source projects need to transition toward more collaborative development in order to prove that they are more than just another software vendor that happens to release software using an open source license.

The report is freely available to CAOS subscribers, while non-clients can purchase it separately or apply for trial access. More details are available here.

Please break our open source business strategy model

UPDATE An updated version of the business strategy framework can be found here. UPDATE

Last week I presented “From support services to software services – the evolution of open source business strategies” at the OSBC event in San Francisco.

The presentation was effectively a work in progress update on our research into the various strategies employed by technology vendors to generate revenue from open source software.

It included a partial explanation of my theory that those strategies do not exist in isolation, but are steps on an evolutionary process, and also introduced our model for visualizing the core elements of an open source-related business strategy.

I provided a number of examples of how the model could be used to compare the strategies of various open source businesses. Here, for example, is the visualization of MySQL’s strategy.

I was pleased with the response to the presentation, not least the number of people who asked us to send them the slide so they could fill it in for their company and send it back to us.

This is definitely something we would like to do in the future but before we do I would like to ensure we have dealt with any problems related to the model. For now I would be more interested in hearing from companies that feel their strategy is NOT covered by the model.

As Jack Repenning has pointed out, the model does not offer the granularity to express some of the nuances of the various “open complement “ strategies where open source code is not monetized directly but via complementary products (and in my own presentation I had to go beyond the model to discuss “open inside” – building proprietary products on open foundations, and “open edge” – using open source to drive innovation on top of a closed platform).

My initial feeling is that there will always be a level of detail that cannot be expressed in a simplified model such as this, although if I can build them in I will.

The development model category also needs some tinkering, not least to cover “gated community” approaches.

Additionally, of course, the model is not great when it comes to multi-product companies (although multiple models can be used to explain a larger strategy).

So anyway, if you think your company does not fit our model, do please tell us how. To help you understand how the model works, here’s a quick user guide and glossary of terms.

Revenue triggers:
These are the things that paying customers actually pay money for (apart from advertising which is an indirect relationship). They should be pretty self-explanatory. When we refer to “support services” we mean support, training, consulting, implementation services etc. “Software services” refers to SaaS and cloud delivery. Vendors can have multiple revenue triggers for a single product.

Software license:

For the purposes of this exercise we are interested in whether the company has a preference for permissive or reciprocal licensing for the underlying open source project, or uses both.

End user licensing:
What licensing strategy is applied to the product that customers pay for (as opposed to the project that it is based on)? It could be the same open source license (single open source) or a combination of open source licenses (assembled open source). It could be that the same code is available using open source and commercial licenses (dual licensing) or that commercial extensions are available (open core). Alternatively, a vendor may not monetize the open source project itself, but offer complementary software or hardware products (open complement), or may turn the open source code into a fully proprietary product (closed). Pick one.

Development model:

This requires a two-part response. Is the open source code developed in public, in private, or a combination of the two (public/private)? Pick one.
Is the development effort dominated my employees of a vendor, or the result of true community collaboration, or an aggregate of multiple projects? Pick one.

Who owns the copyright for the open source code? Is it the vendor in question, a foundation, a distributed collection of companies/individuals, or another company (withheld)? Normally this would be a matter of picking one of the four options, although if a portion of the copyright is withheld, that could be used along with one of the other three.

Do your worst.

Copyright/left at the centre of open source business strategies

Below is a rough draft of the cornerstone slide for a new presentation deck I am putting together to explain the various business strategies for monetizing open source software. The aim is to explain every single existing strategy using the elements on this one slide (although I am yet to test it out).

In our previous discussions about business strategies we have noted that there are four elements that shape a business strategy around open source software: the open source software license; the development strategy; the end user license strategy; and the revenue trigger.

As can be seen from the slide above, I have added a fifth element: copyright control. Copyright was previously considered in our research around business strategies but was seen more as an underlying influence than a distinct strategy element.

I have recently come to the realisation that copyright control is not just a part of each of the four elements, and not just a fifth additional element, but should perhaps be considered the central element which profoundly influences the other four.

Copyright control has a symbiotic relationship with both the open source software license (I’ll leave the copyright/left discussion for another day) and the development strategy, and is influential in determining both the end user license strategy and therefore the choice of revenue trigger.

This has become abundantly clear thanks to the discussion surrounding Oracle’s acquisition of Sun and MySQL.

Back in September I speculated that it was copyright, and not licensing or market share, that was at the centre of the European Commission’s concern about Oracle’s future ownership of MySQL:

    “I would argue, that Oracle’s potential control over MySQL is not about licensing, but copyright… copyright ownership does not just impact the ability to license code, it also provides control over potential commercial uses of that code. This is where it could be argued that the EC could be right to have anti-competitive concerns over Oracle’s future ownership of MySQL.”

This week’s comments from EC spokesperson Jonathan Todd confirmed my suspicions:

    Todd said Tuesday that Oracle would become the exclusive holder of the copyright and trademark for MySQL code “which means that despite the fact that MySQL is open source, it could be very difficult for a competitor using MySQL code to sufficiently replace the competitive constraint” that MySQL places on database rivals. The commission is concerned that Oracle could refuse to license MySQL to some companies or for some uses in order to favor its own software. “Just because MySQL is open source, does not mean that if you want to apply it in the commercial context, that you can do what you like with it,” Todd said.

Which is not to say that I agree that there is enough competitive threat to block the deal. But it has highlighted the importance of copyright control in terms of business strategies around open source. As John Mark Walker noted recently:

    “The remarkable thing about the Oracle – MySQL case is that it forces us to put up or shut up in a realistic, fact-based way not clad in ideological robes. Whatever your opinions, you now have a test case against which to apply them.”

Strategies for creating business opportunities based on open source software

(Or: Not open source business models)

A year ago this week I completed work on our Open Source is Not a Business Model report. The report and its findings have been very much in my mind this week however, as I presented some of the findings to an event organised by Intellect in London yesterday, and due to Stephen Walli’s posts presenting open source business tactics in one slide, and arguing that there is no such thing as an open source business model.

I was reminded that when we published our report its title was seen by some to be highly controversial. That was not our intention – indeed I saw it as a simple statement of fact based on our research findings – but has been interesting during the year and at yesterday’s event to see how the idea has now become widely acknowledged to be true. (I am not saying that it all down to our report, by the way, I think we were somewhat fortunate in that our timing coincided with a wider realisation that references to “the open source business model” were confusing and inaccurate).

I first noticed the tide had turned at OSBC in March when Red Hat CEO Jim Whitehurst declared “there is no open source business model”. This was significant, not just because of the status of Red Hat and Jim, but also because it directly contradicted Michael Tiemann’s earlier claim that Red Hat acquisition Cygnus had created “the open source business model.” (Believe me, contracting Michael was not something I took lightly when putting together the report, although given that Cygnus was the first open source software vendor, his statement was valid at the time).

As I noted in the tweet about Jim’s statement, I had originally wanted to call our report “there is no open source business model” – a statement that Stephen Walli repeated in his post yesterday. The title was rejected by our editors, however, on the grounds that it was improper use of the English language.

I am very glad that they took that decision, because in hindsight the statement “there is no open source business model” would have been inaccurate in the context of our report. We identified that there are multiple models used to build a business around open source: theoretically hundreds.

The way we came to this conclusion was by realising that a business model based around open source software is not a stylized single entity (“the subscription model”, the “dual licensing model”) but a combination of the open source software license for a specific project (the choice of which may or may not be the vendor’s decision) along with three factors that were more often that not at the vendor’s discretion:

1. the product development model
2. the vendor’s software licensing strategy
3. the revenue trigger

An explanation of these and the classifications that we came up with can be found here.

In arguing that “there is no such thing” as an open source business model, Stephen argued that none of the tools or strategies used by vendors to make money from open source are unique to open source.

I would agree with this. If you look at our list of revenue triggers (the things the customer actually pays money for such as commercial license, SaaS, service, custom development) none of them are specific to open source. However, when you look at the development models (vendor, community, mixed and hybrid) and licensing strategies (dual-licensing, Open-Core, assembled open source etc) these are definitely unique to open source. That is to say that open source development and licensing create unique challenges and opportunities for vendors looking to build businesses around open source software.

Stephen writes: “Open source software is a key economic driver from an engineering efficiency and software reuse perspective, but it also opens new opportunities and additional tools for product management to engage better with customers and improve both the top line and the bottom line.”

I agree, but would argue that vendors need to put strategies in place to deal with those opportunities and tools that that are different from the strategies used with traditional software development and proprietary licensing.

It could be argued that the combination of those strategies within a company that has been set up specifically to build a business around open source software would result in what could be referred to as *an* “open source business model”.

Stephen also points out that “when you get into the discussion it immediately degenerates when you try to assign certain companies to certain models”. This is indeed true, which is why we specifically avoided doing so in our report (although we did associate different companies with different strategies, which enabled us to come with statistics such as “60% of open-source-related vendors are utilizing traditional commercial licensing strategies to generate revenue from open source software”. Whether it would be practical or advisable to attempt to do this again is not clear to me right now).

It also gets difficult, as Stephen states, when you begin to look at multi-product companies which use a combination of strategies, which is why attempting to define complete models and associate them with specific companies is a bad idea. It is also difficult when you start looking at traditional vendors utilising OSS for specific projects alongside their proprietary software. However I would argue that – for example – Actuate has assembled strategies for creating a business model around BIRT.

Whether you refer to that as an “open source business model” is a matter of semantics.

What we are verging on here with attempts to define whether a business model is inherently “open source” is arguments around whether it is possible to define an “open source vendor”, something that I have previously done for the purposes of our reports, but which is increasingly futile. As Matt Asay stated recently: “We are all open-source companies now. Which also means that none of us are.”

We are planning to update “Open Source is Not a Business Model” next year and I am somewhat glad that I don’t have to face the problem yet of deciding which vendors will be included in our assessment and which won’t. What I do know is that it would be impossible and impractical to limit our assessment to “open source vendors” not least because – whatever the definition – it would provide an imbalanced view of what we are trying to ascertain, which is how vendors – all vendors – make money from free and open source software.

The trick is not to try to define and pigeon-hole vendors based on their business models, but to try to identify the strategies for creating business opportunities based on open source software that they use within those business models.

I stated above that in “Open Source is Not a Business Model” we identified that there are multiple models used to build a business around open source: theoretically hundreds. At the time I referred to those as “open source business models”. I am confident we will not be doing so this time next year.

Understanding commercial open source via the Bee Keeper model

Last June I reported on James Dixon’s Bee Keeper model for understanding the relationships between commercial open source vendors and their communities.

Recently James has updated the model, incorporating a number of changes, including some suggested by me as a means by which the Bee Keeper analogy could be applied beyond captive open source projects.

I’m very grateful to James for taking my suggestions on board, as well as linking to our wider research on open source business strategies.

Irrespective of our inclusion in James’ paper I wanted to draw attention to the latest version (PDF) of the Bee Keeper as I believe James has done a great job of improving what was already a very elegant explanation of the development and business strategies adopted by commercial open source vendors.

In addition to the original Bee Keeper analogy (in short the vendor is the bee keeper; the community is the bees; the open source project is the honey; and the customer is after processed honey – supported open source software) James has added:

  • The Wild Hive Model for Open Source Projects
  • The Maple Syrup Farm Model for Proprietary Software Companies
  • The Honey-Gatherer Model for Service/Support Commercial Open Source

The inclusion of the first two of these models is a significant improvement, I believe, in providing a context for understanding the motivations of commercial open source vendors in taking the Bee Keeper approach. I’ll leave it to others to comment on James’ wisdom in incorporating the third, as that was my suggestion.

One suggestion I made that didn’t make the cut was that of the blender model for service and certification providers that do the equivalent of “pick and choose honey from a variety of freely available bee nests and blend it together to produce a more palatable product”.

David Dennis of GroundWork has, completely independently, suggested the Honey Blender as an additional model for vendors, applying the same terms to vendors like GroundWork and Linux distributors that combine code from multiple projects (both wild and domesticated).

Reading David’s suggestion I would agree that the ‘blender’ tag is better applied to vendors that adopt this hybrid production model rather than service and certification providers, which are arguably covered by the Honey-Gatherer model.

In the comments to David’s post, James notes that “I have not included it to date because most enterprise proprietary vendors do the same thing” which I took to mean that most proprietary vendors combine open source code within their own to produce their proprietary products.

This is true, and points to the major model that I believe is missing from the latest version of the Bee Keeper – the use of open source by proprietary vendors in their development processes. I previously suggested the concept of “the brewer” – a vendor that takes honey from various sources and turns it into a completely different product (in this case, mead).

That particular analogy is not the greatest to be honest, and does not take into account the variety of ways in which open source software can be used in the development of proprietary products but I believe there is some scope for expanding the Bee Keeper model further, both for completeness, and to make the distinction with the 100% proprietary “The Maple Syrup Farm Model”.

Through our ongoing research we are engaged in examining the strategies of traditional proprietary vendors in engaging with and making use of open source, so I shall put some more thought into how our observations can be applied to the Bee Keeper model.

Given the variety of possible approaches to using open source software in the development of proprietary products it is feasible that such a model belongs in a related but entirely separate paper.

In the meantime, I fully recommend you take a look at the latest draft of The Bee Keeper and follow James’ blog for further updates.

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.

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.

Open source in 2008 in pictures

I was thinking of writing a round-up of the key open source agenda items in 2008 but then I got distracted putting together some graphics, so – two birds with one stone – here’s open source in 2008 in pictures:

(Some of these I’ve already written about, some of them I’ll write about next year. Apologies for the headache-inducing colours on some of these, they are works in progress and brighter colours are easier to assemble.)

Open source is not a business model

What we talk about when we talk about community

The five ages of vendor-led open source revenue strategies

Open source as a strategic competitive weapon

The five ages of vendor-led open source revenue strategies

Before I got waylaid with traveling I wrote that each of the various open source revenue strategies might have its place depending on the stage of commoditization and the short- and long-term goals of the individual vendor.

I was thinking it might be possible to describe the lifecycle of open source strategies, but I never got around to following up on that… until now.

I hereby present the five ages of Vendor-led open source revenue strategies, which takes us through the evolving revenue strategies of vendors that dominate their own open source-based products.

Some vendors may stay longer at one stage than another, or even skip a stage entirely. I don’t claim this to be perfect, and it doesn’t necessarily work for vendors that build a business around community-led projects (I’ll come back to that), but I think it is essentially accurate:

The Support Age
The vendor releases its open source project, prompting widespread downloads and disrupting the market. Since it has first-mover advantage (especially if it uses the GPL) the vendor is the only source of support and services and benefits accordingly from its support-based revenue strategy, which provides support, training and consulting. A dual licensing strategy may enable the company to generate additional revenue from open source-shy ISVs and enterprises.

The Subscription Age
As the software matures and users become more comfortable with it community-based support is a viable alternative to ad hoc support contracts, while third party training and consulting businesses appear. The vendor looks to ensure more repeatable and long-term revenue through the addition of a subscription offering featuring updates, bug fixes and support etc. The subscription offering also enables the vendor to commit to indemnifying its commercial customers without the need for a separately-licensed version.

The Value-add Age
Enterprise users have built up a decent level of expertise and are able to self-support with confidence. Given the maturity and quality of the underlying code some begin to question the need for long-term subscription plans for non-mission critical environments. The vendor responds by adding additional features and services to its subscription offering, such as management capabilities, while maintaining a 100% open source software strategy.

The Extension Age
With the underlying code base even more mature the vendor is struggling to convert large download numbers into paying customers and there is the constant need for newer services to maintain interest in the subscription offering. The vendor turns to the Open-Core strategy and begins to offer proprietary functionality either delivered as a service via the subscription offering, or as a standalone complementary product.

The ?????? Age
It remains to be seen. One possibility is The Golden Age whereby the vendor hits upon a revenue strategy that provides balance in supporting the needs of both community and commercial users, bringing an end to war and poverty, aligning the planets and bringing them into universal harmony, allowing meaningful contact with all forms of life, from extra terrestrials to common household pets.

More likely though is The Acquisition Age, whereby the vendor sells-out to a larger player. My money is on The Embedded Age, whereby the open source software becomes a component of a wider commercial package, either through the extension of the Open-Core model, or through absorption into a larger vendor’s commercial software strategy via acquisition.

UPDATE – As suggested in the comments, The Hosted Age should be added to the list of potential outcomes. I wrote previously about the convergence of open source and SaaS and how the two model complement one another. Several vendors are already moving in the direction of SaaS being the enterprise deployment model for community open source software. – UPDATE

Any other ideas?

Open source is not a business model

(Or “freedom of speech won’t feed my children”)

Last month I noted that Matt Asay, one of the highest profile proponents of open source software, had changed his position on the use of proprietary extensions as a means of attracting paying customers to software based on open source code.

Having previously advocated a 100% open source approach, Matt conceded that “If adding a hint of proprietary software to a solution is done in such a way to encourage a purchase but not compel long-term lock-in, I’m no longer convinced that this is wrong. If it puts food on the table without putting anyone out, where is the harm?”

Matt is not the only open source advocate to have accepted that proprietary and open source software are not mutually exclusive, as has been proven by the findings of The 451 Group’s latest CAOS report, “Open Source is Not a Business Model“.

With this research report we were trying to answer the age old question “How do vendors generate revenue from open source software?”. In order to answer it we analyzed the business strategies of 114 open source-related vendors, including open source specialists such as Red Hat and Alfresco, and those for which open source is used more tactically, such as IBM and Oracle.*

Some of the more interesting findings are as follows:

  • The majority of open source vendors utilize some form of commercial licensing to distribute, or generate revenue from, open source software.
  • Half the vendors assessed are using hybrid development models — combining code developed via open source projects with software developed out-of-sight of open source project members.
  • Vendors using hybrid development and licensing models are balancing higher development and marketing costs with the ability to increase revenue-generation opportunities from commercially licensed software.
  • The license used for an open source project (reciprocal or permissive) has a strong influence on development, vendor licensing and revenue-generation strategies.

In order to assess the business strategies used by open source-related vendors it was necessary to categorise the business models used by open source vendors. We therefore assessed each vendor’s strategy related to license choice (reciprocal or permissive), development model, vendor licensing strategy (e.g. dual licensing, open-core licensing) and revenue generation triggers (e.g. commercial licensing, subscription, support services, other products).

While it had been previously thought that there are a handful of business models related to open source, our research indicated that this is an over-simplification. There are over 80 different combinations of development model, vendor licensing strategy and primary revenue trigger being used today by the vendors we analyzed.

The report also busted some other open source-related myths, such as the idea that open source vendors are reliant on ad hoc support services, and that open source eliminates the need for direct sales. We found that:

  • Ad hoc support services are used by nearly 70% of the vendors assessed, but represent the primary revenue stream for fewer than 8% of open-source-related vendors.
  • Most vendors generating revenue from open source software are reliant on direct sales staff to bring in the largest proportion of revenue.

There are plenty of other juicy statistics in the report, which examines the influence of license, development model, vendor licensing strategy, and revenue triggers on each other, as well as the strengths and weaknesses of the various strategies, and how the use of revenue generation and sales strategies will change over the next two years.

There is also room for a bit of history, examining the origins of open source-related business models, and the evolution of business models over time to accommodate hybrid development and licensing strategies.

As for the overall conclusion. I have already hinted at the findings in a couple of posts, noting that:

  • “Open source is a business tactic, not a business model. Open source is not a market in and of itself, nor is it a vertical segment of the market. Open source is a software development and/or distribution model that is enabled by a licensing tactic.”
  • “The cat is already out of the bag when it comes to open source related business models and there is no way it is going back in.”
  • “There is very little money being made out of open source software that doesn’t involve proprietary software and services.”

The line between proprietary software and open source software is becoming increasingly blurred as open source software is embedded in broader proprietary hardware and software products and proprietary extensions are used to attract more customers.

Some open source purists will no doubt be dismayed that so much software distributed using open source licenses finds its way into commercially licensed products. More pragmatic observers will no doubt be encouraged by the widespread adoption of open source development and distribution principles.

Either way, the fact is there are few vendors generating revenue from open source software that are following a pure open source approach when it comes to developing all of their code in the open and licensing all of their software under open source licenses.

The report was released on Friday to existing subscribers and is also available for purchase. An executive summary (Pdf) is also available. Look out for future details on a live webinar where I’ll discuss the findings in more detail.

*We were aware that the inclusion of (mostly) proprietary vendors such as these might disproportionately influence the results so we also filtered the findings to include only those vendors that could be considered “open source specialists”. We found that over 40% of these specialists are developing some software out-of-sight of open source project members while more than 50% are using some form of commercial licensing strategy. Full details in the report itself.

Smashing the open source glass ceiling

Last week I asked whether open source vendors face a glass ceiling, prompted by Savio Rodrigues’s suggestion that a pure open source support model will only get vendors so far.

While I remain unconvinced at this stage* Savio is in no doubt that such a ceiling exists and has continued his argument with a suggestion as to how to fix what he calls “the broken OSS business model”. The solution, according to Savio, is for a vendor to offer two products – one open source and the other, with additional features, commercially licensed.

Calling it the “Product Driven OSS Business Model”, Savio describes how the features previously only available with the commercial product will be added to version 2.0 of the open source product, while new additional features will be added to the commercial product in version 2.0, maintaining its differentiation.

“I know that all of this sounds like heresy to some OSS purists. It is. We need a dose of heresy to break through the glass ceiling that some of us see ahead,” he writes.

What strikes me about this model is that it is already being put into practice my a number of vendors. In fact, it is a subset of the “Split OSS/commercial products” category defined by Carlo Daffara as part of the FLOSSMetrics project.

For example, SugarCRM, Hyperic, and GroundWork all differentiate their commercial and community products based on features, while EnterpriseDB has also gone in that direction with its PostgreSQL Plus strategy.

While I don’t think any of these vendors are as regimented as Savio suggests about drip-feeding functionality from the commercial version into the community version, the line that divides the products certainly changes over time as new features are added.

As for whether this model can “fix” the problem, as Carlo points out “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.”

Meanwhile in the comments section to Savio’s post, Damon Edwards raises other potential problems: “Your paying customers will immediately question the value of paying full price for something that they could have gotten 80% of for free. Additionally, you are going to run out of “feature carrots” to force upgrades pretty quickly. For example, lots of organizations would happily stick with Exchange 5.x (if it was free) and just ride out the wave until 7.x was free.”

Instead Damon suggests re-thinking support contracts to ensure that they provide value that potential customers will be willing to pay for, which brings us back to the point I made last week about the answer not necessarily being about features and functionality but the perceived value of the application in question.

*Savio’s argument relies on the assumption that a vendor has “saturated” Category C users (“those with cash and willing to spend it to save time”) and has to try and covert Category B users (“those with cash, but who have been trained by the OSS community to expect value for free”).

While this is probably theoretically sound I would argue that even the most successful open source vendor has an opportunity to sell more (valuable) applications into Category C accounts. In his original catagorization Savio wrote “There is likely an aspect of ‘how business critical is the application running on OSS’ that needs to be overlayed on this user categorization. But that’s for another post.” I’d like to read his thoughts on that before making up my mind.