Tag Archives: Open source

Announcing First Group of Google Open Source Peer Bonus Winners in 2022

After receiving over 200 nominations from Googlers, we are very pleased to announce our biggest group of winners to date for the Google Open Source Peer Bonus Program.

We are honored to present 154 contributors from 29 countries with peer bonuses, representing more than 80 open source projects.

The Google Open Source Peer Bonus program was launched in 2011, and over the years became a much loved initiative within open source. Many teams at Google rely on open source projects in their work and are very keen to support contributors who devote their time and energy to these projects. Here are some quotes from our winners about what the program means to them.

“Google's OSS Peer Bonus program recognizes the fantastic work done by people who volunteer their time tirelessly to contribute to open source projects. Society as a large benefits from having a strong community of contributors to open source software. I'm humbled to receive the OSPB award.” – Robert A. van Engelen, ugrep contributor

“It is a very motivating program, rewarding and acknowledging important work [for open source].” - Christoph Gorgulla, VirtualFlow contributor

“Open source is a great chance to work on worldwide use products with other developers. It was a pleasure and, hope I made Firebase a bit better. Thanks a lot!”
- Andrey Uryadov, Firebase iOS SDK contributor

“The Angular team is incredibly welcoming and supportive to open source contributors, the support and appreciation they give to any sort of contribution, no matter on size or relevance is really impressive and heartwarming. It is a pleasure and an honor to be able to interact with such wonderful people and of course awe-inspiring software engineers.” - Dario Piotrowicz, Angular contributor

Below is the list of winners who gave us permission to thank them publicly:

Project

Winner

altair

Christopher Davis

altair

Mattijn van Hoek

Android FHIR SDK

Aditya Kurkure

Android FHIR SDK

Ephraim Kigamba

AndroidX

Simon Schiller

AndroidX, Jetpack

Eli Hart

Angular

Dario Piotrowicz

Apache Airflow

Ash Berlin-Taylor

Apache Airflow

Kaxil Naik

Apache Beam

Alex Kosolapov

Apache Beam

Alex Van Boxel

Apache Beam

Austin Bennett

Apache Beam

Calvin Leung

Apache Beam

Chun Yang

Apache Beam

Matthias Baetens

Apache Beam, Hop

Matt Casters

Apache Cassandra

Dinesh Joshi

Apache Log4J

Ralph Goers

apache/pinot , evidentlyai/evidently

Nadcharin Silaphung

ASF Diversity and Inclusion Committee

Katia Rojas

Bazel

Brentley Jones

Bazel

Fabian Meumertzheim

bazel-zig-cc

Motiejus Jakštys

Buefy

Walter Tommasi

caps-rs

Luca Bruno

Chrome DevTools

Jesper van den Ende

Chrome OS

Álvaro Guzmán Parrochia

Chromium

Jinyoung Hur

Cirq

Victory Omole

conda-forge package maintenance

Mark Harfouche

ContainerSSH

Sanja Bonic

coreboot

Elyes Haouas

coreboot

Felix Held

coreboot

Felix Singer

coreboot

Matt DeVillier

COVID-19 scenario modeling hub

Matteo Chinazzi

Docsy

Andreas Deininger

Docsy

Franz Steininger

Docsy

Gareth Watts

Docsy

Patrice Chalin

DoIT

Eduardo Naufel Schettino

Eleventy

Zach Leatherman

Firebase iOS SDK

Artem Volkov

Firebase iOS SDK

Florian Schweizer

Firebase iOS SDK

Morten Bek Ditlevsen

Firebase iOS SDK

Akira Matsuda

Firebase iOS SDK

Andrey Uryadov

Firebase iOS SDK

Ashleigh Kaffenberger

Firebase iOS SDK

Kamil Powałowski

Firebase iOS SDK

Marina Gornostaeva

Firebase iOS SDK

Paul Harter

Firebase iOS SDK

Yakov Manshin

Flutter

Alex Li

Flutter

Xu Baolin

Flutter DevTools

Bruno Leroux

Fuchsia

Fabio D'Urso

Gentoo

Agostino Sarubbo

Gentoo

Toralf Förster

Go

Rhys Hiltner

Good Docs Project

Carrie Crowe

Halide

Alex Reinking

HTTP Archive

Barry Pollard

classgraph

Luke Hutchison

Istio

Rama Chavali

Jest mock library for Google Maps JavaScript

Eric Egli

