6 ms·

Toxicity in Open Source Discussions

43 points by thcipriani 4y ago

kyleyeats 4y ago
The only thing worse than not having any users for your open source project...
29athrowaway 4y ago
It is even more toxic in the corporate world. At least in the open source world being a sycophant doesn't get you anywhere.
softwaredoug 4y ago
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.
- AmericanChopper 4y ago
  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…
  - doix 4y ago
    > 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.
    - AmericanChopper 4y ago
      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…
      - fmajid 4y ago
        Or IBM, which they now are.
        4y ago
personjerry 4y ago
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.
- jay-barronville 4y ago
  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.
  - ilyt 4y ago
    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
- crummy 4y ago
  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.
- ilyt 4y ago
  Let me guess, MOBA player?
- bitwize 4y ago
  The crazy homeless man can shiv you for not giving him a handout.
- PragmaticPulp 4y ago
mdekkers 4y ago
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.
- ddulaney 4y ago
  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 https://www.sqlite.org/copyright.html
  - koreth1 4y ago
    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.
- strken 4y ago
  You can always go the SQLite way and refuse to accept patches: https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html. Or go further and refuse to accept feature requests, or even turn down bug reports!
  - Gigachad 4y ago
    The SQLite guy is a master class in ignoring the idiots complaining online. I particularly like this page https://sqlite.org/codeofethics.html https://sqlite.org/codeofethics.html
2h 4y ago
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.
- prash_ant 4y ago
  I hope this method catches on.
- retox 4y ago
  I agree this sounds like a reasonable solution, though I can imagine projects with this policy may hear about fewer security issues.
jchw 4y ago
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.
CapsAdmin 4y ago
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.
aaron695 4y ago
[dead]
digdigdag 4y ago
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?
- breakerofbuilds 4y ago
  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.
deleted 4y ago
[deleted]
kasajian 4y ago
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.
- willywanker 4y ago
  >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'.
pella 4y ago
relevant: https://polite.technology/preview 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? ... " read more --> https://polite.technology/preview https://polite.technology/preview
drewcoo 4y ago
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.
- redivysoft 4y ago
  Linguistic prescriptivism in the wild, fascinating.
breakerofbuilds 4y ago
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.

43 points by thcipriani 4y ago

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

It is even more toxic in the corporate world. At least in the open source world being a sycophant doesn't get you anywhere.

softwaredoug 4y ago

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.

AmericanChopper 4y ago
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…
- doix 4y ago
  > 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.
  - AmericanChopper 4y ago
    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…
    - fmajid 4y ago
      Or IBM, which they now are.
      - 4y ago

personjerry 4y ago

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.

jay-barronville 4y ago
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.
- ilyt 4y ago
  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
crummy 4y ago
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.
ilyt 4y ago
Let me guess, MOBA player?
bitwize 4y ago
The crazy homeless man can shiv you for not giving him a handout.
PragmaticPulp 4y ago

mdekkers 4y ago

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.

ddulaney 4y ago
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 https://www.sqlite.org/copyright.html
- koreth1 4y ago
  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.
strken 4y ago
You can always go the SQLite way and refuse to accept patches: https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html. Or go further and refuse to accept feature requests, or even turn down bug reports!
- Gigachad 4y ago
  The SQLite guy is a master class in ignoring the idiots complaining online. I particularly like this page https://sqlite.org/codeofethics.html https://sqlite.org/codeofethics.html

2h 4y ago

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.

prash_ant 4y ago
I hope this method catches on.
retox 4y ago
I agree this sounds like a reasonable solution, though I can imagine projects with this policy may hear about fewer security issues.

jchw 4y ago

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.

CapsAdmin 4y ago

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.

aaron695 4y ago

[dead]

digdigdag 4y ago

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?

breakerofbuilds 4y ago
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.

deleted 4y ago

[deleted]

kasajian 4y ago

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.

willywanker 4y ago
>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'.

pella 4y ago

relevant: https://polite.technology/preview 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? ... " read more --> https://polite.technology/preview https://polite.technology/preview

drewcoo 4y ago

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.

redivysoft 4y ago
Linguistic prescriptivism in the wild, fascinating.

breakerofbuilds 4y ago

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.