opensource.google.com

Menu

Supercharging XLA-based inference: Announcing the launch of XLA Serving Engine

Thursday, November 5, 2026

Today we are excited to announce the launch of XLA Serving Engine (XSE), a general-purpose model export and inference runtime for the OpenXLA ecosystem, open-sourced under the Apache 2.0 license.

XLA Serving Engine logo

We created XLA Serving Engine to enable a “Train in Python, Serve in C++” workflow. Most ML engineers develop models using Python (with frameworks like JAX and PyTorch); however, some production serving environments do not allow Python due to operational and deployment complexity. XLA Serving Engine offers a solution by providing an API for engineers to export their ML models to an “XLA SavedModel” containing the StableHLO representation of their model’s function, which can then be loaded and executed by the XLA Serving Runtime.

This approach allows users to serve models (typically non-LLMs) directly in a C++ runtime, which enables high throughput at any scale and optimizes for low latency by removing the overhead of the Python interpreter. In our studies, we found that for short requests, XSE delivers 2–5x the throughput of the best Python server we could build, and 8–36x that of a straightforward one, while using 30–70% less CPU time per prediction and a quarter of the memory.

Last year, we began deploying core components of XLA Serving Engine as part of Google’s internal load-bearing, production serving infrastructure. Today, XSE serves over 6 million queries per second and powers some of Google's highest-volume online inference pipelines, including YouTube Shorts, Google Ads, Search, and parts of Gemini Omni, with plans to onboard more customers internally.

Having successfully scaled XSE to support the high-throughput workloads of our internal teams, we are now ready to bring this core piece of infrastructure to the wider ecosystem of hardware partners and Cloud TPU users. We designed XLA Serving Engine to be self-contained and modular, so users can deploy it as a standalone inference engine or plug it into their more complex serving solutions.

Core production-ready features

  • Python-Free Serving: XSE enables a “Train in Python, Serve in C++” workflow via the intermediary compiled XLA SavedModel serialization format. In our studies, we found that XSE delivers 2–5x the throughput of a pure Python server.
  • Low-latency execution: The XLA Serving Runtime wraps PJRT directly and optimizes the model using the XLA compiler. This eliminates Python runtime overhead and the global interpreter lock. XSE is C++ native, which means one process is capable of using all eight cores.
Figure 1: Throughput under latency target (QPS vs. p99 latency target in ms)
Figure 1: Throughput under latency target
  • Orbax Checkpointing Integration: XLA SavedModel stores JAX model computations as StableHLO and uses Orbax checkpoint to store the weights.
  • Flexible Scale: Supports both single-host and multi-host serving by leveraging PJRT.
  • Performance Parity: XSE preserves the performance of the model’s forward function (including kernel optimizations). Hand off your model to XLA Serving Engine with confidence that performance will be identical to its training environment.
  • Docker Packages: We provide a suite of Docker images that are tested on CPU, GPU, and TPU and expose simple gRPC APIs for calling your model.

Customer testimonials and partner use cases

Our Private Preview partners have been actively leveraging XLA Serving Engine to bring their deep learning stacks to production. Here is a selection of private preview customers (alphabetized) to showcase the diversity of uses:

Arm: Performance Parity on Arm Neoverse platforms

Our work with Arm has proven the production capabilities of JAX and XLA for training and serving on Arm-based CPUs:

“As AI inference scales, software optimization is critical to delivering performance and efficiency across diverse workloads. Through our collaboration with Google and contributions to OpenXLA, we’ve optimized the XLA CPU backend and serving runtime for vision, embedding and recommendation workloads on Arm Neoverse-based platforms, including Google Cloud Axion.”

— Ian Bratt, Vice President of ML Technology and Fellow, Arm

Intel: Native JAX on Xeon server CPUs

We have also been partnering with Intel to showcase the power of Intel’s optimized compute:

“Our partnership with Google showcases the XLA Serving Engine (XSE) on Intel® Xeon® processors, delivering native, high-performance JAX inference accelerated by Intel® AMX. With XSE, enterprises get out-of-the-box performance across Vision, Recommendation, and LLM workloads — and the flexibility to serve them efficiently wherever their business runs, from cloud to edge to on-prem.”

