Participating in open source communities

Open source has become the de facto way to build software – not only in tech, but across diverse industries. As companies use open source code to build their own commercial products and services, they also see the strategic value of contributing back to those projects.

However, diving in without an understanding of those projects, their communities, and how they operate can lead to frustrations for those companies as well as the open source communities. Approaching open source contributions without a strategy can tarnish a company’s reputation in the open source community and incur legal risks.

This guide covers what it means to contribute to open source as an organization and how to become a good corporate citizen. Learn how open source projects are structured, how to contribute, why it’s important to devote internal developer resources to participation, and why it’s important to create a strategy for open source participation and management.

Table of Contents

Why contribute to open source?

It might be impossible to find an organization today that doesn’t benefit in some way from open source software. Some companies, like Intel, IBM, and Samsung, have entire open source programs devoted to contributing to open source communities. Other companies become consumers of open source almost accidentally when the software is brought in by system administrators or developers.

Many companies are commercially dependent on open source software that is critical to the success of the company, so it becomes advantageous (and necessary) to contribute to open source software projects. Since 2005, more than 13,500 developers from more than 1,300 different companies have contributed to the Linux kernel, and it is just a single project!

“For many larger projects, we know that most of our contributors are going to be people who work at companies that need to use projects like Ceph and Gluster. We have customers, and customers often contribute to software because they’re using it. We consider both the individual participation and the company participation as success stories.” Stormy Peters – Senior Manager, Community Leads at Red Hat

While some of these contributions may come from organizations that just want to give back to the community, there are plenty of strong business reasons to contribute to the open source software projects used within your organization. Here are just a few of the benefits of contributing:

However, you need to be a bit careful about how you engage these communities to avoid perception problems or other issues with your contributions. Every open source project has slightly different norms, expectations, and processes that need to be thoroughly understood before your organization should begin contributing. This can be achieved by having someone join the community and spend some time observing, or you can hire someone who already has a proven track record of participation in the community.

How open source projects are managed

At first glance, open source projects may look chaotic. People who are completely new to open source software often wonder how a group of random people can throw code together and end up with a stable product used by millions of people. It doesn’t take long to realize that this isn’t how open source software works. Almost every open source project has some structure, and the best projects will have the structure and project governance clearly described on the project website or in the documentation. (GitHub’s guides for contributors have a great overview of project anatomy.)

While the exact governance model varies widely across projects, there are some commonalities:

Community can make or break an open source project. Having a strong, vibrant, and diverse open source community is important to a project’s success. All of the people in the roles listed above are part of this community, along with people filling other critical roles in the project for documentation, marketing, user support, and so much more.

How contributions work

The contribution process varies depending on the open source project. For example:

These are just a few ways that the contribution style might differ, so it’s important to start by reading the documentation about how to contribute. Many projects will include this documentation as a CONTRIBUTING or README file in the home directory of the code repository. Otherwise, you may need to dig into the documentation or community section of the website to find it. It’s also a good idea to read some of the other documentation, community guidelines, and code of conduct if they are available to make sure that you understand exactly what behavior is expected within a particular project.

If you are a first-time contributor to a project, you might consider finding a mentor or an experienced project member who can review your work and provide you with some feedback as you prepare your first couple of contributions.

After submitting a contribution using the process described in the documentation, you must remain available to respond to feedback. Common feedback would include questions about how something works or why you chose a particular approach, along with suggestions for improvements or requests for changes. This feedback can be tough sometimes, so it helps to assume that the feedback is in the spirit of making your contribution better. Avoid getting defensive. You may need to go through several rounds of resubmission and additional feedback before your code is accepted, and in some cases it may be rejected. There are many valid reasons why something might not be accepted, so don’t take it personally if your code is rejected. If possible, try to learn more about why your contribution was not accepted to help increase the chances of getting your next contribution included.

Keep in mind that if your contribution was accepted, you may be expected to maintain it over the long-term. This is especially true for large contributions, new features, or standalone code, like a driver for a specific piece of hardware. For small contributions and bug fixes, it is unlikely that there will be any long-term maintenance expected.

What it means for an organization to contribute

Over the years, the relationship between some open source projects and the companies or other organizations that use or contribute to those projects has been a bit rocky. Organizations are often accustomed to forming business relationships in ways that don’t usually work for open source projects, so some organizations struggle to understand how to contribute productively.

Another challenge is that an organization can seem self-serving or troublesome if its needs aren’t aligned with the needs of the open source project. This can cause an open source community to become suspicious of the motives behind an organization’s contributions. In the past, some organizations have tried to make huge contributions that weren’t aligned with the goals of the project, and in certain projects, this history may make it harder for the community to trust organizations.

However, there are also many success stories. One is the Linux kernel, where organizations contribute in meaningful ways. The most common and easiest way for an organization to contribute to an open source project is to pay employees who have a significant amount of time devoted to participation in open source projects. In order for this to be successful, those employees need to understand the contribution processes and norms within that project to increase the chances that their contributions will be accepted. If your organization is new to a project or new to open source, consider hiring someone who has already contributed and is known within the open source project you want to contribute to; they can provide guidance on contributing successfully. Experienced contributors might be willing to mentor your employees as they pursue an open source career path. (See our guide on Recruiting Open Source Developers.)

