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?
- How open source projects are managed
- How contributions work
- What it means for an organization to contribute
- How to be a good corporate citizen when participating in an open source project
- Best practices to contribute code upstream
- How to create your open source contribution strategy
- 11 tips for mastering open source contributions
- Final words
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:
- 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 publicly 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 identify good fits for your company. (See also: 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 an open source project, new features and functionality come from contributions that inevitably influence the project’s direction. If you want a project to offer functionality important to your organization, then you need to have active contributors who can any implement potential changes. Through your contributions, you can influence the project’s direction (assuming that your changes align with the project’s goals).
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.
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:
- Leader: At a minimum, there should be someone responsible for making final decisions about features, releases, and other activities. In some cases this is a single person – for example, Linus Torvalds is the original author of the Linux kernal and has the final say on anything related to its evolution. 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. 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.
- Contributors: Many people contribute to open source projects with code, documentation and other enhancements. These contributions are usually subject to a review from an experienced committer and/or maintainer before they are included.
- Users: Arguably the group most important to an open source project’s growth and development. Users give the project a purpose and help it evolve. These valuable members of the community can provide feedback about features, bug reports and more.
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.
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.
- Projects 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. 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.
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.
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.
- Join the community. Each community has slightly different participation modes and channels. Read the documentation to find out about the community, and join the key communication channels, which 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 know who makes decisions about different types of contributions, and how.
- 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 better understand them as a human being on the other side of their email address or online handle. These events attract a varied mix of people, from project leaders and passionate users to organizations that support projects through sponsorships, booths, and demos. 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.
- Decide to upstream for the right reasons.
- Design and implement code with upstreaming in mind.
- Adopt an “upstream first” policy. Submit patches upstream first, and consume in your own products downstream.
- Keep your developers involved in the open source project, even if it is just a soft involvement.
- Ensure that your contributions are useful to others.
- Follow proper coding style.
- Work within the submission processes of the project.
- Provide documentation and explanation around your contributions.
- Listen to feedback and act upon it.
- 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.
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:
- 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.
- Which 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.
- Which 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 are the contributions we are 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 do 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. In addition to funding projects directly, consider sponsoring related conferences. These can be great for getting the word out about your work and for meeting people who 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. Therefore, it’s important to include this in your implementation plan to make sure that everyone knows how you discuss your contributions in public. 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 kinds of training must we provide? Training on best practices for making contributions, along with some general training about open source licenses, governance, and norms associated with participation in open source communities, can be very useful. Training on conflict resolution, dealing with difficult people, and other people skills can also help avoid issues later. To scale your efforts over time, include in your training plan some programming that provides experienced open source contributors as mentors for new contributors.
- How will we determine whether the plan is successful? Every plan should include 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 How to Measure Open Source Program Success.)
- Do we need an open source office to manage all of these efforts? Having an open source program office or dedicated staff who are responsible for implementing the plan can help you navigate this terrain. 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.)
How to build a healthy environment for open source contributions in your organization:
- Establish a policy and process to guide open source contributions
- Set up a team to oversee approvals for all open source contributions
- Focus contributions in the areas that will enable your technologies
- Provide the needed IT infrastructure and tooling for contributors
- Offer training to your staff on contribution best practices
- Track contributions, measure impact, improve, and communicate
- Establish a mentorship program to train less experienced developers
- Provide contribution guidelines, how-tos, do’s and don’ts
- Make open source legal support accessible to developers
- Hire from the open source communities you value the most
- Always follow the community processes and practices specific to each project
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!
Contributors:
These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source program 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