— Bill Pearson, Vice President of Data Center and AI software, Intel

Moloco: Scaling advertising and recommenders

“To support our demand-side platform (DSP) processing over 650 billion daily inferences and peaking at 10.5 million QPS, we needed an inference runtime that could match our massive scale. XLA Serving Engine is the high-performance, C++-based JAX serving solution we’ve been waiting for that keeps us framework agnostic and complements our Cloud TPU Trillium investments.”

— Kunal Kukreja, Staff Machine Learning Engineer, Moloco

What’s next

  • Torch Support: We plan to integrate with TorchTPU, allowing PyTorch users to export to an XLA SavedModel to serve their models on TPUs in C++.
  • Ahead-of-Time (AOT) Compilation: We are working on rolling out AOT compilation to our internal users before bringing this feature to external users. AOT compilation will reduce cold-start time by offering users the ability to compile their models offline (on CPU) for their target serving hardware.
  • C++ Data Preprocessing: We are offering a C++ based preprocessor for users who want to combine their data processing with their model’s graph in C++.

Limitations

XSE is a lightweight, one-shot inference engine. For large autoregressive language models with long context lengths, we recommend popular projects such as vLLM or SGLang, which benefit from LLM-specific memory management techniques.

Get started today

Ready to streamline your JAX production pipeline?

Acknowledgements

Thank you to everyone who contributed to XLA Serving Engine, including but not limited to the following individuals:

Ashish Agarwal, MD Faijul Amin, Carlos Araya, Isha Arkatkar, Sagun B, Ashok Bhat, Xevi Miró Bruix, Chris Chan, Ray Chen, Chen Cheng, Hyun Min Choi, Gauri Deshpande, Tiffany Dong, Sayce Falk, Happy Gao, Vaibhav Gurunathan, Michael Hudgins, He Jiang, Leon Kennedy, Young Seok (Tony) Kim, Penporn Koanantakool, Kunal Kukreja, Younghee Kwon, Shawn Lu, Xevi Miró Bruix, Sachin Muradi, César Naranjo, Pat Notz, Adam O’Brien, Olivia Qin, AG Ramesh, Shubha Rao, Mayank Raunak, Crefeda Rodrigues, Gassan Salama, Oleg Shaldybin, Brian Seung, Juanli Shen, Prairie Sims, Monica Song, Anne Stern, Quoc Truong, Armando Ugalde Velasco, Jess Wiser, Siqiao (James) Wu, Qinglan Xiang, Yunjie Xu, Jeffrey Yoo, Hyungsuk Yoon, and Wangyuan Zhang.

GKE Workspaces: Your notebook, on Google's AI infrastructure

Wednesday, November 4, 2026

If you're an ML engineer or researcher, the GPUs and TPUs you need increasingly live on Kubernetes, but Kubernetes should be an invisible layer. While your platform team sets up the GKE cluster and manages accelerator capacity and reservations, your job is to train and ship models—not to manage Kubernetes infrastructure.

Today we're introducing GKE Workspaces, a self-hosted AI/ML development platform for Google Kubernetes Engine, built on the open source Kubeflow Workspaces project. Deployed on your team's GKE cluster, it provides a dedicated web dashboard where you can pick an IDE and a machine, and start coding on cloud accelerators in minutes.

Screencast of signing into the GKE Workspaces UI and launching a JupyterLab workspace on cloud accelerators.

Why Kubeflow Workspaces

