Hacker News Reader

Comment by meetups323 | Hacker News Reader

I maintain a very popular piece of FOSS software as my full time job (you've all heard of it, many of you use it).

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.

View on HN

I have a slightly different experience. I find aggressive users very easy to ignore. What does drive me mad is that some non-hostile users put zero value on my time.

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.)

I understand when writing paid software with support expectations/contracts, sometimes you have to engage with the teeth-pulling exercise that is “does not work”. But why do you in FOSS? Can’t you just close the ticket and say “not descriptive enough” and move on?

You can and I regularly close tickets for not following the template that says at the very top "tickets not following this template will be closed with no reply".

It's even better if you can get a bot to automatically reply and close it.

I was thinking about how one could automate this when reading.

Not a foolproof way, but add a string in your Issue Templates that is required to be there, e.g. .

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...

I've seen this in repos, I'm pretty sure there are bots who implement it. I'd guess it catches more than 90% of cases, especially if you put the string at the bottom of the template.

Another, somewhat more underhanded trick: add a string that is required to not be there, e.g. "Please remove this line entirely.", halfway through the template, and mention it nowhere else.

You can. You can do anything, really, including not reading issue reports at all. But you set out to be helpful anyway, so it’s about finding a cutoff where you don’t want to help anymore. As I said, it’s simply harder than ignoring assholes. (Plus you may get a bad rep.)

To do that, you need a healthy brutal self-respecting trait that I think most of us admire.

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.

The Syncthing project will often apply this trait and you're right - it's admirable as well as pragmatic.

Sounds like a good way for someone without coding skills to help a project, bug/message triage.

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 a skill probably worth practicing.

Like anything else, the more you do it the easier it gets. Its not going to be instant but you'll get used to it.

I don't think you even need to be that brutal. Just have a file on your hard drive with a canned response that instructs the reporter that they need to provide more information, and how to provide it. Every time you run into a weak bug report, copy-paste that response into the issue comments. If the extra info gets provided, great, now it's a useful bug report. If not, you can close the issue, and not feel anywhere near as bad about doing so.

Depends on the project. If it is governed by bureaucrats and you do that too often, you'll be accused of "not being inclusive".

The modern version of "Boxer the work horse should work harder".

Honestly sometimes the amount of things that you need to fill out just makes me use other software. I.e. kmail would never remember that I want my email threads expanded (this example is not real, the kmail devs were very helpful with minimal info in this case). Does this really require I hunt down all this info from all around the place? Sometimes I don't even know where to get the info.

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.

KDE, and it's related apps, is an interesting one. For a long time you could get the version info from a menu item (Help>About or something) in any of the K apps. But then they changed it to give no version info ... then the bug report tool asks up front what version you're using ...

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.

> But then they changed it to give no version info

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.

Ok, I'm a 20y user of KDE, and a massive supporter. I still got the app version from apt (apt-get at the time) and framework version and still submitted bug reports - after registering and installing symbols to get decent backtraces. I even helped some people improve their forum posts by showing them how to get the relevant version numbers.

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?

Yeah this was also the gist of my comment(s).

this is extremely frustrating for the users.

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.

Was the game free? And did the people working on the game contribute a lot of their time to it for free?

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.

paid

> (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.)

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?

I never saw a dime and never looked into spending details, but to the best of my knowledge, sponsorship money largely went to hardware for infrastructure; then some went to sponsoring physical meetups, e.g. reimbursing travel expenses of team members who attended FOSDEM. It’s not a lot of money so if everyone gets paid I suppose it would only be a token amount.

Thanks!

you are a true hero :)

You need a consistent process that you can point your users to. If they don't follow the process then politely explain that this will save time for both parties.

I do. It’s in the issue template, it’s in the wiki (pointed to by issue template), and commonly seen error messages may even point to the relevant wiki page. People who don’t care don’t care.

Maybe some one (who's good at writing) could make a closedforreasons.org and you could just put the link in and close the issue anytime someone posts such an issue.

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.

This idea seems really interesting/promising. Here are three considerations I've thought of while thinking about how it might be implemented:

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)

