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.

Contributors to this Guide


Stormy Peters

Senior Manager, Community Leads
Red Hat


Nithya Ruff

Senior Director, Open Source Practice
Comcast

Section 1

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, over 13,500 developers from over 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

Linux kernel developers contributing to each kernel release over time. Source: The Linux Foundation’s Linux Kernel Report, 2016.

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:

  • Attract talent. When you rely on open source software, the best place to find people who know the project inside and out is in the community for that project. By working publically in the community, you can attract people who see that they can get paid to work on their favorite open source project. When your employees are working side by side with these people every day, they can help you find the ones that will be a good fit for your company. (See our guide on Recruiting Developers)
  • Lower maintenance costs. Companies that start fixing bugs or adding new features and functionality to an open source project without contributing them back into the upstream project quickly learn that upgrading later to add new features or apply security fixes can be a nightmare that drives maintenance costs through the roof. Contributing your changes back into the upstream project means that they will automatically be included in future updates without incurring additional maintenance costs.
  • Influence the direction. In open source projects, new features and functionality come from contributions, and these contributions influence the direction of the project. If you want the project to have the functionality that is important to your organization, then you need to have active contributors who can any implement potential changes. Through your contributions, you can have some influence on the direction of the project as long as your changes are aligned with the goals of the project.

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.

Section 2

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 with a resulting 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:

  • Leader: At a minimum, there should be someone responsible for making the final decision about features, releases, and other activities. In some cases, this is a single person, for example, Linus Torvalds is the original author and has the final say on anything related to the Linux kernel. In other projects, there may be one or more committees responsible for various aspects of a project, like the Core Technical Committee that governs the Node.js project.
  • Maintainers: Most leaders delegate some of the decisions to people who are responsible for maintaining specific parts of the project, and in large projects, these maintainers may also delegate to people who are responsible for subcomponents of their portion. For example, Linus Torvalds delegates Linux kernel documentation decisions to Jonathan Corbet.
  • Committers: Some projects also have groups of people who have contributed to the project and are considered reliable and responsible enough to be allowed to commit directly to all or some parts of the project, rather than having to submit to a maintainer for review. Contributions from committers are still subject to review by maintainers or project leaders and may be reverted if there are any concerns about the contribution.
  • Contributors: Many people contribute to open source projects with code, documentation and other contributions. These contributions are usually subject to a review from an experienced committer and / or maintainer before the contributions are included.
  • Users: The most important group of people in an open source project is likely to be the ones who actually use the product, since users give the project a purpose and help it grow. These valuable members of the community can provide feedback about features, bug reports and more.

The community is one of the things that can make or break an open source project, and having a strong, vibrant, and diverse open source community is important to the 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.

Section 3

How contributions work

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

  • Projects have different guidelines with information about coding style, language, formatting, bug / ticket numbers, release timing, and more.
  • Some projects require signed contributor agreements, while others have signed-off-by or other processes.
  • The project may require patches to be posted to the mailing list, but others will ask for pull requests.

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, but if not, you may need to dig into the documentation or community section of the website to find the documentation. 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 will need to be 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 and 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, and 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.

Section 4

How organizations 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 in a way that is productive. Another challenge is that an organization can seem self-serving or troublesome if the needs of the organization aren’t aligned with the needs of the open source project, which 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, like 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, you should consider hiring someone who has already contributed and is known within the open source project you want to contribute to so that they can provide guidance to the organization about contributing in ways that are more likely to be successful in that project. Experienced contributors might be willing to act as mentors to help your employees as they pursue an open source career path. (See our guide on Recruiting Open Source Developers.)

In most projects, there are 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 can be provided by organizations, including infrastructure, funding, marketing, legal services, and much more. Many projects allow companies to sponsor or join a project in some more formal way by contributing funding and / or people to the open source project in exchange for some advisory role in the project or visibility for the company.

For example, the Node.js Foundation Board of Directors is made up 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 pay the project’s expenses and helps the project be successful.

A diverse group of organizations contributes to the Cloud Native Computing Foundation’s Kubernetes project.

Section 5

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 orienting yourself to the project 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.

  • Join the community. Each community will have slightly different ways of participating and different channels. Read the documentation to find out about the community and join the key communication channels. These channels may include mailing lists, forums, IRC, Slack, bug trackers, source code repositories, and more.
  • Lurk first. After you’ve joined the community, spend a significant amount of time lurking and reading the archives to soak up the culture before you start contributing. You’ll want to understand the norms and expectations of this community before you participate. The more time you spend reading and listening, the more likely it is that your first contribution will be well received.
  • Understand the governance. Read the documentation or website sections about project governance and leadership before contributing. You’ll want to understand how decisions are made within the project and who makes the decisions for various types of contributions.
  • Start small. Tackle a simple bug or documentation fix to start. It will be easier to learn the process and correct mistakes on a small contribution that isn’t critical to your organization’s needs. Make your mistakes on small and less significant contributions as you work up to the more complex contributions that your organization needs.

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.

  • Build relationships at events. Relationships on a personal and organizational level are an important aspect of participating in an open source community. One of the best ways to build lasting relationships with other project members is by attending events. There is nothing quite like meeting someone in person to help understand them as a human being on the other side of their email address or online handle. These events have a varied mix of people from project leaders and passionate users of the product to direct participation from many of the organizations through sponsorships, booths, and demos to show how the organization contributes. Most of these events would not be possible without financial support from sponsoring organizations that allow us to get together and learn from each other while helping to achieve the goals of the project.
  • Include the community early and often. Some organizations make the mistake of developing big chunks of code in house and then dumping them into the open source project, which is almost never seen as a positive way to engage with the community. The reality is that open source projects can be complex, and what seems like an obvious change might have far reaching side effects in other parts of the project. Any significant change is likely to require some community discussion before it moves to implementation to make sure that there are no side effects and that the solution is aligned with the broader goals for the project. While you discuss it with the community, it can help to focus on the problem, rather than a specific solution, before you invest too much time in the creation of a body of code. (See Jon Corbet’s guide on How to Participate in the Linux Kernel Community)
  • Contribute upstream. This refers to the practice of sending any changes you make to an open source project back to the original maintainers for inclusion into an upcoming release of the software. If your organization is new to open source, you may need to spend some time educating your employees about the importance of upstreaming contributions. In some cases, people may think it will be easier to do a quick and dirty patch to get something working in your infrastructure and not bother with cleaning it up and going through the process of getting it accepted into the upstream 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

