6 ms·

I'm generally in favor of enforcing high-level "behave professionally" norms in OSS communities. And not as a new phenomenon, either. I've been kick-banning dis

I'm generally in favor of enforcing high-level "behave professionally" norms in OSS communities. And not as a new phenomenon, either. I've been kick-banning disruptive people from IRC channels for several decades, I've run forums where I appointed mods, and I've always avoided participating in completely unmoderated communities beyond N=20 or so (not worth the headache). But for some reason, the formalization of conduct enforcement stuff around OSS projects still feels weird, off-putting, and very "Corporate HR"-y to me. I still get a kinda awkward feeling every time I see a code of conduct in a freaking code repository as opposed to an MOTD or mailing list welcome email or the like. The contents is normally reasonable and if it were in one of those other formats it'd feel normal, but checked into a code repo just feels wildly out of place and needlessly in-your-face? Maybe I'm just getting old.

caffeine 5y ago
Large OSS projects are largely staffed by corporate contributors - the culture shift in the organisations paying the contributors is reflected in the projects and the communities surrounding them.
couchand 5y ago
How exactly are the groups of people working on various parts of the official ecosystem supposed to coordinate their efforts? The only alternative I've seen is a benevolent dictator, which seems significantly worse for a number of reasons. Edit: it looks like you've removed the part about Teams/Committees.
- throwawaygh 5y ago
  yea, sorry, I tend to over-use the "edit" button and treat "submit" as "save draft". > How exactly are the groups of people working on various parts of the official ecosystem supposed to coordinate their efforts? The only alternative I've seen is a benevolent dictator, which seems significantly worse for a number of reasons. Yeah, I guess I'm just getting old. The idea of an open source project with enough people to form an entire committee of moderators also feels weird, but is apparently fairly normal these days.
  - couchand 5y ago
    It's our industry that's getting old. You used to be able to start a big project like a compiler or a browser and have some hope of producing a functional result "organically" (for lack of a better word). But we've reached the point where we're no longer just scrabbling together hovels with scrap wood, we're trying to build the Pyramids or the Hoover Dam now. A few anonymous internet denizens are not going to be able to accomplish that.
    - throwawaygh 5y ago
      Sure. And I dislike corporate BS but happily work in corporations as long as I can mostly get away with nothing but the most surface-level acknowledgment that the shit does indeed smell like roses. (And like 90+% of what HR enforces is mostly good anyways; pretending it's not a facade is often a small price to pay for the level of nonsense I'm shielded from) Again, I'm not even necessarily saying things should be different or proposing a better alternative. Just expressing a feeling. If could change one thing in the corporate world, it wouldn't be to change how corporations work. Simply disabusing people of fantasies about how corporations work would be far better than any incremental improvement. I guess I feel the same way about OSS codes of conduct. They're facade. To the extent that they're enforced, it's because the wizard behind the CoC curtain allows this to the case. Should anything be changed? IDK, but everyone understanding this would probably be preferable to any incremental change to project governance. If that makes sense.
      - klabb3 5y ago
        Late to the party, but I strongly agree with your comments in this thread, based on similar experience in a corporate environment. The weird paradox in this governance model is why we see so much fluff around the actual autocracy that - at the end of the day - is what matters. Why pay for HR, townhall events etc, etc, if in the end it doesn't matter? I think the obvious reason is - ironically - making accountability optional, through selective enforcement. If you have an arbitrary and emotionally based strict set of rules, you can freely accuse practically anyone for breaking it, since the owners have last say anyway. As such, you can say "sorry, we had to let Tim go, because he violated policy" - and abracadabra, nobody is personally accountable. It's the woke equivalent of a firing squad. In fact, if a process is not universal, but selective, it is just a power tool. And what's more attractive than a power tool? Simply throw process on people you dislike, and let the people you like through. That's not to say there's some calculated malicious intent behind this. There are tons of people who genuinely think these systems are good and serve them, or people less privileged than them.
