The title of the session is, "Open-Core Licensing: The New Business Model Standard for Commercial Softtware," taken from my most recent blog on the subject.
Some of the more salient points that Jeff captured:
And on our open source approach:
Finally, a nice summary quote by founder, Sanjiva Nath:
My four posts on Open-Core Licensing:
I think most of us are completely sick of hearing and debating about it, but to quote Michael Corleone in the Godfather series, “Just when I thought I was out... they pull me back in..”
Back in August when I first posted about the Open-Core model, I was simply articulating what Jaspersoft and other of the more successful commercial open source vendors were doing. I invented nothing, just articulated it. I composed that blog out of frustration and wonderment as to how industry pundits seemed to ignore the fact that the emperor was wearing no clothes. Back then the conventional wisdom was, “Red Hat is the most successful open source software company, so success must follow their model.” I think points were ignored about the total potential size of the installed market determining how far you can go on services revenues. I simply pointed out the fact that traditional support-oriented open source vendors like MySQL over time were adding commercial features, AND … there is nothing wrong with that.
Now there is more weighing in around Open-Core:
- “whether the Open Core model is sustainable in the long-term (I'm thinking 5-10 years).“
- “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.” No going out on a limb there.
This all leaves me scratching my head again. Doesn’t everyone realize that the genie is out of the bottle? (sorry, all these clichés keep popping to mind.) Commercial open source is here to stay, everyone agrees. But the commercial proprietary model has been the most successful commercial model the past 30 years... Is it too outrageous of a claim to recognize the following convergence of the two, which appears to be happening before our eyes:
Forget open-core being popular just in open source circles, I mean commercial software in general. I predict that in 5-10 years (just about the time its diminishing importance is being predicted by some), Open-Core will be the standard for most new software companies arriving on the scene. Given the AGPL, this does not of course preclude SaaS models. The traditional proprietary MISO giants (Microsoft, IBM, SAP, and Oracle) will be considered legacy. Unless they act fast. Amazingly, Microsoft is making great strides toward open source (though they are using more of an Open-Crust, those features on top of the core, than Open-Core; still there is talk out there about open sourcing Windows. Reminds me of when I thought they were dead when Netscape arrived, and wham, they flipped on a dime! (How many clichés will I actually use in this blog?) That company re-invents itself more than Madonna. IBM is a big, obvious advocate and promoter of Open Source. Besides its investment arm, I am not aware of SAP making any big open source moves within its own software family, aside from MaxDB (what ever happened to that?). And Oracle has some open source projects here and there (SleepyCat, InnoDB), but can anyone imagine them open sourcing the Oracle RDBMS? Not likely.
Yes, you will have niche products whose creators will believe their products and ingenuity is so unique that they simply can’t divulge any secret sauces (think Ab Initio an exotic black box ETL / data integration tool – by the way how many people do you know using it? One, if you are lucky. I will reserve comment on that for a different blog). But I think those products will be in the minority and be considered quaint ("your product is COMPLETLEY proprietary? Hey this is 2015, not 1995!").
Does this Open-Core business model drive the software industry to become a commodity industry? Perhaps... scary, ay? But commodity only in some respects, I would imagine. Innovation may be driven with core and crust features alike, and revenue can be driven primarily with the crust features in a very successful way. This is why I think open source despite some conventional (forgetful) wisdom, and even more so with the Open-Core model, is actually a wonderful model to drive adoption of innovative technologies. Open-Core is not only for commodity core technology. And this is why zAgile has selected* Open-Core as the business model to drive wide adoption of its own very innovative core technology (released into public beta on SourceForge 1 month ago). Remember, there were some very innovative technologies driven by open source, things like: the original Unix, Apache, Mozilla browser, and the world wide web, to name a few. So why can’t open source in general and the open-core business model in particular drive wide adoption of innovative technologies too? Over the next few years, far from fading and particularly aided by the dire economy, Open-Core will become the standard in commercial software.
* editor's note: as of April 6, 2011, zAgile has not implemented the Open Core Licensing business model
Check out my other posts on Open-Core Licensing:
I read with great interest an article from eWeek, authored by Pringo's Majid Abai, entitled "How Enterprise Information Portals and Social Networking Are Converging." I think Majid is right on the money, and his comments are quite close to zAgile's vision.
In the past, I recognized how zAgile's vision matches up well with emerging trends including: Unified Collaboration, information sharing, semantic discovery, social networking, contextual computing, and the surge in mash-ups.
The thing that intrigues me is that it seems that not many people are putting together the critical idea, that comprehensive, contextual, enterprise collaboration requires a mastery of data and more specifically, that's about semantic data. Certainly SOA / web services are great for connecting data from point A to point B, but if every time you must define all the meta data characteristics of A & B and how they are related, you waste a lot of time, you will get inconsistencies, and you still won't be able to infer meaning with respect to A & B concepts, let alone how they relate to C.
This is why ontology-driven solutions for any kind of enterprise collaboration will become so obviously critical in the coming couple years. The point-to-point hacks will no longer be enough. What is required is an enterprise, contextual, structured foundation, which semantically plugs together all collobartion tools, social networking tools, engineering tools, CRM, and other applications. Ideally, the solution should use semantic web standards and be open source with an open source ecosystem of stanadardized connectors. This is what zAgile delivers.
We are on the cusp of an exciting new era with the Semantic Web. Just as we recall how the web popularized the internet, we are all just about to experience "the new web", one that recognizes the content within any given web page and how it is related to other information on the web. The Semantic Web promises to revolutionize the accessibility of information on the World Wide Web. But until the Semantic Web is a fully implemented and adopted by consumers like "Joe User", how can the benefits of the Semantic Web be applied to your organization today? Semantic wikis hold the answer!
Just as one might argue that Wikipedia is a microcosm of the web, a semantic wiki within your own organization is a microcosm of the worldwide semantic web. Semantic wikis add structure to the wiki enabling the traditional, unstructured content to be complimented with meaningful structure. Now Atlassian Confluence has become an intelligent semantic wiki thanks to an open source semantic web infrastructure called zCALM and a Confluence plug-in called Wikidsmart for Confluence, both from zAgile and free to download from www.zAgile.com. This means the promises of the semantic web can be immediately applied within your organization today, and with open standards and a flexible open source ecoystem.
At the Atlassian headquarters (375 Alabama St in SOMA, cross street 17th) in San Francisco on April 9, 6.30-8.30pm, zAgile will discuss tangible benefits of the Semantic Web and practical ways it can help you to become more efficient, automate processes, and empower your organization. As an example we will discuss and demonstrate zCALM, an open source semantic infrastructure. You will see how zCALM may be used to semantically enable your enterprise wiki (Atlassian Confluence), achieve "intelligent mash-ups" -- deep interoperability and exchange of context-sensitive information between applications (eg, Confluence, Jira, and Subversion - including WANdisco multi-site/cluster versions for Jira and WANdisco for Subversion, Perforce, IBM tools, HP tools, and Salesforce), and even act as a powerful search across your applications and tools.
So come by to learn how you can realize the promises of the semantic web internally in your own organization. If you cannot make it til later, afterwards, we will move over to a nearby bar called Circolo (500 Florida Street, between 18th St & Mariposa St), around 8.30pm to continue discussions.
We look forward to meeeting you! Please make sure to reserve your spot here. Many thanks to Jessie Curtner, Trisha Hong, and Todd Revolt at Atlassian and Marco Neumann from the New York City Semantic Web Meet-Up for enabling this!
My four posts on Open-Core Licensing:
A valuable open source product, a vibrant community, and the right licensing strategy are three keys to the success of a commercial open source software company. This post is a follow-up to my previous blog about the open-core licensing business model, and I address these points around the topic:
- How do you balance features between the commercial and open source versions?
- How do you build a successful community?
- What about the Application Service Provider (ASP) loophole?
Last August, I proposed the name “open-core licensing” for a specific commercial open source business model which appears to be an emerging standard and acceptable in premise by corporate buyers such as CTOs. In this business model, the core technology is licensed under an OSI approved license (typically GPL), and a commercial open source vendor that owns the intellectual property can also offer a commercial license that covers both that core technology as well as premium add-on features. In other words, the term “open-core licensing” was a proposed business model name for a specific type of dual licensing or twin licensing (i.e., if you own or control all the copyrights, you can issue a commercial license with exactly the same bits as the GPL version; it’s dual or twin licensing, but it’s not open-core licensing). This specific business model name was picked up by Matt Aslett of The 451 Group and open source industry observers such as Dave Rosenberg and Savio Rodrigues as an apparently increasingly recognized way to scale a commercial open source business model. Perhaps it is becoming even more accepted now than the previously presumed superior business model of “services only.” While there are certainly vendors out there that do not own the core copyrights of the product but provide commercial extensions, there are some benefits to owning the core copyrights, and that will be covered in a separate blog.
Achieving Balance Between Open Source and Commercially Licensed Versions
It’s a great question and still being posed: “how do you achieve balance between open source and commercial versions?” I think the answer is not a generic, precisely defined method for all vendors but rather specific to each vendor. But the overarching theme to the answer is simply put: make sure the value of the open source edition is compelling enough for broad adoption of the open source product. So, if your open source product is not being widely adopted or not being adopted quickly enough, you probably need to include more of the commercial features in the open source version. For example, keeping a pulse on your open source download rate and forums usage are probably both a good barometer of value in the open source version.
How Do You Build A Successful Community?
There are a lot of good overviews out there (Stormy Peters, Chris Brogan, Connie Bensen / Jeremiah Owyang, and John Lilly). Matthias Stürmer provided a detailed analysis in 2005. I think there are some other good discussions on the topic out there. Do you have further suggestions?
The ASP Loophole
Although GPL is not the choice license of developers for everything (e.g., many libraries), it is enjoys wide adoption, and it’s increasingly the license of choice amongst commercial open source software vendors. I propose that using the GNU Affero GPL v3 license as the specific type of GPL with the open-core licensing business model seems to be the next logical step on the path for commercial open source vendor business model evolution.
The problem with GPL v2 and v3, in the view of many commercial open source vendors, is that ASPs such as Google can profit quite heavily from GPL v2 and v3 open source efforts while not contributing back to those open source projects. Of course in a large enterprise, there is quite a grey area in the use of GPL, and a bank illustrates the case. A company like Citigroup may use GPL software internally, respecting the GPL license, but some of those systems which rely on GPL code may eventually be exposed to people outside of Citigroup, i.e., the ASP loophole. Does this violate the GPL v2? While a company such as Google would probably say “no,” most commercial open source vendors say, “yes.”
While providing many refinements over GPL v2 (see table) and pleasing companies such as Google and even Red Hat, GPL v3 received a tepid response from some commercial open source vendors due to the omission of the Affero clause which addressed the ASP loophole. Perhaps the most outspoken critic of GPL v3, Fabrizio Capbianco, CEO of Funambol, wrote:
The provision is not there. Gone. They dropped the ball. Actually, it has been made very clear that the ASP loophole is not a loophole anymore. It is perfectly fine to change GPLv3 software and offer it to the public as a service, without returning the changes to the community.
Since GPL v3’s release, more than 3,000 projects adopted it, and the ASP loophole was addressed with a new license called GNU Affero GPL v3 (AGPL). Noted open source legal authority Mark Radcliffe wrote, “The AGPL includes a provision requiring that companies providing services over a network make the source code available to users of the services (just as if the companies had distributed a copy of the software under the GPLv3) based on the well known "Affero" modification to the GPLv2.”
But Savio Rodrigues ponders whether the Affero clause is really necessary when a large company like Facebook contributes back code, even when it is not required to do so under a permissive license. My response in the comment section to his blog is basically, “isn’t that simply wishful thinking that all large companies will behave the same?”
I believe a comment by jrpenning on Matt Asay’s blog, points towards the right solution:
I think we're closing in on an optimal model. The AGPL tries to correct something that needed correction, but seems to be a bit too far on the other side. Dual licensing with an AGPL base would be a move back toward the center, where hopefully the optimum lies.
Therefore, a “best of all worlds” solution for commercial open source vendors is to use the open-core licensing business model with GNU Affero v3 as the open source license for the core technology.
When the AGPL license is combined with open-core licensing, software vendors that own their intellectual property are able to have their cake and eat it too. And commercial open source vendors, customers, and the open source community all have solid choices and preserve freedom.
While licensors should certainly be careful about license compatibility, I think AGPL v3 is the right move instead of GPL v3. Readers may presume that a product licensed under AGPL must be designed for SaaS. I propose that products for GPL consideration whose use case are 100% on-premise today but could eventually be used in a networked/web situation should be licensed under AGPL immediately in anticipation of the networked situations so that the licensor is protected. Therefore, up until the product is exposed publicly, GPL v3 conditions apply, and the Affero (ASP clause) is not pertinent. If our recent experience with web, internet, and other new technologies has taught us anything, it's that we cannot predict how software will be used.
That’s how I see things, but I am very curious to know of others’ opinions. In particular, I am curious to know about corporate adoption of GPL v3 and acceptance or criticisms of AGPL v3 – both at the executive and developer level. If corporate stakeholders object to AGPL v3, I would like to understand why. My guess is, as expressed by a variety of people in this 2007 blog, they generally don’t care about licensing. They simply want value and the right products for the right job, and they are willing to pay for the value entailed when required. And even if it’s really the developers, rather than executives, that are actually making the choices of open source products and their corresponding licenses in the bottom-up adoption, an open-core licensing model allows acquisition of a commercial license if that is desired.
Check out my other posts on Open-Core Licensing:
I am pleased to announce that zAgile is going open source with its first publicly available product, the v1.0 Beta of Wikidsmart for Confluence, under the GNU Affero GPL v3. Wikidsmart turns Confluence into a "semantic wiki." The Wikidsmart v1.0 Beta is available here for download. This entitles you to download and use Wikidsmart freely within your organization. Any time a modified version of the binary product is made available to the public, the code with its modifications needs to be also made available to the public.
Whereas a wiki provide an easy mechanism for users to collaborate, develop, and maintain documentation and other content within an enterprise, its inherent wiki characteristics also come with some natural limitations:
- Content organization is limited to mostly page-level hierarchies (though Confluence can help alleviate this with Spaces)
- Content Categorization may be implied in the page hierarchy but there is no inherent structure to support it
- No wiki page attributes or meta data
- Limited interoperability with other applications
- Static versus Dynamic Content
This open source license is great for your organization because there are no obligations to purchase a license, and you can prove out Wikidmart’s use in your organization, risk-free, to:
- Use semantically enabled forms to capture information in a consistent way across your user base. This ensures easy, consistent data entry that is “semantically” understood for easy cohesion across all systems other than the wiki
- Automate content exchange between systems rather than manual updates which can create bottlenecks in engineering operations and outdated and/or erroneous information
- Turn your Wiki into a Knowledge Repository that captures information across your tools and applications
A detailed description of Wikidsmart and its approach may be found here.
Today, the Wikidsmart Beta v1.0 is available for the Atlassian Confluence enterprise wiki. Please contact us if you would like to use zAgile with other wikis including MediaWiki, Microsoft SharePoint (MOSS) Wiki, MindTouch Deki, SocialText, or others.
Wikidsmart is the first of three zAgile products; the others include zPortal and zComposer which are both available as early adopter releases upon request from zAgile at firstname.lastname@example.org
As I walked to work today, I noticed the sky falling. Quite a sight, always wondered what was keeping it up. Turns out nothing. Well, it seems we are being led to believe that with all the recent economic downturn news of doom and gloom.
IT budgets are being slashed. And a recent survey shows half of all CIO's are having a hard time showing their value. It seems that 1 in 4 IT jobs are moving overseas, and apparently they are moving less and less to the BRIC countries. So how are a software engineering and professional services executives to deal with all this chaotic change while budgets are down and demands increase?
Wouldn't it be great if you could scale up your engineering team at will, while being confident that processes are adopted consistently and can be measured, no matter how geographically dispersed your teams are? Heck if you could add engineering resources in other countries at a lower cost while still maintaining your highly crafted processes and methodologies, that would be good, wouldn't it? That's where zAgile can help.
And wouldn't it be great if you could tie sales opportunities, to business requirements to what was actually built, so that the sales and engineering teams could show their mutual value and cohesion, all in a real-time dashboard setting. Yes, zAgile can help there too.
And it sure would be great if your key engineers could focus on buiding rather than plugging together their software engineering requirements with issue tracking, version control, project management, etc. How many hours are lost per month and what efficiencies could you gain if everything were automated? That's where zAgile can help also. Here's an example.
All of these are zAgile's value propositions. Gaining efficiencies in the processes, tools, and teams you already have, while making it easy and inexpensive to scale your teams to new heights.
I’m delighted to share with you about a zAgile customer success story. Market6, the technology leader in retail “last mile” supply chain software, has successfully deployed zAgile’s innovative software to integrate their teams, tools, and processes. The solution includes contextual integration of the Atlassian Jira issue & bug tracking system with the Confluence wiki to create a lightweight requirements management solution. To achieve this, one of the cool zAgile tricks involves turning Confluence into a semantic wiki, in order to capture requirements with semantic forms in the wiki. Those requirements are then instantiated into corresponding workflows in Jira by initiating appropriate Tasks and Subtasks associated with Feature Specification, Development and Testing. Try doing that with any other wiki out there! Not so easy, but with zAgile, it’s a snap to make a semantic wiki out of Confluence, Socialtext, Jive Clearspace Traction, MindSpring, MediaWiki, and other wikis. In addition Market6 wanted to have an easy front-end to applications such as Jira for their professional services and other non-engineering teams so that they could store and track issues in Jira without having to take time to ramp up to learn all the Jira terminology, workflows, and bells & whistles. With a zAgile portal, everyone now has an easy front-end to create and track issues and tasks pertaining to their projects, as well as a composite application to act as the single point of entry to all their applications. The next phase of the deployment involves integration of Subversion version control, GreenHopper (project planning for Jira), and ThoughtWorks CruiseControl (continuous build) together with Confluence and Jira, for an integrated environment. It was quite rewarding to see Market6’s reaction:
the zAgile infrastructure automatically “recognizes” the applications, their functions, and how they are related to one another, for a deep, contextual integration.
I invite you to read zAgile’s case study of Market6 to learn more. And hats off to Market6 for staying ahead of the curve on technology to reduce their costs and improve efficiencies, especially important in today’s challenging economic climate.