Category Archives: Open Source Blog

News about Google’s open source projects and programs

The 2021 Season of Docs application for organizations is open!

Season of docs icon

Google Open Source is delighted to announce Season of Docs 2021!

The 2019 Season of Docs brought together open source organizations and technical writers to create 44 successful documentation projects. In 2020, we had 64 successful standard-length technical writing projects and are still awaiting long-running project results.

In 2021, the Season of Docs program will continue to support better documentation in open source and provide opportunities for skilled technical writers to gain open source experience. In addition, building on what we’ve learned from the successful 2019 and 2020 projects, we’re expanding our focus to include learning about effective metrics for evaluating open source documentation.

What are the 2021 program changes?

Season of Docs 2021 will allow open source organizations to apply for a grant based on their documentation needs. If selected, open source organizations will use their grant to hire a technical writer directly to complete their documentation project. Organizations will have up to six months to complete their documentation project. Keep reading for more information about the organization application or visit the Season of Docs site.

Technical writers interested in working with accepted open source organizations will be able to share their contact information via the Season of Docs GitHub repository; or they may submit proposals directly to the organizations and will not need to submit a formal application through Season of Docs.

Participating organizations will help broaden our understanding of effective documentation practices and metrics in open source by submitting a final case study upon completion of the program. The project case study will outline the problem the documentation project was intended to solve, what metrics were used to judge the effectiveness of the documentation, and what the organization learned for the future. All the project case studies will be published on the Season of Docs site at the end of the program.

How does it work?

February 9 - March 26 Open source organizations apply to take part in Season of Docs
April 16 Google publishes the list of accepted organizations, along with their project proposals and doc development can begin.
June 16 Organization administrators begin to submit monthly evaluations to report on the status of their project.
November 30 Organization administrators submit their case study and final project evaluation.
December 14 Google publishes the 2021 case studies and aggregate project data.
May 2, 2022 Organizations begin to participate in post-program followup surveys.

See the timeline for details.

Organization applications

Organization applications are now open! The deadline to apply is March 26, 2021 at 18:00 UTC.

To apply, first read the guidelines for creating an organization application on the Season of Docs website.

Take a look at the examples of project ideas, then create a project proposal based on your open source project’s actual documentation needs. Your goal is to attract technical writers to your organization, making them feel comfortable about approaching the organization and excited about what they can achieve.

Organizations can submit their applications here: http://goo.gle/3qVxArQ. Organization applications close on March 26th at 18:00 UTC.

Technical writers interested in participating in the 2021 Season of Docs should read our guide for technical writers on the Season of Docs website.

If you have any questions about the program, please email us at [email protected].

Join us

Explore the Season of Docs website at g.co/seasonofdocs to learn more about participating in the program. Use our logo and other promotional resources to spread the word. Check out the timeline and FAQ, and get ready to apply!

By Kassandra Dhillon and Erin McKean, Google Open Source Programs Office

Google joins the Rust Foundation

Droidstacean: Rust mascot Ferris, with Android mascot color/aspects
Droidstacean by Ivan Lozano, based on a design by Karen Rustad Tölva.
Rust is a systems programming language that combines low-level control over performance with modern language features and a focus on memory safety. Memory safety has been an enduring challenge for software developers, particularly those working on systems programs. Google has begun using Rust in settings where memory safety and performance are key considerations, including in key Android systems.

The Rust Core Team recently completed its work to build a new home for Rust: The Rust Foundation. Building on Google’s longstanding investments in C/C++ and the compilers and toolchains, we are delighted to announce our membership in the Rust Foundation. We look forward to participating more in the Rust community, in particular working across the industry on key issues including interoperability with C++, coordinating security reviews and decreasing the costs of crate updates, and continuing to grow our investments in existing Rust projects.

Memory safety security defects frequently threaten device safety, especially for applications and operating systems. For example, on Android, we’ve found that more than half of the security vulnerabilities we addressed in 2019 resulted from memory safety bugs. And this is despite significant efforts from Google and other contributors to the Android Open Source Project to either invest in or invent a variety of technologies, including AddressSanitizer, improved memory allocators, and numerous fuzzers and other code checking tools. Rust has proven effective at providing an additional layer of protection beyond even these tools in many other settings, including browsers, games, and even key libraries. We are excited to expand both our usage of Rust at Google and our contributions to the Rust Foundation and Rust ecosystem.

