Recently a colleague from Apache commented to me that there are no such things as open-source companies. Instead, he identified a few types of companies that “make money out of open source”:
• via expertise in consultancy
• hoarding copyright ownership for a big sale
• providing additional value on top of open-source products
• licensing fear, uncertainty and doubt (choosing GPL to make users who fear GPL pay)
As the vice president of the Apache Synapse project and the cofounder of an open-source company, I regularly think hard about what an “open-source” company means. While I agree that examples of that list of types exist, I also think there is another approach.
Michael Porter, the Harvard Business School professor, is widely considered to be the leading expert on competitive strategy. He identifies three generic strategies for competitive advantage: cost, differentiation and focus.
Differentiation was obviously the first strategy for open-source companies—for example when MySQL was the only commercial open-source database. However, that time is over. There are very few areas where you can point to just one open-source project and one company.
Cost is seen as the next competitive strategy for open-source companies. However, this is a weak strategy for selling complex software. Usually the value of the software to an enterprise is much higher than the actual cost, and the negative value—the risk associated with the project failing—is many times the cost of the software. What this means is that few enterprise companies choose software with cost as their first criteria.
That leaves focus. What is a focus strategy? A focus strategy is where you shape a company around a focus: making every part of your business focused on that single-minded aim. Michael Porter has been vociferous in the support of this model, and I believe it’s the only one that is sustainable. It means focusing on using every aspect of open source to ensure that a company delivers something better and different from other software companies.
One key aspect of the focus strategy that Porter points out is that you cannot be the “everything to everyone” company with a focus strategy. Focusing on one area inherently rules out some customers, but it drives other customers to you more strongly.
Here are some of the ways that I believe a company must apply its focus if it is to have a truly sustainable open-source model.
It is about open development. Open source is not just about the end product (the code), but the process—the development model. Companies that have created code and then published the code as open source have rarely succeeded. Code should be developed in the open with a public code repository, public mailing lists, even a public “architecture” discussion list to define the overall architecture and approach.
It is about community. A community is not measured in downloads. A collection of people who only consume the software is not a community. Having users contribute, help each other, and submit code and patches, involving the community in major decisions, and inviting them to participate in the design process as well; these all build a real participation that strengthens the code and the company.
It’s also about participation in multiple communities, such as Apache and Eclipse, and not just using those communities, but actively contributing to them as well.
It is about the license. GPL is a great license for two different kinds of models. In Irish Music, there is a term: “pure drop,” which means pure, unadulterated Irish music, with nothing imported from outside such as rhythm guitar backing.
Pure-drop music is beautiful and very hard to play well. I think there is a similar community in the open-source world, a community where no proprietary code is used at all. In the pure-drop open-source community, GPL is king. If everything you do is GPL, then there can be no contamination. However, this community isn’t a great community to build a commercial business on, and this is not the focus of companies that use the GPL license.
The second model where GPL is used is to protect code and force companies to buy a commercial (i.e. non-open-source) license. The logic is simple: Most companies don’t like GPL. The company that owns the copyright to a GPL codebase can re-license the code under a different license to those willing to pay.
However, the GPL does not build the community outside of the pure-drop adherents. For example, most companies do not allow their employees to work on and contribute to GPL projects. We have found that the Apache Software License v2 does help build a collaborative community around our projects, and we are now seeing a few companies build a successful business on a open, non-viral license that is used to permeate the entire business model. The Apache license is a great license for collaboration.
It is about the processes your company implements. Here are a few simple examples:
Open-source projects don’t implement features just because they are on some feature list; they wait until there are user involvement and requirements. An open-source company needs to implement the same strategy. Doing so results in much shorter development cycles focused on specific features and improvements, together with much better scenarios and a focus on the most important scenarios.
Open-source projects don’t have separate support teams and separate test teams. Developers are much more rounded; they interact with users, provide support, and write test cases as well as write code. Open-source companies can benefit by implementing this model so that the development team not only provides support, but also goes onsite with customers, and writes technical articles and blogs.
Why is this beneficial? Firstly, issues are resolved much faster. The second benefit is that developers have a much better understanding of real customer pain points than the average developer in a development lab.
Many open-source projects (especially those at Apache) operate on a principal called meritocracy. This is the idea that the projects are led by the people who actually earn that right through merit and successful effort. Another way I’ve heard this described is as a do-ocracy: The people who have to implement the code make the decisions.
I personally have been in many arguments with the youngest developers in my organization, and their ideas and input are given as much space as anyone else. We all benefit when the project leaders are those who have simply proven their worth irrespective of age, time served, golf club membership, or any of the other proxies for merit that rule in so many other domains.
So how would I define an open-source company? My definition is that the company is committed to using open source to create an ongoing competitive advantage—not just in one aspect (i.e. code licenses), but in every aspect of that company’s operations. And yes, there are a few of us around.
Paul Fremantle is CTO and cofounder of WSO2, and vice president of Apache Synapse.
