Category Archives: Open Source Blog

News about Google’s open source projects and programs

OpenXLA is available now to accelerate and simplify machine learning

ML development and deployment today suffer from fragmented and siloed infrastructure that can differ by framework, hardware, and use case. Such fragmentation restrains developer velocity and imposes barriers to model portability, efficiency, and productionization. 

Today, we’re taking a significant step towards eliminating these barriers by making the OpenXLA Project, including the XLA, StableHLO, and IREE repositories, available for use and contribution.

OpenXLA is an open source ML compiler ecosystem co-developed by AI/ML industry leaders including Alibaba, Amazon Web Services, AMD, Apple, Arm, Cerebras, Google, Graphcore, Hugging Face, Intel, Meta, and NVIDIA. It enables developers to compile and optimize models from all leading ML frameworks for efficient training and serving on a wide variety of hardware. Developers using OpenXLA will see significant improvements in training time, throughput, serving latency, and, ultimately, time-to-market and compute costs.

Start accelerating your workloads with OpenXLA on GitHub.

The Challenges with ML Infrastructure Today

Development teams across numerous industries are using ML to tackle complex real-world challenges, such as prediction and prevention of disease, personalized learning experiences, and black hole physics.

As model parameter counts grow exponentially and compute for deep learning models doubles every six months, developers seek maximum performance and utilization of their infrastructure. Teams are leveraging a wider array of hardware from power-efficient ML ASICs in the datacenter to edge processors that can deliver more responsive AI experiences. These hardware devices have bespoke software libraries with unique algorithms and primitives.

However, without a common compiler to bridge these diverse hardware devices to the multiple frameworks in use today (e.g. TensorFlow, PyTorch), significant effort is required to run ML efficiently; developers must manually optimize model operations for each hardware target. This means using bespoke software libraries or writing device-specific code, which requires domain expertise. The result is isolated, non-generalizable paths across frameworks and hardware that are costly to maintain, promote vendor lock-in, and slow progress for ML developers.

Our Solution and Goals

The OpenXLA Project provides a state-of-the-art ML compiler that can scale amidst the complexity of ML infrastructure. Its core pillars are performance, scalability, portability, flexibility, and extensibility for users. With OpenXLA, we aspire to realize the real-world potential of AI by accelerating its development and delivery.

Our goals are to:
  • Make it easy for developers to compile and optimize any model in their preferred framework, for a wide range of hardware through (1) a unified compiler API that any framework can target (2) pluggable device-specific back-ends and optimizations.
  • Deliver industry-leading performance for current and emerging models that (1) scales across multiple hosts and accelerators (2) satisfies the constraints of edge deployments (3) generalizes to novel model architectures of the future.
  • Build a layered and extensible ML compiler platform that provides developers with (1) MLIR-based components that are reconfigurable for their unique use cases (2) plug-in points for hardware-specific customization of the compilation flow.

A Community of AI/ML Leaders

The challenges we face in ML infrastructure today are immense and no single organization can effectively resolve them alone. The OpenXLA community brings together developers and industry leaders operating at different levels of the AI stack, from frameworks to compilers, runtimes, and silicon, and is thus well suited to address the fragmentation we see across the ML landscape.

As an open source project, we’re guided by the following set of principles:
  • Equal footing: Individuals contribute on equal footing regardless of their affiliation. Technical leaders are those who contribute the most time and energy.
  • Culture of respect: All members are expected to uphold project values and code of conduct, regardless of their position in the community.
  • Scalable, efficient governance: Small groups make consensus-based decisions, with clear but rarely-used paths for escalation.
  • Transparency: All decisions and rationale should be legible to the public community.

Performance, Scale, and Portability: Leveraging the OpenXLA Ecosystem

OpenXLA eliminates barriers for ML developers via a modular toolchain that is supported by all leading frameworks through a common compiler interface, leverages standardized model representations that are portable, and provides a domain-specific compiler with powerful target-independent and hardware-specific optimizations. This toolchain includes XLA, StableHLO, and IREE, all of which leverage MLIR: a compiler infrastructure that enables machine learning models to be consistently represented, optimized and executed on hardware.

Flow chart depicting high-level OpenXLA compilation flow and architecture showing depicted optimizations, frameworks and hardware targets
High-level OpenXLA compilation flow and architecture. Depicted optimizations, frameworks and hardware targets represent a select portion of what is available to developers through OpenXLA.

Here are some of the key benefits that OpenXLA provides:

Spectrum of ML Use Cases

Usage of OpenXLA today spans the gamut of ML use cases. This includes full-scale training of models like DeepMind’s AlphaFold, GPT2 and Swin Transformer on Alibaba Cloud, and multi-modal LLMs for Amazon.com. Users like Waymo leverage OpenXLA for on-vehicle, real-time inference. In addition, OpenXLA is being used to optimize serving of Stable Diffusion on AMD RDNA™ 3-equipped local machines.

Optimal Performance, Out of the Box

OpenXLA makes it easy for developers to speed up model performance without needing to write device-specific code. It features whole-model optimizations including simplification of algebraic expressions, optimization of in-memory data layout, and improved scheduling for reduced peak memory use and communication overhead. Advanced operator fusion and kernel generation help improve device utilization and reduce memory bandwidth requirements.

Scale Workloads With Minimal Effort

Developing efficient parallelization algorithms is time-consuming and requires expertise. With features like GSPMD, developers only need to annotate a subset of critical tensors that the compiler can then use to automatically generate a parallelized computation. This removes much of the work required to partition and efficiently parallelize models across multiple hardware hosts and accelerators.

Portability and Optionality

OpenXLA provides out-of-the-box support for a multitude of hardware devices including AMD and NVIDIA GPUs, x86 CPU and Arm architectures, as well as ML accelerators like Google TPUs, AWS Trainium and Inferentia, Graphcore IPUs, Cerebras Wafer-Scale Engine, and many more. OpenXLA additionally supports TensorFlow, PyTorch, and JAX via StableHLO, a portability layer that serves as OpenXLA's input format.

