Table of Contents

Corporate Participation in Open Source

Lighthouse in spring. Used on a post about Corporate Participation in Open Source.

Corporate participation in open source

Using open source software (OSS) to develop applications is now standard practice, not just in tech but in many other industries too. As companies adopt OSS for their products and services, they’re realizing the importance of contributing to these projects. Corporate participation in open source projects may result in the life or death of software critical to businesses. Sometimes, organizations don’t understand how these projects work, creating unnecessary challenges and tension with OSS communities. Contributing without a thoughtful strategy can harm a company’s reputation in the open source community and put them at legal risk.

In this guide, we will explore how organizations can contribute to OSS and be responsible corporate citizens. We’ll cover project structure, the contribution process, the importance of dedicating development resources to OSS, and creating a solid strategy for open source participation and management.

Why contribute?

Almost every organization benefits from open source software in some way. Some big companies like Google, Meta, and Samsung have created specific programs to help the open source community. However, other companies may start using OSS without intending to when their administrators or developers introduce it to the organization.

Many companies rely on OSS—Kubernetes, Apache, Linux, etc—to sustain their business operations. Consequently, corporate participation in open source projects—specifically contributing to OSS—becomes a necessity as well as a strategic advantage.

While some organizations may contribute to open source projects out of a desire to give back, there are also many business reasons to do so. Contributing can help lower maintenance costs, attract talent, and influence the direction of the OSS used by the organization.

🌸👋🏻 Let’s take this to your inbox. You’ll receive occasional emails about whatever’s on my mind—offensive security, open source, academics, boats, software freedom, you get the idea.

Decrease maintenance costs

Contributing to OSS can lower maintenance costs. If a company modifies an OSS project but doesn’t share those changes with the original project’s developers, they may face difficulties when trying to update the project later. This can be expensive and take a lot of time. However, if the company contributes its changes back to the original project, those modifications will be included in future updates without incurring extra maintenance costs.

Attracting talent

Additionally, contributing to open source software can help a company attract skilled professionals. The most knowledgeable people on an open source project are often part of its community. Thus, working within that community can be a great way to connect with talented individuals who are passionate about the project. By working alongside these professionals, a company can also identify good candidates for hiring.

Influence direction

When you contribute to an open source project, you have the chance to shape its future. OSS projects are often developed through contributions. As a result, corporate participation in open source can influence the direction of these projects by actively implementing and contributing changes. By contributing, organizations can guide the project to meet their specific needs and align with the project’s overall goals.

When working with OSS communities, it’s crucial to consider how your organization’s contributions might be perceived and to avoid any possible problems. Before your organization starts contributing, it’s important to fully understand the norms, expectations, and processes unique to each project. You can gain this understanding by having someone from your organization join the community and spend time observing. Alternatively, you can hire someone who has experience participating in the community to help guide your organization’s involvement.

Open source project management

At first, open source projects can seem chaotic to people who aren’t familiar with them. They might wonder how a bunch of random people can collaborate to create a stable product used by millions of people. But in reality, open source projects are usually well-organized and have a clear structure. The best projects have a defined governance and structure. Each project’s management is often explained on its website or documentation. Even though the governance model can differ among projects, there are some common elements: leaders, maintainers, committers, contributors, and users.


Every successful open source project should have a clear leadership structure in place. At a minimum, there should be an individual who is responsible for making final decisions about features, releases, etc.. In some cases, this may be a single person, such as Linus Torvalds, who is the original author and has ultimate authority over the Linux kernel. Alternatively, there may be one or more committees in charge of various aspects of the project, such as Python’s Sprint Committee, which governs the project’s development sprints. In other projects, like Debian, there are a number of individuals, committees, and teams, each with its own area of responsibility.

