Toxicity in Open Source Discussions | Hacker News Reader

Toxicity in Open Source Discussions

tylercipriani.com

43 pointsthcipriani56 comments

One thing I learned from playing video games is that online, you can just ignore and block anyone. Seriously, everything is detached.

What's the difference between a stranger on the internet yelling at you versus a crazy homeless man in San Francisco yelling at you? Absolutely none, their thoughts affect in you in 0 ways, feel free to ignore and carry on with your day.

Edit, because a lot of replies are getting off-track: I'd be curious to learn if it is different in open-source and if so, why. My understanding was that the "professional" way to deal with hecklers online is in fact to ignore them and delete/block their content.

Well, there’s actually one significant different. The IRL deranged person, if physically close enough, can actually cause you physical harm. Sure, ignore them, but remain observant and in tune with your surroundings.

Well the deranged clown in your online game can ruin the next 30 or however much minutes of the online match (as in MOBAs there is punishment for just leaving). Which is still mildly annoying

Hmm. One thing I learned from playing video games is that I enjoy myself way more when my teammates are friendly or at least not actively hostile to me, even if I know I can block their communication.

Let me guess, MOBA player?

The crazy homeless man can shiv you for not giving him a handout.

It is interesting to see the differences in how people handle negativity online. Some people have no problem ignoring negativity and moving on. Others get satisfaction in hitting the block button. Others can't let it go and will eventually let negativity consume them and burn them out.

Learning how to shrug it off is imperative for anyone who wants to post something online. If you can't ignore negative comments and move on without getting worked up, sharing anything from open source to social media isn't a good idea. Save yourself the stress.

> If you can't ignore negative comments and move on without getting worked up

Expecting everyone to have your opinion is literally entitlement.

Perhaps consider empathizing and addressing the complexities root cause rather than just shrugging it off as, "boys will be boys."

If anyone is entitled in this discussion it would be the people expecting to be spoken to in their preferred tone.

Perhaps consider that you will never be able to control the actions of other people and that you can only control the actions (and reactions) of yourself.

I don't understand your point. Are you agreeing that you should simply shrug it off because not everyone will have your opinion, or are you disagreeing?

It also depends on which platform you're on. Traditional forum software has lots of moderation tools at your disposal. Chat software tends to be more limited. GitHub has virtually no tooling for moderatings issues/PRs and blocking abusive people. It's much harder to ignore negativity when you can't decisively remove them from your working environment.

> Some people have no problem ignoring negativity and moving on. Others get satisfaction in hitting the block button.

Not sure if you were trying to set up this dichotomy, but there's a middle ground here where you recognize yourself as someone who has trouble letting it go and can use the block button to help you ignore and move on without feeling perversely satisfied by it.

Certainly we can expect open source work to not be on the same level, experience-wise, as online gaming. ;P

We're a community and we should show each other more respect.

It's not the simple.

Imagine owning a bar and working as the bartender. A dude comes in and starts acting crazy. Sure, maybe you can ignore him. But he's disturbing the other patrons and spoiling their experience of the bar that you're invested being successful.

So maybe you throw him out. But every single thing you do in this bar is streamed 24/7 onto YouTube and visible forever. People may see the clip of you kicking him out, but not the hours of footage of him bothering everyone. Maybe they decide you kicked him out because you're a tyrant, or because of his appearance.

Just ignoring someone, IRL or online can have its consequences. The homeless guy can attack you physically. The online troll can try to cancel you digitally.

If the last few years have taught us anything, it is that no one is safe from abusive behavior by people who feel entitled to something you have (money, time, etc.) and seem to have nothing better to do than go after you for the slightest thing.

Online they can badmouth you and your project to everyone they contact. They can leave nasty comments on your blog or in open forums like HN. They can give your product bad reviews. They can issue takedown notices to social media sites.

Never interact online with your real name. The internet is not a real place. Block the people who are annoying and get on with doing what you enjoy. They can try to cancel your online name all they want. It doesn't matter.

Many (if not most) contribute to FOSS projects under their real names, and often have their email addresses (even if maybe project specific), so they can bother you off list in various ways.

This happens in FOSS projects even to this day. There's this one dude who is banned from a popular linux distro mailing list, so he reads the public archives and emails the people he has disagreements with to yell at them.

Nobody who signed up for that list expected to be yelled at by some asshole.

Others have followed maintainers of projects to other projects to yell at them and spread lies about them to others.

