Posts from 2018

Introducing a Web Component and Data API for Quick, Draw!

Thursday, November 15, 2018

Over the past couple years, the Creative Lab in collaboration with the Handwriting Recognition team have released a few experiments in the realm of “doodle” recognition.  First, in 2016, there was Quick, Draw!, which uses a neural network to guess what you’re drawing.  Since Quick, Draw! launched we have collected over 1 billion drawings across 345 categories.  In the wake of that popularity, we open sourced a collection of 50 million drawings giving developers around the world access to the data set and the ability to conduct research with it.

"The different ways in which people draw are like different notes in some universally human scale" - Ian Johnson, UX Engineer @ Google

Since the initial dataset was released, it has been incredible to see how graphs, t-sne clusters, and simply overlapping millions of these doodles have given us the ability to infer interesting human behaviors, across different cultures.  One example, from the Quartz study, is that 86% of Americans (from a sample of 50,000) draw their circles counterclockwise, while 80% of Japanese (from a sample of 800) draw them clockwise. Part of this pattern in behavior can be attributed to the strict stroke order in Japanese writing, from the top left to the bottom right.

It’s also interesting to see how the data looks when it’s overlaid by country, as Kyle McDonald did, when he discovered that some countries draw their chairs in perspective while others draw them straight on.

On the more fun, artistic spectrum, there are some simple but clever uses of the data like Neil Mendoza’s face tracking experiment and Deborah Schmidt’s letter collages.
See the video here of Neil Mendoza mapping Quick, Draw! facial features to your own face in front of a webcam

See the process video here of Deborah Schmidt packing QuickDraw data into letters using OpenFrameworks
Some handy tools have also been released from the community since the release of all this data, and one of those that we’re releasing now is a Polymer component that allows you to display a doodle in your web-based project with one line of markup:

The Polymer component is coupled with a Data API that layers a massive file directory (50 million files) and returns a JSON object or an HTML canvas rendering for each drawing.  Without downloading all the data, you can start creating right away in prototyping your ideas.  We’ve also provided instructions for how to host the data and API yourself on Google Cloud Platform (for more serious projects that demand a higher request limit).  

One really handy tool when hosting an API on Google Cloud is Cloud Endpoints.  It allowed us to launch a demo API with a quota limit and authentication via an API key.  

By defining an OpenAPI specification (here is the Quick, Draw! Data API spec) and adding these three lines to our app.yaml file, an Extensible Service Proxy (ESP) gets deployed with our API backend code (more instructions here):
  rollout_strategy: managed
Based on the OpenAPI spec, documentation is also automatically generated for you:

We used a public Google Group as an access control list, so anyone who joins can then have the API available in their API library.
The Google Group used as an Access Control List
This component and Data API will make it easier for  creatives out there to manipulate the data for their own research.  Looking to the future, a potential next step for the project could be to store everything in a single database for more complex queries (i.e. “give me an recognized drawing from China in March 2017”).  Feedback is always welcome, and we hope this inspires even more types of projects using the data! More details on the project and the incredible research projects done using it can be found on our GitHub repo

By Nick Jonas, Creative Technologist, Creative Lab

Editor's Note: Some may notice that this isn’t the only dataset we’ve open sourced recently! You can find many more datasets in our open source project directory.

Google Summer of Code: 15 years strong!

Wednesday, November 14, 2018

Google Open Source is proud to announce Google Summer of Code (GSoC) 2019 – the 15th year of the program! We look forward to introducing the 15th batch of student developers to the world of open source and matching them with open source projects.

Over the last 14 years GSoC has provided over 14,000 university students from 109 countries with an opportunity to hone their skills by contributing to open source projects during their summer break. Participants gain invaluable experience working directly with mentors on open source projects, and earn a stipend upon successful completion of their project.

We’re excited to keep the tradition going! Applications for interested open source project organizations open on January 15, 2019, and student applications open March 25.

Are you an open source project interested in learning more? Visit the program site and read the mentor guide to learn more about what it means to be a mentor organization and how to prepare your community and your application. We welcome all types of organizations – large and small – and are eager to involve first time projects. Each year, about 20% of the organizations we accept are completely new to GSoC.

Are you a university student keen on learning about how to prepare for the 2019 GSoC program? It’s never too early to start thinking about your proposal or about what type of open source organization you may want to work with. You should read the student guide for important tips on preparing your proposal and what to consider if you wish to apply for the program in March. You can also get inspired by checking out the 200+ organizations that participated in Google Summer of Code 2018 as well as the projects that students worked on.

We encourage you to explore other resources and you can learn more on the program website.

By Stephanie Taylor, GSoC Program Lead

Google Code-in 2018 contest for teenagers begins today

Tuesday, October 23, 2018

Today marks the start of the 9th consecutive year of Google Code-in (GCI). This is the biggest and best contest ever and we hope you’ll join us for the fun!

What is Google Code-in?

Our global, online contest introducing students to open source development. The contest runs for 7 weeks until December 12, 2018.

Who can register?

Pre-university students ages 13-17 that have their parent or guardian’s permission to register for the contest.

How do students register and participate?

Students can register for the contest beginning today at Once students have registered and the parental consent form has been submitted and approved by Program Administrators students can choose which contest “task” they want to work on first. Students choose the task they find interesting from a list of thousands of available tasks created by 27 participating open source organizations. Tasks take an average of 3-5 hours to complete. There are even beginner tasks that are a wonderful way for students to get started in the contest.

The task categories are:
  • Coding
  • Design
  • Documentation/Training
  • Outreach/Research
  • Quality Assurance

Why should students participate?

Students not only have the opportunity to work on a real open source software project, thus gaining invaluable skills and experience, but they also have the opportunity to be a part of the open source community. Mentors are readily available to help answer their questions while they work through the tasks.

Google Code-in is a contest so there are prizes! Complete one task and receive a digital certificate, three completed tasks and you’ll also get a fun Google t-shirt. Finalists earn the coveted hoodie. Grand Prize winners (2 from each organization) will receive a trip to Google headquarters in California!