There's something similar to what you're proposing: https://idownvotedbecau.se/. It's tailored to Stack Overflow and the Stack Exchange network, but a lot of it overlaps with your proposal.

Having robust reply templates is pretty key. If the templates explain why a thing was closed, there isn't much for the user to refute. They can always fume, but fuming on a closed ticket is like screaming into the void. Leveraging bots helps as well. e.g. if an issue template isn't followed, removed, or omits key required info the issue is closed by a bot and a reply is dropped letting the user know that their attempt to circumvent the requirements means they get no support.

I quite like the idea of using bots - that way there's no human making a decision, and since we've already internalized bots as cold and unfeeling, no one's feelings are hurt.

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.

Bots are good in moderation, but in some cases bots can annoy everyone involved...

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

I manage a couple of high volume projects on a few open source initiatives. Stalebot is a sanity saver. Users are always welcome to trigger the bot to reopen. I won't presume your experience on open source projects of a big size, but when you're dealing with dozens of new issues daily, and have hundreds of issues that go back five years with no activity, the stalebot saves the day.

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.

Drive by issues are noise? So if I say "library X fails with this input" and don't follow up/triage/commit code, then this is a waste of time?

I strongly disagree. Follow-up and collaboration are great, but someone taking the time to write a decent bug report is also valuable.

Presumably if it's a "decent bug report", needing additional feedback etc is less likely, and I assume GP is more talking about bug reports that are not really usable without further information. (Although even if you are careful at providing information, you can easily hit cases where more information is needed)

This presumes that all opened issues are decent. It also presumes that the author of the issue responds to feedback. What I would quantify as drive-by issues include poorly written, lacking information, or providing information that results in a follow up reply from other users or maintainers with a fix or ask for more information that goes unanswered.

"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.

Closing bugs because they don't contain enough info and the reporter is not responsive to providing the required info is commpletely fine. Closing based on inactivity alone is just rude.

> "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.

We disagree. My experience with several extremely large projects has yielded the judgement that closing tickets which are years old without activity is prudent, as is setting a reasonable time frame in which an issue is too stale.

Only the original reporter gets to bump/reopen. Which they are sure to give up doing after a few iterations.

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.

This comment reflects what's wrong with open source. It's bitter, entitled, and devalues the time and effort of project maintainers.

I don't really like something like stalebot from both the maintainer and user side. As a maintainer, I don't want a legitimate issue to get closed just because it's not (yet?) a high priority for me, and I let it go for a while. And as a user, if I've provided sufficient information to reproduce the issue, and the issue is valid, it's really demotivating to have that issue closed by a bot.

I think stalebot works so long as maintainers commit to marking issues as "confirmed" after a while, or if enough people +1. However too often that is not the case.

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 think you are also being a bit entitled here. Bug reports absolutely do take effort to file, especially good ones. Automatically closing bugs for inactivity shows that you don't value that effort. Personally, that would mean every future bug report to your project would receive minimal effort. If you don't like bug reports then you should not have a bug tracker at all. If you do have a bug tracker, try seeing it as a mutually beneficial exchange that is not free for either side.

Unless someone is contributing, it's not at all a mutually beneficial exchange. If someone reports a bug that affects only them (e.g. edge cases) then that ticket benefits only them. The -vast majority- of tickets files on large projects are for the benefit of single users. The tertiary benefit to users that might come along later with that same edge case or edge feature need are moot. It doesn't benefit the maintainers. If someone reports a bug and leaves out critical info because "they know better" than the maintainers, and that causes additional work for the maintainers that creates burden. Maintainers are already giving their time freely to produce something for users to use freely. The scales are always tipped in maintainers' favor.

https://liberamanifesto.com/

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.

Exactly. I'm not asking you anything here, I understand you don't have time to fix it, but leave it up so another contributor can find it. I'm literally asking you to not do something instead of doing something (closing).

I'm going to disagree as someone who reports issues to open source. Often the templates request info I know as an experienced user of the software to be completely irrelevant to the issue, and if provided would only confuse the cause of the problem. Templates often assume a stupidity level of issue submitters. If there is a github template, I'll usually heavily modify the template and delete sections, which then gets flagged by a bot if such a bot exists. This only slows down the process of getting something fixed, not speed it up.

