(This is part of the process for releasing new open source code. There are different processes for patches and projects that you, or someone not at Google needs or wants to own the IP for your code.)
Creating a launch
Open source releases are managed through Ariane. After preparing your project and staging the code on an internal Git-on-Borg repository or Cloud Source Repository, you need to create a launch entry. This includes personal projects that have not gone through IARC, even for DevRel engineers.
IMPORTANT: All open source launches must be tracked in Ariane.
TIP: If you are in DevRel and want to release sample code for an already launched product, see DevRel Releasing.
If you are releasing a new open source product (e.g. Kubernetes, Tensorflow, Go, GRPC, Istio), a Google API, or anything involving a new website, hostname, or domain, your launch must be on your PA Calendar. Add the Open Source calendar as a secondary calendar.
If you are just releasing code (e.g. a tool or library), or it’s a personal project, your launch only needs to have the Open Source calendar. (These launches must include the required disclaimer in the project README.)
IMPORTANT: If your calendars are in the wrong order, your launch will be suspended until you reorder them by removing the Open Source calendar and re-adding it.
Settings on your launch
- Eng bit: Add your manager as an approver for the Eng bit
- Staging Repository: Include a link to your code on a Git-on-Borg
repostiory or Cloud Source Repository in the
URL for Staging Repositoryfield.
- GitHub URL: Include the GitHub URL of where you would like to publish your code. Follow guidance in go/github-docs/where as to which organization to use, and when you may publish in your personal account.
- Approvers: Do not set any approvers’ bits to FYI or change assignments unless specifically instructed to do so. (The opensource-patents bit is set to FYI by default, and you should leave it set that way unless you have specific patent-related concerns.)
- Website: If you are creating a new website/domain with your launch, select “Yes” for the Website Launch field. This requires that you add your PA calendar as the primary calendar to your launch, and the Open Source calendar second.
TIP: You can look at a sample launch to see how a launch should look.
Once your launch is created, follow these steps:
- Ensure all reviewers have read access to your code.
- Address any comments or issues posted by the launch reviewers.
- Wait for approval.
During review, some of the major things reviewers look for include:
- That it doesn’t include anything linked to Google’s “secret sauce” (e.g. ranking, filtering, etc…).
- That sharing helps users, not just our competitors.
- That any non-Google code is in a third_party directory.
- That it is in license compliance with any third-party dependencies.
- That it doesn’t violate a country’s laws.
- There are no patent issues.
- There are no privacy issues (see below).
A legal review will be required if your code collects any data about users and transmits it back to us or if it affects or transmits third-party content. We’ll add the right people to the launch calendar entry, but if you mention this in the description, it will help speed things up.
All launches that include machine learning artifacts such as code, pre-trained models, or datasets are additionally reviewed for compliance with Google’s AI Principles.
We’ll use the launch calendar entry to ask questions and discuss any potential problems, but it’s generally a smooth process. Once you receive full approval, continue on to the next step in this process.
NOTE: This section provides guidance for the Eng reviewer.
The Eng reviewer should primarily seek to answer the question, “Is this project okay to release?”. We ask the launch creator’s manager to make this call, since the Open Source Office often does not have the appropriate context to do so. If the manager does not feel comfortable making this determination, or for larger launches that warrant more senior review, it’s always okay to have a director or VP do this review.
We generally encourage approving releases unless there’s a good reason not to, but if you have any questions, you can reach out to emailremoved@.
Examples of work-related projects that might not be okay to release include:
- A proprietary algorithm we want to keep internal for business reasons
- One that competes with other Google projects or interests in a way that is undesirable (note that this kind of competition between projects is often okay)
- Projects that don’t yet meet some team-specific criteria for release, such as test coverage, documentation, etc.
Not all of these will apply for every launch, and it is common for projects that are releasing existing Google code to receive a more thorough review.
Personal projects a Googler may be working on in their 20% time or personal time often do not require as much scrutiny, but you should still check for the same thing: whether the project is okay to release.
DevRel, Cloud DevRel, and Ads DevRel releasing
DevRel teams producing official sample code and example applications directly related to a released Google product may go through the expedited approval process by writing “DEVREL” in the notes for the Eng bit and flipping the bit yourself. If a launch is not complete within 3 business days of filing, please email emailremoved@ directly.
DevRel teams may use private GitHub repos to stage code related to I/O or marketing deadlines, but only after licensing and patents approval on the launch calendar. They must specify a fixed and reasonable deadline for deleting the repo or making it public.
Here’s some handy templates: go/dpe-launch, go/cdpe-launch.
Additional instructions for DevRel teams can be found at go/dpe-oss and go/gcp-github.
Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.