Over the last 8 years, more than 8,100 students from 107 countries have successfully completed over 40,000 tasks in GCI. Curious? Learn more about GCI by checking out the Contest Rules and FAQs. And please visit our contest site and read the Getting Started Guide.

Teachers, if you are interested in getting your students involved in Google Code-in we have resources available to help you get started.

By Stephanie Taylor, Google Open Source

Building great open source documentation

Monday, October 15, 2018

When developers use, choose, and contribute to open source software, effective documentation can make all the difference between a positive experience or a negative experience.

In fact, a 2017 GitHub survey that “Incomplete or Confusing Documentation” is the top complaint about open source software, TechRepublic writes “Ask a developer what her primary gripes with open source are, and documentation gets top billing, and by a wide margin.”

Technical writers across Google are addressing this issue, starting with open source projects in Google Cloud. We'll be sharing what we learn along the way and are excited to offer this brief guide as a starting point.

Open source software documentation

Providing effective documentation for open source software can build strong, inclusive communities and increase the usage of your product. The same factors that encourage collaborative development in open source projects can have the same positive results with documentation. Open source software provides unique ways to create effective documentation.

When software is open sourced, users are regarded as contributors and can access the source code and the documentation. They’re encouraged to submit additions, fix code, report bugs, and update documentation. Having more contributors can increase the rate at which software and documentation evolve.

The best way to accelerate software adoption is to describe its benefits and demonstrate how to use it. The benefits of timely, effective, and accurate content are numerous. Because documentation can save enough time and money to pay for itself, it:
  • Helps to create inclusive communities
  • Makes for a better software product
  • Promotes product adoption 
  • Reduces cost of ownership
  • Reduces the user’s learning curve
  • Makes for happy users
  • Improves the user interface
When documentation is inadequate, the opposite can occur. Incorrect, old, or missing documentation can:
  • Waste time
  • Cause errors and destroy data
  • Turn away customers
  • Increase support costs
  • Shorten a product’s life span

Why supplying effective documentation can be such a challenge

Useful documentation takes time to write and must be updated with the software. Did the installation process change? Are there better ways to configure performance? Was the user interface modified? Were new features introduced? Updates like these must be explained to new and existing customers.

It’s not enough to add words to a file and call it documentation.

How many times have you tried to use documentation that was five years out-of-date? How long did it take you to find another solution? (Not long, right?) Using old documentation can be like hiking an overgrown trail. The prospects of rogue branches, poison ivy, and getting lost suggest you are unlikely to emerge unscathed.

At first blush, writing documentation may seem optional. However, as a developer, you can literally be so close to your product that you take its features and purpose for granted. But your customers have no idea what you know, or how to apply what you know to address their business challenges. And time is money.

Remember the swimmer who got halfway across the English Channel only to say, “I’m tired,” before turning around and swimming back to shore? Ignoring the need for documentation is like that. Developing a software product gets you some of the way to your goal whereas helpful documentation fulfills your goal.

Momentum matters a lot. If you can settle into a rhythm of implementing new features, fixing bugs in the code, as well as writing and updating documentation, you can propel yourself to success.

Create an inclusive open source community

In the same GitHub survey referenced above, 95% of the respondents were men but evidence suggests that clear documentation:
  • Can contribute to inclusive communities
  • Is more highly valued by those groups who are typically under-represented
Documentation that effectively explains a project's processes, such as contributing to guides and defining codes of conduct, is valued more by groups that are underrepresented in the open source community, such as women.

Factors that can lead to ineffective documentation

Conditions like these almost always compromise the quality of documentation:
  • Belief that it’s enough for open source software to just work.
  • Notion that a specification is as good as instructional text.
  • Idea that casual unreviewed contributions are sufficient.
  • Belief that unscheduled and unspecified software updates are acceptable.
  • Minimal to no style guidelines.

Conquer your documentation challenges

Use these best practices to provide helpful and timely documentation:

1. Identify common terminology

Define and influence the usage and adoption of terminology for your open source project. Use the same terminology in the guides and in the product. Involving a writer early in product development can lead to a natural synergy between the user interface, guides, and training materials.

With clear definitions of terms and consistent usage in the documentation, you can teach your community to speak a common language. As a result, everyone in your products’ ecosystem can communicate more effectively with each other.

2. Provide contribution guidelines describes exactly why contribution guidelines are so important. Consider how Kubernetes describes the types of documentation contributions your users can make and how to make them.

3. Create a documentation template

To make sure your contributors provide details in a consistent format, consider providing a document template to capture details for common topics such as:
  • Overview
  • Prerequisites
  • Procedural steps
  • What’s next

4. Document new and updated features

When a feature is added or updated, ask that it be documented. You can even provide guidelines to capture key information. Initially, some may think it cumbersome to require that  instructions be provided early in the development process. However, think of documentation to be like testing in that nobody really wants to do it but things work so much better. Sufficient testing and teaching are good for quality and momentum.

Code reviewers and maintainers of open source software have power. Code reviewers can (and should) withhold approval until documentation is sufficient.

Remember, not all changes require documentation updates. Here’s a good rule of thumb:

If an update to a project will require users to change their behavior, then documentation updates may be required.

If not, how will your customers find the new feature you worked so hard to implement? Said another way, if a change doesn't require tests, it probably doesn't require docs, either. Use your best judgement. For example, code refactoring and experimental tweaks need not be tested or documented.

As always, simplify and automate this process as much as possible. At Google, teams can enforce a presubmit check that either looks for a flag that indicates a doc update isn't necessary (presubmit checks for style issues can prevent a lot of arguments, too). We also allow owners of a file to submit changes without a review.

If your team balks at this requirement, remind them that simple project documentation is about sharing the information you have in your head so that many others can access it later without bothering you.