A compromise could be to have a bot to check the issue template, but to make the bot aware of users' contribution histories. The bot would skip checking the format of someone's issue if, for example, they had already reported at least three bugs or gotten one patch merged.

Frankly; it's not up to you to determine what info maintainers need - thinking otherwise is an entirely entitled point of view. That's why the project members and maintainers ask for what they need to triage not just your issue, but all issues from a wide variety of users on any variety of platforms.

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?

While I agree with the point you're making, I'd like to point out the tone of your wording. It's not cruel or anything, but there are some pretty easy changes to it that could have made it an explanation instead of an argument.

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.

Your wish is my command: https://closedbecause.xyz/

Source here: https://github.com/andrewaylett/closedbecause.xyz, suggestions for reasons welcome, PRs even more welcome.

It would be neatly recursive if someone opened an incomplete/nonsense PR on the repo for this site, prompting a link to the site itself.

How can you have a closed because site without being able to write a custom reason, with custom parameters, and on top of that, it doesn't make my coffee. Ridiculous.

(Joke obvs. Sorry, couldn't resist.)

Well done!!

A relevant post, "Open Source is Not About You" by Rich Hickey.

https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

Appropriate use of an xyz domain IMO, it's catchy. Bravo.

Great idea! I was looking for a side-project I could do in a week or so, so I just bought the domain and I'll build it.

Came across this explainer site the other day: Short, Self Contained, Correct (Compilable), Example http://sscce.org/

Over the years I've learned there's a class of users that simply don't read.

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.

This sounds like an UI problem. Why can't the system just disable the issue creation button?

Yeah. It's literally one checkbox lacking on GitHub.

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've spent more than a decade in customer/user-facing roles, and that class of users is actually "almost all of them."

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.

And this is why UI/UX experts are so valuable in software projects!

If "almost everyone" fails some expectation, is the problem with the people or the expectation?

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.

I don't see how replacing "sift through a bunch of issues" with "sift through a bunch of feedback forms" makes the developer's job any easier.

That's my point. Things have to be designed with the understanding that "people who won't read the instructions" are the rule, not the exception. That has to be the expectation if anything is ever going to improve.

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.

Exactly; the problem here is that there's a repository that allows issues to be filed, when the owners don't want issues reported there. Issues should just be turned off on that repository (and if you can't do that, I'd consider that a big missing feature).

You need to guide people to do the right thing based on the interface itself; people overwhelmingly don't read instructions.

Then you get people like me who prefer to read words, but are utterly baffled by the user experience on modern social platforms... like, how do I log out? Oh, the smiley button, duh.

Same feeling, the fact that one has to assume people will not take 5s to read and understand a message has nothing to do with the project being open-source & free or not.

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).

Could issue boards have volunteer community moderators, like Reddit and StackOverflow have?

I think a problem is the social integration of sites like Github (I assume you have your project there). Traditionally low-effort questions were filtered out because many users didn't want to get into the trouble of contacting developers directly. Although it wasn't unheard of, but there was probably significantly less noise.

What you are describing is a perfectly typical (and expected) behavior for a user of a commercially-licensed library/server software.

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.

For very popular community projects, you can indeed solve the problems by throwing some manpower at it.

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.

> I’ve painstakingly implemented debug logs and carefully prepared issue templates yet I still get these “does not work (EOM)” (effectively) issues.

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.

Yeah, as much as parent complains about users not believing their time is valuable, my time is valuable too. I might not get back to you for a day or more because I have other shit to do.

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.

I'd like an option to pay for prioritization, or pay outright for fixes. "Pay $100 to raise the priority of this issue X points" or something like that. Wouldn't be that hard to sell to my management when we're running up against a bug that affects us directly but perhaps doesn't have a huge impact on the community at large.

> Pay $100 to raise the priority of this issue X points

That could lead to some perverse incentives, but it points in the right direction. Some "mechanism design" / "reverse game theory"[0] 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."

[0] https://en.wikipedia.org/wiki/Mechanism_design

> I still get these “does not work (EOM)” (effectively) issues

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.

It's the same issue with support as a software company. We have companies paying us $10k a month who "want us to consider something for future roadmap if other customers would also value it" and free users who "demand we fix (expected and documented behavior) IMMEDIATELY". The problem isn't open source, it's free.

You almost need something like a shadow ban for users like that. Or to try and outsource your ticket moderation to the community.

That’s sort of dispersing the problem onto some other poor sap or group of saps. Businesses do need to set boundaries and it’s terrifying to do so because “the mob” can suddenly decide against having goodwill. Best bet is to set standards very early and firmly like you’d treat a child - EG “we do NOT put our hand in the fire, but you can do just about anything else” and “we do NOT adjust our roadmap to people who yell the loudest but we are happy to have a conversation over why it’s important”

I think part of the problem is the expectation of instantaneous gratification today. Individuals can get any item they want shipped premium to their door step the next day nearly everywhere. So why shouldn't software features be the same? The problem with "free" is that many, many more people can use the software.

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.

As somebody who usually works in those big support contact enterprises, I often find myself incredibly frustrated by the open source projects my employers pay for. You often see these companies that take the enterprise approach to support contracts, taking the open source approach to fixing issues. As in, if you want something fixed, you’ll be lucky if it ever happens.

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.

> consider something for future roadmap if other customers would also value it

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.

Isn't it a bit more subtle than that? The business issues with free users are well documented, but this is a bit different. What we're really taking about is GitHub - you don't have the same volume of low effort comments demanding features on pre-GitHub collaboration tools like making lists, IRC or even using the email address associated with commits.

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.

Free users don't care if you tell them to fuck off.

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".

I second that. Once a vendor becomes important enough I even stop thinking of it as a vendor and rather as a partner that you interact with as if it was part of your own organisation. I am not amused when members of my team are rude to a vendor and jeopardise a relationship that took a long time to build. Even when you pay six figures a month, you can still get preferential treatment compared to other customers in the same tier when it comes to influence over the roadmap if you actively foster the relationship.

> Free users don't care if you tell them to fuck off.

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[1], 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"[2] so that you can "encourage a pleasant and productive environment by responding to disruptive behavior in a fast, fair way"[3]. 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.

[1]- https://medium.com/free-code-camp/why-im-not-using-your-gith...

[2]- https://docs.github.com/en/free-pro-team@latest/github/build...

[3]- https://docs.github.com/en/free-pro-team@latest/github/build...

It's like when you give your old stuff away on Facebook/craigslist/gumtree - when it's free, you'll get very entitled people messaging you whether you can deliver it to them, or don't keep agreements. Asking for $5 removes 99% of the trouble.

The enterprise guy is at the other end also writing software professionally so he understands if you can't build to his use-case.

100% Agree.

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.

https://news.ycombinator.com/item?id=25719045

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.

To be fair, Microsoft has plenty of bad rep, stemming from decades of abusive behavior, to recover from.

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.

Signal isn’t an individual developer, so what about the sort of comments highlighted in the original article?

Or is it just 'be nice to developers in small companies, but you can say anything to developers in big companies'?

Microsoft declared war on free software first, pursued that war for many years, and never made amends.

idk man I got a foam Tux with "microsoft <3 linux" on it so clearly it's all water under the bridge

For this exact reason I've cut almost all of my tech support for friends and family. It seems that what goes around comes around, and my time was worth what they paid for.

> 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.

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.

> 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.

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.

End of the day yes I'll implement the thing I was planning on implementing -- I'm not going to let some random user dramatically change my planning process. But the added work of having that conversation if needed gets factored into my mental idea of the cost of the item (I didn't get into software engineering because interpersonal relations come easily and stress-free), and if that means that I prioritize lower cost items with the same impact, so be it.

I made a small app for my specific need and decided to share it with people with same interests. It stated getting traction and more and more users started using it. At first I was exited to read the 5 stars reviews and thanks. When the app got even more traction and reached +30K users, the reviews and direct emails became toxic and insulting: why doesn't the app do this? why is it free? are you selling our data? (the app is free w/o ads and with Zero permissions not even network. It's just a small sqlite database with a UI).

The I read the Flappy Bird's creator story[1], 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.

[1] https://businessideaslab.com/flappy-bird-story-dong-nguyen/

