(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.)
- Get approval 👈 You are here
Creating an Ariane or Launcher2 launch
Launches involving Google Cloud Platform services or teams must use Launcher2 (go/turbo). All other launches should use 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 side projects that have not gone through IARC, even for DevRel engineers.
IMPORTANT: All open source launches must be tracked in Ariane or Launcher2.
TIP: If you are in DevRel and want to release sample code for an already launched product, see DevRel Releasing.
To create an Ariane launch, follow these steps:
IMPORTANT: Open source launches that involve a Google Cloud Platform service or are launched by a GCP employee or team must follow the New Product Introduction (NPI) framework and use Launcher2 tooling. Follow the Launcher2 process at go/oss-Launcher2. All other open source releases should use Ariane launches.
- Go to http://linkremoved/
- Click "Create Launch"
- Add your PA calendar if necessary, see Calendars below, and
then search for and add the
- Complete the rest of the wizard.
- On the resulting launch page, fill in the details about your project.
- When you are ready, click "Save and start review"
- Finally, click the "Request Review" buttons next to every approver to initiate the review process.
To create a Launcher2 launch, follow the steps at go/turbo-user-guide-npi.
For Ariane launches, 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 Ariane 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
side project, your Ariane 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 Ariane launch will be
suspended until you reorder them by removing the
Open Source calendar and
For Launcher2, follow the OSS Launch guidance at go/oss-Launcher2.
Settings on your Ariane launch
- Eng bit: If you are releasing a project as part of the 2020 Google Internship program, see instructions below. Otherwise, set this bit to your manager.
- Staging Repository: Include a link to your code on a Git-on-Borg
repository 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 the approvers 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 Ariane launch to see how an Ariane launch should look.
Settings on your Launcher2 launch
For Launcher2, follow the OSS Launch guidance at go/oss-Launcher2.
Once your Ariane or Launcher2 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.
- If a field has a "Request Review" button, request review.
- If a field is marked "Pending Review", 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.
Side 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
IMPORTANT: DevRel teams in GCP or working on GCP products must follow the New Product Introduction (NPI) framework and use Launcher2 tooling.
DevRel teams outside of GCP 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.
An Ariane template for DevRel launches is available at go/dpe-launch.
Additional instructions for DevRel teams can be found at go/dpe-oss and go/gcp-github.
2020 Internship releasing
NOTE: Ariane or Launcher2 launches for internship projects should be completed by the Googler host.
Projects being released during the 2020 internship season have special requirements for the Eng approval bit:
- If you will be open sourcing existing Google-owned code as part of the internship project, the host should set the Eng approval bit to their Director.
- If the project does not involve releasing any existing Google code, the
host should write
2020 INTERNSHIPin the notes for the Eng bit and flip the bit to