Documentation updates aren't typically onerous! The size of your documentation change scales with the size of your pull request (PR). If your PR contains a thousand lines of code, you may need to write a few hundred lines of documentation. If the PR contains a one-line change, you may need to change a word or two.

Finally, remember that documentation needn’t be perfect, but instead fit for use. What's most important is that key information is clearly conveyed.

5. Conduct regular freshness reviews

At least every quarter, review and update your content. Many hands make for many voices, many typos, and many inconsistencies. Don’t let content persist unchecked for years without periodically confirming it’s still useful.

In conclusion, success breeds success. By effectively documenting open source software, everybody wins.

We hope you'll put this guidance to work and help your open source project become even more successful! We'd love to hear from you if you do, or if you have questions or useful advice to share.

By Janet Davies, Google OpenDocs

Outline: secure access to the open web

Wednesday, October 10, 2018

Censorship and surveillance are challenges that many journalists around the world face on a daily basis. Some of them use a virtual private network (VPN) to provide safer access to the open internet, but not all VPNs are equally reliable and trustworthy, and even fewer are open source.

That’s why Jigsaw created Outline, a new open source, independently audited platform that lets any organization easily create and operate their own VPN.

Outline’s most striking feature is arguably how easy it is to use. An organization starts by downloading the Outline Manager app, which lets them sign in to DigitalOcean, where they can host their own VPN, and set it up with just a few clicks. They can also easily use other cloud providers, provided they have shell access to run the installation script. Once an Outline server is set up, the server administrator can create access credentials and share with their network of contacts, who can then use the Outline clients to connect to it.

A core element to any VPN’s security is the protocol that the server and clients use to communicate. When we looked at the existing protocols, we realized that many of them were easily identifiable by network adversaries looking to spot and block VPN traffic. To make Outline more resilient against this threat, we chose Shadowsocks, a secure, handshake-less, and open source protocol that is known for its strength and performance, and enjoys the support of many developers worldwide. Shadowsocks is a combination of a simplified SOCKS5-like routing protocol, running on top of an encrypted channel. We chose the AEAD_CHACHA20_POLY1305 cipher, which is an IETF standard and provides the security and performance users need.

Another important component to security is running up-to-date software. We package the server code as a Docker image, enabling us to run on multiple platforms, and allowing for automatic updates using Watchtower. On DigitalOcean installations, we also enable automatic security updates on the host machine.

If security is one of the most critical parts of creating a better VPN, usability is the other. We wanted Outline to offer a consistent, simple user experience across platforms, and for it to be easy for developers around the world to contribute to it. With that in mind, we use the cross-platform development framework Apache Cordova for Android, iOS, macOS and ChromeOS, and Electron for Windows. The application logic is a web application written in TypeScript, while the networking code had to be written in native code for each platform. This setup allows us to reutilize most of code, and create consistent user experiences across diverse platforms.

In order to encourage a robust developer community we wanted to strike a balance between simplicity, reproducibility, and automation of future contributions. To that end, we use Travis for continuous builds and to generate the binaries that are ultimately uploaded to the app stores. Thanks to its cross-platform support, any team member can produce a macOS or Windows binary with a single click. We also use Docker to package the build tools for client platforms, and thanks to Electron, developers familiar with the server's Node.js code base can also contribute to the Outline Manager application.

You can find our code in the Outline GitHub repositories and more information on the Outline website. We hope that more developers join the project to build technology that helps people connect to the open web and stay more safe online.

By Vinicius Fortuna, Jigsaw

These 27 organizations will mentor students in Google Code-in 2018

Tuesday, September 18, 2018

We’re excited to welcome 27 open source organizations to mentor students as part of Google Code-in 2018. The contest, now in its ninth year, offers 13-17 year old pre-university students from around the world an opportunity to learn and practice their skills while contributing to open source projects–all online!

Google Code-in starts for students on October 23rd. Students are encouraged to learn about the participating organizations ahead of time and can get started by clicking on the links below:
  • AOSSIE: Australian umbrella organization for open source projects.
  • Apertium: rule-based machine translation platform.
  • Catrobat: visual programming for creating mobile games and animations.
  • CCExtractor: open source tools for subtitle generation.
  • CloudCV: building platforms for reproducible AI research.
  • coala: a unified interface for linting and fixing code, regardless of the programming languages used.
  • Copyleft Games Group: develops tools, libraries, and game engines.
  • Digital Impact Alliance: collaborative space for multiple open source projects serving the international development and humanitarian response sectors.
  • Drupal: content management platform.
  • Fedora Project: a free and friendly Linux-based operating system.
  • FOSSASIA: developing communities across all ages and borders to form a better future with Open Technologies and ICT.
  • Haiku: operating system specifically targeting personal computing.
  • JBoss Community: a community of projects around JBoss Middleware.
  • KDE Community: produces FOSS by artists, designers, programmers, translators, writers and other contributors.
  • Liquid Galaxy: an interactive, panoramic and immersive visualization tool.
  • MetaBrainz: builds community maintained databases.
  • MovingBlocks: a Minecraft-inspired open source game.
  • OpenMRS: open source medical records system for the world.
  • OpenWISP: a network management system aimed at low cost networks.
  • OSGeo: building open source geospatial tools.
  • PostgreSQL: relational database system.
  • Public Lab: open software to help communities measure and analyze pollution.
  • RTEMS Project: operating system used in satellites, particle accelerators, robots, racing motorcycles, building controls, medical devices.
  • Sugar Labs: learning platform and activities for elementary education.
  • SCoRe: research lab seeking sustainable solutions for problems faced by developing countries.
  • The ns-3 Network Simulator Project: packet-level network simulator for research and education.
  • Wikimedia: non-profit foundation dedicated to bringing free content to the world, operating Wikipedia.
These 27 organizations are hard at work creating thousands of tasks for students to work on, including code, documentation, design, quality assurance, outreach, research and training tasks. The contest starts for students on Tuesday, October 23rd at 9:00am Pacific Time.