Flexibility

OpenXLA gives users the flexibility to manually tune hotspots in their models. Extension mechanisms such as Custom-call enable users to write deep learning primitives with CUDA, HIP, SYCL, Triton and other kernel languages so they can take full advantage of hardware features.

StableHLO

StableHLO, a portability layer between ML frameworks and ML compilers, is an operation set for high-level operations (HLO) that supports dynamism, quantization, and sparsity. Furthermore, it can be serialized into MLIR bytecode to provide compatibility guarantees. All major ML frameworks (JAX, PyTorch, TensorFlow) can produce StableHLO. Through 2023, we plan to collaborate closely with the PyTorch team to enable an integration to the recent PyTorch 2.0 release.

We’re excited for developers to get their hands on these features and many more that will significantly accelerate and simplify their ML workflows.

Moving Forward Together

The OpenXLA Project is being built by a collaborative community, and we're excited to help developers extend and use it to address the gaps and opportunities we see in the ML industry today. Get started with OpenXLA today on GitHub and sign up for our mailing list here for product and community announcements. You can follow us on Twitter: @OpenXLA

Member Quotes

Here’s what our collaborators are saying about OpenXLA:

Alibaba

“At Alibaba, OpenXLA is leveraged by Elastic GPU Service customers for training and serving of large PyTorch models. We’ve seen significant performance improvements for customers using OpenXLA, notably speed-ups of 72% for GPT2 and 88% for Swin Transformer on NVIDIA GPUs. We're proud to be a founding member of the OpenXLA Project and work with the open-source community to develop an advanced ML compiler that delivers superior performance and user experience for Alibaba Cloud customers.” – Yangqing Jia, VP, AI and Data Analytics, Alibaba

AWS

“We're excited to be a founding member of the OpenXLA Project, which will democratize access to performant, scalable, and extensible AI infrastructure as well as further collaboration within the open source community to drive innovation. At AWS, our customers scale their generative AI applications on AWS Trainium and Inferentia and our Neuron SDK relies on XLA to optimize ML models for high performance and best in class performance per watt. With a robust OpenXLA ecosystem, developers can continue innovating and delivering great performance with a sustainable ML infrastructure, and know that their code is portable to use on their choice of hardware.” – Nafea Bshara, Vice President and Distinguished Engineer, AWS

AMD

“We are excited about the future direction of OpenXLA on the broad family of AMD devices (CPUs, GPUs, AIE) and are proud to be part of this community. We value projects with open governance, flexible and broad applicability, cutting edge features and top-notch performance and are looking forward to the continued collaboration to expand open source ecosystem for ML developers.”  – Alan Lee, Corporate Vice President, Software Development, AMD

Arm

“The OpenXLA Project marks an important milestone on the path to simplifying ML software development. We are fully supportive of the OpenXLA mission and look forward to leveraging the OpenXLA stability and standardization across the Arm® Neoverse™ hardware and software roadmaps.” – Peter Greenhalgh, vice president of technology and fellow, Arm.

Cerebras

“At Cerebras, we build AI accelerators that are designed to make training even the largest AI models quick and easy. Our systems and software meet users where they are -- enabling rapid development, scaling, and iteration using standard ML frameworks without change. OpenXLA helps extend our user reach and accelerated time to solution by providing the Cerebras Wafer-Scale Engine with a common interface to higher level ML frameworks. We are tremendously excited to see the OpenXLA ecosystem available for even broader community engagement, contribution, and use on GitHub.” – Andy Hock, VP and Head of Product, Cerebras Systems

Google

“Open-source software gives everyone the opportunity to help create breakthroughs in AI. At Google, we’re collaborating on the OpenXLA Project to further our commitment to open source and foster adoption of AI tooling that raises the standard for ML performance, addresses incompatibilities between frameworks and hardware, and is reconfigurable to address developers’ tailored use cases. We’re excited to develop these tools with the OpenXLA community so that developers can drive advancements across many different layers of the AI stack.” – Jeff Dean, Senior Fellow and SVP, Google Research and AI

Graphcore

“Our IPU compiler pipeline has used XLA since it was made public. Thanks to XLA's platform independence and stability, it provides an ideal frontend for bringing up novel silicon. XLA’s flexibility has allowed us to expose our IPU’s novel hardware features and achieve state of the art performance with multiple frameworks. Millions of queries a day are served by systems running code compiled by XLA. We are excited by the direction of OpenXLA and hope to continue contributing to the open source project. We believe that it will form a core component in the future of AI/ML.” – David Norman, Director of Software Design, Graphcore

Hugging Face

“Making it easy to run any model efficiently on any hardware is a deep technical challenge, and an important goal for our mission to democratize good machine learning. At Hugging Face, we enabled XLA for TensorFlow text generation models and achieved speed-ups of ~100x. Moreover, we collaborate closely with engineering teams at Intel, AWS, Habana, Graphcore, AMD, Qualcomm and Google, building open source bridges between frameworks and each silicon, to offer out of the box efficiency to end users through our Optimum library. OpenXLA promises standardized building blocks upon which we can build much needed interoperability, and we can't wait to follow and contribute!” – Morgan Funtowicz, Head of Machine Learning Optimization, Hugging Face

Intel

“At Intel, we believe in open, democratized access to AI. Intel CPUs, GPUs, Habana Gaudi accelerators, and oneAPI-powered AI software including OpenVINO, drive ML workloads everywhere from exascale supercomputers to major cloud deployments. Together with other OpenXLA members, we seek to support standards-based, componentized ML compiler tools that drive innovation across multiple frameworks and hardware environments to accelerate world-changing science and research.” – Greg Lavender, Intel SVP, CTO & GM of Software & Advanced Technology Group

Meta

