Authoritarianism of Code (2020)

I’d take this even further and say most programmers are incapable of building authoritarian software; where the client is subservient to the server by default.

The tyranny of the system administrator.

Repos are owned by an owner. The owner has full control of the repo but it's not like you are being forced to use the Repo. Nobody comes to your house and forces you at gunpoint to delete your forks or forces you not to use alternative software.

Jesus. Stop misusing the word authoritarian.

I stopped reading when the author was spending pages defending the stuff he hadn't even written yet from the imaginary criticism in their head.

Future tip: make your argument. Make it well, and make it succinctly. Save "arguing with the Internet" for the comments.

Seems this person is well known for saying silly things based on the comments but I read it carefully and tried to give it a fair shake.

> Accusations of mental instability are a favorite of fascist regimes, so if you see that you know immediately that person is definitely a fascist.

Spending all of these paragraphs trying to preempt imaginary fallacious arguments that haven't happened yet, and then dropping an unqualified "Anyone that accuses someone of being mentally unstable is definitely a fascist."

It is maybe bad to spend an entire half of your writeup preemptively defending it to begin with, but it's pretty bad if you essentially commit a fallacy while you are trying to preempt similar ones.

--

It then goes on to discuss the utter trainwreck that is Python's handling of two different controversies. To their credit, though, I think I do generally agree with the point being made, but the issue is I'm not really sure what this write-up is meant to do. I think it is effectively an overly long-winded way of saying that Code of Conducts are often "rules for thee and not for me".

But I don't think building out an entire framework for explaining that is going to do anything to change the minds of people who don't already believe that. Citing a bunch of incidents where CoC enforcement was clearly unfair won't get us anywhere because the fact is the moment you assign authority to a group there will be assholes who want to abuse that. People who are in favor of CoC's will likely blame other issues instead of the CoC or structures around it.

This is precisely why software developers were originally attracted to the concept of meritocracy, is it not? If you have a governance board with people who have power to enforce a Code of Conduct, you will inevitably attract people who want to use that for personal gain or at least imposing their will rather than actually trying to be a good semaritan and act in the best interests of everyone as a whole. The meritocracy story sounds so nice by comparison: you build this great software, people use it, in exchange for your hard work you inherit some authority. The people who are most likely to put in this work with no guaranteed return of any kind are most likely to have the interests of the project they poured effort into in mind and heart, so everything is aligned. In theory...

In practice, though, that also comes with plenty of problems.

Personally I think CoCs are mostly a smokescreen, a checkbox to socially signal "Yes we want to be progressive and do the right thing" but not true solution to the structural problems that led to their creation. I think I am aligned with the author on this, to some degree. But what I really want to know is just, what do I do if I want to avoid this problem? I am fine admitting that BFDLs have problems, clearly elected governance boards have just as much or maybe even more problems, how do we structure things to allow projects to thrive and grow without the social problems that have plagued open source?

To me it seems you can't win. It mostly looks like truly eliminating the problem involves radical decentralization, but doing that makes it much harder for projects to thrive and grow, and makes software dev less efficient in some ways. Maybe still worth doing, but all else equals I think centralized development eventually wins defacto. NixOS would be cool if it was radically decentralized but having Hydra be a publicly funded resource accessible to all kinda requires a proper organization.

I am sure this thread will get flagged and buried but it is a discussion that, one way or another, needs to be addressed. How do we set up the foundations for a stronger community more resistant to the kinds of problems that our existing attempts have? Despite pushes for more and heavier bureaucracy, I think even proponents of these measures are starting to get cold feet due to the obviousness with which adding more bureaucracy and authority is genuinely not fixing a god damned thing. I think they're coming to very different conclusions on why sometimes, but still, I genuinely think the current "Just Add Bureaucracy" era of "fixing" open source communities is nearing its end. (Could be a damn long tail though.)