Contributing to Open Source Projects

The second stage of engaging with open source is typically to contribute to an open source project. Most people and companies start contributing by filing bug reports for components they use in the projects and products. Both people and companies may or may not move on to contributing source code. There are many other ways of contributing to open source projects.

Corporate reasons for contributing to open source projects range from the tactical to the strategic:

Tactical reasons are mostly about code contributions that the company does not consider competitively differentiating. The three common types of code contributions are (a) bug fixes, (b) refactorings, and (c) new functionality.

Non-differentiating code is better maintained by the open source project than the company. This makes it easier for the company to catch-up with new versions of the open-source software, because the company doesn’t have to repeatedly merge their closed modifications into the open-source software as it updates to a new version.

Strategic reasons are mostly about ensuring technical compatibility with and managing the dependencies of the company’s projects and products on the open-source software.

Sometimes, an open source project does not have enough interest in a particular feature or technology to maintain it. If the company’s projects or products rely on it, it has to step up and start supporting and maintaining it or see the open-source software go stale for it.

Also, without a voice in the project, the open-source project might take a left turn where the company wants it to go straight. To manage its technical dependencies and to ensure that nothing goes wrong, a company has to pay in by actively contributing. This way, the company maintains its interests.

An open source program office (OSPO), like in the case of incoming open-source software, typically should operate a review and approval process for proprietary software to be contributed to open source projects. This is also called the outbound licensing process.

A company should only ever contribute code to open-source software projects that is competitively non-differentiating for it. As part of an overall strategy, it may decide to let go of closed code that was once considered differentiating, but under the new strategy isn’t any longer.

The outbound licensing process reviews whether a particular open source engagement hurts or strengthens the competitive position of the company.

The obvious reason to not contribute a software feature to an open source project is that customers are paying for it.
Another reason may be that the open source license requires a free patent grant that the company is not willing to provide.
Sometimes information that a company is depending on a particular open-source software, as laid open by a contribution, is hurting its competitive position.

It is a common beginners’ mistake to assume that the open source project exists to serve the company. It doesn’t. The project exists for its own purpose. A company can’t demand a bug fix, for example, even if the bug causes major pain. Similarly, a company can’t provide a bug fix to a project and expect the project to maintain it. The bug fix might just linger and never get picked up, if nobody is interested in it.

There is no guarantee that an open source project will behave the way a company wants it to. The company can ask nicely, but there is no guarantee that it will receive a response.

As a consequence, a company needs to build both capability and credibility with an open-source software and its project community. Then, not only will the company be able to provide good contributions, it may also be listened to. For open source projects, on which a company’s projects and products critically depend, building such capabilities and credibility is a must.

Next up: Leading open source projects