Kubeflow Workspaces gives every researcher a personal, persistent development environment on shared cluster hardware.

  • Self-service, in a few clicks. Sign in to your team's Workspaces web UI, choose JupyterLab or in-browser VS Code, pick an environment, and select a hardware size such as "Small CPU", "GPU", or "TPU". Researchers don't need Google Cloud Console access, YAML, or command-line setup.
  • Your work persists. Each workspace mounts its own home directory on a dedicated, encrypted Persistent Disk in your Google Cloud project—isolated to that workspace, so your files, notebooks, and installed packages stay safe across restarts, pauses, and machine changes.
  • Guardrails set by your platform team. Admins curate the approved images and hardware options, and decide which machines, reservations, and capacity types (such as on-demand or Spot) back them. Researchers only see choices that work.
  • Open source and portable. Workspaces is part of the Kubeflow community, empowering you with the freedom and flexibility of a fully open source notebook ecosystem.
  • Upstream integration and open licensing. GKE Workspaces builds directly on Kubeflow Workspaces with key enhancements for GKE environments—including standalone deployment without Istio dependencies, integrated authentication token flows, and stateful GPU/CPU pause and resume capabilities. Both GKE Workspaces and upstream Kubeflow Workspaces are released under the Apache 2.0 open source license, and we are actively working with the Kubeflow community to upstream these features.

What's unique about GKE Workspaces

GKE Workspaces brings Kubeflow Workspaces together with capabilities that are only available on Google Cloud.

1. Pause and resume—without losing your state

You've spent an hour loading a large model into GPU memory and building up results across notebook cells. Now it's time to go home. Normally you have two bad options: shut down and lose everything, or leave it running and pay for an idle GPU overnight.

With GKE Workspaces, you just pause by clicking a button from the Workspaces Dashboard. Built on Pod Snapshots, GKE takes a snapshot of your running notebook—including variables in memory and models loaded on the GPU—saves it to Cloud Storage, and releases the hardware so you stop paying. When you resume, you pick up exactly where you left off. Workspaces can also be paused automatically after a period of inactivity.

Screencast of stateful pause and resume via GKE Pod Snapshots preserving GPU memory.

2. An easy on-ramp to Cloud TPUs

Moving from a quick experiment to large-scale training on TPUs used to mean switching tools at every step. GKE Workspaces keeps you in the same notebook the whole way, with both JAX and PyTorch:

  1. Prototype on a single TPU chip, just like you would on a GPU.
  2. Scale to multiple chips on one machine by choosing a bigger hardware option.
  3. Scale out to multi-host TPU slices by sending the same training function from your notebook to a larger slice. Logs stream back to your notebook, and the TPUs are released as soon as the job finishes.
Screencast scaling a notebook workload from a single Cloud TPU chip to a multi-host TPU slice.

3. Use your local coding agents with cloud accelerators

Prefer using your own AI coding agents and editors locally? You can easily bridge them to cloud compute. In the Workspaces web UI, generate a short-lived, revocable link to run your notebooks and agent-generated code on a remote GPU or TPU. Traffic is secured over HTTPS via Google Identity-Aware Proxy and the cluster's access proxy, checking permissions on every request—so no SSH keys, local tunnels, or cluster credentials ever sit on your laptop.

Screencast connecting a local coding agent to a remote TPU workspace over Identity-Aware Proxy HTTPS.

4. A launchpad for distributed work

Your workspace doesn't have to be big to drive big jobs. From a small, inexpensive CPU notebook you can process data with Spark, launch multi-host training, serve your model, and scale Ray clusters—all from Python. Built-in Cloud Storage access, with no keys to manage, makes it easy to pass data between each step.

Screencast coordinating Spark and Ray distributed jobs from a lightweight CPU notebook.

5. A portal to safe elastic sandboxes for coding subagents

Running a fleet of coding agents directly on your local machine can drain your battery, expose sensitive files or credentials to agent-executed code, and halt progress as soon as you close your laptop. From a standard GKE Workspace, you can safely task your favorite coding agent to hand off parallel work—such as resolving failing tests across a repository—to background subagents. Crucially, while your primary workspace operates as a full-featured environment, these subagents are isolated within lightweight, in-cluster sandboxes using providers like Agent Substrate, requiring zero local setup. Each subagent executes independently in its own sandbox on shared cluster nodes, continues running even when you log off, snapshots to Cloud Storage at zero compute cost while idle, and outputs a clean patch for your review and merge.

Screencast spawning isolated coding subagents inside lightweight Agent Substrate cluster sandboxes.

6. Lightweight and secure by default

GKE Workspaces runs on its own on GKE Standard or Autopilot—you don't need to install the full Kubeflow platform. Users sign in with their Google accounts, traffic is encrypted with Google-managed certificates, and each team's work is isolated from the others.