Debian structure

  • The Debian Project Leader (DPL) is elected by the Debian developers to represent the project to the outside world. They also oversee the general direction of the project.
  • The Technical Committee (TC) is responsible for resolving technical disputes within the community, making decisions about technical standards and policies, and overseeing the development of Debian.
  • The Release Team is responsible for coordinating the release process of new versions of Debian, including deciding on the release schedule, freezing the distribution, and managing the release itself.
  • The Security Team is responsible for maintaining Debian’s security by identifying and fixing vulnerabilities. The Security Team also providing updates and patches for security issues.
  • The Quality Assurance (QA) Team is responsible for ensuring the quality of the distribution, by testing software packages and reporting bugs and issues to the developers.
  • The Legal Team is responsible for ensuring that Debian complies with all relevant legal requirements. This team manages issues concerning licensing and copyright.
  • Others: There are many other teams and committees involved in the development of Debian, such as the Installer Team, the Accessibility Team, and the Med Team, among others. Each team plays a critical role in the development and maintenance of the Debian distribution.

It is important to remember that each OSS project will have a unique leadership and organizational structure. Pay careful attention to each project that your organization contributes to.


In most cases, leaders of open source projects delegate certain decisions to individuals responsible for maintaining specific areas of the project. In larger projects, these maintainers may also delegate to individuals who oversee sub-components of their respective portions. For instance, David Heinemeier Hansson delegates Ruby on Rails issue management decisions to Adam Hess.


In certain projects, there are groups of individuals known as “committers,” who have contributed to the project. Committers are considered to be trustworthy and accountable enough to be granted the ability to commit (as in git commit) directly to some or all components of the project without having all of their contributions reviewed by a maintainer. However, committers’ contributions remain subject to review by maintainers or leaders. Additionally, contributions may be reverted if there are concerns about them.


Open source projects rely on the contributions of many individuals, who provide code, documentation, and other materials to support the project. Typically, these contributions are reviewed by experienced members before they are pushed upstream. This helps ensure the quality and compatibility of contributions with the project’s goals and standards.


The group of people who use the product are likely the most crucial contributors in an open source project, as they provide a sense of purpose to the project and aid in its growth. These individuals can offer feedback on features, report bugs, and provide other types of useful feedback.

The success of an open source project often hinges on the strength and vibrancy of its community. It’s essential to cultivate a diverse and inclusive community to ensure the project’s continued growth and success. This community includes the individuals holding leadership, maintenance, and contributor roles, as well as those responsible for critical tasks such as documentation, marketing, and user support. Everyone in the community is important and helps the project move forward.


The process of contributing to an open source project can differ depending on the project itself. First, each project has specific guidelines that provide information about coding style, formatting, language, bug/tickets, release timing, and so on. Second, some projects mandate that everyone sign contributor agreements, while others require different processes or nothing at all. Third, one project may require that patches be shared via a mailing list, whereas others might require pull requests.

Open source projects can have different ways for people to help out, so it’s important to check the instructions first. Usually, you can find these instructions in a file called CONTRIBUTING or README stored in the project’s main/root folder. If you can’t find the instructions right away, you might need to look around in the project’s documents or community section. It’s also a good idea to read things like the community rules and codes of conduct so you know how to behave. This helps make sure your contributions match what the project needs and wants.

If you are a new contributor on a project, many OSS veterans recommend finding an experienced member who can provide feedback and advice on your initial contributions. This can help you better understand the project’s guidelines and requirements and ensure that your contributions align with the project’s goals.

Read more: Navigating the Open Source Security Community


Once you submit your contribution, you prepare to respond to feedback. Feedback can include inquiries about how a feature works, why you chose a specific approach, and requests for changes. It can be difficult to receive feedback, but remember that it is intended to improve your contribution. You may need to go through multiple rounds of re-submission and feedback before your code is accepted. In some instances, contributions may be rejected, even after multiple rounds of feedback. There are many legitimate reasons to reject contributions, so don’t take offense if this happens to you. At the same time, try to learn about why the contribution wasn’t accepted. Hopefully, your reflection will increase the likelihood of having your next contribution incorporated.

It’s essential to recognize that if your contribution is accepted, you may be responsible for maintaining it over the long-term, particularly for significant contributions such as new features or standalone code (e.g., driver for specific hardware). However, minor contributions or bug fixes typically do not require long-term maintenance. In general, it’s crucial to understand the level of maintenance your contribution may require before making it, to ensure that you can fulfill any expected responsibilities.

Historical context of corporate contributions to open source software

