Every year, roughly 800 members of the Apache Software Foundation (ASF) elect a Board of Directors, admit new members, and set the foundation's direction — without any corporate sponsor or steering committee influencing the outcome. The integrity of that process depends entirely on the voting system. This year, that system was Apache STeVe v3, a complete rebuild of the foundation's election platform.
What STeVe v3 is
Apache STeVe is not an internal IT tool. It is a standard Apache project — community-led, openly developed, and governed the same way every Apache project is governed. The code is public, decisions are made on mailing lists, and anyone who wants to contribute has a path to do so. For v3, the entire stack was rebuilt on modern foundations.
The application runs on asfquart, an extension of Python's Quart async web framework developed by the ASF Infrastructure team and now available on PyPI. The UI uses Bootstrap, and the Single Transferable Vote (STV) Board election interface is powered by SortableJS. Templates are built on EZT, a lightweight templating system that also lives on PyPI.
How vote privacy works
Every vote in STeVe is encrypted before it is written to the database. Each election uses a series of keys: one salt tied to the election itself, another generated per-voter and per-issue. Those salts and associated data are generated by Argon2, a memory-hard key derivation algorithm designed to resist brute-force attacks. Fernet generates the symmetric encryption key.
The vote record itself contains no names, no choices, and no linkage between a person and their ballot. To tally the results, the system must 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 slowness is deliberate. The same properties that make Argon2 resistant to attackers with large machines — it can consume significant memory, parallelism, and time — make the tally process slow. As hardware gets faster, the parameters can be tuned to keep the difficulty constant. The privacy guarantee does not degrade over time.
Once tallied, results are reported in both human-readable and JSON formats. There is also a separate output for the "whatif" tool, which models alternate outcomes — for example, what if there were only eight board seats, or what if a specific candidate were not running.
The result is a system where no one — not the Infrastructure team running the tally, not the ASF board, not the contributor who wrote the code — can look up how a specific member voted on a specific issue. The math enforces privacy, not a policy.
Why it matters beyond the ASF
Trustworthy digital voting for organizations is a genuinely hard problem. Any organization that relies on member votes — 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. STeVe v3 solves it with cryptography and open source code. It is designed to be self-hosted, meaning election data never leaves your environment and never passes through any third-party platform. Votes remain unreadable at rest without running the full tally process. A compromised server would require excessive work to see how anyone voted.
The full implementation is on GitHub. Anyone can read it, audit it, run it, or fork it.
What's next
STeVe v3 was tested with a full simulated election before the real one. Members voted on fictional candidates with randomly generated nomination statements, results were tallied, and edge cases were found and fixed. The real election ran smoothly.
If you are a developer interested in the async Python framework, the cryptographic design, or the STV tallying algorithm, Apache STeVe is an active project looking for contributors. You do not have to be an ASF member to get involved. The issues are on GitHub at https://github.com/apache/steve/issues. The mailing list is open.