DEV Community: The ASF

ASF Project Spotlight: Apache Iggy

The ASF — Thu, 22 Oct 2026 14:52:13 +0000

Apache Iggy™ is one of the ASF's newest Top-Level Projects. In this Spotlight, the ASF spoke with PMC members Piotr Gankiewicz and Kranti Parisa about the engineering choices behind Iggy, the long road to clustering, and the community that has grown around it.

What Is Apache Iggy and Why It Exists

Can you tell us a bit about Apache Iggy?
Apache Iggy is a persistent message streaming platform written in Rust. It stores messages in streams, topics, and partitions as an append-only log, while consumers read independently or through consumer groups. The server is distributed as a single binary with no external broker or database dependency. It supports TCP, QUIC, WebSocket, and HTTP, and provides SDKs for Rust, C#, C++, Java, Go, Python, Node.js, and PHP. The project also includes a CLI, Web UI, benchmarking tooling, an MCP server, and a connector runtime with sources and sinks for systems including PostgreSQL, Elasticsearch, MongoDB, Apache Iceberg™, ClickHouse, Delta Lake, Apache Doris®, and more. Iggy became a Top-Level Project on 19 August 2026 and released 0.9.0, its first version with replication, on 21 September 2026.

What is changing in the streaming landscape?
The role of streaming is broadening. Real-time data increasingly crosses boundaries between services, interactive applications, operational databases, analytical systems, data lakes, and AI-oriented workloads. That creates pressure for streaming infrastructure to be efficient enough to sit on more data paths, accessible from more environments, and interoperable with a wider ecosystem. Iggy’s response is to combine a durable append-only log with modern systems engineering, multiple native protocols, broad language support, and connectors rather than optimizing only for a single server-to-server integration model.

Apache Kafka® and other streaming platforms already existed. Why build another one?
Previous generations of streaming systems proved the importance of durable, ordered event logs. But many were designed around the hardware, runtimes, and application architectures of an earlier era. Iggy began with a different question: if we designed a persistent streaming engine from scratch today, what would we do differently? The project uses Rust and modern systems techniques including thread-per-core execution, shared-nothing architecture, Linux io_uring, zero-copy data paths, and Direct I/O. The objective is not to reproduce Apache Kafka with a different implementation language. It is to rethink the streaming engine around predictable low tail latency, high throughput, resource efficiency, a smaller operational footprint, and a simpler path from application code to durable streams.

Streaming Beyond Server-to-Server

Why is multi-protocol support a core part of Iggy’s design?
Real-time systems are no longer composed only of backend services speaking one broker protocol. Producers and consumers increasingly include backend services, browsers, developer tools, edge applications, gateways, data platforms, and AI-oriented systems. Iggy therefore treats protocol choice as part of the developer experience. TCP provides a direct high-performance path, QUIC brings a modern transport option, WebSocket makes persistent bidirectional streaming natural for browser and interactive applications, and HTTP lowers the integration barrier for environments where a dedicated streaming client is impractical. These protocols expose the same durable streaming model rather than creating separate products for separate application surfaces.

How does that change the kinds of applications a streaming engine can serve?
A conventional broker is often deployed primarily as infrastructure between backend services. Iggy’s protocol surface is intended to make the durable log directly useful across a wider range of application boundaries. The same underlying stream can participate in service-to-service eventing, telemetry and observability, real-time user experiences, data ingestion, CDC, AI and agent event flows, video or IoT pipelines, and movement of data into databases, search systems, analytic engines, and data lakes. The architectural idea is simple: durable streaming should be a reusable systems primitive, not an integration pattern limited to one class of client.

Developer Experience as a Systems Feature

Why invest in native SDKs across so many languages?
A streaming platform is only as usable as the path from an application to the stream. Iggy maintains SDKs across major application ecosystems including Rust, C#, C++, Java, Go, Python, Node.js, and PHP. The goal is to let teams use the project from the language and runtime they already operate, with idiomatic APIs and runnable examples, rather than forcing every team through a single language binding or a bespoke integration layer. Community members helped drive this breadth early in the project by contributing SDKs for the languages they used themselves.

Where do connectors fit into that strategy?
Protocols and SDKs solve application connectivity; connectors solve system connectivity. Iggy’s connector runtime links streams to operational databases, search engines, analytics systems, and lakehouse storage. Together, the protocol, SDK, and connector layers are intended to reduce the amount of glue code required to move real-time data through a heterogeneous architecture.

Designed Around Modern Systems Engineering

What are the key architectural choices behind Iggy?
Iggy uses a thread-per-core, shared-nothing design. Each CPU core runs its own thread without shared hot-path state, and Linux io_uring is used for disk and network I/O. Because the server is written in Rust, it has no garbage collector. The project has also invested in zero-copy data paths and Direct I/O. These choices are aimed at reducing scheduling, synchronization, memory-management, and I/O overhead that can show up as latency variance under load.