jupyter_bbox_widget

Daria Vasyukova

karatelabs

Dinesh Arora

KDE Frameworks 6

Volker Krause

Knative

Dave Protasowski

Knative

Evan Anderson

Kubernetes

Adolfo García Veytia

Kubernetes

Rey Lejano

libsodium

Frank Denis

Linux, LLVM

Nathan Chancellor

LLVM

Sylvestre Ledru

LLVM

Zhiqian Xia

Mediawiki

Soham Parekh

mold

Rui Ueyama

Multiscale modeling of brain circuts

Salvador Dura Bernal

Open-JDK

Aleksey Shipilëv

OpenROAD

Matt Liberty

oreboot

Danny Milosavljevic

ostreedev/ostree

Colin Walters

p5.js

Lauren Lee McCarthy

PepTrans: SARS-CoV-2 Peptidic Drug Discovery

Ahmed Elnaggar

protoc-jar-maven-plugin

Oliver Suciu

PyBaMM

Priyanshu Agarwal

RDKit

Greg Landrum

regex-automata

Andrew Gallant

rgs1

Raul Gutierrez Segales

Robolectric

Junyi Wang

Ruby for Good

Gia Coelho

Ruby for Good

Sean Marcia

Sass

Christophe Coevoet

Screenity, Omni, Mapus, Flowy

Alyssa X

sigstore

Carlos Panato

SLF4j, Logback, reload4j Java Logging Frameworks

Ceki Gülcü

Smithay

Victor Berger

Sollya

Christoph Lauter

Sollya

Mioara Joldes

Sollya

Sylvain Chevillard

Spanish Open Source Distributed Systems Seminar

Ricardo Zavaleta

strict-csp and html-webpack-plugin

Jan Nicklas

Tekton Pipelines

Aiden De Loryn

Tekton Pipelines

Eugene McArdle

TFX

Gerard Casas Saez

TFX

Vincent Nguyen

The Good Docs Project

Chris Ganta

The Good Docs Project

Deanna Thompson

The Good Docs Project

Gayathri Krishnaswamy

The Good Docs Project

Nelson Guya

TL Draw

Steve Ruiz

Trust-DNS

Benjamin Fry

ugrep

Robert van Engelen

virtio-iommu

Jean-Philippe Brucker

VirtualFlow

Christoph Gorgulla

Vite, Vitest

Matias Capeletto

Vite, Vitest

Anthony Fu

Vue, Stylelint

Yosuke Ota

Vuls

Kota Kanbe

wails

Lea Anthony

WalkingPad controller

Dušan Klinec

Web Almanac

David Fox

WebRTC

Philipp Hancke

What we teach about race and gender: Representation in images and text of children books

Teodora Szasz

Zig

Andrew Kelley


Thank you for your contributions to open source! Congratulations!

By Maria Tabak – Google Open Source

Rewarding Rust contributors with Google Open Source Peer Bonuses

logo showing a trophy cup in the Google colors, with the text “Google Open Source Peer Bonus” below it
We are very excited to reward 25 open source contributors, specifically, for their work on Rust projects! 

At Google, Open Source lies at the core of not only our processes but also many of our products. While we try to directly contribute upstream as much as possible, the Google Open Source Peer Bonus program is designed to reward external open source contributors for their outstanding contributions to FOSS, whether the contribution benefits Google in some way or not.

The Rust programming language is an open source systems programming language with a strong focus on memory safety. The language has a caring community and a robust package ecosystem, which have heavily contributed to its growing popularity. The Rust community shows dedication to maintaining quality packages and tooling, which we at Google are quite thankful for.

Among many other things, Google uses Rust in some open source projects, including Android, Fuchsia, and ICU4X; and has been participating in the efforts to evaluate Rust in the Linux Kernel. Google is also a founding member of the Rust Foundation.

Below is the list of winners who gave us permission to thank them publicly:

Winner

Project

antoyo

For work on rustc_codegen_gcc

Asherah Connor

For maintaining comrak

David Hewitt

For maintaining PyO3

Dirkjan Ochtman

For maintaining rustls and quinn

Frank Denis

For maintaining rust-ed25519-compact

Gary Guo

For maintaining Rust for Linux

Jack Grigg

For integrating RustCrypto into Fuchsia

Jack Huey

For highly involved rust compiler work fixing a large number of crashes around higher-kinded types.

Joe Birr-Pixton

For building rustls