“In research, at Meta AI, we have been using XLA, a core technology of the OpenXLA project, to enable PyTorch models for Cloud TPUs and were able to achieve significant performance improvements on important projects. We believe that open source accelerates the pace of innovation in the world, and are excited to be a part of the OpenXLA Project.” – Soumith Chintala, Lead Maintainer, PyTorch

NVIDIA

“As a founding member of the OpenXLA Project, NVIDIA is looking forward to collaborating on AI/ML advancements with the OpenXLA community and are positive that with wider engagement and adoption of OpenXLA, ML developers will be empowered with state-of-the-art AI infrastructure.” – Roger Bringmann, VP, Compiler Software, NVIDIA.

Acknowledgements

Abhishek Ratna, Allen Hutchison, Aman Verma, Amber Huffman, Andrew Leaver, Ashok Bhat, Chalana Bezawada, Chandan Damannagari, Chris Leary, Christian Sigg, Cormac Brick, David Dunleavy, David Huntsperger, David Majnemer, Elisa Garcia Anzano, Elizabeth Howard, Eugene Burmako, Gadi Hutt, Geeta Chauhan, Geoffrey Martin-Noble, George Karpenkov, Ian Chan, Jacinda Mein, Jacques Pienaar, Jake Hall, Jake Harmon, Jason Furmanek, Julian Walker, Kulin Seth, Kanglan Tang, Kuy Mainwaring, Magnus Hyttsten, Mahesh Balasubramanian, Mehdi Amini, Michael Hudgins, Milad Mohammadi, Navid Khajouei, Paul Baumstarck, Peter Hawkins, Puneith Kaul, Rich Heaton, Robert Hundt, Roman Dzhabarov, Rostam Dinyari, Scott Kulchycki, Scott Main, Scott Todd, Shantu Roy, Shauheen Zahirazami, Stella Laurenzo, Stephan Herhut, Thea Lamkin, Tomás Longeri, Tres Popp, Vartika Singh, Vinod Grover, Will Constable, and Zac Mustin.

By James Rubin, Product Manager, Machine Learning

Introducing Service Weaver: A Framework for Writing Distributed Applications

We are excited to introduce Service Weaver, an open source framework for building and deploying distributed applications. Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices.

More concretely, Service Weaver consists of two core pieces:

  1. A set of programming libraries, which let you write your application as a single modular binary, using only native data structures and method calls, and
  2. A set of deployers, which let you configure the runtime topology of your application and deploy it as a set of microservices, either locally or on the cloud of your choosing.
    3. Flow chart of Service Weaver Programming Libraries from development to execution, moving four modules labeled A through D from application across a level of microservices to deployers labeled Desktop, Google Cloud, and Other Cloud
By decoupling the process of writing the application from runtime considerations such as how the application is split into microservices, what data serialization formats are used, and how services are discovered, Service Weaver aims to improve distributed application development velocity and performance.

Motivation for Building Service Weaver

While writing microservices-based applications, we found that the overhead of maintaining multiple different microservice binaries—with their own configuration files, network endpoints, and serializable data formats—significantly slowed our development velocity.

More importantly, microservices severely impacted our ability to make cross-binary changes. It made us do things like flag-gate new features in each binary, evolve our data formats carefully, and maintain intimate knowledge of our rollout processes. Finally, having a predetermined number of specific microservices effectively froze our APIs; they became so difficult to change that it was easier to squeeze all of our changes into the existing APIs rather than evolve them.

As a result, we wished we had a single monolithic binary to work with. Monolithic binaries are easy to write: they use only language-native types and method calls. They are also easy to update: just edit the source code and re-deploy. They are easy to run locally or in a VM: simply execute the binary.

Service Weaver, is a framework that has the best of both worlds: the development velocity of a monolith, with the scalability, security, and fault-tolerance of microservices.

Service Weaver Overview

The core idea of Service Weaver is its modular monolith model. You write a single binary, using only language-native data structures and method calls. You organize your binary as a set of modules, called components, which are native types in the programming language. For example, here is a simple application written in Go using Service Weaver. It consists of a main() function and a single Adder component:
type Adder interface { Add(context.Context, int, int) (int, error) } type adder struct{ weaver.Implements[Adder] } func (adder) Add(_ context.Context, x, y int) (int, error) { return x + y, nil} func main() { ctx := context.Background() root := weaver.Init(ctx) adder, err := weaver.Get[Adder](root) sum, err := adder.Add(ctx, 1, 2) }
When running the above application, you can make a trivial configuration choice of whether to place the Adder component together with the main() function or to place it separately. When the Adder component is separate, the Service Weaver framework automatically translates the Add call into a cross-machine RPC; otherwise, the Add call remains a local method call.

To make a change to the above application, such as adding an unbounded number of arguments to the Add method, all you have to do is change the signature of Add, change its call-sites, and re-deploy your application. Service Weaver makes sure that the new version of main() communicates only with the new version of Adder, regardless of whether they are co-located or not. This behavior, combined with using language-native data structures and method calls, allows you to focus exclusively on writing your application logic, without worrying about the deployment topology and inter-service communication (e.g., there are no protos, stubs, or RPC channels in the code).

When it is time to run your application, Service Weaver allows you to run it anywhere—on your local desktop environment or on your local rack of machines or in the cloud—without any changes to your application code. This level of portability is achieved by a clear separation of concerns built into the Service Weaver framework. On one end, we have the programming framework, used for application development. On the other end, we have various deployer implementations, one per deployment environment.
Flow chart depicting Service Weaver Libraries deployer implementations across three separate platforms in one single iteration

This separation of concerns allows you to run your application locally in a single process via go run .; or run it on Google Cloud via weaver gke deploy; or enable and run it on other platforms. In all of these cases, you get the same application behavior without the need to modify or re-compile your application.

What’s in Service Weaver v0.1?

The v0.1 release of Service Weaver includes:

  • The core Go libraries used for writing your applications.
  • A number of deployers used for running your applications locally or on GKE.
  • A set of APIs that allow you to write your own deployers for any other platform.

