opensource.google.com

Menu

Docs

Releasing Code as Open Source

This is the process for releasing new open source projects/repositories. This process applies to all types of projects: personal (at home), 20%, and new Google open source releases that aren’t part of an already-established open source project (like Chromium or Android).

TIP: Changes to existing open source projects should follow go/patching.

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

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

This graph can help you understand the process:

G ip I need or want to own the copyright iarc File a request with IARC ip->iarc Yes update This is a patch, or fewer than 100 lines of code ip->update No patch Follow patching policy iarc->patch update->patch Yes type This is a personal (not work-related) project update->type No personal Release in a personal account or Google-managed org patch->personal type->personal Yes google Release in a Google-managed org type->google No

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.

NOTE: Coming soon! A spreadsheet you can use to track the steps required to complete a launch!

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.

2. Stage

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

NOTE: These steps require access to a Linux workstation or CloudTop instance. We’re working on removing this requirement.

  1. Push your code to an internal git-on-borg repo
  2. Set the repository ACLs to ensure that reviewers and Cross linter can access your code
  3. Run the Cross linter (go/cross) to check your repository and then fix any warnings

3. Get approval

Read more at go/releasing/approval

  1. Create an Ariane Launch on your team or PA’s calendar (if you’re releasing a new product or website)
  2. Add the open source calendar. Ordering is important – must be secondary
  3. Ensure you set the fields as described on go/releasing/approval#settings
  4. Wait for approval

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

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/repo 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. Add your project to the Open Source Project Database
  5. Tell the internet about your project
  6. [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

Q: What’s the practical difference between a work-related project and a personal project?

A: There are a few differences in the process for getting approval for a personal project.

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 personal project, then you can choose to release it in a Google-managed organization, or you can release it under your personal GitHub account.

NOTE: Not sure if it’s a work or personal project? Ask emailremoved@.

Approvals: Work projects may have more approvals (privacy, pcounsel, etc…).

Disclaimer: Personal projects should include a disclaimer that it is “not an official Google product”.

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

A: 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.

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

A: 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.

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

A: 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 director. We’re trying to save you trouble later on.

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

Yes! We’re working on it!

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

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

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

A: Right now our tooling requires access to a Linux workstation or CloudTop instance. We’re working on Mac support.

Q: 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?

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

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

A: 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.

Need help?

Email emailremoved@. We’re happy to help!

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.