"If you love something, set it free. If it comes back to you, it's yours. If it doesn't, it never was."
Multi-vendor open source communities enable companies to lower development costs and gain access to wider addressable markets. This article describes best practices for companies considering this approach. First, the different types of open source business strategies are examined along the types of participants that contribute to the communities that support them. Next, five best practices are detailed to show how companies can maximize their engagement with open source communities. Finally, the importance of foundations in implementing multi-vendor open source communities is discussed.
Software companies are adopting open source strategies to drive lower development costs or expand an addressable market for their products. A key success factor for a company's open source strategy is how to engage with an open source community. It is often the community that will help provide resources to lower the development cost or create an expanded market of potential customers. Therefore, a company needs to understand what the strategies that will encourage a growing and engaged community.
Traditional open source: these are the stereotypical open source projects started by a individual developer or group of developers working on interesting technology. Corporate involvement is limited.
Open source distributors: based on the success of early traditional open source projects, like Linux, companies began to create business around projects and contribute resources back to the core of these projects. Red Hat is the most successful company using this strategy.
Single-vendor open source: software companies looking to disrupt an existing market will sometimes use an open source approach to change the market dynamics. These companies will establish an open source project and build a community around the project and technology. Then, they typically sell services and support or value-add products to enterprise customers. The company maintains strong control of the open source project and technology.
Multi-vendor open source: this type includes open source communities that involve multiple organizations working together on an open source project. The vendor collaboration typically focuses on areas that are not part of the participating organization’s core asset.
This article will focus on the best practices for creating a multi-vendor open source community. More and more companies are realizing that the multi-vendor open source community is the best option for achieving their business strategies. Having more companies involved provides incremental resources to work on the project and creates more incentive for companies to create a market around the technology.
Different Types of Community Participants
There are different types of participants in an open source community that help contribute to its health and success:
Users: these participants are individuals or corporations that make use of the technology for their own internal purposes. Typically, their motivation is to improve productivity.
Adopters: these participants add value to the project technology. Companies will often incorporate open source technology into commercial products or build services and components that work on top of the open source technology.
Contributors/committers: these participants are individuals and companies that actively work to develop and advanced the project technology. This type of participant helps lower the development costs of the project. Typically a subset of users and adopters form the core pool of committers and contributors. A strong community of users and adopters is essential for a strong contributor/committer community.
Successful open source communities appeal to all types of participants. In fact, there is often a progression of users to adopters to committers that helps create more core contributors working on the open source project. Therefore, it is important to consider what best practices and strategies are needed to encourage different types of participants.
The starting point for any successful open source project is a concept that creates something useful and has high-quality code. However, great code is not always sufficient to create an environment of collaboration and contribution. The following are five practices companies need to consider following when creating a multi-vendor open source community. These practices are based on the experience of the author observing the dynamics of open source communities and implementing many of these practices in his work at the Eclipse Foundation.
1. Engage a wider community by using a permissive or weak copyleft license. The choice of an open source license can limit participation. In particular, licensing a project under the GNU General Public License (GPL) can limit the number of organizations willing to participate as adopters. For example, a company that wants to use the technology in a commercial licensed product will be excluded due to the terms of the GPL. Using a permissive license, like the Apache Software License (ASL), or a weak copyleft license, like the Eclipse Public License (EPL), makes it easier for a wider range of companies to engage as adopters.
2. Earn the trust of the community by not requiring copyright assignment. Mature open source communities will have contribution agreements that stipulate the terms of a contribution. The basic term is under which license the contribution is being provided, but some contribution agreements will request the contributor to assign the the copyright ownership to a vendor. For single–vendor-dominated communities, copyright assignment was required to allow the receiving vendor the ability to create revenue streams by implementing a dual license for the project code. MySQL is the most common example of this strategy. Unfortunately, this approach creates a revenue stream that is unique to one company. In turn, this inequality creates a barrier to involvement by other companies.
Successful multi-vendor open source communities do not require copyright assignments to a single for-profit company. This is because organizations and individuals want to participate as equals in a community. If one entity is aggregating a special right, in this case copyright to the code, it creates a two-tiered system. Copyright to contributions should be retained by the originating contributor or a license should be granted to a not-for-profit foundation. For example, copyright of contributions to the Linux kernel or projects at the Eclipse Foundation remain with the contributor.
3. Be truly open: develop in the open. In an open source community, the development teams need to truly work in the open. They need to be using public issue trackers, public code repositories, and public build systems, and they must not be developing behind a firewall. Multi-vendor communities inherently require distributed development, but committing code to a public code repository once a month is not sufficient.
The vendor’s development team also needs to make sure updated project plans are published and technical discussions occur in a public forum, not a hallway in the vendor’s office. The development team needs to start believing that they are part of a larger community, not a traditional vendor-oriented development team. True open development allows potential participants to observe and learn how the community operates before beginning to participate. It also allows the existing participants to understand the direction of the project.
4. Have a clear policy on trademarks. The organization that controls the trademark for the project name can ultimately decide how the name is used. For instance, it controls who can use the trademark in a commercial product name, a company name, a service, or even a conference name. In the case of a fork of the project, the organization that controls the trademark controls where the project name can be used after it has been forked.
Successful open source communities define trademark guidelines that describe how the trademarks can and cannot be used. These trademark guidelines should allow all organizations the same rights and privileges. The actual trademark may be controlled by a not-for-profit foundation or a vendor may agree to equal access for all participants.
5. Implement a vendor-neutral governance structure. Successful communities have well-defined rules for making decisions. The rules determine, for example how decisions are made on admitting new committers, who decides the project roadmap and project release schedules, how technical architecture decisions are made, etc. These rules also describe the process to change the rules, strategy, and purpose of the community. Over time, all communities need to adapt, so it is important to define how things can be changed.
A successful open-development community makes these rules visible in the form of a governance document. This allows everyone to know what to expect. A truly vendor-neutral governance structure ensures that no single organization is provided extra decision-making influence within the community.
Implementation: The Role of Foundations
These best practices can be implemented in a variety of ways and to different degrees. Many successful open source communities are set up and managed by for-profit companies, such as Red Hat's Fedora and JBoss, VMWare's SpringSource, and Google's Android. However, open source foundations have demonstrated a scalable model for creating multi-vendor communities. Organizations such as the Apache Software Foundation, Eclipse Foundation, Linux Foundation and many others have implemented many of these best practices for their communities. Starting a new open source project under the auspice of one of these foundations allows for a project to start in less time and at a lower cost than without the help of the foundation, plus it also offers the benefit of leveraging an existing community.
Multi-vendor open source communities are the future of corporate open source. This model best allows companies to leverage communities by collaborating on development and thereby lowering their development costs and gaining access to a wider addressable market. To create a successful multi-vendor community, there needs to be a level playing field for all participants. No one company should be in a position to veto decisions, hold an institutional advantage on any potential profit, or control the intellectual property. Development teams also need to work in an open community, not behind a firewall. Vendors that participate in successful open source projects win by giving up control and following best practices to engage with their communities.