Ibrahim Haddad, PhD @IbrahimAtLinux

Internally 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 was 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, and 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 got out of hand could 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.

Section 6

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 the overall business goals for the organization to figure out how your open source efforts fit into the broader strategies for your organization. (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 for the organization 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:

  • Why are these contributions important? It’s easy to jump in and start talking about all of the great things you plan to do, so don’t forget to include compelling arguments for why this work is important and strategic to the organization.
  • What open source projects do we use within the organization? Take some time to assess which open source projects are already in use across the entire organization to determine which ones are strategic to your business. A few places you might want to focus your assessment: critical business infrastructure (operations), development and deployment tools that impact your ability to release products, and software that is important for customer-facing products or services.
  • What projects should we target for contribution? Most organizations use many open source projects, so it’s important to make sure that your plan focuses on just the most important ones. Just because a project isn’t on the target list doesn’t mean that people can’t contribute to that project, it just means that it isn’t a critical focus for your organization. If an open source project is critical to your business and has the potential to cause significant downtime or disruption to your ability to serve your customers, it’s probably a good candidate for contributions.
  • What contributions are we already making? In some cases, you might already have people making changes to open source projects. They may be creating patches that are used internally, or they could already be contributing those patches back to the upstream project to avoid maintaining them. Spend some time talking to your internal teams to find potential contributions that you can build on while assessing whether or not you already have people on staff who might have the skills and interest to contribute.
  • Do we already have the relevant expertise, or would we need to hire for it? As discussed previously in this guide, it’s important to find people who have both the skills to create the contribution along with the people skills to work with the community to have the contribution accepted. If you already have people contributing to some of these projects, you might be able to use existing staff. If not, you should consider hiring someone who is already making successful contributions to the project. As with any plan, you need to make sure that you have the resources and hiring budget required for it to be a success.
  • What funding do we need for project sponsorships / corporate memberships? Look at the governance models for the projects you’ve selected to determine whether there is an option for corporate membership or sponsorship for the project or the foundation responsible for it. This provides funding to help the project be successful, and in some cases, it can help your organization get more involved in an advisory role or provide some influence into the project. Most open source projects have conferences, and in addition to funding for the project directly, you should also consider sponsoring the project’s conferences, which can be a great way to get the word out about your work and are a place to meet people that you might want to recruit.
  • How should we promote our open source efforts? Depending on your organization, marketing or promoting your open source contributions can be tricky, which is why it’s important to include this in your implementation plan to make sure that everyone knows how you plan to talk about your contributions publicly. Sponsorships and giving talks at the project’s conference or other events can be a good way to promote the work that you are doing and recruit contributors. In particular, don’t overlook your participation in local user groups where you have employees. Sponsoring those local groups and sending contributors to give talks can be a great way to recruit local people who are passionate about particular open source projects.
  • What contribution guidelines or processes do we need? These guidelines and processes should be less about rules and regulations and more about helping people be successful in making contributions to open source projects. It can help if people have guidelines and checklists to make sure that they have everything they need to make a successful contribution without running into licensing or confidentiality issues. Especially for new contributors, it can also help to have an internal review process available as a safe place to get feedback before making a contribution.
  • What training do we need to provide? It can help people to have training on best practices for making contributions along with some general open source training about licenses, governance, and norms associated with participation in open source communities. Training on conflict resolution, dealing with difficult people, and other people skills can also help avoid issues later. Your training plan should also include programs that provide experienced open source contributors as mentors for new contributors as a way to scale your efforts over time.
  • How will we determine whether the plan is successful? Every plan should have success criteria and a plan for measuring whether you achieved your goals. This should come directly out of your strategies to make sure that you are tracking those activities that are the most important for your organization, rather than the ones that are the easiest to measure. The open source GrimoireLab project is a good place to start if you need measurement and metrics tools. (See our guide on Measuring Your Open Source Program Success.)
  • Do we need an open source office to manage all of these efforts? All of this is a lot to think about, and it can help to have an open source program office or dedicated staff who are responsible for implementing the plan. At a minimum, you’ll want to have someone responsible putting processes and training in place, providing licensing guidance, answering questions from senior management or contributors, and communicating updates throughout the organization. (See our guide on Creating an Open Source Program Office.)

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/ practices specific to each project

Ibrahim Haddad, PhD @IbrahimAtLinux

Section 7

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. As an organization, if you want to influence the open source projects that drive the success of your business, you need to participate. Having a solid contribution strategy and implementation plan for your organization puts you on the path towards being a good corporate open source citizen. Good luck!

These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source networking group at The Linux Foundation. A special thanks goes out to the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: todogroup.org

This work is licensed under a Creative Commons Attribution ShareAlike 4.0 International License.

TODO Group
Sign up to get updates! Be the first to know when we add more open source guides and other content like this.