You can learn more about Google Code-in on the contest site where you’ll find Frequently Asked Questions, Important Dates and flyers and other helpful information including the Getting Started Guide.

Want to talk with other students, mentors, and organization administrations about the contest? Check out our discussion mailing list. We can’t wait to get started!

By Stephanie Taylor, Google Open Source

Google Code-in 2018 is looking for great open source organizations to apply

Thursday, September 6, 2018

We are accepting applications for open source organizations interested in participating in Google Code-in 2018. Google Code-in (GCI) invites pre-university students ages 13-17 to learn by contributing to open source software.

Working with young students is a special responsibility and each year we hear inspiring stories from mentors who participate. To ensure these new, young contributors have a solid support system, we only select organizations that have gained experience in mentoring students by previously taking part in Google Summer of Code.

Organization applications are now open and all interested open source organizations must apply before Monday, September 17 at 16:00 UTC.

In 2017, 25 organizations were accepted – 9 of which were participating in GCI for the first time! Over the last 8 years, 8,108 students from 107 countries have completed more than 40,000 tasks for participating open source projects. Tasks fall into 5 categories:
  • Code: writing or refactoring.
  • Documentation/Training: creating/editing documents and helping others learn more.
  • Outreach/Research: community management, outreach/marketing, or studying problems and recommending solutions.
  • Quality Assurance: testing and ensuring code is of high quality.
  • Design: graphic design or user interface design.
Once an organization is selected for Google Code-in 2018 they will define these tasks and recruit mentors from their communities who are interested in providing online support for students during the seven week contest.

You can find a timeline, FAQ and other information about Google Code-in on our website. If you’re an educator interested in sharing Google Code-in with your students, you can find resources here.

By Stephanie Taylor, Google Open Source

Introducing the Tink cryptographic software library

Thursday, August 30, 2018

Cross-posted on the Google Security Blog

At Google, many product teams use cryptographic techniques to protect user data. In cryptography, subtle mistakes can have serious consequences, and understanding how to implement cryptography correctly requires digesting decades' worth of academic literature. Needless to say, many developers don’t have time for that.

To help our developers ship secure cryptographic code we’ve developed Tink—a multi-language, cross-platform cryptographic library. We believe in open source and want Tink to become a community project—thus Tink has been available on GitHub since the early days of the project, and it has already attracted several external contributors. At Google, Tink is already being used to secure data of many products such as AdMob, Google Pay, Google Assistant, Firebase, the Android Search App, etc. After nearly two years of development, today we’re excited to announce Tink 1.2.0, the first version that supports cloud, Android, iOS, and more!

Tink aims to provide cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Tink is built on top of existing libraries such as BoringSSL and Java Cryptography Architecture, but includes countermeasures to many weaknesses in these libraries, which were discovered by Project Wycheproof, another project from our team.

