This Week in Open Source for July 16, 2026

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 Cloud: PostgreSQL community contribution updates

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 sessions included a mix of keynotes, breakout technical sessions, sponsor sessions, and booth interactions.

Google Cloud Sessions

Session Title	Session Type	Speakers
Database And GenAI	Keynote	Paresh Rathod
Experimenting with a Global Index in PostgreSQL	Technical Talk	Dilip Kumar
GCP - Best home to run PostgreSQL	Sponsor Session	Trusar Borse, Abhijeet Rajkur
Beyond shared_buffers: On-Demand Memory PostgreSQL	Technical Talk	Rajeev Rastogi, Vaibhav Popat
Where is my Memory	Technical Talk	Pushkar Kalidkar
Agentic AI Applications with GCP Databases	Keynote	Abhijeet Rajkur, Rishi Kapoor, Saurabh Gupta

PGDay Paris & PGDay France 2026

France hosts two distinct flagship PostgreSQL events, and Google Cloud is deeply embedded in both as both organizers and technical contributors. While PGDay Paris serves as an international, English-language hub for the European community, PGDay France is a community-driven, traveling event that focuses on the francophone ecosystem, taking place in Toulouse for 2026.

Key Highlights

• Matt Cornillon served on the organization committee for PGDay France, while Yves Colin contributed as a member of the program committee.

Google Cloud Sessions

Session Title	Session Type	Speakers
Creating a "Dungeon Master" with Postgres and MCP	Technical Talk	Matt Cornillon
Create your first AI agent with PostgreSQL	Workshop	Matt Cornillon, Yves Colin

PGDay FOSDEM 2026

FOSDEM PGDay is a prominent open source gathering that brings together developers from across the globe to discuss the latest PostgreSQL advancements. It serves as an essential platform for exploring emerging paradigms in database development.

Key Highlights

• Exploration of how AI-assisted workflows are redefining development beyond standard autocomplete for SQL queries.

Google Cloud Sessions

Session Title	Session Type	Speakers
Vibe-coding with Postgres: really?	Technical Talk	Matt Cornillon

PGConf Belgium 2026

PGConf Belgium 2026 took place at the UCLL Campus Proximus in Haasrode, Belgium, serving as an outstanding learning and networking platform for the local PostgreSQL community and students.

Key Highlights

• The session was selected by faculty as supportive material for a database exam following deep student engagement.

Google Cloud Sessions

Session Title	Session Type	Speakers
Creating a "Dungeon Master" with Postgres and MCP	Technical Talk	Matt Cornillon

Nordic PG Day 2026

Nordic PG Day is the largest PostgreSQL event in the Scandinavian countries. The 2026 edition took place in Helsinki, gathering more than 130 PostgreSQL enthusiasts for a day of deep dives.

Key Highlights

• Google joined as an official Partner-level sponsor for the first time, including a dedicated table booth.

Google Cloud Sessions

Session Title	Session Type	Speakers
Unlock AI Agents with PostgreSQL	Technical Talk	Mats Berglin, Miguel Toscano

Swiss PGDay 2026

Swiss PG Day is the annual event organized by the Swiss PostgreSQL User Group in Rapperswil, Switzerland. The ninth edition featured sessions in both English and German.

Key Highlights

• Demonstration of the physical impact of pushing millions of vectors to PostgreSQL based on a real-world use case.

Google Cloud Sessions

Session Title	Session Type	Speakers
Surviving pgvector in production: a reality check	Technical Talk	Miguel Toscano

Postgres Conference: 2026 San Jose

Since its inception in 2007, the Postgres Conference has served as a cornerstone for advancement, fostering a rich environment for learning and professional networking.

Key Highlights

• Google proudly served as a sponsor for the event.
• Adapting PostgreSQL for the artificial intelligence era demands a transformation in operational approaches. With the rise of natural language tools and vibe coding speeding up development, Agentic AI places advanced demands on production databases. In their presentation, Vikas and Vishal examine how Google Cloud managed services have evolved to handle these workloads, providing architectural strategies and best practices for contemporary AI deployment.

Google Cloud Sessions

Session Title	Session Type	Speakers
Postgres and AI - Stronger Together!	Technical Talk	Vikas Arora and Vishal Bagga

Community Leadership and Committees