Get started

GKE Workspaces lets ML teams focus on models, not infrastructure: one-click development environments, stateful pause and resume, a smooth path to Cloud TPUs, and the power of GKE behind every notebook.

Ask your platform team to deploy it using the GKE deployment guide, and learn more about the upstream project at Kubeflow Workspaces. We welcome feedback and contributions for both Apache 2.0-licensed projects.

Introducing Three-Live: turning AI-generated Three.js into interactive 3D, AR, and WebXR across web and mobile

Tuesday, November 3, 2026

Want to add AI-generated 3D or XR to your web or mobile app? Unsure how to get started? That’s why we created the open source cross-platform project Three-Live—written entirely by Google Antigravity, in partnership with one former software engineer turned product manager. (Three-Live is not an officially supported Google product.)

You can think of Three-Live as a simple, unofficial companion to the more capable and feature-rich XR Blocks, Android XR’s web-based cross-platform framework for XR. The goal of Three-Live is to make it easy to get started with 3D and XR that’s AI-authored in Three.js. Three-Live combines the familiar developer experience of <model-viewer> and native mobile libraries with a sandboxed compiler for on-device or server-side compilation of untrusted LLM-generated JavaScript. Large language models (LLMs) have gotten remarkably good at writing software, and that includes generating 3D code in procedural Three.js JavaScript that describes objects, materials, lighting, and animations. But runtime AI-generated code is not trusted, and requires security sandboxing for safe execution. Also, mobile devices provide native support for 3D and XR rendering, and forcing them to run a webview limits the performance.

Screenshot of the Three-Live interactive studio running in a browser, showing live procedural Three.js controls and a real-time PBR 3D scene with metallic and emissive materials.

Today, we are excited to release Three-Live (v1.0.0, Developer Preview) under the Apache 2.0 license. It’s a lightweight, cross-platform open source library and on-device compiler that bridges the gap between AI-generated Three.js code and high-performance 3D, AR, and WebXR rendering across web, Android, and iOS.

Flowchart showing a procedural Three.js script entering the on-device Three-Live sandbox and compiling in milliseconds into binary glTF 2.0 (GLB) and USDZ for WebGL2/WebXR on the web, Google Filament and Scene Viewer on Android, and RealityKit and Quick Look on iOS.

How Three-Live works

Rather than use Three.js as a browser-only rendering loop, Three-Live treats a declarative subset of the Three.js API as a universal, portable scene description language:

Sandboxed execution with strict resource quotas: On the web, untrusted scripts execute inside an isolated Web Worker (with an optional opaque-origin sandboxed <iframe> tier) where network primitives (fetch, XMLHttpRequest, WebSocket, dynamic import()) are stripped before a single line of user code runs. On Android, iOS, macOS, and the command line, scripts execute inside an embedded Rust compiler powered by the Boa ECMAScript engine. Both runtimes enforce hard execution timeouts and geometry quotas (capping vertices, triangles, meshes, and procedural textures) so runaway scripts cannot freeze the host application.

Fast on-device compilation to GLB and USDZ: As the script constructs geometries, physically based rendering (PBR) materials, procedural canvas textures, hierarchy groups, and keyframe animations, Three-Live serializes the resulting scene graph directly into standard binary glTF 2.0 (.glb) and uncompressed Apple USDZ (.usdz) byte buffers in memory—typically in two to five milliseconds.

Platform-optimized rendering: Because the output is a standard binary 3D asset coupled with declarative animation bindings, each platform renders it using its built-in graphics pipeline:

  • Web (three-live and xr-live): A custom zero-dependency WebGL2 PBR renderer and <three-live> web component—inspired by <model-viewer>—complete with procedural Studio HDRI reflections, screen-space ambient occlusion (SSAO), bloom, shadow mapping, and a single-click AR handoff to Android Scene Viewer, Apple AR Quick Look, or immersive WebXR. At launch, the standard bundle with sandboxed scripting and AR is about 45 KB gzipped, and the xr-live spatial computing suite is about 55 KB.
  • Android (com.google.threelive:compiler): A Kotlin SDK and multi-architecture JNI library (arm64-v8a, armeabi-v7a, x86_64) that compiles Three.js strings on a background coroutine straight into ByteBuffer assets for Google Filament ModelViewer and Scene Viewer AR.
  • iOS and macOS (ThreeLiveCompiler): A Swift Package and five-slice XCFramework that compiles Three.js scripts on-device for RealityKit ModelEntity and ARQuickLookPreviewController.