Why focus so much on tail latency and efficiency?
Average latency can hide the behavior users actually experience under load. Streaming infrastructure sits on the path of many downstream systems, so slow outliers can propagate through an architecture. Iggy’s engineering work therefore emphasizes predictable tail behavior as well as throughput. The project’s published benchmark shows a single-node producer P99 latency of about 1 ms, and the project provides iggy-bench so users can measure performance on their own hardware rather than relying only on published numbers.

What changed with clustering?
Clustering was one of the project’s most requested capabilities. An early experiment used Raft, but the team later moved to Viewstamped Replication Revisited (VSR)-based consensus, chosen for the project’s high-throughput replication goals. The groundwork landed in 0.7.0, and 0.9.0 is the first release designed to run as a multi-node cluster. Single-node operation remains available for simpler deployments.

Real-World Use and Interoperability

What kinds of workloads is the community targeting?
Apache Iggy is designed for real-time, data-intensive workloads where predictable latency, throughput, and efficiency matter. Current use cases and integrations span event streaming, logs and observability, real-time analytics, CDC and data pipelines, AI and agent data streams, video and IoT ingestion, and high-volume movement between operational systems and downstream stores. Apache Camel™ includes a camel-iggy component, LakeSail pairs Iggy with its Sail compute engine, and AWeber’s Imbi platform engineering tool uses Iggy for message streaming. The project also maintains a Powered By page where adopters can share their use cases.

Does adopting Iggy require an all-or-nothing migration?
No. Interoperability is an important direction for the project. The community is developing a Kafka protocol gateway so existing Kafka applications can work with Iggy, while the connector ecosystem provides paths into databases, search engines, analytic systems, and lakehouse technologies. This lets teams evaluate Iggy at a specific boundary or workload rather than treating adoption as a wholesale replacement exercise.

Getting Started and Getting Involved

What is the best way to try Iggy?
Start with the official documentation and run the server with Docker or from source. Build a producer and consumer using the SDK that matches your application stack, then use iggy-bench to test the workload on your own hardware. The published benchmark site provides a reference point, while the project’s Discord and dev mailing list are the places to ask questions and discuss designs with the community.

How can people contribute beyond code?
Try Iggy on a real workload and report what you learn. Improve documentation and examples. Help answer questions. Share an integration or operational pattern. Add your organization and use case to the Powered By page. Present at a community meetup. For code contributions, the project’s good first issues provide an accessible starting point.

What does the future hold for Apache Iggy?
The immediate focus is hardening clustering on the path to 1.0. A Kafka protocol gateway is in progress, and the community is exploring multi-leader replication per partition, tiered storage, a message registry, embedded key-value storage, and additional connectors. The broader direction remains consistent with the project’s original question: how should durable streaming evolve when modern hardware, application architectures, and real-time workloads look very different from the environment in which the previous generation of streaming platforms was designed?

Resources

Website: https://iggy.apache.org
Documentation: https://iggy.apache.org/docs/
GitHub: https://github.com/apache/iggy
Benchmarks: https://benchmarks.iggy.apache.org
Mailing lists: https://iggy.apache.org/community/mailing-lists/
Discord: https://discord.gg/apache-iggy
Powered By: https://iggy.apache.org/powered-by/

About the Interviewees

Piotr Gankiewicz is the original creator of Apache Iggy and a member of the Apache Iggy PMC. He previously worked as a software architect in fintech, trading systems, and cybersecurity, was a Microsoft MVP for his open source work, and co-founded DevMentors.io.

Kranti Parisa is Chair of the Apache Iggy PMC and led Iggy's journey into the ASF. A longtime contributor to Apache Lucene®, Apache Solr™, and Apache Camel™, he co-authored the books Apache Solr Enterprise Search Server and O'Reilly’s award-winning Reliable Machine Learning.

Security scanning at Foundation scale

The ASF — Mon, 28 Sep 2026 17:00:00 +0000

By ASF Tooling and ASF Security

During a three-day window in August 2026, the Apache Software Foundation (ASF) ran full security scans across 230 of the foundation’s repositories. The work was done by the ASF Security and ASF Tooling teams, within the Foundation’s Responsible AI Initiative (RAI), using Anthropic’s Claude Mythos 5 through their Project Glasswing security program. Findings from scan results are now being shared with the projects that own the code through the Foundation’s official disclosure path, and remediation is underway.

This post describes how that came together: what prompted the scans, what we had already built, what the projects did to prepare, how the scans ran, and where the results went. It is a report on work in progress rather than a finished story, made possible by a recent donation by Anthropic.

