(This is part of the process for releasing Google-owned code as open source. There are different processes for patches and personal projects.)
Once your launch has been approved, you will get an email detailing next steps for your launch.
Unless your project is an official Google product, you must state "This is not an officially supported Google product" in an appropriate location such as the project's README file.
We do this to help set appropriate expectations for users of these projects. Projects that include this label may not be staffed like larger, supported products such as Android, Chromium, or Go are. Support and/or new releases may be limited.
While it's certainly possible to have general discussion on an issue tracker, many teams find it helpful to keep those things separated. There are a number of options at your disposal for these kinds of discussions, including:
- if your project has Google Workspace (née GSuite) enabled for your domain, use a Google Group within that domain
- a public Google Group
- Group name and email address should both be set to your project's name
- In "Basic Permissions", allow the public to both view and post messages
- Make sure you have a sufficient number of group admins in case people leave Google
- good old IRC (Libera is often favored among open source projects)
Make sure you advertise this on your project's home page. And keep in mind that third-party services like Slack cannot be used to discuss any confidential or proprietary Google information, even if done in a private channel. They are fine to use for public discussions, but any internal team discussion should happen internally.
Distributing build artifacts
To distribute build artifacts into repositories like npm, pypi, rubygems, etc, see go/releasing/distributing.
Publishing apps in Google Play
If you've released code for an Android project, you'll likely want to share a build of it somewhere end users can find it. Google has official accounts in the Google Play Store which are used to publish apps we want to keep associated with Google's brand. See go/android-apps or contact emailremoved@ and ask them if your app should be released via one of those accounts. If so, they will provide directions on how to proceed.
Publishing apps in the Chrome Web Store
If you want to get a Chrome App or Extension released as officially "by Google", please see the Chrome Web Store team's instructions. Most open source Chrome Apps and Extensions won't be published as "by Google" and you may publish them in the store using your personal developer account after completing all previous steps of this go/releasing process.
Creating your repository and publishing your code
Once your Ariane launch has been fully approved, visit go/github/repo to create your repository if you're launching it into a Google-managed organization. If you've been approved to launch in your personal GitHub account, please create the repository as you would normally.
Once your project is released publicly, change your Ariane launches status to "Launched".
Importing into Google
If you are planning to regularly mirror the source from Google internal repos to public ones (or vice versa) Copybara provides workflows and tools for this.
Telling the world
Here are some ideas for stirring up interest in your project. We recommend getting these ready before making the project visible to the public and posting them on your launch day.
- Post to any mailing lists or forums where an announcement of your project would be on-topic, including emailremoved@
- If you have a personal blog, blog about your project
- Write a post for the Google Open Source Blog — we love to feature new projects or major updates
- Use the Corp Comms Social Toolkit at sites/social-toolkit
- Speak at conferences about your project; please see the Corp Comms Speaker Center at go/speakercenter for details