Screenshot of the XR-Live Spatial Computing Playground demonstrating six-degrees-of-freedom (6DoF) spatial traits, live procedural Three.js source editing, and spatial DOM UI projection.

Declarative 3D and spatial WebXR in HTML

On the web, adding an interactive, AI-generated 3D model with built-in orbit controls and mobile AR support requires just a single HTML custom element:

<script src="/?url=https%3A%2F%2Fcdn.jsdelivr.net%2Fnpm%2Fthree-live%401.0.0%2Fdist%2Fthree-live.min.js"></script>
<three-live allow-client-scripts camera-controls ar shadow-intensity="1" environment-image="studio">
  <script type="text/three-live">
    const knot = new THREE.Mesh(
      new THREE.TorusKnotGeometry(0.6, 0.2, 128, 32),
      new THREE.MeshStandardMaterial({
        color: 0x4285f4,
        metalness: 0.85,
        roughness: 0.15
      })
    );
    scene.add(knot);
    // Baked into a looping glTF animation (4 seconds by default).
    scene.userData.animate = (t) => {
      knot.rotation.y = t * (Math.PI / 2);
    };
  </script>
</three-live>

The script runs in the sandbox described above. Because inline scripts are client-modifiable, they require the explicit allow-client-scripts opt-in; server-generated scripts can be loaded with script-src instead.

Only need to display existing models? The viewer-only build drops the script compiler and AR handoff and weighs about 23 KB gzipped at launch—tiny compared to the full Three.js library. The Three-Live viewer focuses on fast-loading PBR display, orbit controls, and glTF animation:

<script src="/?url=https%3A%2F%2Fcdn.jsdelivr.net%2Fnpm%2Fthree-live%401.0.0%2Fdist%2Fthree-live-viewer.min.js"></script>
<three-live src="chair.glb" camera-controls auto-rotate></three-live>

For spatial computing headsets and mobile AR browsers, the companion xr-live package adds <xr-live> and <xr-scene>, enabling six-degrees-of-freedom (6DoF) hand-tracking gestures (pinch, grab, two-hand scale), spatial DOM projection, and real-time voice- or text-to-3D object synthesis inside an active WebXR session.

Try it today

We built Three-Live to make 3D and spatial computing accessible to web, mobile, and AI developer communities without requiring complex 3D modeling pipelines. You can explore the project and try it right in your browser:

Three-Live is currently in Developer Preview, and we welcome feedback, bug reports, and pull requests from open source developer communities on GitHub.

This Week in Open Source for October 30, 2026

Friday, October 30, 2026

Light-theme Google Open Source banner reading 'This Week in Open Source' above four connected circular icon medallions representing upcoming events (calendar), open source reads (globe), code and tutorials (laptop with code brackets), and community (people).

A look around the world of open source

Right before Halloween weekend, it feels fitting to ask what actually haunts open source communities right now—from supply-chain ghosts lurking in commit histories and the hidden cost of maintaining isolated "zombie" forks to models wearing open source costumes without sharing what is under the mask. Across this week's reads, maintainers, researchers, and engineers share how they are keeping the lights on: setting clear community boundaries for AI contributions, wiring human sign-off and cost guardrails directly into automated workflows, and co-building open infrastructure across hardware stacks. Technology only serves people when the humans doing the work stay in control of the machinery—and transparent, inspectable tools remain our best defense against things that go bump in the night.

Upcoming events