Why we started

Two events happened close enough together to become one effort. The first was that ASF Security received Mythos-based scans run by friendly parties from Alpha-Omega on two ASF projects and analyzed the results. Automated security analysis is not new to the Foundation, but these were different: specific, well-reasoned, and detailed enough to provide value. Seeing what the method could do on real ASF code changed the question from whether to use it to how to use it well.

The second event is the growing volume of AI-generated vulnerability reports arriving at open source projects. Anyone can now point a capable model at a codebase and forward whatever results come out. Some of those reports are helpful. Many are not, and separating the two comes at the cost of maintainer attention that projects often do not have to spare. Even reviewing constructive reports could take up too much time. The problem is going to get worse, regardless of what the Foundation does.

Together these events pointed at the same potential solution. If AI-generated security analysis is going to arrive at ASF projects, the Foundation should be the one running it with the projects, in terms of the projects set, and with enough context that the output is worth reading. This motivation generated the threat-modeling effort the Security team would implement.

Meanwhile, ASF Tooling had been working on the same problem from the other side. Scanning a project on demand does not scale past a handful of projects and leaves everyone else waiting. Tooling wanted scanning to be something a project could simply have available, alongside other Foundation-provided infrastructure.

What ASF Tooling had already built

Since early 2026, ASF Tooling has been running an automated audit pipeline that evaluates code against the OWASP Application Security Verification Standard (ASVS). It runs on Gofannon, an agent platform the Tooling team has been developing.

The original goal was code quality on Apache Trusted Releases, the release-management platform Tooling is building: a specific codebase, a specific standard, a specific team that wanted to know where it stood. In developing an automated security scanning pipeline for its own use, Tooling found it had built a system general enough to apply to other codebases across the Foundation, and the purpose widened to providing scanning as a managed service any ASF project could use.

The pipeline is built around three model tiers: A light tier does high-volume filtering; a medium tier builds inventories of what the code contains; and a heavy tier does the analysis that needs real reasoning. The choice of model per tier, and parameters applied for each task, are configurable at runtime. The pipeline runs on an Opus, Sonnet, and Haiku ensemble, or on a Mythos, Gemma, and Qwen ensemble that puts self-hosted models on the two lighter tiers. Swapping between them does not touch the pipeline itself. That flexibility allows a balance among quality, speed, and cost for any given use case.

This process is automated: a project sets what it wants scanned, and the run proceeds, from a browser or through an API without supervision.

Through development of this audit pipeline, we discovered the critical need to provide LLMs with contextual information about the codebase they are reviewing regarding security posture, architectural decisions, team code standards, and even private information about deployment choices. These audit guidance inputs drastically reduced false positives — and even completely wrong inferences — from surviving through to a final report.

When we began the work with Project Glasswing, the pipeline found a second use. Running both approaches over the same repositories and comparing what each produced, turned out to be a good way to learn what each approach is actually good at which fed into how we tuned the Glasswing scans.

Preparing the projects

To set up scanning for success, ASF Security invited interested projects to work through a threat model. 75 Project Management Committees (PMCs), with more than 180 repositories, signed up. Each produced a description of its own security posture: the components that matter, the boundaries that are supposed to hold, and the assumptions the project has already made and does not want relitigated. In other words, what is fully trusted by design, what is delegated to whoever operates the software, and what is explicitly out of scope. A Threat Model skill contributed by Alpha-Omega enabled the Security Team to create individual threat models using an initial template, and helped them maintain ongoing communications with the PMCs at a time to create new models as well as verify and complete existing ones.

ASF Security reviewed every threat model before it fed anything downstream, checking that the model was correct and that it actually applied to the code as written.

The preparation paid for itself directly. Scanning against a reviewed threat model cost roughly one-fifth less than scanning without one, because the analysis spent its effort on the parts of the system the project considers most consequential instead of rediscovering documented design decisions. And even better, saving time of the maintainers, it allowed them to limit the findings to those that do not fall outside of the model.

Glasswing and Mythos 5

Anthropic’s Project Glasswing program has given a number of organizations access to the company’s most capable models for security research. The ASF joined as a participant to support the work.

Each scan is anchored on the project’s threat model. Scans were performed with Glasswing’s harness running in parallel sessions of Claude Code against Mythos 5. We did not customize the harness and provided a series of simple prompts to kick things off.

The quality of findings held up with low levels of false positives along with critical vulnerabilities each packaged with a drafted, separately reviewed patch attached. Getting to that level of results took minimal iteration, and in two batches we had our full result set.

Disclosure and remediation

Everything from these scans runs through the Foundation’s official disclosure path, flowing through Security governance and landing with responsible parties at each project.

