Contributing to open source software is beneficial to a business, its developers, and the open source software (OSS) packages they rely on. By giving back, a company can be confident the foundational technologies for their business are secure and reduce the tech debt by relying on publicly maintained versions.
Contributions also build a relationship with the communities that your business depends on and reduces the likelihood of disgruntled maintainers. Developers contributing to these open source packages gain a deeper understanding of the thinking and technology underpinning their applications.
Open source is how software happens
It's old news that software is eating the world and OSS is no longer theoretical or conceptual. On average, they make up 85% of a modern application. Your company is using it, your teams are using it, and you can't make competitive software without it. OSS was initially created for the public good but has provided immeasurable value to business.
Unfortunately, few have contributed back to the communities that develop key pieces of their infrastructure.
Ongoing help needed from their biggest users
Open source software isn't self-maintaining - to keep up with bugs and security vulnerabilities open source packages need time and attention to stay alive. Many crucial open source packages are maintained by a small number of unpaid volunteers who contribute in their spare time.
But what if these maintainers step away or move on to other projects? This uncertainty means risk: popular packages can become a single failure point of failure for your entire build process. They become tempting targets for bad actors looking to exploit the unregulated nature of the open source community.
It's therefore vital for the industry to recognize open source participation as a crucial part of maintaining your software infrastructure, not just recruiting and public relations tools.
The Sonatype journey started just as the concept of open source software development was gaining steam. From our beginning as core contributors to Apache Maven, to supporting the world's largest repository of open source components (Central), to distributing the world's most popular repository manager (part of the Sonatype Platform), we've played a meaningful role in helping the world embrace the power of open innovation.
We start by dedicating 10% of our developers' time to their individual improvement. This includes assistance to open source projects important to our organization. We also have dedicated teams actively working on open source tools to help developers secure and improve their open source projects.
Some of our contributions include:
OSS Index - A free catalog of open source components and scanning tools to help developers identify vulnerabilities, understand risk, and keep their software safe. Under "Scan your Dependencies," you can find a number of open source tools started and worked on by our developers to help the open source community build better software.
Open Source Community Sponsorships - quoting Sonatype CTO Brian Fox:
"We partner with and support, institutions like the Open Source Security Foundation, the OpenChain Project, and the Python Software Foundation. This enables us to learn from the community while combining efforts with other members to share best practices that ultimately make open source safer and more effective."
Ways your company can help
1. Establish guidelines for involvement
Every organization has a policy about open source contributions - either an explicit one or an implicit one. If your organization only has an implicit policy, you can begin to shift your company towards an explicit one that makes it easier for other members of your team to get involved. Check out these examples of good policies if you need help getting started:
- Balanced Employee IP Agreement (GitHub)
- Corporate Change: Contributing to Open Source (Daniel Doubrovkine)
- Creating an open source program office (Linux Foundation)
More traditionally conservative organizations are also giving back to the open source community:
- Goldman Sachs open sourced its data modeling platform
- United States Department of Defense released guidelines for employee contributions to open source (PDF format)
It's time for every organization to embrace open source contributions.
2. Determine which projects you rely on
If you're unsure which OSS projects you're using ask around, or, better yet, put together a software bill of materials (SBOM). Every project should maintain a SBOM of your open source dependencies. This process is simple to automate during the build process and can be stored in the artifact repository along with your production binaries.
Beyond individual software analysis, SBOMs can also make it easier to identify common projects across your organization.
3. Contribute meaningfully to open source projects
It's fine to deliver time and money, but there are also advantages to direct involvement. For example, it's one thing to ask for a feature, it's another thing entirely to build roadmaps so maintainers can understand how to put it together.
You can take it a step further if you consider becoming a maintainer of that code aspect. Making a major feature ask is easier when you're handling the workload. It's one way contributors become maintainers: after you really understand a project, you can carry the motivation forward with your own work.
Quality contributors also understand the motivations behind a project well enough to know when a potential feature request is out of scope. Because every feature takes time, not just to build but to maintain, it's important to bear in mind where the maintainer(s) want to focus their efforts.
There's an entire Open Source Guide Checklist you can run through to understand if any given project is worth contributing to. Still nervous about getting involved? Stack Overflow breaks down getting started with a step-by-step guide.
Finally, communication is key and good documentation can make or break an open source project.
The benefits of open source contributions go beyond new features. There are important advantages to putting money and resources towards projects not specifically owned by your company. Assisting with crucial open source projects means reduced risk and tech debt. Supporters can also make suggestions about the project and help ensure your key features aren't broken.
Better code and better coding
Involvement means your engineers gain a better understanding of the technology your business relies on. While also letting them leverage your existing infrastructure and avoid pitfalls. In short, contributing to open source makes your company innovate faster, become more agile, and build a network of relationships across different teams and different corporations.
Being involved with open source packages can also help protect your organization. Maintainers of software frequently get notice of vulnerabilities before disclosures are made public, giving the package owners a chance to patch the vulnerability to protect rather than compromising their security. Regular contributions also mean that a package will receive more timely updates for critical bug fixes and vulnerabilities.
Reduce tech debt
Maintaining open source projects can be a great way to reduce tech debt. Fixing security issues in OSS is critical to mitigating risk and it can be tempting to fork the project and patch your own version when a fix isn't available. But it's much better to patch the original package.
Locking your packages to internal versions is costly and hard to get out of. This can be seen in the challenges with GitHub's internal fork of Ruby on Rails, but it's even worse when internal changes are not documented. Internal forks require teams to monitor and duplicate the work being done by the open source community.
When organizations contribute, both the project and your company benefit when those fixes are committed back to the project.
Impact the future of the package
Supporters can help make suggestions about the project and help ensure important features aren't broken. By devoting your resources to the open source packages your company depends on, you get more of a say in it's direction.
Hyrum's law states that, "all observable behaviors of your system will be depended on by somebody." Meaning, even minor changes to a package's behavior can have big consequences for software that depends on it. By working with the open source community on developing packages critical to your business, you can help maintain the behaviors you rely on. This minimizes problematic changes or reduces the impact on your software.
This doesn't have to be voting membership in project governance to influence planning. The ultimate direction of a project is decided by the team working on it. Rather than submitting requests, your developers can help make the software that improves your business.
We're very interested in hearing how you are giving back to the open source community. Share your story.