Googlers play a vital role in shaping the direction of the most prestigious PostgreSQL developer events. Our leadership in these committees helps ensure that enterprise-grade requirements—such as those needed for large-scale migrations—are part of the global conversation.

• PGConf.dev 2026: Dilip Kumar served on the Program Committee.
• PGConf India 2026: Dilip Kumar was a member of the Paper Selection Committee.
• PGDay France: Matt Cornillon was a member of the organization committee and Yves Colin served as a member of the Program Committee.

Looking Forward

Our commitment remains firm: to turn feedback from these global events into code, reviews, and active community partnerships. We thank the wider PostgreSQL community and the project's committers for their continued collaboration in making PostgreSQL better for everyone.

Acknowledgement

We extend our heartfelt appreciation to our open source community contributors for their outstanding dedication and active participation in making PostgreSQL conferences a great success.

Abhijeet Rajurkar, Darshan Nagarajappa, Dilip Kumar, Hannu Krosing, Mats Berglin, Matt Cornillon, Michael Bautin, Miguel Toscano, Niranjan Shivprasad, Paresh Rathod, Rajeev Rastogi, Vaibhav Popat, Vikas Arora, and Yves Colin

Furthermore, we are deeply grateful to the broader PostgreSQL open-source communities, especially the dedicated conference organizers, committee members, and all supporting sponsors.

Community feedback: How can corporations improve support for open source maintainers?

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 necessary to participate in monetary programs?

Advice from Maintainers: Consult a tax professional to understand the implications of various funding methods.

Manage and respect expectations

Beyond financial support, our discussion returned to the importance of respect and etiquette. Particularly, how can we manage expectations between heterogeneous creators, contributors and users - are maintainers clearly communicating their preferences, and are corporations actively respecting them? Some suggestions include:

• Adherence to community norms: Maintainers should share their preferred communication channels, while contributors - both human and agentic - must ensure they review and follow them.
• Consistency with documentation: Discrepancies between documented procedures and actual practices create friction for all participants. This standard should be upheld by both individual maintainers and corporate-managed projects.
• Clarity of intent: Many maintainers would like to understand the motivation behind a contribution and reserve the right to ask questions.

To improve specific program experiences, maintainers suggested:

• Consistent communication: Recipients of funding programs expect clearly communicated expectations regarding the timing and amount of disbursements.
• Transparency and discoverability: Maintainers would appreciate easily discoverable records that track program participation, active agreements, and verify the status of Contributor License Agreements (CLAs).

Let's keep learning as a community

While we cannot make any promises, we want to continue to learn and challenge ourselves to consider novel ways to support OSS communities and maintainers. As a member of our community, we value your opinion. We've created a Google form to collect any thoughts you might have, as well as gauge interest in another open meeting. We plan to share any and all learnings back with the community.

Documenting the manual: how curiosity and robotic arms led to a career in open source

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 existing features, and figured out how to send a plain-text patch via email.

"As it was my first patch, I was a bit intimidated by the procedure," Alejandro recalls. That intimidation led to a commit message he is still proud of today: roughly 120 lines of explanation for just 25 lines of new documentation. He wanted to prove that he had done his homework. The welcoming response from the maintainer encouraged him to keep going, leading to more patches and, eventually, a career-long dedication to clarity in open source communities.

Sustaining the commons

Google understands that open source is a "small community built on trust." By supporting maintainers like Alejandro, we help ensure that critical infrastructure—like the documentation that powers the Linux ecosystem—remains accurate and accessible for everyone. We believe that using open source comes with a responsibility to contribute and sustain it, which is why we partner with developers to maintain and grow critical projects.

Alejandro's work doesn't just help himself; it helps thousands of other programmers who rely on correct documentation to build the next generation of technology. As he puts it: "I couldn't program without correct documentation, so whenever I find an issue in documentation, I try to fix it."

A garden that needs tending

We often say that a community is a garden, not a building—it requires constant tending, not just initial construction. By sponsoring Alejandro, we are helping to tend that garden, ensuring the "manual" remains a living, breathing resource for the global developer ecosystem. Whether it is fixing a typo or documenting a high-precision networking macro, every contribution makes the "eyes" on the code that much sharper.

