Open source is about more than just code. It's also about the planning that happens before the code is written, the process of how that code is used by others, and fostering a welcoming environment where a community can grow.
In the spirit of openness, we are publishing our internal documentation for how we do open source at Google. We invite you to take a look behind the scenes at how we use, release, and support open source projects and communities.
What is included
This is a copy of our internal open source documentation, with a few exceptions. For a number of reasons, we can't share everything, so you might find places where a link is missing or some content had to be removed.
Aside from those few cases, this is the same documentation seen by Google employees. As a result, there is some Google lingo throughout, as well as references to internal tools and systems. See the glossary for definitions of some of the most common ones.
There are three primary sections of the docs:
Creating covers how Googlers release code that they've written, either in the form of a new standalone project or as a patch to an external project. The same process is used for small 20% projects and full blown Google projects.
Using explains how we bring open source code into the company and use it to help build great products. We carefully catalog thousands of packages to help us maintain license compliance.
Growing describes some of the programs we run inside and outside the company to support open source communities.
Who this is for
For other companies that are releasing or using open source software, we want to share the lessons we've learned from many years of experience. By being as transparent as we can about how we do open source, we hope to help others do the same.
However, many of the things we do are unique to how Google operates and our engineering culture, so these should not be read as "how-to" guides. To hear from more companies deeply involved in open source, we recommend checking out the TODO Group.
For individuals or project maintainers, if you've ever contributed to Google open source projects, or received a patch from a Googler, you've been exposed to how we do things. We hope that these documents provide useful insight into how we approach open source and answer questions you may have.
Googlers should continue to use the internal copy of these docs at go/opensource.
Really?
Yes, we really do publish our internal documentation for all the world to see! One of the goals of the site is to expose (where appropriate) our internal processes related to open source so that other companies have the opportunity to learn from them.
We carefully review all content before it's published externally, using automated tooling (go/cleanr) to rewrite internal URLs, file paths, and certain project code names. We also perform a human review of all changes before they're published. In general, we don't consider go/ links to be sensitive since they aren't accessible by non-Googlers and typically have generic names.