All of the libraries are released under the Apache 2.0 license. Please be aware that we are likely to introduce breaking changes until version v1.0 is released.

Get Started and Get Involved

While Service Weaver is still in an early development stage, we would like to invite you to use it and share your feedback, thoughts, and contributions.

The easiest way to get started using Service Weaver is to follow the Step-By-Step instructions on our website. If you would like to contribute, please follow our contributor guidelines. To post a question or contact the team directly, use the Service Weaver mailing list.

The team is excited to host a Twitter Space with Kelsey Hightower on March 2nd, at 10am PST. Keep an eye out on the Service Weaver blog for the latest news, updates, and details on future events.

More Resources

  • Visit us at serviceweaver.dev to get the latest information about the project, such as getting started, tutorials, and blog posts.
  • Access one of our Service Weaver repositories on GitHub.

By Srdjan Petrovic and Garv Sawhney, on behalf of the Service Weaver team

Mentor organizations announced for Google Summer of Code 2023!

After careful review, we are pleased to announce that 172 open source projects have been selected for Google Summer of Code (GSoC) 2023! This year we are excited to welcome 18 new organizations for their first year as part of the program.

Please see our program site to view the complete list of GSoC 2023 accepted mentoring organizations. We invite you to learn more about each organization on their GSoC program page, which includes reading through the project ideas that they are looking for GSoC contributors to work on this year.

Are you interested in being a GSoC Contributor?

The 2023 GSoC program is open to students and to beginners in open source software development. Contributor applications will open on Monday, March 20, 2023 at 18:00 UTC with a deadline of Tuesday, April 4, 2023 18:00 UTC to submit your application (including your project proposal).

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

  • Watch our new ‘Introduction to GSoC’ video to see a quick overview of the program, and view our Community Talks or Org Highlight Videos to get inspired and learn more about some projects that contributors have worked on in the past.
  • Check out the Contributor Guide and Advice for Applying to GSoC doc.
  • Review the list of accepted organizations here. We recommend finding two to four that interest you and reading through their project ideas lists.
  • As soon as you see an idea that sparks your interest, reach out to the organization via their preferred communication methods (listed on their org page on the GSoC program site). The earlier you start the conversation, the better your chances of being accepted as a GSoC contributor.
  • 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 excites 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 urge anyone interested in applying to read the FAQ and Program Rules and watch 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 2023.

Supporting DDR4 and DDR5 RDIMMs in open source DRAM security testing framework

In 2021, Google and Antmicro introduced a platform for testing DRAM memory chips against the unfortunate side effect of the physical shrinking of memory chips—the Rowhammer vulnerability. The platform was developed to propose a radical improvement over the “security through obscurity” approach that was predominant in the industry; as both Antmicro and Google believe that the open source approach to mitigating security threats is a way towards accelerating developments in the field.

The framework was originally developed in the context of securing consumer-facing devices, using off-the-shelf Digilent Arty (DDR3, Xilinx Series7 FPGA) and Xilinx ZCU104 (DDR4, Xilinx UltraScale+ FPGA) boards, then followed by a dedicated open hardware board from Antmicro that allowed work on custom LPDDR4 modules. The framework has since helped discover a new attack method named Blacksmith and continues to provide valuable insights into how the security of both edge device and data center memory can be improved.

In constant development since then, the project has welcomed two more major elements to the ecosystem in order to enable testing of DDR4 Registered Dual In-Line Memory Modules (RDIMM)—commonly used in data centers as well as the newer DDR5 standard and continues to provide useful data.

Memory testing for data center use cases

To extend the Rowhammer tester support from consumer-facing devices to shared-compute data center infrastructure, Antmicro developed the data center DRAM tester board. We adapted this open source hardware-test platform from the original LPDDR4 board to enable Rowhammer and other memory security experiments with DDR4 RDIMMs using a fully configurable, open source FPGA-based DDR controller.

The data center DRAM Xilinx Kintex-7 FPGA based test board features:

  • DDR4 RDIMM connector
  • 676 pins FPGA (compared to the 484 for the LPDDR version)
  • RJ45 Gigabit Ethernet
  • Micro-USB console
  • HDMI output connector
  • JTAG programming connector
  • MicroSD card slot
  • 12 MBytes QSPI Flash memory
  • HyperRAM—external DRAM memory that can be used as an FPGA cache
Photo of the Antmicro data center DRAM Xilinx Kintex-7 FPGA based tester board

It’s worth mentioning that the RDIMM DDR4 memory (as opposed to the custom LPDDR4 modules designed for the original project) are generic and available off-the-shelf. This makes it easier for security researchers to get started with data center memory security research compared to edge devices using LPDDR.

The Data Center DRAM Tester board design has now been upgraded into revision 1.2, which brings new features for implementing even more complex DRAM testing scenarios. The 1.2 boards support a Power over Ethernet (PoE) supply option so the board can act as a standalone network device with data exchange and power-cycling done over a single Ethernet cable. This simplifies integration of the board in DRAM testing clusters and custom runners capable of doing hardware-in-the-loop testing.

The new revision of the board will support hot-swapping of the DRAM module under test, which should speed up testing of multiple DRAM modules without the need to power-cycle the tester. Finally, the new revision of the board will include power-measurement circuitry so it will be possible to compare the peak and average power consumption of DRAM while working with different DRAM refresh scenarios.

We are also working on a custom enclosure design suitable for desktop and networked installations.

Extending open source testing to DDR5

With DDR5 quickly becoming the new standard for data center memory, Antmicro and Google’s Platforms teams also set out to develop a platform capable of interfacing with DDR5 memories, again directly from a low-cost FPGA without a dedicated hard block. The resulting DDR5 tester platform follows the structure of the data center DDR4 tester, while expanding on functionality of the Serial Presence Detection, which monitors the power supply states and system health, or adjusting the circuitry for a nominal IO voltage of 1.1V.

Photo of the Antmicro DDR5 testbed

