Based on this thesis I thought it was going to be a bit more meta about how software itself is inherently authoritarian-by-default from a technical perspective, how it takes active work to mitigate that dynamic, and how that spills over into our communities.

To illustrate this, I'll point to the differing mindset required to write secure code, and how most programmers are not good at it - ie modeling a second party who acts independently from the intent of the programmer. The programmer who doesn't do this is assuming an inherent authoritarianism whereby the code will only be used to carry out their intent, rather than as part of a mediation between parties with diverging interests. (security vulnerabilities specifically are the narrower "emperor has no clothes" dynamic)

We can see this manifest with how business types look at technologies like remote attestation (aka WEI, etc) - as a technique for preventing end users from using their own chosen software for their own purposes, in favor of the business's singular top-down vision/desires.

(OP essay focuses on social dynamics, which are much tougher to frame and substantiate arguments for. The attempt is laudable but then kind of falls flat due to only using one example (regardless of how flagrant of an example it is))

But the author is right, this is a pervasive problem in western culture that is the primary cause of most of our ill's when 90% of our society can't even conceive of supporting structural change in our institutions you know we have a problem.

The tyranny of the system administrator.

Jesus. Stop misusing the word authoritarian.

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

> 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.)