Sensitive findings go to the affected project’s security or private list first. The PMC assesses the finding, decides what it means for their code, and remediates on their own timeline, as they would for a report from any other source.

Reports are ordered by what a maintainer should deal with soonest given how the software is actually deployed, rather than by severity label alone. A high-severity finding in a code path nobody reaches is not the first thing a volunteer should spend a Saturday on, and the reports say so.

What’s next

We are planning three enhancements.

First, we will make scans incremental. A repository scanned once should not be scanned from scratch the next time. The goal is a scan that knows its prior results, tracks what has changed in the threat model, and follows what has actually been fixed and what has been published as a CVE. We identified opportunities to avoid findings covered by the threat model by doing additional adversarial reviews. We also treat the first batch of reports as a learning opportunity and gather feedback from the PMCs that received them.

Additionally, we are looking at other scan types. Review of incoming vulnerability reports are the most immediately useful, given where this project started. Beyond that, we will implement additional OWASP specifications and other standard scan types, each looking at code from a different angle.

Finally, we are continuing to build toward scanning as a self-serve function, where a project chooses the scans it wants and runs them against a token budget the Foundation manages, rather than waiting for a small group to run them manually.

ASF Security (Mark Cox, Jarek Potiuk) and ASF Tooling (Dave Fisher, Andrew Musselman) would like to thank Anthropic (Jake Richards, Karlo Anton) for the Glasswing collaboration and the donated capacity that made this work possible, and the 75 PMCs who did the threat-modeling work that made the results worth reading (special thanks: Evan Rusackas, Piotr Karwasz, Jan Friedrich, Sean Palmer, Alastair McFarlane, Emmanuel Lécharny, Adam Monsen, Greg Stein, Paul King, and James Fredley).

From Friction to Flow: How ASF Tooling Is Lowering Barriers for Maintainers

The ASF — Mon, 21 Sep 2026 16:00:00 +0000

The Apache Trusted Releases (ATR) platform, a new tool from the ASF Tooling Initiative, is making it easier for open source maintainers across hundreds of independently governed ASF projects to ship secure, compliant releases without adding to their workload.

ATR automates the parts of the release process that used to depend on institutional knowledge (e.g., vote tabulation, SBOM validation, compliance checks), while still letting projects use the tools they already work in, from GitHub Actions to the command line. Rather than imposing one workflow across projects, it standardizes the underbelly and stays flexible on the surface.

For example, ATR reduced thousands of missing SBOM fields – such as required package components and metadata – to near complete coverage across releases. By automatically checking and flagging missing information as part of the release process, ATR addressed a problem that would have required maintainers to identify and fix those gaps manually, release after release. Hervé Boutemy of the Apache Maven PMC put it well: “It didn’t feel like we were being asked to change how we work: the system starts by helping us on the vote, then expands progressively at each project’s own pace.”

A new case study examines the impact of the ATR platform. It’s a good look at what “security infrastructure” can mean when it’s designed around maintainers instead of around compliance checklists – and why that distinction matters for a foundation as decentralized as the ASF.

If you’re an ASF contributor and want to try ATR yourself, it’s live at release-test.apache.org, with docs, an open API, and public source repos on GitHub.

Beyond the Hardware Hub: How ALC Taipei Turned Computex 2026 into a Milestone for the Apache Way

The ASF — Wed, 16 Sep 2026 16:00:00 +0000

By Chia-Ping Tsai
ALC Taipei Lead

[Figure 1] Long-time Apache Kafka contributors Jiunn-Yang and Chih-Yuan introducing ALC Taipei’s contributions to open-source veterans Brian Behlendorf and Justin McLean

Introduction

With the globally renowned Computex Taipei now behind us, it’s the perfect time to look back at how ALC Taipei has brought the Apache Way to life in Taiwan.

First and foremost, ALC Taipei successfully brought a diverse array of ASF projects straight to Computex. You could say this was the very first time the Computex exhibition floor featured a showcase purely dedicated to ASF open-source projects. It sparked engaging discussions among public sector representatives, industry leaders, and journalists, helping more people in Taiwan truly understand the value of open source and the Apache Way.

Second, ALC Taipei is steadily weaving the spirit of the Apache Way into public digital policy. We haven’t just joined digital policy discussions — we’ve also participated in press conferences, collaborating with the public sector to encourage more industries to invest their resources into open-source software.

Third, we are sparking new fires for the future. ALC Taipei has partnered with top universities in Taiwan to co-launch open-source courses. This allows students to grasp the Apache Way during their college years, dive into open-source contributions directly through their classes, and build real-world, hands-on experience.

Finally, we are fostering deeper community-to-community exchanges. ALC Taipei continues to serve as a bridge, inviting experts from other prominent open-source projects to grab a bite and dive into deep tech discussions. Our goal is for participants to not just get to know ALC Taipei, but to use us as a gateway to connect with the entire world.

