Creating an Open Source Commercial Ecosystem

One way for an open source project to be successful is to have a thriving ecosystem of companies and products built around it. So what exactly is an open source commercial ecosystem and how can organizations help create and support sustainable open source projects? There are concrete ways to create confidence in a project’s long-term viability, encourage companies to create commercial products and services on top of open source projects, and re-invest in them with contributions, content, and other resources. These practices for enabling ecosystem development help set your projects up for success.

Table of Contents

Defining and creating a sustainable open source commercial ecosystem

Open Source Program Offices can interact with open source in two different ways:

A critical element of any business or product strategy that includes the use of open source software is the reinvestment of resources into the projects on which that strategy relies. This can lead to the creation of open source commercial ecosystems, which contribute to the viability and long-term sustainability for those projects. However, before a company will invest resources it must first have confidence in a project’s future prospects such that they’re willing to build commercial dependencies upon it.

While there are no guarantees that an open source project will be successful, there are ways to set it up for success through practices that help build commercial ecosystems around it. If you can accelerate this process, it speeds innovation, products get to market faster, and projects see faster adoption and use. It becomes a virtuous cycle as described by Accel Partners investor Ping Li.

Li has identified three phases of sustainability to focus on Project, Product, and Profit.

Once an open source creation has progressed through the three phases above, the virtuous cycle, driven by commercial dependency and reinvestment, is completed. At this point, the project has reached a steady-state of robust community development, bug fixes, and security updates are optimized through the many eyeballs on a project, lucrative partnerships can be formed, and much more.

Commercial dependency results in users, users buy solutions that generate profit, and profits increase resources to invest back in the community. A healthy community can also encourage partnerships and cross-pollination between projects that improve quality.

Ingredients of open source ecosystem success

Creating unique code that solves a problem is job number one in pursuing the optimal ecosystem for an open source creation. For example, OpenStack has helped countless organizations centralize resources in the cloud, resulting in cost reductions for in-house storage and compute resources. Likewise, Network Function Virtualization (NFV) technology is helping telecommunications companies reduce their reliance on costly proprietary components in their technology stacks.

Once the problem-solving creation exists, focus can be placed on building community and contributions, instilling confidence for commercial adoption, and adherence to open source culture.

Building community/ growing contributions

To build a healthy community around an open source project, developer training and recruitment are key, as are defining guidelines for inbound contributions, and disciplined development practices such as version management, build and test automation, documentation, on-ramps for contribution, and tracking issues and revisions.

You need to give people ways to get involved with your projects that don’t require them to have a Ph.D. or to have been working in a similar area for 25 years. You need ways for them to get involved quickly. That means that you need really good setup documentation, and it also means having active and healthy forums and responsive maintainers. – Ian Varley, Software Architect, SalesForce.

The Contributor Covenant is a rock solid code of conduct and contributor guidelines document that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. Likewise, organizations such as TODO Group at The Linux Foundation have extensive experience with setting inbound contribution guidelines.

Cloud Foundry’s Code of Conduct provides a strong example of how you can set out official guidelines for community members to follow. It specifies how community members can report incidents, what constitutes unacceptable behavior, and much more.

Instill confidence for commercial adoption

As an open source software project grows, a study shows it reaches an inflection point at which corporations want to participate, but aren’t necessarily comfortable with the intellectual property regime (or lack thereof) in the open source project. These practices help instill confidence in companies that may be hanging out on the fringes, waiting to commit to the project.

Adherence to open source culture

A downstream project with no ecosystem and community is not really leveraging the value of open source. An adherence to an open source culture is needed to succeed.

One of the most important things when building an open source community is making sure that your own processes are open. The more transparent you can make your decision-making processes, the more of a sense of ownership your community will have. You also want to make sure that your process doesn’t become a blocker. If your open source process for either inbound or outbound contributions is onerous, people will look to bypass the process or simply decide that contributing is too difficult. – Luke Faraone, Software Engineer, Dropbox

How to build an open source ecosystem

To build out open source ecosystems around your projects, you must focus on the following: governance; resources needed to use an OS project as a commercial dependency; tracking progress and making adjustments. Let’s look into each of these and the value they can bring to your commercial ecosystem strategy.

1. Establish a healthy governance system

It is essential to create a neutral structure that makes it easy for competitors to participate, and you should also consider whether external stakeholders should participate in the governance process. Your ecosystem is at its healthiest when governance is independent and receiving diverse contributions.

If you oversee the technical governance of your project, you may be far less qualified to make decisions regarding support, trademarking, or licensing. Likewise, you must separate technical and financial decision-making. Some of the best technical advancements take place in environments where moonshots are encouraged. Encourage technical contributors to aim for moonshots, and separate decision-makers can evaluate whether they are financially feasible.