If you are interacting with FOSS as part of your job then this is unavoidable. But if you just want to contribute and share some stuff, it's better to keep it separate. Don't let some online drama affect your source of income.

I disagree with never using your real name. The internet is a real place. Block liberally, absolutely. Use anon accounts liberally as well.

Yeah I never understand that saying. The internet isn’t a physical place but it’s still a place.

It is fairly straightforward to outlaw this kind of thing.

Extend the same laws that we have about commercial speech to the public, to any speech that is to the public. Not speech that is in public, speech that is to the public at large. Must be warrantied, with due diligence.

You know how people talk in the court, so they don't accidentally lie (and get the punishments that that would entail)? Imagine if politicians (or anyone) had to abide by that when they speak to the public. I have a feeling their bombastic claims (and lies) used to incite and defraud people would be greatly tempered and have more qualifying statements. Fraud, libel, and slander laws restored.

Well, back in my day we didn't have the ability to "block anyone", we just smiled knowing we were the man.

because online they can follow you around the internet and lie about you or otherwise harass you. This is something that has definitely happened.

Also,since they can probably connect you to you real name,who knows what else they might do.

Let’s just be honest.

I won’t use the “U-word” because it usually sets HN on fire everytime it’s used.

BUT

…the conditions are such that maintainers should bargain collectively.

THE CONDITIONS:

- entitled people screaming at you to do stuff.

- corporations taking advantage of you.

- being paid very little.

How on Earth could open source maintainers possibly unionize. What am I missing that makes your suggestion remotely feasible or value adding? Am I a scab if I fork a union FOSS project?

Go ahead and fork the top 50 FOSS libraries and maintain them yourself.

But if maintainers quit en masse. We’d learn to appreciate them a bit more.

I don't want to do that, and I also think many FOSS maintainers are underappreciated.

I was asking about how this could possibly work from a regulation and union rules perspective.

A traditional union wouldn’t work because there isn’t a single employer.

It would have to be a trade or membership association like ASCAP that sets standards, advocates for members and engages with industry.

I had a couple of popular repos. Eventually I just started charging for issues. No payment? Issue closed. Stress went way down. If I see an issue I want to fix, I will fix it, for free or otherwise. But the default is "pay me", which helps set expectations.

The code is still available and free, support is not free.

I hope this method catches on.

I agree this sounds like a reasonable solution, though I can imagine projects with this policy may hear about fewer security issues.

Part of the dynamic is that companies have this sense of entitlement. They see the open source as a vendor. Employees have been told to use the tool, so the employees are frustrated. Because the employer has made it hard to contribute back, the employee is doubly frustrated, and feels stuck between unyielding corporate stance towards open source and unpaid volunteers that can’t support them.

I’m not excusing the behavior. I’ve been the victim of it - the person commenting is often actually in a pretty crappy situation because of their employer has a shitty understanding that open source is about participating, not consuming.

I would never excuse this sort of behaviour, but if you want to understand the corporate dynamic with open source, then you need to dig a little deeper than this imo:

> the person commenting is often actually in a pretty crappy situation because of their employer has a shitty understanding that open source is about participating, not consuming.

The most frustrating thing about using open source in a corporate environment is (imo) that open source maintainers have exactly this same attitude (or alternatively some passive aggressive version of it), even when the frustrated user is from a company paying a 6+ figure support contract. My personal expectation is that no bug that I have, no matter how serious, will ever be patched by an OSS maintainer, regardless of how much my employer is paying them in support fees. So far, this expectation has always held true, even with the more professional operations like Red Hat.

This is frustrating for me, but I at least have the ability to write patches for most of the OSS that I use (if I have to). For people who can’t do that, who are paying big bucks for support, I can’t imagine how frustrated they can get…

> So far, this expectation has always held true, even with the more professional operations like Red Hat

This is different from my experience, this happened around 9 years ago, so I can't even remember the software. But there was some bug that was fixed in a later version of some software. The version in the redhat repo was severely out of date (and we were stuck on an old version of redhat anyway).

I tried to get the new version of the software to build, but all the dependencies were out of date as well, I'd basically be recompiling the entire userland at that point.

Since it wasn't my job, I complained to my manager who just said "why are you dealing with this? Just contact Redhat". They backported the bugfix and released a new version. I looked at the diffs, and it took some real development effort on their behalf. It wasn't just a case of cherry-picking some commits.

Maybe Redhat have gone to shit now, but they definitely used to provide proper support in the past.

