Releasing Code

There are several options for how to open source code at Google:

  1. Releasing an official Google project or a side project
  2. Patching an existing project or small code exemption
  3. You need or want to own the copyright

This is the process for releasing any Google owned source code outside of Google. This includes exposing new open source projects/repositories to the world (usually via GitHub), sharing with partners (except when covered by another legal agreement made by your go/pcounsel), and any other method where source code is made available.

The release process applies to all types of projects: official projects, side projects, intern projects, 20% projects, and any other new Google open source releases that aren't part of and following the release process of an already-established Google open source project (like Chromium or Android).

TIP: Changes to existing open source projects should follow go/patching. This includes releasing new versions of such projects.

TIP: Papers and publications should follow go/publications. (Any included code must still go through the process on this page.) Other academic work (like theses or advisorships) should contact emailremoved@ for guidance.

NOTE: Completing the initial steps to stage your code and send it out for review can take as little as 10 minutes for simple side projects, or as much as an hour if there are lots of issues detected. Reviews are typically completed in a couple of days.

This graph can help you understand the process:

Releasing flow chart

This process typically takes under a week from filing to final approval, but it is best to start this process early if you have a strict deadline.

The Short Version

This is a quick overview of the releasing steps. You must still read and follow the detailed instructions at go/releasing/preparing when preparing your launch, even if you are releasing an empty project.

TIP: For simple projects, you may find this unofficial guide to the releasing process useful: go/oss-releasing-speedrun

1. Prepare

Read more at go/releasing/preparing

  1. Name your project
  2. Scrub the code and comments of Google proprietary information
  3. Include a README
  4. Include an Apache 2 LICENSE file and source file headers
  5. Include a CONTRIBUTING file
  6. Ensure that non-Google code is in a third_party directory

TIP: You can base your repo on https://github.com/google/new-project to save time copying boilerplate.

NOTE: If you're in GCP start at go/oss-gcp for work-related projects.

2. Stage

Read more at go/releasing/preparing#stage-your-code-for-review

  1. Check if your launch is low-risk and can be staged directly on GitHub
  2. If your project isn't eligible to be staged on GitHub, push your code to an internal Git-on-Borg or Cloud Source Repository repo
  3. Set the repository ACLs to ensure that reviewers and the Cross linter can access your code
  4. Run the Cross linter (go/cross) to check your repository and then fix any warnings

3. Get approval

Read more at go/releasing/approval

For Ariane launches:

  1. Create an Ariane Launch.
  2. Add the Open Source calendar (if not already added in the previous step).
    • Ordering is important -- it must be secondary if you added a PA calendar.
  3. Ensure you set the fields as described on go/releasing/approval#settings
  4. Request review and wait for approval

TIP: You can look at this sample launch to see how a launch should look.

For Launcher2 launches:

  1. For Launcher2 launches, see the guidance at go/oss-Launcher2.

4. Release

IMPORTANT: Wait for approval before following these instructions!

Read more at go/releasing/publishing and go/releasing/contributions

  1. Create the external repository using go/github/launch if you’re hosting it in a Google-managed organization. Create it normally otherwise
  2. If your project contains encryption code, follow go/releasing-crypto
  3. Push your code to the external repository
  4. [Optional] If you created a staging repository for your project that you're planning to develop in the open, you can delete it once your code is pushed. It's only needed for pre-release checks.
  5. [Optional] Add your project to the Open Source Project Database
  6. Tell the internet about your project
  7. [Optional] Accept contributions from others if they sign our CLA

Patching

If any of these cases apply:

  • Contributing to an existing open source project (regardless of the size or complexity of the contribution)
  • Releasing snippets or gists that are fewer than 100 lines of code
  • Posting code to StackOverflow
  • Performing the duties of an open source project administrator

Use the very lightweight process described at go/patching. You might not have to do anything at all.

IARC

If you, or someone not at Google needs or wants to own the copyright for your code, read and follow the information at go/iarc. This is not handled by the open source team. You may decide to go down this route if this project:

  • Is for your side business
  • Is for someone other than you or Google
  • Is one you wish to retain the copyright for
  • Isn’t one you plan on open sourcing

However, it’s more than likely that going down the IARC route is overkill for you as an open source license allows the code to be used for many purposes, and you should follow the instructions in this page instead.

FAQ

What’s the practical difference between a work-related project and a side project?

NOTE: For the purpose of this document, a "side" project could also be considered a "pet" or "hobby" project.

The differences are:

  • Where you publish the code: If it’s at all related to work, it must go in an organization managed by Google (you can see all the ones we maintain at go/github/orgs). If it’s a side project, then you may release it in a Google-managed organization, or release it under your personal GitHub account. go/github-docs/where has more detail about what's appropriate to go where.

  • Launch calendar: Side projects only need to be on the Open Source calendar. Other Google projects may also need to be on PA specific calendars.

  • Disclaimer: Side projects should include the required disclaimer.

Why do I have to stage my code on Git-on-Borg? Can’t I just push it to GitHub?

There are things that we look for in your code (like if it’s properly licensed, or if you’re vendoring third-party code correctly) during the review process before it is publicly available. Without being able to access your code, we can’t do that.

We are testing a new process for staging low-risk repos directly on GitHub. Learn more and see if your project qualifies at go/easyrelease.

I don’t really have code yet. Can I still start the launch process?

Yes! Start your repository using the template at https://github.com/google/new-project, or add the required files and fill out the README. Put what you have and as much detail as you can about what you’re going to implement into the launch description.

Do I really have to get approval from my manager? This is just a tiny project! What gives?

Google does a lot of different things. It’s hard to tell what’s going to conflict with an ongoing effort without getting input from a manager. We’re trying to save you trouble later on.

This process is a pain, can you automate any of it?

Yes! We're working on it!

My launch has been taking forever. What do I do?

If any individual item is pending for more than three work days please email emailremoved@ and let us know.

I only have a Mac or Chromebook, can I release code?

Right now our tooling requires access to a Linux workstation or Cloudtop instance. We're working on Mac support.

I want to put some code on GitHub to work with vendors, but we don't ever plan to open source it. What should I do?

You should use Git-on-Borg. GitHub is only for code that is or will be open sourced.

I want to update a repository that's already gone through the launch process. Do I have to do it again?

No! That's considered a patch, and you can update without a new Open Source launch entry. That said, depending on the update, you may need to go through your PA's launch process.

How do I rename a repository? Do I need to go through a new launch?

File a request, and we'll probably tell you it's ok to just do it yourself.

How do I split up a repository into multiple repos?

File a new Ariane launch, explaining in the description that you are simply splitting up an existing repository, and link to your original Ariane launch. You can approve the Eng bit yourself, but follow the rest of the process as normal: stage your code so that we can verify the structure and licensing, specify the name of the new desired GitHub repo, etc.

For really large refactors, you can contact emailremoved@.

What about projects from before I worked at Google?

For any project that you created on your personal GitHub account before starting at Google, you are free to do the following: 1) change the license documentation, including adding or removing any license of your choice to the repository, 2) file bugs against the project, and 3) accept external patches to the project.

To continue writing code for the project yourself, it is advised that you proceed through the go/patching process (but you must first add an open source license if it doesn't already have one). Otherwise, you will need to obtain permission through go/iarc in order to proceed with authoring code for the project entirely independently from Google.

What happens to my side projects after I leave Google?

See "Post Google Side Projects".