Hacker News Reader

Comment by throwawaygh | Hacker News Reader

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.

View on HN

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.

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

I'm 30 and that paragraph about OSS vs F500 resonates with me. I don't know how far it goes towards explaining all of my own tastes in OSS community, but the corporate sterility is definitely showing up to different levels in various places. It's the kind of thing I find offputting in and of itself, without even knowing what it's being used to enforce.

> Indeed, but for some reason it still feels odd.

I think putting the CoC into the repo is mainly to clarify that it applies to discussions on the issue tracker. If GitHub didn't also do issue tracking and other things where actual discussions occur, there would probably be fewer CoCs in repos.

> Measured tolerance and forgiveness are both important virtues

There are a small number of extremely toxic people in positions of power who will abuse "forgiveness" in order to deliberately commit an unending series of abuses on a string of people. People kept "forgiving" Harvey Weinstein for decades. The line between tolerance and enabling can get hard to distinguish, especially when someone has enough power to control the narrative.

So a community must be aware that its tolerance mechanisms can themselves be maliciously abused. But the alternative—intolerance and being unwilling to forgive—ends up harming the larger number of people who are fallible, do hurtful things, but can be remediated. It gives less room for people to be human.

Finding the balance between these opposing forces is hard. A maximally efficient and happy community is one of complete trust between all participants. But that is also the definition of a maximally vulnerable and exploitable one.

> But, also, I've always considered OSS a hobby scene rather than a business model or resume booster.

That line got really blurry when open source ate the world and many large tech companies now work heavily with open source. You have many employees (like myself) who work on open source projects full time at work. And you have others who work on open source because it helps them find employment at companies that use that code.

This is a super mature, nuanced post so thanks for that.

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

To some extent I think this is because GitHub doesn't offer the same tools that running your own mailing list would. A mailing list can do what you said, /dev/null ML contributions while still letting patches through. That's not something you can do easily in GitHub.

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