Joshua Nelson

For improving the developer workflow for contributing to Rust itself

Lokathor

For creating tinyvec and bytemuck

Mara Bos

For work on the Rust Libraries Team and the 2021 Rust Edition

Nikita Popov

For maintaining the Rust compiler’s LLVM backend

Pietro Albini

For maintaining crucial Rust infrastructure and working on the Rust core team

Ricky Hosfelt

For maintaining cargo-outdated

Sébastien Crozet

For creating dimforge

Simonas Kazlauskas

For maintaining the Rust compiler’s LLVM backend


Thank you for your contributions to the Rust projects and ecosystem! Congratulations!

By Maria Tabak, Google Open Source and Manish Goregaokar, Rustacean Googler

How to integrate your web app with Google Ads

TL;DR: You can now have a web application integrated with Google Ads in just a few minutes!

Google Ads
Google Ads is an online advertising platform where advertisers can create and manage their Google marketing campaigns. The Google Ads API is the modern programmatic interface to Google Ads and the next generation of the AdWords API. It enables developers to interact directly with the Google Ads platform, vastly increasing the efficiency of managing large or complex Google Ads accounts and campaigns.

A typical use case is when a company wants to offer Google ads natively on their platform to their users. For example, customers who have an online store with Shopify can promote their business using Google ads, with just a few clicks and without needing to go to the Google Ads platform. They’re able to do it directly on Shopify’s platform—the Google Ads API makes this possible.

Demo App
Francisco Blasco, Strategic Technical Solutions Manager at Google, designed and built an open source web application that is integrated with Google Ads and Business Profile (aka Google My Business).

Anyone can use the app, called Fran Ads, to save significant time on product development. Just follow the simple installation steps in the README files (frontend README file and backend README file) on the GitHub repo! The app uses React for the frontend, and Django for the backend; two of the most popular web frameworks.

App's Logo


Check out a product demo here! You can have this app running in your local machine in a few minutes. To learn how, check out the video tutorial.

Blasco acts as an external Product Manager for Google’s strategic partners, driving the entire product development lifecycle. He created this project to help Google’s partners and businesses seeking to offer Google Ads to their users.

The goal is to accelerate the Google Ads integration process and decrease associated development costs. Some companies are using Fran Ads to see what an integration looks like, while others are using the technical guide to learn how to start using the Google Ads API.

In general, companies can use Fran Ads as an SDK to begin working with elements within the Google Ads API, and serve as a guidance system for integrating with Google. This project will minimize the number of times the wheel needs to be reinvented, accelerating innovation and facilitating adoption. Developers can clone the code repositories, follow the steps, and have a web app integrated with Google Ads in just a few minutes. They can adapt and build on top of this project, or they can just use the functions they need for the features they want to develop



App Architecture

Furthermore, you will learn how to create credentials to consume Google APIs; specifically, the README files show how to create a project on Google Cloud Platform (GCP), and how to set it up correctly so a web app can consume Google Ads API and Business Profile APIs.

Also, you will learn how refresh tokens work for Google APIs, and how to manage them for your web application.

Francisco wrote a detailed technical guide explaining how to build every feature of the app. Some of the most important features are:
        1. Create a new Google Ads account
        2. Link an existing Google Ads account
        3. OAuth authentication & authorization
        4. Refresh token management
        5. List of Google Ads accounts associated with Google account
        6. Reporting on performance for all campaign types
        7. Create Smart Campaign (automated ads on Google and across the web)
        8. Edit Smart Campaign settings

As you can see from the list above, the app will create Smart Campaigns — a simplified, automated campaign designed for new advertisers and SMBs

Google made public the suggestion services through the Google Ads API. Fran Ads uses those services to recommend keyword themes, headlines & descriptions for the ad, and budget. These recommendations are specific for each advertiser, depending on several factors such as type of business, location, and keyword themes.



An example of three Google recommendations for an advertiser.


The image above shows the final step of creating a Smart Campaign on Fran Ads. In this step, users have to set a daily budget for the campaign. Not only will you receive recommendations for the budget, but an estimate of how many ad clicks you will get per month. This is a great feature for users who are new to digital marketing and aren’t aware of their spending needs.

You can also see an alert message that the budget can be changed anytime, so users can pause spending on the campaign. This is important because many new users, especially SMBs, have doubts about spending on something new. Therefore, it is important to communicate to them that the decision they are making at that moment is not set in stone.

