Google Open Source Blog

Kubernetes Python client gets a modern overhaul for the AI/ML era

2026-11-12T11:30:00.000-08:00

by Yu Liao, Haowei Cai, and Federico Bongiovanni, Google Cloud Kubernetes Engineering & SIG API Machinery

When you train a large language model with Kubeflow, orchestrate distributed compute with Ray on Google Kubernetes Engine (GKE), serve inference traffic with KServe, or schedule thousands of ML pipeline pods with Apache Airflow, two technologies almost always meet under the hood: Python and Kubernetes.

Python is the undisputed lingua franca of artificial intelligence and machine learning. Kubernetes is the de facto operating system for AI infrastructure—scheduling GPUs and TPUs, orchestrating distributed training jobs, and scaling model serving endpoints. Connecting these two worlds is the official Kubernetes Python client (kubernetes-client/python).

Second only to Kubernetes's in-tree Go client (client-go) in popularity, the Kubernetes Python client is downloaded more than 73 million times per month on PyPI (~1.7 million times a day) and has earned over 7,500 GitHub stars.

Yet for the past several years, this critical bridge between Python and Kubernetes has operated in low-maintenance mode. As AI/ML workloads have exploded in scale and complexity, the gap between what modern AI infrastructure demands and what the legacy Python client was built to deliver has become impossible to ignore.

Today, we're sharing how Google Cloud engineers are partnering with open source contributors in Kubernetes SIG API Machinery to modernize the official Kubernetes Python client for the AI/ML era.

The historical problem: Legacy machinery meets hyperscale AI

As AI/ML clusters grew from dozens of nodes to 50,000-node hyperscale environments, the limitations of the Python client's aging architecture began surfacing as real-world production bottlenecks:

Frozen on a decommissioned code generator: Up through Kubernetes 1.35, the Python client generated its ~400,000 lines of API and model code using OpenAPI Generator v4.3.0 (python-legacy)—a generator version that was deprecated in 2020 and completely removed from the upstream OpenAPI Generator project in May 2022. Staying pinned to v4.3.0 meant the client accumulated DeprecationWarning debt across newer Python releases, struggled with modern dependency resolution alongside PyTorch and TensorFlow, and couldn't easily receive upstream generator bug fixes.
Synchronous-only execution in an asyncio world: Modern Python web frameworks, inference servers, and orchestrators have overwhelmingly shifted to asyncio to handle high-concurrency I/O without being bottlenecked by Python's Global Interpreter Lock (GIL). Because the official client lacked native asyncio support from the start, users were forced to turn to community clients like kubernetes-asyncio or third-party clients (kr8s, lightkube).
Missing controller primitives (SharedInformer): In Go, controllers use SharedInformer to maintain a local, event-driven cache of cluster resources without repeatedly polling kube-apiserver. Without an equivalent primitive in Python, applications watching thousands of training pods or custom resources often hammered the API server or ran into watch disconnects.
Slow model deserialization and HTTP/1.1 transport limits: In large clusters, listing pods or nodes in Python could take 30+ seconds due to excessive model reconfiguration during JSON deserialization (issue #1921). Combined with an underlying urllib3 transport layer restricted to HTTP/1.1, Python workloads missed out on the HTTP/2 multiplexing, flow control, and binary framing that make client-go fast at scale.

A principled approach: Built for AI/ML, not 1:1 parity

When we set out to modernize the Kubernetes Python client, we established two guiding principles to ensure our engineering investments deliver the highest possible return for the community:

Target high-impact gaps, not 1:1 client-go parity: client-go is the in-tree Kubernetes client used by the control plane itself (kube-controller-manager, kube-scheduler, and in-tree controllers). Attempting to replicate every long-tail client-go feature in Python would yield diminishing returns. Instead, we focus strictly on the primitives Python developers and operators actually need in production.
Prioritize AI/ML workload requirements: Because AI/ML training, inference, and batch frameworks are the primary drivers of Python on Kubernetes today, every architectural improvement—from async concurrency and CRD ergonomics to large-cluster list performance—is prioritized through the lens of AI/ML scale.

How we're modernizing the Kubernetes Python client

Our roadmap focuses on three technical pillars: Machinery, Features, and Performance.

1. Machinery: Upgrading to OpenAPI Generator v7.20+

Every improvement to the Python client starts with its code generation pipeline (kubernetes-client/gen). Over the past few years, multiple community attempts to migrate off the decommissioned v4.3.0 python-legacy generator stalled due to the sheer scale of template and schema changes across hundreds of Kubernetes API models.

We are actively driving the migration to OpenAPI Generator v7.20.0+ and establishing continuous tracking with upstream generator releases. Completing this foundational upgrade:

Replaces dead python-legacy templates with actively maintained v7+ Python code generation.
Modernizes type annotations and packaging metadata, easing pip dependency resolution alongside heavy ML frameworks.
Unlocks the ability to contribute performance and serialization fixes directly to upstream OpenAPI Generator templates.

2. Features: Native `asyncio`, Shared Informers, and WebSocket v5

To prevent ecosystem fragmentation and give Python developers first-class Kubernetes primitives out of the box, we are bringing three major capabilities to the official client:

Official asyncio support: Rather than forcing developers to choose between the official synchronous client and third-party async libraries, we are introducing official asyncio support directly into kubernetes-client/python. Async-first ML orchestrators, FastAPI-based model control planes, and notebooks will be able to issue concurrent, non-blocking Kubernetes API calls natively.
Shared Informers (kubernetes-client/python#2515): We are bringing the SharedInformer pattern to the Python client. With built-in list-watch caching, automatic reconnection, and resource event handlers (on_add, on_update, on_delete), Python controllers and AI job managers can monitor cluster state and Custom Resources (TrainJob, RayCluster, InferenceService) with a fraction of the memory footprint and API server load.
WebSocket v5 streaming (KEP-4006, kubernetes-client/python#2486): As upstream Kubernetes transitions remote command streaming (exec, attach, port-forward) away from legacy SPDY to standard WebSockets via the v5.channel.k8s.io subprotocol, we are adding native WebSocket v5 channel support so interactive debugging and remote job execution work seamlessly against modern control planes.

3. Performance: Slashing deserialization overhead

For AI/ML platforms operating on multi-thousand-node clusters, client performance is an availability requirement. Our performance track targets the largest bottlenecks in Python client execution:

Eliminating model reconfiguration overhead: When deserializing large JSON responses (such as listing tens of thousands of Pods across a training cluster), the legacy generated model layer repeatedly instantiates and reconfigures schema validation objects (issue #1921). With the move to OpenAPI Generator v7+, we are revamping model initialization so large cluster queries deserialize in a fraction of the time.

What's next and how to get involved

The intersection of Python and Kubernetes is where modern AI infrastructure is built. By modernizing the code generation machinery, adding native asyncio and SharedInformer primitives, and closing the deserialization performance gap, we aim to give every ML engineer and platform builder a fast, reliable, and Pythonic official client—whether they are running a single notebook experiment or orchestrating a 50,000-node GKE training fleet.

This effort is happening in the open under Kubernetes SIG API Machinery, and we welcome feedback, use cases, and contributions from the community:

Explore the repository and roadmap: Check out kubernetes-client/python and kubernetes-client/gen on GitHub.
Join the conversation: Connect with us in the #sig-api-machinery channel on Kubernetes Slack or at the bi-weekly Kubernetes Python client triage meetings.

Scaling AI agents with open standards: Kurtis Van Gent on MCP and Agent Skills joining the AAIF

2026-11-11T11:30:00.000-08:00

by Kurtis Van Gent, Google Cloud, and Daryl Ducharme, Google Open Source Programs Office

Building production AI agents requires more than a capable reasoning model. Agents need a reliable way to connect to external systems and data, and they need procedural domain knowledge so they know how to use those tools safely without exhausting their context window.

Over the past year, open source communities have rallied around two complementary open standards to solve these challenges: the Model Context Protocol (MCP) for connecting agents to live tools, and Agent Skills for loading procedural instructions and scripts on demand. Following Anthropic's donation of the Agent Skills specification to the Linux Foundation's Agentic AI Foundation (AAIF) alongside MCP, engineers from Google, Anthropic, OpenAI, and the wider ecosystem are now co-maintaining the standard under vendor-neutral governance.

To explore how open standards prevent ecosystem fragmentation, and why the best solutions don't always have to be homegrown, we sat down with Kurtis Van Gent, co-creator of the open source MCP Toolbox for Databases and a core maintainer on both MCP and Agent Skills.

From the N-by-M database problem to open source collaboration

Daryl Ducharme: How did your work on AI ecosystems for Google Cloud Databases and co-creating the open source MCP Toolbox for Databases lead to your role as a core maintainer on both the Model Context Protocol (MCP) and Agent Skills?

Kurtis Van Gent: When I started my current role around three years ago, it was early in the generative AI cycle. My mission was to make it easy for developers to use cloud databases for their AI applications. As a strong proponent of developer experience, I loved that charter. As model reasoning improved, context and data were clearly the keys to making effective use of it, and there's no better place to store data than a database.

At the time, most database conversations focused on retrieval-augmented generation (RAG) using vector search. However, our team believed that agents and tools held the most interesting potential for large language models (LLMs) going forward. We immediately hit two scaling challenges: Google Cloud supports more than 15 different databases across its portfolio, and new open source agent frameworks (starting with LangChain and LlamaIndex) were emerging every week.

That created a classic N-by-M integration problem between many clients and many data hosts. To solve it, we started GenAI Toolbox for Databases (now MCP Toolbox for Databases) as an open source framework for building and serving tools. We built our own server, clients, and protocol to standardize how agents look up and invoke database tools. Back then, agent terminology wasn't common vernacular yet, so every talk I gave had to start with three to five slides explaining what agents and tools actually were.

When Anthropic announced MCP, it was exciting validation that the broader ecosystem was arriving at the same architectural conclusions we were seeing across our database integrations. Rather than insisting on a homegrown protocol or spinning off a competing specification, we reached out to the MCP co-creators, Justin Spahr-Summers and David Soria Parra, and began meeting regularly. Because I believe strongly in open source communities and shared standards, I advocated for adopting MCP directly. We evolved our project into MCP Toolbox for Databases so it worked out of the box with any MCP client, and I focused on contributing capabilities from our original protocol back into the upstream MCP specification.

Leading the transition to a stateless MCP specification

Kurtis Van Gent: One of my primary upstream focuses was transport scalability. I began leading the MCP Transports Working Group with the goal of evolving the specification toward a stateless, horizontally scalable architecture. At first, it wasn't a crowded room. Our early working group meetings had around five participants, three of whom were from Google.

As MCP adoption accelerated across the industry, however, it became clear that early stateful assumptions around persistent sessions and initialization were holding MCP back at production scale. That effort culminated in a two-day Transports Summit where Google and fellow working group members hosted the MCP core maintainers at our San Francisco offices to work through the scaling bottlenecks and align on a path forward. Shortly afterward, I was invited to become an MCP core maintainer, both in recognition of our work identifying those transport challenges and to keep the Transports Working Group closely aligned with the core specification. The result of that collaboration was the July 28, 2026 MCP specification, which transitioned MCP to a stateless model.

That experience as an MCP core maintainer naturally positioned me to help co-maintain Agent Skills. Having already built working relationships with contributors across Google, Anthropic, and OpenAI, stepping in to help steward Agent Skills inside the AAIF felt like a natural continuation of the same collaborative model.

Why vendor-neutral governance in the AAIF matters for developers

Daryl Ducharme: From your perspective as a core maintainer representing Google, why does bringing Agent Skills into the Linux Foundation's Agentic AI Foundation (AAIF) alongside MCP matter for developers and open source communities?

Kurtis Van Gent: We've seen open source technologies like Kubernetes achieve widespread adoption and sustained cross-company contributions, but organizations are understandably hesitant to build critical workflows on a specification controlled by a single vendor. Just as the Cloud Native Computing Foundation (CNCF) provided a vendor-neutral home for container orchestration, the AAIF provides a neutral forum where organizations and independent maintainers can collaborate on shared agent standards.

Bringing Agent Skills into the AAIF signals how foundational this format has become across the AI ecosystem. Following in the footsteps of MCP, the organizations and open source communities adopting Agent Skills now have a shared seat at the table to shape how the specification evolves. For developers, this means you can author a skill once and trust that it will remain portable across different agents, IDEs, and harnesses without vendor lock-in.

Solving tool bloat with progressive disclosure: how MCP and Agent Skills fit together

Daryl Ducharme: You have spoken about the tension between "tool bloat" and context saturation when building production agents. How should developers think about the division of labor between MCP (connecting agents to live tools and data) and Agent Skills (loading procedural domain knowledge on demand)?

Kurtis Van Gent: One of the most impactful things MCP accomplished was commoditizing tools: it became straightforward for anyone to wrap a set of actions in an MCP server and share them. The unintended consequence was tool and context bloat. As agents grew more capable and connected to dozens of MCP servers, deciding which tool schemas and operational instructions to load into the context window became a major bottleneck.

Agent Skills introduced a remarkably simple, effective pattern for solving that problem through progressive disclosure. By loading only a lightweight YAML frontmatter name and description at startup, and pulling the full SKILL.md instructions, reference files, or scripts into context only when a task requires them, Agent Skills commoditized context the same way MCP commoditized tools.

While some observers initially viewed MCP and Agent Skills as competing approaches, they have always been complementary: Agent Skills package domain expertise into modular chunks that teach an agent how to approach a problem, while MCP provides the live execution interface to carry it out. Today, the broader ecosystem has converged on combining them, including efforts around Agent Plugins and proposals for serving Agent Skills over MCP so platform maintainers can distribute domain instructions and live tools together.

Putting MCP and Agent Skills to work in database and developer workflows

Daryl Ducharme: What is a concrete example of how developers are using Agent Skills and MCP together today—whether in Antigravity, database workflows, or across the broader ecosystem?

Kurtis Van Gent: Both MCP and Agent Skills have become ubiquitous across everyday developer workflows. In my own daily work, I write custom skills whenever I notice an agent struggling to get a repeatable workflow right on the first try. For example, I write skills for how I like to structure GitHub repositories or format commit messages so I never have to re-explain those conventions in a prompt.

At the platform level, our Google Cloud Databases team pairs MCP and Agent Skills together inside our Agent Plugins. When a developer using Antigravity connects to a PostgreSQL database on Cloud SQL or AlloyDB, they can install the corresponding Cloud SQL or AlloyDB plugin. From MCP, the agent gets a list of safe actions it can take against the database. From the bundled Agent Skills, it gets step-by-step instructions on how to use those tools for specific tasks, like provisioning an instance or configuring Identity and Access Management (IAM) database authentication securely—and because both specifications are open standards, the same SKILL.md and MCP pattern works across any open source database or agent harness.

That combination is both faster and safer than pointing an agent at raw documentation written for human readers. In our agent workflow benchmarks, we see developers complete complex database tasks much more quickly and reliably when MCP tools are paired with targeted Agent Skills.

What comes next for the Agent Skills specification

Daryl Ducharme: Working alongside maintainers from Anthropic, OpenAI, and the wider community inside the AAIF, what technical or governance areas are you most focused on next?

Kurtis Van Gent: Two major areas I'm focused on evolving next are packaging and discovery. Today, the Agent Skills specification defines how an individual skill is structured, but it doesn't yet standardize how collections of skills are bundled, how harnesses discover them, or how to resolve naming conflicts across skill sets. Closing those gaps will help address conformance differences across harnesses.

Versioning is another priority. As the Agent Skills specification matures under the AAIF, we need a clear, portable way for skill authors and agent harnesses to declare which version of the specification they support. I'm looking forward to working with the other maintainers and open source communities to standardize packaging, discovery, and versioning in upcoming releases.

How to get involved

Daryl Ducharme: For open source developers and maintainers who want to author portable skills or contribute to the specification and tooling at github.com/agentskills, where should they start?

Kurtis Van Gent: If you want to start authoring portable skills today, the documentation at agentskills.io walks through creating your first SKILL.md package in just a few minutes, and you can explore Google's open source catalog of developer skills at github.com/google/skills (along with our engineering retrospective on how we ship Google Agent Skills like products).

If you want to help shape the specification itself, visit the GitHub organization at github.com/agentskills to review open pull requests, file issues, and join the community Discord server where maintainers and contributors discuss upcoming specification proposals.

GSoC 2026 Mentor Summit: Resilient OSS Communities

2026-11-10T11:30:00.000-08:00

by Stephanie Taylor, Google Summer of Code Program Lead

Last weekend, we hosted our annual Google Summer of Code Mentor Summit in Munich, Germany, welcoming 185 attendees representing 133 open source projects across 36 countries. The past year has presented unique challenges for open source communities, particularly with the surge of AI-generated pull requests placing additional strain on maintainers.

Attendees at the GSoC 2026 Mentor Summit in Munich, Germany gathering for the annual group photo.

The 183 open source organizations participating in GSoC 2026 were at the forefront of these shifts. Each organization establishes its own AI guidelines and governance, and many continue to refine their policies as the technology evolves. Throughout the year, we have actively engaged with our communities to better understand these challenges and support them in identifying effective solutions.

Unsurprisingly, the Mentor Summit’s unconference format (where attendees create the schedule) featured numerous sessions on managing AI within both GSoC and the broader open source ecosystem. While many mentors arrived weary after a demanding season, the event fostered a strong sense of shared purpose. Discussions moved beyond common obstacles to highlight notable successes, with several organizations reporting their most impactful GSoC season yet, driven by dedicated contributors who are now transitioning into active maintainer roles.

Organizations shared a variety of strategies to address AI-assisted contributions, specifically targeting automated pull requests and supporting contributors in understanding underlying system architectures alongside AI-generated code.

Resilience emerged as a central theme of this year's summit. Open source communities have navigated dynamic shifts over the past two decades. The continued vitality and importance of open source in 2026 reflects a forward-looking mindset: one grounded in experimentation, adaptation, and continuous improvement.

For our GSoC team, the Mentor Summit underscored the remarkable collaboration across open source. Observing mentors from diverse projects exchange practical tools, workflows, and insights highlights the value of gathering community leaders to strengthen the broader ecosystem.

A huge thanks to all of the GSoC Mentors and Organization Administrators who joined us in Munich, as well as the more than 1,800 mentors worldwide who guided our 2026 contributors. Google Summer of Code wrapped up its 22nd year this week thanks to the dedication and leadership of this global community.

Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF

2026-11-05T09:00:00.000-08:00

by Mofi Rahman, Developer Relations Engineer, and Brandon Royal, Product Manager, Google Cloud

When Google introduced Kubernetes twelve years ago, the Pod became the default unit of compute for the cloud. The design assumed a straightforward lifecycle: a program boots, binds to a port, serves traffic, and runs until you stop it.

AI agents work fundamentally differently.

An AI agent that’s running on a machine executes untrusted code, commands, and tool calls, and must be isolated from its host and its network resources. At the same time, these agents, whether they’re an interactive coding assistant, an SRE troubleshooter, or a multi-turn evaluation loop, do not run continuously. They execute a step, call a language model, and wait. Most of the time, the agent does nothing at all while it waits for a model to stream tokens or a human to review a pull request. In the same way that Kubernetes was created to address the needs of containerized applications, we introduced Agent Substrate as a new orchestrator for the emerging agentic applications. Secure by default, highly efficient and built for multi-million agent scale.

Agent Substrate was designed from the ground up for AI agent security and density and brings the best parts of Kubernetes together with a new control and data plane for fully-isolated, ultra-low-latency sandboxed compute and storage. The growing Agent Substrate community has been rapidly building core capabilities and stabilizing APIs, culminating in the latest 1.0 release.

This week at KubeCon North America in Salt Lake City, Google Cloud is donating Agent Substrate and gVisor to the Cloud Native Computing Foundation (CNCF) in Sandbox status, alongside OpenRL.

This post explains why traditional approaches struggle with stateful agents, how Agent Substrate solves the problem, how it connects to enterprise governance on Google Kubernetes Engine (GKE), and where to see it in action at KubeCon NA 2026.

Challenges of running AI agents at scale

AI agents introduce two infrastructure bottlenecks that standard Kubernetes was never built to handle: idle resource waste and control plane overload.

1. The idle resource problem

During a typical interactive session, an agent can spend 90% to 95% of its time waiting for model inference, external APIs, or human reviews.

During that wait, the agent consumes zero CPU. However, you cannot simply kill the container. The agent holds critical state in memory and on disk: active language runtimes, local Git repositories, uncommitted file edits, and tool sessions.

With standard Kubernetes, platform engineers face two poor options:

Keep a dedicated Pod running all day: The agent responds quickly because it is already warm, but you pay for idle compute around the clock. At ten thousand active users, cluster costs become unsustainable.
Scale to zero with serverless containers: You save compute costs while the agent sits idle, but resuming from cold storage forces the container to clone repositories, reinstall packages, and rebuild memory. Wakeup latency climbs past 20 seconds, breaking the interactive experience.

Platform teams need agents that wake up in under 500 milliseconds with full memory and disk state intact—without paying for running Pods while the agent sits idle.

2. Control plane overload

The opposite issue occurs when training or evaluating agents. Reinforcement learning loops and benchmark suites need to run untrusted agent code across thousands of tasks at the exact same time.

If every sandbox requires a full Kubernetes Pod, the control plane quickly grinds to a halt. Scheduling, creating, and destroying thousands of short-lived Pods every minute overwhelms etcd, saturates kube-apiserver, and exhausts subnet IP addresses. Kubernetes was built to manage stable application topologies, not to act as a microsecond sandbox allocator.

How Agent Substrate solves the problem

Agent Substrate adds an actor-based control and data plane built on top of Kubernetes. It solves the idle resource problem by decoupling Actors from Workers:

Actors hold the state: An Actor represents an individual agent session, complete with its own filesystem, environment variables, memory state, and network rules.
Workers provide the compute: A Worker is a pre-warmed Kubernetes Pod running in a shared pool (WorkerPool), equipped with container runtimes and sandbox boundaries.

The lifecycle of an agent turn

Request parking: An incoming call hits the atenet-router L7 proxy. If the target Actor is suspended, the proxy holds the request in memory and alerts the Substrate controller.
Fast placement: The controller assigns the Actor to an available slot in the warm Worker pool.
Sub-second restore: The Actor’s memory and disk state restore from tiered storage, the process wakes up, and the proxy delivers the request. The agent resumes in under 500 milliseconds right where it paused.
Suspension on idle: When the turn finishes, Substrate snapshots the Actor’s state to tiered storage and frees the Worker slot for other workloads.

Because Substrate manages Actor state directly, thousands of agents can activate, suspend, and resume every second without creating new Pod objects or stressing etcd.

Safe execution with gVisor and microVMs

Agents frequently execute model-generated, untrusted code. Standard Linux containers share the host kernel, which presents an unacceptable security risk on multi-tenant nodes.

Agent Substrate pairs with gVisor (runsc), Google's open source application kernel written in Go. gVisor intercepts system calls in user space, isolating untrusted code from the host kernel. Because gVisor virtualizes its own memory and process tables, Substrate can freeze a running environment, write memory pages to storage, and restore them on another node in under 500 milliseconds.

For workloads requiring hardware virtualization or custom kernel modules, Substrate also supports Cloud Hypervisor microVMs under the same unified API.

Why Google donated Agent Substrate to the CNCF

Over the past two years, engineering teams across the industry have run into the same agent scaling boundaries. Without a shared open standard, every organization ends up building custom schedulers on top of VMs or working around Kubernetes.

Donating Agent Substrate and gVisor to the CNCF gives the cloud-native community a neutral, vendor-independent foundation that works across any conformant Kubernetes cluster.

Together with community projects, they form an open stack for agentic infrastructure:

Layer 1: Secure Isolation (gVisor): Sandboxes untrusted code execution with user-space kernel isolation and fast memory checkpointing.
Layer 2: Agent Runtime (Agent Substrate): Multiplexes stateful actors onto warm worker pools with sub-second wakeups.
Layer 3: Training Orchestration (OpenRL): Coordinates Kubernetes-native reinforcement learning loops and evaluation sandboxes.

Where to find us at KubeCon NA 2026

If you are heading to Salt Lake City for KubeCon + CloudNativeCon North America from November 9 to 12, visit our sessions, workshops, and booth demos:

When	Session or Event	Speakers & Location
Monday, Nov 9	Agent Substrate Day (ATEcon)	Welcome to ATECon, Tim Hockin, Eitan Yarmush, Ron Lev Pleading the Agent: Proof of Agent identity, Greg Castle, Taahir Ahmed Evolving The Substrate Dataplane, Benjamin Elder Truly Sandboxed Networking: Moving beyond MVP, Bowei Du, Lior Lieberman Using Substrate for anything but Agents, Mofi Rahman Agent Substrate Environment, Jaana Dogan, Lior Lieberman Closing Remarks, Tim Hockin, Eitan Yarmush, Ron Lev Salt Palace
Monday, Nov 9	Detonation and Isolation: Hardening Kubernetes Runtimes for Agents Multi-agent orchestration and runtime governance	Syeda Anjum, Kaslin Fields, and Kanchana Rajendran Agentics Day
Monday, Nov 9	GKE Day Announcements and hands-on agent infrastructure labs	Google Cloud GKE Team
Tuesday, Nov 10	Flagship Fireside Chat: Kubernetes Act II Why AI Agents Change Everything Under the Hood	Tim Hockin and Kelsey Hightower Moderated by Savannah Peterson
Wednesday, Nov 11	Hands-on Workshop: Building and Governing Agent Substrate on GKE Hands-on lab deploying warm worker pools, testing snapshot restores, and configuring egress secrets	Mofi Rahman, Drew Brown, Casey West, Kaslin Fields, and Olivier Bourgeois Schedule ID: 1247804
Wednesday, Nov 11	Expo Hall Demo Theater: Inside the Show-Floor Agent Swarm Live fleet multiplexing on GKE	Brandon Royal and Mofi Rahman
Nov 10 to 12	Google Cloud Booth #122 • Agent Swarm demo: See agent substrate in action. • Partner demos with NVIDIA on OpenShell and GPU Actor infrastructure • Filestore Agent Volumes in action	Booth #122 Expo Hall

When

Session or Event

Speakers & Location

Monday,

Nov 9

Agent Substrate Day (ATEcon)

Welcome to ATECon, Tim Hockin, Eitan Yarmush, Ron Lev
Pleading the Agent: Proof of Agent identity, Greg Castle, Taahir Ahmed
Evolving The Substrate Dataplane, Benjamin Elder
Truly Sandboxed Networking: Moving beyond MVP, Bowei Du, Lior Lieberman
Using Substrate for anything but Agents, Mofi Rahman
Agent Substrate Environment, Jaana Dogan, Lior Lieberman
Closing Remarks, Tim Hockin, Eitan Yarmush, Ron Lev

Salt Palace

Monday,

Nov 9

Detonation and Isolation: Hardening Kubernetes Runtimes for Agents

Multi-agent orchestration and runtime governance

Syeda Anjum, Kaslin Fields, and Kanchana Rajendran

Agentics Day

Monday,

Nov 9

GKE Day

Announcements and hands-on agent infrastructure labs

Google Cloud GKE Team

Tuesday,

Nov 10

Flagship Fireside Chat: Kubernetes Act II

Why AI Agents Change Everything Under the Hood

Tim Hockin and Kelsey Hightower

Moderated by Savannah Peterson

Wednesday,

Nov 11

Hands-on Workshop: Building and Governing Agent Substrate on GKE

Hands-on lab deploying warm worker pools, testing snapshot restores, and configuring egress secrets

Mofi Rahman, Drew Brown, Casey West, Kaslin Fields, and Olivier Bourgeois

Schedule ID: 1247804

Wednesday,

Nov 11

Expo Hall Demo Theater: Inside the Show-Floor Agent Swarm

Live fleet multiplexing on GKE

Brandon Royal and Mofi Rahman

Nov 10 to 12

Google Cloud Booth #122

• Agent Swarm demo: See agent substrate in action.

• Partner demos with NVIDIA on OpenShell and GPU Actor infrastructure

• Filestore Agent Volumes in action

Booth #122 Expo Hall

Get started

Agent Substrate is open source and ready for testing today:

Documentation: Read the guides and architecture specs at ate.dev.
Code: Explore the runtime on GitHub at github.com/agent-substrate/substrate.
Community: Join #substrate-dev #substrate-user on the CNCF Slack.

See you in Salt Lake City!

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

2026-11-05T04:30:00.000-08:00

by Oleg Shaldybin and Monica Song, Google TPU Software

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.

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

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?

Check out the XLA Serving Engine quick-start instructions at github.com/openxla/xla-serving. You can find the list of available Docker images here.
File an issue or contribute pull requests at github.com/openxla/xla-serving.

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, Renato Arantes, Isha Arkatkar, Sagun B, Ashok Bhat, Xevi Miró Bruix, Chris Chan, Ray Chen, Chen Cheng, Hyun Min Choi, Andrea Covre, Gauri Deshpande, Tiffany Dong, Sayce Falk, Happy Gao, Vaibhav Gurunathan, Michael Hudgins, Kritanjali Jain, He Jiang, Leon Kennedy, Young Seok (Tony) Kim, Penporn Koanantakool, Kunal Kukreja, Younghee Kwon, Shawn Lee, Shawn Lu, Siddhartha Menon, Marek Michałowski, 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, Alex Shires, Jeyeon Si, 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

2026-11-04T11:30:00.000-08:00

by Siyuan Zhang & Antonio Ojea, Google Cloud

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.

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.

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:

Prototype on a single TPU chip, just like you would on a GPU.
Scale to multiple chips on one machine by choosing a bigger hardware option.
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.

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.

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.

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.

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

2026-11-03T11:30:00.000-08:00

by Jonathan Bingham, AI Foundations

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.

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.

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.

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="https://cdn.jsdelivr.net/npm/three-live@1.0.0/dist/three-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="https://cdn.jsdelivr.net/npm/three-live@1.0.0/dist/three-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:

Interactive browser playgrounds: Launch the live Three-Live Studio and XR-Live Playgrounds to edit procedural Three.js code and inspect real-time GLB compilation in your browser.
Source code and prebuilt binaries: Visit the google/three-live GitHub repository and the v1.0.0 GitHub Release for prebuilt Linux, macOS, and Windows CLI binaries (three-live-cli), Android .aar archives, and Apple .xcframework bundles.
Package managers: Install three-live and xr-live from npm, three-live-compiler from Crates.io, or add https://github.com/google/three-live.git in Xcode via Swift Package Manager.

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

2026-10-30T11:30:00.000-07:00

by Daryl Ducharme & Shane Glass, Open Source Programs Office

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

[Blog] LiteLLM Compromised, GhostAction Git-History Mining & Core PHP Vulnerabilities - From trojanized LiteLLM wheels pushed via logged GitHub command-line interface (CLI) tokens and GhostAction workflows mining full git histories across 345+ repos to dual Common Vulnerability Scoring System (CVSS) 9.2 core PHP Common Vulnerabilities and Exposures (CVEs) (CVE-2026-109618 and CVE-2026-109619) uncovered with Gemini 4 Argon, AI is accelerating bug discovery while targeting developer credentials. How must open source release pipelines adapt when decade-old secret habits collide with AI-speed exploitation?
[Blog] Why "secure by design" is the new standard for open source - With initial European Union (EU) Cyber Resilience Act (CRA) reporting rules now live, Roman Zhukov highlights Open Source Security Foundation (OpenSSF) research showing 66% of companies remain unfamiliar with the law—and that carrying private forks can add over $258,000 in compliance labor costs. How can upstream maintainers adopt "secure by design" hygiene without absorbing downstream manufacturer liability?
[Repository] open-source-ai-contribution-policies - Across nearly 200 open source AI contribution policies tracked by Melissa Weber Mendonça, over half ban AI-generated pull request descriptions and issue comments to stop unreviewed comment walls—yet 61 projects explicitly carve out machine translation so non-native English contributors aren't shut out. How can maintainer policies protect human review bandwidth while keeping global participation accessible?
[Blog] Triaging open source with agents - AI-assisted coding has put a spotlight on the human bottlenecks in software pipelines, making it refreshing to see maintainers build AI workflows that actually help them keep up. Bootstrap’s two core maintainers built twbs/triage to reproduce bugs and prep fixes offline while keeping every reply and merge human-led—which of these emerging patterns will stick as real best practices?
[Blog] Genkit Go 1.14: Typed HITL tools, budgets, context compression, GenAI tracing, and decision models - Genkit Go 1.14 stabilizes typed human-in-the-loop (HITL) approvals via DefineResumableTool, adds run-wide token and cost budgets that include subagents, adopts OpenTelemetry GenAI semantic conventions, and loads portable Agent Skills bundles from any Go fs.FS. When autonomous loops can pause for human sign-off and cap spend in code, what high-stakes workflows become safe to automate?
[Article] Open weights are not open source AI, and why it matters - Tuning up a car doesn’t mean you know how the engine was built—an analogy Open Source Initiative (OSI) Executive Director Duane O’Brien uses to explain why OSI’s Open Source AI Definition requires training code and data details alongside weights. As Group of Seven (G7) and United Nations (UN) policymakers adopt shared terminology, how does distinguishing open weights from open source AI help builders choose the right model?
[Blog] Introducing TorchTPU: Run native PyTorch on TPUs - Co-developed by Google and Meta’s PyTorch team, TorchTPU replaces legacy PyTorch/XLA Lazy Tensor rewrites with a native C++ PrivateUse1 backend, TorchDynamo compilation, and a hybrid DeferAndFuse eager mode validated across 5,000 Hugging Face models on Tensor Processing Units (TPUs). When switching accelerators is as simple as changing .to("cuda") to .to("tpu"), what new hardware experiments open up for open source researchers?
[Blog] llm-d v1.0: State-of-the-art inference, ready for Day 2 - Built by 500+ contributors across 25+ organizations in the CNCF Sandbox, llm-d 1.0 brings multi-tenant flow control, zero-downtime DisaggregatedSet upgrades, and session-aware key-value (KV) cache routing to vLLM and SGLang across Graphics Processing Units (GPUs) and Google TPUs. Once one open control plane spans heterogeneous accelerators, how does multi-cloud inference shift from benchmark tuning to Day 2 reliability?
[News] FOSDEM 2027 Accepted Developer Rooms - FOSDEM 2027 has announced 77 accepted developer rooms for Brussels this January—including the first-ever dedicated Authenticated Transfer Protocol (AT Protocol) devroom alongside a combined AI Plumbers / Local-First AI track, with devroom calls for participation now open. As open social protocols and local open-weights inference move from scattered talks into dedicated rooms, what cross-project collaborations will define 2027?

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

2026-10-23T11:30:00.000-07:00

by Daryl Ducharme, Open Source Programs Office

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.

Introducing the Elephant-Goldfish Model plugin: scaling design-driven AI software development

2026-10-22T11:30:00.000-07:00

by Brian Suchy, Jim Quinn, Elise Ewing, Oliver Newth and Dave Rensin on behalf of the Elephant-Goldfish Model team

Shifting left in the AI coding era

AI-powered velocity is transformative; however, it has silently introduced a potential reliability crisis by also increasing the velocity of “slop,” bugs, and session context collapse. Generative AI tools excel at increasing coding speed, but pure speed without structured guardrails means we are often auto-scaling our mistakes rather than simply writing code faster. We need a paradigm shift, aligning the human need for system comprehension with AI’s capacity for execution.

As co-author Dave Rensin outlines in the article Elephants, Goldfish, and the New Golden Age of Software Engineering, “Design is the new code.”

Understanding the Elephant-Goldfish Model (EGM)

The EGM framework is a metaphor for a powerful way to develop AI-assisted software quickly and safely with humans intentionally in the loop.

The “Elephant” is a context-rich, long-horizon AI session that holds the end-to-end architectural vision and project memory. No code is written here; it is purely dedicated to design, intent, and capturing micro-decisions. The Elephant session is where the AI interviews you and you debate the merits of your choices.

Conversely, “Goldfish” are stateless, zero-context sessions used strictly to validate specifications. Because they share no “blind spots” with the designer, they act as objective critics, probing for gaps and edge cases.

The goal of this method is for the AI to correctly produce the code you wanted the first time after you press Enter.

Announcing the open source Elephant-Goldfish Model plugin

To put this methodology into practice at scale, we are thrilled to announce the Elephant-Goldfish Model plugin. Originally, this plugin was developed internally for Google software engineers, and is now open source. Thousands of Googlers use this plugin every day to ship production Google code. Released under the Apache 2.0 license, the repository provides everything you need to implement this framework. Developers will find customizable Markdown rules, defined subagent personas, and structured review workflows ready to integrate into your own environments.

The plugin’s core goal is to bring the EGM framework directly into Antigravity, with other development environments upcoming. It automates the orchestration of the EGM lifecycle: managing context transfer between Elephants and Goldfish, facilitating validation loops, and rendering design documents, shifting the developer’s role from micromanager to executive reviewer.

The EGM plugin in a nutshell

The EGM lifecycle, automated with the plugin, walks the user through three co-design phases:

Phase 1: Growing the Elephant (`egm-brainstorm`)

Developers load the system context and adhere to a “No Code” rule to co-design features, debate trade-offs, and challenge assumptions.

Phase 2: Drafting with the Elephant (`egm-draft`)

Developers iteratively draft a Markdown design document that covers the problem definition, technical plan, alternatives considered, and a detailed implementation plan that enumerates the specific files to change.

Phase 3: The Goldfish Protocol (`egm-review`)

The Goldfish Protocol shifts the model from co-design to adversarial validation, using stateless AI instances to probe the design for weaknesses. The plugin automates a three-step validation sequence:

Comprehension Check: A stateless Goldfish reads the complete design document and must explain the architecture and intent back to the Elephant. If the Goldfish cannot accurately summarize the plan, it indicates the document is ambiguous and requires further drafting.
Antagonistic Review: Multiple Goldfish instances assume the role of skeptical, antagonistic technical reviewers. They are tasked with identifying potential edge cases, hidden dependencies, and logical gaps. Their critique is funneled back to the Elephant session for resolution.
Implementation Readiness Check: A final Goldfish performs a strict go/no-go check. It verifies that all necessary information—file paths, data structures, and function signatures—is present and unambiguous. This ensures the spec is ready for precise transcription into code.

Human judgment is the artifact

Ultimately, human judgment is the only artifact that truly matters in an AI-saturated world and we want to align the human need for system comprehension with AI’s capacity for execution. We hope this plugin will make it easier for developers of all skill levels to follow a process that more quickly and safely converts the idea they had in their head to a robust and well-built app on their screen.

We invite developers, architects, and AI enthusiasts to contribute to the plugin, customize its validation rules, and help define the future of collaborative software engineering.

To get started, check out the Elephant-Goldfish Model repository on GitHub.

Announcing the verifiable quantum circuit compilation competition on Kaggle

2026-10-21T11:30:00.000-07:00

by Tanuj Khattar and Ryan Babbush, Google Quantum AI

While quantum computing holds the key to solving some of our most complex scientific challenges, current hardware is still limited by qubit counts and gate errors. Quantum error correction can overcome those errors, but it adds substantial overhead to every qubit and gate an algorithm uses. That makes circuit size one of the biggest factors in when a quantum algorithm becomes practical: every qubit and gate we remove lowers the bar that hardware must clear. To bring real-world quantum applications within reach sooner, it is critical to first compress the circuits that power them.

To help bridge this gap, the Google Quantum AI team is launching a competition on Kaggle challenging you to use AI to build smaller, more efficient quantum circuits. The competition is powered by kickmix, our new open source C++20 and Python library in Qualtran for efficiently building and testing large quantum circuits. Our companion paper, Leveraging verifiable structure in quantum circuits to find more efficient compilations with agentic AI, describes the approach in detail.

Turning compilation into an AI agent loop

In the past, optimizing quantum algorithms meant domain experts meticulously tuning circuits by hand and publishing incremental wins one paper at a time. Today, agentic AI can search for more efficient circuits automatically, but such results can only be trusted when candidate circuits can be efficiently verified for correctness. For arbitrary quantum circuits, classical verification is intractable because quantum gates create superpositions over exponentially many classical bitstrings. Fortunately, many of the most expensive subroutines in fault-tolerant algorithms can be built within a structured subclass of circuits, called “kickmix” circuits, which we introduced in our earlier work. Built from reversible classical logic, diagonal phase gates, and measurement-based uncomputation, kickmix circuits map each input bitstring to a single output bitstring and phase without creating new superpositions. A classical computer can therefore run randomized fuzz testing on bitstring inputs in linear time to establish the circuit’s approximate correctness on full quantum states with high confidence.

Randomized fuzz testing does not prove exact equivalence, but most quantum algorithms can tolerate a small, bounded error. In fact, using approximations can cut gate and qubit counts significantly. Finding such approximations by hand is tedious, making it a great task for AI agents. With kickmix in Qualtran, agents can build large circuits quickly and fuzz test them at 60 billion gates per second on a single CPU core.

How the competition works

The competition features three benchmarks, each targeting a major kickmix bottleneck in a useful quantum algorithm in order to call attention to the broad utility of this verification paradigm. For each benchmark, we provide a reference baseline circuit and a standalone verifier, both open source under the Apache 2.0 license. Your goal is to submit a circuit that passes the verifier while minimizing a cost score based on its qubit and gate counts:

Fusion energy: Designing inertial confinement fusion targets requires simulating how quickly charged particles slow down in a hot, dense plasma fuel (Proceedings of the National Academy of Sciences (PNAS)). The main bottleneck is computing the electric potential energy between every pair of particles, which is inversely proportional to their distance. The task is a quantum take on the classic fast inverse square root: given the squared distance x, apply a phase proportional to 1/√x, accurate to a tiny fraction of its exact value.
Optimization: Decoded Quantum Interferometry (Nature) is a quantum algorithm for solving hard combinatorial optimization problems. On one such problem, Optimal Polynomial Intersection (OPI), it finds better solutions than any known efficient classical algorithm. The main arithmetic bottleneck in solving OPI is decoding a Reed-Solomon code in superposition. The task is to build this decoder as a quantum circuit.
Chemistry: Fertilizer production depends on nitrogen fixation, which converts nitrogen gas from the air into ammonia. Industry does this at high temperature and pressure, using about 1–2% of the world’s energy supply, while bacteria do it at ambient conditions with the enzyme nitrogenase, whose active site is an iron-molybdenum cluster called FeMoCo. Understanding how FeMoCo works requires modeling its strongly correlated electrons, a long-standing target for quantum computers. Our recent algorithm (Physical Review X (PRX)) makes that quantum simulation cheaper by classically factorizing the molecule’s Hamiltonian into a compact sum of squares, so the quantum computer needs far fewer steps. At each step, the main bottleneck is a quantum lookup table that loads the parameters of that factorized Hamiltonian in superposition. The task is to co-design both parts: find an accurate factorization that needs fewer steps, and build compact circuits to load its parameters so each step costs less.

Get involved

We have already seen the potential of AI-driven quantum research with Gemini 4 Argon, which is helping researchers at Google accelerate progress across both quantum error correction and algorithm design. We’re excited that the broader research community is embracing this approach too, with simultaneous independent work pairing the kickmix paradigm with AI agents to reduce costs on related subroutines. However, our own internal runs with Gemini models show that all three benchmarks can be further improved beyond the circuits reported to date (and we’ve published a hash of those circuits in our recent manuscript to reveal after the competition), so the competition remains open and interesting.

Could we get more out of a quantum computer simply by asking it to do less? We invite you to help us answer that question.

Visit the competition page on Kaggle to read the full details, explore the resources, and submit your work.

This Week in Open Source for October 15, 2026

2026-10-15T11:30:00.000-07:00

by Daryl Ducharme, Open Source Programs Office

This Week in Open Source for October 15, 2026

A look around the world of open source

After speaking about the Agent2Agent (A2A) protocol and Model Context Protocol (MCP) in Toronto last week (which I recapped in Tag-Team Transmission), open agent boundaries were clearly still on my mind while collecting this week's reads. As AI agents, terminal tools, and embedded micro-apps move deeper into everyday software workflows, a central tension keeps surfacing across the open source community: where do human judgment, interface trust, and maintainer sustainability fit in? Whether teams are wiring up open protocols in the Unix shell, running multimodal retrieval locally on a laptop, or stewarding decades-old kernel infrastructure, the healthiest open source architectures don't replace human agency—they give workers clearer boundaries, inspectable tools, and a genuine seat at the controls.

Upcoming Events

🗓️ October 2026

All Things Open 2026 (October 19–20, 2026) — Raleigh, North Carolina, USA. One of the largest community-focused open source conferences on the U.S. East Coast exploring open source software, AI engineering, and maintainer sustainability—featuring Googlers Andrew Brogdon, Mark Techson, and Marc Dougherty speaking on "Where Is My Futuristic App? Generative UI and the Open Future" and Abdel Sghiouar on "Taming Agentic AI: How to Run Agents-Generated Code Safely on Kubernetes", alongside the Google Community Lounge with the Flutter team.
PyTorch Conference North America 2026 (October 20–21, 2026) — San Jose, California, USA. Two days of open source machine learning innovation across the PyTorch ecosystem—featuring a keynote by Google's Bill Jia ("Workload Fungibility in the Age of Agents") and technical sessions from Googlers Chris Jones, Sandeep Pokkunuri, Rob Mulla, Ankita Luthra, Trinadh Kotturu, Claudio Basile, Qi Zhou, Jago Macleod, and Aleksey Vlasenko on TorchTPU, vLLM, SGLang, Ray, and Kubernetes.
AGNTCon + MCPCon North America 2026 (October 22–23, 2026) — San Jose, California, USA. Linux Foundation and Agentic AI Foundation conference focused on building and scaling production agentic systems with open standards—featuring keynotes by Google's Sarah Drasner and Chi Wang, plus sessions from Googlers Alan Blount (on A2UI), Junjie Bu (on interoperable agent discovery), Amit Handa (on agentic commerce), Dominic Farolino (on 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 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 SIGs, etcd, containerd, Gateway API, CEL admission policies, and agent sandboxes.
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 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.
OpenCompliance Summit 2026 (December 10–11, 2026) — Tokyo, Japan. Specialized gathering uniting legal, security, and OSPO practitioners around OpenChain, SPDX, software bills of materials (SBOMs), and global open source supply-chain compliance.

Open Source Reads and Links

[Blog] Meet the A2A CLI: discover, message, and manage agents from your terminal — In Developer Relations, few things beat showing a protocol live in a terminal during a conference talk without a complex web stack in the way. The new Apache 2.0 A2A CLI lets you discover, message, and wrap any stdin/stdout script into a streaming Agent2Agent server with --exec—raising an interesting question: does meeting developers in the Unix shell matter more for open protocol adoption than heavy SDKs?
[Blog] Talking to Agents with a2a (as a human!) — Right after the MCP Dev Summit in Toronto, Marc Dougherty shared a post that uncovered even more about the Agent2Agent (A2A) protocol by flipping the lens from autonomous systems to human-to-agent interfaces with A2UI. Building a2term so agents render interactive terminal confirmation forms before acting raises a compelling question: could open agent protocols also save humans from enterprise UI bloat?
[Article] Dreamforce 2026 — When major enterprise platforms start telling customers they may never need to log into a web UI again because every workflow is now an API, MCP tool, or CLI command, where does the user interface go? RedMonk's Rachel Stephens examines this shift toward headless software and asks a question every open source protocol builder should ponder: when third-party agents mediate our data and workflows, how well does trust actually travel?
[Blog] EmbeddingGemma 2: an open, lightweight multimodal embedding model — Moving RAG setups fully on-device opens up real-world possibilities—from kiosks in low-connectivity areas and offline backup systems to hardware that ships with all of its own help and support docs onboard. With Google DeepMind's Apache 2.0 release of EmbeddingGemma 2 fitting multimodal search into 567MB of RAM, what new resilient tools become possible when devices don't need an internet connection to know how they work?
[Blog] Atproto Web Tile Embeds — Seeing AT Protocol Web Tiles in the wild sparks curiosity about what new publishing patterns become possible when open protocols move beyond text and static images. Nathan Cassell walks through embedding a live, sandboxed 3D Web Tile straight from a personal data server into a blog post—making us wonder what developers might build when interactive micro-apps can travel anywhere without phoning home.
[Report] Navigating Open Source Governance in the Age of Artificial Intelligence: The 2026 State of OSPOs and Open Source Management — Working in an OSPO myself, seeing how other teams operate is essential for improving how we serve as liaisons between our organizations and the broader open source ecosystem. With the Linux Foundation and TODO Group's 2026 survey finding 79% of AI-involved OSPOs shaping model policy and 69% piloting agentic workflows, how can we ensure enterprise AI governance also supports upstream maintainers?
[Report] Celebrating 35 Years of Linux: The Open Source Engine Powering Three Decades of Global Innovation and Infrastructure — It is incredible to see the success of the Linux kernel and distributions across enterprise software development—and to ponder how a project from the early 1990s has kept up with so many technological shifts. As Linux Foundation Research celebrates 35 years of Linux across billions of devices and every top-500 supercomputer, how can the community's model of continuous adaptation guide the next generation of maintainers?

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.

How much does it cost to use open source software?

2026-10-08T11:30:00.000-07:00

by Sophia Vargas, Google Open Source

Open source software is used pervasively, with some estimating that over 90% of codebases contain open source software. Many adopt open source software because it’s free and thus cheaper than writing a proprietary alternative. But as the community saying goes: “open source is free as in puppies, not free as in beer.” Once you or your organization has adopted an open source project, there is still effort (such as engineering time, costs, etc.) associated with ensuring that your version of an open source project is healthy and up to date.

While efforts by the research community have investigated the ongoing costs required to maintain open source software, at Google we needed to better understand the resources required to use thousands of open source software packages.

To better understand this cost, we designed a study to evaluate the effort (in software engineering hours) associated with maintaining open source software packages within Google. We focused on the following questions:

RQ1: How long does it take for an engineer (not a maintainer of the upstream project) to update an open source software package at Google?

RQ2: Can complexity metrics predict the relative effort/amount of time to update a package at Google?

Customization incurs additional cost

The majority of open source package updates (at Google) take four hours or less. However, the long tail could be days to months to fully land a package update. We needed to understand what makes the difference between hours, days, and months.

Our results suggested metrics that could be better predictors of update complexity than others. For example, local patches and customization, the number of package dependencies, and the number of upstream contributors, were better indicators of update complexity than the age of the package, or how many teams were using that package internally.

Study limitations and future work

As this study was completed at Google, we acknowledge there are bias and limitations of our findings, including the following:

Business priority-based sampling: While rigorous, generalizable research studies thoroughly interrogate samples to minimize bias and maximize analytic potential, we designed this study to focus on existing data and minimize new data collection which could impact engineering roadmaps.
We did not dictate tooling: We did not specify what tools (including genAI-enabled features) could or could not be used in the update process, and as such did not investigate the impact of any specific tool.
Bias towards Go: Our collected data had significant bias towards Go. Given the lack of variety in our sample, we could not investigate the effect of language ecosystems, but other internal efforts indicated that language may significantly impact maintenance efforts. We encourage this line of investigation for future studies.
Only active projects: This effort did not include significant data collection on stale or archived packages.

Curious about our approach and findings? Read the full research report: “How much does it cost to maintain a copy of an open source software package (at Google)?”

Adopting Pyrefly as the Python type checker at Google

2026-10-06T11:30:00.000-07:00

by Amer Elsheikh, Python Team

Python is one of the primary languages at Google, powering everything from machine learning research to developer infrastructure and data pipelines. Across hundreds of thousands of files in our monorepo, fast and reliable static type checking is essential for maintaining code safety and developer velocity.

Today, Pyrefly—an open source type checker developed by Meta—is the Python type checker at Google.

Replacing our previous type-checking infrastructure with Pyrefly provided significant speedups for engineers and agents alike, while substantially reducing build-system compute resources.

Moving away from Pytype

For more than a decade, Google relied on Pytype, an internally developed type checker that pioneered Python type checking and collaborated with the open source community to create typeshed.

However, as Python’s typing system evolved rapidly, Pytype faced fundamental challenges. Because it operated by analyzing compiled bytecode rather than source ASTs, keeping pace with modern typing PEPs became an increasing maintenance burden due to bytecode instability across Python releases. In addition, it struggled to deliver the fast turnaround times required for modern development loops.

As detailed in the Pytype update, we decided that Python 3.12 would be the final supported version for Pytype, leading us to evaluate and adopt modern open source alternatives.

Why Pyrefly?

Pyrefly incorporates years of collective lessons from earlier tools across the Python typing ecosystem. When evaluating candidates to succeed Pytype, Pyrefly quickly stood out across three key areas:

Performance

Written in Rust, Pyrefly is designed for high throughput and lazy, parallel evaluation. In our internal benchmarks across various Google projects, it proved to be an order of magnitude faster than Pytype, while scaling smoothly across large dependency graphs.

Typing spec conformance

Pyrefly achieves strong conformance—scoring roughly 97% on the official typing conformance test suite—and is actively maintained to track new Python versions and typing PEPs. This comprehensive language support makes Python version upgrades across our monorepo smoother.

In addition to supporting new syntax, Pyrefly provides strict type safety in areas where Pytype was historically permissive. A notable example is unsound unions: Pytype allowed passing a value of a union type (such as int | None or int | str) to a function expecting a specific type (such as int), as long as at least one type in the union was compatible. However, Pyrefly enforces sound union checking, catching these mismatches:

# foo.py
def process_id(x: int) -> None:
    ...
def get_id() -> int | None:
    ...
val = get_id()
# Accepted by Pytype, but rejected by Pyrefly:
process_id(val)

Actionable error diagnostics

Pyrefly provides Rust-style compiler diagnostics, displaying the offending code snippet with inline annotations that point directly to the root cause of type mismatches, sometimes with suggested fixes. E.g., for the foo.py example above, Pyrefly produces:

ERROR Argument `int | None` is not assignable to parameter `x` with type `int` in function `process_id` [bad-argument-type]
 --> foo.py:8:12
  |
8 | process_id(val)
  |            ^^^
  |
  The declared type does not allow `None`. Consider narrowing the value with an `is not None` check.

Performance and infrastructure impact

Switching to Pyrefly brought measurable improvements across Google's developer ecosystem and infrastructure:

Up to 98% faster incremental rebuilds: In developer edit-and-rebuild workflows (with a warm daemon during active editing cycles), Pyrefly delivered up to a 98% latency reduction across various targets. On large machine learning targets, type-checking times dropped from minutes to seconds.
>90% critical-path reduction in clean builds: In cold-cache benchmark suites across major libraries and models, Pyrefly consistently reduced the type-checking share of the build critical path by 90% to 99%, eliminating a long-standing bottleneck in our build pipelines.
>80% compute hardware savings: Pyrefly reduced Google’s daily peak compute occupancy for Python type checking by more than 80%, saving thousands of machine cores every day.

To illustrate this impact on developer workflows, the chart below compares total edit-and-rebuild latency between Pytype and Pyrefly across targets of varying sizes.

Developer feedback

Beyond aggregate metrics, Pyrefly improved the day-to-day development loop, allowing engineers and AI coding agents to catch bugs faster.

Here is what engineers across Google have shared about their experience:

"I haven't waited for a Pytype action to complete since our project switched [to Pyrefly]. It is doubly awesome for agentic coding. Type checking is faster than running the tests now." — Peter Hawkins, JAX Tech Lead

"I really like that Pyrefly gives super clear errors that point out exactly what's wrong." — Yotam Doron, Gemini Large Scale Pretraining

“Investing in Python tooling pays huge dividends for research velocity: Pyrefly keeps our experimental iterations fast and catches subtle bugs early with clear, actionable errors.” — Tom Ward, GDM Science

Looking forward

Adopting Pyrefly highlights the value of uniting behind shared open source developer tooling. We are deeply grateful to the Pyrefly team for their rapid turnaround and responsiveness on upstream issues throughout our rollout. We look forward to continuing our collaboration and contributing to the Python open source community.

To learn more about Pyrefly or try it in your own projects, visit the Pyrefly website and the Pyrefly GitHub repository.

This Week in Open Source for October 2, 2026

2026-10-02T11:30:00.000-07:00

by Daryl Ducharme, Open Source Programs Office

This Week in Open Source for October 2, 2026

A look around the world of open source

As AI becomes part of everyday software development, the most compelling questions in open source are shifting from the models themselves to everything surrounding them. I’m always drawn to how technology affects individuals, and especially the workers who use and maintain it, for better or for worse (I definitely prefer better). That’s why I’m convinced the next phase of open-source AI won’t be won by chasing bigger benchmarks, but by building the open infrastructure, transparent local tooling, and community norms that keep developers and maintainers in control. This week’s reads explore what that looks like in practice.

Upcoming Events

🗓️ October 2026

ValkeyConf 2026 (October 5, 2026) — Prague, Czechia. Dedicated community conference advancing the open source Valkey in-memory data store, featuring a keynote by Valkey TSC member and Google Cloud engineer Jacob Murphy on open source in-memory data structures and scaling high-performance workloads.
MCP Dev Summit Toronto (October 5–6, 2026) — Toronto, Ontario, Canada. Dedicated Linux Foundation developer summit advancing the Model Context Protocol (MCP) and open agentic interoperability standards. Join Google OSPO's Daryl Ducharme (that's me!) on Tuesday, October 6 (11:00 AM EDT) for "Tag-Team Transmission: Navigating A2A and MCP for Optimum Orchestration," examining how the Agent2Agent (A2A) protocol and MCP interoperate across multi-agent architectures.
Open Source Summit Europe (October 7–9, 2026) — Prague, Czechia. The premier Linux Foundation gathering in Europe celebrating the 35th anniversary of Linux and connecting developers, technologists, and community leaders—including a keynote by Google OSPO's Erin McKean on Docsy and technical documentation for humans and AI agents.
Community Over Code (October 11–14, 2026) — Glasgow, Scotland. The flagship Apache Software Foundation conference bringing together project maintainers, committers, and users to collaborate on open governance, data architecture, and community-led software development.
BazelCon 2026 (October 13–15, 2026) — Amsterdam, Netherlands. Annual gathering of the Bazel community uniting build system engineers, maintainers, and ecosystem contributors around fast, reproducible, multi-language software builds.
All Things Open 2026 (October 19–20, 2026) — Raleigh, North Carolina, USA. One of the largest community-focused open source conferences on the U.S. East Coast exploring open source software, AI engineering, and maintainer sustainability—featuring a Google keynote on Generative UI and the Open Future alongside the Google Community Lounge with the Flutter team.
PyTorch Conference North America 2026 (October 20–21, 2026) — San Jose, California, USA. Two days of open source machine learning innovation covering training, inference, compiler toolchains, and hardware heterogeneity across the PyTorch ecosystem.
AGNTCon + MCPCon North America 2026 (October 22–23, 2026) — San Jose, California, USA. Linux Foundation conference focused on building and scaling production agentic AI systems with open standards, observability, and control, featuring a keynote by Google's Rao Surapaneni.
GitHub Universe 2026 (October 28–29, 2026) — San Francisco, California, USA & Virtual. Annual global developer gathering highlighting open source workflows, collaborative security, and 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.
KubeCon + CloudNativeCon North America 2026 (November 9–12, 2026) — Salt Lake City, Utah, USA. The Cloud Native Computing Foundation's flagship conference uniting adopters and maintainers around Kubernetes, platform engineering, and cloud-native infrastructure.
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.

Open Source Reads and Links

[Article] Mila and Mozilla announce new initiative to build trustworthy open source AI for everyone, with Canadian government support — As a Canadienthusiast, seeing Mozilla and Mila partner with the Canadian government on an open source AI foundation layer immediately grabbed my attention. The crossover of open source and public-sector sovereign systems seems clear on the surface, yet real-world adoption reveals unexpected decisions. How do we make open source and open models useful to governments—is it in the open source infrastructure around them?
[Article] Google’s open source EnvHarness lets AI agents train against environments that evolve with them — As AI adoption matures, the need for solid infrastructure around AI is becoming more evident. It is nice to see Google Research’s work leading to open source tools like EnvHarness, which adapts training sandboxes to an agent’s failure modes—and raises the question of how our evaluation infrastructure must evolve alongside the agents themselves.
[Blog] Inside LLM Inference: Every Calculation from Text to Token using Gemma 4 12B — LLM inference often feels like an opaque black box, making Amulya Bhatia’s calculation-by-calculation trace of a token moving through Google’s open source Gemma 4 12B fascinating to ponder. Seeing how hybrid attention bounds memory under the hood prompts a broader question: how differently do we design AI systems when we actually understand the math happening inside the model?
[Video] 100% Local RAG Without Internet: Qdrant Edge and Google LiteRT — GDE Tarun R Jain pairs Google LiteRT and Gemma 4 with Qdrant Edge to run retrieval-augmented generation 100% offline. It prompts an interesting question for system design: how differently do teams experiment with their knowledge bases when local prototyping is free—and how much of what we default to the cloud could stay on the edge?
[Post] UISurf: An Operator-Centric Multi-Agent Platform for Observable and Cross-Environment UI Automation — UISurf explores orchestrating UI agents across Web, Desktop, and Mobile boundaries using the open Agent2Agent (A2A) protocol. Beyond the tool itself, its lessons on sandboxing and human-in-the-loop oversight are worth pondering: when autonomous agents coordinate across environments, what level of observability do human operators actually need to stay in control?
[Article] PS5 Linux lead quits as open-source projects have become “a bunch of noobs using LLMs” that “they don’t even understand” — When maintainers leave high-profile projects like PS5 Linux, it is important to look at the reasons. In the age of AI-assisted software development, unvetted LLM code and shifting bounty incentives are straining both maintainers and community trust. What can we learn from these events as we update open source and AI governance best practices to keep projects safe, secure, and viable?

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.

Standardizing fine-grained access control in Apache Iceberg's REST catalog

2026-10-01T11:30:00.000-07:00

by Talat Uyarer & Sung Yun, Google Cloud

The Apache Iceberg community recently merged a change to the REST Catalog specification that gives lakehouses something they have long been missing: a standard, engine-neutral way to express column masking and row filtering. It is a small change, but it addresses a structural gap in how open table formats handle data governance. This post walks through the problem, the design, and why the details matter.

The problem: there is no server in the read path

In a traditional database, access control is straightforward because there is exactly one door. Every query passes through the database server, the server knows who is asking, and if policy says "this user only sees the last four digits of the card number," the server applies that policy before returning results. One process, one enforcement point.

Apache Iceberg deliberately removed that door. The data is Parquet files in object storage, and any engine—such as BigQuery, Spark, Trino, Flink, PyIceberg, or DuckDB—can read those files directly. This design is what makes Iceberg fast and interoperable. But it also means that once an engine asks the catalog "where is the payments table?" and receives the metadata pointer, it has full access to the files. The catalog can grant or deny access to the whole table, but it has had no vocabulary for "access granted, but mask the email column" or "access granted, but only on rows where region = 'US'."

Until now, Iceberg had no built-in answer to this. The REST spec did offer coarser instruments like credential vending, which controls storage access per table, and server-side scan planning, which lets a catalog withhold entire data files. But neither can express "mask this column" or filter rows that are not already physically separated into their own files. So users who needed fine-grained access control had to step outside the open protocol entirely. They could adopt a vendor-provided client that understands its proprietary policy format, or route every read through a vendor's proxy service, giving up the direct-to-storage performance that motivated the use of Iceberg in the first place. It also quietly undermines Iceberg's core promise: the moment governance requires a specific vendor's client, the table is no longer open to any engine.

The new read-restrictions field in the REST Catalog spec is the community standardizing that vocabulary.

The mechanism

When an engine calls loadTable, the response may now include an optional read-restrictions object:

Read restrictions are expressed in two fields:

required-row-filter: a standard Iceberg predicate expression. Rows for which it evaluates to false must not appear in the result, and no information derived from them may be included.
required-column-projections: a list of columns, identified by field ID, each with a transformation the reader must apply before returning values.

One evaluation rule ties them together: the row filter is evaluated against the original, untransformed column values, and projections are applied to the rows that survive. This ordering is what makes the two features composable. A policy can filter on region = 'US' and also mask region in the output, and the filter still works. If masking ran first, any policy that filtered on a masked column would silently break.

Note what the catalog is doing here. It evaluates the access policy server-side—it knows the caller's identity from the authentication token—and returns only the result of that evaluation. The policy itself, with its roles, tags, and governance model, never crosses the wire. The engine does not need to understand how any particular catalog models governance. It needs to understand nine actions and a predicate.

The whole architecture fits in one sequence:

The catalog stays the policy decision point; the trusted engine becomes the policy enforcement point; the end user never holds storage credentials. Sections below unpack the three load-bearing details in this picture: the enforcement ordering, the fail-closed branch, and the trust boundary.

The nine masking actions

The specification defines a closed set of nine masking actions, each with an exact, per-type definition. The goal is cross-engine consistency: Spark, Trino, and PyIceberg must produce identical output for any given masking action. These actions are being implemented in iceberg-core, providing engines with spec-compliant transformations out of the box rather than requiring them to reimplement byte-level logic independently.

Below, the actions are grouped by the analytical utility of the resulting masked data:

Preserve the shape, hide the value

mask-alphanum—digits become n, other characters become x, with a small allowlist of punctuation (( ) , . - @) preserved. iceberg16112018@apache.org becomes xxxxxxxnnnnnnnn@xxxxxx.xxx—recognizably an email address, but not whose.
show-first-4 / show-last-4—preserve four code points, and apply mask-alphanum to the rest. 4111-1111-1111-4444 becomes nnnn-nnnn-nnnn-4444, the familiar customer-support view of a card number.

Hide everything

replace-with-null—the value becomes NULL. Only valid for optional fields; a server must not return it for a required field, and a reader that receives one must fail the query.
mask-to-fixed-value—the value becomes a type-specific constant (0, "XXXXXXXX", the epoch, an all-zero UUID, an empty list, and so on, each spelled out in the spec). Uniquely among the actions, this one also replaces NULL inputs—even the null-or-not bit is hidden.

Reduce precision

truncate-to-year / truncate-to-month—2024-07-15 becomes 2024-01-01 or 2024-07-01. Cohort analytics keeps working; identifying individuals gets harder.

Allow joins, hide values

sha-256-global—deterministic SHA-256, with exact byte-encoding rules per input type. The same input always produces the same output, everywhere, so GROUP BY user_id and joins across tables on a hashed key still work. The cost of that determinism is that hashed values can be tested against precomputed guesses—this is pseudonymization, not encryption.
sha-256-query-local—the same hash, salted with a fresh, cryptographically random salt (at least 16 bytes) per query. Values remain consistent within a single query, so self-joins and aggregation work, but cannot be correlated across queries, and precomputed-guess attacks no longer apply.

This last pair is a nice piece of design: the tradeoff between linkability and privacy, expressed as two enum values that a policy author chooses between per column.

Every action produces a value of the same type as its input—masked strings are strings, truncated dates are dates—so restrictions never change the schema an engine plans against. Queries do not need rewriting; values simply arrive transformed.

Fail-closed by design

The most consequential sentence in the specification is this one:

If a trusted reader that supports read-restrictions cannot apply any returned restriction, it must fail the query and must not silently return raw, partial, or empty results.

Consider the failure modes. A catalog sends an action added in a future spec version that the engine does not recognize. Or an expression type it cannot evaluate. The convenient behavior would be to skip what it does not understand and return the data. The spec rules this out: unrecognized action, fail; unparseable filter, fail; duplicate field ID in the projections, fail. Every ambiguity resolves to "no data" rather than "raw data." This is the right default for an access control mechanism, and it is also the one implementers would be tempted to soften—which is exactly why it is normative in the spec rather than left to judgment. It is also what allows the action vocabulary to grow in future versions without older engines becoming silent leak vectors.

A few prohibitions in the spec reward a closer look, because each one closes a subtle correctness hole:

No projections on map keys. Masking a map's keys can collapse two keys into one, or produce null keys, which engines silently coalesce or reject—data corruption presented as privacy. The spec bans it outright.
No projection on both a nested type and a field inside it. Masking a struct and also a field within that struct has no well-defined order of operations, so the spec refuses to define one: servers must not send it, and readers must reject it.
Everything references field IDs, never column names. This is standard Iceberg discipline: if ssn is renamed to national_id, the policy remains bound to the same physical column. A name-based policy would silently detach on rename—the worst possible failure mode for access control.

The trust model, stated plainly

All of this is enforced by the reader. The catalog hands the engine the file locations along with the restrictions, and a client that chooses to ignore the restrictions can read the raw files. So what is this actually protecting?

The specification is explicit: this mechanism assumes a trust relationship between the catalog and the engine, and how that trust is established is deliberately out of scope. The intended deployment is one where a platform team's engines—the shared Spark and Trino clusters—are trusted enforcement points that hold storage access (for example, through credential vending), while end users only ever talk to those engines and never hold storage credentials themselves. The trusted engine becomes the enforcement point, playing the role the database server played in the traditional architecture. The difference is that its behavior is now defined by a common, open protocol rather than by N proprietary integrations.

In other words, read restrictions do not protect data from the engine; they let the catalog direct a trusted engine to protect data from the engine's users. For genuinely untrusted readers, the coarse-grained model still applies: they are restricted to vended credentials where the storage access granted to the user aligns with the data permission of the user.

One operational subtlety deserves attention: restrictions are per-response and per-identity. The same loadTable call made by a different principal—or by the same principal later—may return different restrictions, and the restrictions attach to every read performed with that response, including subsequent planTableScan and fetchScanTasks calls. The spec therefore requires that the response not be cached outside its authentication scope. If your platform caches loadTableResponse, that cache is now security-sensitive and worth an audit.

What is still missing

Read restrictions are a foundation, not the finished building. It is worth being honest about the gaps between this specification and complete fine-grained access control:

The action vocabulary is fixed, because Iceberg Expressions are not implemented yet. Nine actions cover the common masking policies, but they are a deliberately closed set: a policy like "apply this custom redaction function" cannot be expressed, and the row filter is limited to predicates—comparisons that produce true or false. The path to generalizing this already exists on paper: the Iceberg Expressions specification, proposed by Ryan Blue and adopted in mid-2026, defines a portable structure for value expressions—constants, field references, and calls to well-defined functions or SQL UDFs. Once engines can evaluate those expressions, a catalog could return arbitrary transformations instead of choosing from an enum. Today no engine implements general expression evaluation, which is why the initial design confines itself to a small vocabulary that can be specified bit-for-bit.
There is no policy definition—deliberately. The specification standardizes the result of policy evaluation, never the policy itself. How an organization expresses "analysts see masked PII, auditors see everything"—the roles, tags, rules, and administrative APIs—remains entirely the catalog vendor's domain, and the assumption is that it stays there. Only the consequences of a policy are portable across engines; the policy definition is not. Whether communities eventually want a portable policy format is an open question the spec does not attempt to answer.
Trusted clients are asserted, not proven. As the trust-model section noted, how a catalog establishes that a caller is a trusted, enforcing engine is out of scope. In practice that trust is deployment configuration—service identities, network boundaries, and which principals receive vended credentials. There is no attestation mechanism in the protocol by which an engine proves it enforces restrictions; the trusted-client mechanism is an assumption the platform operator must make true.

None of these gaps undermines the design—each is a deliberate scoping decision that kept the proposal small enough to reach consensus—but they define the roadmap for what "complete" fine-grained access control in the open lakehouse still requires.

Why this matters

The specification change itself does not ship enforcement; that work in the engines begins now, starting with the default actions. But the shape of the design is right in three ways:

It picks the honest enforcement point. In an architecture with no server in the read path, the trusted engine is the only place enforcement can live without giving up direct storage reads. The spec accepts that constraint explicitly rather than obscuring it.
It standardizes the narrow waist. Catalogs keep their own rich policy engines—roles, tags, and attribute-based rules. Engines implement nine actions and a predicate evaluator, once. N×M becomes N+M.
It is fail-closed everywhere, which is what makes the vocabulary safely extensible.

The pattern—the catalog evaluates policy against the caller's identity and returns a small, closed vocabulary of obligations that the client must enforce or fail—is a useful template, and it would not be surprising to see more of the governance surface expressed this way over time.

The proposal was approved on the Apache Iceberg dev list with eight binding +1 votes and no objections. This is a strong signal of consensus across the many companies and open source communities that participate in the project. Consistent, engine-independent enforcement of fine-grained policies is a property the ecosystem has long wanted; it now has a specification for it, and the interesting work of implementing it in engines and catalogs is underway. If you work on either, the dev list is the place to get involved.

The full schema is available in rest-catalog-open-api.yaml under ReadRestrictions. View the full vote thread.

New public datasets available in Google Cloud Lakehouse

2026-09-30T11:30:00.000-07:00

by Daniel Rodrigues & Alex Stephen, Google Cloud

Did you know the Google Chrome Wikipedia page received over 36 million page views in 2025, or that Chromium logged over 3,700 commits in April 2010? If you have needed large, real-world datasets to benchmark query engines on Apache Iceberg, Google Cloud’s Lakehouse team is excited to announce the release of new public datasets in Google Cloud Lakehouse to help you explore and analyze open data at scale.

Google Cloud’s Lakehouse provides a high-performance storage catalog using Apache Iceberg as its open table format. By decoupling storage from compute, it enables you to use your preferred query engines—such as BigQuery, Apache Spark, or Trino—while managing data in an open format to avoid vendor lock-in.

These new public datasets are designed to help you explore the Apache Iceberg ecosystem and begin working immediately with real-world data. We are providing access to some of the most popular BigQuery public datasets, including Wikipedia pageviews and GitHub commit histories. Let’s dive into how you can start querying them.

Prerequisites

A Google Cloud project (for authentication).
Standard Google Application Default Credentials (ADC) configured in your environment.

Explore metadata with PyIceberg

To explore table metadata using PyIceberg, install the required Python packages in a virtual environment:

sudo apt-get install python3-venv
python3 -m venv public_data_lakehouse
source public_data_lakehouse/bin/activate
pip install google-auth
pip install pyiceberg
pip install pyarrow

After installing the required packages, you can inspect a table’s schema using the Python script below. Here is how to inspect the table containing Wikipedia page view data from 2016:

from pyiceberg import catalog as pyiceberg_catalog

PROJECT = "<YOUR_PROJECT_ID>"
NAMESPACE = "wikipedia"
TABLE = "pageviews_2016"

def load_catalog() -> pyiceberg_catalog.Catalog:
  properties = {
      "type": "rest",
      "uri": "https://biglake.googleapis.com/iceberg/v1/restcatalog",
      "warehouse": "gs://lakehouse-public-data",
      "auth": {"type": "google"},
      "header.X-Iceberg-Access-Delegation": "vended-credentials",
      "header.x-goog-user-project": PROJECT,
  }
  return pyiceberg_catalog.load_catalog(PROJECT, **properties)

def main() -> None:
  catalog = load_catalog()
  table = catalog.load_table((NAMESPACE, TABLE))
  print(f"Schema for `{NAMESPACE}.{TABLE}`:", table.schema())

if __name__ == "__main__":
  main()

Note: Replace <YOUR_PROJECT_ID> with your actual Google Cloud Project ID. This is required for the REST catalog to authenticate your quota usage, even for free public access.

PySpark and Managed Service for Apache Spark

Now that we have explored the table’s schema, we can use a managed, serverless Spark notebook to query the tables. This provides the speed and flexibility of Apache Spark without creating or managing a cluster. You can run this script in Google Cloud's serverless Managed Service for Apache Spark (formerly Dataproc):

from google.cloud.dataproc_v1 import Session
from google.cloud.dataproc_spark_connect import DataprocSparkSession

PROJECT_ID = "<YOUR_PROJECT_ID>"
spark_catalog = "lakehouse-public-data"

session = Session()
session.runtime_config.properties = {
  "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
  f"spark.sql.catalog.{spark_catalog}": "org.apache.iceberg.spark.SparkCatalog",
  f"spark.sql.catalog.{spark_catalog}.type": "rest",
  f"spark.sql.catalog.{spark_catalog}.uri": "https://biglake.googleapis.com/iceberg/v1/restcatalog",
  f"spark.sql.catalog.{spark_catalog}.rest.auth.type": "org.apache.iceberg.gcp.auth.GoogleAuthManager",
  f"spark.sql.catalog.{spark_catalog}.io-impl": "org.apache.iceberg.gcp.gcs.GCSFileIO",
  f"spark.sql.catalog.{spark_catalog}.header.X-Iceberg-Access-Delegation": "vended-credentials",
  f"spark.sql.catalog.{spark_catalog}.warehouse": "gs://lakehouse-public-data",
  f"spark.sql.catalog.{spark_catalog}.header.x-goog-user-project": PROJECT_ID,
}

spark = (
   DataprocSparkSession.builder
     .appName("Lakehouse Public Data Demo")
     .dataprocSessionConfig(session)
     .getOrCreate()
)
spark.conf.set("spark.sql.defaultCatalog", spark_catalog)

With the session active, you can query monthly Wikipedia view counts for BigQuery-related articles by executing the following code in a new cell:

df1 = spark.sql("""
SELECT
  title,
  wiki,
  SUM(views) AS total_views
FROM wikipedia.pageviews_2026
WHERE datehour >= TIMESTAMP '2026-01-01 00:00:00'
  AND datehour <  TIMESTAMP '2026-02-01 00:00:00'
  AND LOWER(title) LIKE '%bigquery%'
GROUP BY title, wiki
ORDER BY total_views DESC
LIMIT 20
""")
df1.show(10)

Or, you can retrieve recent GitHub commits referencing Iceberg using the following snippet:

df2 = spark.sql("""
SELECT
  commits.commit,
  commits.subject,
  commits.message,
  commits.author.name AS author_name,
  timestamp_seconds(commits.committer.date.seconds) AS commit_time,
  repo_name
FROM github_repos.commits AS commits
WHERE LOWER(commits.subject) LIKE '%iceberg%'
   OR LOWER(commits.message) LIKE '%iceberg%'
ORDER BY commit_time DESC
LIMIT 50
""")
df2.show(10)

Start building today

These datasets were imported from their BigQuery counterparts and transformed using Apache Iceberg as the table format and Parquet as the data file format. Our goal is to lower the entry barrier so you can learn and explore Apache Iceberg with your favorite query engine without managing any infrastructure. To get started with building an open, managed, and high-performance Iceberg lakehouse, visit the Google Cloud Lakehouse page.

This Week in Open Source for September 24, 2026

2026-09-24T11:30:00.000-07:00

by Daryl Ducharme, Open Source Programs Office

This Week in Open Source for September 24, 2026

A look around the world of open source

Open source underpins an $8.8 trillion global economy, yet sustaining it requires moving beyond voluntary charity and philosophical appeals. This week’s reads examine how the ecosystem is adapting to modern economic and AI pressures—from proposing package-registry royalties and quantifying 2–5x net value for regulated utility grids, to turning autonomous AI security incidents into hardened supply-chain defenses that empower open-science breakthroughs like NASA and IBM’s Lunar Foundation Model.

Upcoming Events

🗓️ October 2026

MCP Dev Summit Toronto (October 5–6, 2026) — Toronto, Ontario, Canada. Dedicated Linux Foundation developer summit advancing the Model Context Protocol (MCP) and open agentic interoperability standards. Join Google OSPO's Daryl Ducharme on October 6 for "Tag-Team Transmission: Navigating A2A and MCP for Optimum Orchestration," examining how the Agent2Agent (A2A) protocol and MCP interoperate across multi-agent architectures.
Open Source Summit Europe (October 7–9, 2026) — Prague, Czechia. The premier Linux Foundation gathering in Europe celebrating the 35th anniversary of Linux and connecting developers, technologists, and community leaders across open AI, embedded systems, and digital trust.
Community Over Code (October 11–14, 2026) — Glasgow, Scotland. The flagship Apache Software Foundation conference bringing together project maintainers, committers, and users to collaborate on open governance, data architecture, and community-led software development.
All Things Open 2026 (October 19–20, 2026) — Raleigh, North Carolina, USA. One of the largest community-focused open source conferences on the U.S. East Coast exploring open source software, AI engineering, DevSecOps, and maintainer sustainability.
GitHub Universe 2026 (October 28–29, 2026) — San Francisco, California, USA & Virtual. Annual global developer gathering highlighting open source workflows, collaborative security, and 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.
KubeCon + CloudNativeCon North America 2026 (November 9–12, 2026) — Salt Lake City, Utah, USA. The Cloud Native Computing Foundation's flagship conference uniting adopters and maintainers around Kubernetes, platform engineering, and modern cloud infrastructure.
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.

Open Source Reads and Links

[Blog] Nobody pays for open source. We can force them to. — Companies already spend over $1 billion a year on open source, but that money goes to supply-chain mirror and security vendors rather than the maintainers writing the code. Laurie Voss breaks down why voluntary charity and license changes always fail, arguing that commercial package registries and mirror vendors should pay automatic royalties down the dependency tree to long-tail maintainers.
[Article] AI Is reshaping open source software and straining the systems that sustain it — As conversations grow around moderating the speed of AI development across the industry, it is critical to watch the friction points where AI and open source overlap—particularly as an influx of AI-generated code and vulnerability discovery strains maintainers of an $8.8 trillion ecosystem. Funding remains front and center, requiring not just raw capital but continuous monitoring for effectiveness in sustaining the human governance, consensus-building, and non-coding infrastructure that AI cannot replace.
[Report] LF Energy Research Finds Open Source Software Can Deliver 2-5x Greater Net Value for Grid Operators — While open source software and public utilities seem like natural philosophical allies as public goods, philosophical appeals routinely fail in regulated infrastructure sectors where operators are bound by strict reliability mandates and ratepayer accountability. This new LF Energy report demonstrates how to bridge that gap: by translating collaborative "make together" governance into an auditable benefit-cost framework showing two to five times greater net value over proprietary procurement.
[Article] AI Is at a Turning Point — High-profile incidents of autonomous AI agents breaching Hugging Face or social-engineering open source maintainers inevitably dominate headlines and amplify purely negative narratives around AI. However, treating these security failures as concrete post-mortems—exposing how standard reinforcement learning incentivizes deceptive subgoals—is exactly what allows open source communities to establish hardened supply-chain defenses and safely advance high-impact, positive AI use cases.
[Article] IBM and NASA Release Open-Source AI Model to Support Lunar Exploration — Seeing open source, AI, open data, and space science converge is genuinely inspiring, especially when it demonstrates that open scientific models are only as useful as the open datasets beneath them. While NASA and JAXA planetary archives have long been public, IBM and NASA's release of the Lunar Foundation Model alongside the first harmonized, machine-learning-ready lunar dataset (unifying 30+ multi-instrument layers) proves that transforming raw open data into shared, interoperable infrastructure is what unlocks domain discovery.

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.

Google Cloud: Investing in the future of PostgreSQL — 2026 highlights

2026-09-23T11:30:00.000-07:00

by Dilip Kumar, Cloud SQL for PostgreSQL

Google Cloud is committed to open source, and PostgreSQL is a cornerstone of managed database offerings, including Cloud SQL and AlloyDB.

Continuing our work with the PostgreSQL communities, we've been contributing to the core engine and participating in the patch review process. Below is a summary of that technical activity between January 2026 and September 2026, highlighting our efforts to enhance the performance, stability, and resilience of the upstream project and ecosystem. By strengthening these core capabilities, we aim to drive innovation that benefits the entire global PostgreSQL ecosystem and its diverse user base.

Our technical contributions in this period have focused on enhancing core engine performance, introducing features for logical replication, fixing critical bugs, and improving upgrade resilience. We also continue to invest in the PostgreSQL ecosystem by addressing bugs in widely used extensions.

Technical contributions: January 2026 – September 2026

Our contributions this cycle span four key areas:

Logical replication and conflict management: Paving the way for active-active replication, enhanced conflict logging, and catalog safety.
Core engine performance and reliability: Eliminating tuple-level overhead in sequential scans and making promotion timeouts accurate.
Core catalog, collation, and indexing bug fixes: Strengthening privilege consistency, deferrable index builds, collation handling, and memory safety.
PostgreSQL extension and ecosystem hardening: Resolving critical crashes, lock tranche registrations, and memory vulnerabilities across popular ecosystem extensions (plpgsql_check, pgfincore, and pgtt).

1. Logical replication and conflict management

Logical replication is essential for near-zero downtime migrations, major version upgrades, and multi-region data distribution. Our recent work focuses on conflict log table infrastructure, namespace clarity, and cross-database catalog hygiene.

Conflict log table infrastructure

Background and challenge: A major milestone on the roadmap to active-active multi-master replication is the ability to automatically record and resolve data discrepancies across nodes. Without structured conflict logs, tracking conflicting writes requires inspecting server logs or relying on custom application handlers.
Solution: This patch introduces the foundational conflict log table management infrastructure as an option in CREATE SUBSCRIPTION. It establishes the catalog structures and configuration hooks necessary to direct conflict records into dedicated, queryable tables, serving as the cornerstone for upcoming automatic conflict logging into tables.
Note: Provided no blocking issues arise, this functionality is slated for inclusion in PG 20.
Contributors: Dilip Kumar (Primary Author)

Fix REASSIGN OWNED for subscriptions in other databases

Background and challenge: While pg_subscription is physically a shared catalog so the background launcher process can scan all databases, subscription objects are logically local to each database. Certain operations, such as REASSIGN OWNED, failed to restrict their catalog scans to the current database (MyDatabaseId), leading to accidental modifications across database boundaries.
Solution: Added explicit guards to pg_subscription readers to ensure non-launcher processes filter strictly by MyDatabaseId, protecting cross-database isolation and updating documentation.
Contributors: Dilip Kumar (Author)

Schema-qualified names in EXCEPT clause error messages

Background and challenge: When publishing tables with EXCEPT clauses, check_publication_add_relation() previously reported only unqualified table names when a relation could not be processed, leading to ambiguous error messages in multi-schema databases.
Solution: Updated error reporting paths to emit fully schema-qualified relation names, aligning with PostgreSQL's broader error messaging standards.
Contributors: Dilip Kumar (Author)

2. Core engine performance and administrative enhancements

Optimizing throughput and improving the predictability of administrative operations remain top priorities for database workloads.

Timeout handling in pg_promote()

Background and challenge: Standby promotion via pg_promote() allows users to specify a timeout interval. Due to imprecise elapsed-time tracking during wait loops, promotion operations could terminate prematurely before the configured timeout elapsed.
Solution: Refined the promotion loop to pre-calculate the expected end timestamp and track actual elapsed time across iterations, ensuring strict adherence to user-configured wait intervals.
Contributors: Robert Pang (Reporter and Author)

Sequential scan performance optimization

Background and challenge: Previously, CheckXidAlive validation was executed inside the inner table_scan_next routines. This incurred repetitive check overhead on every single tuple fetched during sequential scans.
Solution: Restructured the scan control flow to eliminate redundant per-tuple checks, yielding cleaner execution paths and measurable throughput improvements on large table scans.
Contributors: Dilip Kumar (Author)

3. Core engine access control, collation, and indexing bug fixes

We continue to harden PostgreSQL's core engine against catalog inconsistencies, segmentation faults, and edge-case query anomalies.

Large object access with pg_{read,write}_all_data

Problem: The default roles pg_read_all_data and pg_write_all_data were designed to allow maintenance utilities like pg_dump to operate without superuser privileges. However, Large Objects (LOBs) remained inaccessible under these roles without explicit object-level grants.
Fix: Updated permission checks to extend pg_read_all_data and pg_write_all_data coverage to Large Objects, completing superuser-free dump and maintenance workflows.
Contributors: Nitin Motiani (Author), Dilip Kumar (Reviewer)

Immediate property propagation in index copies (REINDEX CONCURRENTLY)

Problem: When building a replacement index during REINDEX CONCURRENTLY for a deferrable unique constraint, index_create_copy() defaulted constraint flags to 0, setting the immediate property to true. This caused concurrent transactions to immediately trigger constraint violations rather than deferring verification until commit time.
Fix: Introduced the INDEX_CREATE_DEFERRABLE flag to properly propagate an immediate property of false to transient copied indexes without violating internal constraint assertions.
Contributors: Nitin Motiani (Author)

LIKE matching with nondeterministic collations and backslashes

Problem: Following the addition of nondeterministic collation support for LIKE, literal pattern substring parsing unconditionally skipped all backslash characters. When encountering escaped backslashes (\\), the engine omitted the second backslash entirely instead of emitting a literal \.
Fix: Corrected pattern de-escaping logic to correctly recognize and emit escaped backslashes during evaluation.
Contributors: Nitin Motiani (Author)

DSM lock release and crash prevention

Problem: If a backend encountered a FATAL exit while holding a lock in a Dynamic Shared Memory (DSM) segment (e.g., inside dynamic shared hashtables dshash) outside of an active transaction, releasing locks during process termination could reference already detached DSM segments, triggering a segmentation fault.
Fix: Hardened cleanup and lock release sequences during fatal exits to safely detach memory segments without segfaulting.
Contributors: Dilip Kumar (Reviewer)

4. PostgreSQL ecosystem and extension hardening

Enterprise PostgreSQL architectures rely heavily on third-party extensions. Our team actively contributes bug fixes and stability improvements upstream to critical ecosystem projects.

plpgsql_check: LWLock tranche registration for PG14

Problem: In PG14 and earlier, loading plpgsql_check via shared_preload_libraries could fail with shared memory lock errors due to missing or outdated named LWLock tranche registrations (plpgsql_check profiler funcs stats and plpgsql_check profiler func stmts stats).
Fix: Aligned pre-PG15 tranche initialization with modern shmem_request_hook patterns, guaranteeing safe shared memory allocation on older server versions.
Contributors: Aniket Jha (Author)

pgfincore: Memory safety hardening

Problem: pgfincore contained two subtle memory corruption issues: an off-by-one array boundary access during buffer inspection and a dangling pointer assignment during deallocation.
Fix: Authored patches to enforce strict boundary checks and clean pointer resets, eliminating potential memory corruption during OS buffer cache analysis.
PRs: klando/pgfincore#12 and klando/pgfincore#13
Contributors: Robert Pang (Author)

pgtt: Use-after-free prevention on cached plans

Problem: When running utility commands via the extended query protocol or within cached contexts (such as PL/pgSQL and SQL functions), pgtt modified cached statement parse trees in-place using short-lived query memory. Once that memory was freed, subsequent executions of the cached plan led to Use-After-Free crashes.
Fix: Updated the extension to operate on an isolated, deep copy of the parse tree for cached and read-only statements, ensuring memory safety across repeated executions.
Contributors: Sunaina Punyani (Author)

Community roadmap: Your feedback matters

We encourage you to utilize the comments area to propose new capabilities or refinements you wish to see in future iterations, and to identify key areas where the PostgreSQL open source communities should focus their investments.

Acknowledgments

We would like to celebrate our engineers for their ongoing dedication to open source:

Dilip Kumar (PostgreSQL Significant Contributor): Authoring and reviewing core replication, catalog, memory, and performance patches.
Nitin Motiani: Authoring core privilege expansions, collation de-escaping, and indexing constraint fixes.
Robert Pang: Authoring promotion timing fixes and hardening pgfincore memory safety.
Aniket Jha: Hardening plpgsql_check shared memory lock mechanics.
Sunaina Punyani: Resolving memory and execution safety in pgtt.

We also extend our sincere gratitude to the wider PostgreSQL open source communities—especially the committers, reviewers, and extension maintainers—for their collaborative reviews and shared commitment to keeping PostgreSQL the world’s most advanced open source database.

Reconnecting with the heart of open source: Highlights from our 2026 GSoC India tour

2026-09-17T11:30:00.000-07:00

by Mary Radomile, Stephanie Taylor & amanda casari, OSPO

For over twenty years, Google Summer of Code (GSoC) has welcomed new developers into open source by pairing them with experienced mentors on real projects. This spirit is especially vibrant in India, which is home to more than 55% of all global GSoC participants over the last decade.

This July, our team traveled across Bengaluru and Delhi to host a series of developer events and debut our first-ever GSoC Alumni CAMP, bringing together members of India’s vibrant GSoC alumni community. We engaged directly with current and former GSoC Contributors, Mentors, and project maintainers, experiencing firsthand the passion and energy of the Indian developer ecosystem.

Community stories: Learning to think and lead as an engineer

In both Bengaluru and Delhi, a highlight of the trip was hearing directly how open source and GSoC have fundamentally changed how developers think and work.

For many attendees, having a dedicated open source mentor through GSoC took the fear out of tackling new and intimidating codebases. One former participant told us they almost walked away from a distributed storage project because it felt too overwhelming: "Storage systems felt impossible. But great mentors taught me how to think, not just how to code." Another echoed that shift in perspective: "Why am I spending so much time thinking rather than coding? Then I realized that building products is actually about thinking more than coding. GSoC taught me to think like an engineer."

That shift in mindset turns first-time contributors into long-term open source community leaders. We met one developer who submitted their very first pull request in 2023, started mentoring in 2024, and is now a lead maintainer for a major open source Android app. We also saw how new contributors to global projects can spark entire local ecosystems—like the Indian compiler community, which started with a few GSoC alumni and has rapidly grown into a 3,500+ member network with dozens of meetups across the country.

The Google Summer of Code Alumni CAMP — Bengaluru

Open source mentorship in the age of AI

Across our sessions and unconference discussions, one recurring conversation resonated above all others: the evolving role of mentorship in an AI-assisted world. The human element of open source is more critical than ever. As one attendee noted:

AI can generate the slides, but the context takes nine years.

We heard over and over from participants—open source maintainer time and attention remains a limited resource. CAMP participants presented multiple examples of where AI is proving effective for generating starter templates, writing tests, or fixing syntax. Even with this, what open source projects fundamentally need hasn't changed: maintainer time, clear architectural vision, and thoughtful code reviews.

Beyond code quality, the industry agrees that dedicated mentorship is the vital bridge between temporary contributions and long-term project stewardship. Without structured guidance, newcomers often struggle with unwritten project norms, complex codebase histories, or public review feedback, leading to contributor burnout and abandoned pull requests. Programs like GSoC transform casual interest into a sustainable maintainer pipeline by fostering psychological safety, belonging, and accountable relationships. By investing directly in maintainer time and human connection, GSoC ensures that open source projects remain secure and resilient for generations to come.

What’s next?

If our trip across Bengaluru and Delhi taught us anything, it’s that the strength of open source has always come from the communities we build together, not the volume of code any one person can ship.

As developer tools evolve, our main focus for GSoC is preserving the mentorship experience that makes the program special. Manually sifting through low-quality, automated submissions wastes maintainer time and drains the energy of volunteers who signed up to mentor new peers and colleagues. We're ready to tackle these challenges directly by optimizing our program to assist and protect our community of open source maintainers, so they can focus on leading their open source projects and helping new engineers grow. You can stay updated on GSoC’s program rules and timelines at g.co/gsoc.

To everyone who joined us in Bengaluru and Delhi—thank you for your energy, your endless inspiration, and your dedication to open source!

How much should you trust your OSS data?

2026-09-03T09:00:00.000-07:00

by Sophia Vargas, Google Open Source & Andrew Nesbitt, Ecosyste.ms

Every second, open source contribution quietly shapes the software we rely on, and yet our view of this open ecosystem is surprisingly opaque. Open source development is performed in public spaces — we can see the commits, issues and comments, the APIs and endpoints are free to use — the logs are just sitting there, so why can’t we just collect all of the data?

…Said every researcher, everywhere. However in most cases of open source related data, we are only looking at part of the whole. Why am I writing this post? Because many of us (including many business decision-makers) are too comfortable with unsubstantiated data. We’ve gotten used to it. Our models assume that it's smelly and we adjust the logic and weights to compromise. When it comes to open source, our confidence is even lower, even though our resulting decisions can directly impact individuals whom we collectively depend on.

Let’s consider one of my favorite datasets: GHarchive. Started as a hobby project in 2011, this crawler has amassed more than 15 years of event data from GitHub. While this source provides a historical record of open source development on GitHub, as a real-time or comprehensive source of metrics, it's unreliable and should not be a source for volume-based metrics.

In 2025, GHarchive captured 14% fewer events than in 2024, despite steady growth in platform adoption. Since 2025, we estimate that data retention in GHarchive has fallen to ~50% and in 2026 it may be as low as 20% for some event types (see figure below). Prior to 2025, you could make the general assumption that the majority of events would be represented in this pipeline. Since 2025, we must now assume we may be missing at least half of events and possibly more — not to mention all of the additional activity that’s left out of the event API (see GitHub’s GraphQL API.)

The crawler logic behind this dataset is simple: give me all the events from the GitHub Event stream (e.g. opening pull requests, commenting on issues etc). However, the GitHub API has limitations on the number of calls per hour as well as the number of events listed, so for days with a lot of spiky activity, the crawler will miss some. Although we never assumed that this dataset was collecting 100% of events, the current architecture is showing signs of strain. We suspect that this is due, in part, to the rate of repository growth and adoption of automated tooling on GitHub. In 2011, GitHub announced it reached 2 million public repositories, and by 2026, that figure surpassed 400 million.

I want to acknowledge that building and sharing comprehensive open datasets at scale is hard. Have you ever built a pipeline only to discover that the variables changed mid year, the payload for one output is getting truncated, all your joins broke because one side of the dataset is case sensitive … I could go on. And these examples are just ordinary data issues. Building a dataset at the scale of GitHub where “Every second, more than one new developer on average joined GitHub—over 36 million in the past year”—you start running into a new set of challenges.

My own journey with open source related data began when I repeatedly found myself questioning how much we could trust our own metrics. To expand my understanding of the nuances and the limitations of open source related datasets, I reached out to Andrew Nesbitt, who has spent years digging in data trenches for the benefit of the community. Together we converged on the following issues that we wanted to highlight for the broader community.

Assembling: Assume there will be problems

When I asked Andrew ‘can you summarize the challenges you have faced assembling comprehensive datasets?’ —“I just assume I'm going to have a terrible time anyway, so I start with my best effort and fill in the gaps”. While disappointing, this aligned with most data aggregation methods I’ve reviewed—tools such as Grimoire labs and OSS insights also require multiple processes for collection, combination and reconciliation. Even with these approaches, many sources have missing, incomplete, or inconsistent information.

One source is probably not enough. If you are considering the use of an open source project, you may want to know how many maintainers work on this project, what versions are available, what their dependencies are and any active vulnerabilities or known issues. Each of these queries requires a distinct source—the development history, the dependency graph, the CVE database, etc. Ecosyste.ms strives to pull this information together into one place, but combining data from 1000+ datasets has its own unique set of challenges.

For example, my index is probably not your index. One perennial issue is inconsistent naming conventions across sources. Beyond variable type and format, repository names, versions, packages, tags, licenses, urls, etc. tend to be unique across platforms. Some are case sensitive, there are often duplicates, and anyone can change a name at any time… I’ve been keenly following the adoption of purl and SWHID, but so far I have not found one name to rule them all.

Now we have to keep this up to date: At the moment, there is no consistent way of sharing updates across platforms. Changes to names, APIs, deletions, etc. are more often discovered by errors and breakage than by scouring release notes. To keep Ecosyste.ms up to date, Andrew has written multiple syncing processes that identify or infer updates that need to be accounted for. I asked Andrew ‘If you could ask a platform/data source to change one thing, what would it be?’, “Can I crawl an endpoint that's just NEW stuff?’

Consuming: Design your pipeline for your use case

Because of LLMs, “it's now easier for anyone to try to access and build reports”. But those building quick reports are likely not going to go through the pain of being comprehensive. This is where aggregated sources like GHarchive and Ecosyste.ms thrive. As data providers, we’d love if data consumers knew that:

How you collect data matters. If everyone wanted the same dataset, in the same format, at the same time, it would be simple. Depending on how the data is stored—centralized vs distributed and cached, relational vs graph, etc. —queries could be more efficient (in cost and computation) than exports or bulk requests faster than individual requests. This all depends on the topology of the infrastructure and the dataset. In a perfect world, data producers would design their architecture for their top user journeys. However open source related datasets serve a wide variety of user personas from corporations to non-profits, researchers to individual users, maintainers, funders, and many more, with a variety of demands from historical deep dives to realtime feedback. Data producers can’t design for all of these cases, so my challenge to them is to be more open about the best way to access this information.

At the end of the day, we have to respect the human infrastructure: Open source-related datasets are riddled with personally identifiable information (PII). Some individuals may be comfortable sharing their information with fellow contributors, but seeing it aggregated across platforms can be uncomfortable. Any source with PII should be handled with care: anonymize when you can and ensure you are in alignment with policies and regulations. Open source communities are real people so please, consume their data responsibly.

Interpreting: Never stop asking questions

While many have moved on from ‘data-driven’ to ‘AI-enabled’, the fact remains that ALL AI SYSTEMS DEPEND ON DATA. Our data about open source will continue to be incomplete and imperfect, but by asking questions about our sources, acknowledging the gaps, and considering both the technical and human processes behind open source development, we can refine and improve on how we interpret our insights and models even if they don’t completely reflect reality.

Securing the agentic era: Introducing formal verification for CEL

2026-08-18T11:30:00.000-07:00

by Sean Huh, Common Expression Language Team

We are rapidly entering an era where AI agents can autonomously draft, refactor, and deploy policies that protect our users and our systems. But this velocity introduces a vital question: How do we trust AI-generated policies?

Unit tests may fail to cover the infinite set of possible inputs that occur in production; thus, an AI agent that overfits its policy to existing tests may fail spectacularly in production. To secure automated policy authoring, we must combine heuristic testing with mathematical proofs.

We are thrilled to announce the Common Expression Language (CEL) Formal Verification Framework is now available. Powered by the Z3 theorem prover, this framework allows you to prove the correctness of your CEL expressions and policies, serving as the ultimate safety net for the agentic policy.

Automated reasoning definitively answers questions like:

“Is there any combination of inputs that allows an unapproved request into production?”
“Are we absolutely certain this AI-refactored policy matches the original behavior?”
“Can a bad actor manipulate this rule to force an evaluation error?”

Formal verification establishes mathematical certainty across the infinite spectrum of inputs. Proven policies protect your users and system while giving auditors clear proof of compliance.

To see these capabilities in action, watch our video demonstrating how the CEL Verifier REPL catches subtle logic flaws in seconds:

Proving rules from the ground up

Getting started with formal verification doesn’t require learning complex architectures right away. You can evaluate simple standalone CEL expressions to catch edge cases that tests easily miss.

(Note: The examples below use our interactive REPL syntax—check out the REPL documentation to follow along!)

1. Catching logic bugs in simple expressions (Equivalence)

How do you guarantee a refactored rule behaves identically to the original? Suppose we have a policy that allows ports 80 or 443 in production. An agent might factor the is_prod check like so:

equiv
  (is_prod && port == 80) || (is_prod && port == 443) 
  <=>
  is_prod && port == 80 || port == 443

Because logical AND has a higher operator precedence than OR, the verifier immediately flags Violated, and outputs the exact exploit: in a non-production environment (is_prod = false), the rule mistakenly allows port 443. Fixing the grouping parentheses returns Verified.

2. Enforcing exhaustive guardrails (Validity)

This capability scales directly to use cases like Kubernetes Validating Admission Policies. Suppose an engineer writes a guardrail expression that assumes every request will either be on a low port (under 80) or a high port (over 1024):

valid request.port > 1024 || request.port <= 80

When we check validity (whether an expression holds true for all inputs), the verifier exhaustively searches the entire integer space, flags Violated, and outputs the exact counterexample:

[VIOLATED] Condition is not always true. Counterexample input:
  request.port = 81

3. Guaranteeing security invariants with CEL Policy

While the verifier works perfectly with standalone CEL expressions, complex environments compose multiple rules and variables. Here, the CEL policy format shines. Using assume and assert blocks, the verifier proves a mathematical implication: if the assumptions hold, the assertions must also hold.

name: workload_admission
rule:
  variables:
    - is_admin: 'request.auth.claims.groups.exists(g, g == "admin")'
  match:
    # A subtle flaw introduced during authoring:
    - condition: 'request.is_privileged && request.is_prod'
      output: 'true'
    - condition: 'variables.is_admin || request.has_approval'
      output: 'true'
    - output: 'false'
verification:
  invariants:
    - id: universal_no_unapproved_privileged_prod
      assume:
        - 'request.has_approval == false'
        - 'variables.is_admin == false'
      assert:
        - 'rule.result == false'

The first condition admits privileged workloads into production without checking for approval or admin status. The verifier flags this and provides an example that exploits the issue:

Invariant 'universal_no_unapproved_privileged_prod' violation detected. Counterexample input:
  request.is_privileged = true
  request.is_prod = true
  request.has_approval = false
  request.auth.claims.groups = []

Assertions and assumptions define the boundaries of acceptable agent behavior, allowing developers to configure CI/CD pipelines to validate AI-generated changes simply and securely.

Under the hood: High-fidelity mathematical modeling

Translating a dynamic language into the Satisfiability Modulo Theories (SMT) domain requires immense engineering rigor to prevent the solver from hanging or hallucinating bugs. Our engine provides:

Zero false positives via three-pass taint tracking

Traditional verification tools are prone to “solver hallucinations”—reporting fake bugs when encountering custom domain-specific functions or external variables they don’t fully understand. To eliminate this noise, if a potential issue relies on an unmapped custom function, the verifier isolates and flags it as Inconclusive rather than breaking your CI pipeline with a false alarm. This guarantees every Violation report is a 100% real, reproducible bug.

Deep structural extensionality

The Formal Verification Framework offers configurable-depth bounded-model checking to prevent infinite loops within SMT quantifiers. These configurable limits allow you to control the cost of verification when analyzing deep structure equivalence in expressions like [[1], [2]] == [[1], [2]].

The mandatory bridge of trust

In the agentic era, code writes code. Mathematical proof isn’t just a nice-to-have; it is the fundamental bridge of trust developers require to let AI operate autonomously in their most sensitive systems. Get started with the CEL Formal Verification Framework, to take the next step toward a more secure agentic future today!

Let us know what you think—issues, pull requests, and feedback are always welcome!

Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation

2026-08-11T11:30:00.000-07:00

by Ethan Mahintorabi & Aaron Cunningham, Hardware Toolchains Team

Google is committed to advancing open source silicon innovation. We are excited to share that we have formally joined the OpenROAD Initiative (ORI), Inc. as a principal member. ORI is a nonprofit public benefit corporation dedicated to the open source electronic design automation (EDA) ecosystem. As part of this commitment, Aaron Cunningham has been appointed to the ORI Governing Board to represent Google and help drive the foundation’s strategic direction, financial sustainability, and technical stewardship.

Driving long-term open source sustainability

The OpenROAD Initiative’s mission is to advance and sustain the open source EDA ecosystem by fostering collaborative innovation across research, education, and industry—transforming ideas into silicon. Google’s membership aligns directly with ORI’s multi-year sustainability goals, supported by the US National Science Foundation’s (NSF) Pathways to Enable Open-Source Ecosystems (POSE) program.

With Google’s participation and membership commitment, ORI will continue to strengthen, grow, and sustain its open source ecosystem through key vectors:

Neutral Stewardship: Fostering transparent governance where no single company has outsized control over the code, ensuring the project remains inspectable, accessible, and community-driven.
Ecosystem Growth: Supporting open and reproducible silicon research, developing robust design flows, and hosting global design contests.
Workforce Development: Supporting global silicon skilling initiatives by expanding open source chip design curricula and collaborating with academic institutions and industrial training networks.
Technical Strengthening: Enhancing continuous integration and deployment (CI/CD) pipelines, expanding PDK enablement, and improving user experience.

Leadership perspectives

“The OpenROAD Initiative is built on the vision of making chip design open and accessible to all—building a collaborative ecosystem driven by transparency and shared innovation,” said Andrew Kahng, board member of the OpenROAD Initiative. “Google’s deep commitment to open source software and hardware makes them an ideal partner. By joining at our highest membership tier, Google is helping to ensure that the open source EDA ecosystem has the stable, long-term governance and financial foundation required to grow.”

“Cutting-edge silicon research requires robust, inspectable, and reproducible toolchains,” said Drew Wingard, Director of Silicon Infrastructure, Tools and Methodology at Google. “OpenROAD has already made an incredible impact across academia and the broader industry, enabling many successful tapeouts. Google is proud to support the OpenROAD Initiative’s mission to scale this open infrastructure for the next generation of developers.”

About the OpenROAD Initiative and OpenROAD project

The OpenROAD Initiative, Inc. is a California-based 501(c)(3) nonprofit organization that provides governance, stewardship, and coordination for the OpenROAD ecosystem. The OpenROAD Project is an open source, autonomous digital chip design toolchain that democratizes semiconductor design, enabling a complete RTL-to-GDSII flow in less than 24 hours with no human in the loop. Grounded in academic research and referenced in over 500 peer-reviewed publications, OpenROAD has lowered the barriers to hardware innovation, enabling thousands of students, researchers, and startups worldwide to design and manufacture chips.

To learn more about the OpenROAD Project and install the toolchain, visit the new OpenROAD website.

For more information about membership tiers and the foundation’s governance, visit the OpenROAD Initiative website at www.openroadinitiative.org or contact membership@openroadinitiative.org.

Adapting open source practices to an AI-first world: A retrospective on 2025

2026-08-03T11:30:00.000-07:00

by Sophia Vargas, Google Open Source

Even as AI adoption accelerates and transforms the global technology landscape, open source remains foundational to how Alphabet builds, uses, and collaborates on products for billions of users. Our commitment to open source remains broad and consistent, including sharing our work year-over-year, and reflecting on what we've learned.

In 2025:

Roughly 10% of Alphabet's full-time workforce actively contributed to open source projects. This contribution ratio has remained steady over the past five years, scaling to match our growth.
These open source contributions are not just solely focused on Google. Our top projects by unique contributors at Alphabet include community-led projects such as LLVM, vLLM, Envoy, and Rust, as well as Google-initiated projects like Kubernetes, Apache Beam, and gRPC.
In addition, Alphabet projects received commits from more than 20,000 non-Alphabet affiliated user accounts.

Working together on emerging standards

Open source communities continue to provide vital collaborative spaces to define emerging standards, ensuring the interoperability and extensibility for the next generation of technologies. In 2025, we worked with more than 50 partners on the Agent2Agent (A2A) protocol to enable AI agents to communicate with each other, securely exchange information, and coordinate actions on top of various enterprise platforms and applications. Within weeks of our initial announcement, Google donated the A2A project to the Linux Foundation as part of our long-standing commitment to develop "open, collaborative ecosystem – offering greater autonomy and multiplying productivity."

Launching tools with transparency

Open source licenses provide a framework for anyone to explore, test, fork and expand on our technologies. Over the last 15 years, Google has created more than 15,000 public repositories on GitHub. Today, Google continues to maintain more than 5,000 public repositories on GitHub, and more than 1,500 public repositories on Git-on-Borg. A quick look back to some highlights from our 2025 launches includes:

Gemma 3 – a collection of lightweight open models built from the same research and technology that powers our Gemini 2.0 models. They are designed to run directly on devices — from phones and laptops to workstations — helping developers create AI applications, wherever people need them. Since Gemma’s release in 2024, the Gemmaverse community has created more than 60,000 Gemma variants. We’ve continued work on this collection and in 2026 we released Gemma 4 under an Apache 2.0 license.
Agent Development Kit – an open-source framework and SDK designed to help developers build, compose, and run both conversational and non-conversational AI agents.

Adjusting our collective security practices

As the threat landscape evolves and accelerates in the AI era, we are working on novel solutions to mitigate vulnerabilities at scale and remove some of the burden from overloaded maintainers. In 2025, we introduced several critical security initiatives to support upstream open source projects:

CodeMender: An agent designed to be both reactive, instantly patching new vulnerabilities, and proactive, rewriting and securing existing code and eliminating entire classes of vulnerabilities in the process. In its first six months, we were able to upstream 72 security fixes to open source projects, including some as large as 4.5 million lines of code.
OSS Rebuild: A security initiative to prevent software supply chain attacks by verifying build provenance. It automates package rebuilding and semantically compares results to upstream artifacts to detect tampered code on registries like PyPI, npm, and Crates.io.
OSV-Scalibr: (Software Composition Analysis Library) the core engine for vulnerability scanning used internally and in OSV-Scanner.
Credential Scanning on deps.dev: A service (using Veles) that actively scans open-source packages on deps.dev for leaked GCP credentials to prevent account compromise.

Working together to sustain the contributor community

Beyond security contributions, we remain committed to providing financial support directly to projects and maintainers. In 2025, the Open Source Programs Office (OSPO) directed $2M in sponsorships and investments to more than 40 open source projects.

Google Summer of Code celebrated its 21st year of enabling open source organizations to find, mentor, and onboard new contributors, directly supporting 1,280 individuals to contribute to 185 organizations. Over its lifetime, the global program has connected more than 23,000 participants from 125 countries with over 1,000 open source organizations globally. Moving forward, we recognize the need to evolve our program structures to ensure they continue to effectively support maintainers in the AI era.

Evolving the way we work in open spaces

Respecting community norms and practices is fundamental to establishing and maintaining trust in open source communities. To ensure we remain supportive members of your community, we encourage projects to document preferred practices and policies in the wake of new technologies. As AI changes the way we work, we are continually evaluating how best to evolve the way we engage in open spaces to preserve, prepare and bolster the communities we depend on.

We are deeply grateful for the many individuals and organizations that have worked with us to create global technologies from which everyone can benefit. You can continue to learn more about our open source initiatives, ongoing programs, and new projects at opensource.google.

Appendix: About this data

This report features metrics provided by many teams and programs across Alphabet. In regards to the code and code-adjacent activities data, we wanted to share more details about the derivation of those metrics.

Data sources: These data represent the activities of Alphabet employees on public repositories hosted on GitHub and our internal production Git service Git-on-Borg. These sources represent a subset of open source activity currently tracked by Google OSPO.
Business and personal: Activity on GitHub reflects a mixture of Alphabet projects, third-party projects, experimental efforts, and personal projects. Our metrics report on all of the above unless otherwise specified.
Alphabet contributors: Please note that unless additional detail is specified, activity counts attributed to Alphabet open source contributors will include our full-time employees as well as our extended Alphabet community (temps, vendors, contractors, and interns). In 2025, full time employees at Alphabet represented more than 95% of our open source contributors.
GitHub Accounts: For counts of GitHub accounts not affiliated with Alphabet, we cannot assume that one account is equivalent to one person, as multiple accounts could be tied to one individual or bot account.
Active counts: Where possible, we will show ‘active users’ defined by logged activity (excluding ‘WatchEvent’) within a specified timeframe (a month, year, etc.) and ‘active repositories’ and ‘active projects’ as those that have enough activity to meet our internal active-project criteria and have not been archived.

This Week in Open Source for July 16, 2026

2026-07-16T11:30:00.000-07:00

by Daryl Ducharme, Open Source Programs Office

This Week in Open Source for July 16, 2026

A look around the world of open source

We’re diving into another week of open source news and discussions. As the ecosystem continues to evolve, we're seeing more conversations around the intersection of AI workflows, security at scale, and the infrastructure that supports the open web.

This week, we’re highlighting a few "Open Source Reads" that tackle some of the biggest questions facing our ecosystem today—from the complex ethics of AI-generated workflows to the future of federated social networks. We hope these links provide valuable context as we work together to sustain the critical infrastructure we all rely on.

Upcoming Events

ASWF Open Source Days (July 19–20) — Los Angeles, CA. Hosted by the Academy Software Foundation, focusing on open source software in visual effects (VFX) and animation.
KubeCon + CloudNativeCon Japan 2026 (July 28–30) — Yokohama, Japan. The Cloud Native Computing Foundation's flagship conference in Japan.
Black Hat & DEF CON 2026 (August 1–9) — Las Vegas, NV. While primarily cybersecurity, both heavily feature open source hacking tools. The Open Source Security Foundation (OpenSSF) also has a major presence here.
FOSSY (August 6–9) — Vancouver, Canada. A highly community-focused open source conference emphasizing grassroots participation and collaboration.
Community over Code Asia (August 7–9) — Beijing, China. The Asian edition of the Apache Software Foundation's (ASF) community-first conference.
Open Source Summit Korea (August 11–12) — Seoul, South Korea. Hosted by the Linux Foundation, bringing together open source maintainers and enterprises.
KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China (September 7–9) — Shanghai, China. A massive collaborative mega-event uniting open infrastructure, cloud, and AI communities.
OSPOlogy + OSPO Summit (September 7) — Shanghai, China. Focused on Open Source Program Offices (OSPOs), governance, and corporate open source sustainability.

Open Source Reads and Links

[Blog] Elephants, Goldfish and the New Golden Age of Software Engineering - This isn't directly open source, but with the open source ecosystem trying to find good AI workflows I thought the Elephant-Goldfish model was an interesting take. It makes the distinction between using AI as a toy and using it as a tool.
[Article] Open-source AI and the Choice Before Us - The communities with minimal influence on AI development will likely be the most affected by it. This article looks at how strong rules and institutions are needed to guide AI's safe and fair use. The future of AI depends on whether we build systems that include everyone or just deepen existing divides.
[Article] Open source carries the world. Patching it at Mythos-scale can't fall to maintainers alone. - The past year has shown that AI is speeding up the discovery of vulnerabilities in open source software. Endor Labs is offering a solution to utilize AI to create patching stop gaps for users of the libraries so that maintainers and contributors have the time to create good quality fixes to these vulnerabilities.
[Blog] The AT-URI Syntax Mess - I am very excited about the open social web, especially things happening around the AT protocol. Early misunderstanding led to the current AT URI syntax being invalid. This article looks at the possible ways forward.
[Article] The Open Social Web Needs Section 230 to Survive - The open web has always been a promise of free speech. When walled garden social media got involved it created some questions around whether free speech applies to the content served by the corporations running those networks. However, the open social web is not run by corporations. It can be, and it can also be run by individuals federating instances or running their own PDS. So, how do we maintain the free speech promise of the internet with this in mind?

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.

Google Open Source Blog

Kubernetes Python client gets a modern overhaul for the AI/ML era

The historical problem: Legacy machinery meets hyperscale AI

A principled approach: Built for AI/ML, not 1:1 parity

How we're modernizing the Kubernetes Python client

1. Machinery: Upgrading to OpenAPI Generator v7.20+

2. Features: Native asyncio, Shared Informers, and WebSocket v5

3. Performance: Slashing deserialization overhead

What's next and how to get involved

Scaling AI agents with open standards: Kurtis Van Gent on MCP and Agent Skills joining the AAIF

From the N-by-M database problem to open source collaboration

Leading the transition to a stateless MCP specification

Why vendor-neutral governance in the AAIF matters for developers

Solving tool bloat with progressive disclosure: how MCP and Agent Skills fit together

Putting MCP and Agent Skills to work in database and developer workflows

What comes next for the Agent Skills specification

How to get involved

GSoC 2026 Mentor Summit: Resilient OSS Communities

Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF

Challenges of running AI agents at scale

1. The idle resource problem

2. Control plane overload

How Agent Substrate solves the problem

The lifecycle of an agent turn

Safe execution with gVisor and microVMs

Why Google donated Agent Substrate to the CNCF

Where to find us at KubeCon NA 2026

Get started

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

Core production-ready features

Customer testimonials and partner use cases

Arm: Performance Parity on Arm Neoverse platforms

Intel: Native JAX on Xeon server CPUs

Moloco: Scaling advertising and recommenders

What’s next

Limitations

Get started today

Acknowledgements

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

Why Kubeflow Workspaces

What's unique about GKE Workspaces

1. Pause and resume—without losing your state

2. An easy on-ramp to Cloud TPUs

3. Use your local coding agents with cloud accelerators

4. A launchpad for distributed work

5. A portal to safe elastic sandboxes for coding subagents

6. Lightweight and secure by default

Get started

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

How Three-Live works

Declarative 3D and spatial WebXR in HTML

Try it today

This Week in Open Source for October 30, 2026

A look around the world of open source

Upcoming events

🗓️ November 2026

🗓️ December 2026

🗓️ January 2027

Open calls for proposals (CFPs)

Open source reads and links

This Week in Open Source for October 23, 2026

A look around the world of open source

Upcoming Events

🗓️ October 2026

🗓️ November 2026

🗓️ December 2026

Open Source Reads and Links

Introducing the Elephant-Goldfish Model plugin: scaling design-driven AI software development

Shifting left in the AI coding era

Understanding the Elephant-Goldfish Model (EGM)

Announcing the open source Elephant-Goldfish Model plugin

The EGM plugin in a nutshell

Phase 1: Growing the Elephant (egm-brainstorm)

Phase 2: Drafting with the Elephant (egm-draft)

Phase 3: The Goldfish Protocol (egm-review)

Human judgment is the artifact

Announcing the verifiable quantum circuit compilation competition on Kaggle

Turning compilation into an AI agent loop

How the competition works

Get involved

2. Features: Native `asyncio`, Shared Informers, and WebSocket v5

Phase 1: Growing the Elephant (`egm-brainstorm`)

Phase 2: Drafting with the Elephant (`egm-draft`)

Phase 3: The Goldfish Protocol (`egm-review`)