Rust has a pretty friendly community (from what I've encountered at least), but a lot of its core stakeholders do have a lot of corporate obligations, and many of them Rust related. It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job.

> I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are.

Github is part of it, but in general I think a lot of today's OSS projects don't have a strict separation of "community" and "code" in the way that projects in the past used to. Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation, and that older tools like mailing lists are cumbersome enough to maintain that newer developers don't actually explore using them very often.

> [Moderation is] not something you can do easily in GitHub

That seems like a pretty significant design flaw :(

> Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation [between "community" and "code"]

Indeed, this makes perfect sense.

> It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job.

Yup, totally fair and makes sense.

The assumption here is that any violation of the Code of Conduct would result in the offender being instantly kicked out, right?

But there are other ways to deal with actions that go against a code of conduct, to de-escalate situations and encourage rehabilitation within the project - just like what a healthy project would do without an explicit code of conduct.

Because let's be honest - those hobby groups you're talking about almost certainly did have a code of conduct, but it was probably implicit and uncodified.

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.

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.

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)

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

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.

I don't think you can really have good moderation of a stable group without the moderators being members of the group themselves -- and known and trusted/viewed positively by a majority. Otherwise they'll just be perceived as jerk outsiders who swoop in to make more trouble than they solve. And they will face constant pushback and non-compliance.

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

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.

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.

The problem is that people want the facade. I generally expect managers to present themselves as first among equals, even though I understand in extremis that's not true, and I wouldn't work in an organization where they do a bad job at pretending. It's my understanding that my mindset is pretty common, although I have to admit that I'm not sure because this isn't the kind of thing I'm comfortable polling my coworkers about.

My post is about HR processes, not management relationships. And what I said about the ultimate authority was about ownership, not management.

Managers are also just laborers. As laborers, they also need to know that "getting along with people" is most important.

> I generally expect managers to present themselves as first among equals, even though I understand in extremis that's not true, and I wouldn't work in an organization where they do a bad job at pretending.

If you're a senior engineer making anything less than 500k or so, your first-line and even second-line managers do have a complicated power relationship with you.

I.e., another way of saying what you said here is that your labor is in high enough demand that your mangers have to treat you with a certain amount of respect in day-to-day interactions.

A manager who doesn't show enough politeness/deference will have high turn-over, and in most situations that spells problems. Again, because they aren't capital owners. They are laborers.

Like I said, "getting along with people" is probably the most important skill. Finding yourself in an HR process means you failed at "getting along with people". The rest is noise. Don't rely on HR. Get along with people.

I have a nagging feeling the rules are different in fields like sales, trading, sports, or others where performance is more precisely quantified.

The reality, somewhat sad in my view, is that in most places, software shops, architecture firms, academia, pretty much anywhere where individual measurement isn't possible and most work is done in teams, most performance reviews are a thin veneer over a high school popularity contest. You get ahead by being liked, something that's at best loosely correlated to how much work you get done, or at what quality.

Of note, the best manager I worked for (in software) ran a great team by making work about the work, not being liked, or delivering great powerpoints, or other secondary things.

> sales

Most types of sales labor is a complete commodity. For every one high-powered b2b software sales person there are hundreds of folks selling commodity laptops to rural schools, pushing trim upgrades in car dealerships, cold-calling convenience store owners, etc. The high school politics in those sorts of sales shops are next-level.

> trading

Trading desks are often whole orgs, often with diffuse and difficult to measure contributions. Not so dissimilar from software shops, really. In fact, often literally are software shops!

> sports

I don't have first-hand experience with anything other than climbing and skiing, where "hussle" and getting along with everyone from sponsors to gym/resort owners to random community members is way more important than raw talent. At the end of the day you're basically an influencer. Instead of HR imposing rules to help with reputation management work, you're doing the HR reputation management job yourself.

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

> so play nice and don't piss off the wrong folks

"Play nice", "don't piss off" and "the wrong folks" are open to interpretation. I think having these at least somewhat codified is very helpful. Cultures differ a lot, and what may be considered "a useful, clear, concise and honest code review" in one is "blatant non-constructive shitstorm from an arrogant a-hole" in another.

However, such codification probably requires specific examples rather than "please be respectful to all people regardless of X, Y, Z" or "don't piss off people". For example, I really like how Recurse Center's "Social Rules" are described: https://web.archive.org/web/20211117232710/https://www.recur...

> Most of our social rules really boil down to "don't be a jerk" or "don't be annoying." Of course, almost nobody sets out to be a jerk or annoying, so telling people not to be jerks isn't a very productive strategy. That's why our social rules are designed to curtail specific behavior we've found to be destructive to a supportive, productive, and fun learning environment.

> "Play nice", "don't piss off" and "the wrong folks" are open to interpretation.

Yup. It's sometimes hard to figure out how power flows and the social preferences of the people who modulate those flows. Getting along in large orgs is a skill that requires both experience and intentional work.

The problem is that people rarely run into trouble due to abrasiveness among peers, so examples like the Recurse center can be helpful but are woefully incomplete as a guide to corporate politics.

Getting along while being ambitious is anything but easy. There are no rules.

At the end of the day, "social skills" and "social intelligence" are just that -- forms of skill and intelligence. "Getting Along" is always a learned behavior, albiet does come more naturally to some than others, and is far easier said than done.

These skills are often learned pretty early on in life. It's one of the reasons I encourage folks who are considering home-schooling to at least send their kids to one year of high school.

What's "a community" here?

If this "moderation team" felt that there is no option but to quit, that means that they were rejected by the community, complete with the "CoC" they tried to enforce.

Seems like everything is fine to me.

For me seems they were rejected by the core team, no idea who elected the moderators and who elected the core team , I do not know if Rust is a democracy and works like Debian or is different, I will try to inform myself though.

HR rules don't typically apply to executives even when it's stated that they apply to executives.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

The code doesn't cease to exist. If one person is doing all the heavy lifting and decides to stop, it isn't their fault for not creating a social hierarchy.

Reply on news.ycombinator.com