🗓️ November 2026

  • Open Source in Finance Forum (OSFF) New York (November 4–5, 2026) – New York, New York, USA. Dedicated industry conference examining open source compliance, supply-chain security, and collaborative innovation across regulated financial institutions.
  • SeaGL (Seattle GNU/Linux Conference) 2026 (November 6–7, 2026) – Seattle, Washington, USA & Virtual. Free, grassroots technical summit dedicated to spreading awareness and knowledge of free and open source software, hardware, and culture.
  • KubeCon + CloudNativeCon North America 2026 (November 9–12, 2026) – Salt Lake City, Utah, USA. The Cloud Native Computing Foundation's (CNCF) flagship conference uniting adopters and maintainers around Kubernetes and containerized distributed infrastructure—featuring over 35 sessions and keynotes from Googlers including Abdel Sghiouar, Jago Macleod, Tim Hockin, Kaslin Fields, John Belamaric, Dawn Chen, Janet Kuo, Benjamin Elder, Antonio Ojea, Lior Lieberman, Michelle Au, and Braydon Kains across Kubernetes Special Interest Groups (SIGs), etcd, containerd, Gateway API, Common Expression Language (CEL) admission policies, and agent sandboxes, plus the Google-sponsored Community Hub.
  • SFSCON (South Tyrol Free Software Conference) 2026 (November 13–14, 2026) – Bolzano, Italy. One of Europe's longest-running free software conferences bringing together public-sector decision-makers and developers to advance digital sovereignty and open infrastructure.

🗓️ December 2026

  • Yocto Project Virtual Summit 2026.12 (December 1–3, 2026) – Virtual. Community summit for embedded Linux engineers and maintainers building custom, reproducible Linux distributions across edge and Internet of Things (IoT) hardware.
  • Open Source Summit Japan 2026 (December 7–9, 2026) – Tokyo, Japan. The Linux Foundation's premier Asia-Pacific conference connecting open source developers, kernel maintainers, and enterprise leaders across cloud, embedded Linux, and open AI—featuring a keynote by Google's Kaz Sato on building agents on open standards alongside sessions from Googlers Tanya Sharma, Tarun Sahu, and Anurag Sinha.
  • Open Compliance Summit 2026 (December 10–11, 2026) – Tokyo, Japan. Specialized gathering uniting legal, security, and Open Source Programs Office (OSPO) practitioners around OpenChain, Software Package Data Exchange (SPDX), software bills of materials (SBOMs), and global open source supply-chain compliance.

🗓️ January 2027

  • Free and Open Source Software Developers' European Meeting (FOSDEM) 2027 (January 30–31, 2027) – Brussels, Belgium. Europe's largest free, volunteer-organized gathering for free and open source software developers at the Université libre de Bruxelles—with calls for participation now open across 77 community developer rooms and main-track proposals open through November 16.

Open calls for proposals (CFPs)

  • Free and Open Source Software Developers' European Meeting (FOSDEM) 2027 (Event: January 30–31, 2027 – Brussels, Belgium) – Main-track CFP deadline: November 16, 2026 (developer room calls for participation open across 77 accepted community developer rooms, with devroom schedules published by December 7, 2026).
  • AtmosphereConf 2027 (Event: April 29 – May 2, 2027 – Amsterdam, The Netherlands) – Round 1 CFP deadline: November 30, 2026 (Round 2: January 11 – February 14, 2027). Community conference uniting developers, researchers, and creators building on the Authenticated Transfer Protocol (AT Protocol), open social web standards, and decentralized agent substrates across Build, Create, Inform, and Govern tracks.

Open source reads and links

Which of these stories will you be chatting about at your next meetup or conference? Let us know! Share with us on our @GoogleOSS X account or our @opensource.google Bluesky account.

This Week in Open Source for October 23, 2026

Friday, October 23, 2026

Light-theme Google Open Source banner reading 'This Week in Open Source' above four connected circular icon medallions representing upcoming events (calendar), open source reads (globe), code and tutorials (laptop with code brackets), and community (people).

A look around the world of open source

What actually sustains an open source community when the cost of generating code drops toward zero, while the human labor required to review, govern, and secure it stays just as demanding? Across this week's reads, researchers, legal scholars, and builders examine the tension between automated volume and human stewardship—from public-infrastructure policy and maintainer bandwidth to provenance transparency, copyright law, and compact models running entirely on local hardware. Because software only serves people when human judgment remains in the loop, protecting maintainer agency and keeping project doors open to real newcomers matter more than ever.