When you start using Fran Ads, you will see there is guidance so users complete the tasks they want.


Guidance on how to complete tasks based on Google’s best practices.


Furthermore, the app is designed based on Google’s best practices. For example, when users are creating a Smart Campaign, in step three (see the above image) they need to select keyword themes (group of keywords). If you choose “bakery” as the keyword theme, your ad is eligible to show when people search for “bakery near me”, “local bakery”, and “cake shop”.

Google’s best practices suggest that advertisers use between seven and ten keyword themes per campaign. Therefore, Fran Ads is designed for users to select up to seven keyword themes. Refer to the image of step three when creating a Smart Campaign on Fran Ads. However, you can set it to ten if you like.

The technical guide also provides:

        1. Production-ready code for both the frontend and backend
        2. Engineering flow diagrams
        3. Best practices
        4. High-fidelity mockups
        5. App architecture and structure diagrams
        6. Workarounds to current bugs on Google Ads API v9
        7. Important information on how to handle important tasks necessary for integrating your platform with Google Ads
        8. Help with the design strategy for the UX and design elements of the UI.

Important resources

See below the list summarizing the important resources that will help you integrate with Google Ads easier, faster, and better.
        1. Frontend repo: all the code for the frontend of Fran Ads.
        2. Backend repo: all the code for the backend of Fran Ads.
        3. Technical guide: 3 sections: ‘Before Starting’, ‘Configurations & Installation’, and ‘Build web              app’. In section 3, you have explanations on how to build all the features of the app.
        4. Product demo: 15-minute demo of Fran Ads showing many core features.
        5. Video tutorial: 17-minute tutorial on how to set up and run Fran Ads.


By Francisco Blasco – Launch, Channel Partners

Google Summer of Code 2022 mentoring orgs revealed!


After reviewing over 350 mentoring organization applications, we are excited to announce that 203 open source projects have been selected for Google Summer of Code (GSoC) 2022. This year we are welcoming 32 new organizations to mentor GSoC contributors.

Visit our new program site to view the complete list of GSoC 2022 accepted mentoring organizations. You can drill down into the details for each organization on their program page, including reading more about the project ideas they are looking for GSoC contributors to work on this year.

Are you a developer new to open source interested in participating in GSoC?
If you are a new or beginner open source contributor over 18 years old, we welcome you to apply for GSoC 2022! Contributor applications will open on Monday, April 4, 2022 at 18:00 UTC with Tuesday, April 19, 2022 18:00 UTC being the deadline to submit your application (which includes your project proposal).

The most successful applications come from students who start preparing now. We can’t say this enough—if you want to significantly increase your chances of being selected as a 2022 GSoC Contributor, we recommend you to prepare early. Below are some tips for prospective contributors to accomplish before the application period begins in early April:

  • Watch our short videos: What is GSoC? and Being a GSoC Contributor
  • Check out the Contributor/ Student Guide and Advice for Applying to GSoC doc.
  • Review the list of accepted organizations and find two to four that interest you and read through their Project Ideas lists.
  • When you see an idea that piques your interest, reach out to the organization via their preferred communication methods (listed on their org page on the GSoC program site).
  • Talk with the mentors and community to determine if this project idea is something you would enjoy working on during the program. Find a project that motivates you, otherwise it may be a challenging summer for you and your mentor.
  • Use the information you received during your communications with the mentors and other org community members to write up your proposal.
You can find more information about the program on our website which includes a full timeline of important dates. We also highly recommend reading the FAQ and Program Rules and watching some of our other videos with more details about GSoC for contributors and mentors.

A hearty welcome—and thank you—to all of our mentor organizations! We look forward to working with all of you during Google Summer of Code 2022.

By Stephanie Taylor – Google Open Source

Google Summer of Code 2022 mentoring orgs revealed!


After reviewing over 350 mentoring organization applications, we are excited to announce that 203 open source projects have been selected for Google Summer of Code (GSoC) 2022. This year we are welcoming 32 new organizations to mentor GSoC contributors.

Visit our new program site to view the complete list of GSoC 2022 accepted mentoring organizations. You can drill down into the details for each organization on their program page, including reading more about the project ideas they are looking for GSoC contributors to work on this year.

Are you a developer new to open source interested in participating in GSoC?
If you are a new or beginner open source contributor over 18 years old, we welcome you to apply for GSoC 2022! Contributor applications will open on Monday, April 4, 2022 at 18:00 UTC with Tuesday, April 19, 2022 18:00 UTC being the deadline to submit your application (which includes your project proposal).

