This is the third in a series of blog posts intended to help IT managers understand open source licensing and its implications. In this post I cover the roles an open source product can play in an enterprise vendor’s business (which are enabled by open source licenses) and what this means for the enterprise itself.
A previous post discussed the four key levers of open source licensing that can support a vendor’s business model:
- Hereditary versus permissive licensing (and the impact of Copyleft)
- Source code ownership rights
- Limitations around attribution
- What defines “distribution”
These levers are important to enabling the roles a vendor intends a software product to play in support of their business objectives, which are listed below. I’ll go through each of these in detail:
- Commoditizing a Function
- Increasing Accessibility to Code, But Retaining Ownership
- Sustaining a Community
- Delivering Services
- Providing Support
Commoditizing a Function: This role is enabled by permissive open source licenses. For example, the Apache web server has commoditized basic web serving. Large companies like IBM have been the biggest contributors to these types of projects, often supplying the most developers and even contributing code that becomes the basis of new projects.
Nearly all open source products benefit from these products since they provide the foundation for other opportunities (e.g., LAMP-based solutions). IBM benefits by incorporating these in commercial product offerings, enabling contributions to come from a wider audience of developers (thereby sharing some cost), providing a forum to explore new technologies and standards (reducing risk and increasing interoperability), and reducing the chance of competing technologies from becoming standards (for example, the Apache web server has remained the most popular web server despite efforts from companies like Microsoft).
Increasing Accessibility to Code, But Retaining Ownership: This role is enabled by dual licensing of software. In particular, companies have licensed software they own with both a proprietary license and a hereditary open source license, such as the GPL. The classic example of this is MySQL. In the content management market, Alfresco is a good example.
The key to enabling this dual licensing approach is having ownership rights to the source code. For example, take a look at the Sun Contributor Agreement. The author of a contribution that makes it into the core product must give ownership rights to Sun.
In this role the GPL discourages competitors from incorporating MySQL source code into a proprietary product (since distributing the resulting product would require it to be licensed under the GPL) while also increasing visibility enabling others to interoperate with it. Nearly every Linux distribution comes packaged with the GPL version of MySQL, making it an easy choice for many developers to use. I’m sure Alfresco would love to have the same type of relationship with Linux at some point.
Sustaining a Community: For all of the complaints made against the GPL (mostly by commercial software vendors) it is hard to dispute the success of a number of communities supporting GPL-licensed products. For example, the Drupal community has over 350,000 members and the Wordpress community has produced over 4,200 plugins. These are extremely active communities and are examples of what many established commercial vendors have been striving to build for years.
None of the main commercial entities involved in these products (Acquia for Drupal and Automattic for Wordpress) control the source code, nor license it separately. The GPL seems to level the playing field, enabling community members to compete on aspects other than proprietary software offerings. Rather, community members use the source code as a basis for competing in downstream markets such as custom website development, various types of services, and support. The result is a robust open source product that incorporates cutting-edge innovations at a pace commercial software vendors have difficulty matching.
Delivering Services: One of the ways Acquia and Automattic leverage their open source products is to provide services and support. For example, basic hosted Wordpress.com blogs are free. But, Automattic also provides premium blogging services as well as software support for enterprises. Acquia also provides support and later this year will offer site hosting and a premium site-search service (based on Solr, an Apache-licensed product, and provided via a Drupal module). Of course, many online service providers use open source software. The most recognizable being Google and Yahoo.
Providing Support: Although community leaders (such as Acquia, Alfresco, and Automattic) offer paid support services for their open source products, there are also companies that provide support for a broader selection. These include OpenLogic and SpringSource. For example, OpenLogic provides support for MediaWiki (the software which runs Wikipedia) as well as hundreds of other open source products including development tools.
Most enterprises will need some type of commercial support for open source products, unless they intend to maintain a staff with sufficient skills to do it themselves. So which type of support should you use, a contract with a community leader or a support-only vendor? Each situation can be different but, in most cases, I would first consider going with the community leader (since this contributes to the long-term viability of the product), unless the use of the product is limited and the risk of problems low. Either way, I think there is room in the market for both types of open source vendors and their positioning will be sorted out over time.
Clearly, open source products need viable community leaders and these companies will likely provide the best support. However, enterprises can only be expected to maintain so many vendor relationships and there are literally hundreds of opportunities for enterprises to use open source (many, of which, do not have a commercial entities behind them) so the open source support vendors should have plenty of business to go after.
What does this all mean to enterprises wanting to use open source solutions? When considering a particular open source product,first understand the role it plays in the plans of vendors supporting it.
- Products with strong communities behind them will tend to be more innovative, likely have enterprise support options, and be around for some time.
- Those products without strong communities need to be assessed as if they were a commercial product being sold by the vendor providing support.
- If they have neither a strong community nor a viable commercial vendor behind them, either reconsider your options or proceed with caution and look for signs that the community will continue growing.
The key is understanding the long-term viability of an open source product, whether it is backed by a vendor or a community.
In my next post I will discuss some of the risks involved with open source licensing, thoughts on mitigating these risks, and open questions that still remain.
This is a repost of a blog originally posted on the Collaboration and Content Strategies Blog