Data center DRAM testing is part of Google’s and Antmicro’s belief in security through transparency. Both hyperscalers and a growing number of organizations who operate their own data centers increasingly embrace this perspective, and there is great value in providing them with a scalable, customizable, commercially supported open source platform that will help in collaborative research and mitigation of emerging security issues.

Rowhammer attacks, security threats, and countermeasures remain an active research area. With Google, Antmicro continues to adjust the Rowhammer test platform to most recent developments, opening the way for researchers and memory vendors to more sophisticated testing methods to enable testing of state-of-the-art memories used in data centers. This work stems from and complements other open source activities the companies jointly lead as members of RISC-V International and CHIPS Alliance, aimed at making the hardware ecosystem more open, secure and collaborative. If you’re interested in open source solutions for DRAM security testing and memory controller development, or more broadly, FPGA and ASIC design and verification, don’t hesitate to reach out to Antmicro at [email protected].

By Michael Gielda – Antmicro

Kickstarting your tech writing career with open source

After graduating from University in the midst of a pandemic, I knew that I wanted to be a tech writer, but I wasn’t sure how to start. Google Season of Docs was the perfect way to launch my career; it let me work on my own terms and led to me starting my own business and to subsequent tech writing jobs in open source. I am currently working as a tech writer at Google and volunteering for documentation-related open source projects.

Should you join an open source project?

The charm (and challenge) of open source is that the line between creators and users becomes blurred. Do you wish that your beloved tool had that one feature you really need? You can add it yourself! Other users might support your feature request and may even help you build it. Before you know it, you’re part of a wonderful community bound together by passion.

People join open source projects for many reasons:

  • They believe in the vision of a project and want to help build it
  • They want to build professional and technical skills
  • They are motivated by the possibility of hundreds—or even thousands—of people using their work

Life in open source as a tech writer

Many contributors in open source come from a software engineering background. They are great at building software, but they sometimes struggle with documentation. Through Google Season of Docs, open source projects can hire technical writers to help them create much-needed content. These technical writers are likely the first person in the project working exclusively on educational content—which comes with ups and downs.

The fun parts

As an open source technical writer, you will often be in close contact with your users. Through researching user needs, technical writers develop more empathy for the struggles of the users. Many tech writers (myself included) find that this closeness helps them write better.

Contributing to open source also allows you to create documentation in different contexts. For example, you might have authored content in a CMS in the past—diving into an open source project gives you the opportunity to explore a docs-as-code workflow. Another circumstance could be that you wrote documentation in a different industry and you want to see what it’s like to document software. Changing up your writing routine helps you find more creative ways to tackle problems for the next project you work on.

The hard parts

Documentation quality can be quite variable in open source. While some pages might be really useful, others might be outdated, don’t follow the user workflow, or cover way too much information on one page. Making sense of the existing documentation landscape can feel like a daunting task.

Most open source projects suffer from gaps in the documentation. Since open source developers are so enmeshed with their code and the project, they have a lot of context, and suffer from the “curse of knowledge”. It’s hard for contributors, or anyone who has held a position for a while, to remember what it was like to be a beginner or new to a project. When developers write documentation, their brain auto-completes what is missing on the page.

Because many people work on open source for personal satisfaction, you might experience pushback from people who are protective of their documentation. I find it helpful to view pushback as an act of caring about documentation. Take a closer look at why you are receiving pushback:

  • Do the developers have concerns about your technical understanding?
  • Are they not ready to let go of their document?
  • Do you have different ideas of who the user is and what their goals are?

Understanding developer concerns can help you reach the shared goal of improved documentation.

Succeeding in Google Season of Docs and beyond

These tips helped me make the most of my Google Season of Docs experience.

Gain clarity

Take time in the beginning of the project to really understand the software, the user’s needs, and your docs landscape. (I allocated one third of my entire project timeline to gaining clarity.) Talk to your project mentors, do user research, and perform a content audit—this will help you understand the current structure and identify weaknesses and gaps in the content.

Keep your community in the loop

Open source communities attract contributors from all over the world—which means communication is usually asynchronous and in writing. Transparent communication is a must to keep your users (and potential co-creators) engaged. When they know what’s going on, it’s easier for them to chip in.

Deal with pushbacks

Transparent communications and a solid documentation plan go a long way towards addressing concerns. It’s easier to receive support if your team knows what you’re doing.

Build a professional support network

Find other tech writers to geek out with, especially if you’re the only technical writer in your project. Groups like Write the Docs and The Good Docs project are good places to find like-minded people to brainstorm and learn with.

I hope you find a project that interests you and the bandwidth to participate in Google Season of Docs. It was a worthwhile experience for me, helped me advance in my career, and I hope the same for you.

P.S. You can find a detailed write up of my work for Season of Docs ‘21 on my website.

By Tina Luedtke, Technical Writer – Google

Kickstarting your tech writing career with open source

After graduating from University in the midst of a pandemic, I knew that I wanted to be a tech writer, but I wasn’t sure how to start. Google Season of Docs was the perfect way to launch my career; it let me work on my own terms and led to me starting my own business and to subsequent tech writing jobs in open source. I am currently working as a tech writer at Google and volunteering for documentation-related open source projects.

Should you join an open source project?

The charm (and challenge) of open source is that the line between creators and users becomes blurred. Do you wish that your beloved tool had that one feature you really need? You can add it yourself! Other users might support your feature request and may even help you build it. Before you know it, you’re part of a wonderful community bound together by passion.

People join open source projects for many reasons:

  • They believe in the vision of a project and want to help build it
  • They want to build professional and technical skills
  • They are motivated by the possibility of hundreds—or even thousands—of people using their work

Life in open source as a tech writer

Many contributors in open source come from a software engineering background. They are great at building software, but they sometimes struggle with documentation. Through Google Season of Docs, open source projects can hire technical writers to help them create much-needed content. These technical writers are likely the first person in the project working exclusively on educational content—which comes with ups and downs.

The fun parts