The most successful applications come from students who start preparing now. We can’t say this enough—if you want to significantly increase your chances of being selected as a 2022 GSoC Contributor, we recommend you to prepare early. Below are some tips for prospective contributors to accomplish before the application period begins in early April:

  • Watch our short videos: What is GSoC? and Being a GSoC Contributor
  • Check out the Contributor/ Student Guide and Advice for Applying to GSoC doc.
  • Review the list of accepted organizations and find two to four that interest you and read through their Project Ideas lists.
  • When you see an idea that piques your interest, reach out to the organization via their preferred communication methods (listed on their org page on the GSoC program site).
  • Talk with the mentors and community to determine if this project idea is something you would enjoy working on during the program. Find a project that motivates you, otherwise it may be a challenging summer for you and your mentor.
  • Use the information you received during your communications with the mentors and other org community members to write up your proposal.
You can find more information about the program on our website which includes a full timeline of important dates. We also highly recommend reading the FAQ and Program Rules and watching some of our other videos with more details about GSoC for contributors and mentors.

A hearty welcome—and thank you—to all of our mentor organizations! We look forward to working with all of you during Google Summer of Code 2022.

By Stephanie Taylor – Google Open Source

The 2022 Season of Docs application for organizations is open!

Organization applications for the 2022 Season of Docs are now open!

Through Season of Docs, Google awards grants to open source projects and organizations to hire technical writers to work on documentation projects. Participating organizations hire and pay the technical writers directly (we use Open Collective to help transfer grant funds). Organizations have up to six months to complete their documentation project. At the end of the program, organizations submit a case study outlining the results of their documentation projects, including the metrics they used to evaluate the success of their new or improved documentation. The case studies from the 2021 Season of Docs program are available online, and we will be releasing a summary report for the 2021 Season of Docs shortly—join our Season of Docs announcements list to be notified when it’s available! 

How does my organization apply to take part in Season of Docs?


Organization applications are now open! The deadline to apply is March 25, 2022 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.

We strongly recommend reading through the proposals and case studies submitted by organizations participating in the 2021 Season of Docs.

Organizations can submit their applications here: https://goo.gle/3dRyD7P. Organization applications close on March 25th at 18:00 UTC.

How do technical writers take part in Season of Docs?


Technical writers interested in working with accepted open source organizations can share their contact information via the Season of Docs GitHub repository; or they may submit proposals directly to the organizations using the contact information shared on the organization project page. Technical writers do not submit a formal application through Season of Docs.

Technical writers interested in participating in the 2022 Season of Docs should read our guide for technical writers on the Season of Docs website. Please note that technical writer recruiting began on February 3, 2022.

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

General timeline

February 23 - March 25

Open source organizations apply to take part in Season of Docs

April 14

Google publishes the list of accepted organizations, along with their project proposals and doc development can begin.

June 15

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 releases submitted case studies. 

May 2, 2023

Organizations begin to participate in post-program followup surveys.


See the timeline for details.

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 apply now!

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

A New Library for Network Optimization

Networks are all around us from the electrical circuits inside our computers to the multitude of internet servers that route packets of data around the globe. Even the web itself is a network of pages connected to each other by a myriad of blue links.

A network of rubber bands on a wooden pegboard


A network's structure is referred to as its topology. Network topologies can be physical or logical, centralized or decentralized, and fully or partially connected. Given a network with n nodes, the number of possible topologies grows exponentially with n; even just a dozen nodes admit nearly a trillion trillion possible configurations!

The network-opt logo


We are pleased to announce the open source release of network-opt, a C++ library that supports the optimization of network topologies. Using sophisticated techniques for combinatorial search, this algorithm can efficiently construct instances from a family of so-called series-parallel networks that commonly arise in electrical and telecommunications applications. For example, given 15 1-Ω resistors and a target resistance of π Ω, our tool can produce a circuit that achieves six digits of precision:

A 15-element circuit composed of 1-ohm resistors


For more details, refer to our paper: "Search Strategies for Topological Network Optimization," appearing this month at the Thirty-Sixth AAAI Conference on Artificial Intelligence (AAAI-22).


By Michael D. Moffitt, Core Enterprise Machine Learning

The Balloon Learning Environment

