4 ms·

How about the insane entitlement that many devs have when it comes to open source? Getting bombarded with requests and angry emails from people who demand free

How about the insane entitlement that many devs have when it comes to open source? Getting bombarded with requests and angry emails from people who demand free support and bug fixes can burn anyone out. I think Github can be a positive force for change here. Redesign the UI to encourage donations, to encourage people to get involved in project work, to write less hostile issues, etc. If devs and designers can weaponize UI to create addiction, anxiety and FOMO, maybe we can use the same tools for good for once.

fxtentacle 5y ago
This! Several of my github repos now have a disclaimer that says "if this doesn't work, don't send me insulting emails" It's especially bad if a big company links to you from their tutorial or in their add-on catalogue because then some of their customers will feel like your open source is part of the commercial offering that they bought. So then you're forced to do open source support for entitled aholes and someone else is cashing in on your work.
- matkoniecz 5y ago
  > So then you're forced to do open source support for entitled aholes I had no opportunity to do it so far, but what is wrong with simply banning such people and closing tickets (with note that this issue is closed for rude behavior, not WONTFIXed)? I would certainly not feel forced to support them.
bawolff 5y ago
I wonder if this is a back-firing of the push for people to be "nice" and "professional". Open source maintainers used to have the sterotype of being rather harsh, and basically telling people to f off if they had stupid questions, didn't RTFM or didn't follow cultural norms. And dont get me wrong, there's a lot wrong with that, but maybe it was also that way for a reason.
- fxtentacle 5y ago
  Agree. I'm active in some communities that are unfriendly if not outright hostile towards newcomers. I'm sure they lose a good amount of potential contributers that way. But the few newcomers that remain are highly motivated.
  - pteraspidomorph 5y ago
    Now that I think of it, that's also my experience. If I really need a project to do whatever (and can't implement the feature myself), I shut up, let the horrible attitude wash over me and put hours of effort into testing and providing helpful information, and maintainers usually mellow out eventually. If I hadn't done all of that work, the maintainer would have had to do it. Sure, they're much better equipped to do it and can probably do it in a quarter of the time it takes me, but multiplied by fifty tickets... Oof.
- watwut 5y ago
  Nice professional people have large backlogs ignored for years, say no to requests or delay work. Otherwise said, being nice and professional does not imply you will immediately implement every feature request or bug report. It does not imply you will not block/mute abusive people.
  - beckingz 5y ago
    Being nice and professional just means smiling as you get a dumb request and being open about your intent to prioritize the request alongside everything else.
- planb 5y ago
  You can be harsh in a nice and professional way though.
  - kjs3 5y ago
    I can't second this enough, and it's the other side of that whole "put your code on Github and use it as a resume". If I'm looking to hire someone, and I look at their Github repository and it's full of nasty, unprofessional responses to PRs and such, it's a pretty safe bet I don't need that attitude on my team.
marcus_holmes 5y ago
I don't think some UI tweaks are going to fix this sense of entitlement. Modern devs in those ecosystems that use a lot of dependencies see their jobs as plugging together lumps of other people's code. There's a very strong "don't re-invent the wheel" vibe - the first thing any dev does when presented with a problem is look for an existing code base that solves it. This means that people have their entire jobs on the line relying on other people's code. If the OS library that you found has a bug in it, and your project depends on that library, and your manager is shouting at you to get it fixed, then you're having a bad day. In an ideal world, "fixing the bug" would mean diving deep into the library code, finding and fixing the bug, and submitting a PR to the maintainer. But this can be beyond the dev's abilities, especially when the only kind of coding work they're done is plumbing together dependencies. So they only have two options: try and get the maintainer to fix the bug, or switch dependencies (which might take longer, and possibly have other bugs). There's a real sense of "I'm using your library, giving you cred, so you need to fix it for my use-case" that I've seen. It doesn't help that dependencies are free (as in beer) - it's a well-known truth that people don't respect things that are free. I think for all of this to change, we need to scale back the dependence on dependencies, audit dependencies properly for security and sustainability issues, and pay the maintainer. If there's any change needed in Github, it's that Github needs to start charging a fee for every download.

fxtentacle 5y ago

This! Several of my github repos now have a disclaimer that says "if this doesn't work, don't send me insulting emails" It's especially bad if a big company links to you from their tutorial or in their add-on catalogue because then some of their customers will feel like your open source is part of the commercial offering that they bought. So then you're forced to do open source support for entitled aholes and someone else is cashing in on your work.

matkoniecz 5y ago
> So then you're forced to do open source support for entitled aholes I had no opportunity to do it so far, but what is wrong with simply banning such people and closing tickets (with note that this issue is closed for rude behavior, not WONTFIXed)? I would certainly not feel forced to support them.

bawolff 5y ago

I wonder if this is a back-firing of the push for people to be "nice" and "professional". Open source maintainers used to have the sterotype of being rather harsh, and basically telling people to f off if they had stupid questions, didn't RTFM or didn't follow cultural norms. And dont get me wrong, there's a lot wrong with that, but maybe it was also that way for a reason.

fxtentacle 5y ago
Agree. I'm active in some communities that are unfriendly if not outright hostile towards newcomers. I'm sure they lose a good amount of potential contributers that way. But the few newcomers that remain are highly motivated.
- pteraspidomorph 5y ago
  Now that I think of it, that's also my experience. If I really need a project to do whatever (and can't implement the feature myself), I shut up, let the horrible attitude wash over me and put hours of effort into testing and providing helpful information, and maintainers usually mellow out eventually. If I hadn't done all of that work, the maintainer would have had to do it. Sure, they're much better equipped to do it and can probably do it in a quarter of the time it takes me, but multiplied by fifty tickets... Oof.
watwut 5y ago
Nice professional people have large backlogs ignored for years, say no to requests or delay work. Otherwise said, being nice and professional does not imply you will immediately implement every feature request or bug report. It does not imply you will not block/mute abusive people.
- beckingz 5y ago
  Being nice and professional just means smiling as you get a dumb request and being open about your intent to prioritize the request alongside everything else.
planb 5y ago
You can be harsh in a nice and professional way though.
- kjs3 5y ago
  I can't second this enough, and it's the other side of that whole "put your code on Github and use it as a resume". If I'm looking to hire someone, and I look at their Github repository and it's full of nasty, unprofessional responses to PRs and such, it's a pretty safe bet I don't need that attitude on my team.

marcus_holmes 5y ago

I don't think some UI tweaks are going to fix this sense of entitlement. Modern devs in those ecosystems that use a lot of dependencies see their jobs as plugging together lumps of other people's code. There's a very strong "don't re-invent the wheel" vibe - the first thing any dev does when presented with a problem is look for an existing code base that solves it. This means that people have their entire jobs on the line relying on other people's code. If the OS library that you found has a bug in it, and your project depends on that library, and your manager is shouting at you to get it fixed, then you're having a bad day. In an ideal world, "fixing the bug" would mean diving deep into the library code, finding and fixing the bug, and submitting a PR to the maintainer. But this can be beyond the dev's abilities, especially when the only kind of coding work they're done is plumbing together dependencies. So they only have two options: try and get the maintainer to fix the bug, or switch dependencies (which might take longer, and possibly have other bugs). There's a real sense of "I'm using your library, giving you cred, so you need to fix it for my use-case" that I've seen. It doesn't help that dependencies are free (as in beer) - it's a well-known truth that people don't respect things that are free. I think for all of this to change, we need to scale back the dependence on dependencies, audit dependencies properly for security and sustainability issues, and pay the maintainer. If there's any change needed in Github, it's that Github needs to start charging a fee for every download.