![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dizietThere is a thread of opinion in some Free Software communities, that we shouldn’t be doing “politics”, and instead should just focus on technology.
But that’s impossible. This approach is naive, harmful, and, ultimately, self-defeating, even on its own narrow terms.
- Today I’m talking about small-p politics
- Many people working together always entails politics
- Consensus is great but always requiring it is harmful
- Governance is like backups: we need to practice it
- Governance should usually be routine and boring
- Governance means deciding, not just mediating
- On the autonomy of the programmer
- Mitigate the consequences of decisions — retain flexibility
- But don’t do decisionmaking like a corporation
Today I’m talking about small-p politics
In this article I’m using “politics” in the very wide sense: us humans managing our disagreements with each other.
I’m not going to talk about culture wars, woke, racism, trans rights, and so on. I am not going to talk about how Free Software has always had explicitly political goals; or how it’s impossible to be neutral because choosing not to take a stand is itself to take a stand.
Those issues are all are important and Free Software definitely must engage with them. Many of the points I make are applicable there too. But those are not my focus today.
Today I’m talking in more general terms about politics, power, and governance.
Many people working together always entails politics
Computers are incredibly complicated nowadays. Making software is a joint enterprise. Even if an individual program has only a single maintainer, it fits into an ecosystem of other software, maintained by countless other developers. Larger projects can have thousands of maintainers and hundreds of thousands of contributors.
Humans don’t always agree about everything. This is natural. Indeed, it’s healthy: to write the best code, we need a wide range of knowledge and experience.
When we can’t come to agreement, we need a way to deal with that: a way that lets us still make progress, but also leaves us able to work together afterwards. A way that feels OK for everyone.
Providing a framework for disagreement is the job of a governance system. The rules say which people make which decisions, who must be consulted, how the decisions are made, and, how, if any, they can be reviewed.
This is all politics.
Consensus is great but always requiring it is harmful
Ideally a discussion will converge to a synthesis that satisfies everyone, or at least a consensus.
When consensus can’t be achieved, we can hope for compromise: something everyone can live with. Compromise is achieved through negotiation.
If every decision requires consensus, then the proponents of any wide-ranging improvement have an almost insurmountable hurdle: those who are favoured by the status quo and find it convenient can always object. So there will never be consensus for change. If there is any objection at all, no matter how ill-founded, the status quo will always win.
This is where governance comes in.
Governance is like backups: we need to practice it
Governance processes are the backstop for when discussions, and then negotiations, fail, and people still don’t see eye to eye.
In a healthy community, everyone needs to know how the governance works and what the rules are. The participants need to accept the system’s legitimacy. Everyone, including the losing side, must be prepared to accept and implement (or, at least not obstruct) whatever the decision is, and hopefully live with it and stay around.
That means we need to practice our governance processes. We can’t just leave them for the day we have a huge and controversial decision to make. If we do that, then when it comes to the crunch we’ll have toxic rows where no-one can agree the rules; where determined people bend the rules to fit their outcome; and where afterwards people feel like the whole thing was horrible and unfair.
So our decisionmaking bodies and roles need to be making decisions, as a matter of routine, and we need to get used to that.
First-line decisionmaking bodies should be making decisions frequently. Last-line appeal mechanisms (large-scale votes, for example) are naturally going to be exercised more rarely, but they must happen, be seen as legitimate, and their outcomes must be implemented in full.
Governance should usually be routine and boring
When governance is working well it’s quite boring.
People offer their input, and are heard. Angles are debated, and concerns are addressed. If agreement still isn’t reached, the committee, or elected leader, makes a decision.
Hopefully everyone thinks the leadership is legitimate, and that it properly considered and heard their arguments, and made the decision for good reasons.
Hopefully the losing side can still get their work done (and make their own computer work the way they want); so while they will be disappointed, they can live with the outcome.
Many human institutions manage this most of the time. It does take some knowledge about principles of governance, and ideally some experience.
Governance means deciding, not just mediating
By making decisions I mean exercising their authority to rule on an actual disagreement: one that wasn’t resolved by debate or negotiation. Governance processes by definition involve deciding, not just mediating. It’s not governance if we’re advising or cajoling: in that case, we’re back to demanding consensus. Governance is necessary precisely when consensus is not achieved.
If the governance systems are to mean anything, they must be able to (over)rule; that means (over)ruling must be normal and accepted.
Otherwise, when the we need to overrule, we’ll find that we can’t, because we lack the collective practice.
To be legitimate (and seen as legitimate) decisions must usually be made based on the merits, not on participants’ status, and not only on process questions.
On the autonomy of the programmer
Many programmers seem to find the very concept of governance, and binding decisionmaking, deeply uncomfortable.
Ultimately, it means sometimes overruling someone’s technical decision. As programmers and maintainers we naturally see how this erodes our autonomy.
But we have all seen projects where the maintainers are unpleasant, obstinate, or destructive. We have all found this frustrating. Software is all interconnected, and one programmer’s bad decisions can cause problems for many of the rest of us. We exasperate, “why won’t they just do the right thing”. This is futile. People have never “just”ed and they’re not going to start “just”ing now. So often the boot is on the other foot.
More broadly, as software developers, we have a responsibility to our users, and a duty to write code that does good rather than ill in the world. We ought to be accountable. (And not just to capitalist bosses!)
Governance mechanisms are the answer.
(No, forking anything but the smallest project is very rarely a practical answer.)
Mitigate the consequences of decisions — retain flexibility
In software, it is often possible to soften the bad social effects of a controversial decision, by retaining flexibility. With a bit of extra work, we can often provide hooks, non-default configuration options, or plugin arrangements.
If we can convert the question from “how will the software always behave” into merely “what should the default be”, we can often save ourselves a lot of drama.
So it is often worth keeping even suboptimal or untidy features or options, if people want to use them and are willing to maintain them.
There is a tradeoff here, of course. But Free Software projects often significantly under-value the social benefits of keeping everyone happy. Wrestling software — even crusty or buggy software — is a lot more fun than having unpleasant arguments.
But don’t do decisionmaking like a corporation
Many programmers’ experience of formal decisionmaking is from their boss at work. But corporations are often a very bad example.
They typically don’t have as much trouble actually making decisions, but the actual decisions are often terrible, and not just because corporations’ goals are often bad.
You get to be a decisionmaker in a corporation by spouting plausible nonsense, sounding confident, buttering up the even-more-vacuous people further up the chain, and sometimes by sabotaging your rivals. Corporate senior managers are hardly ever held accountable — typically the effects of their tenure are only properly felt well after they’ve left to mess up somewhere else.
We should select our leaders more wisely, and base decisions on substance.
If you won’t do politics, politics will do you
As a participant in a project, or a society, you can of course opt out of getting involved in politics.
You can opt out of learning how to do politics generally, and opt out of understanding your project’s governance structures. You can opt out of making judgements about disputed questions, and tell yourself “there’s merit on both sides”.
You can hate politicians indiscriminately, and criticise anyone you see doing politics.
If you do this, then you are abdicating your decisionmaking authority, to those who are the most effective manipulators, or the most committed to getting their way. You’re tacitly supporting the existing power bases. You’re ceding power to the best liars, to those with the least scruples, and to the people who are most motivated by dominance. This is precisely the opposite of what you wanted.
If enough people won’t do politics, and hate anyone who does, your discussion spaces will be reduced to a battleground of only the hardiest and the most toxic.
If you don’t see the politics, it’s still happening
If your governance systems don’t work, then there is no effective redress against bad or even malicious decisions. Your roleholders and subteams are unaccountable power centres.
Power radically distorts every human relationship, and it takes great strength of character for an unaccountable power centre not to eventually become an unaccountable toxic cabal.
So if you have a reasonable sized community, but don’t see your formal governance systems working — people debating things, votes, leadership making explicit decisions — that doesn’t mean everything is fine, and all the decisions are great, and there’s no politics happening.
It just means that most of your community have given up on the official process. It also probably means that some parts of your project have formed toxic and unaccountable cabals. Those who won’t put up with that will leave.
The same is true if the only governance actions that ever happen are massive drama. That means that only the most determined victim of a bad decision, will even consider using such a process.
Conclusions
Respect and support the people who are trying to fix things with politics.
Be informed, and, where appropriate, involved.
If you are in a position of authority, be willing to exercise that authority. Do more than just mediating to try to get consensus.
(no subject)
Date: 2025-05-02 07:23 am (UTC)A particular interesting case where this comes up is setting up a governance from scratch.
All code bases start out zero lines long, and someone has to start writing them. If the code base is not already being originated within the context of some kind of cooperating organisation with an existing governance, then it probably starts off as one person's project, and grows more developers later on as people notice it, like it, and join in.
So, at least to start with, it will have the default governance structure of a dictatorship. The project originator may give other people commit access, but can remove it again by virtue of being physically in charge of the git repo. So in case of any disagreement over what ought to be done with that access, the originator de facto has the final say: I can always revoke your commit rights and then revert your objectionable changes. Probably I would do that in a sufficiently deserving case (say, if one of my long-trusted committers turned out to have perpetrated something like the libxz backdoor). The only thing that stops me doing it capriciously, if one of my committers does something I only mildly disagree with, is my desire to keep some goodwill and not have all my co-developers leave in disgust.
(IME "benevolent dictators" in charge of software projects are more likely to be actually benevolent than the ones in charge of countries, although still not 100%. But then I would say that, wouldn't I :-)
Once a code base is in that governance situation, who persuades the dictator to let go of the reins and hand over ultimate control to the Foo Foundation or the Foo Steering Committee or whatever?
Ultimately, this involves persuading the dictator not to have full control over the project any more. Even if you have a transitional phase in which they're still the chairbeing of the committee and retain most of the decision-making power (maybe unless outvoted by a sufficiently huge margin), you're still telling them to sign up for a situation which can lead to them being voted out of their own project.
This surely isn't likely to seem attractive to them. In political terms, they won't want to give up power, or have their autonomy threatened. Inside their own head, they're going to see it in terms of "But what if the new governance makes some terrible decision? If I keep control I can make sure that doesn't happen." Assuming the software matters to the developer – and surely it must, in any case where there are also enough people around to try to form a governance structure – they're going to think of that as a very real risk that they care about.
I suppose the easy case is if the originating developer is tired of the project and wants to hand it on to a new maintainer anyway. Then it's as easy to hand it on to a governance structure as to hand it on to a new single individual. (Perhaps even easier, if the governance structure has enough transparency that it looks easy to tell if it's trustworthy?)
Perhaps this is the one case where forking is a reasonable solution? Even with a program small enough for one person to maintain, a big problem with forking is persuading people to switch to a new fork with no reputation or track record, despite the existing maintainer being generally known and trusted. But if the would-be Foo Foundation is better funded than one programmer maintaining Foo at weekends, then perhaps it would have the resources to make a fork and do lots of actually useful work on it, establishing the track record it needs for Forked Foo to become known as a better option than Classic Foo.
(no subject)
Date: 2025-05-02 07:54 am (UTC)I suppose an in-between situation is the one where all the developers except for the no-longer-wanted originating dictator stage a revolt. If a project has a dev team of (say) 10, and 9 of them set up a fork and pointedly don't include the remaining one, then that fork may manage to have credibility in the eyes of the users even if the disinvited developer was the originator. Particularly if they've done anything publicly recognisable as a bad idea.
And then I suppose there's the "bloodless" version, in which the 9 other developers collectively present the dictator with an ultimatum: agree to a formal process in which your word is not necessarily the final word, or else we all make our own fork and don't invite you. If the dictator believes the threat is credible and would work, then they're going to lose their dictatorship anyway, so saying yes to this deal is in their interest, because it means they retain some influence over what the software does.
Either way, that's an identifiable point at which you switch from having 1 person in charge to having 9 people in charge, so it's a place where you can set up a thing looking like a governance.