Benchmark challenges have been a driving force in the advancement of machine learning (ML). In particular, difficult benchmark environments for reinforcement learning (RL) have been crucial for the rapid progress of the field by challenging researchers to overcome increasingly difficult tasks. The Arcade Learning Environment, Mujoco, and others have been used to push the envelope in RL algorithms, representation learning, exploration, and more.

In “Autonomous Navigation of Stratospheric Balloons Using Reinforcement Learning”, published in Nature two years ago, we demonstrated how deep RL can be used to create a high-performing flight agent that can control stratospheric balloons in the real world. This research confirmed that deep RL can be successfully applied outside of simulated environments, and contributed practical knowledge for integrating RL algorithms with complex dynamical systems.

Today we are excited to announce the open-source release of the Balloon Learning Environment (BLE), a new benchmark emulating the real-world problem of controlling stratospheric balloons. The BLE is a high-fidelity simulator, which we hope will provide researchers with a valuable resource for deep RL research.

Station-Keeping Stratospheric Balloons
Stratospheric balloons are filled with a buoyant gas that allows them to float for weeks or months at a time in the stratosphere, about twice as high as a passenger plane’s cruising altitude. Though there are many potential variations of stratospheric balloons, the kind emulated in the BLE are equipped with solar panels and batteries, which allow them to adjust their altitude by controlling the weight of air in their ballast using an electric pump. However, they have no means to propel themselves laterally, which means that they are subject to wind patterns in the air around them.

By changing its altitude, a stratospheric balloon can surf winds moving in different directions.

The goal of an agent in the BLE is to station-keep — i.e., to control a balloon to stay within 50km of a fixed ground station — by changing its altitude to catch winds that it finds favorable. We measure how successful an agent is at station-keeping by measuring the fraction of time the balloon is within the specified radius, denoted TWR50 (i.e., the time within a radius of 50km).

A station-seeking balloon must navigate a changing wind field to stay above a ground station. Left: Side elevation of a station-keeping balloon. Right: Birds-eye-view of the same balloon.

The Challenges of Station-Keeping
To create a realistic simulator (without including copious amounts of historical wind data), the BLE uses a variational autoencoder (VAE) trained on historical data to generate wind forecasts that match the characteristics of real winds. A wind noise model is then used to make the windfields more realistic to match what a balloon would encounter in real-world conditions.

Navigating a stratospheric balloon through a wind field can be quite challenging. The winds at any given altitude rarely remain ideal for long, and a good balloon controller will need to move up and down through its wind column to discover more suitable winds. In RL parlance, the problem of station-keeping is partially observable because the agent only has access to forecasted wind data to make those decisions. An agent has access to wind forecasts at every altitude and the true wind at its current altitude. The BLE returns an observation which includes a notion of wind uncertainty.

A stratospheric balloon must explore winds at different altitudes in order to find favorable winds. The observation returned by the BLE includes wind predictions and a measure of uncertainty, made by mixing a wind forecast and winds measured at the balloon’s altitude.

In some situations, there may not be suitable winds anywhere in the balloon’s wind column. In this case, an expert agent is still able to fly towards the station by taking a more circuitous route through the wind field (a common example is when the balloon moves in a zig-zag fashion, akin to tacking on a sailboat). Below we demonstrate that even just remaining in range of the station usually requires significant acrobatics.

An agent must handle long planning horizons to succeed in station-keeping. In this case, StationSeeker (an expert-designed controller) heads directly to the center of the station-keeping area and is pushed out, while Perciatelli44 (an RL agent) is able to plan ahead and stay in range longer by hugging the edge of the area.

Night-time adds a fresh element of difficulty to station-keeping in the BLE, which reflects the reality of night-time changes in physical conditions and power availability. While during the day the air pump is powered by solar panels, at night the balloon relies on its on-board batteries for energy. Using too much power early in the night typically results in limited maneuverability in the hours preceding dawn. This is where RL agents can discover quite creative solutions — such as reducing altitude in the afternoon in order to store potential energy.

An agent needs to balance the station-keeping objective with a finite energy allowance at night.

Despite all these challenges, our research demonstrates that agents trained with reinforcement learning can learn to perform better than expert-designed controllers at station-keeping. Along with the BLE, we are releasing the main agents from our research: Perciatelli44 (an RL agent) and StationSeeker (an expert-designed controller). The BLE can be used with any reinforcement learning library, and to showcase this we include Dopamine’s DQN and QR-DQN agents, as well as Acme’s QR-DQN agent (supporting both standalone and distributed training with Launchpad).