The Spark: A Unified ASF Presence at Computex

For this event, ALC Taipei mobilized an incredible crew of over 30 members. For five straight days, eight hours a day, they were on the floor at the globally renowned Computex Taipei, passionately introducing every visitor to the world of open source and the Apache Way. And the team staffing the booth wasn’t just made up of the Apache Kafka folks you might have spotted in the photos! We were also joined by maintainers from a fantastic lineup of other ASF projects, including Apache Ozone, Apache Airflow, Apache Mahout, Apache YuniKorn, Apache DataFusion, and Apache Gravitino. The collaborative spirit didn’t even stop there — maintainers from projects under other open-source foundations, such as Ray and Flyte, stood shoulder-to-shoulder with ALC Taipei to champion the open-source movement together.

Beyond the bustling booth, several of our members also took the stage to deliver insightful talks. Dr. Wei-Chiu shared his deep insights and valuable experiences on navigating the intersection of open-source and commercial development. Zhe-you and Wei Lee gave a great presentation on how Airflow is evolving and leveling up in the AI era. Meanwhile, You-Cheng from the Ray project shared an inspiring story about how, by connecting through ALC Taipei, they successfully collaborated with a wave of external contributors to hit major open-source milestones.

Looking past the final day of Computex, ALC Taipei has established a multi-layered roadmap designed to integrate open-source ideals into the broader digital and educational ecosystem:

The Long-Term Blueprint: Rooting the Apache Way in Taiwan

Looking past the final day of Computex, ALC Taipei has established a multi-layered roadmap designed to integrate open-source ideals into the broader digital and educational ecosystem:

1. Integrating with Digital Policy

Building directly on recent high-level institutional discussions on open-source digital policy, the goal is to advocate for community-driven development frameworks in the public sector. Establishing official channels ensures that open-source methodologies become a core element of broader software strategy.

[Figure 3] Dr. Chia-Ping Tsai, ALC Taipei Lead, speaking at an official Ministry of Digital Affairs (MODA) press conference to advocate for open-source frameworks in public digital policy.

2. Cultivating the Next Generation: A Two-Pronged Mentorship Strategy

To secure the sustainable growth of open source, ALC Taipei is rolling out a comprehensive mentorship and talent development framework split into two core pillars:

Mobilizing Ecosystem Resources for Mentorship: We are collaborating across sectors, aligning with public-sector institutions and industry partners to mobilize vital resources. This collective effort aims to rally a broader network of experienced open-source mentors to guide and cultivate top-tier engineering talent, building a resilient pipeline of future contributors.

[Figure 4] Shaping collaborative digital frameworks: KubeRay maintainer Han-Ju, representing the ALC Taipei community, engages in a direct dialogue with public sector leaders and policy makers to deliver strategic recommendations on open-source policy

Bringing Open Governance Back to Universities: In partnership with leading universities, we are mobilizing active open-source mentors from within our OpenSource4You community to return to academic classrooms. These mentors teach practical open-source technologies and methodologies for upstream contributions, directly bridging the gap between theoretical computer science and global engineering practices.

[Figure 5] Bringing open governance to academia: Apache Kafka Committer Po-An returning to the university classroom to teach upstream contribution methodologies.

3. Fostering Grassroots Technical Ecosystems via OpenSource4You

In parallel with public sector and academic initiatives, ALC Taipei continues to nurture a vibrant local ecosystem by leveraging its foundation as OpenSource4You, its core technical community. Operating as a unified grassroots hub, it provides a welcoming environment where developers can share technical storytelling, network, and seamlessly practice the Apache Way in their daily workflows.

[Figure 6] Keeping it real: Open-source is built on human connection. This photo captures community members who traveled from across the country—via high-speed rail and flights—to gather over dinner, creating a grassroots space to discuss open-source sustainability, career growth, and mentorship.

Conclusion: Keeping the Journey Going

Although we have accomplished many unprecedented open-source milestones in Taiwan over the past year, this is truly just the beginning. Moving forward, we will continue to push the Apache Way further. This includes collaborating with the public sector and enterprise partners to channel funding and support for independent open-source developers.

At the same time, ALC Taipei will be leading delegations to participate in Community Over Code (C/C) in both Beijing and Glasgow. We are also actively in the early planning stages to bring a C/C event right here to Taipei!

Simply put, ALC Taipei is steadily evolving from a grassroots developer community into an organization with real policy impact and commercial appeal — perhaps even laying the groundwork for a future Taiwan Open Source Foundation. Yet, what allows us to stay true to our roots every step of the way is not just our unwavering belief in the Apache Way, but our incredible group of outstanding open-source engineers.

Thank you to The ASF, and thank you to everyone involved. Let’s continue using open source to make the world a better place, and let the world see the brilliant open-source energy coming from Taiwan!

Apache Geode 2.0, Part III: Lessons Learned and the Path Forward

The ASF — Tue, 15 Sep 2026 14:54:57 +0000

What Geode 2.0 taught us—and what comes next

By Jinwoo Hwang
Lead Developer, Project Lead, and Release Manager, Apache Geode 2.0
https://JinwooHwang.com

This post is divided into three parts. Part I explains why Apache Geode 2.0 matters. Part II walks through how it was modernized. Part III looks ahead—what we learned, what changed, and how you can help shape what comes next.

Apache Geode 2.0 represents more than a successful release—it captures hard-won lessons about large-scale modernization, the limits of backward compatibility, and the importance of communication in open source. This final section reflects on what this journey taught us, why Geode is now positioned for long-term sustainability, and how the future of the project depends not on any single contributor, but on continued shared effort.

Lessons Learned, Sustainability, and How to Get Involved

Apache Geode 2.0 reinforced several hard‑earned truths. Order matters. Foundational dependencies must come first. Tests should be modernized early to serve as a safety net. Large transformations succeed when broken into deliberate, incremental steps.

Backward compatibility has limits. When the ecosystem makes irreversible shifts, the responsibility shifts from avoidance to communication. Clear documentation, migration guidance, and early community engagement turn breaking changes into shared progress.

Most importantly, Apache Geode 2.0 succeeded because it was visible, discussed, reviewed, and improved together. Community engagement was not optional—it was essential.

The Road Ahead

Apache Geode 2.0 is now secure, modern, and positioned for long‑term sustainability. But its future does not belong to one person. It belongs to all those who choose to participate.

Contributions come in many forms: documentation, testing, design discussions, user support, and mentorship matter just as much as code. Open source thrives when effort is shared and generosity flows freely.

You can learn more at geode.apache.org, contribute on GitHub at github.com/apache/geode, join the mailing lists, or connect with the broader Apache community through communityovercode.org.

The Future Is a Shared Effort

Apache Geode 2.0 reflects the best of The Apache Way—collaboration, transparency, and a shared commitment to quality. My sincere thanks go to everyone who contributed, reviewed, and supported this release, with special appreciation to Sai Boorlagadda, Arnout Engelen, and Leon Finker for their critical contributions.

Open source does not thrive on heroic efforts alone—it thrives on participation. Whether your contribution is code, documentation, testing, feedback, or mentorship, there is room for you in the Apache Geode community. Apache Geode 2.0 reopened the door; what comes next is shaped by those who choose to walk through it.

Resources:

ASF Plus One Newsletter: August 2026

The ASF — Tue, 08 Sep 2026 04:00:00 +0000

Community News

The ASF has announced the keynote speakers for Community Over Code Glasgow, taking place October 11–14, 2026 in Glasgow, Scotland. The lineup features Adjunct Faculty at Carnegie Mellon University Stephen Walli, Executive Director of the Software Stewardship Lab Vlad-Stefan Harbuz, and Scottish Games Network CEO Brian Baglow, who will explore topics ranging from open source education and sustainability to the role of interactive technology in the economy.

The event will also feature Airflow Contributor Days and Lakehouse Day with opportunities for ASF project communities to connect, share knowledge, and collaborate. Register here.

Project Updates

Apache Geode 2.0 wraps up its modernization journey with lessons learned, key takeaways, and a look at what’s next for the project and its community. The project is now positioned for long-term sustainability, with its future shaped by continued contributions from the community.

Read Apache Geode 2.0, Part III: Lessons Learned and the Path Forward

The ASF announced that Apache Fluss has become a Top-Level Project. Fluss is an open source, lakehouse-native streaming storage system built for real-time analytics and AI, bringing streaming and historical lakehouse data together through a common table abstraction.

The ASF has welcomed Apache Pony Mail as a Top-Level Project. Pony Mail is a web-based mail archive browser built to scale to millions of archived messages with hundreds of requests per second. It allows users to browse, search, and interact with mailing lists including creating replies to mailing list threads.

The ASF announced that Apache Iggy has become a Top-Level Project. Iggy is a hyper-efficient, persistent message streaming platform written in Rust, built for predictable ultra-low latency and a minimal infrastructure footprint.

Apache Sourcelume has officially become a Top-Level Project, providing open source instrumentation for AI training-data provenance, giving dataset producers, model builders, and downstream consumers a shared, vendor-neutral way to document where training data came from and under what terms it may be used.

We’re also proud to celebrate six ASF Top-Level Project anniversaries this month:

1-5 Years
Apache HertzBeat
Apache Teaclave
Apache Training

10-15 Years
Apache Ignite
Apache Serf
Apache Lucene.NET

Foundation News

We released the FY2026 Annual Report with highlights from another year of growth across our projects and open source community. During the fiscal year, the ASF welcomed its 10,000th committer, reaching 10,225 committers across 302 projects. The ASF also continued to strengthen the infrastructure and tools that support open source development and software releases.

The report covers the launch of the Responsible AI Initiative, continued development of Apache Trusted Releases, contributions to international software supply chain standards, and the graduation of 11 projects to become ASF TLPs.

The ASF Tooling Initiative is helping open source maintainers reduce friction in the release process while improving security and compliance. This article explores how the Apache Trusted Releases (ATR) platform automates key release tasks, including vote tabulation, SBOM validation, and compliance checks, while allowing projects to continue using the tools and workflows they already rely on. Learn more about how ASF tooling is lowering barriers for maintainers.

Events

Airflow Summit
August 31-September 3, 2026
Austin, TX, USA

Fluss Forward London
September 22-23, 2026
London, UK

Lakehouse Day Glasgow
October 10, 2026
Glasgow, Scotland

Community Over Code Glasgow
October 11-15, 2026
Glasgow, Scotland

Community Over Code Sydney
November 18-19, 2026
Sydney, Australia

CloudStack Collaboration Conference
November 18-20, 2026
Edinburgh, UK

President’s Letter

You’re probably accustomed to seeing annual announcements that some organization you’re involved with, from your employer to your power company provider, has published its annual report. You probably then yawn and move on with your day. (With the exception of the handful of people who find this sort of thing to be more than cromulent evening reading! We’re glad you exist.)

Well, this month it’s the ASF’s turn, but I hope instead of skipping past it, you’ll take a moment to flip through it. An annual report is more than just financial statements. It’s like our yearbook. It’s a chance to look around this big foundation that you’re a part of and see the rest of the space. The other 300+ projects. The newcomers to the group. The companies helping make it possible and how we’ve used their donations.

It’s been a big year for the ASF, from the launch of our new logo (that already feels like an old friend just eight months later) to reaching our 10,000th committer. We helped 11 projects graduate from the incubator and seven to move into retirement. We were able to help 19 recipients with travel assistance grants and mentored 25 candidates in Google Summer of Code. Beyond our projects themselves, we continued building the Apache Trusted Releases platform and worked with the global ecosystem towards the upcoming CRA compliance deadlines. And that’s just the beginning.

Our annual report tells the past year’s story—your story—of a group of thousands of volunteers creating software for the public good, which in many cases has become the software that runs the world. I hope you find it worth a few minutes of your time.

Connect

Follow us on social: X, LinkedIn, Bluesky and YouTube
About ASF Projects
Become an ASF Sponsor
Find Community Resources

THANK YOU SPONSORS

What the GSoC Mentor Summit Reminded Me About Open Source

The ASF — Thu, 20 Aug 2026 17:00:00 +0000

By: Priya Sharma

As a Google Summer of Code (GSoC) organization admin representing the Apache Software Foundation, I had the privilege of attending the GSoC Mentor Summit 2025, and it was an incredible experience!

The Mentor Summit is a unique opportunity to connect with amazing mentors and discuss open source topics in an unconference format — there is no fixed agenda. Instead, attendees collaborate on-site to create the session schedule themselves, brainstorming fresh concepts while strengthening the global open source ecosystem and forging long-term ties across projects. From meeting participants who have been involved for over 15 years to newcomers who recently transitioned from being mentees to mentors, the sense of community was inspiring. Meeting Staphanie, GSoC admin and program manager and Google, and the team was cherry on top.

The passion for open source and the innovative approaches to ensure continuity truly stood out for me. I joined discussions on topics such as AI in GSoC, challenges in remote setups, monetizing open-source contributions, and some amazing lightning talks.

Additionally, I connected with mentors from other organizations and exchanged ideas about their processes while sharing some of ours. Google's team organized the event so well that we didn't really feel like attending a professional gathering but more of a friend's get-together. From the gala dinners hosted and chocolate room hosted by long-time GSoC mentor Robert Kaye — who we lost this year — to karaoke night, it was so much fun.

What stood out most is that it’s not just about writing code; it’s about how deeply we embrace humanity and compassion as a community — which is very similar to the ASF’s “community over code” ethos. Creating an environment where everyone feels included and valued is something I’ll carry forward.

My key takeaway was the opportunity to deepen how GSoC contributors connect with the ASF as an organization. Today, most interaction happens between contributors and their project mentors, which works well, but there is an opportunity to introduce contributors more broadly to how the ASF functions and the wider community they are joining. Building that bridge earlier could help contributors find a lasting home in the Apache ecosystem long after GSoC ends.