As an open source technical writer, you will often be in close contact with your users. Through researching user needs, technical writers develop more empathy for the struggles of the users. Many tech writers (myself included) find that this closeness helps them write better.

Contributing to open source also allows you to create documentation in different contexts. For example, you might have authored content in a CMS in the past—diving into an open source project gives you the opportunity to explore a docs-as-code workflow. Another circumstance could be that you wrote documentation in a different industry and you want to see what it’s like to document software. Changing up your writing routine helps you find more creative ways to tackle problems for the next project you work on.

The hard parts

Documentation quality can be quite variable in open source. While some pages might be really useful, others might be outdated, don’t follow the user workflow, or cover way too much information on one page. Making sense of the existing documentation landscape can feel like a daunting task.

Most open source projects suffer from gaps in the documentation. Since open source developers are so enmeshed with their code and the project, they have a lot of context, and suffer from the “curse of knowledge”. It’s hard for contributors, or anyone who has held a position for a while, to remember what it was like to be a beginner or new to a project. When developers write documentation, their brain auto-completes what is missing on the page.

Because many people work on open source for personal satisfaction, you might experience pushback from people who are protective of their documentation. I find it helpful to view pushback as an act of caring about documentation. Take a closer look at why you are receiving pushback:

  • Do the developers have concerns about your technical understanding?
  • Are they not ready to let go of their document?
  • Do you have different ideas of who the user is and what their goals are?

Understanding developer concerns can help you reach the shared goal of improved documentation.

Succeeding in Google Season of Docs and beyond

These tips helped me make the most of my Google Season of Docs experience.

Gain clarity

Take time in the beginning of the project to really understand the software, the user’s needs, and your docs landscape. (I allocated one third of my entire project timeline to gaining clarity.) Talk to your project mentors, do user research, and perform a content audit—this will help you understand the current structure and identify weaknesses and gaps in the content.

Keep your community in the loop

Open source communities attract contributors from all over the world—which means communication is usually asynchronous and in writing. Transparent communication is a must to keep your users (and potential co-creators) engaged. When they know what’s going on, it’s easier for them to chip in.

Deal with pushbacks

Transparent communications and a solid documentation plan go a long way towards addressing concerns. It’s easier to receive support if your team knows what you’re doing.

Build a professional support network

Find other tech writers to geek out with, especially if you’re the only technical writer in your project. Groups like Write the Docs and The Good Docs project are good places to find like-minded people to brainstorm and learn with.

I hope you find a project that interests you and the bandwidth to participate in Google Season of Docs. It was a worthwhile experience for me, helped me advance in my career, and I hope the same for you.

P.S. You can find a detailed write up of my work for Season of Docs ‘21 on my website.

By Tina Luedtke, Technical Writer – Google

Configure your private clouds using the Google Cloud VMware Engine IaC Foundations repository

Introduction

Google Cloud VMware Engine is a Google-managed VMware platform that customers can use to run their VMware workloads on Google Cloud. VMware Engine private clouds consist of VMware ESXi clusters that are managed by Google. Customers manage the virtual infrastructure of private clouds using VMware vCenter and VMware NSX-T for software-defined networking. The GCVE IaC Foundations code guides customers to automate the configuration of several layers of the infrastructure and virtualization stack, using infrastructure as code. This includes the integration of platform logging and monitoring with the Google Cloud Operations Suite, configurations such as VM folders, permissions and VM deployments in vCenter and network configurations in NSX-T, including subnets, firewalls, and load balancers.

The use of infrastructure as code for a VMware Engine Private Cloud offers multiple benefits, including:

  1. Providing consistent and repeatable deployment templates which can be reused across SDLC environments to reduce human error and shorten configuration times.
  2. Enabling continuous integration using GitOps workflows to improve collaboration between engineers and increase reliability in the release process.
  3. Offering version control of configuration templates to track changes in the infrastructure and a simple method to revert changes to a previous configuration.

Technical Details

The Google Cloud VMware Engine IaC Foundations Github repository contains Terraform modules and sample code for maintaining VMware Engine, vCenter and NSX-T configurations using infrastructure as code. The repository is structured as follows: 

├── examples
│   ├── nsxt-gateway-firewall
│   ├── nsxt-load-balancer-pool
│   ├── nsxt-load-balancer-service
│   ├── ...
├── modules
│   ├── nsxt-gateway-firewall
│   ├── nsxt-load-balancer-pool
│   ├── nsxt-load-balancer-service
│   ├── ...
└── stages
    ├── 01-privatecloud
    ├── 02a-nsxt
    ├── 02b-vcenter
    ├── 03-vms
    └── 04-load-balancing

The modules directory contains the Terraform IaC modules for GCVE (vCenter & NSX-T) resource types. Each module has a corresponding example in the examples directory. Modules and examples are meant to be discrete and function as the building blocks for managing GCVE at scale.

The stages directory contains sample deployments composed from modules for each of the different stages of the foundational deployment. These stages should be executed in the order they are listed. Stages may also be delegated to different teams within an organization depending on organizational roles and responsibilities. As an example, there may be a team that manages vCenter, while a Networking team manages NSX-T and each team has their own code repository for configuration management.

The individual stages deploy the following components:

Stage

Deployed sample Component(s)

01-privatecloud

  • Google Cloud Monitoring & Logging integration for GCVE

02a-nsxt

  • Virtual machine network segment

  • North / south firewall (gateway firewall)

  • East / west firewall (distributed firewall)

02b-vcenter

  • vCenter resource pools & folders

  • vCenter role assignments

03-vms

  • Virtual machines

04-load-balancing

  • NSX-T Load balancing

Deployment Walkthrough

To deploy the sample stages you will need to clone the gcve-iac-foundations repository and have Terraform 1.3.x or later installed.

To deploy the stages proceed in order in the stages directory from 01-privatecloud until 04-load-balancing. In each directory perform the following:

  • Copy terraform.tfvars.example to terraform.tfvars and customize any values as necessary
  • Run `terraform init`, `terraform plan` and `terraform apply`