In the past, the connection between open source projects and the organizations that contribute to them has been somewhat tense. Many businesses are accustomed to creating strategies and processes that are typically unsuitable for open source projects. Occasionally, misaligned strategies result in some organizations finding it difficult to determine how to make constructive contributions.


One of the challenges an organization can face when contributing to OSS is the perception that their actions are self-serving or disruptive, particularly if their goals do not align with those of the project. Such misalignment can raise suspicion within OSS communities, causing them to question the motives behind an organization’s contributions. In some cases, organizations have attempted to make significant contributions that do not align with the project’s goals, which can make it more challenging for the community to trust them. As such, it’s essential for organizations to ensure their contributions align with the project’s objectives and values to avoid negative perceptions from the community.

At the same time, many open source projects have experienced successful relationships with organizations, with the Linux kernel being a notable example. An easy and common way for organizations to contribute to open source projects is by paying employees who have sufficient time and expertise to participate in the projects. To maximize the chances of success, employees must understand the norms and processes of the project they wish to contribute to. If your organization is new to open source or a particular project, hiring someone who has already contributed can provide valuable guidance. Additionally, experienced contributors may be willing to mentor your employees to help them succeed in an open source career path.


There are various ways in which organizations can participate in open source projects, though these opportunities may differ from one project to another. Projects and the foundations that support them often require resources that companies can offer, such as infrastructure, funding, marketing, legal services, and more.

Many projects permit companies to sponsor or become more involved in the project formally by contributing funding or personnel in exchange for an advisory role or increased visibility. However, the avenues and levels for participation and involvement vary by project. Sponsor participation is often explored on a case-by-case basis.

Each open source project has its unique approach to sponsorship or membership, and funding them can help cover expenses and ensure their continued success. As an example, The Rails Foundation’s Board of Directors includes representatives from founding corporate members who each contribute around $400,000/year. Yet, the board is chaired by the creator of Ruby on Rails, David Heinemeier Hansson. There are opportunities for new contributing corporate members, and their contributions are dealt with on a 1-1 basis.

Corporate citizenship in open source

Again, when joining a project, it’s important to take the time to familiarize yourself with the project and its processes. Likewise, for organizations participating in open source projects, each employee will need to undertake this learning process for every project they contribute to. Here are a few things that can help get your organization on the right track:


Get involved

Allow and encourage employees to join the key communication channels, mailing lists, forums, bug trackers, repositories, and more. Additionally, read the documentation to learn about the community’s participation guidelines and channels.


Familiarize yourself with project governance. Before making any contributions, take time to read through the project’s documentation or website sections on governance and leadership. This will help you understand the decision-making process and who is responsible for different types of contributions.


Lurk and observe the community for a while before contributing. Spend some time reading and reviewing the archives to absorb the culture and understand the community’s norms and expectations. The longer you listen and learn, the better your first contribution is likely to be received.

Small steps

Begin with small tasks. Starting with a simple bug fix or documentation update can be a great way to ease into contributing to a project. This approach allows you to learn the contribution process and make mistakes on less critical contributions before moving on to more complex tasks that may be more important to your organization’s needs.


Once your organization has successfully made small contributions to an open source project, it’s time to leverage those experiences and build towards making larger, more impactful contributions.


One way to develop important personal and organizational relationships within an open source community is to attend events. Events offer a diverse mix of participants, from project leaders and dedicated users to representatives of organizations that contribute to the project. They provide a unique opportunity to meet people face-to-face and develop a deeper understanding of the individuals behind online personas. Sponsorships from organizations are a crucial element of these events, allowing attendees to learn from each other and work towards shared project goals. Without financial support from sponsoring organizations, these events would not be possible.

Community inclusion

To effectively engage with the community, involve them early and often. Instead of developing large portions of code in-house and then abruptly adding them to the open source project, seek input and feedback from the community as early as possible. Keep in mind that making significant changes to the project can have far-reaching side effects, so it’s crucial to discuss any proposed changes with the community beforehand to ensure alignment with the project’s broader goals. Before investing time in creating code, consider focusing on the problem rather than a specific solution. Then, discuss the problem with the community. Remember, corporate participation in open source is often highly scrutinized by developer communities. Involving the community can ease tension, prevent conflict, and promote communal development.

Aim upstream

