How Should I Run My Community Elections?

Sooner or later in the growth of a community project, the question arises of how to choose representatives for the community. For some projects, this is when they lose a founder, and as a group decide to move to a “ruling technical council” model; for other projects, the need comes from the move to a non-profit governing body with paying members, and the desire to have a technical steering committee chosen from members; other projects evolve over time to a representative leadership model.

I have been involved in boot-strapping, reforming, or running elections in a number of different communities over the years (GNOME, Maemo, OpenStack, OPNFV, OpenDaylight,, and others). Which voting system to use, how to define the electorate, and limiting the pool of eligible candidates have tended to create the deepest rat-hole conversations in all projects I have been involved in when the topic of elections has come up.

The Python project, in the context of debating a governance change, recently put together a comprehensive survey of project governance and voting procedures, and voted to move to an elected Steering Committee model. This article attempts to synthesize some of the best practices I have seen used in various projects and elections, covering who gets to vote, who can be a candidate, and how elections are run.

Electorate and Eligible Candidate Pool

One project I recall had a situation where anyone who was registered for the site (a very low bar) could vote, but only project committers (a high bar) could be candidates in the election. However, almost all projects eventually converge on broadening the pool of potential candidates to equal the pool of voters. Anyone who can vote in the election is therefore eligible to become a candidate.

I have seen three main approaches for defining the electorate and candidate pools:

  • High bar: Committers, maintainers, core contributors: voters are members of an “in” group, which involves long participation, and seniority recognised by peers
  • Medium bar: “Active” participants, or foundation members can vote, as long as they pass some defined, and relatively low, bar of participation
  • Low bar: Anyone can vote as long as they do some very basic thing like “signing up to the program” or “become a member of the members mailing list”

The kernel community TAB elections are an interesting exception: The electorate used to be “people who are in the room during the Kernel Summit party at which we hold the election“. This has since changed to “people who are in the conference room where the election is held during the Kernel Summit”. For a couple of these, when the Linux Kernel Summit coincided with co-located Linux Foundation events, people with no kernel connections whatsoever have been able to vote just by going to the room at the right time. Personally I think this disenfranchises kernel developers who can’t make it to the Summit, but if it works for the kernel community, I guess it works.

Defining the activity metric and minimum bar for what qualifies as participation can become contentious, mainly because where you draw the line will be arbitrary, and will omit people who you want to include, or include people who you want to omit. For example, if you set the bar at the minimum contribution level of one commit to the project, you omit all whose contributions are significant but not code related. The typical fear is ballot stuffing or cohort effects — where large companies will dominate the representative bodies by having a large voting bloc, or where friends of candidates (or people with a certain agenda) will pass the low bar to become voters just to vote for their candidate.

One community I am familiar with required one patch submission in last 12 months be a voter. Other projects require 20 or 25 “contributions,” including patches, patch reviews, wiki page edits, and a variety of other types of measurable contribution. Another project had a hybrid “karma” metric made up of weighted amounts of different contributions (one code contribution was worth five wiki edits and twenty emails or forum posts). Other projects require people to request becoming members to vote (or allow those not covered in the automated bar to apply for a waiver).

Generally, some ongoing participation, which can be quantified in some way, is needed to be part of the electorate.  This group includes many more people, some of whom are passive participants in the community, or who “join” just to vote in the election. In my experience, fears of ballot stuffing and cohort effects are unfounded, but the risk exists. Technical communities tend to try to create rules to defend against possible abuses of the system, but this can be considered as premature optimization, which Donald Knuth has famously described as the root of all evil. It is better to avoid special rules to begin with, and address issues with the electoral process as they arise.

One final consideration is the process for becoming a candidate in the election. A few options exist, all of which seem to work. The most popular is self-nomination. Candidates post to a certain place with their reasons for running and any other information relevant to the election. Another option is nomination — which often amounts to the same thing, as the candidate typically will have to ask people to nominate and second their nomination. Either works, just pick one.

Voting System

Anther guaranteed rat-hole conversation is the voting system. Here Be Dragons! In any community, there will always be two or more people who are passionate about how to vote, and how to count votes. These conversations can go on for months, and end up with proposals that are almost impossible to implement, if you are not careful.