I think that this is a bit different from what the parent comment was about.

> 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".

Yeh reading app reviews is toxic. We build a free open source/creative commons app (https://www.secfirst.org) to help people learn about digital and physical security. It's one of the biggest guides ever written about the topic, something like about 160k words in 40 different topics translated into 7 main languages. All done with volunteers.

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.

Honest question: why don't you ban such users?

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".

If I were acting on behalf of myself I might, but as a representative of {FAANG company}, it a bad look to be banning people left and right.

> toxic users who hop on to issues demanding you implement them immediately

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!

> I would have a policy of not allowing feature requests, only bug reports.

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.

Also, while a lot of feature requests are for kind of obvious things and not really all that valuable IMO, sometimes people just post really good ideas in feature requests. It would be a shame to lose that.

Brian Fox had a great canned response to such people: he would reply "Please return your copy of Bash for a full refund"

> "rewarding" their behaviour (in their eyes at least)

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.

Reading your post reminded me of a common social conundrum among lawyers who negotiate deals.

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.

> 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 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?

I suspect the project was started by a FAANG business, eg React or something like that.

React isn’t something we all use, as OP implied...on the other hand, OP might be maintaining a left padding package!

I'm now imagining a stream of hysterical entitled feature request demands from users of leftpad.js...

"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'???"

He implied that we all heard of it, but it’s besides the point I was trying to make — rather than starting an OSS project in the hopes some FAANG company may sponsor it, it may very well be a project started by such a company instead. Ie its not likely something you can “grow” a project into.

I suspect that what meetups323 means is that they work for a FAANG company on a piece of software that company uses that is also open-source, not that it's their own FOSS project and it draws them a FAANG-equivalent salary.

One possible path here is to build something so close to a company that you're likely to end up getting hired to maintain it. One notable example is the author of the "boto" aws SDK (https://aws.amazon.com/blogs/aws/big-news-regarding-python-b...), who was hired by amazon to keep working on it. It still took 6 years for him to get hired. The majority of projects like this end up not resulting in hires to work on that project (though they can result in hires pretty easily to do other work at the company).

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.

In my case, it took about 20 years. I don't make the FAANG money because I prefer to pay other contributors, but the project raises that much. I was willing and able to sit back and enjoy the ride. YMMV.

There are a number of resources for getting paid to work on FOSS on the FOSSjobs wiki:

https://github.com/fossjobs/fossjobs/wiki/resources

The realistic answer is to abandon your personal project and get hired to work on one of the many open source teams within Google or Facebook.

Thanks for what you do.

If you are willing to share, when you say that you get FAANG salary you mean FAANG-level or actually from one of those companies?

I'm employed by a FAANG to maintain an OSS project.

I strongly hold the belief that, for the long run, the success of open source depends on establishing a profitable business model that rewards people like yourself who put their hearts into it.

I maintain or contribute to various FLOSS projects. The day FLOSS becomes profit-driven is the day I stop contributing.

Profit and user freedom are two different priorities. Sometimes they are compatible, more often they are not.

There is a difference between "profit-driven" and "spending untold hours getting very little in return while some of the people using this are literally some of the richest companies and people in the world".

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[1], but I think we really need to think more about money instead of treating it as the devil.

[1]: https://lobste.rs/s/r5qaap/introducing_preql_new_relational#...

My $0.02 advice for dealing with toxic FOSS users: "You already got more than you paid for, closing this ticket for violation of basic human interaction protocols."

A bit of a tangent, but when it comes to consumable media I often hear the same lament: "X is great," (where X is a band, a TV show, a video game, etc.) "but it's got a toxic community."

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."

I've definitely noticed there is a difference between communities. Of course, no community is "perfect", and a lot of times conflicts happen just because someone having a bad day or lost their temper. That's okay, part of the human condition and all of that.

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.

If you published a roadmap would it solve the problem?

I cant help but laugh, since this is very likely the kind of things he fields, but is also totally natural for techies to suggest.

I meant it more as a solution to people thinking their bad behaviour is being validated.

I was thinking the same. Doesn't even have to be a roadmap, even merely opening an issue for a feature long in advance, saying "comments about x go here, as we intend to implement it at some point in the future".

Those kind of issues, while useful for well-behaved people, are often magnets for the kinds of people who yell "look! People have been asking for this for 201X, why are you ignoring your users!"

Would it be okay to explain why other issues have taken priority and will likely take priority for the near future?

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.

The tone might be off but it seems like a perfectly valid question.

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.

We do exactly that with our customers. Here is our roadmap but if you must have feature x you can pay us to prioritise it and get it sooner. It’s a great way to filter wants from needs.

Yes it's the decent thing to do.

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.

> is a valid answer but needs to be explicit

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.)