With Tink, many common cryptographic operations such as data encryption, digital signatures, etc. can be done with only a few lines of code. Here is an example of encrypting and decrypting with our AEAD interface in Java:
     // 1. Generate the key material.
    KeysetHandle keysetHandle = KeysetHandle.generateNew(
     // 2. Get the primitive.
    Aead aead = AeadFactory.getPrimitive(keysetHandle);
     // 3. Use the primitive.
    byte[] plaintext = ...;
    byte[] additionalData = ...;
    byte[] ciphertext = aead.encrypt(plaintext, additionalData);
Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and nonce reuse makes it insecure, then Tink does not allow the user to pass nonces. Interfaces have security guarantees that must be satisfied by each primitive implementing the interface. This may exclude some encryption modes. Rather than adding them to existing interfaces and weakening the guarantees of the interface, it is possible to add new interfaces and describe the security guarantees appropriately.

We’re cryptographers and security engineers working to improve Google’s product security, so we built Tink to make our job easier. Tink shows the claimed security properties (e.g., safe against chosen-ciphertext attacks) right in the interfaces, allowing security auditors and automated tools to quickly discover usages where the security guarantees don’t match the security requirements. Tink also isolates APIs for potentially dangerous operations (e.g., loading cleartext keys from disk), which allows discovering, restricting, monitoring and logging their usage.

Tink provides support for key management, including key rotation and phasing out deprecated ciphers. For example, if a cryptographic primitive is found to be broken, you can switch to a different primitive by rotating keys, without changing or recompiling code.

Tink is also extensible by design: it is easy to add a custom cryptographic scheme or an in-house key management system so that it works seamlessly with other parts of Tink. No part of Tink is hard to replace or remove. All components are composable, and can be selected and assembled in various combinations. For example, if you need only digital signatures, you can exclude symmetric key encryption components to minimize code size in your application.

To get started, please check out our HOW-TO for Java, C++ and Obj-C. If you'd like to talk to the developers or get notified about project updates, you may want to subscribe to our mailing list. To join, simply send an empty email to You can also post your questions to StackOverflow, just remember to tag them with tink.

We’re excited to share this with the community, and welcome your feedback!

By Thai Duong, Information Security Engineer, on behalf of Tink team

Announcing Google Code-in 2018: nine is just fine!

Wednesday, August 29, 2018

We are excited to announce the 9th consecutive year of the Google Code-in (GCI) contest! Students ages 13 through 17 from around the world can learn about open source development by working on real open source projects, with mentorship from active developers. GCI begins on Tuesday, October 23, 2018 and runs for seven weeks, ending Wednesday, December 12, 2018.

Google Code-in is unique because, not only do the students choose what they want to work on from the 2,500+ tasks created by open source organizations, but they have mentors available to help answer their questions as they work on each of their tasks.

Getting started in open source software can be a daunting task for a developer of any age. What organization should I work with? How do I get started? Does the organization want my help? Am I too inexperienced?

The beauty of GCI is that participating open source organizations realize teens are often first time contributors, so the volunteer mentors come prepared with the patience and the experience to help these newcomers become part of the open source community.

Open source communities thrive when there is a steady flow of new contributors who bring new perspectives, ideas and enthusiasm. Over the last 8 years, GCI open source organizations have helped 8,108 students from 107 countries make meaningful contributions. Many of these students are still participating in open source communities years later. Dozens have gone on to become Google Summer of Code (GSoC) students and even mentor other students.

The tasks that contest participants will complete vary in skill set and level, including beginner tasks any student can take on, such as “setup your development environment.” With tasks in five different categories, there’s something to fit almost any student’s skills:
  • Code: writing or refactoring
  • Documentation/Training: creating/editing documents and helping others learn more
  • Outreach/Research: community management, marketing, or studying problems and recommending solutions
  • Quality Assurance: testing and ensuring code is of high quality
  • Design: graphic design or user interface design
Open source organizations can apply to participate as mentoring organizations for in Google Code-in starting on Thursday, September 6, 2018. Google Code-in starts for students October 23rd!

Visit the contest site to learn more about the contest and find flyers, slide decks, timelines, and more.

By Stephanie Taylor, Google Open Source

That’s a wrap for Google Summer of Code 2018

Wednesday, August 22, 2018

We are pleased to announce that 1,072 students from 59 countries have successfully completed the 2018 Google Summer of Code (GSoC). Congratulations to all of our students and mentors who made this our biggest and best Google Summer of Code yet.

Over the past 12 weeks, GSoC students have worked diligently with 212 open source organizations and over 2,100 mentors from all around the world, learning to work with distributed teams and developing complex pieces of code. Student projects are now public – take a closer look at their work.

Open source communities need new ideas to keep projects thriving and evolving; GSoC students bring fresh perspectives while helping organizations enhance, extend, and refine their codebases. This is not the end of the road for GSoC students! Many will go on to become mentors in future years and many more will become long-term committers.

And finally, a big thank you to the mentors and organization administrators who make GSoC possible. Their dedication to welcoming new student contributors into their communities is awesome and inspiring. Thank you all!

By Mary Radomile, Google Open Source

ZuriHac 2018: Haskell hackathon in Rapperswil

Friday, August 17, 2018

Google Open Source recently co-sponsored a three-day hackathon for Haskell, an open source functional programming language. Ivan Krišto from Google’s Zürich office talks more about the event below.

Over the weekend of June 9th, Rapperswil, Switzerland became a home for 300 Haskellers. Hochschule für Technik Rapperswil hosted the seventh annual ZuriHac, the biggest Haskell Hackathon in Europe. ZuriHac is a free, international coding festival with the goal to expand our community and to build and improve Haskell libraries, tools and infrastructure.

Participants could choose to hack all day long, attend the Haskell beginners course led by Julie Moronuki, join the Glasgow Haskell Compiler (GHC) DevOps track organized by GHC contributors with the goal to bring in new contributors, listen to the Haskell flavoured talks, or socialize and swim in the lake. The event was colocated with C++ standardization committee meetings which offered a unique opportunity for sharing ideas between the two communities.

Here is a short summary of featured talks at ZuriHac.
The event concluded with a presentation of the results of the three day hackathon: project presentations.

Video by Hochschule für Technik Rapperswil.

Once again, we broke the attendance record! We’re already preparing for ZuriHac 2019 and hope to keep up this amazing growth. See you next year!

By Ivan Krišto, Software Engineer

Congratulations to the latest Google Open Source Peer Bonus winners

Wednesday, August 15, 2018

We are pleased to announce the latest round of Google Open Source Peer Bonus winners and the projects they support.

Open source software is a cornerstone of software development inside and outside of Google, and the Google Open Source Peer Bonus program is one way we thank the people who make our work possible. Twice a year we invite Googlers to nominate external contributors to be rewarded for their contribution to open source projects.

This time we have a truly international team of recipients from Australia, Brazil, Canada, Germany, India, Italy, Ireland, France, Japan, Netherlands, Russia, Singapore, Switzerland, Sweden, UK and USA. You can learn about previous recipients in these blog posts.

Projects range from Linux distributions and version control systems to monitoring and testing software. Some are part of the backbone of our industry, others are critical dependencies of specific products and services we offer. All of them are important to us!

Listed below are the individuals who gave us permission to thank them publicly:

Name Project Name Project
Sultan AlsawafAndroid KernelRavi Santosh GudimetlaKubernetes
Allan McRaeArch LinuxSteve KuznetsovKubernetes
Seth Pollackaws-encryption-providerHisham MuhammadLuaRocks
George GensureBazel BuildfarmYutaka Matsubarameinheld
Omar CornutDear ImGuiPulkit GoyalMercurial
Alessandro ArzilliDelveYuya NishiharaMercurial
Matt KleinEnvoyAdam Mummery-SmithMixin
Ivan GrokhotkovESP8266 core for ArduinoArnout EngelenNotion
Esther OnfroyExodus PrivacyBrian BrazilPrometheus
Yao LiForkliftBruno Oliveirapytest
Warner LoshFreeBSDJames FriedmanRMWC
Elijah NewrenGitSteve KlabnikRust Book
Gábor SzederGitJack LukicSemantic UI
Alvaro Viebrantzgoogle-cloud-iot-arduinoVidar HolenShellCheck
Richard MusiolGopherJS, go-wasmIvan PopelyshevSkia graphics in Chrome
Tobias FuruholmGrafeasSpencer GibbSpring Cloud
David PursehouseJGitDaniel AlmSwift gRPC
Brian GrangerJupyterYong TangTensorFlow
Rodrigo MenezeskopsJason ZamanTensorFlow, Gentoo, SELinux
Rohith JayawardenekopsKai SasakiTensorFlow.js
Kam KasraviKubeflowManraj GroverTensorFlow.js
Pete MacKinnonKubeflowStefan WeilTesseract
Christoph BleckerKubernetesSumana HarihareswaraWarehouse (PyPI)
Davanum SrinivasKubernetesJia Lizone.js

Once again we would like to express our gratitude and appreciation to current and former recipients for their hard work, time and devotion to open source. Without you these projects wouldn’t thrive!

We look forward to your ongoing contributions and can’t wait to recognize even more contributors for their work in 2019.

By Maria Tabak, Google Open Source

How we brought the latest version of Python to App Engine and Cloud Functions

Monday, August 13, 2018

At Cloud Next 2018, we added Python 3.7 support to Cloud Functions and now we’ve announced Python 3.7 support for the App Engine standard environment. These new runtimes allow you to write Python functions and apps using the latest version of Python and the rich ecosystem of packages available on Python Packaging Index (PyPI).

This new runtime marks a significant update to App Engine and was enabled by new open source software that we recently released: gVisor and FTL.

Python, straight from the source

Running Python 3.7 on App Engine and Cloud Functions required us to fundamentally rethink our infrastructure. Traditionally, meeting Google Cloud’s security requirements meant that we had to run a modified version of the Python interpreter. However, using a modified interpreter constrained some language features and only allowed us to support a limited set of whitelisted Python libraries.

Thanks to gVisor, a container sandbox that provides improved security and process isolation, we can now run the unmodified Python 3.7.0 interpreter. We’ve done extensive testing to make sure Python 3.7 is compatible with gVisor. As part of our compatibility testing, we run Python’s full suite of language tests, and tests for Python packages that are popular on PyPI. We’re committed to ensuring that everything you’ve come to know and love about Python is supported on our platform.

Seamless deployments

Most importantly, this change in our infrastructure makes it easier to take advantage of Python’s vast ecosystem. As a developer, you just add project dependencies to a requirements.txt file and deploy.

During deployment, FTL, a tool for building containers, fetches dependencies listed in your requirements.txt file and installs them alongside your app or function. FTL also includes a short-lived dependency cache, which speeds up repeated deployments if no changes are detected in your requirements.txt file. This is particularly useful if you find just need to re-deploy because you found a typo.

Keeping up with the Pythonistas

In making these changes, we also decided to expand the list of system packages that are included with each runtime’s Ubuntu 18.04 distribution. We think that will make life just a little bit easier for developers working with the latest release of Python.

Looking forward, we’re excited about how these changes will allow us to keep up with the Python community’s progress as they release new versions and libraries. Please let us know what you think and if you run into any challenges.

You can learn more about how to get started with it on App Engine and Cloud Functions in our documentation. We can’t wait to see what you build with Python 3.7.

By Stewart Reichling, Product Manager

OpenMetrics project accepted into CNCF Sandbox

Friday, August 10, 2018

For the past several months, engineers from Google Cloud, Prometheus, and other vendors have been aligning on OpenMetrics, a specification for metrics exposition. Today, the project was formally announced and accepted into the CNCF Sandbox, and we’re currently working on ways to support OpenMetrics in OpenCensus, a set of uniform tracing and stats libraries that work with multiple vendors’ services. This multi-vendor approach works to put architectural choices in the hands of developers.
OpenMetrics stems from the stats formats used inside of Prometheus and Google’s Monarch time-series infrastructure, which underpins both Stackdriver and internal monitoring applications. As such, it is designed to be immediately familiar to developers and capable of operating at extreme scale. With additional contributions and review from AppOptics, Cortex, Datadog, InfluxData, Sysdig, and Uber, OpenMetrics has begun the cross-industry collaboration necessary to drive adoption of a new specification.

OpenCensus provides automatic instrumentation, APIs, and exporters for stats and distributed traces across C++, Java, Go, Node.js, Python, PHP, Ruby, and .Net. Each OpenCensus library allows developers to automatically capture distributed traces and key RPC-related statistics from their applications, add custom data, and export telemetry to their back-end of choice. Google has been a key collaborator in defining the OpenMetrics specification, and we’re now focusing on how to best implement this inside of OpenCensus.

“Google has a history of innovation in the metric monitoring space, from its early success with Borgmon, which has been continued in Monarch and Stackdriver. OpenMetrics embodies our understanding of what users need for simple, reliable and scalable monitoring, and shows our commitment to offering standards-based solutions,” said Sumeer Bhola, Lead Engineer on Monarch and Stackdriver at Google.

For more information about OpenMetrics, please visit For more information about OpenCensus and how you can quickly enable trace and metrics collection from your application, please visit

By Morgan McLean, Product Manager for OpenCensus and Stackdriver APM

Introducing the new lead for Android Open Source Project

Wednesday, August 8, 2018

This week began with the announcement of Android 9 Pie and, as usual, the subsequent upstreaming of code to the Android Open Source Project (AOSP). But the release of Android 9 isn’t the only important Android news!

Tucked away in the announcement to the Android Building mailing list was this note:

“I also wanted to take a moment to introduce myself as the new Tech Lead / Manager for AOSP. My name is Jeff Bailey, and I’ve been involved in the Open Source community for more than two decades. Since I joined the Android team a few months ago, I’ve been learning how we do things and getting an understanding of how we could work better with the community. I’d love to hear from you: @JeffBaileyAOSP on Twitter or Be well!”

As Jeff notes in his introduction, he has a history in free and open source software (FOSS). He’s been an avid user, contributor, and maintainer since before the Open Source Definition was inked!

Jeff co-founded Savannah, where GNU software is developed and distributed, spent 15 years working on Debian, and has been an Ubuntu core developer. Further, he spent some time on the Google Open Source team and was involved in open sourcing Android back in 2008.

Open source projects, even those which originate inside of companies, are powered by the community of users and contributors that surround them. And those communities thrive when they have stewards who are steeped in the traditions of free and open source software. We’re excited for AOSP as Jeff takes the reins. He brings both technical and cultural skills to the table, and he’s been involved with the project since the beginning!

Suffice it to say, AOSP is in good hands. We welcome Jeff to his new role and, as he said in his introduction, he’d love to hear from the community: you can reach Jeff on Twitter and via email.

By Josh Simmons, Google Open Source

Magnificent mentors of Google Summer of Code 2018

Thursday, August 2, 2018

Mentors are the heart and soul of the Google Summer of Code (GSoC) program and have been for the last 14 years. Without their hard work and dedication, there would be no Google Summer of Code. These volunteers spend 4+ months guiding their students to create the best quality project possible while welcoming them into their communities – answering questions and providing help at all hours of the day, including weekends and holidays.

Thank you mentors and organization administrators! 

Each year we pore over heaps of data to extract some interesting statistics about the GSoC mentors. Here’s a quick synopsis of our 2018 crew:
  • Registered mentors: 2,819
  • Mentors with assigned student projects: 1,996
  • Mentors who have participated in GSoC for 10 or more years: 46
  • Mentors who have been a part of GSoC for 5 years or more: 272
  • Mentors that are former GSoC students: 627
  • Mentors that have also been involved in the Google Code-in program: 474
  • Percentage of new mentors: 36.5%
GSoC 2018 mentors are from all parts of the world, hailing from 75 countries!

If you want to see the stats for all 75 countries check out this list.

Another fun fact about our 2018 mentors: they range in age from 15-80 years old!
  • Average mentor age: 34
  • Median mentor age: 33
  • Mentors under 18 years old: 26*
GSoC mentors help introduce the next generation to the world of open source software development – for that we are very grateful. To show our appreciation, we invite two mentors from each of the 206 participating organizations to attend our annual mentor summit at the Google campus in Sunnyvale, California. It’s three days of community building, lively debate, learning best practices from one another, working to strengthen open source communities, good food, and lots and lots of chocolate.

Thank you to all of our mentors, organization administrators, and all of the “unofficial” mentors that help in the various open source organization’s communities. Google Summer of Code is a community effort and we appreciate each and every one of you.

Cheers to yet another great year!

By Stephanie Taylor, Google Open Source

* Most of these 26 young GSoC mentors started their journey in Google Code-in, our contest for 13-17 year olds that introduces young students to open source software development.

Announcing Cirq: an open source framework for NISQ algorithms

Wednesday, August 1, 2018

Cross-posted from the Google AI Blog

Over the past few years, quantum computing has experienced a growth not only in the construction of quantum hardware, but also in the development of quantum algorithms. With the availability of Noisy Intermediate Scale Quantum (NISQ) computers (devices with ~50 - 100 qubits and high fidelity quantum gates), the development of algorithms to understand the power of these machines is of increasing importance. However, a common problem when designing a quantum algorithm on a NISQ processor is how to take full advantage of these limited quantum devices—using resources to solve the hardest part of the problem rather than on overheads from poor mappings between the algorithm and hardware. Furthermore some quantum processors have complex geometric constraints and other nuances, and ignoring these will either result in faulty quantum computation, or a computation that is modified and sub-optimal.*

Today at the First International Workshop on Quantum Software and Quantum Machine Learning (QSML), the Google AI Quantum team announced the public alpha of Cirq, an open source framework for NISQ computers. Cirq is focused on near-term questions and helping researchers understand whether NISQ quantum computers are capable of solving computational problems of practical importance. Cirq is licensed under Apache 2, and is free to be modified or embedded in any commercial or open source package.

Once installed, Cirq enables researchers to write quantum algorithms for specific quantum processors. Cirq gives users fine tuned control over quantum circuits, specifying gate behavior using native gates, placing these gates appropriately on the device, and scheduling the timing of these gates within the constraints of the quantum hardware. Data structures are optimized for writing and compiling these quantum circuits to allow users to get the most out of NISQ architectures. Cirq supports running these algorithms locally on a simulator, and is designed to easily integrate with future quantum hardware or larger simulators via the cloud.

We are also announcing the release of OpenFermion-Cirq, an example of a Cirq based application enabling near-term algorithms. OpenFermion is a platform for developing quantum algorithms for chemistry problems, and OpenFermion-Cirq is an open source library which compiles quantum simulation algorithms to Cirq. The new library uses the latest advances in building low depth quantum algorithms for quantum chemistry problems to enable users to go from the details of a chemical problem to highly optimized quantum circuits customized to run on particular hardware. For example, this library can be used to easily build quantum variational algorithms for simulating properties of molecules and complex materials.

Quantum computing will require strong cross-industry and academic collaborations if it is going to realize its full potential. In building Cirq, we worked with early testers to gain feedback and insight into algorithm design for NISQ computers. Below are some examples of Cirq work resulting from these early adopters:
To learn more about how Cirq is helping enable NISQ algorithms, please visit the links above where many of the adopters have provided example source code for their implementations.

Today, the Google AI Quantum team is using Cirq to create circuits that run on Google’s Bristlecone processor. In the future, we plan to make this processor available in the cloud, and Cirq will be the interface in which users write programs for this processor. In the meantime, we hope Cirq will improve the productivity of NISQ algorithm developers and researchers everywhere. Please check out the GitHub repositories for Cirq and OpenFermion-Cirq — pull requests welcome!

By Alan Ho, Product Lead and Dave Bacon, Software Lead, Google AI Quantum Team

We would like to thank Craig Gidney for leading the development of Cirq, Ryan Babbush and Kevin Sung for building OpenFermion-Cirq and a whole host of code contributors to both frameworks.

* An analogous situation is how early classical programmers needed to run complex programs in very small memory spaces by paying careful attention to the lowest level details of the hardware.

Introducing Data Transfer Project: an open source platform promoting universal data portability

Friday, July 20, 2018

In 2007, a small group of engineers in our Chicago office formed the Data Liberation Front, a team that believed consumers should have better tools to put their data where they want, when they want, and even move it to a different service. This idea, called “data portability,” gives people greater control of their information, and pushes us to develop great products because we know they can pack up and leave at any time.

In 2011, we launched Takeout, a new way for Google users to download or transfer a copy of the data they store or create in a variety of industry-standard formats. Since then, we've continued to invest in Takeout—we now call it Download Your Data—and today, our users can download a machine-readable copy of the data they have stored in 50+ Google products, with more on the way.

Now, we’re taking our commitment to portability a step further. In tandem with Microsoft, Twitter, and Facebook we’re announcing the Data Transfer Project, an open source initiative dedicated to developing tools that will enable consumers to transfer their data directly from one service to another, without needing to download and re-upload it. Download Your Data users can already do this; they can transfer their information directly to their Dropbox, Box, MS OneDrive, and Google Drive accounts today. With this project, the development of which we mentioned in our blog post about preparations for the GDPR, we’re looking forward to working with companies across the industry to bring this type of functionality to individuals across the web.

Our approach

The organizations involved with this project are developing tools that can convert any service's proprietary APIs to and from a small set of standardized data formats that can be used by anyone. This makes it possible to transfer data between any two providers using existing industry-standard infrastructure and authorization mechanisms, such as OAuth. So far, we have developed adapters for seven different service providers across five different types of consumer data; we think this demonstrates the viability of this approach to scale to a large number of use cases.

Consumers will benefit from improved flexibility and control over their data. They will be able to import their information into any participating service that offers compelling features—even brand new ones that could rely on powerful, cloud-based infrastructure rather than the consumers’ potentially limited bandwidth and capability to transfer files. Services will benefit as well, as they will be able to compete for users that can move their data more easily.

Protecting users’ data and keeping them in control

Data security and privacy are foundational to the design of the Data Transfer Project. Services must first agree to allow data transfer between them, and then they will require that individuals authenticate each account independently. All credentials and user data will be encrypted both in transit and at rest. The protocol uses a form of perfect forward secrecy where a new unique key is generated for each transfer. Additionally, the framework allows partners to support any authorization mechanism they choose. This enables partners to leverage their existing security infrastructure when authorizing accounts.

As it is an open source product, anyone can inspect the code to verify that data isn't being collected or used for profiling purposes. Tech savvy consumers are also free to download and run an instance of the framework themselves. Interested parties can learn more at the Data Transfer Project website, which explains the technical foundations behind the project and goes into greater detail on how it works.

How to get involved

It is very early days for the Data Transfer Project and we encourage the developer community to join us and help extend the platform to support many more data types, service providers, and hosting solutions.

The Data Transfer Project’s open source code can be found at and you can learn more about Google’s approach to portability in our paper, where we describe our history with this topic and the values and principles that motivated us to invest in the Data Transfer Project. Our prototype already supports data transfer for several product verticals including: photos, mail, contacts, calendar, and tasks. These are enabled by existing, publicly available APIs from Google, Microsoft, Twitter, Flickr, Instagram, Remember the Milk, and Smugmug.

Data portability makes it easy for consumers to try new services and use the ones that they like best. We’re thrilled to help drive an initiative that incentivizes companies large and small to continue innovating across the internet. We’re just getting started and we’re looking forward to what comes next.

By Brian Willard, Software Engineer and Greg Fair, Product Manager

Googlers on the road: CLS and OSCON 2018

Friday, July 13, 2018

Next week a veritable who’s who of free and open source software luminaries, maintainers and developers will gather to celebrate the 20th annual OSCON and the 20th anniversary of the Open Source Definition. Naturally, the Google Open Source and Google Cloud teams will be there too!

Program chairs at OSCON 2017, left to right:
Rachel Roumeliotis, Kelsey Hightower, Scott Hanselman.
Photo used with permission from O'Reilly Media.
This year OSCON returns to Portland, Oregon and runs from July 16-19. As usual, it is preceded by the free-to-attend Community Leadership Summit on July 14-15.

If you’re curious about our outreach programs, our approach to open source, or any of the open source projects we’ve released, please find us! We’re eager to chat. You’ll find us and many other Googlers throughout the week on stage, in the expo hall, and at several special events that we’re running, including:
Here’s a rundown of the sessions we’re hosting this year:

Sunday, July 15th (Community Leadership Summit)

11:45am   Asking for time and/or money by Cat Allman

Monday, July 16th (Tutorials)

9:00am    Getting started with TensorFlow by Josh Gordon
1:30pm    Introduction to natural language processing with Python by Barbara Fusinska

Tuesday, July 17th (Tutorials)

9:00am    Istio Day opening remarks by Kelsey Hightower
9:00am    TensorFlow Day opening remarks by Edd Wilder-James
9:05am    Sailing to 1.0: Istio community update by April Nassi
9:05am    The state of TensorFlow by Sandeep Gupta
9:30am    Introduction to fairness in machine learning by Hallie Benjamin
9:55am    Farm to table: A TensorFlow story by Gunhan Gulsoy
11:00am  Hassle-free, scalable machine learning with Kubeflow by Barbara Fusinska
11:05am  Istio: Zero-trust communication security for production services by Samrat Ray, Tao Li, and Mak Ahmad
12:00pm  Project Magenta: Machine learning for music and art by Sherol Chen
1:35pm    Istio à la carte by Daniel Ciruli

Wednesday, July 18th (Sessions)

9:00am    Wednesday opening welcome by Kelsey Hightower
11:50am  Machine learning for continuous integration by Joseph Gregorio
1:45pm    Live-coding a beautiful, performant mobile app from scratch by Emily Fortuna and Matt Sullivan
2:35pm    Powering TensorFlow with big data using Apache Beam, Flink, and Spark by Holden Karau
5:25pm    Teaching the Next Generation to FLOSS by Josh Simmons

Thursday, July 19th (Sessions)

9:00am    Thursday opening welcome by Kelsey Hightower
9:40am    20 years later, open source is as important as ever by Sarah Novotny
11:50am  Google’s approach to distributed systems observability by Jaana B. Dogan
2:35pm    gRPC versus REST: Let the battle begin with Alex Borysov
5:05pm    Shenzhen Go: A visual Go environment for everybody, even professionals by Josh Deprez

We look forward to seeing you and the rest of the community there!

By Josh Simmons, Google Open Source