Upcoming Events

🗓️ October 2026

  • Open Source AI Week 2026 (October 19–24, 2026) — San Francisco Bay Area, California, USA. Now in its final stretch across the Bay Area alongside PyTorch Conference, this decentralized week of community meetups, workshops, and hackathons—with Google DeepMind and Gemma as Platinum Sponsor—wraps up this weekend with tonight's Open Source AI Awards Night (Friday, October 23, 5:00–10:00 PM PT at Fort Mason, San Francisco) and tomorrow's Google Gemma Hardware Hackathon at AGI House (Saturday, October 24, 10:00 AM–5:00 PM PT in Hillsborough, CA).
  • AGNTCon + MCPCon North America 2026 (October 22–23, 2026) — San Jose, California, USA. Happening this week, this Linux Foundation and Agentic AI Foundation (AAIF) conference focuses on building and scaling production agentic systems with open standards—featuring keynotes by Google's Rao Surapaneni, Sarah Drasner, and Chi Wang, plus sessions from Googlers Vishal Motwani & Alan Blount (on Agent-to-User Interface [A2UI]), Junjie Bu (on interoperable agent discovery), Amit Handa (on agentic commerce), Dominic Farolino (on Model Context Protocol [MCP] Apps + WebMCP), and Prerna Kakkar & Kurtis Van Gent (on EvalBench).
  • GitHub Universe 2026 (October 28–29, 2026) — San Francisco, California, USA & Virtual. Annual global developer gathering highlighting open source workflows, collaborative security, and multi-model AI-assisted software engineering.

🗓️ November 2026

  • Open Source in Finance Forum (OSFF) New York (November 4–5, 2026) — New York, New York, USA. Dedicated industry conference examining open source compliance, supply-chain security, and collaborative innovation across regulated financial institutions.
  • SeaGL (Seattle GNU/Linux Conference) 2026 (November 6–7, 2026) — Seattle, Washington, USA & Virtual. Free, grassroots technical summit dedicated to spreading awareness and knowledge of free and open source software, hardware, and culture.
  • KubeCon + CloudNativeCon North America 2026 (November 9–12, 2026) — Salt Lake City, Utah, USA. The Cloud Native Computing Foundation's (CNCF) flagship conference uniting adopters and maintainers around Kubernetes and cloud-native infrastructure—featuring over 35 sessions and keynotes from Googlers including Abdel Sghiouar, Jago Macleod, Tim Hockin, Kaslin Fields, John Belamaric, Dawn Chen, Janet Kuo, Benjamin Elder, Antonio Ojea, Lior Lieberman, Michelle Au, and Braydon Kains across Kubernetes Special Interest Groups (SIGs), etcd, containerd, Gateway API, Common Expression Language (CEL) admission policies, and agent sandboxes, plus the Google-sponsored Community Hub.
  • SFSCON (South Tyrol Free Software Conference) 2026 (November 13–14, 2026) — Bolzano, Italy. One of Europe's longest-running Free Software conferences bringing together public-sector decision-makers and developers to advance digital sovereignty and open infrastructure.

🗓️ December 2026

  • Yocto Project Virtual Summit 2026.12 (December 1–3, 2026) — Virtual. Community summit for embedded Linux engineers and maintainers building custom, reproducible Linux distributions across edge and Internet of Things (IoT) hardware.
  • Open Source Summit Japan 2026 (December 7–9, 2026) — Tokyo, Japan. The Linux Foundation's premier Asia-Pacific conference connecting open source developers, kernel maintainers, and enterprise leaders across cloud, embedded Linux, and open AI, including sessions from Google engineers such as Anurag Sinha.
  • Open Compliance Summit 2026 (December 10–11, 2026) — Tokyo, Japan. Specialized gathering uniting legal, security, and Open Source Programs Office (OSPO) practitioners around OpenChain, Software Package Data Exchange (SPDX), software bills of materials (SBOMs), and global open source supply-chain compliance.

