Participating in Open Source Communities

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.

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.)