Announcing a new kind of open source organization

Google has deep roots in open source. We're proud of our 20 years of contributions and community collaboration. The scale and tenure of Google’s open source participation has taught us what works well, what doesn’t, and where the corner cases are that challenge projects.

One of the places we’ve historically seen projects stumble is in managing their trademarks—their project’s name and logo. How project trademarks are used is different from how their code is used, as trademarks are a method of quality assurance. This includes the assurance that the code in question has an open source license. When trademarks are properly managed, project maintainers can define their identity, provide assurances to downstream users of the quality of their offering, and give others in the community certainty about the free and fair use of the brand.

In collaboration with academic leaders, independent contributors, and SADA Systems, today we are announcing the Open Usage Commons, an organization focused on extending the philosophy and definition of open source to project trademarks. The mission of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing. Creating a neutral, independent ownership for these trademarks gives contributors and consumers peace of mind regarding their use of project names in a fair and transparent way.

Understanding and managing trademarks is critical for the long-term sustainability of projects, particularly with the increasing number of enterprise products based on open source. Trademarks sit at the juncture of the rule of law and the philosophy of open source, a complicated space; for this reason, we consider it to be the next challenge for open source, one we want to help with.

To get the Open Usage Commons started, Google has contributed initial funding, and the trademarks of Angular, a web application framework for mobile and desktop; Gerrit, web-based team code-collaboration tool; and Istio, an open platform to connect, manage, and secure microservices, will be joining the Open Usage Commons. If you use a trademark of one of the projects currently, you can continue to use those marks, following any current guidance from the project. As the Open Usage Commons is focused on trademark management, the contributor communities and technical roadmaps of these projects are not changed by joining the Commons, although we hope this new model encourages anyone who has stood on the sidelines until now to participate in these projects.

As the Open Usage Commons board wrote in their announcement, this is uncharted territory, and the Commons intends to “walk before they run,” so you can expect more information and activity from the organization in the coming months.

Learn more about the role of trademarks in open source and the Open Usage Commons at openusage.org.

By Chris DiBona, Director, Open Source at Google

Expanding our Differential Privacy Library

All developers have a responsibility to treat data with care and respect. Differential privacy helps organizations derive insights from data while simultaneously ensuring that those results do not allow any individual's data to be distinguished or re-identified. This principled approach supports data computation and analysis across many of Google’s core products and features.

Last summer, Google open sourced our foundational differential privacy library so developers and organizations around the world can benefit from this technology. Today, we’re announcing the addition of Go and Java to our library, an end-to-end solution for differential privacy: Privacy on Beam, and new tools to help developers implement this technology effectively.

We’ve listened to feedback from our developer community and, as of today, developers can now perform differentially private analysis in Java and Go. We’re working to bring these two libraries to full feature parity with C++.

We want all developers to have access to differential privacy, regardless of their level of expertise. Our new Privacy on Beam framework captures years of Googler developer experience and efficiency improvements in a comprehensive and easy-to-use solution that handles computation end-to-end. Built on Apache Beam, Privacy on Beam can reduce implementation mistakes, and take care of all the steps that are essential to differential privacy, including noise addition, partition selection, and contribution bounding. If you’re new to Apache Beam or differential privacy, our codelab can get you started.

Tracking privacy budgets is another challenge developers face when implementing differential privacy. So, we’re also releasing a new Privacy Loss Distribution tool for tracking privacy budgets. With this tool, developers can maintain an accurate estimate of the total cost to user privacy for collections of differentially private queries, and better evaluate the overall impact of their pipelines. Privacy Loss Distribution supports widely used mechanisms (such as Laplace, Gaussian, and Randomized response) and can scale to hundreds of compositions.

We hope these new languages, tools, and features unlock differential privacy for even more developers. Continue to share your stories and suggestions with us at dp-open-source@google.com—your feedback will help inform our future differential privacy launches and updates.

Acknowledgements

Software Engineers: Yurii Sushko, Daniel Simmons-Marengo, Christoph Dibak, Damien Desfontaines, Maria Telyatnikova, Dennis Kraft, Jimmy Ross, Vadym Doroshenko
Research Scientists: Pasin Manurangsi, Ravi Kumar, Sergei Vassilvitskii, Alex Kulesza, Jenny Gillenwater, Kareem Amin

By: Miguel Guevara, Mirac Vuslat Basaran, Sasha Kulankhina, and Badih Ghazi – Google Privacy Team and Google Research

Welcoming 1,000+ Interns to Open Source at Google

One of the core tenets of open source is about finding ways for people to build great things by working together, regardless of location. This summer, through our intern program we’re gathering incredible talent from schools around the world, Googlers with a passion for open source, and project maintainers both inside and outside of Google to see what we can build together. 

Onboarding that many interns and turning them into new open source contributors was no easy task. So in partnership with the Intern Programs team and engineering teams across Google, we’ve grounded our planning by answering four key questions. 

How can we make our internship program a force for good in the open source ecosystem?

We knew that having more than a thousand interns contribute to open source projects could have a huge impact, however, many projects aren’t set up to onboard dozens of new contributors at one time and many maintainers can’t take on hundreds of new pull requests. Early on, we established best practices for intern placement and support. We committed to:

• Aligning interns’ work with project priorities to advance the project while also allowing the interns to learn and grow their skills.
• Proactively communicating with project maintainers and contributors, keeping them in the loop on timelines and logistics.
• Looking beyond Google. While we prioritized projects that have full-time Google engineerings support. That includes Google-owned projects like Go, TensorFlow, and Chromium, as well as Google-created projects we invest heavily in, such as Kubernetes, Apache Beam, and Tekton. But Google also has full-time engineers working on outside projects we rely on, so our interns will also be working on projects like Envoy, Rust, and Apache Maven.

How can we introduce the interns to open source at Google?

We are determined to support and empower the interns as they become lifelong contributors to open source. Every Noogler in engineering learns about using and contributing to open source in a training run by our Open Source Programs Office. With an unprecedented number of interns working on open source projects, we are also providing additional resources; from offering a platform for questions, office hours, enrichment talks, and partnerships with external open source organizations.

How can we learn from our interns about the experience of contributing to open source at Google and beyond?

We see a huge opportunity to listen to our interns this summer. By meeting with interns and hosts—as well as surveying the entire class of interns at the end of the summer—we can look for ways to improve open source at Google and the contributor experience for projects they’re working on. We’re excited to learn from the internship program and from interns’ perspectives working in and contributing to open source.

How can we have an impact on these students that carries on throughout their careers?

One of my favorite questions to ask Googlers who are active in open source is how they were first introduced to open source. There’s a well-trodden path of a developer fixing an annoying bug, then a few more bugs, then adding small features, becoming a core contributor, and eventually a project maintainer. That process requires persistence and patience, and projects lose a lot of great developers along the way.

But... What if your first experience with open source is being welcomed into a large and thriving community of contributors? What if you get to contribute to open source full time, mentored by creators and maintainers of the project you’re working on, collaborating across organizations and across time zones? Our hope is that this kind of experience will leave a lasting impression on this summer’s interns and that they’ll continue to contribute to open source for a long time to come.

By Jen Phillips, Google Open Source