All of my recent interactions with Red Hat have been bad. Recently I had to fire them of a project they were supporting because they only wanted to use Red Hat certified container images, the image they were trying to deploy was configured to run as root for absolutely no reason, they refused to fix the image, and they refused to use a non-Red Hat image.

My second most recent interaction with Red Hat involves them sending an engineer to perform an Ansible Tower upgrade, only to find out the engineer they sent had no idea what he was doing, so we ended up teaching him how to upgrade Ansible Tower safely.

However, after thinking about it, I don’t think they properly illustrate the problem I’m talking about. Red Had incompetence is the sort of incompetence I’d expect from certain big enterprise vendors. They don’t have the “check your entitlement” attitude. They have the “we don’t care about you at all” sort of attitude that I would expect from say Oracle or Broadcom.

In my experience at least…

Or IBM, which they now are.

Yeah I keep forgetting about that…

I think the sense entitlement goes both ways. Sometimes maintainers get the wrong idea that their work is above critique because it's open source.

Such that even when presented with reasonable feedback, they balk and snap at the contributor. "Well if you don't like feature X, why don't you GTFO and fork it". For some reason it's okay for contributions to be critiqued but not the projects. Who gave this poor author this wrong idea?

Yes, nothing is free, when I start using an open source project I make some assumptions on what to expect from the project. Based on those assumptions I will invest more or less time learning and integrating the project into my workflow.

The problem arise when my expectations doesn't match the project maintainers expectation.

Ideally every project should announce clearly for newcomers what to expect. Will there be be features, how fast will bugs be investigated and fixed, at what cost.

Leaning on a code of conduct to fix a cultural problem seems like a losing battle. In the sense that it establishes a framework for moderation, a CoC has some value, although if I'm being honest I think the CoC concept is more about signalling than anything else. But this article already hits on the core problem:

We're living in a culture where a large amount of people think that it's OK to be rude to service workers because it's their job. People who don't return the shopping cart because there's no incentive.

I think that engaging a beurocratic process every time you get a toxic comment will in fact not make your job as a maintainer less stressful. I also suspect that it won't reduce the volume of abuse anymore than just blocking/muting abusive folks. If anything, for most first time offenders, they're probably just tilted and telling them to stop is the most productive thing to do. But abusive asshats don't care about your rulebook very much other than to use it against you, so I really think it's not as valuable as it's being made out to be.

I don't know if we can improve the cultural problem. It really did feel, at least from what I can recall, that "netiquette" was stronger at some point. Exactly what was "toxic" was tuned very differently, but that's not the point. The point is that there were SOME baseline tenets that most people expected out of eachother in a lot of situations. These days, it feels like everyone has completely different standards and really long, complex justifications for their standards on what conduct is OK and when. I dunno if that's good or not. All I know is, "don't be an asshole" is deprecated, but its replacement doesn't appear to be ready yet, whatever it is.

So what do we do? Frankly, my recommendation is to detach harder. I know the "just grow a thick skin" bit has gotten stale, but that's not really the point. The point is to try to not be vulnerable. Detach. Block and mute as you need if politely asking people to stop acting like an ass doesn't work. Try not to take it personally; recognize that most people don't actually mean what they're saying. Etc, etc. Changing the world is hard and slow. Changing your own behavior is also hard, but at least you have more personal control over it.

I feel bad for open source maintainers getting burnt out over this. It's a shame. But, it'd be impossible to have all of the amazing upsides of the internet and open source without some coinciding downsides. You have to be realistic to some degree.

I made something I know for a fact a lot of people under 20 use, and the entitlement in the community is really something else when compared to other projects. In this particular project it helps to remind yourself that people are most likely under 20 as you don't let children and teenagers get to your head the same way an adult would.

The internet is a weird place where you'd think everyone is probably around your own age.

Personally I've just learned to ignore negative feelings in bug reports and general entitlement over wanting features.

A pattern I picked up from all of this and even caught myself thinking a few times is if more than 2 or 3 things are not working as it should you'd think everything is broken. You end up with a bug report that is 95% negative emotions about you and your project and the remaining 5% describe what the actual 2 bugs are.

It usually happens when you decide to rewrite something for a better future. You're told to roll it all back rather than fixing what's wrong.

I think it helps to find people in the community that act more like adults and involve them in the project more. They will often help you in return to manage entitlement from other people.