Most projects offer other ways for organizations to participate, but these are likely to vary by project. Open source projects and the foundations that support them often need resources that organizations can provide, including infrastructure, funding, marketing, legal services, and much more. Many projects allow companies to sponsor or join a project more formally by contributing funding and/or people in exchange for some advisory role in the project or enhanced visibility.

For example, the Node.js Foundation Board of Directors consists of representatives from corporate members, a representative of the Technical Steering Committee, and representatives elected by the individual membership class. The corporate members comprising a portion of the board pay anywhere from $5,000 for a small organization to $250,000. While each project has a slightly different approach to sponsorship or membership, funding an open source project helps cover expenses and fund its continued success.

How to be a good corporate citizen when participating in an open source project

If there is an underlying theme for this guide and for open source in general, it’s that every project is different. Every time you join an open source project, you’ll need to spend some time finding your way around and learning how it works.

For organizations participating in an open source project, each employee will need to go through this learning process for each project they participate in. Here are a few things that can help you get started off on the right foot.

Now that your organization has figured out how to make those first small contributions, you’ll need to build on those contributions to begin making larger contributions and having a bigger impact in the project.

However, over the long-term, the quick patch that needs to be tested, updated and reapplied during every upgrade cycle is almost always going to take more time and effort than upstreaming it. This behavior can also be perceived as selfish within the community, since others might also benefit from your fixes, so it could also harm your organization’s reputation in open source communities.

Best Practices to Contribute Code Upstream

Internal to your organization

  1. Decide to upstream for the right reasons.
  2. Design and implement code with upstreaming in mind.
  3. Adopt an “upstream first” policy. Submit patches upstream first, and consume in your own products downstream.
  4. Keep your developers involved in the open source project, even if it is just a soft involvement.

Externally/toward the project

  1. Ensure that your contributions are useful to others.
  2. Follow proper coding style.
  3. Work within the submission processes of the project.
  4. Provide documentation and explanation around your contributions.
  5. Listen to feedback and act upon it.
  6. Be patient and continue to rework the code until acceptance.

One of the most challenging things for organizations is understanding how influence is earned within open source projects. Just because your organization is a big deal, doesn’t mean that you should expect to be treated like one without earning the respect of the open source community. Influence comes from participation. Some of the people contributing to an open source project will eventually earn positions of greater influence and leadership over time after they prove that they are reliable and responsible.

You should also expect some conflict and be ready to handle it professionally. The review process can get quite heated as people disagree with decisions, approaches or styles of contributions. It’s important to remain calm and professional while making sure that the feedback stays focused on the contribution rather than becoming personal. Keep in mind that your participation in an open source project is public and could remain on the internet forever, and one heated discussion that gets out of hand can come back to haunt you as an organization or an individual at a later date. Because all of this participation is very public, offering some training about handling difficult people and resolving conflict for your employees might be a good idea.

How to create your open source contribution strategy

Having a deliberate and thoughtful open source contribution strategy not only helps guide your employees when participating in open source projects, but it can also help justify this participation to senior management within your organization. It’s important to start by looking at your organization’s overall business goals to figure out how your open source efforts fit into your broader strategies. (See our guide on Creating an Open Source Business Strategy.) By clearly tying your open source contribution strategy to the organization’s strategic efforts, you can show senior management why the work is important and help your employees understand the impact of their contributions.

“Support from leadership and acknowledgement that open source is a business critical part of your strategy is so important. You should really understand the company’s objectives and how to enable them in your open source strategy.” Nithya Ruff – Senior Director, Open Source Practice at Comcast

Once you’ve developed some goals and strategies that are aligned with the business goals, you’ll need to develop an implementation plan. These questions will help you think about some of the things that might need to be addressed in your plan:

11 Tips for Mastering Open Source Contributions

How to build a healthy environment for open source contributions in your organization:

  1. Establish a policy and process to guide open source contributions
  2. Set up a team to oversee approvals for all open source contributions
  3. Focus contributions in the areas that will enable your technologies
  4. Provide the needed IT infrastructure and tooling for contributors
  5. Offer training to your staff on contribution best practices
  6. Track contributions, measure impact, improve, and communicate
  7. Establish a mentorship program to train less experienced developers
  8. Provide contribution guidelines, how-tos, do’s and don’ts
  9. Make open source legal support accessible to developers
  10. Hire from the open source communities you value the most
  11. Always follow the community processes and practices specific to each project

Final Words

Open source projects are here to stay, and they play a critical role in the ability for most organizations to deliver products and services to customers. If your organization wants to influence the open source projects that drive your success, you need to participate. Having a solid contribution strategy and implementation plan puts you on the path towards being a good corporate open source citizen. Good luck!



Stormy Peters Senior Manager, Community Leads Red Hat

Nithya Ruff Senior Director, Open Source Practice Comcast