Google Cardboard XR Plugin for Unity

Late in 2019, we decided to open source Google Cardboard. Since then, our developer community has had access to create a plethora of experiences on both iOS and Android platforms, while reaching millions of users around the world. While this release has been considered a success by our developer community, we also promised that we would release a plugin for Unity. Our users have long preferred developing Cardboard experiences in Unity, so we made it a priority to develop a Unity SDK. Today, we have fulfilled that promise, and the Google Cardboard open source plugin for Unity is now available via the Unity Asset Store. 

What's Included in the Cardboard Unity SDK

Today, we’re releasing the Cardboard Unity SDK to our users so that they can continue creating smartphone XR experiences using Unity. Unity is one of the most popular 3D and XR development platforms in the world, and our release of this SDK will give our content creators a smoother workflow with Unity when developing for Cardboard.

In addition to the Unity SDK, we are also providing a sample application for iOS/Android, which will be a great aid for developers trying to debug their own creations. This release not only fulfills a promise we made to our Cardboard community, but also shows our support, as we move away from smartphone VR and leave it in the more-than-capable hands of our development community.



If you’re interested in learning how to develop with the Cardboard open source project, please see our developer documentation or visit the Google VR GitHub repo to access source code, build the project, and download the latest release.

By Jonathan Goodlow, Product Manager, AR & VR

Knative elects new Technical Oversight Committee members

Towards the end of 2019, Knative project initiated a series of changes to its governance to ensure sustainability in the long term. Over the last week, the project reached a new milestone by successfully wrapping up its first Technical Oversight Committee (TOC) elections, bringing more vendor diversity to the technical stewardship of Knative.

Google has grown thousands of open source projects throughout the years, and it is this collective knowledge that informed the changes proposed to Knative governance. Over the last six months, we worked together with the other members of the Knative Steering Committee, and with the project’s contributors to create a clear set of rules for technical leadership and governance, describing the many ways in which contributors could engage with the project. This process was key to developing trust with Knative’s community, the project’s most valued stakeholder. In the exercise of this vote, the community was able to test the new election process, which proved to be solid: it will be repeated annually for this project, and can serve as a model for other projects as well.

The TOC election, which had a turnout of 70% of active contributors to the project, yielded a new technical stewardship for Knative, with members representing RedHat, VMWare and Google, as follows:

Nghia Tran (Google) - new member
Markus Thömmes (Red Hat) - new member
Grant Rodgers (Google) - new member
Matt Moore (VMWare) - existing member
Evan Anderson (VMWare) - existing member

Members of Knative TOC not only have the technical stewardship of the project in their hands for the next two years, they also model the community’s values: they have strong technical skills, they contribute to the project, and they are collegial, mentoring other contributors and helping the project to grow in a sustainable and healthy way.

We celebrated this important milestone for Knative at the last community meetup. Watch the video to meet the new TOC members, and check out the contribution guidelines to join the project.

By María Cruz, Google Open Source

SoD: experiences and tips for participation

Have you ever heard about a program that lets technical writers contribute to open source documentation? Towards this effort, Google launched its pilot program for Season of Docs (SoD) around April 2019. SoD immediately caught my attention because it is the first-ever program that seamlessly brings tech writing to the open source world. By carefully selecting open source organizations and their projects, SoD allows seasoned or aspiring technical writers around the world to work closely with an open source organization, and understand their open source product, processes, and tools.

Luckily, I discovered SoD 2019, submitted my application—and after being selected to work for Tor—started my journey into the world of open source. I successfully completed my project in March 2020, and my project report was called out on the Results page for SoD 2019 that lists all successful contributions.

Now in its second year, SoD has gained momentum and is the talk of most technical writing communities and student circles. For the benefit of SoD aspirants, I am recounting my participation experiences along with useful tips in this blog post. I have included answers to questions that I am frequently asked, along with some simple tips to help you successfully complete your project.

• Firstly, all aspiring participants for SoD 2020 must go through the program and its timeline hosted on the Season of Docs website. Make sure you read the Technical writer guide to understand the different phases of the program.
• It’s a common myth that only seasoned technical writers who have coding knowledge are at fit for this program as SoD 2019 saw a lot of students participating in the program. Experienced technical writers or even students, who can show their interest in tech documentation are free to participate. From the highly to moderately technical projects available, you can opt for a project depending on your expertise and knowledge.
• During the application phase, try to shortlist organizations closest to your domain knowledge and work area, and submit project proposals for two or three organizations. This increases your chance of being accepted by an organization. I shortlisted Tor and Hydra because of my interest in anonymous communications and my experience of working with APIs.
• Before submitting your proposal, it’s a good idea to establish interaction with the org mentors to understand if you’re going in the right direction with your project proposal and most importantly to break the ice for future communications. I found some interesting project ideas and reached out to the mentors to understand their expectations of the project before submitting my application. In hindsight, this proved to be extremely valuable, as I was able to fine-tune my proposal in collaboration with my mentor, and I had already built a rapport with them.
• Build your project proposal based on whether you’re opting for a three- or a five-month program. Break down details by months and weeks, which will testify your commitment to the project. I had chosen a standard three-month long project and detailed my work by months. When scoping your project, always allow time for roadblocks and unforeseen situations.
• After your proposal is selected by an organization, it’s community-bonding time. Take this phase seriously and use this time to get to know your peers in the organization, build a rapport with your mentors, set up a communication channel with them, and prepare your work environment. My project proposal for Tor was accepted, and my mentors reached out to me to quickly get me up-to-speed with their communication tools, meeting timings, and smoothly inducted me into the networking team that I was going to work with. Even before I started working on the project, I was attending their weekly meetings and learning more about the work they do.
• During the doc development phase, try to accomplish everything you promised in your proposal. At the same time, don’t feel bogged down by any changes that arise due to the complexity of your proposal. I faced hiccups during this phase because some of my ideas were not possible to implement and I had to rescope my proposal. Thanks to the invaluable support from my mentors and my peers at Tor, I was able to overcome all the obstacles and move forward with my project. The key to overcoming hurdles during your project is to keep your mentors updated about your work with frequent communication.
• Once the work’s done complete your project report which will serve as the final assessment. Ensure that this report clearly shows all the work you’ve done; nothing is too big or too small to highlight in this report. A well-written report is more important than your project proposal as this decides whether your project has been successful. Based on this report, your mentor gives you a pass or fail mark for your project.
• If your project is successful, you receive a stipend at the end of the program if you opted for one. Choosing to opt out of the stipend does not increase your chances of being selected to the program. This depends solely on your project proposal and your efforts at bonding with the chosen communities before applying.

For any more questions or concerns that you may have at any point in the program, I’d suggest looking up the FAQ for technical writers. You can also give a shout out to the extremely helpful program admins at season-of-docs-support@googlegroups.com.

I hope I have inspired SoD 2020 applicants to make their participation successful. I wish each one the very best.

By Swati Thacker, guest writer from Oracle