Upstream contribution is the process of submitting any modifications made to an open source project back to the original maintainers for potential inclusion in a future software release. If your organization is new to the world of open source, you may need to take some time to inform your staff about the significance of up-streaming contributions. Occasionally, individuals may assume that a quick and unrefined patch to get something functioning in their infrastructure is preferable to the thorough approach of cleaning it up and seeking approval for inclusion in the upstream project.

Over time, a quick patch that requires testing, updating, and reapplying with each upgrade cycle will likely take more time and effort than up-streaming it. The open source community may view this behavior as selfish since corporate members may primarily benefit from your fixes. Consequently, your organization’s reputation within these OSS communities may be negatively impacted.

Earning respect within open source communities

Understanding how to earn respect within OSS projects is a major challenge for many organizations. Simply being a big player in the industry does not automatically command respect within OSS communities. In order to gain influence, you must actively participate and contribute to the project. Over time, individuals who demonstrate reliability and responsibility in their contributions may earn greater positions of influence and leadership.

Furthermore, prepare for potential disagreements and conflicts during the review process. It’s essential to remain calm and professional while addressing feedback and making sure it focuses on the contribution and not the person. Remember that your participation in an open source project is public, and negative interactions can have long-lasting consequences. It’s a good idea to provide training to employees on how to manage conflicts with others.

Upstream recommendations

Work within your organization to:

  • Ensure you have good reasons for up-streaming.
  • Develop your code with up-streaming in mind.
  • Embrace a design mentality that prioritizes upstream: share your changes with the project before incorporating them into your products.
  • Maintain developers’ involvement with the project, even if it’s only a minor involvement.

Work within the project to:

  • Ensure your contributions are beneficial to others.
  • Adhere to the appropriate coding conventions.
  • Follow the submission guidelines set by the project.
  • Offer documentation and explanations for your contributions.
  • Listen to feedback and take appropriate action.
  • Value patience, communication, and kindness when responding to feedback.
  • Continue refining your code until it is accepted.

Open source contribution strategy

A well-planned contribution strategy can guide your employees in participating in open source projects. It can also help justify it’s importance to senior management. It’s crucial to align your organization’s OSS efforts with its overall business goals to establish how they fit into the broader strategies. By explicitly linking your open source contribution strategy to your organization’s strategic efforts, you can demonstrate to senior management why the work is valuable and help your employees understand the significance of their contributions.

After establishing business-aligned goals and strategies, the next step is to create an implementation plan. To ensure a thorough plan, consider the following questions:


In other words, what are the organization’s intentions for its corporate participation in open source projects.

Are our contributions important? If so, for who?

Don’t forget to provide a compelling rationale for your contributions. While it’s exciting to dive into the details of what you plan to do, it’s important to explain why these contributions are important and align with the organization’s strategic goals.

State of open source

What open source projects does our organization use?

Before contributing to open source projects, it’s important to assess which ones are used within your organization and which ones are strategic to your business. Consider critical business infrastructure, development and deployment tools that impact product releases, and software that’s important for customer-facing products or services.

Are we contributing to any OSS projects?

Consider the contributions we are currently making. It is possible that your organization may already have individuals making changes to open source projects. They could be developing patches for internal use or already sending those patches back to the upstream project to avoid the hassle of maintaining them. Discuss with your teams internally to identify potential contributions that can be built upon. In addition, evaluate whether you have staff members with the necessary skills and interest to contribute.

Which projects should we focus on contributing to?

Determining which open source projects to target for contribution is essential for most organizations that use multiple projects. Focusing on only the most important projects is key to making the most of your plan. However, this doesn’t mean that your employees can’t contribute to other projects that are not on the target list. If an open source project is critical to your business and could cause significant downtime or disruption to your ability to serve your customers, it’s probably a good idea to prioritize contributing to that project.



Do we have the necessary expertise?

Before making any significant contribution to an open source project, you must determine if you have the necessary expertise or if you need to hire new staff. As I emphasized earlier, successful contributions require individuals who possess not only the technical skills but also the social skills needed to work with the community to have the contribution approved. You may already have employees contributing to the project, and you can rely on them to make further contributions. However, if you don’t have the necessary expertise, you may need to consider hiring someone who is already making successful contributions to the project. You should also ensure that your organization has the resources and budget needed for the contribution to be a success.