Evaluation performance by the included benchmark agents on the BLE. “Finetuned” is a fine-tuned Perciatelli44 agent, and Acme is a QR-DQN agent trained with the Acme library.

The BLE source code contains information on how to get started with the BLE, including training and evaluating agents, documentation on the various components of the simulator, and example code. It also includes the historical windfield data (as a TensorFlow DataSet) used to train the VAE to allow researchers to experiment with their own models for windfield generation. We are excited to see the progress that the community will make on this benchmark.

Acknowledgements
We would like to thank the Balloon Learning Environment team: Sal Candido, Marc G. Bellemare, Vincent Dumoulin, Ross Goroshin, and Sam Ponda. We’d also like to thank Tom Small for his excellent animation in this blog post and graphic design help, along with our colleagues, Bradley Rhodes, Daniel Eisenberg, Piotr Staczyk, Anton Raichuk, Nikola Momchev, Geoff Hinton, Hugo Larochelle, and the rest of the Brain team in Montreal.

Source: Google AI Blog


FPGA Interchange format to enable interoperable FPGA tooling

Field Programmable Gate Arrays (FPGAs) have been around for decades and historically, the development of their specific toolchains happened in separate ecosystems that were driven by the vendors themselves. This has changed in recent years with the development of vendor-neutral open source toolchains, but this has revealed a new problem: the need for an abstraction layer to describe and define FPGA architectures through a standard format.

FPGA toolchains are not trivial, but roughly speaking, you can divide the process of “compiling” FPGA-targeted code in a Hardware Description Language (HDL) into three stages: synthesis, place and route, and bitstream generation. A standard format provides a common description of the architectures and serves as a bridge between the open source and closed proprietary tools responsible for various parts of the process.This includes the open source Yosys for synthesis, VtR and nextpnr for place and route, and vendor tooling from Xilinx, Intel, Lattice, QuickLogic, etc.

The introduction of a common format enables a shared methodology where specific building blocks are interchangeable. With that in mind, Google and Antmicro started the FPGA Interchange format project, providing a unified framework to lower the entry barriers for developers to swiftly move from one tool to another. In collaboration, Antmicro and other CHIPS Alliance members are developing the Interchange format definition and related tools aiming to become a development standard that the FPGA industry needs.

Components

The Interchange format provides three key descriptions to describe an FPGA and to interact with the various tools involved:
  • Device resources: defines the FPGA internal structure and the technological cell libraries describing FPGA logic blocks (basic blocks like flip-flops and complex like DSP cells).
  • Logical netlist: post-synthesized netlist compatible with the Interchange.
  • Physical netlist: collection of all placement locations and physical routing of the nets and resources produced by the place and route tool.
A challenge behind the creation of a standard format lies in the definition of the line between generalization and specificity of an FPGA architecture. By focusing on the only architecture type in mainstream use on the market today, namely island-based (also called tile-based) FPGAs, the standard reaches a level of universality and conciseness, which makes it easy to work with, adopt, and implement.

How it works

As previously mentioned, the FPGA Interchange format aims at lowering the barriers and building bridges between different place and route tools that can read and write using the same convention.

To achieve this, Antmicro and Google chose nextpnr as the first place and route tool to adopt the Interchange format. In the past few months, Antmicro extended nextpnr with FPGA Interchange format capabilities to place and route basic designs for the Xilinx 7-series and Lattice Nexus FPGA families.

To achieve initial support for Xilinx devices, the vendor’s own interesting RapidWright framework has also been introduced to the flow in collaboration with Xilinx’s research team. It is specifically used to write the device database in the Interchange format, consisting of all the device information.

Additionally, RapidWright can read and write the physical netlists to generate design checkpoint files that can be opened in Xilinx’s Vivado tool.

Example flow

The default open source flow for Xilinx devices uses Yosys to synthesize the design and VPR or nextpnr for place and route. The last step, bitstream generation, uses the open source FPGA Assembly FASM format to generate the file used for programming the FPGA. VPR supported this format natively, and nextpnr has been extended to support it as a part of the interchange format support work.


Now, by using the interchange format, you can create your flow from building blocks with the possibility to use a different tool (either open source or proprietary) for each step. A sample which illustrates this mix-and-match nature of interchange-capable tooling may look as depicted in the diagram above.

