Releasing and Publicizing
Once your launch has been approved, you will get an email from emailremoved@ detailing next steps for your launch.
The regulations surrounding cryptographic software are notoriously complex, so we have people who specialize in complying with them.
You do not need to contact the export compliance team if your project only provides encryption functions relating to authentication and digital signatures. However, if your project performs or uses data encryption — such as providing crypto libraries or using https, OpenSSL, OpenVPN, or other encryption protocols to perform data encryption — then email emailremoved@ on the day that your code is made public with the following information:
- Google project owner name(s)
- Google product name (e.g., Google AdWords API)
- The URL where the source code will be published.
If you have any questions about this specific topic, please email emailremoved@.
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:
- 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
- External chat services like Slack, Discord, Gitter, Spectrum, or Discourse
- good old IRC (freenode 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.
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.
- Add your project to the Open Source Project Database.
- Post to any mailing lists or forums where an announcement of your project would be on-topic
- 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
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.