In-place pod restarts: Boosting efficiency and workload reliability in Kubernetes v1.35

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 proper set of nodes, recreating Pods can lead to other pending Pods taking over those resources. In-place restarts eliminate this race condition risk.

Previously, resolving these failures required destroying the entire Pod. For large batch or AI/ML workloads, where thousands of Pods might fail simultaneously, this can lead to "Thundering Herd" scheduling requests, delaying recovery and wasting expensive GPU/TPU compute time.

Introducing In-Place Restarts: The RestartAllContainers Action

Kubernetes v1.35 introduces the RestartAllContainers action, enabled by the RestartAllContainersOnContainerExits feature gate, which graduated to beta in 1.36 alongside its dependencies ContainerRestartRules and NodeDeclaredFeatures. This lets a container's exit behavior trigger a fast, in-place restart of the entire Pod on its existing node.
The Kubelet halts all containers while keeping the Pod sandbox intact, preserving critical infrastructure:

• Network Identity: Keeps the same IP, network namespace, and UID, completely bypassing IP reassignment.
• Hardware and Devices: Keeps GPUs/TPUs bound, eliminating scheduling and re-allocation delays.
• Storage Mounts: Volumes, including emptyDir and PVCs, remain fully mounted; their content is not cleared during restarts.

Once terminated, the Kubelet re-runs init containers (including sidecars, which are part of the init sequence) in order, guaranteeing a clean setup in a known-good environment.

A Native Pod Specification Example

You can implement this under the container's restartPolicyRules field. Here is a quick example of how a watcher sidecar can trigger an in-place restart of the entire Pod by exiting with code 88:
YAML
Note: Image names and paths in the YAML below are for illustrative purposes.

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
    - name: setup-environment
      image: registry.k8s.io/ml-tools/setup-worker:v1.0
    - name: watcher-sidecar
      image: registry.k8s.io/ml-tools/watcher:v1.0
      restartPolicy: Always
      restartPolicyRules:
        - action: RestartAllContainers
          exitCodes:
            operator: In
            values: [88]
  containers:
    - name: main-application
      image: registry.k8s.io/ml-tools/training-app:v1.0

The Operational Impact of In-Place Restarts

For organizations running distributed workloads, RestartAllContainers provides serious operational advantages:

• No Control Plane Overhead: By preserving identity, clusters avoid scheduling latency and DNS propagation. This was a key factor for JobSet using this feature to reduce recovery from minutes to seconds.
• Node Locality Preservation: Since the Pod stays anchored to the same node, restarted containers can instantly access local, warm storage caches.
• Maximized Hardware Efficiency: In distributed AI training, losing a single node halts the entire job. Keeping accelerators like GPUs/TPUs bound lets workloads resume training significantly faster, directly reducing compute costs.

Observability and SRE Best Practices

To support monitoring, Kubernetes v1.35 introduces the AllContainersRestarting Pod condition. Set to True during restarts, it alerts SREs and autoscalers, preventing false-positive alerts, while container restart counts increment to let Prometheus easily track recovery events.
To use in-place restarts successfully, shift your mental model to "persistent sandboxes" and follow three best practices:

1. Ensure Reentrancy: Kubelet only guarantees "at least once" execution for init containers. Reentrancy is now a standard requirement, so your code must be fully idempotent.
2. Plan for Termination Handling: Graceful termination (preStop hooks) is not supported for in-place restarts. SIGKILL is almost immediate, so applications must handle sudden exits gracefully.
3. Prepare External Tooling: CD and observability tools should expect re-running init containers without interpreting them as new deployments.

What's Next?

This beta capability is a major step toward fluid workload management and serves as a building block for advanced community features like JobSet in-place restarts (KEP-467).
Our work on KEP-5532 reflects our commitment to transparent open source governance. Developed collaboratively within SIG Node, this feature shows how we hold ourselves to high citizenship standards; making our design, goals, and intentions transparent while building shared best practices that benefit everyone. We encourage you to experiment with Kubernetes v1.35 and share your feedback with the community!

Learn More

• Read the Kubernetes Pod Lifecycle Documentation.
• Explore KEP-5532: Restart All Containers on Container Exits.
• Review theKubernetes v1.35: Restart All Containers Blog Post.
• Join the SIG Node Community on Slack (#sig-node).