One of the things that we’ve tried to engender in the Kubernetes community is the idea of a project over people or company. What’s good for the project is a separate question from what’s good for the companies that are involved with the project. When you end up with open source projects that are too tightly tied to a single company, really sticky issues can arise. – Joe Beda, Co-Founder of Kubernetes, and Co-Founder and CTO of Heptio

2. Evaluate resources

When partners or customers are deciding whether to utilize open source projects in their businesses, there are certain different resources they might evaluate or consider:

Look at how your community is interacting with itself, how new leadership is being grown and mentored, and how any pain points are evolving. As an example, Kubernetes right now has a pain point of very long review times on pull requests, so we’re getting started building out a mentoring program to help mentor new reviewers. Through the mentoring program, we’ll be able to track measurements and ideally see a decrease in the amount of time the review process takes. – Sarah Novotny, FOSS strategy at Azure

3. Track progress and make adjustments

Of course, your effort to create a healthy, commercial ecosystem around open source is a moving target. You must keep the people overseeing your governance structure involved, and keep your community providing feedback. “Listen, measure and adjust,” is good advice on this front. The members of your community can provide extraordinarily good feedback on how to make needed improvements and reach more people. Remember that each community is different.

Find metrics for each community that you’re working with. I tend to find metrics based on what a specific community is feeling as pain, and try to change those metrics for the better. There is no one magic assessment where if you look at six metrics, ranging from pull requests to contributor numbers, you can suddenly pronounce your community and ecosystem healthy. You could have a very small project that is extraordinarily healthy because it has half a dozen core contributors and a dozen people who are active but not maintainers. There might be healthy discussions, and pull requests might be handled in a speedy manner, and that might be an incredibly healthy community even though it’s not going to have a million stars or forks on GitHub. – Sarah Novotny, Open Source Wonk, Azure Office of the CTO

Example: Google Open Source Office

Many companies have built out successful open source program offices. The trend started in the technology industry as big players like IBM and Oracle realized that open source was seriously influencing the software ecosystem, but now companies of all stripes run open source programs. For example, Walmart Labs and Netflix have flourishing,highly structured open source programs and regularly contribute projects to the community. Open source programs are ubiquitous because open source is ubiquitous. In fact, according to the Future of Open Source Survey from Black Duck and North Bridge, a mere three percent of respondents, most of them from enterprises, said they don’t use any open source tools or platforms.

Among open source programs, Google’s is perhaps the most widely imitated of all. Google releases a lot of open source contributions, and company leaders are very frank about saying that the company gets business benefits from the ensuing community participation. Just witness the momentum that Android and Kubernetes have gained through community development and contributions. In a story on open source programs, John Mark Walker, the Director of Capital One’s Open Source Program Office, noted the following:

Technology vendors have no choice—collaborate or die. They can willfully disregard trends as long as they want, but ultimately it’s to their detriment. They would do well to borrow a few pages from Google and other TODO Group participants and take a holistic approach to open source ecosystems: Which ones are of strategic importance, and how can participation help go to market more quickly with new products and services? And for an extra dash of magic, Google has shown that embracing a mission outside of a company’s primary product focus yields results as well.

That couldn’t be more true, and this advice extends beyond just technology vendors. All companies could learn valuable lessons from Google’s open source program. Recently, Google launched a new home for its open source projects, processes, and initiatives. The site runs deep and has several avenues that are worth observing for anyone who wants to create a commercial ecosystem around open source.

The Google site features a directory of open source projects and a Community section that provides a good look at how training, events, and other efforts can harness energy from an open source community. However, the real crown jewel if you want to create a commercial ecosystem around open source projects is a section called Docs, which is billed as “our internal documentation for how we do open source at Google." From open source contributors and developers to companies implementing open source programs, this section of Google’s site has a motherlode of tested and hardened information. There are three primary sections of Docs:

According to Will Norris, former software engineer at Google’s Open Source Programs Office: “These docs explain the process we followed for releasing new open-source projects, submitting patches to others’ projects, and how we manage the open-source code that we bring into the company and use ourselves. But in addition to the how, it outlines why we do things the way we do, such as why we only use code under certain licenses or why we require contributor license agreements for all patches we receive.”

Google has released excellent open source process documentation, essentially laying out their internal policies and procedures. Their description of their internal ownership model is definitely instructive. I also highly recommend Karl Fogel’s Producing Open-Source Software book, available online under a Creative Commons license. – Luke Faraone, Software Engineer, Dropbox

A close look at how Google’s Open Source Programs Office works show that the company places substantial emphasis on community diversity and diverse programs that advance its open source communities. The concept of community is very much worth focusing on as you seek to build a healthy commercial ecosystem around open source.

An open source project has the best chance of growing into a successful ecosystem if the entire community around it takes an active role. This includes everyone from code committers, users, documentation writers, software vendors, platform vendors, and integrators. – Abby Kearns, Chief Technology Officer at Puppet


Contributors to this guide: