Monday, March 2, 2009

Building on the Success of Open Core, guest post by Matt Aslett

My thanks to Matt Aslett from The 451 Group for guest blogging here at The Open Book on BI. Matt has been an active participant in the debate on open core, and has agreed to share his last words on the topic here today. The views and opinions expressed are his own.

Building on the success of Open Core

Thanks to Brian Gentile for the chance to guest post on the debate surrounding open source business models. Brian recently joined that debate, writing that the Open Core model offers the best model for community and commercial success.

I absolutely agree that Open Core is a successful strategy. In the report, Open Source is Not a Business Model, we noted that it is now the most popular commercial open source licensing strategy, used by 23.7% of the 114 vendors we assessed and 40.4% of those that were using a commercial licensing strategy to generate revenue from open source.

However, I also recently questioned whether the Open Core model is sustainable in the long-term (I'm thinking 5-10 years).

This is partially based on my belief that we will see a shift away from vendor dominated open source projects (such as MySQL and JasperSoft) to vendor-dominated open source communities (such as Eclipse and Symbian) during this period, but also because there are other potential problems that arise with the Open Core model.

Rather than re-hash those issues here I thought it would be better to use this guest-post opportunity to suggest some strategies that could be used to ensure a sustainable implementation of the Open Core model.

Many of these are being implemented by the various Open Core vendors - including JasperSoft - and with that in mind - along with the final caveat that unlike Brian I am the chicken in this debate (involved but not committed) - these are the issues that I think are critical to a successful Open-Core model:

Truth in advertising
Be absolutely transparent about licensing. Potential customers don't like feeling confused or misled and it is vital that the marketing makes it clear that the community version is open source and the enterprise edition is not. Personally, I believe that Open Core vendors could and should be referred to as "open source vendors" but that is something of a hypothetical construct. What is clear is that if the product in question does not use an OSI-approved license it is not open source, and should not be referred to as open source.

Don't promise what you can't deliver
On a related note, open core vendors must avoid overselling the benefits of open source. Be an advocate for open source, but never forget that the revenue generating products and features are not open source. Tarus Balog of the OpenNMS Group recently highlighted the theoretical contradiction at the heart of the Open-Core model in the context of the request from open source vendors, including some open core advocates, for open source to be included in President Obama's economic stimulus plans. If you ask the government to mandate open source, don't be surprised if it insists on the source code to your proprietary functionality. Similarly in our Cost Conscious report, we found that 73% of end users surveyed expected to generate cost savings from deploying open source software through reducing the cost of software licenses. Clearly some of them are going to be disappointed if they need to be deploying software licenses to get the functionality they require.

The new UK government policy on open source software also makes the distinction between the treatment of open source licensed products and the exit, rebid and rebuild costs associated with proprietary software. Yes, there are licensing mechanisms that can be used to ensure Open-Core products can be used as part of pro-open source adoption policies, but Open-Core vendors must make sure they are not selling customers a vision of open source while delivering the proprietary licenses they are supposedly trying to avoid.

Separation of church and state
The further removed the proprietary functionality is from the needs of community users the less likely it is that the community will develop their own alternatives and the easier it will be to manage the needs of both commercial and community users. If the vendor is hearing constant demands from the community for features in the enterprise version then the balance is wrong. It might sound like a great opportunity for up-sell but if the community users are never going to pay for the enterprise product then it just creates confusion and antagonism. When deciding on proprietary features vendors should create a list of features that is only ever going to solve the problems faced by enterprise customers. In the context of the law of Conservation of Attractive Profits, articulated by Clayton Christensen in The Innovator's Solution, it also makes sense for a vendor to focus its attention further up the value chain than the stage it is actively commoditizing with the open source community version.

Care in the community
Brian is right to say that "Community and Commercial customers form a necessary and symbiotic virtuous circle" and that "done properly, the resulting broad use yields benefit and value to both the Community and Commercial customers." Doing it properly means looking after and understanding the community. Among other things a vendor needs to:

  • Hire a proven, experienced and respected community manager to liaise between the company and the community
  • Create a forge - if you don't know who your community is and what they are doing with the software you cannot hope to understand why an individual or company is part of the community and respond to their wants and needs.
  • Encourage partners to become part of the community, rather than part of commercial partnerships, to help improve the core code base and enable new commercial strategies.
Keep an eye on the bigger picture
Defining and creating understanding about licensing and revenue strategies is important but philosophical debates between open source vendors can appear from the outside like a fight between two bald men over a comb (and yes I am totally aware that I am guilty of propagating the current debate, I fully intend this will be my last word on the subject of Open Core for a while). Michael Tiemann recently claimed that the world wastes $1 trillion per year in "dead-loss writeoffs of failed proprietary software implementations" and maintained that open source software is the way to solve that problem. He also stated that "semi-proprietary strategies... are all too clever by half, because they all imagine winning the next battle in a war that's already been lost." Of course he might not be right, but $1 trillion makes it worth thinking about.

I realize that for many Open Core vendors I am preaching to the converted. Many of the same themes were discussed on a panel on open source at the recent Accel Symposium at Stanford, for example.

Open Core is definitely the most popular and successful model of commercial open source in use today, and I expect it to remain so for the next few years, but the conclusion of Sun's Zack Urlocker on that Accel open source panel is worth bearing in mind:

"There are many different ways to skin this cat. There isn't one single model for commercializing open source, and things will continue to evolve as the market expands. What worked in the past may not always apply in the future."

Matt Aslett
Analyst, enterprise software, The 451 Group


  1. You make statements like "I absolutely agree that Open Core is a successful strategy". I've heard this before in other places and I've always wondered where the supporting evidence is.

    I don't mean to be confrontational, but those I've heard claiming "success" with this model of having free (both as in beer and speech) and paid-only features of what is essentially the same product all appear to be private start-ups who couldn't keep the lights on without venture funding.

    Shouldn't we wait for examples of rapid self-sustaining growth and large exits (all of the signs that used to indicate a successful software-based business model) before declaring "open core" a success?

  2. @Damon,

    You're right, there have only been a few successful exits in the Open Source community since the early days (Red Hat, VA, ...) where one could consider an Open Core aspect. But those have been the only exits full stop:
    * MySQL wasn't acquired for Monty, it was acquired (if revenue was at all a reason for that deal) for the commercial side of the licensing equation;
    * Zimbra was a revenue loss situation, except for the commercial side, by properly focusing on the commercial vs. community side of things.

    I think you'll start to see more and more companies focusing on a split between the people who will never provide revenue, and the people whole will only provide revenue if there are features the other side will never pay for.

    You're right, though, these are still early times for exits. There are a lot of firms (Jasper, Spring, Terracotta) that are trying to navigate this towards a successful exit for their investors. Not all of them will succeed.

    But my opinion is that knowingly segregating your user base into those who might pay for core++ and those will never pay for anything is a better chance than praying for support contracts.

  3. Perhaps where I'm getting confused is why you have to segregate users into those blanket categories at all.

    I'm sure there are plenty of companies that are using your product but say they will never pay a dime for it but they are simultaneously happily paying another company many dimes for some different product (open source or closed) or service. Your classification puts them in freeloader bucket while they have plenty of money to spend on things they find valuable.

    Instead of creating what is going to seem like an arbitrary line that exists for no other reason then to COMPEL those existing users to pay for something, why not create completely separate offerings that people are willing to happily pay for? (products or services that address the same users but don't interfere with the open source project). The model of parallel products and services that don't interfere with the project or retard community use seemed to work wonders for the few big OSS exits we can all cite. Why go a different direction now?

    This mixing of business models doesn't seem to serve anyone's needs but investors on whiteboards who long for the old days before OSS existed.

  4. "Instead of creating what is going to seem like an arbitrary line that exists for no other reason then to COMPEL those existing users to pay for something, why not create completely separate offerings that people are willing to happily pay for?"

    Absolutely - as I wrote above the further removed the proprietary functionality is from the needs of community users the better. If a vendor is trying to "compel" community users to pay for the enterprise product then the balance is wrong.

  5. I have voiced my doubts about whether Open Core will prove to be self-sustaining in the long-term and prove successful beyond generating enough momentum to attract a buyer.

    It is definitely early days for the Open Core strategy and due to its relative immaturity we have yet to see many exits, so the measure for success I would use at this stage is revenue growth.

    Recently JasperSoft announced 75% business growth, Zmanda claimed to have quadrupled revenue and subscribers, Zenoss announced 382% revenue growth, KnowledgeTree announced 91% revenue growth and xTuple claimed 250% sales growth.

    You are also right that the strategy is partially driven by the needs of venture funding but if they did not see signs of potential returns they would not continue to invest

    Links -