Eric S. Raymond to the Oss Community on Codes of Conduct: Refuse to Have One
Posted3 months agoActive3 months ago
twitter.comTechstory
heatednegative
Debate
80/100
Open SourceCode of ConductCommunity Management
Key topics
Open Source
Code of Conduct
Community Management
Eric S. Raymond advises against having a code of conduct in open source projects, sparking a heated discussion on the necessity and effectiveness of CoCs.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
7m
Peak period
18
0-6h
Avg / period
5.7
Comment distribution34 data points
Loading chart...
Based on 34 loaded comments
Key moments
- 01Story posted
Sep 27, 2025 at 1:44 AM EDT
3 months ago
Step 01 - 02First comment
Sep 27, 2025 at 1:51 AM EDT
7m after posting
Step 02 - 03Peak activity
18 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 30, 2025 at 6:06 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45393425Type: storyLast synced: 11/20/2025, 5:57:30 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> "If you are more annoying to work with than your contributions justify, you'll be ejected."
is not unreasonable (whether written down or not) for an individual's hobby project, but for something run by a company or other organization I think more detail is required.
The OSI code of conduct seems too general, perhaps open for different interpretations or potentially selective enforcement: https://opensource.org/codeofconduct
The Linux one I prefer, since it's concise and clear, e.g. "sexualized language" and "harassment" are unacceptable: https://docs.kernel.org/process/code-of-conduct.html
My own employer's code of conduct (we have open source projects, discussion forums etc) looks similar to the Linux one. I think it is enforced about once a year, and I think the reason has been either sexual harassment or repeated personal criticism of individuals' work.
Good questions are: What purpose does a CoC serve? How does it help?
In most, if not all cases, they are not very helpful beyond, indeed, politics and drama because they turn into a weapon (on the assumption that this wasn't the aim all along).
When a CoC is pushed by a company I think it's probably because companies need company policies for employees for HR and legal reasons. I am not convinced they could explain why that must extend beyond that, and really this is an ass-covering exercise in case things get too "raucous" in the project and produces bad PR.
At work I think it has helped since we now have a clear procedure to follow if there's a problem.
Having the Code of Conduct be a public document rather than only an internal one means there are fewer excuses available for not following it — for example someone can't claim they thought it would be OK to ask a developer for sex since we wrote down that that's not OK.
It's also easier to explain in case the problem individual is employed by a paying customer.
The person who thought this would be okay will not be stopped by a Code of Conduct.
The people who know it's not okay don't need a Code of Conduct.
The whole thing is useless. This is the same retarded shit as people stating their pronouns, trying to engineer every social human relation.
Don't be a jerk with people. If someone looks a certain way, it would be kind to assume they want to be treated in a certain way, etc, etc. You don't need terms of conduct and similar bullshit for that.
I'd argue that this is unreasonable for any project large enough to need a CoC at all. What it amounts to is excusing misconduct by project insiders, while allowing them to drive off new users by declaring their behavior 'annoying'. This isn't a code of conduct at all; it's a formalized "old boys club" dynamic.
There's a risk that this happens, sure, but it can be more charitably read as allowing/retaining people like Steve Jobs or Linus Torvalds, who, despite being assholes, are effective assholes and usually spew vitriol only in the interests of the product itself.
Weighing annoyance against contributions is a valid methodology. Your concern is valid, as well, so governance should always be introspective enough to ensure that the metrics of "annoying" and "useful" are objective ones and don't grandfather in the insiders.
In fact, a CoC is no more than them laying down the law explicitly on how they want people to behave in the project.
"If you are more annoying to work with than your contributions justify, you'll be ejected" is spot-on on how things work in general.
That might lead the project to fail or fork (beauty of OSS) but that's life.
I don't like CoCs either, but ironically guys like him make me think they might be needed after all...
Having a clear CoC helps keep the good actors safe while having clear red lines to keep the bad actors either in line, or out. But it's so sad that we got to that point at all...
Simple, well-motivated, well-practiced (I think). Unlike more convoluted CoCs, it’s tightly scoped on work, not fun. Specific labor intended to produce contributions instead of enjoyable social experiences.
I feel a lot more OSS should avoid fun. Fun doesn’t seem to scale, especially when it gets in the way of real work.
This, so much. F/OSS os so much drama these days, and codes of conduct are the most effective tools to create more drama, usually.
https://discourse.ubuntu.com/t/on-discourse-rules-about-poli...
If you are actually right, then talk about in the open. Show restraint from name calling. Not everybody is out there with a hidden agenda. Lobste.rs is a great example of this. No shadow banning. Everything has a reason and accountability.
Shoutout to people like JT from the BSD Now podcast as well. I am a fan of his moderation on the Telegram channel. Atleast as far as I have witnessed, I have seen some of the controversial topics going on and on but not banned for difference of opinions. A lot of de-escalation and patience. It would've been so easy for him to just do some Hammering. But that's not how it goes most of the time.
We need more spaces like this.
It’s basically addressing the symptoms rather than curing the disease: if you want to do foss, you have to accept you might be collaborating with somebody whose ideas are completely antithetical to yours. Any other approach is not free, and is not open.
Yes. Looks like I didn't clarify my point in the main post. I don't think CoC is helping anyone. It is better to be without it.
I was talking about how CoC's was being applied at present and how it was first introduced. If you've been around since at least early 2000s with flamewars, then you know why CoC came about. It was not a pretty sight. A lot of communities were like 4chan. Unfiltered and with people getting banned when nobody is backing down from an argument. I wasn't rallying for CoC to be made better. But I understand where it came from at the same time.
I've been on the Internet when flamewars were common, and CoC weren't a thing yet.
CoC (along with committees) are a very recent thing. They weren't introduced until certain people started exercising moral blackmail onto projects, people and organizations by pushing political topics into technical discussions.
Back in the days of flamewars there were a few rules and pretty much just moderators to enforce them.
Rules were simple, you were usually banned if your messages were either not civil (and here again, the bar was high), if your contributions were comically off-topic or if you spammed the forum/newsgroup/mailing list.
And it's not just OSS projects you know? There are OSS related communities like Linux / BSD and many many other projects/communities. CoC unfairness is all over there too.
CoCs simply exist because there is a large contingent of people that really do love making and enforcing rules.
I'm in your camp to be honest, as a maintainer I feel like I need no other justification than "I don't like you" for refusing someone access to my project.
What is practical is a list of obligations the maintainers are willing to do for the community:
Maintainers can only directly control themselves, after all. Only through their actions does anything happen, either merging code, or removing people from accessing the project.
Knowing where the maintainers are going to draw the line is far more useful.
Indeed, this is how cancel culture started (not just in OSS), and look where it got us.
"If you are more annoying to work with than your contributions justify, you'll be ejected." should be all that is required, if it really needs to be said at all.
e.g. "all violations must be reported to the committee" => "we will forbid anyone taking action without the committee's prior approval, and insist that disclosing any reports to us is a violation of policy, then refuse to take any action on reports".
So a thing that was supposed to explicitly communicate shared expectations and norms, instead becomes a way to minimize risk of bad PR for the project by silencing anyone who believed they were operating in good faith.
[1] - https://aworkinglibrary.com/writing/accountability-sinks
People who run projects get to decide if they have a CoC or not, Raymond isn't the boss of the bazaar or the cathedral.
13 more comments available on Hacker News