Each of the stages and examples contain reference terraform.tfvars files which can be used in the initial stages to test deployment and later customized to meet specific requirements.

As an example, the following Terraform configuration can be used to configure the NSX-T distributed firewall: 

dfw_policies = [
  {
    display_name    = "dfw_allow_policy"
    sequence_number = 1
    rules = [
      {
        action             = "ALLOW"
        destination_groups = ["10.123.1.0/24"]
        source_groups      = []
        direction          = "IN_OUT"
        display_name       = "dfw-allow-ssh"
        logged             = false
        services           = ["SSH"]
      },
      {
        action             = "ALLOW"
        destination_groups = ["10.123.2.0/23"]
        source_groups      = ["10.200.1.0-10.200.1.128"]
        direction          = "IN_OUT"
        display_name       = "dfw-allow-dns"
        logged             = false
        services           = ["DNS"]
      },
    ]
  },
<…snip…>
]

Apply the Terraform configuration from a terminal using 

terraform init // initialize the provider and modules
terraform plan // validate the expected Terraform configuration on the console
terraform apply // deploy the configuration in NSX-T

Try it yourself

Whether you consider using VMware Engine for your VMware workloads or you actively use the service already, give it a try and clone the repository into your environment and go through the provided deployment examples and stages of the repository. Review if you can automate any processes that you perform manually today using infrastructure-as-code and improve your VMware operations using the content from the foundations repository.

We would like to get your feedback! If you encounter any issues or you have any feedback or suggestions for improvement, create an issue directly on the repository on Github. We would also like to encourage you to create pull requests to the main branch if you like to become an active contributor. To get started, review how to contribute on Github.

By Konrad Schieban and Jason Steenblik – Google Cloud

Acknowledgments:

Thank you to the following team members who made this solution possible: Kumari Renuka, Ashwin Naik, Leandro Carracedo, Eric Danan, and Umesh Kumhar from Google Cloud.

Mentor organization applications are open for Google Summer of Code 2023!


We are excited to announce that open source projects and organizations can now apply to participate as mentor organizations in the 2023 Google Summer of Code (GSoC) program. Applications for organizations will close on February 7, 2023 at 18:00 UTC.

As 2023 begins, so does our 19th year of Google Summer of Code! Last year, we had a few updates to the program that will continue for the 2023 program year. Our most noted change coming in 2023 is that we are expanding the program to be open to students and to beginners in open source software development. We are also continuing our increased flexibility in the length of the projects—offering 175 and 350-hour projects—and the ability to extend the program from the standard 12 weeks up to 22 weeks.

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 mentor organization and how to prepare your community (hint: have plenty of excited, dedicated mentors and well thought out project ideas!).

We welcome all types of organizations and are very eager to involve first-timers with a 2023 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, media, and more! Projects can range from being relatively new (about 2 years old) to well established projects that started over 20 years ago. We welcome open source projects big, small, and everything in between.

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

You can apply to be a mentor organization for GSoC starting today on the program site. The deadline to apply is February 7, 2023 at 18:00 UTC. We will publicly announce the organizations chosen for GSoC 2023 on February 22nd.

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, our new ‘Intro to Google Summer of Code’ video, 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 mentor organization applicants!

By Stephanie Taylor, Program Manager – Google Open Source Programs Office

Announcing Google Season of Docs 2023!



Google Season of Docs provides support for open source projects to improve their documentation and gives professional technical writers an opportunity to gain experience in open source. Together we raise awareness of open source, of docs, and of technical writing.

How does GSoD work?

Google Season of Docs allows open source organizations to apply for a grant based on their documentation needs. If selected, the open source organizations use their grant to directly hire a technical writer to complete their documentation project. Organizations have up to six months to complete their documentation project. At the end of the program, organizations complete their final case study which outlines 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 project case studies are published on the Season of Docs site at the end of the program.

Organizations: apply to be part of GSoD!

The applications for Google Season of Docs open February 15 for the 2023 cycle. We strongly suggest that organizations take the time to complete the steps in the exploration phase before the application process begins, including:
  • Creating a project page to gauge community and technical writer participant interest (see our project ideas page for examples).
  • Publicizing your interest in participating in GSoD through your project channels and adding your project to our list of interested projects on GitHub.
  • Lining up community members who are interested in mentoring or helping onboard technical writers to your project.
  • Brainstorming requirements for technical writers to work on your project (Will they need to be able to test code, work with video, or have prior experience with your project or related technologies?).
  • Reading through the case studies from previous Season of Docs participants.

Organizations: create your project page

Every Google Season of Docs project begins with a project page, which is a publicly visible page that serves as an overview of your documentation project. A good project page includes:
  • A statement of the problem your project needs to solve (“users on Windows don’t have clear guidance of how to install our project”).
  • The documentation that might solve this problem (“We want to create a quickstart doc and installation guide for Windows users”).
  • How you’ll measure the success of your documentation (“With a good quickstart, we expect to see 50% fewer issues opened about Windows installation problems.”).
  • What skills your technical writer would need (break down into “must have” and “nice to have” categories. “Must have: access Windows machine to test instructions”).
  • What volunteer help is needed from community members (“need help onboarding technical writers to our discussion groups”) and links to where the community can discuss the proposal.
  • Most importantly, include a way for interested technical writers to reach you and ask questions!

Technical writers: reach out to organizations early!

Technical writers do not submit a formal application through Google Season of Docs but those interested in working with accepted open source organizations can share their contact information now via the Google Season of Docs GitHub repository; or they may submit proposals directly to the organizations using the contact information shared on the organization project page. Check out our technical writer guide for more information. We suggest that interested technical writers read through the case studies from the previous Season of Docs participants to get an idea of the kinds of projects that have been accepted and what organizations have learned from working with technical writers.

General timeline

February 15 - March 24 Open source organizations apply to take part in Google Season of Docs