For processing any design, you need the FPGA device description files. These are generated in the following matter:
  • RapidWright generates the device description in the Interchange format.
  • The device description is translated by a dedicated script into the data-format suitable for nextpnr. The script will be eventually integrated into nextpnr enabling it to read the interchange format device description natively.
The device description has to be generated only once, and will normally be distributed with the toolchain installation package so that the user will not have to bother with this part. With the device architecture in place, a digital design can be processed with the toolchain.

This flow example shows how the Interchange creates a bridge between an open source flow with Yosys and nextpnr, and a closed source one using Vivado, demonstrating the possibility of interchanging tools thanks to a shared format.

To push forward the adoption of the format, the effort was recently onboarded into CHIPS Alliance, whose goal is to build an open source ASIC/FPGA ecosystem—including cores, I/O IPs, interconnect standards as well as digital and analog tooling—to radically transform the ASIC/FPGA design landscape.

Apart from allowing various existing tools to interoperate and share development efforts today, the Interchange format is a natural addition to the CHIPS Alliance in that it opens up smart ways to rapidly design and prototype new FPGA architectures, reduce the iteration times to implement, or add support to a place and route tool for a new architecture.

To further the collaboration around the Interchange Format, Xilinx has just joined the CHIPS Alliance to participate in the newly established FPGA workgroup of the Alliance which will include this and other FPGA-related projects that CHIPS Alliance is hosting.

Plans for the coming months

Besides nextpnr, there are other open source place and route tools slated to adopt the Interchange format as well, such as the Versatile Place and Route (VPR) from the Verilog-to-Routing project (VtR).

VtR can be used to place and route designs on FPGAs such as the Xilinx 7-series and QuickLogic’s eFPGA. This can only be done using the VPR data model and device description for now as it doesn’t support the Interchange format.

Antmicro is now implementing native support of the format within VPR, therefore enabling the use of place and route using different tools interchangeably; e.g. jumping from VPR placement output to nextpnr routing, allowing for faster improvements in algorithms.

Those benefits will extend to not only VPR and nextpnr, but to any other closed source tools, or new open source ones that adopt and implement the Interchange format.

Having a standard Interchange format at the tooling developers’ disposal lowers the barriers to developing new open source tools in this area. As example use cases, it enables new approaches to partial dynamic reconfiguration and the exploration of different place and route algorithms.

Customers will benefit from a wider range of flexible and customizable tools and ultimately get more control over their products. Antmicro provides end-to-end custom FPGA services, which involve reusable open source IP blocks, fast and reconfigurable SoCs, innovative tooling, and helping customers adopt the latest advances in software-driven FPGA development methodologies.


By Alessandro Comodi and Tom Michalak – Antmicro

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

We are excited to announce that open source projects and organizations can now apply to participate as mentoring organizations in the 2022 Google Summer of Code (GSoC) program. Applications for organizations will close Monday, February 21 at 10am PT.

As 2022 begins, so does our 18th edition of Google Summer of Code! With our new updates to the program, we look forward to welcoming not just students, but new and beginner open source contributors over 18 years old into our GSoC community. With increased flexibility in the length of the projects—now offering 175 and 350-hour projects—and the ability to extend the program from the standard 12 weeks to 22 weeks, we hope to spur the interest of more potential GSoC contributors.

Does your open source project want to learn more about becoming a mentor organization? Visit the program site and read the mentor guide to learn what it means to be a mentoring organization and how to prepare your community (hint: have plenty of excited mentors and well thought out project ideas!).

We welcome all types of organizations and are very eager to involve first-timers with a 2022 goal of welcoming 30+ new orgs into GSoC. We encourage new organizations to get a referral from experienced organizations that think they would be a good fit to participate in GSoC.

The open source projects that participate in GSoC as mentor organizations do all kinds of interesting work in security, cloud, development tools, science, medicine, data, and media for example. Projects can be relatively new (about 2 years old) to well established projects that started over 20 years ago. We welcome open source projects big and small and everything in between.

One thing to remember is that open source projects wishing to apply need to have a solid community. While you don’t have to have 50+ community members, the project also can’t have as few as 3 people; the goal of GSoC is to bring new contributors into communities and there should be an established community for them to join.

You can apply to be a mentor organization for GSoC starting today on the program site. The deadline to apply is February 21st at 10am PT. We will publicly announce the organizations chosen for GSoC 2022 on March 7th.

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

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source