# Google Open Source Blog News about Google's Open Source projects and programs. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## GHarchive data has become unreliable for measuring GitHub activity DevFeed: [GHarchive data has become unreliable for measuring GitHub activity]() Original publisher: [Read original article]() Author: KD (noreply@blogger.com) Published: 2026-09-03T16:00:00Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [data](), [datasets](), [GitHub](), [Crawler](), [GitHub API](), [Open Source](), [GraphQL]() Tags: [collect](), [data](), [dataset](), [datasets](), [github](), [google](), [google-open-source](), [graphql](), [open-data-sets](), [open-source](), [oss](), [pipeline](), [pull-requests](), [retention](), [stream](), [volume]() ### AI overview This article examines the reliability of open source data, focusing on GHarchive's coverage of GitHub events. It argues that GHarchive should not be used for real-time or volume-based metrics because event retention has declined and some activity is omitted by the GitHub Event stream and API limitations. ### Source excerpt 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 Ev ## Securing the agentic era: Introducing formal verification for CEL DevFeed: [Securing the agentic era: Introducing formal verification for CEL]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-08-18T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Formal verification](), [Automated reasoning](), [Testing](), [Artificial Intelligence]() Tags: [agent](), [ai](), [ai-agent](), [automated-reasoning](), [cel](), [common-expression-language](), [formal-verification](), [open-source](), [security](), [testing](), [verification](), [z3]() ### AI overview Google's Common Expression Language (CEL) Formal Verification Framework is available for proving the correctness of CEL expressions and policies. Powered by the Z3 theorem prover, it complements heuristic testing by using mathematical proofs to identify logic flaws, equivalence issues, and potentially unsafe policy behavior. ### Source excerpt 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 ## Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation DevFeed: [Google joins the OpenROAD Initiative as principal member to accelerate open source silicon innovation]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-08-11T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Google](), [Chip design](), [Open Source](), [toolchains](), [Continuous integration]() Tags: [chip-design](), [ci-cd](), [eda](), [google](), [open-source](), [openroad](), [semiconductors](), [toolchains](), [user-experience]() ### AI overview Google has joined the OpenROAD Initiative as a principal member and appointed Aaron Cunningham to its Governing Board. The partnership supports OpenROAD's open-source electronic design automation ecosystem through governance, ecosystem growth, workforce development, and technical improvements. ### Source excerpt 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 ecosyst ## Adapting open source practices to an AI-first world: A retrospective on 2025 DevFeed: [Adapting open source practices to an AI-first world: A retrospective on 2025]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-08-03T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [Open Source](), [Google](), [A2A protocol](), [interoperability](), [GitHub](), [linux foundation](), [Protocol (disambiguation)](), [LLVM](), [Rust](), [vllm](), [gRPC](), [Kubernetes]() Tags: [2025](), [a2a](), [a2a-protocol](), [agents](), [ai](), [ai-agents](), [github](), [google-open-source](), [interoperability](), [kubernetes](), [linux](), [linux-foundation](), [open-source](), [report-card](), [retrospective](), [rust](), [security](), [vllm]() ### AI overview Google reviews Alphabet's 2025 open source activity, including employee and external contributions, collaboration on the Agent2Agent protocol, and the maintenance and launch of public repositories and tools. ### Source excerpt 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 publi ## This Week in Open Source for July 16, 2026 DevFeed: [This Week in Open Source for July 16, 2026]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-07-16T18:30:00Z Content type: news Language: en Sources: [Google Open Source Blog]() Topics: [Open Source](), [Artificial Intelligence](), [Cybersecurity](), [Cloud]() Tags: [ai](), [cloud-native](), [conference](), [cybersecurity](), [events](), [news](), [open-source](), [twios]() ### AI overview A roundup of open source news, discussions, recommended reading, and upcoming community events, with attention to AI workflows, security, open web infrastructure, and related conferences. ### Source excerpt 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), gove ## Google Cloud: PostgreSQL community contribution updates DevFeed: [Google Cloud: PostgreSQL community contribution updates]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-07-10T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [PostgreSQL](), [Google Cloud Platform (GCP)](), [Google](), [Open Source](), [Replication]() Tags: [architecture](), [collaboration](), [community-contribution](), [conference](), [consensus](), [contribution](), [google](), [google-cloud](), [open-source](), [postgresql](), [replication](), [technical](), [updates]() ### AI overview Google Cloud recaps its participation in 2026 PostgreSQL community events, including discussions of logical replication, global index architecture, DDL replication, and AI-assisted development workflows. ### Source excerpt by Dilip Kumar, Cloud SQL for PostgreSQL & Matt Cornillon, Sales EMEA Google Cloud is deeply committed to the long-term success of the PostgreSQL ecosystem. Our involvement goes beyond providing PostgreSQL managed services; it's also about active participation in the open source communities through technical contributions, leadership in conference committees, and sharing architectural insights that benefit all users. Following is a recap of recent events Google Cloud participated in. PGConf.dev 2026 Serving as a vital developer-centric hub, PGConf.dev provides a unique opportunity for collaboration with the full assembly of senior PostgreSQL committers. This gathering is essential for aligning technical efforts and shaping the future project roadmap. Key Highlights Participation focused on strategic coordination with PostgreSQL committers regarding logical replication development, and a consultation on global index architecture. High community interest confirms the Global Index feature solves a vital architectural requirement for enterprises. Established community consensus to pursue a deparsing-based architectural approach for DDL replication. Google Cloud Sessions Dilip Kumar, a PostgreSQL contributor from Google Cloud, presenting "Experimenting with a Global Index in PostgreSQL" at pgconf.dev 2026 in Vancouver. He is speaking at a podium next to a presentation slide detailing the Global Index storage architecture and PartitionIdentifier management. Session Title Session Type Speakers/Led by Experimenting with a Global Index in PostgreSQL: Design, Implementation, and Challenges Technical Talk Dilip Kumar Unconference: Global Indexes Unconference Session Dilip Kumar Unconference: Logical Replication: Warts and Missing Pieces Unconference Session Hannu Krosing PGConf India 2026 Key Highlights The three-day conference was divided into a training day followed by two days of sessions. More than 580 participants attended the conference over three days. The conference se ## Community feedback: How can corporations improve support for open source maintainers? DevFeed: [Community feedback: How can corporations improve support for open source maintainers?]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-30T18:30:00Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [Maintainers](), [Open Source](), [Google](), [Pull Request]() Tags: [community](), [conference](), [funding](), [maintainers](), [open-source](), [open-source-communities](), [procurement](), [sponsorship](), [sustainability](), [transparency]() ### AI overview Google Open Source reports community feedback on how corporations can better support open source maintainers. Suggestions include predictable financial support, contribution-based payments, procurement and support services, conference travel sponsorships, respect for community norms, and consistency between documentation and practice. ### Source excerpt by Sophia Vargas, Google Open Source We know that AI is actively transforming the sustainability and socio-technical dynamics of OSS communities. Google Open Source is committed to partnering with open source communities and ecosystems to learn together how we should update our own models for engagement and support. During an open meetup for GitHub Maintainer Month, I led a session to gather community feedback on how corporations can more effectively support open source maintainers. Paying maintainers takes creativity Many maintainers would appreciate consistent financial support. However, facilitating payments to individuals without established contractual relationships remains a complex challenge, particularly across diverse international jurisdictions. Fiscal hosts and programs such as Open Collective, GitHub Sponsors, and the LFX Mentorship Program can simplify components of this process, but they do not resolve the underlying issues of funding sustainability and predictability. While initiatives like the Open Source Endowment are working toward long-term funding sustainability, individual maintainers also had a few ideas: Pay per meaningful contribution vs gameable metrics: Avoid payment models based on easily manipulated units like pull request counts or review volume. A proposed alternative is 'pay per report,' encouraging maintainers to document their achievements and upcoming roadmaps. Commitment-based purchasing: Corporate policies might make procurement simpler (or more complex) than sponsorships, so maintainers could benefit from offering structured support services alongside traditional sponsorship opportunities. Fund conference attendance: In-person networking can be a boon for solo maintainers but it's often cost-prohibitive. For some corporations, travel sponsorship may be a simpler alternative to direct payments. Challenge for Corporations and Fiscal Hosts: How can we assist maintainers in understanding any and all prerequisites and documentation ne ## Documenting the manual: how curiosity and robotic arms led to a career in open source DevFeed: [Documenting the manual: how curiosity and robotic arms led to a career in open source]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-22T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [Documentation](), [Open Source](), [Linux Kernel](), [Linux](), [C](), [Undocumented feature](), [Network](), [Scripting]() Tags: [c](), [communities](), [documentation](), [linux](), [linux-kernel](), [linux-man-pages](), [network](), [open-source](), [scripting](), [sponsorship](), [undocumented-feature](), [work]() ### AI overview This article profiles Alejandro "Alex" Colomar's path from working with robotic arms to maintaining Linux Kernel documentation. It explains how documenting the previously undocumented SO_TIMESTAMPNS feature led to his first man-pages patch and eventually to a career focused on clarity in open source communities. Google sponsors his work on the Linux Kernel man-pages project. ### Source excerpt by Daryl Ducharme, Google Open Source When you think of "innovation" in open source, your mind probably jumps to the latest AI model or a revolutionary new framework. You might not immediately think of manual pages. Even Alejandro "Alex" Colomar, who spends his days maintaining Linux Kernel documentation, jokingly admits that some might find the work "boring" because it focuses on fixing existing issues and documenting new features rather than flashy inventions. But as any developer knows, the most powerful code is only as good as the documentation behind it. At Google, we believe that investing in the success of projects we don't own is a core part of being a good open source citizen. That is why we are proud to sponsor Alejandro's work on the Linux Kernel man-pages project--supporting the critical infrastructure that many of our own systems rely on every day. Documentation is the gift you give to your future self and your whole community. The precision of a robot Alejandro's journey into the world of essential documentation started at university. He was working with robotic arms that used a proprietary scripting language. Wanting more control, he decided to write a C library to communicate with the robots over the network by sniffing packets with Wireshark. It worked, but it was slow--he had to wait seconds between commands to ensure the robot had finished moving. To make the movements smooth, he needed to understand the messages the robot was sending back in real-time. This required high-precision timing. He found SO_TIMESTAMP, which provided microsecond precision, but he noticed a macro called SO_TIMESTAMPNS in the header files that promised nanosecond resolution. The problem? It wasn't documented in the manual page. The first patch After figuring out how to use the undocumented feature by looking at the kernel source code, Alejandro decided to ensure the next person wouldn't have to struggle. He cloned the man-pages repository, wrote a new paragraph based on exis ## In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35 DevFeed: [In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-18T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [Kubernetes](), [reliability](), [Resilience](), [Containers](), [distributed-systems](), [etcd](), [benchmarking]() Tags: [ai](), [containers](), [control-plane](), [efficiency](), [etcd](), [google](), [kubernetes](), [ml](), [reliability](), [resilience]() ### AI overview This article explains how Kubernetes v1.35 introduces the RestartAllContainers action for in-place Pod restarts. It describes how restarting containers while preserving the Pod's runtime identity can reduce resource waste, control-plane churn, scheduling races, and recovery delays for complex, batch, and AI/ML workloads. ### Source excerpt by Duncan Campbell & Giuseppe Tinti Tomio, Kubernetes Operational efficiency and system resilience are critical when running scaled platforms. Yet, in Kubernetes, recovering from software crashes remains a headache because you couldn't trigger a clean restart of a Pod's containers without recreating the entire Pod object, leading to some amount of resource waste. To address this, Restart All Containers on Container Exits graduated to beta and is enabled by default in Kubernetes v1.36. Developed in close collaboration with the CNCF community, this capability represents Google's commitment to investing in the success of foundation-led open source projects. By sharing best practices from running large distributed systems internally, we are helping build a more resilient and efficient ecosystem. Letting containers restart while keeping the Pod's runtime identity provides a built-in way to perform in-place Pod recovery, boosting application reliability and saving resource costs. The Problem: The High Cost of Pod Re-creation Historically, Kubernetes managed failures using pod level restart policies. While sufficient for simple services, modern multi-container Pods often have complex dependencies. When a failure requires a full environment reset, your only option was deleting and recreating the entire Pod. This introduces massive control plane churn, causing latency and pressure on the etcd backend during large failures: Initialization Dependencies: If a main container corrupts a local environment, for example, single-use secrets that must be re-requested, restarting just that container is insufficient; the setup must run again. Watcher Interoperability: If a watcher sidecar detects a fatal error, it must trigger a full recreate of the entire pod and its infrastructure, including the sandbox. Stale States: If a database sidecar proxy restarts, the main application can get stuck attempting to use stale, broken connections. Resource Race Conditions: When a large job finds a ## Open rails for agentic commerce at Open Source Summit North America 2026 DevFeed: [Open rails for agentic commerce at Open Source Summit North America 2026]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-16T23:16:03Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [Artificial Intelligence](), [Open Source](), [systems](), [Protocol (disambiguation)]() Tags: [2026](), [agentic](), [agentic-commerce](), [ai](), [ai-agents](), [business](), [capabilities](), [checkout](), [consumer](), [e-commerce](), [features](), [fragmentation](), [integration](), [interoperability](), [open-source](), [open-standards](), [payment](), [platforms](), [shopping](), [standard](), [ucp](), [universal-commerce-protocol](), [workflows]() ### AI overview An article from Open Source Summit North America 2026 explains why agentic commerce may require shared, open rules and integrations. It presents Universal Commerce Protocol (UCP) as an open standard intended to let agents, businesses, consumer surfaces, and payment providers work together across shopping, checkout, fulfillment, and post-purchase flows. ### Source excerpt by Anurag Sinha, Universal Commerce Protocol (UCP) At Open Source Summit North America 2026, I shared why agentic commerce needs open rails. As AI agents become more capable, the shopping journey is shifting from "show me" to "help me." Instead of browsing, comparing, clicking, and checking out step by step, people can increasingly ask an agent to help them decide what to buy and, in some cases, complete the purchase. Industry forecasts suggest agentic shopping could account for roughly 10% to 25% of U.S. e-commerce by 2030 (Bain), which points to a meaningful shift in how digital commerce will work. Watch the full keynote here. Why shared rules matter That shift also exposes a challenge. Commerce is still highly fragmented. Different businesses, payment providers, and platforms operate with their own rules, workflows, and business logic. Every new surface adds more integration work. Every bespoke connection creates more complexity. And that fragmentation makes it harder for AI systems to understand and perform commerce actions consistently across businesses. A shared language lowers that barrier for everyone. A common language for agentic commerce That is the problem Universal Commerce Protocol (UCP) is designed to solve. We launched the Universal Commerce Protocol, or UCP, with industry leaders to establish an open standard for agentic commerce, built to work across the shopping journey. UCP creates a common language for agents and systems to operate together across consumer surfaces, businesses, and payment providers, so the ecosystem does not need a different bespoke integration for every new agent or platform. Just as importantly, UCP is designed for the real world. Every business has its own way of selling. Checkout, fulfillment, loyalty, policy logic, shipping, and post-purchase flows can vary widely between a local shop, a marketplace, and a large retailer. UCP is built to support that reality. A layered architecture for a shared commerce language UCP uses a ## CEL repositories move to the dedicated cel-expr GitHub organization DevFeed: [CEL repositories move to the dedicated cel-expr GitHub organization]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-16T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [GitHub](), [Git]() Tags: [announce](), [brand-identity](), [c-plus-plus](), [cel](), [common-expression-language](), [consistency](), [dependencies](), [dependency-management](), [development](), [discoverability](), [github](), [go](), [java](), [pull-requests](), [python]() ### AI overview The official Common Expression Language (CEL) repositories have moved from the Google organization to the dedicated cel-expr GitHub organization. The move centralizes the language specification and implementations, while redirects preserve existing links and repository history. ### Source excerpt by Olena Huang, CEL (Common Expression Language) team We're excited to announce that the official Common Expression Language (CEL) repositories have moved to a dedicated GitHub organization. Visit the new cel-expr repository now! Why the move? This move is a key step in strengthening the CEL ecosystem. By centralizing our projects, including the language specification, Go, C++, C, Java, and Python implementations, under the cel-expr organization, we aim to: Enhance Branding: Create a clear and unified brand identity for CEL. Improve Discoverability: Make it easier for users and contributors to find all official CEL resources in one place. Ensure Consistency: Foster consistency across all CEL projects. Streamline Development: Simplify our development and release processes. What's Changing? The following repositories now reside in the cel-expr organization: google/cel-spec is now cel-expr/cel-spec google/cel-cpp is now cel-expr/cel-cpp google/cel-go is now cel-expr/cel-go google/cel-java is now cel-expr/cel-java cel-expr/cel-python and cel-expr/cel-c have already been in the cel-expr namespace All future development, issues, and pull requests for these projects will take place in their new homes within the cel-expr organization. This is a non-breaking change, due to automatic redirects, but you should update your URLs where possible. What Stays the Same? We've worked to make this transition as seamless as possible: Automatic Redirects: GitHub will automatically redirect all web traffic and git operations from the old google/cel-* URLs to the new cel-expr/cel-* locations. Your existing links and git remote configurations pointing to the old URLs should continue to work for cloning and fetching. Preserved History: The full commit history, issues, and pull requests for each repository have been migrated and are available in the new locations. Action Required: Update Your Dependencies While existing links and git remote configurations pointing to the old URLs should conti ## A new pkg.go.dev API for Go DevFeed: [A new pkg.go.dev API for Go]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-12T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [API](), [Go Language](), [JSON](), [OpenAPI Specification](), [Command-line interface](), [AI-assisted coding]() Tags: [agents](), [ai-assisted-coding](), [api](), [developer-tools](), [go](), [json](), [open-source](), [openapi](), [pkg-go-dev]() ### AI overview The Go Team introduces a structured API for pkg.go.dev, providing programmatic access to Go package metadata. The stateless, GET-only API returns JSON metadata, is currently available under a v1beta path, and is intended to evolve toward a formal v1 release after community feedback and stability validation. ### Source excerpt by Ethan Lee, Jonathan Amsterdam & Hana Kim, Go Team Access to Go metadata has been an everpresent need for the Go community. Since its launch, pkg.go.dev has served as a central hub for Go package documentation and discovery. While we initially prioritized providing this comprehensive access via a web interface, the need for streamlined programmatic access has become increasingly clear. Structured API access has been one of the most highly requested features for pkg.go.dev for a while now. Developers building tools, IDE integrations, automated workflows, and other systems have had to rely on inconsistent and fragile scraping methods. By providing a formal API, we can provide fast and efficient access to required data. This foundation also sets Go up for the future of AI-assisted coding. Large language models and agents can access the context necessary to reason about the Go ecosystem with greater precision and accuracy. Empowering Tool Builders Our goal with this API is to reduce the technical churn for builders and innovators. By offering structured JSON metadata, we address the following use cases: Search and Discovery: The API enables fast and efficient search across the entire Go module ecosystem. Driving AI Innovation: As AI-assisted coding evolves, LLMs and agents need precise context. This API provides the data required for agents and models to reason deterministically about Go packages. The Service Interface Built for stability and efficient caching, the API uses a stateless, GET-only architecture. Primary endpoints are currently hosted under the v1beta path. Following a period of feedback from the Go community and confirmed stability, we intend to transition toward a formal v1 release. For a complete interactive reference of all endpoints, query parameters, and response shapes, see pkg.go.dev/api. The machine-readable API contract is also published directly at pkg.go.dev/v1beta/openapi.yaml. Endpoint Description /v1beta/imported-by/{path} Paths of packages ## Introducing OpenRL: A self-hosted post-training API for fine-tuning LLMs DevFeed: [Introducing OpenRL: A self-hosted post-training API for fine-tuning LLMs]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-11T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [API](), [Fine-tuning](), [Large Language Model](), [Self-hosted](), [post-training](), [Kubernetes](), [Orchestration](), [reliability]() Tags: [api](), [fine-tuning](), [gke](), [kubernetes](), [llms](), [open-source](), [orchestration](), [post-training](), [reinforcement-learning](), [reliability](), [rl](), [self-hosted](), [sft]() ### AI overview This article announces OpenRL, an open-source research preview from GKE Labs. OpenRL is a self-hosted training API for fine-tuning LLMs on a Kubernetes cluster, designed to separate post-training infrastructure from AI research workflows. The article describes potential benefits including concurrent reinforcement-learning jobs, improved GPU utilization, and simpler researcher workflows. ### Source excerpt by Sunil Arora, Shuby Mishra & Chuang Wang, GKE We are pleased to share a research preview of OpenRL, a new open-source project coming out of GKE Labs. OpenRL is a self-hosted training API for fine-tuning LLMs on your own Kubernetes cluster. Why we built it If you look at agentic RL on LLMs, it is incredibly easy to get bogged down in system complexity. To run a single RL loop, you have to coordinate a dozen different things: selecting and cleaning datasets, choosing RL environments, debugging training loops, managing reward signals, handling inference mismatches, allocating hardware, and managing infrastructure. Picture looks something like this: Figure shows an AI researcher and an infrastructure engineer staring at the hurdles in post training along the way to the summit. Each of these is a hard problem. But what makes it more complex is how tightly AI research and infrastructure concerns are mixed together in today's tooling and frameworks. We believe decoupling the infrastructure from AI research can make these problems more tractable so that infrastructure engineers and AI researchers can independently tackle them. We have seen this pattern with Kubernetes where Kubernetes abstracted out the infrastructure and made application developers and SREs life easier. So, can you abstract out post training infrastructure? We believe so and drew huge inspiration/validation from Tinker (from Thinking Machines). The Tinker APIs for post training hit that Goldilocks zone where it hides all the post training infrastructure behind four key APIs: Figure shows high level components and their interaction in a OpenRL based RL workflow So the end result of this abstraction is that AI Researchers get full flexibility on their RL loop and infrastructure engineers can focus on scaling, orchestration, and reliability. OpenRL allows you to run the same training APIs but on your own infrastructure. And this decoupling has other interesting benefits. Sharing GPUs Traditional RL loops ar ## Google joins the Eclipse Foundation as a strategic member to accelerate AI-integrated developer tools DevFeed: [Google joins the Eclipse Foundation as a strategic member to accelerate AI-integrated developer tools]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-10T18:30:00Z Content type: news Language: en Sources: [Google Open Source Blog]() Topics: [Google](), [Open Source](), [Artificial Intelligence](), [dev-tools](), [google-antigravity](), [Extension](), [Critical Infrastructure]() Tags: [ai](), [ai-integrated](), [antigravity](), [critical-infrastructure](), [developer-tools](), [eclipse-foundation](), [google](), [google-ospo](), [open-source](), [open-source-security]() ### AI overview Google joined the Eclipse Foundation as a Strategic Member in April 2026. It will sponsor Open VSX, participate in the foundation's governance, and support open infrastructure for AI-integrated developer platforms, along with open source security and regulatory compliance initiatives. ### Source excerpt by amanda casari & Mike Bufano, Google Open Source Collaboration with the Eclipse Foundation will support open infrastructure for AI-integrated developer platforms like Google Antigravity, while advancing broader open source security and regulatory compliance initiatives As of April 2026, Google has joined the Eclipse Foundation as a Strategic Member, reflecting the company's continued investment in open source technologies and modern developer infrastructure. As part of this collaboration, Google will additionally sponsor Open VSX and is among the first adopters of the recently announced Open VSX Managed Registry service. Open VSX is the open source, vendor-neutral extension registry for tools built on the VS Code™ extension API. It powers a rapidly growing ecosystem of AI-integrated IDEs, cloud development environments, and developer platforms, including Google Antigravity, AWS's Kiro, Cursor, and, Windsurf among many others. As a Strategic Member, Google will participate in the Eclipse Foundation's Board of Directors and Technical Advisory Council, helping guide the technical and strategic direction of one of the world's leading open source software foundations. "The industry is feeling the massive turning point as AI continues to change how developers write, deploy, and maintain software," said amanda casari of Google's Open Source Programs Office and new Eclipse Board member. "Joining The Eclipse Foundation as a Strategic Member ensures that the next generation of AI-integrated developer experiences--including platforms like Google Antigravity--are built in partnership with transparent, vendor-neutral foundations. Open registries, like Open VSX, are critical infrastructure which keep the global developer ecosystem open to everyone." Google and the Eclipse Foundation share a deep history, having collaborated across numerous initiatives since 2006. This Strategic Membership elevates the relationship and support critical to modern initiatives like Open VSX, Open Reg ## Unlocking TPU performance: Deep kernel profiling with XProf DevFeed: [Unlocking TPU performance: Deep kernel profiling with XProf]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-08T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [AI Development](), [telemetry](), [debugging](), [Compiler](), [Google]() Tags: [compiler](), [debugging](), [google](), [ml-dev-tools](), [performance](), [profiling](), [telemetry](), [tpu](), [tpu-optimization](), [tpu-performance]() ### AI overview Google introduces the Kernel Profiling suite in XProf for debugging and optimizing custom Pallas kernels on Google TPUs. It combines static compilation tracking with dynamic, sub-microsecond hardware telemetry and exposes compilation details through HLO graphs and lowered MLIR text. ### Source excerpt by Yogesh SY, AI Infra Google Unlocking TPU performance: Deep kernel profiling with XProf As machine learning workloads scale to unprecedented heights, developers are increasingly writing highly specialized Tensor Processing Unit (TPU) kernels using frameworks like Pallas, Mosaic, and Triton to maximize hardware performance. However, customizing high-performance kernels has historically introduced a major engineering challenge: optimization blind spots. To legacy performance profilers, custom compilation paths appear as opaque execution paths. Developers are left with single, massive execution blocks in their trace captures, lacking granular visibility into what is actually occurring inside the chip's internal components. Did a vector processing instruction stall? Was matrix math idle due to data loading bottlenecks? Traditional profiling relies heavily on compile-time static cost models to estimate kernel efficiency. While helpful for standard operations, these models cannot capture dynamic runtime realities like instruction execution stalls, memory subsystem congestion, or hardware scheduling conflicts. To open this opaque execution path, we are excited to introduce the Kernel Profiling suite in XProf--a low-level hardware debugging suite engineered specifically for Pallas kernel authoring and optimization on Google TPUs. By combining static compilation tracking with dynamic, sub-microsecond hardware telemetry, XProf Kernel provides the deep transparency required to optimize high-scale ML workloads. Deep visibility: HLO Graphs & MLIR Inspection The first step in debugging any custom kernel is understanding how your high-level code is translated by the compiler. When compiling a JAX or PyTorch model, the compiler generates a High-Level Optimizer (HLO) graph. Previously, custom calls inside these graphs remained completely obscured. XProf's updated Graph Viewer resolves this by exposing the internal compilation logic of these custom regions directly. To unlock this d ## Journey to JPEG XL: How open source experiments shaped the future of image coding DevFeed: [Journey to JPEG XL: How open source experiments shaped the future of image coding]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-03T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [coding](), [Compression](), [Open Source](), [Optimization](), [color](), [Internet]() Tags: [coding](), [color](), [compression](), [image](), [image-compression](), [internet](), [jpeg](), [jpeg-xl](), [open-source](), [optimization](), [web]() ### AI overview The article traces the development of JPEG XL through earlier open-source experiments, including WebP Lossless, Brotli, Butteraugli, Guetzli, and Brunsli. It explains how work on entropy coding, context modeling, psychovisual metrics, color representation, and JPEG compression informed the newer image format. ### Source excerpt by Jyrki Alakuijala, Zoltán Szabadka & Luca Versari, Paradigms of Intelligence, Google Technology & Society Building the Next Generation Image Standard The internet runs on images. Since the early days of the web, there has been a relentless tension between visual fidelity and bandwidth. For decades, the industry relied on the venerable JPEG standard for images loading fast. It served us remarkably well, but as displays moved to High Dynamic Range (HDR) and Wide Color Gamut (WCG), the format began to show its limits. The road to JPEG XL (JXL) wasn't a straight line. It was a decade-long exploration, creating a series of milestone projects testing radical ideas in psychovisual modeling, entropy coding, and optimization. Today, as JPEG XL sees rapid adoption across operating systems and professional standards, we're looking back at the experiments that made it possible. The Early Foundation: 2011-2017 Our study began with a focus on understanding the limits of existing technology. We didn't start by trying to write a new standard; we started by trying to make the current ones better, and learning their limitations. This allowed us to make the new formalism more flexible and efficient in the right places. WebP Lossless and Brotli: Lossy WebP drew its lineage from video technology, the WebP Lossless (2011) represented an architectural and scoping departure. We debuted the entropy image concept, an innovative method utilizing a secondary image to orchestrate the selection of static entropy codes for the primary visual data. We reapplied this approach later with data-driven context modeling in the Brotli compression format, enabling rich context modeling without slowing decoding. Butteraugli: Around 2014, we realized that raw mathematical compression (PSNR) wasn't enough, and simple psychovisual approximations (SSIM and similar) failed in color-rich environments. We built Butteraugli and the XYB color space to mimic the human visual system's edge detection and opponent-co ## Announcing Apache Iceberg 1.11.0 DevFeed: [Announcing Apache Iceberg 1.11.0]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-05-27T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Apache Iceberg](), [Apache Spark](), [apache-flink](), [schema-evolution](), [Streaming](), [Encryption](), [Cryptography]() Tags: [apache-flink](), [apache-iceberg](), [apache-spark](), [encryption](), [kms](), [lakehouse](), [releases](), [schema-evolution](), [streaming]() ### AI overview Apache Iceberg 1.11.0 adds support for Apache Spark 4.1 and Apache Flink 2.1, makes both default build targets, and introduces changes including server-side REST catalog scan planning, partition statistics APIs, built-in envelope encryption with Google KMS support, and Google Storage Analytics integration. ### Source excerpt by Alex Stephen & Talat Uyarer, Lakehouse Apache Iceberg project has just launched version 1.11.0! A lot has happened since the last version. Iceberg 1.11.0 adds support for Apache Spark 4.1 and Apache Flink 2.1, the latest releases of the two engines and makes both the default build targets The rest are more structural. The REST catalog learns to plan scans server-side, shifting metadata work off the query engine. A new partition statistics scan API gives optimizers a clean, supported way to read a table's shape. Built-in table encryption arrives with envelope encryption and Google KMS support. And Google Storage Analytics library integration makes your Iceberg workloads faster than before. Let's take a look at some of the biggest changes. Spark & Flink Updates As Spark and Flink are moving forward, the 1.11.0 release is pushing forward for new version support in both. Spark 4.1 & DSv2 Migration: Spark 4.1 unlocks is MERGE INTO with automatic schema evolution: Spark's newer MERGE syntax accepts a WITH SCHEMA EVOLUTION clause, so a MERGE whose source carries columns the target table lacks can add those columns to the table within the same statement, with no separate ALTER TABLE round trip. Beyond the version bump, the 1.11 Spark connector also modernizes against Spark's newer DataSource V2 APIs and adds an asynchronous micro-batch planner that speeds up Structured Streaming. Flink Ecosystem Updates: Initial work for Flink 2.1 support has landed in the core repository, continuing Iceberg's promise of providing first-class, low-latency streaming sink capabilities. The centerpiece of the Flink work is the DynamicIcebergSink, an experimental sink that breaks the old one-sink-per-table model: a single sink routes each record to a table chosen at runtime, creating tables on demand and evolving their schemas and partition specs on the fly as the input changes including dropping columns once you opt in with dropUnusedColumns. In addition to DynamicIcebergSInk work Flink sta ## TestParameterInjector introduces an idiomatic Kotlin API DevFeed: [TestParameterInjector introduces an idiomatic Kotlin API]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-05-25T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Kotlin](), [Testing](), [unit tests](), [test-coverage](), [Java](), [Open Source]() Tags: [java](), [junit4](), [junit5](), [kotlin](), [open-source](), [parameterized-tests](), [test-coverage](), [testing](), [testparameterinjector](), [unit-tests]() ### AI overview Google announces KotlinTestParameters, a Kotlin-only API for TestParameterInjector. It uses Kotlin default function arguments to make parameterized tests type-safe, concise, and compatible with refactoring tools, avoiding string-based YAML maps and verbose provider classes. ### Source excerpt by Jens Nyman, TestParameterInjector Team In March 2021, we announced the open source release of TestParameterInjector: a simple but powerful parameterized test runner for JUnit4. In September 2022, we followed up with JUnit5 support, bringing our framework to developers who had moved on to the Jupiter API. We're excited to announce our biggest update yet for our Kotlin users: KotlinTestParameters. The de facto standard for parameterized testing When we first introduced TestParameterInjector, we shared a graph showing its rapid adoption within Google. Over the past few years, that trajectory has continued to a point where TestParameterInjector is the de facto parameterized test framework. Usage of all other alternative frameworks continues to steadily decline, while TestParameterInjector's adoption keeps growing rapidly. It has fundamentally lowered the barrier to writing data-driven unit tests, empowering Googlers and open source developers alike to maximize test coverage with minimal boilerplate. We believe its ubiquity internally is a strong testament to its reliability and utility for the broader developer communities. The Kotlin challenge As Kotlin's popularity has surged, developers have naturally been writing more of their TestParameterInjector tests in Kotlin. However, specifying explicit test values in Kotlin historically meant falling back to Java-centric paradigms. If you wanted to provide specific values to a test, you typically had three options, none of which felt truly idiomatic in Kotlin: @TestParameter({"123", "456"}): This relies on string arrays, limiting you to a subset of types that the string parsing supports. @TestParameters: This allows for more complex sets of data, but relies on YAML strings (e.g.,"{age: 17, expectIsAdult: false}"). These strings however are not type-safe, and are completely ignored by IDE refactoring tools. Provider classes: For complex types that couldn't be easily represented in strings, you have to write Provider classe ## Kube-Agents: an intent-driven presentation layer for Kubernetes DevFeed: [Kube-Agents: an intent-driven presentation layer for Kubernetes]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-05-21T18:30:00Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [Kubernetes](), [control-plane](), [API](), [YAML]() Tags: [agents](), [api](), [autonomous](), [control-plane](), [kube-agents](), [kubectl](), [kubernetes](), [yaml]() ### AI overview The article presents Kube-Agents, a proposed system of autonomous and human-in-the-loop agents that would provide an intent-driven presentation layer for Kubernetes. It describes agents that complement existing Kubernetes interfaces by observing cluster state and carrying out operations through existing APIs. ### Source excerpt by Adrian Chung, Abdelfettah Sghiouar & Matt Larkin, Google Kubernetes Engine Empowering every engineer to do more with Kubernetes Kubernetes is the gold standard for container orchestration. Its power, flexibility, and rich API surface are exactly why it has become the foundation of modern cloud-first infrastructure. Today, engineers express that power through the K8s API, declarative YAML manifests, and cloud consoles, a remarkably expressive toolbox. We believe the next step is to expand how engineers interact with that toolbox. A Kubernetes expert should be able to converse with a deep-domain peer that speaks fluent control-plane and can reason about cluster state in real time. An engineer who isn't a Kubernetes specialist should be able to express higher-order intent, such as "deploy my application," "rebalance this workload" and have it carried out safely against the same powerful APIs. Both audiences get more leverage out of the platform they already trust. This is the vision behind Kube-Agents: a system of intelligent, autonomous, and human-in-the-loop agents that act as a new, intent-driven presentation layer for Kubernetes. We are moving from declarative intent via API to higher-order, human intent-driven operations while preserving everything that makes Kubernetes great underneath. The Vision: Expanding the Presentation Layer Today, engineers do impressive work stitching together metrics, alerts, and multi-step commands to keep clusters healthy. Agents extend that work, not replace it. By complementing existing interfaces with autonomous agents, engineers can choose the level of abstraction that fits the task: drop down to kubectl and YAML when precision matters, or describe intent in plain language when speed and clarity matter more. The agents continuously observe system state and can execute complex operations in real time on the engineer's behalf. This isn't about hiding Kubernetes. It's about giving every engineer a more capable collaborator on top o ## The Journey Begins: Meet the 2026 GSoC Contributors! DevFeed: [The Journey Begins: Meet the 2026 GSoC Contributors!]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-04-30T18:30:00Z Content type: news Language: en Sources: [Google Open Source Blog]() Topics: [Google](), [Open Source](), [Development]() Tags: [2026](), [community](), [contributors](), [google-summer-of-code](), [gsoc](), [mentoring](), [open-source](), [program](), [student-programs]() ### AI overview Google Summer of Code welcomes its 1,141 contributors for 2026. The article reports 15,245 applicants from 131 countries, 23,371 proposals, 184 mentoring organizations, and more than 2,000 mentors and organization administrators. It also describes the 3.5-week Community Bonding period before coding begins on May 25. ### Source excerpt by Stephanie Taylor, Mary Radomile & Lucila Ortíz, Google Summer of Code A warm welcome to the 1,141 Contributors of Google Summer of Code (GSoC) 2026! We are excited to start this new edition alongside our 184 mentoring orgs. Organizations reviewed a record-breaking 23,371 proposals to find the best matches for their communities. 2026 Application Statistics: 15,245 applicants from 131 countries submitting a total of 23,371 proposals Over 2,000 mentors and org admins What's Next? Before the first line of code is written, there is Community Bonding. This 3.5-week GSoC tradition is about more than just tool configuration; it's about immersion. It's a dedicated space for Contributors to master the codebase, align with community standards, and understand the 'why' behind their projects. By the time the coding period begins, every Contributor is ready to turn project fundamentals into real-world impact. The official coding period begins on May 25. For our contributors, this period represents a deep dive into collaborative development, offering the chance to learn new tools and contribute to the heartbeat of open source projects. Thank you, Mentors! Finally, we want to express our deepest gratitude to our phenomenal Mentors and Org Admins. As AI profoundly shifts the landscape of open source communities, GSoC is no exception. Your patience, grit, and tireless volunteer efforts are the heartbeat of this program, ensuring its continued success as we welcome a new generation of contributors into the open source ecosystem. ## Introducing AMS: Activation-based model scanner for open-weight LLM safety verification DevFeed: [Introducing AMS: Activation-based model scanner for open-weight LLM safety verification]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-04-27T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [Artificial Intelligence](), [Large Language Model](), [Security](), [Open Source](), [Testing](), [Fine-tuning](), [hugging face]() Tags: [ai-security](), [benchmark](), [devsecops](), [evaluation](), [llm-safety](), [model](), [model-verification](), [open](), [open-source](), [safety](), [security]() ### AI overview Google introduces AMS, an open-source Activation-based Model Scanner for verifying the safety-related integrity of open-weight large language models before deployment. The tool analyzes geometric structure in model activation space instead of sending behavioral-test prompts and is described as scanning models in 10-40 seconds. ### Source excerpt by Glen Messenger, Google Kubernetes Engine (GKE) The open-weight model ecosystem is thriving--and so is its shadow. A 2025 study identified over 8,000 safety-modified model repositories on Hugging Face alone, with modified models complying with unsafe requests at rates of 74% compared to 19% for their original instruction-tuned counterparts. For organizations deploying open-weight models, a critical question emerges: how do you know the model you downloaded is safe to run? We believe defensive security tools should be widely available. AMS represents our contribution to a safer AI ecosystem--one where developers everywhere can verify model integrity before deployment. Today we're releasing AMS (Activation-based Model Scanner), an open source tool that answers this question in 10-40 seconds--without sending a single prompt. The Problem with Behavioral Testing Traditional safety verification relies on behavioral testing: send harmful prompts, check if the model refuses. This approach has three fundamental limitations. It's slow. Comprehensive benchmarks like HarmBench require hundreds of queries. For organizations running continuous integration pipelines or screening large model registries, this can be impractical. It's incomplete. No benchmark covers every harmful behavior. Models can exhibit safe behavior on known test sets while remaining unsafe on novel or out-of-distribution prompts. It's gameable. Models can be fine-tuned to refuse benchmark prompts while complying with novel attacks--a known limitation of purely behavioral evaluation approaches. A Structural Approach Clean vs Tampered Models AMS takes a different approach entirely. Instead of testing what a model says, it measures how a model thinks. Safety training creates measurable geometric structure in a model's activation space. Instruction-tuned models develop internal "direction vectors"--representations that separate harmful content from benign content with high statistical confidence (4-8σ separation). Wh ## Google introduces the A2Family of open source protocols and tools for AI agents DevFeed: [Google introduces the A2Family of open source protocols and tools for AI agents]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-04-23T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [A2A protocol](), [Artificial Intelligence](), [interoperability](), [Model Context Protocol](), [Open Source](), [linux foundation]() Tags: [a2a](), [a2a-protocol](), [a2ui](), [adk](), [agent2agent](), [agents](), [ai](), [ai-agents](), [ap2](), [interoperability](), [linux-foundation](), [open-source]() ### AI overview Google presents the A2Family, a suite of open source protocols and tools for building, connecting, and scaling AI agents. The article describes A2A for agent interoperability, its relationship with MCP and skills, and A2UI for rendering interactive interfaces without executing arbitrary code. ### Source excerpt by Daryl Ducharme, Google Open Source & Alan Blount, Cloud AI At Google, we know that building on open source gives teams the freedom and flexibility to use meaningful technologies faster. Openness drives innovation and security, and it is core to our mission. As we look toward the future of computing, we want to ensure that developers across all open source communities have the foundational tools they need to build secure and collaborative AI systems. That is why we are excited for you to get to know the "A2Family"--a suite of open source protocols and tools designed to help you build, connect, and scale your AI agents. A2A: The cornerstone of agent interoperability The Agent2Agent (A2A) Protocol is an open standard designed to enable seamless communication and collaboration between AI agents. It provides the definitive common language for agent interoperability in a world where agents are built using diverse frameworks and by different vendors. Originally developed by Google, A2A has now been donated to the Linux Foundation. As a famous open source aphorism reminds us: "If you want to go fast, go alone. If you want to go far, go together." A2A brings this collaborative philosophy to AI, allowing agents to delegate sub-tasks, exchange information, and coordinate actions to solve complex problems that a single agent cannot. MCP & Skills: Agents need tools and skills Since day one A2A has loved MCP, and we love skills too ♥. Agents discover, negotiate, converse, make plans, adapt when those plans don't work out - that's a different interaction pattern than a tool and that's what A2A was built for. But for your agents to function, they need access to tools, and instructions on how to use those tools safely and securely. While MCP and A2A might not be from the same origin story, they are a family that works better together. When you're not sure - if it's a quick deterministic resource or action, it's a tool, but if you may end up with a conversation, it's an agent. Ano ## A year of open collaboration: Celebrating the anniversary of A2A DevFeed: [A year of open collaboration: Celebrating the anniversary of A2A]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-04-16T20:55:00Z Content type: opinion Language: en Sources: [Google Open Source Blog]() Topics: [A2A protocol](), [Artificial Intelligence](), [Google](), [interoperability](), [Open Source](), [linux foundation](), [Security](), [Load Balancing]() Tags: [a2a](), [a2a-protocol](), [a2april](), [agent2agent](), [agents](), [ai](), [ai-agents](), [amazon](), [amazon-web-services](), [cisco](), [cryptographic](), [interoperability](), [linux-foundation](), [load-balancing](), [microsoft](), [open-source](), [sap](), [security](), [specifications](), [standard]() ### AI overview Google reflects on the first year of the Agent2Agent (A2A) protocol, including its donation to the Linux Foundation, the growth of its supporting ecosystem, and the release of A2A Protocol v1.0. The article highlights security, enterprise architecture, and interoperability improvements for multi-agent workflows. ### Source excerpt by Patricia Cruz, Google Open Source One year ago, on April 9th, 2025 Google announced the Agent2Agent(A2A) protocol. We saw the need for a "common language" that allows AI agents built on different frameworks to collaborate well across diverse systems. Then, on June 23, 2025 at the Open Source Summit North America in Denver, Mike Smith stood on stage to share a pivotal moment for the future of AI interoperability when Google officially donated the A2A protocol to the Linux Foundation, establishing it as a vendor-neutral, community-governed standard. This move was driven by a core belief: for AI agents to truly transform how we work and live, they must be able to communicate across framework boundaries and organizational silos without being locked into a single provider's ecosystem. By placing A2A under the neutral stewardship of the Linux Foundation, we opened the doors for the entire industry to build, contribute, and innovate together. A Foundation of Partners The formation of the A2A Project was made possible through the support of our founding members, including Amazon Web Services, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. Over the past twelve months, this coalition has grown, with over 100 technology companies now supporting the project. From Prototype to Production The momentum since the donation has been remarkable. What began as a Google-led initiative has evolved into critical infrastructure for horizontal, peer-to-peer collaboration. Just one month ago, in March, the project reached a major milestone with the release of A2A Protocol v1.0, the first stable, fully production-ready version of the standard. Key achievements from the community this year include: Enhanced Security: The implementation of Signed Agent Cards for cryptographic identity verification, ensuring trust in multi-agent workflows. Web-Aligned Architecture: Refined specifications that support familiar load-balancing and security patterns for enterprise-scale deployments. Ecosystem ## Jaspr: Why web development in Dart might just be a good idea DevFeed: [Jaspr: Why web development in Dart might just be a good idea]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-04-15T18:30:00Z Content type: article Language: en Sources: [Google Open Source Blog]() Topics: [Dart](), [Framework](), [Flutter](), [Web Development](), [Open Source](), [Google]() Tags: [css](), [dart](), [flutter](), [framework](), [google](), [jaspr](), [open-source](), [web-development]() ### AI overview This article introduces Jaspr, an open source web framework for building dynamic, fast-loading, SEO-friendly websites in Dart. It explains the framework's origins, its Flutter-like developer experience, and its use of native HTML and CSS. Google selected Jaspr to rebuild the official Dart and Flutter websites. ### Source excerpt by Kilian Schulte, Netlight Jaspr, the open source web framework, is built on Dart Most developers know Dart as the language that powers Flutter, the multi-platform app framework. But the Dart ecosystem has so much more to offer. For example: Jaspr, a web framework that provides a familiar Flutter-like experience, but is made for building fast, SEO-friendly, and dynamic websites natively in Dart. Dart on the web is not a new idea. Initially, Dart was designed to run natively in browsers, similar to JavaScript. Google even developed AngularDart, a pure-Dart version of the popular JS framework. And although this is no longer supported, it resulted in some surprisingly powerful web tooling for Dart. Back in 2016, teams at Google chose Dart for its strong type safety and excellent development experience, and it has only improved since then. However, all of this was unknown to me when I started building Jaspr in 2022. As a web developer who had transitioned to Flutter, I had grown to love Dart and wanted to explore using it for web development. So Jaspr started as a personal challenge: What would a modern web framework look like if it was built entirely in Dart? Creating Jaspr as an open source project has been one of the most challenging, but also rewarding journeys of my career. Starting out as a solo maintainer is definitely hard work, but it comes with absolute creative freedom. I can explore unconventional ideas, design APIs exactly how I envision them, and integrate modern features seen in other frameworks. All without being slowed down by processes or roadmaps. I poured more than three years of late nights and weekends into the framework. That dedication finally paid off in a way I had never imagined: Google selected Jaspr to completely rebuild and power the official Dart and Flutter websites. Architecture & design To understand how Jaspr actually works, let's look at its underlying design. Jaspr is primarily targeted at Flutter developers venturing into web devel [Next page]()