My four posts on Open-Core Licensing:
===============
I was a panelist on the open core business model panel today at OSBC. Open core seems to be a hotly debated topic in the blogosphere today, mostly I think because some folks fear being "left out" or FUD around the core product's value, when it's not about that at all. The open core model is about a particular business model that an increasing number of commercial open source vendors have chosen for its ability to both scale a business while serving communities. There are other successful commercial open source business models too, but it depends upon goals for the customers, community, and vendors to select the "right one” for their needs.
When it comes down to it, it's all about value. If the open source core adds value to the community, the project will thrive. If the commercial license adds valuable features, the vendor will thrive as well.
The moderator of the session was Dave Rosenberg, COO and GM of the Americas of RiverMuse and fellow panelists were Aaron Fulkerson, CEO of MindTouch, and Ed Boyajian, CEO of EnterpriseDB.
It was fun to participate, and I am grateful to the OSBC conference organizers for the opportunity to join the debate.
There was an interesting point raised about the copyright ownership of the core code and its implications. In my original post last year, I defined open-core licensing as when the vendor owns the core copyright codes and offers a dual license, where the commercial license has additional premium features. However, that definition excludes vendors who do not own the open source core product; yet "open core" seems to be descriptive of that business model still. In anticipation of the topic, I Tweeted a proposed modification before the panel discussion, which would modify the definition to include two variants:
1) Vendor Controls (VC) core's copyrights
2) Community Controls (CC) core's copyrights. Of course the vendor is part of community but does not have enough copyright control to dictate license. However, as a vendor backs the project, they are likely to be able to dictate some large direction of the product's roadmap.
I would like to explore the benefits and challenges of both variants a bit more, from communities', customers', and vendors' perspectives:
1) Vendor Controls (VC) core's copyrights
There are a number of benefits and potential challenges:
a) Benefits to the community:
- A commercial entity ensures value in the core open source product, with paid staff to provide support and new features
b) Challenges to the community:
- Is there a challenge in participation to the degree you wish? My feeling is this is really a FUD point. Any community will be pleased to have a productive contributor.
c) Benefits to the customer:
- customers know the core uses an OSI-approved license (probably GPL or AGPL), and they have an option to purchase a commercial license to release themselves from the GPL obligations
- core roadmap has a commercial entity methodically financing and driving a roadmap -- and innovation -- of both the core and commercial features
- customer has "one throat to choke" around both the core and commercial features
d) Challenges to the customer:
- the customer needs to understand the vendor's strategy for how features are determined to be included in the open source core and which features are reserved for the commercial product. The customer should ask the vendor to post the policy publicly to be clear if the vendor has not done so already.
e) Benefits to the open core vendor:
- vendor can offer a commercial license to ISV customers who wish to embed the product without GPL restrictions
- vendor can choose to change the open source license (eg, GPL 2 to GPL 3) or offer a commercial license
- Lower indemnification risk of vendor due to knowledge of core code
- Enforce violation of copyright of core
f) Challenges for the open core vendor:
- see 1b above. What is the best way, in terms of features, to simultaneously serve the community and drive revenue. This requires keeping a good pulse on the community's wishes and requirements. Probably if put to a vote, the community will always request more features in the open source core. But as mentioned above, it's all about value for both the open source core and the commercial features. If there is solid value in the open source core, and the community continues to download and participate, there may not be a huge requirement to move additional features into the open core. Whatever the policy, the vendor should be clear about it.
2) Community Controls (CC) core's copyrights
There are a number of benefits and challenges:
a) Benefits to the community:
- A community, whether reality or not, feels that it is free of commercial, emphatic control
b) Challenges to the community:
- Does the community have enough support? If there is a commercial entity backing it, chances are yes. But does this put point 2a into question?
c) Benefits to the customer:
- if permissive license, no commercial license required to embed core in your ISV product
- core's roadmap MIGHT NOT be dictated by vendor or single person (may be bad too)
d) Challenges for the customer:
- if GPL, probably no easy way to get out of GPL requirements when embedding
- maybe no throat to choke or difficult to find or influence someone on core's roadmap
e) Benefits to the open core vendor:
- Probably there is a large community contributing to the core which lessens the R&D cost burden on the vendor.
f) Challenges for the open core vendor:
- vendor cannot change the core license, e.g. GPL to AGPL or commercial
- vendor is financing a core for which it likely does not retain control
All in all, it's about value, and both of the variants of the open core licensing model provide both to customers and communities alike.
========
****Special thanks to Matt Dahlman and Sherman Wood for their edits and input to this post.
=======
Check out my other posts on Open-Core Licensing:
