Easily the worst part of the job is toxic users who hop on to issues demanding you implement them immediately and belittling your planning ability. Worse when you were planning on implementing it soon anyways, but now if you do it's "rewarding" their behaviour (in their eyes at least), and they become invigorated to go and spread their toxicity even further. Alternatively, you can hold off on implementing it until things cool down, but then all the nice users who have been patiently waiting get screwed.
I'm forever grateful that I actually get FAANG salary to do this -- I wouldn't keep it up if I was getting the little-to-noting many FOSS contributors get.
I’ve painstakingly implemented debug logs and carefully prepared issue templates yet I still get these “does not work (EOM)” (effectively) issues. In the back-and-forth that ensues, sometimes it takes three or four attempts of asking the same question to get what I need, possibly separated by a day each time. Sometimes they’ll eventually realize what they missed was documented in the first place and would have been obvious if they followed the issue template to begin with.
Then there are users expecting me to help with an incomplete, out of context code snippet, or quite the opposite, with their 5k LoC repository, hoping I’d fish out the 50 or 5 lines that are actually relevant on my own.
These users are not outright assholes, so it’s somewhat harder to justify passive-aggressiveness against them. And they may have actual issues locked behind three or four back-and-forths.
(For the record, I got maybe a total of $10 in donations from thousands of hours of FOSS work. Actually a high profile project I worked for did receive sponsorship, but nothing went into my pocket for obvious reasons.)
The site could try to be as polite as possible, explaining that your time isn't free. You're not there to cater to them or give them free labor. You are interested in bug reports but only if they contain a minimal complete repo and explain what minimal means, what complete means, and what repo means. There could be common links like closedforreasons.org/mcve closedforreasons.org/rude closedforreasons.org/nofreelabor closedforreasons.org/notyouremployee closedforreasons.org/outofscope closedforreasons.org/askingfortutorial etc...
It will certainly piss some people off but maybe after a hopefully short while it would be seen as a gentle nudge by everyone that's been through it.
Source here: https://github.com/andrewaylett/closedbecause.xyz, suggestions for reasons welcome, PRs even more welcome.
(Joke obvs. Sorry, couldn't resist.)
For example; the Angular repository has a "stale bot", which closes and locks the issue after a certain amount of time of inactivity.
This sounds great on the surface, however it's insane in practice. The users constantly need to recreate duplicate issues, as the original issue is locked. Most of the duplicates are not linked, so maintainers can't determine which issues are duplicates. And it also increases the friction of users notifying that the issue is still occurring.
Basically the result of "stale bots" is more duplicate issues and less engagement on old issues (as they're locked)
Moral of the story, use bots in moderation
That speaks to another issue of open source - it's more common than not for a user to report an issue with no intention of following up, nor helping to triage (let alone contributing). Drive-by issues are noise and take precious time away from maintainers. There again, stalebot steps in to help. YMMV but my personal experience is that we don't get too many reopens, and we don't get too many duplicates from closed issues.
In addition, it's just plain rude. If you don't have time to fix it, that's valid, but what makes you presume you community has time to deal with constant bot reminders on order to keep the bug open?
You don't have to deal with it, that's fine, leave it there. Or get some more maintainers on board to help with triage.
We owe you nothing.
You owe us nothing.
Play by the rules set in the project, fork, or don't play. The choice is yours.
Multiple times have I filed an issue, that collects many people's "me too" and workarounds for over a year. And every month, stalebot comes and mentions everybody, so that I have to go and type in that stalebot command.
Until one day I give up, because I don't want to get those notifications anymore, or because I move to a more active project. The issue gets closed even though multiple people are affected, and all they can do is open a new one, link to the workarounds somehow, and take over the duty of fighting the bot.
Why make everyone do this? You say you don't owe me anything, but that's different from taking active step to hurt your community.
(and by you I mean stalebot users like andrew_)
I strongly disagree. Follow-up and collaboration are great, but someone taking the time to write a decent bug report is also valuable.
"library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
> "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
They could still be a hint that the documentation or reported error could be clearer.
IIRC, Gentoo does this, and my first patch was rejected multiple times. But because it was a bot that responded,I just felt like I had made a mistake, whereas with a human in the mix I probably would've asked a bunch of a questions and wasted her time and mine.
If you can't take a few extra seconds to enter information in a template, why on earth should maintainers donate their time to you to triage what you're reporting?
As for the original point: I suspect every developer has encountered a bug in their code that couldn't possibly be caused by something, but ultimately was. Getting all the information requested up front in a regularly structured way, even when we think it's irrelevant, can make tracking these problems much easier.
1. Many years ago (I only saw this here and there myself) a particular essay on Asking Smart Questions that would sometimes be linked whenever a suboptimal(ly worded) query was posted on a mailinglist or newsgroup or forum. http://www.catb.org/~esr/faqs/smart-questions.html
It's quite the wall of text, because it's thorough. This produces an unfortunate effect: everyone who reads the article, digests it, and applies what it says "disappears" into the bigger picture of people who ask good questions; while people who don't have the time to read an issue template properly have their eyes glaze over and they add the URL to their mental list of "evil entitled webpages that demand too much of my time" and go on filling the internet with noise.
TL;DR, a webpage this big: --> <-- works for just about everyone, but the "TLDR dropoff" is disillusioningly exponential beyond 0 bytes.
2. Taking as an example the common use case of people at the stage of learning about software development, there's a specific point in that learning process where everything seems possible... too possible. Of course it's possible to merge the Linux and Windows kernels. Of course it's possible to "just rewrite the codebase" to make the two mutually incompatibly designed components work together. One place that comes to mind that this sort of thing can concentrate is in game modding communities. It's not uncommon for there to be one or two "dev" type positions that are basically hacking it but have enough figured out to be competent, with a bunch of other users surrounding them that have no idea what they're doing and asking for the impossible. The net result is 500+ issues or forum posts, with only one or two ((ahem, achievable)) items slowly being acknowledged worked on, and the rest basically ignored for the sake of efficiency. The people that all have no idea what they're doing collectively think each others' ideas are great and if only the devs would actually listen to them the project might actually get somewhere.
TL;DR, accessibility and intuitivity are hard.
3. There are thousands of devs out there in situations where they simply don't have time to answer every possible question. They may honestly have a massive workload and are doing triage on top of that, they might be maintaining a minimum-viable free user support forum for a commercial product, they might be a time-poor OSS contributor, they may have laziness issues :P (independent of any other points here), they may have communication issues, ...
Again, there are thousands of devs out there who would be looking for a TLDR for their circumstance.
A large proportion of those that choose to use a template-as-a-service website to optimize their time can only pick from the best possible option from the available choices, even where the choices that are available aren't an exact fit, because this is a common pattern when optimizing.
Considering all of the above together, *you are going* to have circumstances where angry users will feel snubbed by suboptimally-chosen messages, and the challenge with a site like this would be to figure out how to reduce the chances that...
- almost-but-not-100% templates are chosen by time-poor devs for lack of better options, which will lead to poor reception of the site by end users
- the message is too long or complicated for the user to read and act on (can the user read English easily? Do they have intellectual issues (autism and ADD are particularly common, and drastically underaddressed) that make it hard for them to break work down into chunks and focus on it? Does the text of the template help the user to feel supported so they can calm down and focus on the work they must now do? Etc)
A couple of other points:
- Analytics would definitely be a good idea, as would actually looking through the supplied referers (that you can actually open).
- An "I didn't find anything appropriate for [URL]" option with a free-text "description" box would deliver a lot of helpful signal to further refine the options available
- Editing everything on GitHub or similar would make it straightforward for people to simply just contribute direct improvements (the "nothing appropriate" submission box would not be public)
Example: for GitLab we stopped using the repository that used to host the code for GitLab CE. All issues were closed, and when you create a new issue there's a template active that basically says "Don't create issues here". In spite of that, people still create issues here, and in some cases don't even bother changing that template.
But it's worse than that. Most people do not have the reading fluency to read more than a few words in a sentence without getting frustrated and confused. If your work peers and social groups consist of the 3-5% of people who aren't in that category, it can be easy to forget that.
Any time you can make something's function clear with one or two words and design, opt for that over explanation.
The average user might not be super invested in the application, they just know that something doesn't work, which is frustrating. If their only outlet for that is a bug report, the developers get overwhelmed with bad bug reports and users get the expectation that the developer is going to fix all their problems for them.
If the outlet is a feedback form instead, maybe the user can feel listened to in a small way and move on. The developer doesn't have to sift through a bunch of issues, they can just follow up if there seem to be any hot-spots that are causing a lot of frustration.
You need to guide people to do the right thing based on the interface itself; people overwhelmingly don't read instructions.
Unless you know you're dealing with a very specific subset of the general population who loves reading, design around things that don't need to be read.
So (1) Scrape the old, closed issues to a static website, link it from README.md. (2) Disable Issues in GitHub's repo settings.
Part 1 is somewhat complicated, because issue-to-issue linking.
I feel that it must be even more annoying when you're offering free great work to these people. But I believe it to be a fact about all users (I include myself, though I'm trying to work on it).
The rest of us feel bad doing that, especially towards someone trying to use something we built ourselves that holds some measure of our own pride or even self-worth, it feels closer to obligation. So we waste our time trying to help the characters that deserve our help the least, and we learn to develop a resentful version of that trait over a period of decades.
But then, a good bug-reporting system should be able to do such filtering?
I'm wondering if detecting abusive communications is/could be part of it, bit of ML seems like it would fit, even just some Bayesian filtering might do.
One could also train an NN to recognise images of the app (or simpler: OCR|grep) and require a screenshot with any submission.
But I guess automated triage mightn't be the best route. It seems very much a delicately balanced people problem.
It's even better if you can get a bot to automatically reply and close it.
Not a foolproof way, but add a string in your Issue Templates that is required to be there, e.g. <!-- AUTOMATIC-CHECK -->.
If this is not present in the issue, the GitHub action just closes the issue with a message to please fill in the template if they wish to create an issue.
Doesn't catch nearly everything, but should get some and it's easy to set up. Could be interesting to go further with the idea and maybe check if each section contains text or something like this, hmm...
What helps immensely (and I saw this in the Geyser MC project), the software can produce a snippet with all info the devs want with one command, and it even exports to pastebin taking out sensitive info. If you paste such a link in their Discord it even makes an overview with syntax highlighting in the chat. That really helps a lot on my (bug reporter) side. And thus on the dev side.
One of the great things with Steam when I started running it on Linux was it's debugging info that gathered details of your system so you didn't have to.
This is still the case. Every KDE application has the menu entries Help → About $APPNAME and Help → About KDE which both show the relevant version numbers. I'm overwhelmingly certain this feature never went away because I am on a rolling distro and upgraded through pretty much all versions and I figure I would have noticed the absence of these menu entries.
> then the bug report tool asks up front what version you're using
That's incorrect. The menu entry Help → Report Bug… opens a dialog with version information that has a button Launch Bug Report Wizard which produces a link like e.g. `https://bugs.kde.org/enter_bug.cgi?format=guided&product=kon...`. Consequently in the bugtracker, the available information is already filled in.
By the way, this post is an example for the bullshit asymmetry principle, and I resent that I had to spend a magnitude more time to correct your misinformation than it took you to produce it. Please be a better netizen.
There was a change, it was unhelpful. There were reasons, it was to do with changes in versioning on plasma frameworks - I could look up the details, but that isn't really important a few years hence.
The jist of my comment is that structures within an application can help us non-programmers to make useful bug submissions; I cited 2 examples from my real life experience.
Hopefully we agree on the basic premise I set out at least?
1. Create crappy bug report and move on quickly to get things done or:
2. Do not create a bug report and move on immediately, to get things done
I try to file whenever I can but when it's getting late and I want to go to bed I choose option 1 sometimes. Maybe I should choose option 2?
For example, take the Nextcloud bug filing template on GitHub . It's quite a long read but sure, worth the effort for free software I agree (Nextcloud is my favorite project, my life is in there, on my server)! However, I may not know exactly where these things are:
#### Web server error log
<summary>Web server error log</summary>
Insert your webserver log here
#### Nextcloud log (data/nextcloud.log)
Insert your Nextcloud log here
#### Browser log
Insert your browser log here, this could for example include:
b) The network log
Login as admin user into your Nextcloud and access
### Server configuration
\*Nextcloud version:\* (see Nextcloud admin page)
\*Updated from an older Nextcloud/ownCloud or fresh install:\*
As said, the Geyser MC project  can do exactly this and to me it is a game changer, the whole process was fast and pleasant and it was easy to test the automated builds they made in the branch based on my issue and report back in context on GitHub. Pasting the JSON their report feature generates into their Discord channel together with your question and their ability to just !docs/something point you to relevant docs with a small command feels like magic. I found the whole process inspirational.
I love all FOSS devs. You are my heroes.
First of all, I applaud your proper use of the semicolon in a sentence. As someone who should probably step away from my computer a lot more though, I've got to disagree that "it's getting late" isn't a valid excuse, because I use it all the time and I mean it when I say it (i.e. it's 4am and I have to wake up for work in 6 hours).
I definitely wasn't intending to be snarky, my compliment was genuine. I don't see people use semicolons properly in sentences often, or much at all outside of coding. I meant no offense, I was giving you an honest compliment.
I really don't want to make it later for devs that give me so much. I'd be ok with: "Closed: Too little info" from a bot. I may decide to have another crack at it later when I have more time.
Edit: Btw, I'm using software for fee but, I'm also beta-testing for free. It's not just a one-way street: "I derive value from a free product so I should never complain." Is that really true?
I also invest time beta-testing (some times for products that make money on support or are open-core or are a gateway to paid software). Sure there are trolls, but there are also many users that make crappy reports that really want to help but just don't understand how (or why their report is a waste of everyone's time).
Assuming you're talking about a beta release for some open source software package, versus a full release, I don't think the distinction matters. You're using software that you got for free. It doesn't matter if it's beta- or release-quality. You aren't entitled to different/better support for it just because the developer chose to put out a version they admit isn't quite release-quality. You're entitled to exactly the same amount of support as for a release version: none whatsoever.
> "I derive value from a free product so I should never complain."
I think that's framed the wrong way. I do agree that you should probably never complain about something you got for free; that smacks of undeserved entitlement. But constructive criticism and useful bug reports are (usually, depending on the maintainer) welcome.
 A developer might put out a beta version for a variety of reasons. One reason, yes, might be because they intend to jump on support requests faster in order to shape things up for a proper release. But another reason might be because they simply wanted to share with people as soon as possible.
There is a difference between not complaining vs raising issues constructively and valuing the maintainers time at least as much as you value your own time.
The modern version of "Boxer the work horse should work harder".
there's a game I used to play fairly often before updates simply broke it. like mission items were replaced with random fires floating in water. many users with the same issue reported it, and some like me even provided a save (which was never even downloaded)
all such tickets were closed with "cannot reproduce"
I'm not (their) tester, I don't have time to fully reproduce issues step by step, and I don't have access to a debug build anyway to figure out the bug trigger condition
"does not work" is the best I can say here.
If not then I can see the reason for your frustration, however it is not the same as free software being worked on (at least partly) by volunteers receiving the same lack of effort (or in signal's case nastiness) in bug submissions.
I’ve gone to a few GitHub repos to report bugs only to be met with a novel length template and just left.
Got no issue following a template to provide enough info to help solve a bug. But damn nothing worse than having a giant template with 20 questions.
Generally speaking, I don't even bother to file bug reports anymore. 70% of the time my issue is already in your issue tracker, sometimes has been for years, and nothing has been done about it despite multiple users giving you the logs and whatnot you've asked for anyway. I could be all "me too" in a vein attempt to convince you you really should fix this thing, but you're just as likely to be annoyed by the complaint and further deprioritize it in your mind.
Can you expand on the last bit? Is it common for sponsorship not to go to the actual developers working on the project and getting eaten by middle layers of bureaucracy?
That could lead to some perverse incentives, but it points in the right direction. Some "mechanism design" / "reverse game theory" needs to be applied, to turn the problem of frustrated users into a net benefit for the software, rather than escalating the conflict between developers and users.
For example, if a user provides incomplete information about a bug, you could respond with a message like:
"Thanks for your interest in the app and the information you have provided so far. We're currently deciding on bug fixes that will be in the next release, which should come out 3 months from now. Our decision will be influenced by the number of votes for the issue, the clarity of the bug report, and the amount of money pledged. Please head over to our forum to find other users of the software who might vote for this issue or might provide the missing information, and head to our Bountysource page to pledge a financial incentive for the fix."
Over the last 20 years, I have received more than my fair share of bug reports just like this from well paid, trained, educated, internal engineers who's entire purpose is to support our software product.
When I complain to management, I get "does not play well with others" type comments.
Many developers/admins use both FOSS and COTS, and feel the same low-effort interaction with upstream is okay in both cases. It's possible to educate a small number of your users (and to a some extent, you should try - for example your post here is a small step in that direction!), but that work is even lower-reward than answering those half-baked reports.
To deal with low-effort, good-faith user reports, in COTS scenario, you'd hire a support/TAC person (a team, eventually). For a popular/accessible FOSS project, it is possible to have something similar on a volunteer basis:
- set up IRC channel/slack/forum/mailing list for that;
- display a prominent banner asking to "please try support forum first" on your bug submission page;
- encourage people who want to contribute, but are not quite acing your codebase (yet), to hang around in the forum, help others.
However, there's this uncanny valley of somewhat popular, mostly solo maintainer projects where you get a steady stream of tickets (say one or two a week) yet there's no community to speak of, so everything falls onto you. It gets pretty annoying when you have a couple of these uncanny valley projects.
And this can happen on HackerNews too! Here is a thread in the last week where 50% of posters from HackerNews were berating Microsoft for open sourcing all of VS code, but not open sourcing one of their free language servers (calling them selfish, anti open-source e.t.c.). I think this is the exact same sentiment.
So Microsoft open sourced all of VS Code, but didn't want to open source the Pylance language server (a separate product which is installed separately as an extension) which they provide as a free (as in beer). This is because Pylance is also used within their other (charged) offerings such as full Visual Studio and is a differentiator from their competition in the premium space. Also they have hinted that it includes some proprietary secret-sauce that they don't want to make public.
Bear in mind that Microsoft is making VS Code free and open source... here are some quotes from the thread:
> I find it what they are doing to be dishonest [...] the consequences of their actions is that people who dislike them will talk bad about them.
> [Microsoft] have the right to be two-faced about their open source policy, I have the right to speak about how I think it's bad to do so.
> They should please stop acting like they are the second coming of christ for open source [...] they are misleading their users.
> Microsoft proved that they only care for OSS [...] because it enables them to spy on coders and their code to develop proprietary and closed sourced spins for software development product. The OSS community got served.
> Microsoft always does this, they fool people by pretending they’re in favor of open source or make something free but it’s just a trick used to bait and switch people into the proprietary anticompetitive Microsoft ecosystem.
> Seems like Microsoft is back to pissing in the public pool.
Also, a megacorp is not a person (no matter what the law may say).
Being abusive towards individual developers should not be tolerated, but leveraging fair or unfair criticism towards an amoral entity? Eh, whatever floats your boat.
Or is it just 'be nice to developers in small companies, but you can say anything to developers in big companies'?
The company paying $10k can't change vendor overnight so it's in their best interest to stay in good terms. Also in his company, the guy you're talking to don't want to be "the guy who pissed off that key vendor".
You don't have to and shouldn't respond in any specific time period. Even if you're the sole maintainer of a critical project and you imagine the world wants your head, the world has to wait sometimes.
However, users may abandon projects where support tickets go untended, maybe even writing a post about it in the process, so try to respond when you can, unless you've abandoned the project.
As a representative for a FOSS project or even a bystander commenting on a PR, respond professionally and succinctly.
If you shouldn't accept a PR, don't.
If it's a request that seems hostile to the project, and you have time, either leave it for a little while to cool off, try to serve it with professionalism without getting off-topic, or at worst close it.
If needed, add a "code of conduct" so that you can "encourage a pleasant and productive environment by responding to disruptive behavior in a fast, fair way". Note that instituting one before it's needed, while seeming proactive, may put off some users.
If you screw-up, apologize briefly, then fix it or move on.
Large corporations (which the $10k/mo user probably is) on the other hand calculate updates in months or even years.
My company also has a very large customer that asks us to implement something "whenever possible" and if we need 2 years they are just happy we did it. Why? Because they have a long update cycle. It's not really important if it's in the next release because they might not even install that but wait for the release after that.
The issue that undermines you’re (mostly correct) observations on slowing moving enterprise, is that they’ll often adopt technology before knowing if it will even work the way they want it to. So when it comes time to implement, you’ll find things that don’t work as described, often accompanied by some years old issue on their tracker which basically say “we might get around to that some time”.
“Enterprise grade” proprietary software is usually terrible anyway, so still prefer open source for the reason that I’m able to write my own patches for it (which I often do). But I find the open source attitude toward fixing issues, in software that your customers are actually paying a lot of money for, incredibly frustrating. There’s a particular maintainer on a project that I use a lot at work, and anytime I see his avatar on the forum while trying to debug an issue, I instantaneously know that my whole day is about to be ruined by some of the least helpful advice you could possibly imagine.
I'd suggest that it's more a combination of: the volume of users that now have access to the world's most popular git hosting service is vast compared to the number of people who can usefully contribute, the ease with which maintainers can be contacted through it and the "friendly by default" stance that most maintainers take on a platform where your stars are more valuable in the real world than your CV.
Personally I wouldn't want a custom feature just for me. Because I know it'd likely be poorly supported and sometimes break. Because that's how it's been when I've been on the other side of that.
No, please don't think like that.
Implement what you see fit when you planned to do it and you can ignore this.
1. You don't know how "toxic" people really are. Some of them are nice, but just put no time/understanding into their internet communication. They write and forgot what they wrote a minute later.
2. If they really need to learn something, talking to them politely "Thanks for the suggestion but...", "Could you please..." etc. will help over time. Not doing something in the fear of rewarding their behaviour is way too complex to understand.
A bit of a cop-out, IMHO. That's also true of real-life interactions: most people you'll talk to, you'll forget about 5 minutes later. I honestly don't remember if I said anything in particular to the corner store lady just yesterday, and I see her every other day. If I was a jerk to her, putting in thought or not, I was the asshole, final. Seriously, it's not that hard not being an asshole, just... don't be.
> 2. If they really need to learn something, talking to them politely "Thanks for the suggestion but...", "Could you please..." etc. will help over time. Not doing something in the fear of rewarding their behaviour is way too complex to understand.
Sure, treat people with respect. However, I'm not convinced it would be that guy's responsibility not to hurt someone's feelings, especially when that person was a jerk in the first place. I don't think we owe respect to someone who was disrespectful. The whole point is that dealing with it is a chore; having to take the time to educate people on their own behavior doesn't make it easier. I just think it shouldn't be _expected_ of maintainers to have to deal with it at all: simply closing the issue or ignoring the request should be seen as a fine response to asshole behavior.
The I read the Flappy Bird's creator story, I decided to stop reading the reviews all together, it's just too much stress. I'm sure a lot of users (the silent majority) appreciate and find the app useful.
> why doesn't the app do this? why is it free? are you selling our data?
These are all valid questions, in my opinion, especially the last two. Some of them could easily be answered in a FAQ section.
And no, I almost never leave reviews, so I am not one of "them".
We regularly get people giving us one star reviews and telling us the app is shit because it's not translated into Japanese, Korean, Dutch or Norwegian etc. I mean we'd love to translate it into all these languages but Norway isn't exactly the world's most dangerous country so not our main priority. We try to reach out to every user who contacts us no matter what and sometimes we send people the details about how easily to help is translate it if they can - but the usual answer is abrupt, unhelpful and dismissive.
I used to be in non-main-stream politics, and we had the same problem - people coming into the group who were toxic and made our lives hell. It took me far too long to realize the following:
Freedom of speech does not mean that individuals and private groups have to tolerate asshats. It's a fallacy that many, many, far too many, progressive groups and movements fall into: this feeling that we "owe" people to hear them out. And that we "owe" people to let them sit at the same table with us.
You are not the government or a hegemonic group/platform. You don't owe toxic people anything. Ban them, without remorse. Have a rule for it - obviously - but for the most toxic behaviors don't even give them a warning. What do you have to lose - a few asshats out of hundreds, thousands or tens of thousands of users?
And no, it's not censorship. Not everything is censorship. Telling idiots and asshats to STFU or GTFO isn't censorship. And a lot, and I do mean A LOT of problems that online communities and even real world politics have is connected to just not telling people the simple word of "NO".
I would have a policy of not allowing feature requests, only bug reports. Their demands gets immediately deleted. Either report a bug or GTFO - and make this the norm!
There's also the "polite" feature request, that's actually helpful. For example, a user wants a feature, and they ask if the developer would be willing to accept a pull request implementing that feature. I think this is respectful and better than sending the pull request right away.
Sometimes I will run into a businessperson, on our side or the other side, who loves to send follow-up messages, or even makes calls, demanding progress reports or turnaround times. Almost never do these messages have even the slightest effect on how quickly I get to a job, or finish it. I have a to-do list, a calendar, and a list of priorities. Their content-free follow-ups affect none of them, unless it includes genuinely new and relevant information. Very, very, very rarely does an ongoing deal slip my mind.
It may be that I was right in the middle of finishing a turn of an agreement when they interrupted me. I had no way to know their message wasn't reporting some important new development in the negotiation. Having stopped to check, I've broken focus, and will probably take longer to finish what I was doing.
But from their point of view, they're reinforced every time they send a low-effort follow-up message and see progress a relatively short time later, whether the two were causally related or not. Even if the message actually delayed delivery. This leads to yet more follow-up messages, both later in the current deal and in other deals. It leads to disappointed expectations when mashing the lawyer's button doesn't make them scribble faster.
Anecdotally, I see this most from people with strong sales backgrounds. Either way, I almost always find it worthwhile to cut it off preemptively, by making it very clear that I'm an organized professional, and not a rower in their galley. I have threatened to fire a client for putting me in their CRM for automated follow-ups. Things got much better, for both of us, from there.
You must, in your own mind, depersonalize the requests and translate them into polite-speak. You know better than I that people who complain about software are usually unaware and frustrated. If they knew the whole picture and hadn't just encountered limitations in the software, maybe they'd be nicer.
The risk is that your resentment could lead to wanting to delay an improvement just because you want to disincentivize toxic demands.
I wonder if you have any tips or advice for other people out there maintaining FOSS projects who are struggling to get paid for their work.
How can a person in that scenario move closer to what you've got going on?
A second path is to join a faang company that does OSS work, specifically on a team that does so. You could join facebook on the react team, google on the chromium/android/go team, etc etc. In all of those teams, you'll probably be a small cog in the machine for a while, but if you persevere, it's possible to create an adjacent project that you own. It's much easier to split out into your own company-paid-for OSS work from a team that already does OSS work. This option is unquestionably the easiest path. It's still not easy.
A third path is to build something that is valuable enough to be acquired, but coincidentally is open source, and then make it remaining open source a condition of being acquired. Zulip managed this route when dropbox acquired them, and there's a few other examples, but this is a very hard route.
Notice that none of these examples are great for most open source projects. Those options mostly require you to change the OSS projects you work on from what you want to something a faang wants you to work on.
To get paid a faang salary working on your own project of your own invention is practically impossible without incredible luck, or being a principal engineer (i.e. guido getting paid by google to work on python, rob pike to create go, other examples certainly exist).
My recommendation? If you want a faang salary to do oss work, but are okay compromising on the project, pick the faang company with a project closest to what you want to do and get hired for that oss project specifically.
If you'd rather work on your oss project than have a faang salary to work on someone else's project, then that's great! You have the passion to work on your foss thing, and that's a good sign. Keep working on it, and understand that your chance of making any money is almost nil.
"This dumb library doesn't left pad correctly when I'm standing on my head. FIX THIS IMMEDIATELY or I'll change to an alternative library and leave a 1 star Yelp review! What kind of clueless amateurs are you? You call yourself 'developers'???"
Profit and user freedom are two different priorities. Sometimes they are compatible, more often they are not.
I am not at all money-driven; my current income is about €600/month, which is not much but a sustainable where I currently live, and in return I can work on open source/free software as I see fit. It's not what everyone would choose, but for me, it's good trade-off, right now away.
I wrote a bit about this over here last week, but I think we really need to think more about money instead of treating it as the devil.
I'm not sure how many of these things really have a toxic community per se. Instead I just wonder if you could more correctly say they have a "large community on the internet, which is usually caustic no matter the topic at hand."
What matters is 1) how you deal with things when someone is having a bad day (things can either cool down or escalate), and 2) how you deal with people who seem to be having bad days almost every day (i.e. assholes).
If you don't do anything then all communities will gravitate towards toxicity; simply because non-assholes will get tired of assholes and will stop coming back, and then all you're left with are ... assholes, and people with above-average patience.
They don’t see their own toxicity. If they see the roadmap and their desired feature X isn’t there, there will just be screaming about that.
Edit: Or something like kickstarter, if enough people pledge for the issue it gets priority on roadmap.
Edit: I looked up if software is being developed on patreon and... so much NSFW stuff.
If most users have wanted X for years but the developer instead spent her energy implementing Y and Z that noone else cares about, that begs questions like how are features prioritized ("based on what I want to work on" is a valid answer but needs to be explicit) and who the software is for ("me but sure you guys can tag along and use it for free I guess" is a valid answer but needs to be explicit)
Maybe some of those users who have wanted feature X for years would be happy to pool some cash to make it happen if given the opportunity.
Honestly, it doesn't even need to be explicit, they just need to not be actively implying otherwise. (Eg, like gnome/gtk from the sibling thread.)
Building a tool that works juuuuust enough for people to set it up and start relying on it, and then never ever fixing the most salient and impactful bugs because "people aren't entitled anything after all" is just wrong.
It would be much more honest to state up front that said tool should not be relied on for any use beyond one's hobby, that it will not be supported, and that the whole package is just "up there" for anyone interested, without any guarantee. And no, having that written in the default LICENSE file is not sufficient.
2. "Aight I step up to maintain the feature"
I seriously don't understand the expectant attitude of some users. You get what you pay for.
I find it funny how often FOSS advocates extoll the virtues of FOSS, only to turn around and silence complaint with statements like "what do you want for free?".
It doesn't hurt to write down the thought process. Of course some people can't be appeased and no reasonable explanation will be sufficient.
I'll assume he worked on Hannah Montana Linux /s
Do they think they're just being funny or something and aren't aware of the inherent rudeness in their comments?
Maybe people work in a bro type culture and this kind of thing is acceptable and so they don't realize ther behavior is not viewed favorably by the wider world?
Just curious. It's interesting phenomenon.
If it's Firefox, thank you from the bottom of my heart. This piece of software is essential in keeping the web free and open. Fight the good fight. Don't let the trolls and the selfish users dissuade you.
Regardless of what you work on, thank you. We should all be more appreciative.
While users have no justification for being rude or insulting, they absolutely do have justification to be frustrated if you want to have your cake (compensation in the form of notoriety due in large part to the willingness of others to actually use your FOSS project) and eat it too (not prioritize plans, bug fixes, or features in accordance with what that user base needs & requests, over and above what you prefer).
I’m not saying this applies to you specifically, but it does apply to many FOSS projects, and arguments of infinite entitlement to strand users who bring your project notoriety because the compensation isn’t in currency format are totally specious and deserve to be met with (polite) frustrated pushback.
Yes, some open source software (like Red Hat Enterprise Linux) is run by a company and has an expectation of support.
The vast majority of free software, from the GNU tools like gcc to the linux kernel to clang, does not have that expectation.
All free software has a license that lets you fork it (by definition)... and that's where your reasonable expectations should end.
If you think the maintainer isn't doing a good job working on the right issues or maintaining the project, that's not the maintainer's problem. That's your problem. If you have the abilities to fork it and implement those changes yourself (realizing the maintainer does not have to incorporate those changes of course), go for it. If you can't, well, your expectations are totally wrong.
If a maintainer actively looks for "fame" or actively pushes more people to use their software, that does not mean they have to provide support. That does not mean they have to live up to some standard you've made up in your head.
They should make a reasonable attempt to uphold any specific promises they make, but that's about all they owe people, and if they promise to build a feature, then burn out, that's okay too really.
This is backwards. The maintainer is expecting attention and users. By alerting the maintainer to issues, I would be helping them (using my own extra effort, eg bug reports, feature requests).
The nuclear option for a user is to just throw their hands up, not even try to lobby the maintainer to make better choices, and quit using the project. The nuclear option for a maintainer is to completely ignore the user base whose attention they need and whose efforts on bug reports or whose frustrations give them free labor to understand their projects fault points and fix them, and instead say, “you’re not paying me with money, only with attention, time and effort, so I owe you nothing” (as if owing was any part of any of it) and ignore their feedback.
Either side can go for the nuclear option. But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports, etc. before “going nuclear” and gainsaying everything with “you don’t pay me in the form of currency so I owe you nothing.”
Do they? The projects I maintain I do so for myself and work.
> By alerting the maintainer to issues, I would be helping them
Do you? I need to weight the time and effort to understand your issue against my potential gain from it.
> The nuclear option for a maintainer is to completely ignore the user base whose attention they need
Odd, I don't need attention for my projects.
> as if owing was any part of any of it
You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".
> But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports
If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
> Do you?
Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong.
> Odd, I don't need attention for my projects.
Then why are they open source?
> You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".
No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc.
In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem.
These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”
> If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.
This is a bizarre viewpoint. The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it. They understand the technical restrictions that result in various tradeoffs. Users making feature requests rarely have the full picture or understand the technical tradeoffs at play, unless they implement or fix their issue themselves.
Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.
Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.
In addition, if a user feels like they're spending enough time to "put work into documenting issues/features" that they're net losing time after the savings of being able to use the project (vs implement it all themselves), then they should neither file issues nor use the project at all.
> Then why are they open source?
Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.
In fact, if you listen to maintainers, the vast majority don't want that crap.
Projects can be open source because "information wants to be free", or "I want my users to be able to fork it, they have rights", or "I hope someone learns from this", or "I want people to contribute code (but not dumb issues)".
For the most part, an open source project wants attention from a group of people - people who find the project useful already, and who are willing to not incur a maintenance burden.
Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.
> Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”
No, it's not more reasonable for users to complain unless the maintainer asks users to complain. If the maintainer has a contributing.md or a page on their site that says something like "please send me poorly thought out feature requests, hate mail, and entitled bullshit", then yes, users can do that.
Otherwise, the user should indeed take it or leave it. If the maintainer has a contributing.md saying "I might accept PRs", the user can absolutely discuss implementing a feature with the maintainer.
The default, if there's no documentation about expectations, is that it is 100% take it or leave it.
You seem to think that all open source projects are like RHEL, where a huge company runs it and all users pay thousands of dollars for support.
In that specific case, yes it's totally fine for users to send support emails describing issues they ran into.
The majority of oss projects are not that. The majority are some dude who hacked something out and hopes other people like it too. If other people like it, cool. That does not give other people a reasonable right to expect that person to actually do any serious maintainership of it.
That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).
I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?
Your viewpoint seems quite foreign to the maintainers I've met, and I'm curious what has shaped it.
My perspective has largely been shaped by maintaining OSS projects, talking to other maintainers, and reading secondary sources on the free software ethos.
This is a bizarre point of view. The maintainer has only spent time thinking about it from the point of view of their lone preferences and opinion. Users come from all walks of life and are in the weeds with many use cases or blocking issues or bugs that the maintainer would never realize or think of if it weren’t for the free effort gifted by users reporting bugs and requesting features. It’s far more bizarre for you to assert maintainers are in the best position to judge over and above users.
> Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.
This is exactly backwards.
> Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.
No they should lobby the maintainer to prioritize it for the existing project. Forking and doing it themselves should be an extremely uncommon fallback or hobbyist special interest, not at all a default.
> Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.
> In fact, if you listen to maintainers, the vast majority don't want that crap.
You seem to have some mix of a superiority complex / poor attitude towards users of OSS. It sounds extremely obvious that you aren’t suited to be a FOSS maintainer if you harbor these biases against users. Have you considered taking your projects down? It might be a benefit for all parties to not have to experience this anger / belittlement issue from you.
> Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.
Nope, the internet doesn’t work that way. If you want to post your software project for passive consumption, people absolutely have every right to complain about it. You don’t have to listen but they absolutely have full justification to provide their take on the thing you published.
> That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).
It has nothing to do with being “entitled” to anything, for either party (users or maintainers). And this doesn’t matter if the maintainer is RHEL or some random guy that can spend max one hour a month on a project.
> I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?
Given the vitriol in your comments and especially the really abusive language you use to sweep the entire class of FOSS users under an umbrella of being completely stupid and dimwitted compared to maintainers, I do not for one second believe you genuinely want to engage in discussion or debate whatsoever. If I shared my own personal experiences managing FOSS projects for two past employers, I think you will just find excuses to unfairly dismiss it, make sniping replies and take various pieces out of context as you have so far.
It's clear to me we aren't going to get anywhere in this discussion. We're talking past each other. As such, I'm walking away from this conversation.
Likewise, I don't believe I am speaking negatively or uncharitably at all. I think I have responded in good faith and with due self-reflection and that my comments are fair reflections of what you are communicating. Looking back, I don't see anything I'd change or any place where I wasn't engaging with polite, good faith responses to your negative comments.
Having access to the source doesn't automatically mean the owner/maintainer owes you nothing. I think the comment is promoting only the "FOSS == gratis" side of getting things for free ($0) and not considering the original "FOSS == insight and rights, even if paid for" side of things.
> "there can be explicit contract where you are funding specific feature"
Yes, I said as much when I said you can have a contract for support and also have FOSS software. Here, you are downvoting me and agreeing with me. There can be a explicit contract where you have the source source and also are entitled to some development that you're paying for.
> "You can stop using the software if it does not provide you any use. That is the only thing you are entitled to."
NO, here you are changing your mind again and narrowing it back down to "it was free so you have no rights". You cannot make the judgement that because someone has open source software, they didn't pay for it, and you cannot make the judgement that if they have open source software, they are not entitled to anything. The three are DIFFERENT things. The original point of FOSS was to avoid vendor lockin, not to get free downloads from Github.
In case it isn't extremely clear, downloading a free and foss tool from Github does not entitle you to feature requests or support. Donating to it does not either. Saying "every FOSS user has no entitlement to support or feature requests because the code is FOSS" is incorrect, and a bad idea for the programming/tech industry to be spreading, partly because a lot of developers would benefit from spreading the idea of paid FOSS because they want to work on it and get paid, and partly because users would benefit from the increase in paying for software and also getting the source as part of that, including whatever entitlement to support paying would have got them normally.
There might be such people, but I doubt such projects would be very successful or notorious. Being able to put something on CV does not provide that long lasting gratification needed to develop/maintain software in the long run. If it's about your CV only, then there are probably more effective ways to achieve better returns.
(In my case I don't put my F/OSS on my CV and I don't think I'm "extreme minority")
Maybe I just see an unusual slice of the OSS maintainer world, but it’s very common.
That's an interesting concept of compensation, does this apply in other domains, e.g. if I go to a soup kitchen which donates free food is my eating that food compensation?
I'm really trying to understand this argument.
Giving my attention to your FOSS project is compensation. In fact, FOSS is so over-saturated with options that giving my attention is high compensation. Project maintainers are lucky to have an audience of users and should value their feedback and create solutions for them, if they want the attention to continue or they want compensation to increase.
What doesn’t make sense is to treat users like they don’t matter, ignore critical bug fixes or feature requests to prioritize dabbling or recreational features, and disingenuously turn around and claim users are rude or should be shadow banned for stating justified frustration over this, all under the false pretense that just because the compensation is in the form of attention and engagement (similar to currying “likes” or “votes” on social media), and not currency, this somehow means there is zero social contract between maintainers and users.
If users are kind enough to express frustration in bug reports or feature requests, it means they are making an extra effort to hopefully not have to leave your project and stop using it. It’s an attempt at a constructive solution by letting the maintainer know there’s a social obligation problem happening. That seems way, way more positive and reasonable than a disgruntled maintainer immediately shrugging it off and going straight for the nuclear option of, “well if you don’t like it, leave.”
So your argument is that in compensation for your attention you are entitled to give uninvited criticism, or lets say tell them to play songs you like? Moreover, how do you assume that your criticism or the songs you would like to have played somehow take priority over other peoples interests? If I would be in the audience for some unknown band I certainly hope that people who don't like the music leave instead of heckling the musicians.
You are saying that maintainers have a "social obligation" by giving you something for free, so you are entitled to their time, because that's what it boils down to. To make another analogy (again admittedly flawed), would I be entitled to demand you reply to me, because I have given you my attention in this discussion?
I would maintain that in many cases it isn't uninvited, just unwanted. There are many repos on github that are just somebody's pet project they did for fun or because it filled a need for them, and they aren't inviting criticism because they just shared code in case anyone else could use it or learn something from it.
However, many FOSS projects are very much like the band analogy above in that they aren't content to upload videos of their jam session to youtube but actively seek to attract an audience. They make project announcements on places like HN, they show up in forums and tell people how blazing fast their project is and it's a good fit for someone's use case, they have fancy websites, etc. They ask for your attention, and in so doing invite criticism.
Of course you can ignore that criticism - that was never in doubt. But users are fully justified to make the criticism and it would be rude and wildly unreasonable to reply by saying, “if you don’t like it, leave.”
It does though IMHO.
If you are just some person who wrote some code and made it open in case anyone else finds it useful, that's totally cool and I can respect that.
If your goals are to attract a lot of users and you're out there pushing for people to use your product, don't be surprised when they tell you what their problems with it are. You've already signaled you want them as a user, and by ignoring them you're signaling that you don't want to put any work in for it.
How would you prefer that kind of "arbitrary planning" be addressed though?
I don't have any luck with my FOSS projects but I am SUPER grateful for that because I just don't have the time to sit and work on them after I've done the job I have to pay the bills I also have.
Any advice for someone like me?
That's the 1 line summary of doing volunteer work.
If you want to enjoy working on FOSS, choose to solve a problem that lots of users need solved, the more mundane the better, then make your whole backlog focused on what the user tells you.
FOSS needs product / market (of attention) fit like anything else. Unless you are your own user for a real use case, you need other real users to be the sole driver.
But the only reward with volunteer work in FOSS is the fun you get out of it. That's your compensation. So if you don't like what you are doing, stop doing it. Don't try to mainly please others, unless that's what gives you pleasure.
I hope that with all of these new users they are free to continue to provide their service for free, and even more so, that they may inspire us to build a better future with similar apps in other domains. They may definitely have some growing pains and tough moments ahead of them, but I'm ecstatic to see e2e getting so popular and users finally seeing the value in these kinds of things (after, for what seemed like a decade, getting anyone to care seemed impossible).
(I don't actually know if this would work, just a guess.)
It is not perfectly nonpartisan, but compare it to the websites that are similar in popularity and you'll find there's no contest.
The lack of federation, crippled data export and requirement for a phone number puts it into the "no good" category for me.
Doesn't matter how much Open Source they throw around, what matters is how much effort it will be to stop using your software. Signal so far, looks to run with the same lock-in tactics as everybody else and that in turn gives them the power to switch over from nice to naughty mode whenever they want.
Wait do we consider Wikipedia to be "Good" now? Just the banning of Fram in 2019 should be an indicator that the people steering the ship are probably not good.
If you struggle with impulsive thoughts, anger, rudeness, you may be in need of a change in your ways, habits, and mental health. Try diet, exercise, and clean living to help your body feel right, but also meditate and allow your skill of executive function to take over. This secretary of the mind will stop you in your tracks, reallocating attention into better pursuits.
I think the key is decoupling thoughts from behaviors. It's one thing to think, "implement this basic feature already you freshman noob." It's another to let that thought pass away, without typing or saying anything.
To practice this, meditation is a good start. It teaches the simple noticing of thoughts, and practices not acting on them. And don't beat yourself up btw, if I get mean thoughts, I just laugh it off and notice the primates' mind within me. We are running aggressive chimp software 2.0, it's not very refined! You can patch it with meditation and healthy living.
I think everyone is realizing that software/tech doesn't magically solve fundamental human dynamics, no matter how much it fixes other problems. And that you need to have non-negligible resources dedicated to policing/enforcing rules so that we can have nice things.
And be grateful for those who do.
There is a world out there ready to mess up your carefully built shit, by maliciousness, honest inadvertence, people not reading the directions, people learning for the first time and making mistakes, or just sheer incompetence, or indifference.
1) If people aren't being respectful, block them.
2) If they put little effort into bug reports/feature requests and are not respectful of your free time - close the issue, link to a generic explanation why.
3) If you are not being compensated and the project burns you out: stop doing it.
There is usually nobody else who can or will do these things for you. Grow a spine, have self respect, value your time, learn from the experience.
1) you cannot control the world around you
2) you can only control how you react to the world around you
3) to tie your happiness to things you cannot control is to suffer
Once you internalize this, you will identify attempts to circumvent this truth, and why they are ultimately self-defeating.
It's definitely not either/or, sometimes you can change the world a little bit by making a post that says "please be nice".
Or the way I see it: be prepared to step in shit sometimes but if street defecation is not culturally accepted, your walks will be nicer.
I wonder if they ever influenced each other, or if those principles where 'discovered' independently ?
Having read the linked post, I sincerely doubt Adam Piggott lacks a spine, self-respect, a proper sense of his time's worth, or an inability to learn from experience.
People working for companies who pay are more likely to be well paid and both of (a) technically competent and (b) having empathy and some amount of charm as qualifying criteria to get that well paid gig.
It's no slam-dunk but it's more likely. People who work for organisations who don't pay are likely to be paid a little less and include some who are working a second choice gig because of some deficiencies in (a) or (b) or both. (L. is great but difficult to work with and we'll never find someone like that to hire to replace them.) As individuals they may improve their abilities in time, possibly dramatically too. The young, arrogant hotheads, sheesh. None of us were ever like that. Obviously...
The paying can be a fuzzy select for kinds of people who behave in particular ways rather than the paying itself causing particular behavior in a given person.
Make someone pay for software and they always treat you far better.
I'm sure there's some cognitive reason/explanation for this.
Remember the last time you got an item for free. You probably didn't worry too much about it, because it didn't cost you anything. You didn't treat it that carefully.
Compare that to something you bought for yourself, that you had to work hard for. You probably took a lot of care for it. You probably really paid attention to ensure it didn't break.
I feel like this is the mentality difference. Something free = no value = we can treat it badly. Something not free = it has value = we are more careful with it.
The nicest customers I have for my Saas product are also the ones who have the largest accounts. The ones that pay $15 a month for a single user on the cheapest account are always the ones asking for a list of like 50 new features to be implemented yesterday or "the product just isn't gonna work for us". Yea ok, because your $15 buys you a right to own my entire roadmap... not.
They’re paying for whatever product or service they went in for. It’s not because something is free, it’s because they’ve designated certain people as servants.
I think there’s a pernicious attitude that the “free” part of open source is an entitlement to service, and that the people providing it are servants.
I think products do have the ability to make us feel an emotional response, even when free?
Apart from gifts, as mentioned by another commenter, I often seem to value things higher and be more careful with them when I know they're valuable and I got them without having to pay.
Do you pay for the oxygen you breathe?
Indirect correlation if you ask me.
"Consumer" users are most likely to behave as consumers, ie not being interested with the project but their work getting done. Open source distribution channels are often independent from the actual project management, opening the possibility for varying degrees of quality.
Paid for bugs are more irritating than free bugs. Consumer support is rare for "paid for" software (good luck getting support from Apple radar, google services, iOS App Store ...) where open source projects provide forums, issue trackers ...
So if people made a monetary investment they have the emotional need to justify to themselves and others that they made a good decision (hence you talk positively about that purchase), however somehow when they use something free, people don't feel that emotional need.