- DoneWithAllThat 5y ago
  As a matter of fact no, benevolent dictator is not significantly worse. In fact historical evidence when it comes to OSS projects points to the benevolent dictator model being the most effective. It may not satisfy social justice activists pretending to be competent programmers demanding a seat at a table that they never earned, but most successful projects are not ruled by committee until they reach a significant level of maturation, and it’s arguable their development slows down quite a bit at that point.
  - throwawaygh 5y ago
    > benevolent dictator is not significantly worse I think your normative justification for project dictatorship misses the more important point: there's probably a dictatorship either way. In these cases, the main advantage of the overt dictatorship model over the layer of indirection dictatorship model is that you at least know who's really in charge. In some odd sense, the mod team that just resigned is in agreement: their resignation lays vare exactly who's in charge.
    - raxxorrax 5y ago
      The benevolent dictator might have too much sway in some project, although in most cases it literary is his project. Problem with enforcing compliance of behavior is that this becomes the raison d'être. This will always fail in any configuration at some point. We are talking about people and if their rulings don't find acceptance, they will interpret it as a personal attack. I am not above that, you are not above that and nobody really is. I have no info about this case, but it fits the profile. I only take active part in smaller OSS projects and corporate rules in general do suck the fun out of it. Maybe Rust is beyond that, but I would vastly prefer the eccentric dictator to corporate HR, because the latter is nothing else. The dictator or developer has other ambitions aside from behavior enforcement, so it is easier to cooperate. And if you do not like the dictator, you might be able to fork the project and make it conform to your personal views to the same (overbearing) degree. Win-win.
  - couchand 5y ago
    Far too many promising open source projects have disappeared because the benevolent dictator lost interest and disappeared without leaving an empowered community. Far too many promising open source projects withered and died because the not-actually-benevolent dictator turned off every would-be contributor. In the scope of things, these are much more common that the few examples of projects that succeeded in spite of low bus factor and toxicity.
simion314 5y ago
>But for some reason, the formalization of conduct enforcement stuff around OSS projects still feels weird, off-putting, and very "Corporate HR"-y to me. But if a community already approved such rules is it OK that those would not apply equally for all? Before joining a new community I always check and see if there is a lot of toxicity or just low effort contributions and I am avoiding those, it would suck to join a community because they promise moderation and later you see that the rules don't apply equally.
- throwawaygh 5y ago
  Maybe it will help to explicate what rubs me the wrong way about "corporate HR". The facade of process masking Machiavellian reality is what rubs me the wrong way. I'm always astounded by folks who don't understand that companies are feudal kingdoms and that all the stuff about processes and protecting people who are innocent/do the right thing is just hot air. And I've never been on the wrong side of HR, so this isn't a personal issue per se. But when I mentor new grads, I do make sure to find some time to explain how companies really work and stress that "getting along" with people is the most important skill. I've always felt like the world would be a better place -- and workplaces would function better -- if Corporate HR was just honest: "this company is someone else's property, you have no rights to that property, we do what we want, so play nice and don't piss off the wrong folks unless you're ok leaving." Most OSS projects aren't so dissimilar. I don't know about Rust, and suspect "Core" might have a different meaning here. But in most projects the core (aka primary) developers effectively own the project. Rules to the contrary are at best aspirational and at worst lies. If you disagree with the primary developers, it's much better the just fork the project than to imagine that there's some fair and rational process by which you will be able to plead your case and over-ride their edicts. Again, this isn't a value judgement. It's just a description of how reality works.
  - poszlem 5y ago
    This 100 times this. It's especially weird since the whole idea of open source was that you can just fork a project if you don't like it.
  - 5y ago