One organization I recall wanted to increase the mix of representatives to include core and non-core projects. The small group who volunteered to define the election process defined project groups, and categorized candidates and electorates for each project type, then used a fancy proportional representation formula to choose the Technical Steering Committee with a quota of members from both groups, while simultaneously satisfying vendor diversity rules. Over-engineered and confusing.

Most community projects I am familiar with have tended towards the following:

  • Voting by secret ballot
  • Online voting, with a personal token to ensure one person, one vote
  • Some form of preferential voting (list candidates in order of preference)
  • Either Condorcet or Single Transferable Vote to count the votes and identify winners

Some projects continue to use alternative voting systems like “first past the post” or weighted voting systems, where you get 12 tokens to “spend” on whichever candidates you want, and the candidates with the most tokens at the end win.

Several projects use online counting software – several options to consider:

  • Condorcet Internet Voting System is a free, online voting and Condorcet counting system
  • OpaVote (formerly OpenSTV) is a commercial election counting software as a service
  • OpenSTV used to be available under the GPL, and the last open source version has been conserved for posterity, and is used by several projects to count their elections
  • Helios is another free election service, used by several projects, which allows online voting, and enables vote counting with several counting methods

How Should I Start?

My suggestion, if you are going to propose or boot-strap an election system, is to start with a mission statement. For example: “the goal is to ensure the technical steering committee represents everyone contributing actively to the project, valuing non-code contributions equally to code contributions, in the definition of the technical scope and direction of the project”. This mission statement will identify a few things: who is being represented by the elected body, and what their authority will be (or why they are being elected in the first place).

Once you agree on the goal of the elected body, choose the absolute simplest ways to define membership in the body being represented, and the absolute simplest voting and counting system possible. For example, following on from the mission statement above, you might decide that a TSC size of 9 is appropriate to represent everyone, and include anyone with at least one code commit, documentation commit, wiki edit, or event participation (presentation or booth) in the membership list, and run a simple voting system where the top 9 candidates are elected. People fear that the system will be gamed with ballot stuffing, and voting blocs, but this happens way less often than people fear.

Especially in community projects, the vast majority of project participants have the best interests of the community (as they perceive them) at heart. Until you are proven wrong, trust your community to choose representatives who reflect the diversity of views they are representing.

(Image courtesy of Dude7248, licensed in the public domain.)

8 Comments / Read more

About Dave Neary

Dave Neary is part the Open Source Program Office at Red Hat, driving adoption and community growth for projects including oVirt, RDO, a distribution of OpenStack for Red Hat-based operating systems, Gluster, and Fedora. Dave is currently concentrating on projects related to developer tooling, in particular the awesome Eclipse Che. He previously worked for several years on Network Function Virtualization and Software Defined Networking. Dave has been active in free and open source communities for more than 15 years as a consultant, community manager, trainer and developer. Find him on Twitter @nearyd

