Matt Aslett, from 451 Group, is one of the best analysts in the industry for studying the business strategies of companies related to open source. His 2008 report ‘Open Source is Not a Business Model’ correctly pointed out that companies did not just use open source but used a number of strategies to maximize their revenue generating and profit opportunities. Therefore, I was very pleased to hear Matt was doing a new report, called Control and Community. The report is being sold to 451 customers but I was lucky enough to review a copy of the report.
The general thesis of the report is that the open source business strategies of companies is evolving and we are entering a new stage. The stages being:
1. Software developed by communities of individuals
2. Vendors begin to engage with existing open source communities
3. Vendor-dominated open source development and distribution projects
4. Corporate-dominated open source development communities
According the report, companies are moving to stage 4 by participating in collaborating open source communities. This is certainly something we at the Eclipse Foundation encourage, support and see in action.
As Matt points out in the report many open source software companies in stage 3 have been operating in more of a traditional cathedral development model. These companies use a combination of strong copyleft license (GPL), strict rules on copyright assignment to the vendor and a development model that requires for the most part committers to be employees of the vendor. These companies have used open source licensing to disrupt a market but behave like a typical software vendor. However, there appears to be a change occurring where companies are realizing they are not benefiting from the bazaar approach to open source. The report, I think correctly states:
the main influence of open source software, it could be argued, has been to lower the operational costs of those dominating proprietary vendors by enabling them to collaborate on the development of non-differentiating, commodity components, while continuing to generate profits from complementary products elsewhere in the value chain.
Vendors are now realizing they don’t have to have absolute control over an open source project. There are plenty of business strategies to generate revenue and profit by building on top and around a successful open source project. In fact, using the cathedral approach as their development model might indeed be limiting their company.
This is something I am seeing more and more at Eclipse and other open source communities. The Eclipse CDT project is a perfect example of companies collaborating to lower their costs of development. Companies like Freescale, Ericsson, IBM, Intel (Wind River) and others are all collaborating to build a better C/C++ IDE that helps them either sell more product and services or build products and services. The report also showcases SAP increasing involvement at Eclipse and other open source projects.
I also see a lot more VC funded startup taking the stage 4 approach. Sonatype is a great example with Maven, Cloudera with Hadoop and many others. These companies get they don’t need complete control and in fact benefit from having a more engaged community.
Besides the cost reduction, I think the report missed the point that having more companies invest in value-add services and products actually increases the value of the open source code. The more companies that build on top of Eclipse makes it more valuable to the end user, since they can standardize on a common platform. Similarly, mores companies that invest in Maven, Hadoop or Cassandra means downstream consumers have more selection of tools, services and other products. They aren’t limited to a single vendor. This only helps accelerate adoption and creating a bigger market.
The report also points to a trend of corporate contributions from companies like Facebook, Twitter, Yahoo, etc. These companies had requirements that were not being meet, so they looked to implement themselves but then collaborate on the ongoing development. I hope to see this trend expand into other areas. The power of collaborating communities is something too good to be restricted to a few technology oriented companies.
One of the final report recommendations, is something I have believed for a long time.
Our recommendation is that vendors that control open source projects need to transition toward more collaborative development in order to prive that they are more than just another software vendor that happens to release software using an open source license.
If a company really wants to benefit from open source, you really need to live in open source. Releasing software with an open source license is an important first step but there is much more to consider.
Ian Skerrett 
Great post. I believe your recommendations are spot-on, and it’s something that open-source communities need to reflect upon during their evolutionary cycle of open-source. Infobright, the first open-source columnar database company, sits into the between phase2 and phase3.
What are best practices to help evolve an open-source community? Is Social Outreach the main component, or is there something more?
@Jeff Great question and probably worthy of another blog post. The 451 report actually touches on some of the best practice. Off the top of my head some things to thing about:
1. Adopt the Bazaar development model. Make sure you allow non-vendor employees to be committers, assuming they have proven their aptitude (meritocracy). Don’t expect copyright assignments from these committers.
2. Use a permissive (ASL) or weak copyleft (EPL) license. This opens up your community to organizations interested in creating commercial products. Unfortunately GPL limits the participation of many organizations.
3. Reach out to your competitors. If you really really want to evolve to an vendor-neutral community, get your competitors involved. It makes a huge statement and brings a lot of discipline to the originating organization.
4. Make sure you develop in the open. No more hallway meetings (if you have them, document them in a public forum). Have nightly builds of the code in the public code repo. Have one bug tracking database that is open to all. You might already be doing this but it is amazing how many aren’t.
I hope this helps.