On a personal note, this was my first-ever international event, which made the experience even more special and memorable. I am truly grateful to the ASF for providing us with all these experiences. Overall, it was a rewarding experience that reinforced the spirit of open source. Thank you for giving me this opportunity!

How Open Source Governs Itself: The Story Behind Apache STeVe v3

The ASF — Thu, 13 Aug 2026 04:00:00 +0000

By Greg Stein, Apache Software Foundation Member and STeVe Contributor

Every year, roughly 800 members of the Apache® Software Foundation cast votes to elect a Board of Directors, admit new members, and decide the direction of one of the oldest and most important institutions in open source. No corporate sponsor or steering committee with a financial stake in the outcome influences this very membership-driven process. The people who do the work choose the leadership, and the integrity of that process is entirely load-bearing.

That's not a small thing. In a technology landscape where "open source" has become a broad tent covering everything from genuine community projects to vendor-controlled repositories with a permissive license, The ASF is something more rare: a neutral foundation that truly governs itself, without vendor influence. And for that to mean anything, the voting system it uses has to be trustworthy.

Recently, we ran our annual Members' Meeting election on Apache® STeVe v3, a complete rebuild of the system we've relied on for years. I want to tell you what went into it, why it matters beyond The ASF, and how you can get involved.

Built by the community, for the community

Apache STeVe is not an internal IT tool. It's a standard Apache project — community-led, openly developed, governed the same way every Apache project is governed. That distinction matters. It means the code is public, the decisions are made on mailing lists, and anyone who wants to contribute has a path to do so. The people who vote on it can, in principle, help build it.

For v3, we rebuilt the entire stack on modern foundations. The application runs on asfquart — The ASF Infrastructure team's extension of Python's Quart async web framework, now available on PyPI — with Bootstrap handling the UI and SortableJS powering the STV (Single Transferable Vote) Board election interface. The templates are built on EZT, a lightweight templating system I wrote about 25 years ago that also lives on PyPI. It's clean, fast, and designed to feel like the kind of software people actually want to use.

The part that keeps votes private, even from us

Here's the piece I find most interesting, and I think you will too.

Every vote in STeVe is encrypted before it's written to the database. Each election uses a series of keys: one salt tied to the election itself, another generated per-voter, per-issue. Those salts and associated data are generated by Argon2, a memory-hard key derivation algorithm designed to resist brute-force attacks, while Fernet generates the symmetric encryption key. The vote record itself contains no names, no choices, no linkage between a person and their ballot.

To tally the results, the system has to work backward: generate all possible decryption keys (up to 40,000 for a full election with 800 voters and 50 issues), attempt each one, and collect the votes that actually exist. On typical hardware, that process takes 15 to 60 minutes.

That's deliberate. The same properties that make Argon2 resistant to attackers with large machines — it can consume significant memory, parallelism, and time — make our own tally process slow. We're not fighting that tradeoff; we're leaning into it. As hardware gets faster, we can tune the parameters to keep the difficulty constant. The privacy guarantee doesn't degrade over time.

Once tallied, results are reported in both human-readable and JSON formats. There's also a separate output for the "whatif" tool, a way to model alternate outcomes like "what if there were only eight board seats?" or "what if a specific candidate weren't running?”, so the community can examine the results from every angle.

The result is a system where no one — not the Infrastructure team running the tally, not the ASF board, not me — can look up how a specific member voted on a specific issue. The math enforces privacy, not a policy.

Why this matters beyond The ASF

Trustworthy digital voting for organizations is a genuinely hard problem, and not just for foundations. Any organization that relies on member votes (e.g. professional societies, standards bodies, open source consortia, unions, cooperatives) faces the same tension: how do you verify that the process was fair without compromising the privacy of individual voters?

Most organizations solve this with a combination of vendor trust and procedural controls. We solve it with cryptography and open source code. STeVe v3 is designed to be self-hosted, which means your data never leaves your environment — your election data never passes through any third-party platform, and votes remain unreadable at rest without running the full tally process. A compromised server requires very excessive work to see how anyone voted, far too much for any practical benefit. The full implementation is on GitHub. Anyone can read it, audit it, run it, or fork it.

What's next — and where you come in

We tested STeVe v3 with a full simulated election before the real one. Members voted on fictional candidates with randomly generated nomination statements, the results were tallied, edge cases were found and fixed. That's the Apache Way: ship early, iterate openly, trust the community to find what you missed.

The real election ran smoothly.

If you're a developer who finds any of this interesting — the async Python framework, the cryptographic design, the STV tallying algorithm — Apache STeVe is an active project looking for contributors. You don't have to be an ASF member to get involved. You just have to show up.

The issues are on GitHub at https://github.com/apache/steve/issues. The mailing list is open. Come join us.