8 thoughts on “How Should I Run My Community Elections?

  1. > It is better to avoid special rules to begin with, and address issues with the electoral process as they arise.

    The problem with this is that if a group of people gains “legislative power” due to cohorting or or ballot stuffing they can block any changes to the rules from being put in place—or even worse, they can change the rules to cement their position. Of course, the community can choose to just up and leave, but this can be difficult if you have bad actors sitting on the keys to all existing infrastructure, and project forking is never nice.

    Even if it may be premature optimisation, it’s better to do premature optimisation than to end up in a situation you can’t get out of because you didn’t build in a fail-safe.

    • I understand there may be a problem. As I said, in my experience, such fears are unmerited. I have never yet seen a hostile take-over of a governing body of a project, in 20 years working with open source. I have seen founders who did not act in the interests of a broader community, and those projects either drift into irrelevance, or fork. But I have yet to see a single instance of ballot stuffing end in a dramatic change in direction of the project in question. Pareto’s Rule applies, and the people who do the work continue to have significant authority, with or without elections and a governing body.

    • Hostile actors will game your rules, and the more rules you have, the bigger an attack surface they have. I’m paraphrasing Bruce Schneier here, and everything I’ve ever seen upholds his point. Simple systems are actually *harder* to game.

      So if you have complex, protect-ourselves-from-hostiles rules out of the gate, you’ll make a lot of extra work for everyone without making governance more stable.

      Unlike Dave, I have seen hostile takeover attempts of OSS project governance. None of those cases were thwarted by special provisions of governance rules. Everyone that was defeated was defeated by mobilizing the contributor base.

  2. Okay, so the picky election-science note: STV is positive enough in terms of being reasonably proportional, but it’s far from perfect. It has quirks that can mean that some voters’ preferences get counted while others’ preferences are ignored.

    So, say, 100% of the voters put candidate X as their 2nd choice. That candidate gets eliminated because of lack of 1st-choice votes. That’s already unfortunate, but that’s not the only problem. The premise is “you move to your next choice if your 1st choice is eliminated” and that doesn’t hold up. In many or even *most* STV elections, there are candidates eliminated in a particular order such that *some* voters don’t get to move to their 2nd or 3rd choice because they are already eliminated before their 1st choice.

    If 1st round eliminates my 2nd choice, 2nd round eliminates my 3rd choice, and *then* my 1st choice is eliminated, all my top 3 preferences are totally ignored. Meanwhile, some other voters get all their preferences counted!

    This sort of problem doesn’t happen with simple approval voting (which OSI uses and is supported by Helios). For single-seat elections, the best is probably STAR voting (see ) or 3-2-1 voting (, and there exist better proportional approaches than STV…

    At the very least, anyone using or proposing STV should be understanding and honest about its flaws.

    • Thanks Aaron. I understand the issues with STV. In the physical world, one of the biggest issues is how surpluses get distributed when someone is over a quota in multi-seat constituencies – in Ireland, in one election, the result was challenged because surplus transfer votes were distributed from the top of the pile, rather than a random sample from all the votes for the elected candidate. To see why this is an issue, consider a situation where one party has 2 candidates, candidate A is very popular, gets 32% of the vote, candidate B a little less popular, gets 30%, and another party has 2 candidates, candidate C, who gets 20%, and candidate D, who lives close to candidate A, and gets 18% of the vote.

      Candidate D votes split 60/40 between candidate C, from the same party, and candidate A, the neighbour, resulting in candidate A having 38% of the vote after distribution, candidate B with 32%, and candidate C with 30% (candidates need one third plus one to be elected). Now, taken as a whole, candidate A’s votes split 80/20 to candidate B, from his own party, but taken alone, the votes that transferred from candidate D to A split 80/20 to candidate C. 4 2/3% of candidate A’s votes are distributed as a surplus, and if those votes are a random sample, candidate B wins the 2nd seat, but if they are taken off the top, from the votes just distributed, they will favour candidate C.

      Incidentally, STV isn’t the only system that has strange outcomes like this, Condorcet has its share of mediocre candidates, who inflame the passions of none. STV has the merit of being easy to understand, and easy to count, which can not be said for many other preferential counting methods. There are trade-offs, and (as I said) it’s a great way to have very detailed conversations about what is fair, whether it is better to have candidates who are loved or not disliked, and more. It is, as I also said, a trap – the differences between the methods, for practical purposes, are small, and people who care about counting systems care passionately.

      • As it stands, STAR voting and 3-2-1 which I mentioned are the best for single-seat, and the folks around STAR are currently discussing what’s the closest as-good form of some proportional representation…

        I don’t know what PR forms are really the best or most practical, only that STV not only has problems but it’s often presented deceptively as though it didn’t. So, I try to start with the idea that everyone should just at least avoid the common *misunderstandings* about it, even if the conclusion is to use it anyway.

        It does seem that the best PR systems involve delegation of some sort (where when a candidate you like doesn’t get elected *they* have some say in who their votes go to, and that involves candidates setting their own preferences about what *other* candidates they support). But I’m not sure about those details, and there aren’t practical tools for using other systems currently.

        • Of course at some point, everything will be decided either by meritocratically nominated experts, or by liquid democracy backed by a Blockchain 😉

Leave a Reply

Your email address will not be published. Required fields are marked *