Against IRC democracy

I am an IRC user and channel operater on Freenode, and I’ve seen a lot of calls for different op policies in my life. In fact, I don’t think there’s been a single channel I’ve been to that didn’t, sooner or later, get some sort of conflict regarding operator policies.

An attractive notion is that we should transport principles of democratic decision-making and administration to IRC, and avoid the current situation of oligarchy or tetrarchy (Freenode allows 4 founders per channel), installing self-government in our channels and reducing the need for a specialised cadre of superusers with centralised power. This idea fits well the aphorism that “there is always a well-known solution to every human problem—neat, plausible, and wrong”.

My objections to democratising IRC are not grounded on an opposition to democracy. I am a committed democrat, and consider that the world has overall too little, not too much of it. Elections and representation, for example, seem to me to produce considerable democratic deficits. I’m also not opposed to these solutions because of my personal interest in perpetuating the power of channel operators, though it is difficult to demonstrate this claim to everyone’s satisfaction. My opposition is based on technical, social and organisational peculiarities of IRC which I shall proceed to discuss.

Identity.

The first problem in attempting to set up democratic governance is determining who has voting rights. This is relatively easy when it comes to countries (through a census) though it has its own issues in setting the age of majority and so on, but on IRC it becomes almost impossible. Identity creation on IRC is as simple as connecting a client. Even registration is very easy, and effectively free. Through the use of virtual masks, it is effectively very difficult to tell which users are controlled by the same real person.

Without being able to determine the actual users (as opposed to the clients) in a channel, it becomes very hard to tell who should have the right to vote in it, in order to avoid ballot stuffing.

Even then, determining the conditions of elligibility for voting is difficult. Should it be an automatic right on joining? In that case flooders will win the day. Should it depend on mechanical criteria? In that case it is likely to be possible to get voting rights through bots.

The only approaches that seem workable rely on preseeding the database of voters with known good users (or at least well known regulars) and depending on voting itself to extend voting rights. The extension of such rights will depend on the willingness of existing voters to dilute their power in favour of people whom they may not agree with, which is always a little difficult to obtain. The starting voting base will therefore, in all likelihood, make political judgement on whom voting rights should be extended to, and this will condition the likely boundaries of future decisions.

Speed.

IRC is a very dynamic medium. Floods can take place in matter of seconds, and decisions are required to be made quickly. Some of this can be automated (for example there can be flood automatic triggers), but it is always possible to evade them by the use of multiple bots, unless the automation is so sensitive that they will eventually trigger on innocent cases.

While automating some of this problem away is good, certain judgement will have to be made by humans. At this point we find ourselves with the problem of articulating a democratic decision fast enough that the damage isn’t done. Not so much because a flood causes irreparable harm (though it can) but because when a particular action has been taken, the flood can continue with different accounts, and another decision is then required which also needs time to be voted on and implemented.

An option is to use human operators as an emergency mechanism, subject to democratic oversight. However, inevitably there will be differences between the judgements made by the operators and the voting base, and then if the operators have the power to overrule, the democratic implementation is useless; and if not, finding operators who won’t mind will be complicated.

Operating is usually an unpleasant task. It requires willingness to confront people, and often results in a lot of friction against operators, both from those whom they act on directly, but also from other bystanders who for whatever reason disagree with their decisions. If they have to make these decisions in an environment in which they can easily be overruled, the tendency will be to only act in the most obvious cases. This, however, is not a politically neutral position. It sets up the conditions for laxer moderation in the channel (which is a legitimate desire, but which should be argued for on its own merits, not under the cloak of democracy), and makes it more difficult to act in contentious cases.

Engagement.

IRC channels have users coming in and out all the time. They are open 24 hours, and they can be very busy at one moment and very quiet on the next. In order for democratic decisions to be carried out effectively it is necessary to have an engaged electorate. However, the vast majority of IRC users are not particularly interested in making decisions about day-to-day channel handling. Even when it comes to very large changes in channel policy, it is generally difficult to get a lot of engagement. Overviewing specific decisions on users often requires being acquainted with some of the history. This may require checking logs, talking to other users, and so on. Such tasks are time consuming, and most users are unwilling to carry them out.

Empirically, in those cases where I’ve seen attempts to install democracy on IRC, decisions were often voted on by very few users (as few as 3). Sometimes it is simply a timezone issue (people are asleep), and sometimes people are uninterested in the outcome of some specific vote.

Quorum rules would be desirable in order to make sure that the decisions made are made by something close to the actual base of voters, so that the voting represents the decision by the community. However, in order to be able to make decisions timely, quora must be relaxed to the point of absurdity. Even tiny quora like 5 people on channels with 200 users will be too high for decisions to be made on anything like a regular basis.

Affordances.

Make a lever, and people will pull it; make a button, and people will push it. I strongly suspect if there were a button that said PUSH THIS TO END THE WORLD at some secluded location, it wouldn’t take long until someone decided to try it. The democracy proposals for IRC necessarily depend on mechanisation. Bots are used to tally votes and implement measures. This creates affordances for political conflict to be played out through bot use. Suddenly, IRC becomes a social game of build a faction and ban the enemy. This may be fun (I like a game of Mafia or Diplomacy as much as the next nerd) but it doesn’t make for particularly pleasant communities. Community policing becomes more stringent, and clear lines of demarcation between different groups arise, competing for hegemony. As banned users are expelled from future decisions, the affordances reward factional behaviour: ban the enemy, their friends in case they vote with them, those neutrals who may not be committed to vote your way, etc.

As an operator, it was infinitely easier to get people banned and quieted while there was a bot on ##politics than before or after it. In spite of certain conspiranoic notions by the bot writer, this wasn’t because there was any kind of attack or threats made against users, but simply because of the logic of the situation. Without the bot, I felt obliged to at least be able to justify, if nothing else to myself, the decisions I made as an operator. With it, I simply had to put together a sufficient majority at any particular time. Considering the previous sections, and the fact very small numbers of users could, during times of low activity, get measures passed, it became straightforward to carry out purges.

In the end, this results in an environment that is extremely favourable to active persuasive users. Since the decisions often require very few votes, it is possible to shift the channel considerably by strategically deploying them at the right time and changing the voting base.

Conclusion.

Democracy is great. Every cook can govern. However, democracy is useful for structures which have as their main point of existence the administration of scarce resources and the realisation of coercive measures to protect communities. On IRC resources are not particularly scarce: namespace issues aside, a new channel is a /join away. The object of IRC is communication itself, and all administrative talk detracts from the actual point. Without wanting to fetishise freedom of association, IRC communities should be much more concerned about assuring a good environment for conversation than any particular abstract freedom of expression for community members. People who have irreconcileable differences aren’t going to make for good interlocutors anyway and should use channels where their positions are acceptable, rather than try to fit where they do not belong.

Democracy is unsuitable as a means for community management on IRC. The fundamental problems are not of a technical nature, but derive from the social context and object of IRC. Democracy is not fast enough, requires unavailable amounts of engagement, and factionalises communities, taking up the space they would use for discussing whatever their core interest is in order to handle administrative questions. Once the system is available, groups are incentivised to play it to their advantage, and the seeds for community strife are sowed. When there is inevitable resource contention, politics, in the sense of struggle about administration, becomes inevitable; but IRC is more suitable for secession, like a group of friends or a bunch of people talking at a table. There is nothing gained, and much lost, in attempting to democratise it.

links

social