Well, it's sometimes valid criticism. Have you ever checked out the gtk file picker ticket from 2004?

If you ever wonder why GNOME devs seem so hardnosed on issue trackers, just read comments by people demanding that they implement things users have been wanting for years :)

Well, when instead of fixing decades old bugs they decide to instead remove features people used because they don't want to maintain them and add features nobody asked for because they were fun to work on, what do you expect people to say?

1. Nothing, because the maintainers have the last say because it's their time and they don't owe anyone anything

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.

That's fine, then don't ever ask me to use your product or pretend like it is a serious tool.

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?".

I don't see GNOME devs going around asking people to use it? And you can do what you want on a piece of software and still have it be a "serious tool". I don't see a contradiction.

Nope, it’s a culture problem. Everywhere were stuff is being made, you get what I call the proverbial twelve year old. These are emotional immature people who are unable to emphatically imagine that there is a person on the other side donating his time to create something that is useful.

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.

At which point you ask for a substantial sum of money to prioritise their feature (and hopefully they go away).

This is actually not a bad idea. There are already so many sponsor project like github sponsors, brave tips etc. Something like patreon can be used to solve this. You buy into a higher tier and that gives you 1 feature request.

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.

one would think Signal can hire bunch of devs full time with 50M donation to avoid such lame excuses

Apply here: https://signal.org/workworkwork/

I would see it as addressing the very narrow issue of accidentally "rewarding bad behavior". You can more convincingly tell people that their pet feature shipping right after their tirade had nothing to do with them. I feel like that would help me as a maintainer, if nothing else...

I don't know what you maintain. But let me say, loudly, THANK YOU! YOU ARE APPRECIATED.

This is the exact reason working on video game mods stopped being fun for me

You can just block users that bother you, can't you?

If I were a solo dev yes, as I'm acting on behalf of a company it's a bad look. (As I said, I'm 100% grateful to be in this position, and this being the worst part of my job is a testament to how nice the job is, I'm simply venting a bit)

What is FAANG salary?

Its a salary that you would normally earn working for the large tech companies in Silicon Valley. FAANG stands for: Facebook Apple Amazon Netflix Google

The salary made at companies like Facebook, Amazon, Apple, Netflix and Alphabet (formerly known as Google), together known as FAANG.

Is this Moxie? If so I just want to say I love your blog and your thoughts and wish I could read more. :)