I stopped contributing to Open Source in any meaningful way in 2004 due to the incredible amount of non-stop entitlement and toxicity. I am working on a project with a few other folks and the subject of “to open source or not” has come up a few times, and in principle I think we should open source, but in practice I can do without the meaningless drama in my life.

You might consider a “source available” model a la SQLite. The maintainers there chose to make the code open and freely usable, and you’re welcome to fork it and use it for whatever you want, but they won’t take contributions back. It might be a good middle ground, depending on what your project looks like.

https://www.sqlite.org/copyright.html

My team took this approach when we open-sourced our web app. Apache licensed and anyone is free to do with our code as they please, but GitHub issues and PRs are set to employees only.

But whether this approach makes sense really depends on what you're hoping to accomplish by making your code available. For us, the goals were mostly around transparency and assuring customers that if we went out of business, it'd be possible for someone else to operate our service. As a side effect, it's also nice for hiring since candidates can see exactly what our code base looks like, what kind of feedback we give each other in code reviews, etc.

You can always go the SQLite way and refuse to accept patches: https://www.sqlite.org/copyright.html. Or go further and refuse to accept feature requests, or even turn down bug reports!

The SQLite guy is a master class in ignoring the idiots complaining online. I particularly like this page https://sqlite.org/codeofethics.html

He doesn’t refuse feature requests, indeed he completely revised his development process to meet the mission-critical needs of Airbus or Android, just not randos on the Internet. He also followed Mitchell Baker of Mozilla’s advice to keep developers in control of the SQLite foundation.

No, but you could go further than him and refuse them, if you wanted to.

It is even more toxic in the corporate world.

At least in the open source world being a sycophant doesn't get you anywhere.

It's not toxic. It's not going to kill anyone. It's just antisocial behavior.

You'd think we'd expect antisocial behavior to result from people being physically isolated, unable to pick up on the usual cues from one another and not able to be "policed" by the social group.

You know what else is antisocial? Constantly shouting about how toxic non-toxic things are. That alarmism only feeds knee-jerk reactions and sets people against one another.

Linguistic prescriptivism in the wild, fascinating.

Entitlement is a mismatch between expectations.

Frowning upon entitlement will not fix that.

Instead be clear on what to expect. What is the goal of the project. Do you want users, what you expect from them? What do you offer in return?

This must be clearly communicated even before a newcomers starts spending time learning the project, because then they have already invested time based on their own expectations and assumptions.

The only thing worse than not having any users for your open source project...

relevant: https://polite.technology/preview

polite.technology is a free text under the CC0 license originally penned by Tom MacWright

"This is a book about the social interactions and situations that are the underpinnings of the open source world. It's about how humans collaboratively create software.

This isn't a programming handbook or a guide to using GitHub. If that's what you're interested in, there are links in the bibliography to great resources.

Specifically this is about creating open source software. Open source software, loosely defined, is software that is free to share. Typically, open source software is released under a license that reverse-engineers copyright in order to protect this right to share, instead of doing copyright's traditional work of restricting sharing.

The ramifications of this tweak to copyright are tremendous. Open source software doesn't have to be a closely-guarded secret: instead, it's usually created in public spaces, shared widely, and distributed for free. Since everyone can read the source code and contribute changes back, software projects can become collaborative projects between multiple companies, private individuals, foundations, and even governments, all sharing in the work of creating software and the benefit of having it.

The successes of open source software have been world-changing: the Linux operating system runs the majority of the Internet, the git version control system is the basis for GitHub, and thousands of other pieces of open source software make everyday life possible. On a personal level, open source software and the systems of collaboration it comes with have enabled people to work remotely, make friends, and learn about parts of systems that were previously the exclusive domain of experts.

But that's the ideal. The everyday work of creating things is difficult and fraught - filled with the same social difficulties as any other job, along with unusual new challenges. How do communities scale when they contain differing opinions and styles? How do decisions get made without formal power structures - or does decision-making require the creation of such structures? What about the way that these projects interact with companies who wield the power of commerce, users who have the power of speech, and developers who may have more technical skill than collaborative ability? ... "

rudeness is unacceptable, but there's also the belief that if someone is working on open-source, then any type of a complaint about the software is unwarranted. That actually itself is entitlement. No matter if open or closed source, sometimes customers are going to complain.

>customers will complain.

Assuming they are paying customers and not users. There's long been the attitude that the developer is doing people a favor by not charging for using the software and therefore 'if you find a problem, fix it yourself using the source code'.

Reply on news.ycombinator.com