tzs 5y ago
With most OSS projects nowadays I don't think you have to use a mailing list or anything that would have an MOTD in order to contribute. Contributions nowadays are often done entirely through the repository, so it makes sense to put in them the things that people contemplating contribution should be cognizant of. Repositories for most projects are more project repositories than mere code repositories.
- throwawaygh 5y ago
  > Repositories for most projects are more project repositories than mere code repositories. Indeed, but for some reason it still feels odd. I've acknowledged I'm getting old, right? ;-) Also, there is some rational justification to my feeling. It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contributions. But if they made a technically meritorious merge request via SCM the contribution would still get due consideration. Even assholes can be good programmers, after all. That always felt healthy & mature to me. Finding a way to protect the masses from assholes without exiling the asshole always felt like a sign of good community stewardship. It's something I strived to do in communities I moderated. So, what? I guess this: Bundling the CoC into the repo violates this expectation. Just because someone couldn't get along doesn't mean we kick them out of the hobby. I think that's why it makes me uncomfortable. In a hobby org, you don't let the known jerk on the board. You definitely don't let him man the booth at community outreach events! However, you also don't usually kick him out of the core activity. In a non-OSS hobby context, I've had folks steal things but still allowed them to stay in the community while taking away unsupervised physical access to common property. Measured tolerance and forgiveness are both important virtues, and sticking around in a community after public humiliation shows a commendable level of commitment to the hobby/community. The social bonding that happens via the process of apology and forgiveness often does far more good for the community than the harm of the infraction. But, also, I've always considered OSS a hobby scene rather than a business model or resume booster. I guess if an OSS project is just a way for companies to commodify complements and for contributors to get jobs, then treating it like a Fortune 500 all-hands makes sense. But I'm not interested in those types of communities; I have hobbies, and programming can be a hobby for me, but I charge a lot for my labor and would never, ever work in a corporate environment for free. I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are. Again, getting old I guess.
cbm-vic-20 5y ago
The vast majority of open source projects do not create their own open source license- most of them choose from a relatively small selection of widely used licenses (GPL, BSD, MIT, Apache, etc.). Why then do so many project choose to roll their own CoC? I'd expect that there would also be a relatively small handful of widely used CoCs to choose from, and a project could pick based on their projects' needs.
- Macha 5y ago
  I'd wager this is because there is one outright leader in the field (the Contributor Covenant) who's author has at times been a controversial figure in her views on enforcement and scope of codes of conduct, which can lead to people being apprehensive of just adopting the popular example. You can see similar with licenses. Stallman was initially controversial for his views on software licensing, and so in the early days there was a proliferation of licenses like the eclipse public license, mozilla public license, microsoft public license, CCDL, etc.
- bluGill 5y ago
  I'm on a tiny project without a CoC because I don't know how to enforce it if we had one. Enforce means it needs to apply to me, and also whoever enforces it needs to be active to watch for issues. I wish KDE/Gnome/other big project would just do a CoC as a service for tiny projects. For the most part the CoC should be standard, and a few experts to enforce it would be better than random enforcement. (note I have no idea if the above is possible)
  - throwawaygh 5y ago
    > For the most part the CoC should be standard, and a few experts to enforce it would be better than random enforcement. I've heard that large-scale enforcement of CoC is super easy and that all the big social media companies have it figured out ;-)
  - ufmace 5y ago
    I don't think it makes sense to have a CoC beyond "Don't be a jerk" until you have multiple teams and more complex governance structures.

caffeine 5y ago

Large OSS projects are largely staffed by corporate contributors - the culture shift in the organisations paying the contributors is reflected in the projects and the communities surrounding them.

couchand 5y ago

How exactly are the groups of people working on various parts of the official ecosystem supposed to coordinate their efforts? The only alternative I've seen is a benevolent dictator, which seems significantly worse for a number of reasons. Edit: it looks like you've removed the part about Teams/Committees.