Open Source Reads and Links

  • [Blog] Open Enables a Lot: The OSI at UNGA81 — At the 81st United Nations General Assembly (UNGA81), the Open Source Initiative (OSI) hosted a panel featuring Google OSPO’s Amanda Casari alongside policy and academic leaders to explore how open source reshapes public infrastructure. Framed by Duane O’Brien’s takeaway that “open by itself does very little, but enables a lot,” what shared scaffolding is needed to turn open licenses into real public value?
  • [Paper] “AI Slop is DDoSing Open Source”: Understanding the Impact of AI-Generated Contributions on Open Source Sustainability — After hearing questions about AI-generated pull requests online and at conferences for a while now, I came to Google and Oregon State University’s study of 294 repositories looking for what solutions are actually working. Surveying 11 remediation strategies as first-time contributor merge rates drop 18.18%, how can communities filter synthetic noise without closing the door on newcomers?
  • [Article] Who’s Writing Open Source Code? — Have AI coding agents actually taken over open source repositories, or is human authorship still the norm? Auditing 24,000 commits across 15 critical C infrastructure projects from the first half of 2026, RedMonk’s Stephen O’Grady finds that fewer than 1% carry explicit machine co-author or agent markers—raising a pressing question: how should open source communities build cultural norms around provenance transparency?
  • [Article] The copyright problem with AI-generated code — In creative circles online, people often argue that prompting AI makes you closer to an art patron or a music producer than the artist—but I had never thought about the copyright realities for software. Since open source licenses rely on human copyright, FreeDOS founder Jim Hall asks a foundational question: can you even license code you didn’t actually author?
  • [Blog] Launching an opt-in vulnerability-finding service for open-source software — Inspired by Google’s OSS-Fuzz, Anthropic’s new opt-in OSS Scanner offers open source maintainers free, periodic security audits complete with test reproducers and suggested patches running in isolated Docker environments. Giving resource-constrained projects direct access to frontier vulnerability detection is a welcome step forward—how can we keep expanding shared security tooling to help upstream maintainers catch complex bugs early?
  • [Blog] Do Agent Skills Help? I Ran 72 Trials to Find Out — Evaluating whether AI agent skills beat prompt-and-guess baselines, Karl Weinmeister ran 72 sandboxed trials across 12 scenarios using Harbor and SkillEvaluator—complementing Google’s open source skill-reach suite for catching description collisions across harnesses like AAIF’s Goose and Claude Code. Together, they raise a practical question for maintainers: how do we test both skill discovery and execution quality?
  • [Blog] Make the PDS Your Own: Customization and Metrics — The Authenticated Transfer Protocol (AT Protocol) is one of my major interests right now, so seeing how people are making its foundations work in practice is fascinating. The latest Reference Personal Data Server (PDS) release adds custom OAuth login branding, 300MB video blobs, and direct-to-Prometheus OpenTelemetry metrics in under 1GB of RAM—what other operational building blocks will help small teams self-host federated infrastructure?
  • [Article] Google’s new 4B Gemma model cuts speaker-labelling errors on all four benchmarks, two barely — Automated transcripts still struggle when speakers talk over one another in meetings and interviews. Built on Google’s Gemma 4 E4B and open source DiarizationLM framework, the community-trained Apache 2.0 DiarizationLM-Gemma-4-E4B-v1 approaches speaker diarization as a lightweight post-processing pass over existing transcripts—beating an 8B Llama 3 baseline at half the size. Where can compact local models clean up brittle pipeline handoffs in your own workflows?
  • [Blog] Open-Source Voice AI runs entirely on ESP32-S3 — Some of the most inspiring moments in open source come from individual builders experimenting at the edges of hardware constraints. Anankush Pandit’s GNU General Public License (GPL) Ivy AI packs wake-word detection, speech recognition, a 4-bit language model, and speech synthesis onto an ESP32-S3 microcontroller with just 8MB of pseudo-static RAM (PSRAM)—making us wonder what other everyday devices could run entirely offline?

Which of these stories will you be chatting about at your next meetup or conference? Let us know! Share with us on our @GoogleOSS X account or our @opensource.google Bluesky account.

.