What type of training do we need to provide?

To ensure your corporate participation in open source projects is successful, it’s essential to provide the necessary training to your team. This training should cover best practices for making contributions, open source licenses, governance, and community norms. In addition, providing training on conflict resolution, cultural customs, and other communication skills can prevent issues down the road. To scale your efforts, consider implementing a mentorship program that pairs new contributors with experienced open source contributors who can guide and support them through the process.


Do we need funding or a sponsorship/corporate membership?

Consider the funding requirements for project sponsorships and corporate memberships. Evaluate the governance models of the projects that interest you to determine whether they offer these options for the project or its foundation. These methods of funding can help to ensure the success of the project. Additionally, they may allow your organization to have a greater influence on the project and its direction. Lastly, sponsoring conferences related to the project can be beneficial for both promoting your work and for networking with potential recruits.

Do we have a promotion strategy?

It’s essential to include a plan for marketing and publicizing your open source contributions to ensure that they are effectively promoted. This can be especially challenging for some organizations, so it’s crucial to establish guidelines for discussing your contributions in public. Participating in the project’s events, such as conferences, and sponsoring user groups can be an effective way to promote your work and attract new contributors. Additionally, sending employees to present at local user groups is a valuable recruitment strategy for engaging with community members who are passionate about specific open source projects.

Tracking goals

How will we evaluate success?

A plan’s success should be measured through specific criteria that directly align with the organization’s strategies. Measuring the success of corporate open source contributions should focus on tracking the activities that are most important to the organization rather than the easiest to measure. Developing a set of criteria to evaluate the success of your open source contribution plan is critical. To start measuring your open source program’s success, checkout GrimoireLab, which provides useful metrics and measurement tools.


Do we have contribution guidelines inside our organization?

To facilitate successful contributions to open source projects, it’s important to establish contribution guidelines and processes. Rather than being overly restrictive, these guidelines should aim to provide helpful checklists and resources. Here, the goal is to ensure contributors have all the necessary information and tools to make successful contributions, while avoiding licensing or confidentiality issues. Particularly for novice contributors, providing an internal review process where they can receive feedback in a safe and supportive environment is also beneficial.

Long-term corporate participation in open source

Do we need an open source programs office?

Having a dedicated open source program office (OSPO) or staff to manage these efforts can be invaluable. This can include someone who is responsible for establishing processes, training, and licensing guidance. Additionally, they may be responsible for answering questions from senior management or contributors, and communicating updates throughout the organization. An OSPO can help you navigate this terrain, ensuring that your efforts are successful and aligned with your business’ goals.

TLDR: corporate participation in open source

Here are some tips for corporate participation in open source:

  • Develop and implement a clear policy and process to guide open source contributions in your organization.
  • Create a dedicated team or person responsible for overseeing and approving contributions.
  • Focus your contributions on areas that will drive your technologies forward and align with your business goals.
  • Offer clear and comprehensive contribution guidelines to ensure that all contributors understand the process and expectations.
  • Ensure that your contributors have the necessary IT infrastructure and tools to support their work.
  • Provide training to your employees on best practices for open source contribution.
  • Track your contributions, measure their impact, and continuously improve your strategy. Communicate progress and successes to stakeholders.
  • Make legal support for OSS accessible to your developers to avoid licensing and other legal issues.
  • Consider hiring talent from the open source communities you value and support.
  • Follow the community processes and practices specific to each project to ensure that your contributions are accepted and well-received.

Open source for business

OSS has become a significant factor in the success of most organizations in delivering products and services to customers. It’s clear that they are here to stay. To have a say in the open source projects that drive your business, it’s essential to participate. Creating a sound contribution strategy and implementation plan can put your organization on the path of becoming a responsible corporate citizen in the open source community. Best of luck!

I hope you enjoyed this post on corporate participation in open source. If you want to learn more about open source, consider reading Enemies of Human Nature.

Portrait of Olivia Gallucci in garden, used in LNP article.

Written by Olivia Gallucci

Olivia is an honors student at the Rochester Institute of Technology. She writes about security, open source software, and professional development.