I started taking part in open source seriously in the second half of this year. It hasn’t been long, but I knew which areas I cared about, so I read a lot of issues and sent a fair number of PRs. Then in October I got an email inviting me to vote in the OpenTelemetry Governance Committee election. That was when I learned that an open source project, which is neither a company nor a country, holds elections, and that I had a vote even though I had only just started, because I had kept showing up.
The invitation I got on October 22. It calls on people who made more than 20 contributions on GitHub in the past year, counting comments, code reviews and PRs.
Once I looked, open source turned out to have far more votes than I expected, and in that one month I encountered three kinds: a vote on a new committer, a vote on whether to ship a release, and an election for the people who run the project. I only saw the committer vote through its result announcement. I cast a ballot in the other two, and the Governance Committee election was the first time I had voted in one.
#The vote that makes a committer
In Apache Software Foundation projects such as Flink, a committer is someone with the right to merge code directly, and who becomes one is also decided by vote. That vote happens out of sight, though. Under the Flink bylaws, the Project Management Committee (PMC) votes on a private mailing list for at least three days. It passes with three or more yes votes from active PMC members and no justified objection from any of them. One such objection is enough to act as a veto.
From the outside, all you see is the result. On October 21 an [ANNOUNCE] email about a new committer arrived on the Flink dev mailing list, and people replied with congratulations one after another. I looked at how the earlier replies were written and sent a short one with my name.
The new committer announcement on October 21 and the congratulations I sent early the next morning.
#The vote that ships a release
The vote on whether to ship a release happens in the open. The release manager uploads a release candidate, the build to be checked before the official release, and sends an email whose subject starts with [VOTE] to the dev mailing list. People download the candidate, check it themselves and reply with +1 or -1. The Flink bylaws keep the vote open for at least three days, and only the votes of active PMC members count toward the result. These are called binding votes. A release passes with at least three binding yes votes and more binding yes than binding no, and others can also vote and report what they verified.
On October 21, while checking things ahead of the Flink Agents 0.4 release, I found and fixed a bug where Java chat calls failed in the build made with JDK 17. On the 27th I checked the signatures and checksums of the first release candidate, compared the source against the tag and built it myself, and I also checked whether the classes my fix needed were in the release files. Then on the 28th I found that the vote email itself had landed in my spam folder.
In my reply I gave a +1 marked as non-binding, meaning it doesn’t count toward the result, listed what I had checked, and said I had not run an end-to-end functional test. I had also found a case where the state of in-flight work was not restored when upgrading from the previous version, but since the problem was not new in this release, I did not raise it as a blocker. I suggested adding a line to the upgrade notes and said I would try to fix it in the next version.
The vote passed with no objections. The result email listed seven yes votes, four of them binding, and my name was on the non-binding side.
The result email for the first Flink Agents 0.4.0 release candidate, received on October 29.
#The vote that picks the Governance Committee
OpenTelemetry’s Governance Committee reviews proposals for new projects, sets priorities and maintains the public roadmap, and the vote for its members was the most election-like of the three. I hadn’t applied for voting rights, either. Anyone with 20 or more contributions to the OpenTelemetry GitHub organization in the past year, counting PRs, issues and comments, gets one. Approvers, who review and approve contributions in their area, and maintainers, who set the technical direction of subprojects, also get a vote. The list is generated automatically, and contributors who fall short can ask for an exception.
The public voter list as of October 21 had 837 accounts, and my username was on it. The count next to it said 29 contributions.
All ten candidates nominated themselves. Self-nomination alone was not enough: each needed endorsement comments from voters at two other companies, and a cap keeps people from one company from filling the committee. During the election, one candidate even messaged me directly to ask what I thought.
Voting ran on an online system called Helios from 9 p.m. on October 26 to 8:59 p.m. on October 29, Korea time.
We could pick up to four candidates for four seats, and by a few hours before the deadline I had read all ten platforms. I had expected governance to mean rules and votes, but the platforms ranged much wider, from install packages and the demo app to moderation policy, events and relations with neighboring projects.
AI stood out first. By my count, six of the ten candidates mentioned AI or agents in their bios or platforms, and by my reading five promised to protect maintainers’ time. Several platforms promised to help end users adopt OpenTelemetry, and a candidate who works at the American Red Cross wrote that OpenTelemetry is a core part of the blood services that supply roughly 40% of the US blood supply.
What stayed with me longest was what the candidates said about code review. One candidate wrote that monthly PRs in the group they lead nearly quadrupled this summer and review could not keep up, and another, who put maintainer burnout on the first line, proposed cutting repetitive work with shared tools and automated checks.
#After the vote
The official results for the OpenTelemetry Governance Committee election went up on October 29 in the US, and I saw them on the morning of the 30th, Korea time. 41% of eligible voters cast a ballot, and the top four vote-getters won new terms. That doesn’t mean seats simply go in order of votes. The charter allows at most two committee members from the same company at any time, and the cap counts members whose terms are still running. A candidate over the cap is skipped even with more votes, and the next candidate in line takes the seat. This time the top four came from four different companies, and none of those companies matched the companies of members whose terms run through 2027, so the seats went straight by vote count.
Whoever won, the review problem in those platforms is something many open source projects share right now. A post on the Kubernetes blog in June made the same point: AI has made generating code fast, but there has been very little improvement in maintaining code bases. In OpenTelemetry, one candidate wrote that review can’t keep pace with the growth in PRs, and the project’s generative AI policy calls maintainer and approver time a very scarce resource. The policy doesn’t ban AI. It says AI can be a useful tool for writing code, docs and tests when used well, and asks contributors to share their own thinking, even in imperfect English, rather than just passing along what a model generated.
I use AI to contribute too. It makes writing issues in English and reading large, unfamiliar codebases much easier. When I open a PR, I write in the description what I actually ran and what I couldn’t verify, and splitting my release vote reply into what I checked and what I didn’t came from the same habit. Reading the platforms made me think this habit matters even more in open source. At a company you share context with your reviewers and can ask the person next to you, but an open source reviewer gives their own time to read a PR from someone they’ve never met. So the code and the PR description have to explain the intent of the change on their own, and they have to be written for the reviewer from the start.
#References
- Flink Bylaws: Defines who votes, for how long and what it takes to pass, for release votes and committer votes.
- 2026 OpenTelemetry Governance Committee candidates: Collects the bios and platforms the ten candidates wrote themselves.
- OpenTelemetry governance charter: Defines the committee’s role, voter eligibility, endorsement requirements for candidates and the per-company cap.
- Open source maintainership in the age of AI: Describes how the Kubernetes community has changed its policies and review practices as AI-driven contributions grew.
- OpenTelemetry generative AI contribution policy: Sets out maintainer discretion and contributor responsibility for contributions made with AI.