> I maintain a very popular piece of FOSS software as my full time job (you've all heard of it, many of you use it).

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.

On the flip side though, lots of FOSS project maintainers want a large user base for fame and glory but also want to omit support for that large user base to instead pursue whatever interests the maintainers, as opposed to what is evidently needed, all under the disingenuous guise that not being directly compensated entitles any arbitrary planning policy.

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.

> not being directly compensated entitles any arbitrary planning policy.

It does though IMHO.

You present no argument at all. FOSS is FOSS. Creator or current maintainer owes you and other users exactly nothing. They are putting their stuff up for you to use if you see value in it. You can report bugs and make feature requests, but no one is under any obligation to even read your bug reports or feature requests. If you want your specific thing fixed right now then do it yourself.

Grandparent comment is “I maintain a very popular piece of FOSS software as my full time job”; FOSS means libre not necessarily gratis, it could still be paid for, with paying customers or employer-users in this case and owe them a lot.

That's correct, but misses the point. If you are paid for FOSS work then whoever pays you can expect you to do certain things. But that's the "get paid" part, not the "FOSS" part. It would be the same with paid work on proprietary software.

Yes it would be the same with paid work on proprietary software, which is why the comment I was replying to "FOSS is FOSS. Creator or current maintainer owes you and other users exactly nothing." is a non-sequitur, it doesn't hold up. Whether you have the source code and rights to redistribute it is orthogonal to whether the creator or current owner has a contract with you and "owes" you anything.

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.

Even if you pay for piece of software that does not entitle you any say on the direction the software is going or priority on your bug reports or feature requests. There can be explicit contract where you are funding specific feature, but just donating to a project does not entitle you to anything. You can stop using the software if it does not provide you any use. That is the only thing you are entitled to.

I never said "payment ENTITLES you to support", I said having access to the source does NOT mean NO entitlement to support, one does not control the other either way because access to the source and paid support contracts are separate 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.

Sure, but that doesn’t mean I have to view it as an acceptable choice if a maintainer leverages a large user base for notoriety and then fails to prioritize that user base’s needs. They can do that, and I can express frustration that it’s an unacceptably poor failure if they do, in more ways than just declining to use their software.

I think there's a big assumption that maintainer does the work to gain notoriety. Many of them (myself included) do it completely anonymously. Many others have a traceable identity but still they may be motivated by other things.

If it appears on a resume, it’s done for notoriety. If it’s fully anonymous and never appears on a resume, then I concede you are right in that case, but I think that’s an extreme minority of cases among the types of projects the thread is discussing.

> If it appears on a resume, it’s done for notoriety.

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")

As a hiring manager, a large fraction (easily greater than 50%) of resumes that I see do list OSS projects and contributions as accomplishments and technical experience.

Maybe I just see an unusual slice of the OSS maintainer world, but it’s very common.

If you have issues with how a project is being run fork it and do it yourself

Or, politely object, raise issues & frustrations and lobby the maintainers to make different choices.

Your comment misunderstands the point of some most software.

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.

> “ 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.”

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.”

> The maintainer is expecting attention and users

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 they?

Overwhelmingly yes.

> 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.

> Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features

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.

> 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.

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.

I don't mean to be interpreted so negatively, and you don't have to speak so negatively either.

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.

I agree we probably won't get anywhere constructive and your decision is respectable. However, I disagree that you are being interpreted negatively. You are being negative - it's not an interpretation, it is just the unquestionable property of your communication and the substance of your comments, especially insulting towards users of FOSS projects. There's no matter of interpretation, it just is negative.

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.

So according to your argument the users are compensating the FOSS maintainers by using the software?

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.

It's analagous to the brain-rotting line of thinking that pirating games is a benefit to the developer because "exposure".

Your analogy is extremely specious. A better analogy is an unheard of band playing an open mic night. The audience is doing the band a favor, by giving attention, possibly giving word of mouth reviews, not the other way around. The audience has every right to give feedback and help the band understand they don’t sound good. The band can ignore that feedback if they want, but they sure have no justification to look down on the audience for saying it, or saying, “play your own music if you don’t like it.”

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.”

I think your analogy is just as flawed (and you have not explained why yours applies more than mine, as you do not know the motivation of maintainers), but lets go with it for now.

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?

> So your argument is that in compensation for your attention you are entitled to give uninvited criticism

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.

There’s no such thing as “uninvited criticism” in FOSS (or open mic night). Merely by exposing your project to be acquirable by end users, you have invited criticism. And if you go further and promote the project, give talks about it, recommend it, seek sponsorship, seek contributors, then you’ve invited criticism even more so.

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.”

People are people and whether they are maintainer or customer, we can all be ass-hats.

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?

My advice: if you like the project you are working on, great! Keep working on it and maybe users will come along. Or they may not, but it does not really matter cause you like it anyway right? If you do not like working on it, stop doing it. No matter users or not.

That's the 1 line summary of doing volunteer work.

In my experience this is usually a recipe for unhappiness, similar to choosing a college major by “following your passion.”

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.

The analogy with a college major is not a good fit. College education needs to provide you with a job later that puts food on the table. Not every moment of that is fun, hopefully many moments are though.

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 don't have time to spend on my FOSS projects and I don't care about user growth. If I use the project myself and my friends are deriving lots of value then that's more than enough.

I agree wholeheartedly with this post.

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.

Reply on news.ycombinator.com