Today, some examples of projects where Google is either already using Rust or contributing to the Rust ecosystem include:
  • Operating system modules in Android, including bluetooth and Keystore 2.0
  • Low-level projects, such as the crosvm virtual machine monitor and drivers (alternative to QEMU) used in ChromeOS
  • Contributing to open source projects that we use and use Rust, such as the Mercurial source code control system
  • Firmware for FIDO security key support
And, there are many additional projects that are evaluating the use of Rust for new libraries or products. Some examples include:
We are also excited to support key Rust projects and their maintainers, such as:
  • Adding Rust code to curl
  • Working with ISRG to add a Rust TLS module to the Apache HTTP Server Project
We can’t wait to work across the industry to contribute to and support existing projects and libraries as well as help build out key areas such as C++ interoperability and security review.

By Lars Bergstrom, Director of Engineering, Android Platform Programming Languages

Writing fuzz tests with ease using Bazel

We are announcing Bazel support for developing and testing fuzz tests, with OSS-Fuzz integration, through the new rules_fuzzing Bazel library.

Fuzzing is an effective, well-known testing technique for finding security and stability bugs in software. But writing and testing fuzz tests can be tedious. Developers typically need to:
  • Implement a fuzz driver function, which exercises the API under test;
  • Build the code with the proper instrumentation (such as Address Sanitizer);
  • Link it with one of the available fuzzing engine libraries (libFuzzer, AFL++, Honggfuzz, etc.) that provide the core test generation logic;
  • Run the fuzz test binary with the right set of flags (e.g., to specify corpora or dictionaries);
  • Package the fuzz test and its resources for consumption by fuzzing infrastructures, such as OSS-Fuzz.
Unfortunately, build systems don't traditionally offer any support beyond the core primitives of producing executables, so projects adopting fuzzing often end up reimplementing fuzz test recipes.

Bazel is a versatile and extensible build system, focused on scalable, reliable, and reproducible builds. Originally designed to scale to Google's entire monolithic repository, it now underpins large enterprises and key open source Internet infrastructure projects.

We are pleased to announce that projects using Bazel can get advanced fuzzing support through the new rules_fuzzing extension library. The new fuzzing rules take care of all the boilerplate needed to build and run fuzz tests. Developers simply write the fuzz driver code and define a build target for it (example driver and target for RE2). Fuzz tests can be built and run using a number of fuzzing engines provided out-of-the-box, such as libFuzzer and Honggfuzz, as well as sanitizers. The rule library also provides the ability to define additional fuzzing engines.

You can integrate the fuzzing library with around 10 LOC in your Bazel WORKSPACE file. Defining a fuzz test in Bazel is as easy as writing the following in your BUILD file:

