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.
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.
Staging Repository: Include a link to your code on a Git-on-Borg repostiory or Cloud Source Repository in the URL for Staging Repository field.
GitHub URL: Include the GitHub URL of where you would like to publish your code. Follow guidance in go/github-docs#organizations as to which organization to use, and when you may publish in your personal account.
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.
Ensure all reviewers have read access to your code.
Address any comments or issues posted by the launch reviewers.
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.
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@.
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 okay to release.
DevRel teams producing 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/cloud-dpe-launch.
Additional instructions for DevRel teams can be found at go/dpe-oss and go/gcp-github.