throwawaygh 5y ago
yea, sorry, I tend to over-use the "edit" button and treat "submit" as "save draft". > How exactly are the groups of people working on various parts of the official ecosystem supposed to coordinate their efforts? The only alternative I've seen is a benevolent dictator, which seems significantly worse for a number of reasons. Yeah, I guess I'm just getting old. The idea of an open source project with enough people to form an entire committee of moderators also feels weird, but is apparently fairly normal these days.
- couchand 5y ago
  It's our industry that's getting old. You used to be able to start a big project like a compiler or a browser and have some hope of producing a functional result "organically" (for lack of a better word). But we've reached the point where we're no longer just scrabbling together hovels with scrap wood, we're trying to build the Pyramids or the Hoover Dam now. A few anonymous internet denizens are not going to be able to accomplish that.
  - throwawaygh 5y ago
    Sure. And I dislike corporate BS but happily work in corporations as long as I can mostly get away with nothing but the most surface-level acknowledgment that the shit does indeed smell like roses. (And like 90+% of what HR enforces is mostly good anyways; pretending it's not a facade is often a small price to pay for the level of nonsense I'm shielded from) Again, I'm not even necessarily saying things should be different or proposing a better alternative. Just expressing a feeling. If could change one thing in the corporate world, it wouldn't be to change how corporations work. Simply disabusing people of fantasies about how corporations work would be far better than any incremental improvement. I guess I feel the same way about OSS codes of conduct. They're facade. To the extent that they're enforced, it's because the wizard behind the CoC curtain allows this to the case. Should anything be changed? IDK, but everyone understanding this would probably be preferable to any incremental change to project governance. If that makes sense.
    - klabb3 5y ago
      Late to the party, but I strongly agree with your comments in this thread, based on similar experience in a corporate environment. The weird paradox in this governance model is why we see so much fluff around the actual autocracy that - at the end of the day - is what matters. Why pay for HR, townhall events etc, etc, if in the end it doesn't matter? I think the obvious reason is - ironically - making accountability optional, through selective enforcement. If you have an arbitrary and emotionally based strict set of rules, you can freely accuse practically anyone for breaking it, since the owners have last say anyway. As such, you can say "sorry, we had to let Tim go, because he violated policy" - and abracadabra, nobody is personally accountable. It's the woke equivalent of a firing squad. In fact, if a process is not universal, but selective, it is just a power tool. And what's more attractive than a power tool? Simply throw process on people you dislike, and let the people you like through. That's not to say there's some calculated malicious intent behind this. There are tons of people who genuinely think these systems are good and serve them, or people less privileged than them.
DoneWithAllThat 5y ago
As a matter of fact no, benevolent dictator is not significantly worse. In fact historical evidence when it comes to OSS projects points to the benevolent dictator model being the most effective. It may not satisfy social justice activists pretending to be competent programmers demanding a seat at a table that they never earned, but most successful projects are not ruled by committee until they reach a significant level of maturation, and it’s arguable their development slows down quite a bit at that point.
- throwawaygh 5y ago
  > benevolent dictator is not significantly worse I think your normative justification for project dictatorship misses the more important point: there's probably a dictatorship either way. In these cases, the main advantage of the overt dictatorship model over the layer of indirection dictatorship model is that you at least know who's really in charge. In some odd sense, the mod team that just resigned is in agreement: their resignation lays vare exactly who's in charge.
  - raxxorrax 5y ago
    The benevolent dictator might have too much sway in some project, although in most cases it literary is his project. Problem with enforcing compliance of behavior is that this becomes the raison d'être. This will always fail in any configuration at some point. We are talking about people and if their rulings don't find acceptance, they will interpret it as a personal attack. I am not above that, you are not above that and nobody really is. I have no info about this case, but it fits the profile. I only take active part in smaller OSS projects and corporate rules in general do suck the fun out of it. Maybe Rust is beyond that, but I would vastly prefer the eccentric dictator to corporate HR, because the latter is nothing else. The dictator or developer has other ambitions aside from behavior enforcement, so it is easier to cooperate. And if you do not like the dictator, you might be able to fork the project and make it conform to your personal views to the same (overbearing) degree. Win-win.
- couchand 5y ago
  Far too many promising open source projects have disappeared because the benevolent dictator lost interest and disappeared without leaving an empowered community. Far too many promising open source projects withered and died because the not-actually-benevolent dictator turned off every would-be contributor. In the scope of things, these are much more common that the few examples of projects that succeeded in spite of low bus factor and toxicity.

simion314 5y ago

>But for some reason, the formalization of conduct enforcement stuff around OSS projects still feels weird, off-putting, and very "Corporate HR"-y to me. But if a community already approved such rules is it OK that those would not apply equally for all? Before joining a new community I always check and see if there is a lot of toxicity or just low effort contributions and I am avoiding those, it would suck to join a community because they promise moderation and later you see that the rules don't apply equally.

