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
Blog
Twitter