[Flameeyes] has heard complaints (and at times, he admits, has complained himself) about big companies not contributing improvements to projects they seem to find useful, or rolling their own implementation rather than use and contribute to an existing code base. Having recently left Google after seven years, he has some insights into some of the reasons big corporations (at least Google, anyway) may sometimes seem to eschew making code contributions, and some of the reasons might come as a surprise.

There are things a corporation can do differently, but there are also some things that can be done on the project’s end to make accepting contributions easier. [Flameeyes] took some time to write out a few pointers on how to make it easier for others (particularly large corporations) to contribute code to a software project.

The biggest issue is the software license. Without one, there is no legal structure to use, distribute, or contribute to the code, and no corporate entity will want to touch it. Google specifically forbids creating patches for projects with either no license, or incompatible licenses. An example of an incompatible license is one that forbids commercial use, because everything a corporation like Google does — even research –is considered a commercial endeavor. In addition, on the corporate side making contributions might trigger a code review process of some kind for some licenses, but not for others. [Flameeyes] suggests the MIT license as one that is acceptable to pretty much everyone with a minimum of fuss. Another caution: if a project’s code resides in an online repository, make sure the repository is licensed as well.

A few other small suggestions (such as maintaining an AUTHORS file to track contributors in a tidy way) rounds out the advice. It sounds simple, but software licensing is so critical to the whole affair that it’s important to get it right — he suggests the REUSE tool for anyone wanting to make sure a project’s licensing is tidy.

[Flameeyes] makes a point that none of this guidance is based on secret or institutional knowledge. Google has a public document detailing exactly how they use and deal with open source, and it’s a solid guide for how to make your project more accepting of contributions from a corporate entity like Google. (Or, if you prefer, a guide on how to set up as many barriers as possible for your project.)

In case you missed it, we just want to remind you that our favorite recent open source project from Google is definitely Pigweed.