Almost every business depends on open source software, from the operating system on its servers to the libraries inside its applications. Most use it without giving anything back, and that is entirely permitted by the licences. Yet a growing number of companies, including small ones, choose to contribute to open source projects they rely on. Is it worth the time, and how do you do it without creating legal or security headaches?
What "contributing" can mean
Contribution is broader than writing code:
- Bug reports with clear steps to reproduce the problem.
- Code fixes and features submitted as pull requests.
- Documentation: correcting errors, adding examples, translating.
- Testing pre-release versions against your real use cases.
- Answering questions in forums and issue trackers.
- Funding: sponsoring maintainers or projects, or joining a foundation.
- Releasing your own tools as new open source projects.
Even small contributions, such as a well-written bug report, help maintainers and cost very little.
The business case to contribute to open source
Lower maintenance costs
If you fix a bug or add a feature in an open source component and keep the change private, you must reapply it every time you upgrade. If the change is accepted upstream, the project maintains it for you. For companies that customise open source software, this alone can justify contributing.
Healthier dependencies
Many projects that businesses depend on are maintained by a small number of people, sometimes volunteers. Contributions and funding make it more likely that the software you rely on stays secure and maintained.
Influence
Active contributors understand where a project is heading and can shape decisions that affect them. Passive users find out when the release notes arrive.
Skills and recruitment
Developers who contribute learn from experienced maintainers and code review in public. Visible contributions also show prospective hires and clients that your team does serious technical work.
Reputation
Public, useful contributions are verifiable evidence of expertise, more credible than marketing claims.
The costs and risks
Time
Preparing a contribution to a project's standards, responding to review and revising takes longer than making a private change. Maintainers may request changes or decline the contribution altogether.
Intellectual property
Employees' work typically belongs to the employer, so contributions are the company's to give. Some projects require a Contributor Licence Agreement (CLA) that grants the project rights to your contribution; others use a Developer Certificate of Origin (DCO), where each commit is signed off to confirm the contributor has the right to submit it. Someone in the company should understand and approve what these mean before staff sign them.
Confidentiality
Code written for a client may belong to the client, and internal code may reveal business logic, customer names or security details. Contributions need a check that nothing confidential is included.
Releasing your own projects
Publishing a new project brings expectations: issues to triage, questions to answer, security reports to handle. An abandoned company project can reflect worse than none. Choose a licence deliberately (choosealicense.com explains common options) and decide in advance how much maintenance you will commit.
A simple contribution policy
You do not need a large programme. A one-page policy covering these points is enough for most companies:
- Scope: which kinds of contributions staff may make without extra approval (for example, bug reports, documentation and small fixes to projects the company uses).
- Approval: who approves larger contributions, CLAs and new project releases.
- Ownership: confirm that contributions are made on behalf of the company and identify which accounts and email addresses to use.
- Client work: never contribute code created for a client without the client's written permission.
- Confidentiality and security: remove secrets, internal details and customer data; report security vulnerabilities privately through the project's published process, never as public issues.
- Licences: which licences the company is comfortable releasing its own projects under.
- Time: whether contributions happen during working hours and how they are prioritised against client work.
Larger organisations sometimes formalise this in an open source programme office (OSPO), a small team that manages open source use, compliance and contribution. Smaller companies can achieve the same with a clear policy and a named owner.
Where to start
| Effort level | Practical first steps |
|---|---|
| Minimal | File good bug reports for problems you find; share workarounds in issue threads |
| Low | Fix documentation errors; submit small fixes you have already made internally |
| Moderate | Upstream your customisations to tools you depend on; sponsor key maintainers |
| Significant | Allocate regular developer time to strategic projects; release useful internal tools |
Before contributing code, read the project's contribution guidelines and code of conduct, look for issues labelled for newcomers, and discuss larger changes with maintainers first so effort is not wasted.
Is it right for your company?
If you only use open source lightly and never modify it, occasional bug reports and perhaps sponsorship may be all that makes sense. If you customise open source applications or depend heavily on particular projects, upstreaming changes is often the cheapest way to keep your systems maintainable. Our open source solutions work involves this regularly, and software consulting can help set a policy that fits your business.
Key takeaways
- Contributing includes bug reports, documentation, testing and funding, not just code.
- Upstreaming customisations reduces your maintenance burden and strengthens dependencies.
- Manage IP, CLAs, client confidentiality and security reporting with a short written policy.
- Start small and scale contribution to how heavily you rely on each project.