load("@rules_fuzzing//fuzzing:cc_deps.bzl, "cc_fuzz_test")
cc_fuzz_test(
   name = "my_fuzz_test",
   srcs = ["my_fuzz_test.cc"],
   deps = [":my_library"],
)

You can easily test the fuzzer locally by invoking its launcher:

$ bazel run --config=asan-libfuzzer //:my_fuzz_test_run

To improve the effectiveness of test case generation, fuzz tests also support seed corpora and dictionaries, through additional rule attributes. They will automatically be validated and included in fuzz test runs. Fuzz tests also serve as regression tests on the seed corpus. For example, you can add previously found and fixed crashes to the corpus and have them tested in your CI workflows:

$ bazel test --config=asan-replay //:my_fuzz_test

The fuzzing rules provide built-in support for OSS-Fuzz, our continuous fuzzing service for open source projects. The OSS-Fuzz support drastically simplifies writing the build scripts in project integration by automatically packaging the fuzz test and its dependencies using the expected OSS-Fuzz structure.

The Envoy Proxy project is one of the early adopters of the fuzzing rules library. As a large, mature C++ codebase, Envoy has maintained its own custom implementation of fuzzing support for its over 50 fuzz targets written so far. By switching to the new Bazel fuzzing rules, Envoy's fuzz targets automatically gained new features, such as local running and testing tools and support for multiple fuzzing engines. At the same time, Envoy simplified its OSS-Fuzz integration scripts. Moreover, it will automatically gain future functionality (e.g., more effective fuzzing engines, better coverage tracking, improved corpus management) as the Bazel fuzzing rules library evolves.

The Bazel rules for fuzzing draw from Google's experience providing effective fuzzing tools to our internal developers. We hope the new Bazel support for fuzzing will lower the barrier to fuzzing adoption in open source communities, further increasing the security and reliability of many projects. To learn more about integrating the fuzzing rules into your project, take a look at the Getting Started section in the documentation.

By Stefan Bucur, Software Analysis, Asra Ali, Envoy, and Abhishek Arya, OSS-Fuzz – Google

Launching OSV – Better vulnerability triage for open source

Open Source Vulnerabilities logo


We are excited to launch OSV (Open Source Vulnerabilities), our first step towards improving vulnerability triage for developers and consumers of open source software. The goal of OSV is to provide precise data on where a vulnerability was introduced and where it got fixed, thereby helping consumers of open source software accurately identify if they are impacted and then make security fixes as quickly as possible. We have started OSV with a data set of fuzzing vulnerabilities found by the OSS-Fuzz service. OSV project evolved from our recent efforts to improve vulnerability management in open source ("Know, Prevent, Fix" framework).

Vulnerability management can be painful for both consumers and maintainers of open source software, with tedious manual work involved in many cases.

For consumers of open source software, it is often difficult to map a vulnerability such as a Common Vulnerabilities and Exposures (CVE) entry to the package versions they are using. This comes from the fact that versioning schemes in existing vulnerability standards (such as Common Platform Enumeration (CPE)) do not map well with the actual open source versioning schemes, which are typically versions/tags and commit hashes. The result is missed vulnerabilities that affect downstream consumers.

Similarly, it is time consuming for maintainers to determine an accurate list of affected versions or commits across all their branches for downstream consumers after a vulnerability is fixed, in addition to the process required for publication. Unfortunately, many open source projects, including ones that are critical to modern infrastructure, are under resourced and overworked. Maintainers don't always have the bandwidth to create and publish thorough, accurate information about their vulnerabilities even if they want to.

These challenges result in open source consumers not incorporating important security fixes promptly. OSV aims to:
  1. Reduce the work required by maintainers to publish vulnerabilities, and
  2. Improve the accuracy of vulnerability queries for downstream consumers by providing precise vulnerability metadata in an easy-to-query database (complementing existing vulnerability databases).

Automation

OSV aims to simplify the vulnerability reporting process for an open source package maintainer by accurately determining the list of affected versions and commits. This requires providing both the commits that introduce and fix the bugs. If that information is not available, OSV requires providing a reproduction test case and steps to generate an application build, and then it performs bisection to find these commits in an automated fashion. OSV takes care of the rest of the analysis to figure out impacted commit ranges (accounting for cherry picks) and versions/tags.

How OSV works


OSV automates the triage workflow for an open source package consumer by providing an API to query for vulnerabilities. A typical OSV workflow for a package consumer looks like the picture above:
  1. A package consumer sends a query to OSV with a package version or commit hash as input.
    curl -X POST -d \
    '{"commit": "6879efc2c1596d11a6a6ad296f80063b558d5e0f"}' \
    'https://api.osv.dev/v1/query?key=$API_KEY'

     curl -X POST -d \
      '{"version": "1.0.0", "package": {"name": "pkg", "ecosystem": "pypi"}' \
      'https://api.osv.dev/v1/query?key=$API_KEY'
  1. OSV looks up the set of vulnerabilities affecting that particular version and returns a list of vulnerabilities impacting the package. The vulnerability metadata is returned in a machine-readable JSON format.
  2. The package consumer uses this information to either cherry-pick security fixes (based on precise fix metadata) or update to a later version.

Ongoing work

OSV currently provides access to thousands of vulnerabilities from 380+ critical OSS projects integrated with OSS-Fuzz. We are planning to work with open source communities to extend with data from various language ecosystems (e.g. NPM, PyPI) and work out a pipeline for package maintainers to submit vulnerabilities with minimal work.

Our goal with OSV is to rethink and promote better, scalable vulnerability tracking for open source. In an ideal world, vulnerability management should be done closer to the actual open source development process, aided by automated infrastructure. Projects that depend on open source should be promptly notified and fixes uptaken quickly when a vulnerability is reported.

You can access the OSV website and documentation at https://osv.dev. You can explore the open source repo or contribute to the project on GitHub, and join the mailing list to stay up to date with OSV and share your thoughts on vulnerability tracking. 

By Oliver Chang and Kim Lewandowski, Google Security Team

Know, Prevent, Fix: A framework for shifting the discussion around vulnerabilities in open source

Executive Summary:
The security of open source software has rightfully garnered the industry’s attention, but solutions require consensus about the challenges and cooperation in the execution. The problem is complex and there are many facets to cover: supply chain, dependency management, identity, and build pipelines. Solutions come faster when the problem is well-framed; we propose a framework (“Know, Prevent, Fix”) for how the industry can think about vulnerabilities in open source and concrete areas to address first, including:
  • Consensus on metadata and identity standards: We need consensus on fundamentals to tackle these complex problems as an industry. Agreements on metadata details and identities will enable automation, reduce the effort required to update software, and minimize the impact of vulnerabilities.
  • Increased transparency and review for critical software: For software that is critical to security, we need to agree on development processes that ensure sufficient review, avoid unilateral changes, and transparently lead to well-defined, verifiable official versions.
The following framework and goals are proposed with the intention of sparking industry-wide discussion and progress on the security of open source software.


Due to recent events, the software world gained a deeper understanding about the real risk of supply-chain attacks. Open source software should be less risky on the security front, as all of the code and dependencies are in the open and available for inspection and verification. And while that is generally true, it assumes people are actually looking. With so many dependencies, it is impractical to monitor them all, and many open source packages are not well maintained.

It is common for a program to depend, directly or indirectly, on thousands of packages and libraries. For example, Kubernetes now depends on about 1,000 packages. Open source likely makes more use of dependencies than closed source, and from a wider range of suppliers; the number of distinct entities that need to be trusted can be very high. This makes it extremely difficult to understand how open source is used in products and what vulnerabilities might be relevant. There is also no assurance that what is built matches the source code.

Taking a step back, although supply-chain attacks are a risk, the vast majority of vulnerabilities are mundane and unintentional—honest errors made by well-intentioned developers. Furthermore, bad actors are more likely to exploit known vulnerabilities than to find their own: it’s just easier. As such, we must focus on making fundamental changes to address the majority of vulnerabilities, as doing so will move the entire industry far along in addressing the complex cases as well, including supply-chain attacks.

Few organizations can verify all of the packages they use, let alone all of the updates to those packages. In the current landscape, tracking these packages takes a non-trivial amount of infrastructure, and significant manual effort. At Google, we have those resources and go to extraordinary lengths to manage the open source packages we use—including keeping a private repo of all open source packages we use internally—and it is still challenging to track all of the updates. The sheer flow of updates is daunting. A core part of any solution will be more automation, and this will be a key theme for our open source security work in 2021 and beyond.

Because this is a complex problem that needs industry cooperation, our purpose here is to focus the conversation around concrete goals. Google co-founded the OpenSSF to be a focal point for this collaboration, but to make progress, we need participation across the industry, and agreement on what the problems are and how we might address them. To get the discussion started, we present one way to frame this problem, and a set of concrete goals that we hope will accelerate industry-wide solutions.

We suggest framing the challenge as three largely independent problem areas, each with concrete objectives:
  1. Know about the vulnerabilities in your software
  2. Prevent the addition of new vulnerabilities, and
  3. Fix or remove vulnerabilities.
A related but separate problem, which is critical to securing the supply chain, is improving the security of the development process. We’ve outlined the challenges of this problem and proposed goals in the fourth section, Prevention for Critical Software.

Know your Vulnerabilities

Knowing your vulnerabilities is harder than expected for many reasons. Although there are mechanisms for reporting vulnerabilities, it is hard to know if they actually affect the specific versions of software you are using.

Goal: Precise Vulnerability Data
First, it is crucial to capture precise vulnerability metadata from all available data sources. For example, knowing which version introduced a vulnerability helps determine if one's software is affected, and knowing when it was fixed results in accurate and timely patching (and a reduced window for potential exploitation). Ideally, this triaging workflow should be automated.

Second, most vulnerabilities are in your dependencies, rather than the code you write or control directly. Thus, even when your code is not changing, there can be a constant churn in your vulnerabilities: some get fixed and others get added.1

Goal: Standard Schema for Vulnerability Databases
Infrastructure and industry standards are needed to track and maintain open source vulnerabilities, understand their consequences, and manage their mitigations. A standard vulnerability schema would allow common tools to work across multiple vulnerability databases and simplify the task of tracking, especially when vulnerabilities touch multiple languages or subsystems.

Goal: Accurate Tracking of Dependencies
Better tooling is needed to understand quickly what software is affected by a newly discovered vulnerability, a problem made harder by the scale and dynamic nature of large dependency trees. Current practices also often make it difficult to predict exactly what versions are used without actually doing an installation, as the software for version resolution is only available through the installer.

Prevent New Vulnerabilities

It would be ideal to prevent vulnerabilities from ever being created, and although testing and analysis tools can help, prevention will always be a hard problem. Here we focus on two specific aspects:
  • Understanding risks when deciding on a new dependency
  • Improving development processes for security-critical software
Goal: Understand the Risks for New Dependencies
The first category is essentially knowing about vulnerabilities at the time you decide to use a package. Taking on a new dependency has inherent risk and it needs to be an informed decision. Once you have a dependency, it generally becomes harder to remove over time. Knowing about vulnerabilities is a great start, but there is more that we can do. Continue reading →

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

The Future of Tilt Brush

Tilt Brush by Google

Open Sourcing Tilt Brush

Tilt Brush, Google's virtual reality painting application, has collaborated with amazing creators over the years, many of whom were part of our Artist in Residence Program. We have tremendous pride for all those collaborations, and the best part has been watching our community learn from each other and develop their abilities over the years.

As we continue to build helpful and immersive AR experiences, we want to continue supporting the artists using Tilt Brush by putting it in your hands. This means open sourcing Tilt Brush, allowing everyone to learn how we built the project, and encouraging them to take it in directions that are near and dear to them.

Tilt Brush launched on the SteamVR platform for the HTC Vive VR headset in April 2016. It went on to help users create their artwork on every major VR platform, including the Oculus Rift, Windows Mixed Reality, Valve Index, PlayStation VR, and Oculus Quest VR headsets. Tilt Brush won dozens of awards, including the Unity Awards 2015: Best VR Experience, the Cannes Lions 2017 Gold Lion in Innovation, and the Oculus Quest award for Best of 2019: VR Creativity Tool of the Year, and was often featured on The Tonight Show Starring Jimmy Fallon. As we look back on Tilt Brush, we’re proud of what this creative application has achieved, and excited for where the community will take it.
Tilt Brush by Google

What’s Included

The open source archive of the Tilt Brush code can be found at: https://github.com/googlevr/tilt-brush

Please note that it is not an actively developed product, and no pull requests will be accepted. You can use, distribute, and modify the Tilt Brush code in accordance with the Apache 2.0 License under which it is released.

In order to be able to release the Tilt Brush code as open source, there were a few things we had to change or remove due to licensing restrictions. In almost all cases, we documented the process for adding those features back in our comprehensive build guide. ‘Out of the box’, the code in the archive will compile a working version of Tilt Brush, requiring you only to add the SteamVR Unity SDK.

The currently published version of Tilt Brush will always remain available in digital stores for users with supported VR headsets. If you're interested in creating your own Tilt Brush experience, please review the build guide and visit our github repo to access the source code.

Cheers, and happy painting from the Tilt Brush team!

By Tim Aidley, Software Engineer, and Jon Corralejo, Program Manager – Tilt Brush