Not knowing CS appears to be an advantage in this case? A socially well adjusted 14 year old girl could glance at the text and say "yeah that is obvious".
The problem in open source is that programmers often accept tyranny by a couple of manipulators because they are conflict averse or don't even notice. CS does not help here.
The manipulators of course are the players and know the drill.
Van Rossum used organizations and people from the start at CWI. He set up the PSF to increase his power and that of his lieutenants. No other open source organization understand politics and bureaucracy as well as the PSF people.
Most of the real work is done by others. Initially the inner circle even merged the work of others and got credited in the SVN commits. That is why they have such high commit counts in the GitHub statistics. Being release manager helps, too.
I think the concept that our culture is ripe with authoritarianism is sound idea. It's funny, I can see it easy in politics and government but not in our organizations until now, so that was a surprise to me. But the way it's written comes off like someone with an axe to grind. The length was way over the top and it needs refining.
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.
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.
> authoritarianism is so ingrained in the fabric of software development
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))
I like people who pre emptively counter common arguments they have been made in the past or that they can predict by red teaming their own thought. What’s wrong with that ? Shows careful thought
I think that it's fine to address anticipated counterarguments, but you should save that for after you made your main point. Otherwise the reader is going to get bored of reading a defense of something he hasn't even seen yet.
The initial sections are a bit dry, yes. I would suggest skipping to "Deference to Authority" and "2012 Pycon Code of Conduct" and "2012 Pycon: Steve Holden's One Eyed Snake".
Zed Shaw accurately predicted the cancellation excesses of 2020 up to at least 2024 using basic reasoning about group dynamics and a concrete example from 2012. The inner circle is always protected and can do whatever it likes. He was wrong about all core devs being protected. The inner circle is very much a subset.
To this end, I've long held that Zed Shaw's blindness was in his misunderstanding of how authoritarian inner sancta tend to work in times of social or ideological crisis. Some protection happens, but the lion's share of the work undertaken is purification, especially when the list of targets external to that inner sanctum has been exhausted.
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.)
From the same mind who brought us "python 3 is not turing complete because its interpreter cannot run python 2 code."
Not knowing CS appears to be an advantage in this case? A socially well adjusted 14 year old girl could glance at the text and say "yeah that is obvious".
The problem in open source is that programmers often accept tyranny by a couple of manipulators because they are conflict averse or don't even notice. CS does not help here.
The manipulators of course are the players and know the drill.
Van Rossum used organizations and people from the start at CWI. He set up the PSF to increase his power and that of his lieutenants. No other open source organization understand politics and bureaucracy as well as the PSF people.
Most of the real work is done by others. Initially the inner circle even merged the work of others and got credited in the SVN commits. That is why they have such high commit counts in the GitHub statistics. Being release manager helps, too.
I think the concept that our culture is ripe with authoritarianism is sound idea. It's funny, I can see it easy in politics and government but not in our organizations until now, so that was a surprise to me. But the way it's written comes off like someone with an axe to grind. The length was way over the top and it needs refining.
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.
Should be (2020) per the URL.
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.
> authoritarianism is so ingrained in the fabric of software development
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))
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.
I like people who pre emptively counter common arguments they have been made in the past or that they can predict by red teaming their own thought. What’s wrong with that ? Shows careful thought
I think that it's fine to address anticipated counterarguments, but you should save that for after you made your main point. Otherwise the reader is going to get bored of reading a defense of something he hasn't even seen yet.
It may show careful thought, but it can also take too long to get to the point, especially for readers who don't have those objections.
The initial sections are a bit dry, yes. I would suggest skipping to "Deference to Authority" and "2012 Pycon Code of Conduct" and "2012 Pycon: Steve Holden's One Eyed Snake".
Zed Shaw accurately predicted the cancellation excesses of 2020 up to at least 2024 using basic reasoning about group dynamics and a concrete example from 2012. The inner circle is always protected and can do whatever it likes. He was wrong about all core devs being protected. The inner circle is very much a subset.
To this end, I've long held that Zed Shaw's blindness was in his misunderstanding of how authoritarian inner sancta tend to work in times of social or ideological crisis. Some protection happens, but the lion's share of the work undertaken is purification, especially when the list of targets external to that inner sanctum has been exhausted.
who could ever tell that someone questioning authority would need to position themselves forward in face of unfounded criticism?
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.)
[flagged]