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.