March 31

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

Technical writer hiring deadline
June 14

Organization administrators begin to submit monthly evaluations to report on the status of their project.
November 6 - 21

Organization administrators submit their case study and final project evaluation.
December 5

Google publishes the 2023 case studies and aggregate project data.

May 1, 2024 Organizations begin to participate in post-program followup surveys.
See the full program timeline for more details.

Join us

Explore the Google 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 Romina Vicente and Erin McKean – Google Open Source Programs Office

More voices = More Bazel

Takeaways from the BazelCon DEI lunch panel

In front of a standing-room-only lunch panel, Google’s head of Developer X strategy Minu Puranik asks us, “If there is one thing you want to change [about Bazel’s DEI culture], what would it be and why?”

We’d spent the last hour on three main themes: community culture, fostering trust, and growing our next generation of leaders. Moderated by Minu, our panel brought together a slate of brilliant people from underrepresented groups to give a platform to our experiences and ideas. Together with representatives and allies in the community, we explored methods for building inclusivity and sought a better understanding of the institutional and systemic barriers to increasing diversity.

Culture defines how we act, which informs who feels welcome to contribute. Studies show that diverse contributor backgrounds yield more and better results, so how do we create a culture where everyone feels safe to share, ask questions, and contribute? Helen Altshuler, co-founder and CEO of EngFlow, relayed her experience regarding some best practices:

“Having people that can have your back is important to get past the initial push to submit something and feeling like it’s ok. You don’t need to respond to everything in one go. Last year, Cynthia Coah and I gave a talk on how to make contributions to the Bazel community. Best practices: better beginners’ documentation, classifying GitHub issues as ‘good first issue,’ and having Slack channels where code owners can play a more active role.”

                    - Helen Altshuler, co-founder and CEO of EngFlow

Diving further, we discussed the need to make sure new contributors get positive, actionable feedback to reward them with context and resources, and encourage them to take the risk of contributing to the codebase. This encouragement of new contributors feeds directly into the next generation of technical influencers and leaders. Eva Howe, co-founder and Legal Counsel for Aspect, addressed the current lack of diversity in the community pipeline.

“I’d like to see more trainings like the Bazel Community Day. Trainings serve two purposes:

1. You can blend in, start talking to someone in the background, and form connections.
2. We can give a good first educational experience. It needs to be a welcoming space.”

                     - Eva Howe, Legal Counsel – Aspect Dev

    In addition to industry trainings, the audience and panel brought up bootcamps and university classes as rich sources to find and promote diversity, though they cautioned that it takes active, ongoing effort to maintain an environment that diverse candidates are willing to stay in. There are fewer opportunities to take risks as part of a historically excluded group, and the feeling that you have to succeed for everyone who looks like you creates a high-pressure environment that is worse for learning outcomes.

    To bypass this pipeline problem, we can recruit promising candidates and sponsor them through getting the necessary experience on the job. Lyra Levin, Bazel’s internal technical writer at Google, spoke to this process of incentivizing and recognizing contributions outside the codebase, as a way to both encourage necessary glue work, and pull people into tech from parallel careers more hospitable to underrepresented candidates. And Sophia Vargas, Program Manager in Google’s OSPO (Open Source Programs Office), also offered insight regarding contributions.

    “If someone gives you an introduction to another person, recognize that. Knowing a system of people is work. Knowing where to find answers is work. Saying I’m going to be available and responding to emails is work. If you see a conversation where someone is getting unhelpful pushback, jump in and moderate it. Reward those who contribute by creating a space that can be collaborative and supportive.”

                         - Lyra Levin, Technical Writer

    “Create ways to recognize non-code contributions. One example is a markdown file describing other forms of contribution, especially in cases that do not generate activity attached to a name on GitHub.”

    An audience member agreed that for the few PRs a positive experience is critical for community trust building: And indeed, open source is all about building trust. So how do we go about building trust? What should we do differently? Radhika Advani, Bazel’s product manager at Google, suggests that the key is to:

    “Make some amazing allies. Be kind and engage with empathy. Take your chances—there are lots of good people out there. You have to come from a place of vulnerability.”

                        - Radhika Advani, Bazel Product Manager

    Vargas also added some ideas for how to be an “amazing ally” and sponsor the careers of those around you, such as creating safe spaces to have these conversations because not everyone is bold enough to speak up or to ask for support since raising issues in a public forum can be intimidating. Making yourself accessible and providing anonymous forms for suggestions or feedback can serve as opportunities to educate yourself and to increase awareness of diverging opinions.

    An audience member stated that recognizing an action that is alienating to a member of your group—even just acknowledging their experience or saying something to the room—can be very powerful to create a sense of safety and belonging. And another said that those in leadership positions being forthright about the limits of their knowledge, gives people the freedom to not know everything.

    So to Minu’s question, what should we do to improve Bazel’s culture?

    Helen: Create a governance group on Slack to ensure posts are complying with the community code of conduct guidelines. Review how this is managed for other OSS communities.

    Sophia: Institutionalize mentorship; have someone else review what you’ve done and give you the confidence to push a change. Nurture people. We need to connect new and established members of the community.

    Lyra: Recruit people in parallel careers paths with higher representation. Give them sponsorship to transition to tech.

    Radhika: Be more inclusive. All the jargon can get overwhelming, so let’s consider how we can make things simpler, including with non-technical metaphors.

    Eva: Consider what each of us can do to make the experience for people onboarding better.

    There are more ways to be a Bazel contributor than raising PRs. Being courageous, vulnerable and open contributes to the culture that creates the code. Maintainers: practice empathy and remember the human on the other side of the screen. Be a coach and a mentor, knowing that you are opening the door for more people to build the product you love, with you. Developers: be brave and see the opportunities to accept sponsorship into the space. Bazel is for everyone.

    By Lyra Levin, Minu Puranik, Keerthana Kumar, Radhika Advani, and Sophia Vargas – Bazel Panel