throwawaygh 5y ago
Maybe it will help to explicate what rubs me the wrong way about "corporate HR". The facade of process masking Machiavellian reality is what rubs me the wrong way. I'm always astounded by folks who don't understand that companies are feudal kingdoms and that all the stuff about processes and protecting people who are innocent/do the right thing is just hot air. And I've never been on the wrong side of HR, so this isn't a personal issue per se. But when I mentor new grads, I do make sure to find some time to explain how companies really work and stress that "getting along" with people is the most important skill. I've always felt like the world would be a better place -- and workplaces would function better -- if Corporate HR was just honest: "this company is someone else's property, you have no rights to that property, we do what we want, so play nice and don't piss off the wrong folks unless you're ok leaving." Most OSS projects aren't so dissimilar. I don't know about Rust, and suspect "Core" might have a different meaning here. But in most projects the core (aka primary) developers effectively own the project. Rules to the contrary are at best aspirational and at worst lies. If you disagree with the primary developers, it's much better the just fork the project than to imagine that there's some fair and rational process by which you will be able to plead your case and over-ride their edicts. Again, this isn't a value judgement. It's just a description of how reality works.
- poszlem 5y ago
  This 100 times this. It's especially weird since the whole idea of open source was that you can just fork a project if you don't like it.
- 5y ago

tzs 5y ago

With most OSS projects nowadays I don't think you have to use a mailing list or anything that would have an MOTD in order to contribute. Contributions nowadays are often done entirely through the repository, so it makes sense to put in them the things that people contemplating contribution should be cognizant of. Repositories for most projects are more project repositories than mere code repositories.

throwawaygh 5y ago
> Repositories for most projects are more project repositories than mere code repositories. Indeed, but for some reason it still feels odd. I've acknowledged I'm getting old, right? ;-) Also, there is some rational justification to my feeling. It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contributions. But if they made a technically meritorious merge request via SCM the contribution would still get due consideration. Even assholes can be good programmers, after all. That always felt healthy & mature to me. Finding a way to protect the masses from assholes without exiling the asshole always felt like a sign of good community stewardship. It's something I strived to do in communities I moderated. So, what? I guess this: Bundling the CoC into the repo violates this expectation. Just because someone couldn't get along doesn't mean we kick them out of the hobby. I think that's why it makes me uncomfortable. In a hobby org, you don't let the known jerk on the board. You definitely don't let him man the booth at community outreach events! However, you also don't usually kick him out of the core activity. In a non-OSS hobby context, I've had folks steal things but still allowed them to stay in the community while taking away unsupervised physical access to common property. Measured tolerance and forgiveness are both important virtues, and sticking around in a community after public humiliation shows a commendable level of commitment to the hobby/community. The social bonding that happens via the process of apology and forgiveness often does far more good for the community than the harm of the infraction. But, also, I've always considered OSS a hobby scene rather than a business model or resume booster. I guess if an OSS project is just a way for companies to commodify complements and for contributors to get jobs, then treating it like a Fortune 500 all-hands makes sense. But I'm not interested in those types of communities; I have hobbies, and programming can be a hobby for me, but I charge a lot for my labor and would never, ever work in a corporate environment for free. I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are. Again, getting old I guess.

cbm-vic-20 5y ago

The vast majority of open source projects do not create their own open source license- most of them choose from a relatively small selection of widely used licenses (GPL, BSD, MIT, Apache, etc.). Why then do so many project choose to roll their own CoC? I'd expect that there would also be a relatively small handful of widely used CoCs to choose from, and a project could pick based on their projects' needs.

Macha 5y ago
I'd wager this is because there is one outright leader in the field (the Contributor Covenant) who's author has at times been a controversial figure in her views on enforcement and scope of codes of conduct, which can lead to people being apprehensive of just adopting the popular example. You can see similar with licenses. Stallman was initially controversial for his views on software licensing, and so in the early days there was a proliferation of licenses like the eclipse public license, mozilla public license, microsoft public license, CCDL, etc.
bluGill 5y ago
I'm on a tiny project without a CoC because I don't know how to enforce it if we had one. Enforce means it needs to apply to me, and also whoever enforces it needs to be active to watch for issues. I wish KDE/Gnome/other big project would just do a CoC as a service for tiny projects. For the most part the CoC should be standard, and a few experts to enforce it would be better than random enforcement. (note I have no idea if the above is possible)
- throwawaygh 5y ago
  > For the most part the CoC should be standard, and a few experts to enforce it would be better than random enforcement. I've heard that large-scale enforcement of CoC is super easy and that all the big social media companies have it figured out ;-)
- ufmace 5y ago
  I don't think it makes sense to have a CoC beyond "Don't be a jerk" until you have multiple teams and more complex governance structures.