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.
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.)
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.
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.
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.
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)
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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).
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?
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.
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.
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.
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. <!-- AUTOMATIC-CHECK -->.
If this is not present in the issue, the GitHub action just closes the issue with a message to please fill in the template if they wish to create an issue.
Doesn't catch nearly everything, but should get some and it's easy to set up. Could be interesting to go further with the idea and maybe check if each section contains text or something like this, hmm...
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.
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.
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.)
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?
I understand the -1, but you have to understand that to a user the choice is sometimes between:
1. Create crappy bug report and move on quickly to get things done or:
2. Do not create a bug report and move on immediately, to get things done
I try to file whenever I can but when it's getting late and I want to go to bed I choose option 1 sometimes. Maybe I should choose option 2?
For example, take the Nextcloud bug filing template on GitHub [0]. It's quite a long read but sure, worth the effort for free software I agree (Nextcloud is my favorite project, my life is in there, on my server)! However, I may not know exactly where these things are:
```
#### Web server error log
<details>
<summary>Web server error log</summary>
```
Insert your webserver log here
```
</details>
#### Nextcloud log (data/nextcloud.log)
<details>
<summary>Nextcloud log</summary>
```
Insert your Nextcloud log here
```
</details>
#### Browser log
<details>
<summary>Browser log</summary>
```
Insert your browser log here, this could for example include:
a) The javascript console log
b) The network log
c) ...
```
They also want config.php, contents of `sudo -u www-data php occ app:list`, ask you to do this:
Login as admin user into your Nextcloud and access
http://example.com/index.php/settings/integrity/failed
Also all versions:
### Server configuration
\*Operating system:\*
\*Web server:\*
\*Database:\*
\*PHP version:\*
\*Nextcloud version:\* (see Nextcloud admin page)
\*Updated from an older Nextcloud/ownCloud or fresh install:\*
Moreover, I'm quite afraid to put my domain names or even more sensitive info onto a public website if I just copy and paste. All I'm saying is that a big button that generates everything a dev needs with sensitive stuff redacted (which should be doable here and yes maybe I should make a PR for that) will make the experience a lot nicer for the reporter and the dev.
As said, the Geyser MC project [1] can do exactly this and to me it is a game changer, the whole process was fast and pleasant and it was easy to test the automated builds they made in the branch based on my issue and report back in context on GitHub. Pasting the JSON their report feature generates into their Discord channel together with your question and their ability to just !docs/something point you to relevant docs with a small command feels like magic. I found the whole process inspirational.
> But "it's getting late" is not an excuse; it's getting later for people who need to read your crappy bug report.
First of all, I applaud your proper use of the semicolon in a sentence. As someone who should probably step away from my computer a lot more though, I've got to disagree that "it's getting late" isn't a valid excuse, because I use it all the time and I mean it when I say it (i.e. it's 4am and I have to wake up for work in 6 hours).
No one’s forcing you to submit a ticket at 4am, full stop. You can do it the next day, or you can simply not do it. You’re the initiator of the interaction, and if you intentionally half-ass it you’re not respecting the other side. Not sure what that snarky (?) remark on semicolon usage was about. We’re not grade school pupils here so no point in applauding or criticizing punctuation usage; doing so only raises eyebrows.
> Not sure what that snarky (?) remark on semicolon usage was about.
I definitely wasn't intending to be snarky, my compliment was genuine. I don't see people use semicolons properly in sentences often, or much at all outside of coding. I meant no offense, I was giving you an honest compliment.
Hey, I also just wanted to say that I know you FOSS folks are overworked and under-appreciated, and a lot of us really do appreciate you. I know you all get bombarded with all kinds of BS all the time, and I'm thankful that my patience hasn't been tested to such an extent. Thank you.
Fair enough. It helps if at least the communciation is clear: Like "Fill it all or don't file" or "Try to file as much as you can".
I really don't want to make it later for devs that give me so much. I'd be ok with: "Closed: Too little info" from a bot. I may decide to have another crack at it later when I have more time.
Edit: Btw, I'm using software for fee but, I'm also beta-testing for free. It's not just a one-way street: "I derive value from a free product so I should never complain." Is that really true?
I also invest time beta-testing (some times for products that make money on support or are open-core or are a gateway to paid software). Sure there are trolls, but there are also many users that make crappy reports that really want to help but just don't understand how (or why their report is a waste of everyone's time).
> I'm using software for fee but, I'm also beta-testing for free.
Assuming you're talking about a beta release for some open source software package, versus a full release, I don't think the distinction matters. You're using software that you got for free. It doesn't matter if it's beta- or release-quality. You aren't entitled to different/better support for it just because the developer chose to put out a version they admit isn't quite release-quality[0]. You're entitled to exactly the same amount of support as for a release version: none whatsoever.
> "I derive value from a free product so I should never complain."
I think that's framed the wrong way. I do agree that you should probably never complain about something you got for free; that smacks of undeserved entitlement. But constructive criticism and useful bug reports are (usually, depending on the maintainer) welcome.
[0] A developer might put out a beta version for a variety of reasons. One reason, yes, might be because they intend to jump on support requests faster in order to shape things up for a proper release. But another reason might be because they simply wanted to share with people as soon as possible.
TFA and the person you're replying are not suggesting you can never complain (at least I don't think they are).
There is a difference between not complaining vs raising issues constructively and valuing the maintainers time at least as much as you value your own time.
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
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.
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.
> (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.
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."
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 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.
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.
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.
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.
And this can happen on HackerNews too! Here is a thread in the last week where 50% of posters from HackerNews were berating Microsoft for open sourcing all of VS code, but not open sourcing one of their free language servers (calling them selfish, anti open-source e.t.c.). I think this is the exact same sentiment.
So Microsoft open sourced all of VS Code, but didn't want to open source the Pylance language server (a separate product which is installed separately as an extension) which they provide as a free (as in beer). This is because Pylance is also used within their other (charged) offerings such as full Visual Studio and is a differentiator from their competition in the premium space. Also they have hinted that it includes some proprietary secret-sauce that they don't want to make public.
Bear in mind that Microsoft is making VS Code free and open source... here are some quotes from the thread:
> I find it what they are doing to be dishonest [...] the consequences of their actions is that people who dislike them will talk bad about them.
> [Microsoft] have the right to be two-faced about their open source policy, I have the right to speak about how I think it's bad to do so.
> They should please stop acting like they are the second coming of christ for open source [...] they are misleading their users.
> Microsoft proved that they only care for OSS [...] because it enables them to spy on coders and their code to develop proprietary and closed sourced spins for software development product. The OSS community got served.
> Microsoft always does this, they fool people by pretending they’re in favor of open source or make something free but it’s just a trick used to bait and switch people into the proprietary anticompetitive Microsoft ecosystem.
> Seems like Microsoft is back to pissing in the public pool.
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.
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.
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.
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.
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.
> 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.
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.
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”
> 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.
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.
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".
> 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.
> "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 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.
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'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'???"
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.
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.
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.
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.
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...
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.
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!"
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.
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.
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?
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.
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)
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
If that's toxic (I said please, in fact), then the OP is too thin-skinned. Why signal that you work on a popular software title (you've all heard of it...geez), but then not name it?
I'll assume he worked on Hannah Montana Linux[1] /s
Do some people not recognize when they're being rude?
Do they think they're just being funny or something and aren't aware of the inherent rudeness in their comments?
Maybe people work in a bro type culture and this kind of thing is acceptable and so they don't realize ther behavior is not viewed favorably by the wider world?
> 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.
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.”
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 :)
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 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.
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.
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?
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.”
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.
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.
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.
"Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights"
https://twitter.com/cra/status/1306694315624796160
Signal is a treasure that shows us that more things than just Wikipedia can occupy the holy trio of Good, Popular, and Free, all at the same time (I would include having a user-aligned profit model such as donations instead of surveillance under Free/Good).
I hope that with all of these new users they are free to continue to provide their service for free, and even more so, that they may inspire us to build a better future with similar apps in other domains. They may definitely have some growing pains and tough moments ahead of them, but I'm ecstatic to see e2e getting so popular and users finally seeing the value in these kinds of things (after, for what seemed like a decade, getting anyone to care seemed impossible).
I'm still a bit concerned about the unique structuring of the Signal Foundation and the 100 million dollar loan it got from Brian Acton. Is there an expectation that the organization will be disbanded by the time the loan comes due in 2068? Brian will be 96 years old.
Maybe so that the charitable deduction could be split up among multiple years (forgive $X amount annually) instead of one enormous deduction taken all at once which would be ineffective?
(I don't actually know if this would work, just a guess.)
Not only that, but it shows us that projects matching that holy trio can still gain a footing today, rather than the beginning of the web being the only period in which such projects could have come into existence.
Wikipedia was definitely like this in its early days but surprised how many people think it’s a nonpartisan thing anymore. Maybe for some topics it can be still
I'm very cynical, much more so than you, however you do make a good point. I like that at least they have a little bit of transparency in the talk pages, even if im often not always happy with the consensus
The lack of federation, crippled data export and requirement for a phone number puts it into the "no good" category for me.
Doesn't matter how much Open Source they throw around, what matters is how much effort it will be to stop using your software. Signal so far, looks to run with the same lock-in tactics as everybody else and that in turn gives them the power to switch over from nice to naughty mode whenever they want.
Wait do we consider Wikipedia to be "Good" now? Just the banning of Fram in 2019[1] should be an indicator that the people steering the ship are probably not good.
Just be nice, is that hard? Well yes, it can be extremely hard for some who are stuck reentering a negative modality constantly.
If you struggle with impulsive thoughts, anger, rudeness, you may be in need of a change in your ways, habits, and mental health. Try diet, exercise, and clean living to help your body feel right, but also meditate and allow your skill of executive function to take over. This secretary of the mind will stop you in your tracks, reallocating attention into better pursuits.
I think the key is decoupling thoughts from behaviors. It's one thing to think, "implement this basic feature already you freshman noob." It's another to let that thought pass away, without typing or saying anything.
To practice this, meditation is a good start. It teaches the simple noticing of thoughts, and practices not acting on them. And don't beat yourself up btw, if I get mean thoughts, I just laugh it off and notice the primates' mind within me. We are running aggressive chimp software 2.0, it's not very refined! You can patch it with meditation and healthy living.
I mean, if everyone were well behaved in life and would just "be nice", there would be no need for laws, or police, or moderators.
I think everyone is realizing that software/tech doesn't magically solve fundamental human dynamics, no matter how much it fixes other problems. And that you need to have non-negligible resources dedicated to policing/enforcing rules so that we can have nice things.
And be grateful for those who do.
There is a world out there ready to mess up your carefully built shit, by maliciousness, honest inadvertence, people not reading the directions, people learning for the first time and making mistakes, or just sheer incompetence, or indifference.
No, even if everybody was nice all the time you'd need laws/rules. Their purpose is not just to keep bad guys at bay, but also to give good guys a pre-agreed framework within which to operate.
We all need some thick skin to get on in life and need to cope with bad behaviour but hopefully the post gave some people pause for thought about how they act next, and how they have acted before.
People will exploit and abuse you, knowingly or unknowingly. The amount of idiots and assholes will never go to zero. Never. The good news is that there are usually mechanisms to stop them.
1) If people aren't being respectful, block them.
2) If they put little effort into bug reports/feature requests and are not respectful of your free time - close the issue, link to a generic explanation why.
3) If you are not being compensated and the project burns you out: stop doing it.
There is usually nobody else who can or will do these things for you. Grow a spine, have self respect, value your time, learn from the experience.
It may be poorly put, but I think there's some truth to it: your most effective strategies for dealing with this kind of abuse are those that involve changes to your own behaviors. Trying to solve the problem The Right Way (i.e. at the source) is high effort and low (or no) reward. I don't think advising the pragmatic approach here suggests that abuse is the fault of the abused.
> Grow a spine, have self respect, value your time, learn from the experience.
Having read the linked post, I sincerely doubt Adam Piggott lacks a spine, self-respect, a proper sense of his time's worth, or an inability to learn from experience.
We've found the same thing with other software we make. The free users and those charitable organizations and schools we give free licenses to, are the least "nice" in their technical support queries. Odd that.
There will be many explanations. One explanation not seen here yet:
People working for companies who pay are more likely to be well paid and both of (a) technically competent and (b) having empathy and some amount of charm as qualifying criteria to get that well paid gig.
It's no slam-dunk but it's more likely. People who work for organisations who don't pay are likely to be paid a little less and include some who are working a second choice gig because of some deficiencies in (a) or (b) or both. (L. is great but difficult to work with and we'll never find someone like that to hire to replace them.) As individuals they may improve their abilities in time, possibly dramatically too. The young, arrogant hotheads, sheesh. None of us were ever like that. Obviously...
The paying can be a fuzzy select for kinds of people who behave in particular ways rather than the paying itself causing particular behavior in a given person.
If you get something for free then it has no value.
Remember the last time you got an item for free. You probably didn't worry too much about it, because it didn't cost you anything. You didn't treat it that carefully.
Compare that to something you bought for yourself, that you had to work hard for. You probably took a lot of care for it. You probably really paid attention to ensure it didn't break.
I feel like this is the mentality difference. Something free = no value = we can treat it badly. Something not free = it has value = we are more careful with it.
The nicest customers I have for my Saas product are also the ones who have the largest accounts. The ones that pay $15 a month for a single user on the cheapest account are always the ones asking for a list of like 50 new features to be implemented yesterday or "the product just isn't gonna work for us". Yea ok, because your $15 buys you a right to own my entire roadmap... not.
I think you’re partly right but it’s not the whole story. People (not all but many) notoriously treat service/public facing workers horribly. The same people also treat those workers’ supervisors with more respect, or at least with less aggressive behavior.
They’re paying for whatever product or service they went in for. It’s not because something is free, it’s because they’ve designated certain people as servants.
I think there’s a pernicious attitude that the “free” part of open source is an entitlement to service, and that the people providing it are servants.
I was going to write the exact same thing. It's even more extreme, I generally have much more problems parting with a gift, even if it is genuinely useless and holds no particular emotional value to me, just because it was given to me.
It might make sense but personally I tend to complain and ask for improvements if it's something I paid for, because hell, I PAID for it, I want it to work!
If it's free as in beer, I care less about the quality (usually I thank the authors for releasing it for free).
I don't agree with the generalisation to private possessions.
Apart from gifts, as mentioned by another commenter, I often seem to value things higher and be more careful with them when I know they're valuable and I got them without having to pay.
Setting aside emotional value I guess monetary value is a good estimate.
An example would be when I, through a misunderstanding, received two copies of a $16 promotional Magic card for free from my local game store. I tried explaining that they gave me something way more valuable than the free 30 card deck I had a code for. They just threw in that free deck as well and didn't want to hear it. The cards have since decreased in value somewhat, and I have other much more valuable cards, but the story of how I acquired them somehow make those cards feel very valuable to me.
Does making someone pay change that specific person's behavior? Or is it that raising your price just filters out certain people? Perhaps the remaining people would have been nice at any price?
> Make someone pay for software and they always treat you far better.
Indirect correlation if you ask me.
"Consumer" users are most likely to behave as consumers, ie not being interested with the project but their work getting done. Open source distribution channels are often independent from the actual project management, opening the possibility for varying degrees of quality.
Paid for bugs are more irritating than free bugs. Consumer support is rare for "paid for" software (good luck getting support from Apple radar, google services, iOS App Store ...) where open source projects provide forums, issue trackers ...
I suspect this is related to the phenomenon that people often quite strongly need to justify their purchasing decisions, leading to fanboism (I know that free systems also have fanboys but I think there is a difference in the type).
So if people made a monetary investment they have the emotional need to justify to themselves and others that they made a good decision (hence you talk positively about that purchase), however somehow when they use something free, people don't feel that emotional need.
I think it's important to point out that "being nice" also involves making room for people that might come across as rude, or that have difficulty expressing themselves in a polite way, or that are just speaking directly. I often get accused of being rude in my writing because I am direct. I've known lots of people (especially devs) that don't really understand that their phrasing might be interpreted as rude. If someone is clearly just lobbing insults, that's one thing, but we also have obligations to be charitable when interpreting others, and that charity often involves couching their expression as an attempt at being "politely informative." I would also say: unless it's flagrant, learn to deal with it. It's important to be able to deal with people, and that involves dealing with unhappy people, people who are stressed or at wits end, and so on. It goes both ways.
> It's important to be able to deal with people, and that involves dealing with unhappy people, people who are stressed or at wits end, and so on. It goes both ways.
That's a good rule on thumb, provided that the initiator is willing to reflect, take responsibility and repair any damage caused when the receiver indicates that their communication wasn't received well. Or, if the initiator isn't willing to do that, then being able to disconnect peacefully without judgement and further harming the receiver. "I'm sorry for coming across that way" is a pretty simple way to acknowledge the receiver's experience without feeling like you need to change or that it was your fault. It's amazing how much damage to relationships comes not from the initial blow, but rather the insistence that no blow was delivered.
Many times I've seen "straight shooters" be received poorly and result to calling their receiver sensitive, etc., rather than accepting that the "straight talk" doesn't work for that person and that neither one of you has done anything wrong, it's just that the two styles aren't working for either of you. Or vice versa when an initiator tries really hard to "soften the blow" with slow, peaceful words when it ends up being more torture for the receiver than just spitting it out with whatever emotion comes with it.
So, I agree we should all be charitable, but we also shouldn't settle for "well, that's just how I am" because communication can be a practiced skill.
As one example, a direct-personality coworker of mine learned to compensate by asking others for feedback before sending emails (or at least important ones to others outside the team).
As another example, I've seen people with http://three.sentenc.es/ in their email signatures, and this makes it clear that the brevity comes from valuing the time of the reader.
I strongly recommend being kind and polite, avoiding personal attacks, in all spaces.
> “How can you write a piece of software that doesn’t do y?”. “It’s 2021 and you still can’t make a program do z, how pathetic”
Leaving aside the attack with “how pathetic”, I can understand these sentiments from people who have been following the developments (or lack of it) with Signal for several years. That the main developers brush aside requests that are important for most people or ignore them and don’t respond on those would make it quite frustrating for the users who care enough to write.
Signal could do a lot better in connecting with the community of users who care to connect. Remember that the users have a stake in this, so dismissing their feedback as “this is free, don’t ask for more” is actually condescending. Without users and users who evangelize the product in their circles, no such project can expand or thrive.
Signal team, you could also practice being nicer and more attentive.
Hi there, Signal Android developer here. I'm sorry if you've had any sort of negative interaction with Signal in the past. I would personally never dismiss anyone's feedback on the grounds that this is a free app (the linked post was written by a very kind community member, not a Signal employee, but I also don't believe they were being dismissive either). Given that Signal has no metrics, feedback provided online is one of the only tools we have to know if we're working on the right things.
That being said, we do have a lot of feedback to comb through every day, so if you don't get response (or get a short one), the intention is not malicious -- it's sometimes just a result of having too much to read and too little time. But we truly do read nearly everything (particularly on Github), even if we don't have a comment on everything. I hope you continue to provide feedback!
I feel this goes beyond simply not providing a "feature", but rather it is actively harmful to users, especially in combination with unreliable mobile/desktop sync. It means that people get their memories destroyed, without warning and without recourse.
Would you be willing to have a conversation with me over email (address in profile)? I would like to discuss what can be done about this, and I would be open to compensating developers for their time.
Yes, unfortunately this is inadequate. Note that only transfers to other iOS devices are supported, and also “your old device will delete your message history after the transfer is complete”.
I've read similar sentiments before. After reading between the lines it's often clear that the developers have not brushed aside a concern or ignored a request. Sometimes they've actually explained their side, but a user has not bothered searching and reading forum history, they've simply sprayed their keyboard into a text box with unreasonable and rude remarks.
If I get a terse reply that says "We know this is a pain point, we're working on it!" then I take that in good faith and leave it be. But some find any reply an excuse to fuel their ranting.
There are definitely some areas, particularly those of principles, where the foundation makes a hard line clear. Even if this goes against what I think is best, I respect their clear message that this is their stance and it's staying.
Lastly I feel your remark that the team could be nicer is flagrantly unfounded. I have never come across any user being treated unkindly and without the attention one can expect from such a skewed user:resource ratio. I'm dismayed you've taken something I wrote for good and blemished it with an unfounded reprisal.
I also am extremely frustrated by the inability to export and backup chats. In combination with mobile/desktop sync problems, it means that I have lots of personal memories on one device, with no way to get them off and protect them.
There was no warning when I first installed Signal that the usual phone backup mechanism (via iTunes, in my case) would not backup this data, or that mobile/desktop syncing problems might mean that hundreds of messages just don't get synced to my other devices, and that this is expected behavior.
So I'm angry, and I can't recommend Signal to others for this reason. And the devs just don't seem to care.
I appreciate that it's an open-source project, and the developers have no obligation to develop new features. But this isn't really a feature request; certain sharp edges in a product are actively destructive if you don't warn the user about them. It's like someone handing out free food which turns out to be poisonous, and then saying, "What are you all complaining about? The food is free!"
If any Signal developer sees this, I would personally be happy to have a discussion about compensating you for your time to fix this problem for the community. My email address is in my profile.
> So I'm angry, and I can't recommend Signal to others for this reason. And the devs just don't seem to care.
Could have just been: "I can't recommend Signal to others for this reason."
I read the "Please be nice" post as a request to leave out the part about being angry or assuming that the devs don't care. It is understandable that you feel that way, but saying so doesn't fix your issue. It does make other people feel bad.
I guess I’m just saying I don’t think it’s a reasonable request, and this was my way of politely explaining why. It’s okay for users to express anger over something like this. The fact that devs are doing volunteer work is great, but it doesn’t exempt them from certain responsibilities (see my food analogy).
If you have an Android phone, yes, I suppose you can backup. But I don't.
There's no backup procedure for iOS. There's a migration, but the phone you're migrating from has to be working at the time. So if it's destroyed, you're SOL. Also, it's really buggy and has never worked every time I've seen it attempted.
The desktop instructions do not describe a backup. If you try to copy your old data over to a new machine in an attempt to preserve your chat history, you will break things. The procedure doesn't describe how to make things work, but rather how to unhose things once Signal has prevented you from doing what you want and blown up in your face to punish you. There is a way to export from the Desktop client, but it involves using sqlcipher and is an undocumented, unsupported, discouraged hack.
I often find myself thinking the same about other projects.
A good example is Nextcloud, who keeps growing its feature list, but never implements any of them properly. It's a fair line of questioning when your Nextcloud install borked itself for the third time in a year, and Android synchronisation doesn't work reliably.
> Signal could do a lot better in connecting with the community of users who care to connect. Remember that the users have a stake in this, so dismissing their feedback as “this is free, don’t ask for more” is actually condescending. Without users and users who evangelize the product in their circles, no such project can expand or thrive.
> Signal team, you could also practice being nicer and more attentive.
I've been interacting with Signal and observing Signal interacting with people for several years now and I have observed the opposite of what you're saying here. They are nice, they are attentive, and they do a great job of connecting with their community. They don't always do what I ask, and that's OK.
I will be a little provocative even, and say that you're deliberately misrepresenting what has been said in their post (dismissing their feedback as “this is free, don’t ask for more” is actually condescending) - that's bad faith, and maybe their post is aimed at you. It will be beneficial if you attempt to separate the emotion and try rereading what they have said.
Basically Signal doesn’t clarify to users that their keyboard is quite possibly spying on them, rendering all of Signals security moot if you’re trying to steer clear of spying governments. In practice this means that Signal is completely owned for most users in China if they use their phone as Chinese users normally do.
I keep hearing people say “use signal, it’s secure” and very few people also say “and the keyboard may render all of that security useless”. Thoughts? Naomi Wu has expressed recently that she feels totally ignored in this issue. Almost as if Signal doesn’t want to discuss it.
On the one hand, there is nothing on a technical level that Signal can do beyond what they’ve already done (linked in the twitter thread, set a flag that the installed keyboard may or may not respect). Anything beyond this is venturing into providing a general computer security 101 course and/or telling you how your mobile OS permissions work and/or region-specific opsec advice. I’m not sure they’re equipped to do that or if they are even the right people to do that. They are a small team and they most definitely do not have somebody embedded in activism of any kind in the sinosphere, which I think is what it would take for them to actually responsibly give region specific opsec advice.
On the other hand, I think it may be quite reasonable for them to say, very clearly, “use your system IME to input text”. It’s a very simple guideline with reasoning that I think can be understood easily by most people. They have a privacy/security section in the FAQ on their site; something like this could go there.
But of course if they did that, they would have to keep managing expectations around how much to delve into the security model of every platform they run on, and how many resources they can reasonably dedicate to usage scenario support. Their mission and product and user requirements are really unique; I’d love to be a fly on the wall of a signal product management meeting lol
I’m basic and use my iOS system IME to text in chinese, but also I’m a basic overseas chinese. Maybe I’ll have to survey my friends and family for what keyboard they use...
Yes. I think at this point Naomi is seeking official recognition from Moxie that this is a flaw in the overall system. I think she feels that she has been unfairly ignored, and she also knows people who she believes have been kidnapped by her government because of this flaw. So it’s a very real and visceral issue for her and she is also a very high profile person so it seems wrong to ignore her. I believe her recent Twitter frustrations started when she noticed that Signal responded to questions from some very small Twitter account, but still hasn’t responded directly to her.
If, due to factors outside of their control, Signal cannot actually guarantee that your conversations are secure, it may be irresponsible of Signal not to make that more clear. But one can understand why they might prefer to avoid the issue...
I think it's completely unrelated to Signal, to be frank.
> Naomi Wu has expressed recently that she feels totally ignored in this issue.
Yeah; I'd ignore it too if it was reported in a bug bounty programme. It'd obviously be out of scope.
It reminds me of the "but users might be running malicious WebExtensions!" argument (one of many!) I keep seeing in the Signal community for not implementing a proper web client (along with "but the PKI might be compromised and the JavaScript might be backdoored!"). They might be running a compromised OS too! Hell, their phone might have an entire ARM-based listening device inside the case. Security is always relative, and if someone reading "Use Signal, it's secure" doesn't understand that then they have bigger problems.
It basically boils down to "your fancy lock doesn't fix the person-sized hole in my door". She seems to be expecting the Signal devs to develop an entire Chinese IME. Why should the lock company have to also make doors?
Somewhere in the middle there she gets rather rude and starts accusing Signal devs of only caring about western users, as if there is a double standard. But there isn't: Signal doesn't provide a keyboard and keylogger detector for "western" users, why should it for Chinese?
I think this is the core part where Signal decides what it wants to really be:
* A messenger for activists, whistleblowers and other people that might be hunted by governments.
* A decently secure messenger for everyone that provides an alternative to WhatsApp, Facebook Messenger and other major corporate platforms.
Because in these cases those two goals are opposite - IME is the most fundamental way how people interact with a messaging app. Switchin it is very hard because users have muscle memory connected to an IME and IMEs vary wildly in their language support and typing experience,. Messing with it (blocking it, forcing people to use another) will make a lot of people refuse to use the app. Not messing with it will make activists mad and result in bunch of "Signal is crap for proper security" posts.
They need to choose. And sitting on both goalposts is the worst option here.
It doesn't have to force it. One of the proposed things has been making one of the on-boarding prompts give on-boarding prompts and point this out to the user - giving people who expect security of the first level based on how it has been presented to them the chance to realize they don't have it, and react.
Seems more like a core OS issue than something Signal specific. iOS at least disables keyboard apps' network access by default, Android users seem to be screwed (as usual) unless they root the phone and install a firewall..
I think the issue is that Naomi is seeking official recognition of this system flaw but signal and moxie have not done so in response to her questions. I think “signal creator acknowledges that signal is not always secure” would be a headline that would help non technical people understand this system flaw.
Why do you say that. You are free to block any app on Android from accessing the internet, including keyboards, from the standard Android settings, no root or anything.
Because what GP points out is that in China everyone uses Baidu's third party keyboard. So Signal alone enough is not enough to ensure safe communication.
This isnt a signal problem, its an android problem. I don't see how Signal could fix it, short of developing their own keyboard for their own app only but that would break a shitton of android accessibility features.
I was the original architect (but no longer maintain) a fairly ambitious FOSS project that is the worldwide standard for a very particular demographic.
That demographic is notorious for a propensity to be “not nice.”
I kept it going for a decade, sometimes receiving rather...strident...”feedback.” I was called a tyrant (and worse) for refusing to deviate from its Core Mission, in order to make it easier for certain individuals to use in narrow contexts (that type of request is quite common, if you manage a general-purpose infrastructure project).
I learned (slowly) to be polite and respectful in my responses, even when approached in an abusive manner. The times I “hit back” (I’m good at that) were quite self-destructive, and did not do the project any favors.
My tyranny paid off, but it took a while. The project has been handed over to a team of really sharp folks that will, hopefully, never have to deal with the kind of crap I put up with. They will get a great deal of positive feedback, and very little of the asinine, juvenile garbage I got. That makes me happy. They don’t deserve it, and I’m grateful they took it over, making it much better than I ever could.
It was worth it. If I had to do it all over again, I would (but I’m glad I don’t have to). I’m a tough, stubborn old coot that can take it, and I knew what I was getting into, when I started (I’m quite familiar with the demographic). Even so, there were a number of times I wanted to bin the project and walk away. I’m glad I didn’t (and there’s many thousands of people that are glad I didn’t, but don’t know it).
Sometimes, we do stuff for reasons other than money, property, and prestige.
It’s an old reference to Usenet and AOL. It used to be that many Usenet groups had problems every fall when new college students would discover Usenet after getting internet access for the first time at their university. In general this meant posts that went against the norms of many groups. It would usually straighten itself out after a few months, but in general, September was a rougher month.
Then, sometime in the mid 90’s (maybe 95?), AOL gave its users access to Usenet. This meant a steady flow of new users who didn’t adhere to norms of the newsgroups. Therefore, the Eternal September.
Same concern now as it seems like everyone is discovering Signal. I’m not sure how much I agree as signal is primarily small group chats where norms can be better enforced.
This is about tone on the Signal Community Forums, not within the Signal App. As Signal is an encrypted chat app, there is no Signal culture within the app that could Eternal September.
No i meant in the community forums - since there’s likely been a large addition of users in the past few days due to WhatsApp. I suspect a decent chunk of tech forward people have moved.
So I was wondering it if was Eternal September for the forums.
But I think I see where you are coming from = there is a finite number of people who will come to a coding forum, not an unbending wave, which would make Eternal September less of a good fit.
Is this a typical outcome of an open-source project that gains widespread popularity? It's a trend that popular projects get criticism that is too personal. This is a tricky problem. The obvious answer is to be anonymous on GitHub and not care when complaints get too shrill. This hurts the professional value of being an open-source contributor. How to achieve a balance between this and the need to insulate oneself from haters in the (unlikely) case your open-source project hits the big time?
I recall a similar story, I think it was the guy who wrote the Python library for the Raspberry Pi GPIO pins. In his case, I think he used his main email for commits and that was included by the Debian package maintainers who refused to change it.
While people should be nice, maybe it's time for Signal to hire a professional community manager. If developers do support on such forums (who else would be disappointed by unilateral demands?), it is a productivity killer.
For example, when people demand something from Telegram, their response is usually brainless "I'll pass that to developers" or something slightly more witty like "it's planned for 2301, watch for updates". Everybody's happy.
How do you look up an original post in twitter that they replied to? If I tap on “in reply to @“ link it just shows their entire feed. Thanks in advance!
Usually original tweets are just shown in the feed, but if you click on the tweet body, it will explicitly unfold the thread, if I got what you are asking.
I'm in the unique position to interact with clients from the 3 digit to 8 digit ARR range, and it's so hard managing expectations across the group. All of these clients are massive, it's just a matter of what stage of adoption they're at with us. More 0s = all hands on deck, two 0s = "I can't give you any kind of timeline and may never be able to". All of this is to say please be kind, it's generally not up to the people you're yelling at, even if you're paying for it.
First, I suspect a lot of new Signal users are the Reddit/Twitter terror assholes from thedonald.lose and other similar suddenly exposed rock bottoms that have been forced to relocate over the last week or so. Ignore them, ban them, etc. Don’t let ANY of that bit of animated shit pukes that mumble like they’re semi conscious bags of bird shit bother you.
2nd point. It’s ok to say no. Proof in point, I’ve been running jsonip.com for 11 years. Service supports many many millions of requests a month. Completely free.
I’m lucky, I don’t frequently get any hate mail or “add this new thing asshole” for the service. But any time I have over the last 11 years, I’ve directly told those people to shove it if they’ve been rude or demanding.
They’re using my service for free. I’m paying for this out of pocket. Fuck you if you think you can abuse me.
Just to round out, since I’m obviously very suave about language and what not, stop being nice. Stop letting a lot of free loaders ruin your day and kill your mood and passion by treating you badly.
There is an equivalent to the no shoes, no shirt, no mask policy and retail store has for online stores and OSS projects. If the user/customer can’t adhere to extremely basic human decency norms, they don’t get to play. You tell them to fuck off and go away, then move on with helping people that actually give a shit and are nice.
> Don’t let ANY of that bit of animated shit pukes that mumble like they’re semi conscious bags of bird shit bother you.
LOL. Appropriately eloquent. And I'm not being sarcastic!
The number of times I've gone to reply to a post somewhere to tell someone "You don't get candy if you're a bad boy, go back to your room" but ten other, nicer people have already tried to positively engage...
You'll be glad to hear I'm not the one being nice. I flag/report, or if a thread is turning sour tell them they're on their own if they try to mistreat me. This is why I don't mod any communities because too many people would get the same treatment the lamers did on IRC: I'd kick them out the door and get on with my day. Seems that's out of vogue these days.
Hah. I’m with you. Even used to do the same thing on IRC years ago.
I’m firmly of the opinion we (general collectively) of the mainstream have bent far enough back and tried too hard to accommodate the ignorant for too long. No time for that shit anymore.
Oh and I’m hell when I host an Among Us game. If the randos don’t catch on quick, boot put the hatch!
A good solution might be an "exponential back-off" temporary ban.
In this, an open-source project adopts a policy that the mental health and wellbeing of its developers is a priority, and in particular abusive language from end users is not accepted. Specifically, if a user communicates with such negativity (e.g. commenting this way on a github issue), two things happen:
1) That comment is deleted
2) That user is prohibited from posting on this project's issues for 30 days.
That's for the first offense. If, after 30 days, the user does something like this again, they are temporarily banned for 60 days. And then 120.
You get the idea.
If you don't like 30 days as a base, then it can be 24 hours, or 90 days, or whatever the project decides is appropriate. Regardless of these or other parameters, this strikes a balance between accepting needed feedback from the community, and "canceling" someone from contributing useful feedback in the future.
In fact, I bet you this will have a role in conditioning certain people to communicate in more nurturing and kind ways. A permaban would likely NOT do that, but a short temporary ban that increases on repeat offenses probably will.
I am not sure if Github supports this already, or provides some mechanism that could be used by the project maintainers to manually implement it...
But if you are developing on any platform where end users sometimes communicate toxically with volunteer developers just trying to make the world a better place, maybe this idea is worth considering.
> Just scroll past if something isn’t nice or offends you.
It's easy to dismiss this argument as it's obviously weak (it doesn't make any sense) but it sure seems to be a popular thing to say. Why do people think their right to act any way they want supercedes the right of others to not have to put up with trolls and jerks? Do these people have social problems, are they legitimately not smart enough to see the problem, or what is it?
> this argument as it's obviously weak (it doesn't make any sense)
It's the only mature and sane thing to do. Otherwise, what's the alternative?
> Do these people have social problems
I have a theory split in two parts:
1) Because it's online/remote and anonymous: I think that in 99% of the cases, when face-to-face, the toxic persons wouldn't even dare to say what they say online.
2) I learnt that most of the times toxic persons are in the 15-25 years olds range. They are just kids that do not know any better. If a 15 years old kid starts to insult me in the street, I'll just ignore him. It's just a kid.
Maybe because trolls and jerks have no goals beyond heating the discussion? Most calm and constructive forums and mailing lists I’ve ever seen had an unwritten rule (written actually, but who reads ‘em, right?) to ignore “hot” messages or at least the hot tone in these. It doesn’t prove that it’s the only way, but once the reply is done, every other user feels urge to add to that, because it is in a human nature that something said repeatedly or upvoted has more weight than something stated once, but it is harder if you’re first (crowd psychology). It is a culture of a public place (a thing that supports healthy cooperation) and they have to learn it, no matter how strong is their desire to respond.
One forum I'm on has a very strong community standard of "This place is like a local pub. If you show up mouthing off you'll be called on it by the regulars who may all look like they're shit talking each other, but who have mostly spent time together in real life, and who as a group have each other's backs against outsiders. If you keep it up you'll be asked to leave, possibly if needed by the managers (forum mods) who'll ban you for a short or extended time."
It works remarkably well for that particular group of people. It's almost certainly turned a lot of people away who _may_ have pulled their head in and become contributing members of that community, but largely they don't care too much. The forum has stayed small (it was recently characterised only a bit unfairly as "12 cranky old cunts" by someone who wouldn't/couldn't live up to the community standards there.)
> "Why do people think their desire to act any way they want supersedes the desire of others to not have to put up with trolls and jerks?"
There are two answers to this question, a "not nice" answer and a "nice" answer.
Answer 1: Because it does. Freedom of speech is more important than "your desire of not putting up with things you dislike"; so yes, the rights of trolls do actually supersede the comfort of the trolled.
Answer 2: It doesn't really matter. Just ignore the stupid trolls and go on with your life.
Freedom of speech is genuinely important. Critical even.
But it certainly does not extend to my lounge room, Your right to freedom of speech does not mean you get to act like a troll or jerk in my house, or to expect to be able to behave in ways you think I should "just scroll past". You will be asked to "be nice", and asked to leave if you choose not to (and ejected of you continue and refuse to leave). Your "rights as a troll" do not superseded my comfort in my home.
Your (assuming you're in the US) "Freedom Of Speech 1st Amendment" rights mean your government may not pass laws to inhibit your free expression. It does not mean your choice to freely express yourself will be free of consequences (as the well known "yelling 'Fire!" in a theatre" example illustrates), nor does it mean that owners/managers of private spaces are required to put up with your free speech in their venues.
Whether an internet forum is closer to a private home or Speaker's Corner in a public park is a good question. But claiming the forum regulars and owners should "Just ignore the stupid trolls and go on with your life." is not the only possible answer to that.
It doesn't validate it the slightest, but it is a common problem that people claim to be abused if they don't like the content, which results in obvious problems.
Minorities profit most significantly from freedom of speech.
I think the community forums will have to rapidly evolve to deal with the influx of new users.
If you look at successful, very large internet communities, almost none of them look like traditional forums.
I think wiki-like features could be important here, so that users can maintain high-quality references to point to during discourse. For example, reddit has subreddit wikis, and stack overflow allows questions to be repeatedly edited by the community.
I feel like this is more a sociological or even philosophical question but why are users like this, in particular for something that is free? Sometimes I wish we were more grateful for things instead of being so damn entitled (about a free service, nonetheless!).
That reply that is on the bug report (literally the post about being nice) which accusing the author of needing to "man up" is too on the nose.
Ironically I saw that dedicated, talented people who toil away for open source were being abused so badly that they left. I decided to put my head above the parapet and do something I don't like to do: preach. Figured I'd get some people shoot me down or start mouthing off at me but I manned up and posted it anyway.
It works both ways. I'm not addressing the Signal project in particular, but maintainers of free software projects need to be polite and professional (in words and deeds) as well. Users who take the time to investigate bugs and get involved in fixing them don't have "infinite resources to pour down the drain" either. Maintainers presumably derive some value, even if not monetary, from their involvement in these projects. Having more users than they can handle is a problem that comes with the territory of a popular project--and needs a solution just like the more technical ones. (I translate the term "toxic users" as modern-speak for "people who aren't exactly aligned with me".) I often contribute to alpha status free software, so I don't always gain reciprocal benefit--but I do like to help others. How many times have you seen an open issue or pull request on a project that isn't addressed at all after years? Often, in my experience.
Last year, I was working on my free software project, and I heard repeated blasts of a car horn from my driveway. I have advanced arthritis, so it took me a while to get up and go to the door--I wasn't expecting anybody. The car drove off before I could get to the door. The next day the same car was in front of my mailbox. The door of the mail box was drooping down. The car stopped on the side of the road, so I had enough time to hobble out and approach it. It was pouring rain--I had my shirt up over my head to keep the water off. I found out it was my new neighbor. She was doing improvements on her home and needed my signature on an HOA document. She said, "I'm disabled, and I need a favor. Also, I broke your mail box putting the document in it." I said, "I'm disabled too". She laughed, "Oh, I see."
The moral of the story being, Signal, be glad you don't have to deal with people who want something from you IRL. :)
People say: man up. I’d say let’s ignore the toxicity and go about our way. If someone wants to be an asshole, fine by me, but I’m not letting them take my fun out of my life. Therefore it would be good to have a way of hiding stuff that you don’t feel like putting your energy into. Sort of shadow banning but only for yourself.
"Man up" is great advice, but it's from an era where socialized interaction happened mostly in person. In those times, the consequence of insults was almost always physical violence, sometimes to the death in a formally arranged way.
Perhaps somebody needs to invent that device that allows us to punch people over the internet.
Yes and that makes me think. What if we could un-anonimise the internet for things like these. I think the anonymity of the internet makes trolls, toxicity, bullying and such much easier. Where if it’s your actual name that’s next to it, it influences your real life as well. Recruiters will search for your name on the internet and if you come off as a toxic bully, it’ll have consequences
There is empirical evidence otherwise, e.g. toxicity on Facebook. On the contrary, it gets far more personal if people know each other too and petty infighting dominates.
Recruiters looking up your name on the internet is awful. It got better, but a few years ago they haunted you to your last refuges.
Some people have their real names attached to their profiles, but I assume most prefer it the other way around.
Yeah, that sounds like an excellent idea. I would also add punishments (social media bans to start with, perhaps fines and even prison time for extremely serious cases) for spreading obvious lies.
It's difficult if you're seen as an authority figure, if you're one writing the code. Ignoring assholes could well simply inflame them further when they see other people receiving official replies, when their 42 posts have garnered nothing.
I certainly brush off the seething wastrels when they come my way, but I'm merely another member of the community and I have the luxury of ignoring them, flagging them, and letting someone else decide whether they should be kicked out or not. I really can imagine that if you cannot ignore these people (or have to add five people to your /ignore, every single day) it will wear most people down to a nub after a few years.
Developing a pleasant community, and developing the skills and environment to deal with angry people who use the project as their punchbag, is more valuable than the code. People who nice, pleasant and diplomatic are gold, and can help shape the community. They’re as valuable as your most skilled coder.
Maybe, there should be a Kickstarter for GitHub issues to prioritize them. You can prioritize them by money put in, and whoever wants their feature IMMEDIATELY, puts their money on it so, necessary resources can get allocated, and the rest can shut up about something not being done.
There used to be a Signal project on Bountysource with a bunch of pledged money, but I can't find it anymore. I had pledged. Odd, I can even find the PayPal receipt for my pledge.
One of the best parts of OSS is that if the maintainers don't have the time or the priorities to solve your problem you can fix it yourself and get your change upstream, or fork it. It blows my mind that some people can take OSS for granted.
There is a rising tide of hyper vigilance and explosive anger that cannot be escaped these days. I hope everyone can wake up and realize this - to stop it before it becomes the new normal.
(high) time to start educating children in schools regarding differences in software. preferably as early as primary school. so that every person on this planet better understands what is free, what different types of software licenses do. software and we never ever have to talk again about the offenses taken by people spending free time on software that helps the world spin in a more consistent way...
You overestimate the importance of software development and licensing in the life of the average person. Most people never interact with a software developer or even understand what they do, much less submit bug reports and feature requests to open source projects.
I've come to the conclusion in the past couple years that the world would be a better place if adults were forced to watch Daniel Tiger episodes. So many things it covers (like, how to be kind, how not to over react to bad news, how to give a proper apology or show gratitude) seem like they ought to be simple but turn out to be rare.
FWIW I’m very grateful to all the people who work on FOSS software. I probably wouldn’t be a software developer if it wasn’t for these tools and libraries. I often wonder how they all find the energy do it, I know I wouldn’t be able to contribute more than the tiny PRs or issues I’ve submitted over the years.
And that means it's OK to abuse them and their volunteer moderators? Getting a paycheck that big wouldn't make me feel better if I was having shit slung at me from all directions.
I'd have a more comfortable life but I'd still be getting up in the morning to go to work knowing I was going to open my inbox to weeping boils flinging their bile at me.
It means it's not okay to write poor-me post pretending you're some regular person who's sacrificing a pay check to work on a project simply because it's the right thing to do.
I don't work for the foundation so I'll accept your permission to write the piece. Thank you for your generosity. Perhaps I'll write a special section on why not to write comments on web sites while you're feeling extra-sensitive, preventing the need for you to bother commenting in this way?
if someone starts being toxic to me, I'll just let them know they have access to the source code like everyone else and that they are free to open a pull request if they wish to and close the thread. And that's the end of that.
If someone asks why, just tell them you don't entertain any level of toxicity.
The entitlement those people have is ridiculous. They are literally not paying anything for the service and come in demanding things.
It's funny that all these people moving away from WhatsApp (for no good reason, IMO. Facebook can't read your private or group messages anyways thanks to e2e) and think the free app they downloaded will have the same level of features as the one funded by a multi-billion company.
I think the word "kind" is more appropriate here than "nice". Being nice is shallow (surface-level, appearances, civility, tolerance...), whereas kindness is profound (empathy, connection, harmony, respect). The former is certainly better than nothing, but the latter is transformative and radically more powerful.
I agree but the article was written in a knee-jerk fashion and once I'd written the title I felt the need to repeat it a few times to help push the point :-)
Not sure what people see in Signal. Having the client be open source without having the infrastructure decentralized is pretty pointless and just sets it up for failing again when the organization controlling the central infrastructure starts acting poorly.
But that being said, if you don't like Signal, just don't use it.
For some of us, "the organization controlling the central infrastructure" is _way_ more trustworthy to not start "acting poorly" than any of the alternatives.
For me, Apple comes a close second maybe, but lack of interoperability between iMessage and Android makes it a non starter amongst my friends/family. Even assuming some self-hosted version of an E2EE messaging service exists and I could convince enough of my family/friends to use it, I then become "the organization controlling the central infrastructure" who risks "acting poorly" due to incompetence or lack of resources to keep that self hoisted infrastructure running and secured.
Signal is not perfect. I don't agree with all of Moxie's choices (I'd strongly prefer it not to need to be linked to a real world phone number) and I strongly disagree with some of his choices (I get angry every time a "$name (someone in my contact list) has just joined Signal" notification arrives.
But it's better than the alternatives for me. And for enough of my friends/family that it's my most commonly used comms channel outside work.
To me the end result of this shifting landscape is something which has the attributes of Matrix. Matrix may have issues, but it's architecture and implementation is very resistant to bad actors.
You can fork the server code and the server instances of matrix servers and have it work with existing servers and clients. Without this capability it is a matter of time until bad actors kill it and everyone moves to the next thing. The problem is that "trust" is not enough.
You trusting Signal operators more than Whatsapp operators does not fix the problem that we cannot run these services on trust.
Of course they can stop being nice at any moment and start doing nefarious things. But having the client open source means that when this happens, you can stop using it without data leaks, and until that happens, you can also be sure about the security of your data and exchanges. As a plus, you can run your own server for you and a group of friends/collaborators/whatever, if you wish. In my eyes that's a vastly better alternative than (I would say most, but it would be inaccurate) all the non-decentralized non-federative alternatives. Plus, their whole mission being secure messaging (as opposed to a nice-to-have side feature) will probably make it harder to do a full turn soon, I guess. Even if Signal is on to something eventually, I believe it does no harm to take full advantage of it while we can, as long as we are aware of a potential turn of events.
But also, if I fork the server, where central control can be applied, nobody else will be on my server. The client is only half the problem, and the most insignificant part in my view. I would rather have proprietary client with decentralized infrastructure than the other way round if I could only choose one of the two.
He co-founded WhatsApp with Brian Action. They both wanted cash but also felt bad for selling out WhatsApp.
So Moxie founded Signal and Brain contributed. A new clean room project under a non-profit with an endowment. Made as what WhatsApp should of been if they didn't sell out.
And to the commenter below he work for Jack Dorsey as the head of cyber security. And Jack supported this project from the get go. They probably like each other. Go figure.
I think this comment is low effort, malicious, and unreasoned.
There is a meta play at worst. Like, someone showering you with 1 million dollars, no obligations and no strings attached, but having an ulterior motive. But, as in that scenario, it's in our hands to make the best use of what we are given.
I dunno, I could select multiple pictures to share in Whatsapp for years, Signal implemented this when, year or two ago?
I can chat online in browser with Whatsapp for years, you still can't even do that with Signal, so not sure what features are you talking, but Signal is for sure lacking more basic features than Whatsapp.
I wonder if there might be any connection between a sudden rise in narcissistic personalities who feel a great sense of entitlement arriving on Signal forums and Trump-supporting lunatics who are fleeing social media sites which are now closing the barn-door after their horse has bolted :)
Considering the second response I received to that post was a spittle-flecked rant on how being nice isn't mandatory, made by someone with literally zero post history, I wonder alongside you :-)
Is the exact demographic I was aiming for when I wrote the post, with the aim of making them stop for a moment to gather themselves, before being part of the problem.
It's not just "being nice to devs" -- open source communities are utter shit for everyone.
My experience working on open-source projects, from a Product Manger perspective, is it sucks too.
To get it right, modern software takes a team. Everything from BAs, UX designers, QA, DevOps, etc.
But the projects aren't treated like a real project. Often it's a dev doing something on their own... often again it's to get away from the "team organizational structure" and just do something on their own. They don't get paid for it, they're just out to "hobby build" so why not play a bit. Test out some ideas.
But inevitably it's shit. They don't make decisions based on what's good for the customer (and the customers don't pay), they make decisions based on, "Do I have 20 hours to put in to get this right, or do I want to ignore the edge cases and just do the quick and dirty 30 second solution so I can move on to the next task I find fun?"
And the quality suffers. And that's OK, except the expectations are all set so high. "This is the open-source version of Microsoft Office!" or "This is a peer-to-peer replacement for Facebook!" and when a user hears that, and then goes to use it... and finds their expectations were totally mis-set... oof. They're pissy. "I put in all this time thinking it would do whatever basic thing Microsoft Office has done for 20 years... and it didn't do it... and I wasted a day trying... wasted a day looking at obsolete / poorly done documentation... and now I'm mad too!" Expectations need to be set better, and they never are. Everyone over promises based on a vision, not based on actual capabilities.
And when a QA person, or a product manager, volunteers to help... then herding devs, who "own" the project into best practices or a team-based workflow becomes a nightmare. Everyone is working on their own version of "off hours" on the project -- no way to sync a 9 to 5 schedule of any sort. Team meetings never happen; maybe you get together on Slack or something, but like very rare anyone is able to be like, "Hey let's all go bond and get a beer..." As a "leader" you can't enforce best practices -- and that's frustrating for everyone as the devs started the project to get away from management, and management gets burnt out trying to manage devs who don't want managers... Corners are cut, opportunities to bring in other talent are squandered because it's all about ego.
Long enough rant, but like... TL;DR: Open Source sucks. If you're gonna build something, start with a business plan. Make enough money to hire BAs to gather requirements, UX designers to build good flows, devs to build it, QAs to test it, managers to wear chinos, and support staff to handle the onslaught of shitty annoyed customers. And guess what, to make all this work... you'll need some sales guys too. Make it a business, you'll be a lot happier in the end. Fundamentally, if you're good at something... why are you giving it away for free?
Be Nice, but you can't really un-ring this bell. Fire is hot. Water is wet. The internet is mean. And working on Open Source projects is pretty much universally horrible.
Some Elon but also a huge amount of Indian users who are leaving whatsapp en masse and have a different culture of online conduct that many westerners aren't used. The replies on the signal Twitter account make this very apparent if you don't want to dig through the forums.
I'm up to 50 or 60 new Signal contacts since WhatsApp announced their latest privacy policy updates. (That's actual friend/acquaintances rather than just people I once added to my contact list like ex cow workers or clients/vendors - there's probably another 50 of those as well.) This is largely (but not exclusively) people in Australia.
Reminds me of the 2020 Hacktoberfest. Tons of users would submit spam PRs, when you'd close them and tell them to read the contribution guide they'd start personally attacking you.
TLDR don't ask devs/managers to do anything, they are just small company living of 50M donation and other donations
I mean FFS Signal didn't even allowed until 2018 or 2019 to select more than one picture to share and people asked about it for years. How long it took Mozilla to implement pull down to refresh on mobile version until 2020, 5+ years?
These devs WANT their product to fail, they don't want success, they don't want users, they just wanna get their weekly money and play and implement useless features nobody asked for. This is what happens with horrible management in Mozilla with Firefox going now extinct, Signal (pretty much same as Firefox not growing ant user base, even the uptick in recent days in molecule (drop would be overestimate) in Whatsapp ocean) and Wikipedia which is also spending money on projects completely unrelated to Wikipedia site, yet they dare every year ask users for donations to keep Wikipedia running without ads, while reality is they have money for years to run and if they didn't waste them on stupid things even longer.
I believe the Signal app should at least have a token fee. It can be donated to the open source community.
That would immediately get rid of the freeloaders and their annoyances.
The Signal Project's greatest vulnerability isn't technical but social. Contributors probably work in clean environments and follow special security protocols. Yet, their policies and procedures haven't considered emotional compromise by hostile attackers. It's a social hack, essentially. If any group wants to shut down the Signal Project, all they need to do is agitate overworked contributors in message forums.
User entitlement and harassment are major problems in FOSS, and I don't endorse it, even for Signal. But, coming from Signal in particular, this seems pretty weak. It almost feels exploitative of the real problem - harassment in FOSS - as an excuse for Signal to make self-serving design decisions at the user's expense.
Remember that Signal touts itself as a secure communications tool, with endorsements from the likes of Edward Snowden and Bruce Schiener. We should hold them accountable for delivering on that promise, or we risk the real human lives who choose to rely on a flawed tool. Signal has made several design decisions which reduce its ability to address the problem of secure communications, which are conveniently self-serving. When their arguments for these decisions have been debunked, and yet the self-serving designs persist, this is a bad look for Signal. They have chosen to weigh their self-interests against the user's security, in a tool designed for securing vulnerable users.
Signal is unlike most FOSS projects. They have access to resources which put them among the most privelged projects in terms of ability to execute on changes. The Signal Foundation has a war chest of hundreds of millions of dollars.[0] With a hundred million dollars, a full-time dev team, and 10+ years of development, I think we can expect them to have addressed many of the complaints ten times over, especially when similar systems have been built by volunteer teams in a fraction of the time. Complaints, again, which address ways in which Signal's privacy guarantees are lacking, and which Signal conveneintly benefits from leaving unsolved.
I don't think anyone should be mean or rude to FOSS maintainers, including the Signal contributors. Entitlement and harassment are huge problems in FOSS. However, I do think we should hold Signal accountable for delivering on its privacy promise, being good stewards of vulnerable people, and not compromising on this to chase after their own self-interest.
I feel like this comment, and others like it, start from a baseline misunderstanding of Signal’s goal, and extrapolate from there into a narrative where the Signal team is plotting the downfall of all that’s good and right.
Signal has been pretty clear that their goal is to create a messaging platform that provides security against the threat model faced by the vast majority of humans in the world, in a form factor that makes it effortless for those people to use it for their communications.
Specific technical details, like federation, are not their goal, and their assessment is that the side effects of federation actively harm their goal. You’re welcome to disagree about whether it’s possible to federate and still solve the problem they’re targeting, but it’s not clear to me why they’d be expected to target their “war chest” at solving something that they’ve always acknowledged is not their actual goal, based on message board commenters demanding they do so.
Yeah, there's something fishy with Signal, though it's been obvious for years that HN is one of its propaganda hubs.
The other day I described one of my concerns with it here [0]. I made no demands or anything like that (this is HN after all) yet someone chose to basically label me "entitled"... that must address all concerns, right?
Anyway, today I woke up and it seems this global campaign to ditch Facebook works, because some contact of mine added me to a group of "friends", people who "forgot" about me for years (because I'm not on any social network) and who had no idea what Signal was until now, who never knew or cared about privacy, but apparently decided to start using it this week. Neither he nor Signal asked for my consent, and now I'm faced with the unpleasant task of leaving that group and possibly hurting people because I never wanted to receive hundreds of vacuous messages every day. Thus I'm one step closer in my mind to moving to set up Matrix on my own server.
Sorry if this comes across as blunt, but what self-serving decisions has Signal made, how do they benefit Signal, and how do they compromise users' privacy?
I've found the opposite more often than not: Users are nice, but the maintainers are arrogant, unwilling to listen to your issue, close the issue without explanation, disrespect you for bringing something that breaks their product or shows a major flaw, nitpicking until cows come home with PRs, rejecting PRs for no reason at all (screw you for putting all this effort in the PR, right?), god-forbid if you ever talk about any drawbacks or issues with the license. Users are usually nice and other users moderate them if a wild one appears.
I think it's reasonable to critique the fact that OWS has received $100mm and I can't even add all my devices to my account (they limit it to 4 or 5, iMessage permits at least 10), or add any other phones (only tablet and desktop can be linked).
Being an asshole is unwarranted, but oftentimes one wonders where the money is going with that group. Their production is certainly behind reasonable expectations. We have stickers but not backup, we have some SGX thing for safe server contacts but video calls on desktop are still basically broken/unusable.
For that kind of cash they should have a lot more to show.
Have you got links to any complaints about how OWS is being run by the people donating money to them? (At least for non-troll sized donations. Sending them $5 by PayPal then claiming the right to define and prioritise their roadmap doesn't count.)
I'm not sure you are displaying "reasonable expectations" here, nor that your opinion on how much they should have "to show" carries much weight.
As always, you're welcome to 100% of your money back on your purchase of Signal and it's services if you don't like the product.
It's reasonable to criticize waste even if the waste isn't of my resources.
It's reasonable to criticize and editorialize even over squandered opportunity, something that is (in the case of such criticism) always someone else's, not your own.
I can reasonably think they're doing a mediocre job, given the circumstance that they received $100mm, even if it's not a dime of my money.
I think this attitude reflects much more on your misplaced understanding of what OWS are doing and why, rather than anything meaningful about your critizisms.
It's a _really_ poor proxy for most things, but they're the ones with $100mm of somebody else money. I suspect your opinion that they're "wasting" any of that is much more likely to be that you don't understand the goals, rather than the people behind _that_ much money letting it be "wasted".
You've demonstrated very little understanding of the reasons behind the problems you cite. Do you know the tradeoffs behind the decision to limit linked devices? Do you think OWS's priority on desktop video call quality is the same as yours, and do you know the tradeoffs they're making by choosing not to prioritise that? You pretty much admit you have zero clue how or why they're using SGX - which is one of that most innovative privacy techniques in the entire space (it's not perfect, but it's about as diametrically opposed to how Facebook et al do contact discovery as it's possible to get).
[Edit: It's also possible _my_ understanding of what Moxie and OWS are trying to do is wrong, and I'm crediting them for or at least giving them a pass on a lot of stuff based on that. But I don't think so. I've been reading their blog since they worked on an Android app called TextSecure back in 2014 or so. Moxie is a friend of a friend, and I'd eaten and drunk with him. I think I have a reasonable understanding, for an outsider, of what is important to them and why they're doing the things they do.]
I am quite familiar with all of the things you asked about, including the SGX server attestation stuff. I glossed over it for the sake of comment brevity; I browse HN comments on mobile and reply with thumbs.
I know their tradeoffs well; I also know the SF rumors I hear about the fate of their money.
I think they should have quite a bit more to show for it.
> As always, you're welcome to 100% of your money back on your purchase of Signal and it's services if you don't like the product.
When it becomes possible to change this to “100% of your time back”, I’ll be able to agree with such sentiments. Users invest time that they cannot get back.
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.