Signal community: Reminder: Please be nice
community.signalusers.org
community.signalusers.org
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.
Large corporations (which the $10k/mo user probably is) on the other hand calculate updates in months or even years.
My company also has a very large customer that asks us to implement something "whenever possible" and if we need 2 years they are just happy we did it. Why? Because they have a long update cycle. It's not really important if it's in the next release because they might not even install that but wait for the release after that.
The issue that undermines you’re (mostly correct) observations on slowing moving enterprise, is that they’ll often adopt technology before knowing if it will even work the way they want it to. So when it comes time to implement, you’ll find things that don’t work as described, often accompanied by some years old issue on their tracker which basically say “we might get around to that some time”.
“Enterprise grade” proprietary software is usually terrible anyway, so still prefer open source for the reason that I’m able to write my own patches for it (which I often do). But I find the open source attitude toward fixing issues, in software that your customers are actually paying a lot of money for, incredibly frustrating. There’s a particular maintainer on a project that I use a lot at work, and anytime I see his avatar on the forum while trying to debug an issue, I instantaneously know that my whole day is about to be ruined by some of the least helpful advice you could possibly imagine.
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.
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.
The company paying $10k can't change vendor overnight so it's in their best interest to stay in good terms. Also in his company, the guy you're talking to don't want to be "the guy who pissed off that key vendor".
You don't have to and shouldn't respond in any specific time period. Even if you're the sole maintainer of a critical project and you imagine the world wants your head, the world has to wait sometimes.
However, users may abandon projects where support tickets go untended, maybe even writing a post about it in the process[1], so try to respond when you can, unless you've abandoned the project.
As a representative for a FOSS project or even a bystander commenting on a PR, respond professionally and succinctly.
If you shouldn't accept a PR, don't.
If it's a request that seems hostile to the project, and you have time, either leave it for a little while to cool off, try to serve it with professionalism without getting off-topic, or at worst close it.
If needed, add a "code of conduct"[2] so that you can "encourage a pleasant and productive environment by responding to disruptive behavior in a fast, fair way"[3]. Note that instituting one before it's needed, while seeming proactive, may put off some users.
If you screw-up, apologize briefly, then fix it or move on.
[1]- https://medium.com/free-code-camp/why-im-not-using-your-gith...
[2]- https://docs.github.com/en/free-pro-team@latest/github/build...
[3]- https://docs.github.com/en/free-pro-team@latest/github/build...
And this can happen on HackerNews too! Here is a thread in the last week where 50% of posters from HackerNews were berating Microsoft for open sourcing all of VS code, but not open sourcing one of their free language servers (calling them selfish, anti open-source e.t.c.). I think this is the exact same sentiment.
https://news.ycombinator.com/item?id=25719045
So Microsoft open sourced all of VS Code, but didn't want to open source the Pylance language server (a separate product which is installed separately as an extension) which they provide as a free (as in beer). This is because Pylance is also used within their other (charged) offerings such as full Visual Studio and is a differentiator from their competition in the premium space. Also they have hinted that it includes some proprietary secret-sauce that they don't want to make public.
Bear in mind that Microsoft is making VS Code free and open source... here are some quotes from the thread:
> I find it what they are doing to be dishonest [...] the consequences of their actions is that people who dislike them will talk bad about them.
> [Microsoft] have the right to be two-faced about their open source policy, I have the right to speak about how I think it's bad to do so.
> They should please stop acting like they are the second coming of christ for open source [...] they are misleading their users.
> Microsoft proved that they only care for OSS [...] because it enables them to spy on coders and their code to develop proprietary and closed sourced spins for software development product. The OSS community got served.
> Microsoft always does this, they fool people by pretending they’re in favor of open source or make something free but it’s just a trick used to bait and switch people into the proprietary anticompetitive Microsoft ecosystem.
> Seems like Microsoft is back to pissing in the public pool.
Also, a megacorp is not a person (no matter what the law may say).
Being abusive towards individual developers should not be tolerated, but leveraging fair or unfair criticism towards an amoral entity? Eh, whatever floats your boat.
Or is it just 'be nice to developers in small companies, but you can say anything to developers in big companies'?
\s
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.
It does though IMHO.
Having access to the source doesn't automatically mean the owner/maintainer owes you nothing. I think the comment is promoting only the "FOSS == gratis" side of getting things for free ($0) and not considering the original "FOSS == insight and rights, even if paid for" side of things.
> "there can be explicit contract where you are funding specific feature"
Yes, I said as much when I said you can have a contract for support and also have FOSS software. Here, you are downvoting me and agreeing with me. There can be a explicit contract where you have the source source and also are entitled to some development that you're paying for.
> "You can stop using the software if it does not provide you any use. That is the only thing you are entitled to."
NO, here you are changing your mind again and narrowing it back down to "it was free so you have no rights". You cannot make the judgement that because someone has open source software, they didn't pay for it, and you cannot make the judgement that if they have open source software, they are not entitled to anything. The three are DIFFERENT things. The original point of FOSS was to avoid vendor lockin, not to get free downloads from Github.
In case it isn't extremely clear, downloading a free and foss tool from Github does not entitle you to feature requests or support. Donating to it does not either. Saying "every FOSS user has no entitlement to support or feature requests because the code is FOSS" is incorrect, and a bad idea for the programming/tech industry to be spreading, partly because a lot of developers would benefit from spreading the idea of paid FOSS because they want to work on it and get paid, and partly because users would benefit from the increase in paying for software and also getting the source as part of that, including whatever entitlement to support paying would have got them normally.
There might be such people, but I doubt such projects would be very successful or notorious. Being able to put something on CV does not provide that long lasting gratification needed to develop/maintain software in the long run. If it's about your CV only, then there are probably more effective ways to achieve better returns.
(In my case I don't put my F/OSS on my CV and I don't think I'm "extreme minority")
Maybe I just see an unusual slice of the OSS maintainer world, but it’s very common.
Yes, some open source software (like Red Hat Enterprise Linux) is run by a company and has an expectation of support.
The vast majority of free software, from the GNU tools like gcc to the linux kernel to clang, does not have that expectation.
All free software has a license that lets you fork it (by definition)... and that's where your reasonable expectations should end.
If you think the maintainer isn't doing a good job working on the right issues or maintaining the project, that's not the maintainer's problem. That's your problem. If you have the abilities to fork it and implement those changes yourself (realizing the maintainer does not have to incorporate those changes of course), go for it. If you can't, well, your expectations are totally wrong.
If a maintainer actively looks for "fame" or actively pushes more people to use their software, that does not mean they have to provide support. That does not mean they have to live up to some standard you've made up in your head.
They should make a reasonable attempt to uphold any specific promises they make, but that's about all they owe people, and if they promise to build a feature, then burn out, that's okay too really.
This is backwards. The maintainer is expecting attention and users. By alerting the maintainer to issues, I would be helping them (using my own extra effort, eg bug reports, feature requests).
The nuclear option for a user is to just throw their hands up, not even try to lobby the maintainer to make better choices, and quit using the project. The nuclear option for a maintainer is to completely ignore the user base whose attention they need and whose efforts on bug reports or whose frustrations give them free labor to understand their projects fault points and fix them, and instead say, “you’re not paying me with money, only with attention, time and effort, so I owe you nothing” (as if owing was any part of any of it) and ignore their feedback.
Either side can go for the nuclear option. But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports, etc. before “going nuclear” and gainsaying everything with “you don’t pay me in the form of currency so I owe you nothing.”
Do they? The projects I maintain I do so for myself and work.
> By alerting the maintainer to issues, I would be helping them
Do you? I need to weight the time and effort to understand your issue against my potential gain from it.
> The nuclear option for a maintainer is to completely ignore the user base whose attention they need
Odd, I don't need attention for my projects.
> as if owing was any part of any of it
You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".
> But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports
If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
Overwhelmingly yes.
> Do you?
Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong.
> Odd, I don't need attention for my projects.
Then why are they open source?
> You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".
No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc.
In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem.
These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”
> If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)
No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.
This is a bizarre viewpoint. The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it. They understand the technical restrictions that result in various tradeoffs. Users making feature requests rarely have the full picture or understand the technical tradeoffs at play, unless they implement or fix their issue themselves.
Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.
Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.
In addition, if a user feels like they're spending enough time to "put work into documenting issues/features" that they're net losing time after the savings of being able to use the project (vs implement it all themselves), then they should neither file issues nor use the project at all.
> Then why are they open source?
Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.
In fact, if you listen to maintainers, the vast majority don't want that crap.
Projects can be open source because "information wants to be free", or "I want my users to be able to fork it, they have rights", or "I hope someone learns from this", or "I want people to contribute code (but not dumb issues)".
For the most part, an open source project wants attention from a group of people - people who find the project useful already, and who are willing to not incur a maintenance burden.
Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.
> Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”
No, it's not more reasonable for users to complain unless the maintainer asks users to complain. If the maintainer has a contributing.md or a page on their site that says something like "please send me poorly thought out feature requests, hate mail, and entitled bullshit", then yes, users can do that.
Otherwise, the user should indeed take it or leave it. If the maintainer has a contributing.md saying "I might accept PRs", the user can absolutely discuss implementing a feature with the maintainer.
The default, if there's no documentation about expectations, is that it is 100% take it or leave it.
You seem to think that all open source projects are like RHEL, where a huge company runs it and all users pay thousands of dollars for support. In that specific case, yes it's totally fine for users to send support emails describing issues they ran into.
The majority of oss projects are not that. The majority are some dude who hacked something out and hopes other people like it too. If other people like it, cool. That does not give other people a reasonable right to expect that person to actually do any serious maintainership of it.
That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).
I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?
Your viewpoint seems quite foreign to the maintainers I've met, and I'm curious what has shaped it.
My perspective has largely been shaped by maintaining OSS projects, talking to other maintainers, and reading secondary sources on the free software ethos.
This is a bizarre point of view. The maintainer has only spent time thinking about it from the point of view of their lone preferences and opinion. Users come from all walks of life and are in the weeds with many use cases or blocking issues or bugs that the maintainer would never realize or think of if it weren’t for the free effort gifted by users reporting bugs and requesting features. It’s far more bizarre for you to assert maintainers are in the best position to judge over and above users.
> Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.
This is exactly backwards.
> Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.
No they should lobby the maintainer to prioritize it for the existing project. Forking and doing it themselves should be an extremely uncommon fallback or hobbyist special interest, not at all a default.
> Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.
> In fact, if you listen to maintainers, the vast majority don't want that crap.
You seem to have some mix of a superiority complex / poor attitude towards users of OSS. It sounds extremely obvious that you aren’t suited to be a FOSS maintainer if you harbor these biases against users. Have you considered taking your projects down? It might be a benefit for all parties to not have to experience this anger / belittlement issue from you.
> Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.
Nope, the internet doesn’t work that way. If you want to post your software project for passive consumption, people absolutely have every right to complain about it. You don’t have to listen but they absolutely have full justification to provide their take on the thing you published.
> That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).
It has nothing to do with being “entitled” to anything, for either party (users or maintainers). And this doesn’t matter if the maintainer is RHEL or some random guy that can spend max one hour a month on a project.
> I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?
Given the vitriol in your comments and especially the really abusive language you use to sweep the entire class of FOSS users under an umbrella of being completely stupid and dimwitted compared to maintainers, I do not for one second believe you genuinely want to engage in discussion or debate whatsoever. If I shared my own personal experiences managing FOSS projects for two past employers, I think you will just find excuses to unfairly dismiss it, make sniping replies and take various pieces out of context as you have so far.
It's clear to me we aren't going to get anywhere in this discussion. We're talking past each other. As such, I'm walking away from this conversation.
Likewise, I don't believe I am speaking negatively or uncharitably at all. I think I have responded in good faith and with due self-reflection and that my comments are fair reflections of what you are communicating. Looking back, I don't see anything I'd change or any place where I wasn't engaging with polite, good faith responses to your negative comments.
That's an interesting concept of compensation, does this apply in other domains, e.g. if I go to a soup kitchen which donates free food is my eating that food compensation?
I'm really trying to understand this argument.
Giving my attention to your FOSS project is compensation. In fact, FOSS is so over-saturated with options that giving my attention is high compensation. Project maintainers are lucky to have an audience of users and should value their feedback and create solutions for them, if they want the attention to continue or they want compensation to increase.
What doesn’t make sense is to treat users like they don’t matter, ignore critical bug fixes or feature requests to prioritize dabbling or recreational features, and disingenuously turn around and claim users are rude or should be shadow banned for stating justified frustration over this, all under the false pretense that just because the compensation is in the form of attention and engagement (similar to currying “likes” or “votes” on social media), and not currency, this somehow means there is zero social contract between maintainers and users.
If users are kind enough to express frustration in bug reports or feature requests, it means they are making an extra effort to hopefully not have to leave your project and stop using it. It’s an attempt at a constructive solution by letting the maintainer know there’s a social obligation problem happening. That seems way, way more positive and reasonable than a disgruntled maintainer immediately shrugging it off and going straight for the nuclear option of, “well if you don’t like it, leave.”
So your argument is that in compensation for your attention you are entitled to give uninvited criticism, or lets say tell them to play songs you like? Moreover, how do you assume that your criticism or the songs you would like to have played somehow take priority over other peoples interests? If I would be in the audience for some unknown band I certainly hope that people who don't like the music leave instead of heckling the musicians.
You are saying that maintainers have a "social obligation" by giving you something for free, so you are entitled to their time, because that's what it boils down to. To make another analogy (again admittedly flawed), would I be entitled to demand you reply to me, because I have given you my attention in this discussion?
I would maintain that in many cases it isn't uninvited, just unwanted. There are many repos on github that are just somebody's pet project they did for fun or because it filled a need for them, and they aren't inviting criticism because they just shared code in case anyone else could use it or learn something from it.
However, many FOSS projects are very much like the band analogy above in that they aren't content to upload videos of their jam session to youtube but actively seek to attract an audience. They make project announcements on places like HN, they show up in forums and tell people how blazing fast their project is and it's a good fit for someone's use case, they have fancy websites, etc. They ask for your attention, and in so doing invite criticism.
Of course you can ignore that criticism - that was never in doubt. But users are fully justified to make the criticism and it would be rude and wildly unreasonable to reply by saying, “if you don’t like it, leave.”
How would you prefer that kind of "arbitrary planning" be addressed though?
I don't have any luck with my FOSS projects but I am SUPER grateful for that because I just don't have the time to sit and work on them after I've done the job I have to pay the bills I also have.
Any advice for someone like me?
That's the 1 line summary of doing volunteer work.
If you want to enjoy working on FOSS, choose to solve a problem that lots of users need solved, the more mundane the better, then make your whole backlog focused on what the user tells you.
FOSS needs product / market (of attention) fit like anything else. Unless you are your own user for a real use case, you need other real users to be the sole driver.
But the only reward with volunteer work in FOSS is the fun you get out of it. That's your compensation. So if you don't like what you are doing, stop doing it. Don't try to mainly please others, unless that's what gives you pleasure.
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.
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?
"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'???"
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.
It doesn't hurt to write down the thought process. Of course some people can't be appeased and no reasonable explanation will be sufficient.
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.
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.
Honestly, it doesn't even need to be explicit, they just need to not be actively implying otherwise. (Eg, like gnome/gtk from the sibling thread.)
2. "Aight I step up to maintain the feature"
I seriously don't understand the expectant attitude of some users. You get what you pay for.
I find it funny how often FOSS advocates extoll the virtues of FOSS, only to turn around and silence complaint with statements like "what do you want for free?".
They don’t see their own toxicity. If they see the roadmap and their desired feature X isn’t there, there will just be screaming about that.
Edit: Or something like kickstarter, if enough people pledge for the issue it gets priority on roadmap.
Edit: I looked up if software is being developed on patreon and... so much NSFW stuff.
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.)
It's even better if you can get a bot to automatically reply and close it.
Not a foolproof way, but add a string in your Issue Templates that is required to be there, e.g. <!-- AUTOMATIC-CHECK -->.
If this is not present in the issue, the GitHub action just closes the issue with a message to please fill in the template if they wish to create an issue.
Doesn't catch nearly everything, but should get some and it's easy to set up. Could be interesting to go further with the idea and maybe check if each section contains text or something like this, hmm...
The rest of us feel bad doing that, especially towards someone trying to use something we built ourselves that holds some measure of our own pride or even self-worth, it feels closer to obligation. So we waste our time trying to help the characters that deserve our help the least, and we learn to develop a resentful version of that trait over a period of decades.
But then, a good bug-reporting system should be able to do such filtering?
I'm wondering if detecting abusive communications is/could be part of it, bit of ML seems like it would fit, even just some Bayesian filtering might do.
One could also train an NN to recognise images of the app (or simpler: OCR|grep) and require a screenshot with any submission.
But I guess automated triage mightn't be the best route. It seems very much a delicately balanced people problem.
The modern version of "Boxer the work horse should work harder".
What helps immensely (and I saw this in the Geyser MC project), the software can produce a snippet with all info the devs want with one command, and it even exports to pastebin taking out sensitive info. If you paste such a link in their Discord it even makes an overview with syntax highlighting in the chat. That really helps a lot on my (bug reporter) side. And thus on the dev side.
One of the great things with Steam when I started running it on Linux was it's debugging info that gathered details of your system so you didn't have to.
This is still the case. Every KDE application has the menu entries Help → About $APPNAME and Help → About KDE which both show the relevant version numbers. I'm overwhelmingly certain this feature never went away because I am on a rolling distro and upgraded through pretty much all versions and I figure I would have noticed the absence of these menu entries.
> then the bug report tool asks up front what version you're using
That's incorrect. The menu entry Help → Report Bug… opens a dialog with version information that has a button Launch Bug Report Wizard which produces a link like e.g. `https://bugs.kde.org/enter_bug.cgi?format=guided&product=kon...`. Consequently in the bugtracker, the available information is already filled in.
----
By the way, this post is an example for the bullshit asymmetry principle, and I resent that I had to spend a magnitude more time to correct your misinformation than it took you to produce it. Please be a better netizen.
There was a change, it was unhelpful. There were reasons, it was to do with changes in versioning on plasma frameworks - I could look up the details, but that isn't really important a few years hence.
The jist of my comment is that structures within an application can help us non-programmers to make useful bug submissions; I cited 2 examples from my real life experience.
Hopefully we agree on the basic premise I set out at least?
there's a game I used to play fairly often before updates simply broke it. like mission items were replaced with random fires floating in water. many users with the same issue reported it, and some like me even provided a save (which was never even downloaded)
all such tickets were closed with "cannot reproduce"
I'm not (their) tester, I don't have time to fully reproduce issues step by step, and I don't have access to a debug build anyway to figure out the bug trigger condition
"does not work" is the best I can say here.
If not then I can see the reason for your frustration, however it is not the same as free software being worked on (at least partly) by volunteers receiving the same lack of effort (or in signal's case nastiness) in bug submissions.
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?
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.
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)
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.
For example; the Angular repository has a "stale bot", which closes and locks the issue after a certain amount of time of inactivity.
This sounds great on the surface, however it's insane in practice. The users constantly need to recreate duplicate issues, as the original issue is locked. Most of the duplicates are not linked, so maintainers can't determine which issues are duplicates. And it also increases the friction of users notifying that the issue is still occurring.
Basically the result of "stale bots" is more duplicate issues and less engagement on old issues (as they're locked)
Moral of the story, use bots in moderation
That speaks to another issue of open source - it's more common than not for a user to report an issue with no intention of following up, nor helping to triage (let alone contributing). Drive-by issues are noise and take precious time away from maintainers. There again, stalebot steps in to help. YMMV but my personal experience is that we don't get too many reopens, and we don't get too many duplicates from closed issues.
I strongly disagree. Follow-up and collaboration are great, but someone taking the time to write a decent bug report is also valuable.
"library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
> "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
They could still be a hint that the documentation or reported error could be clearer.
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.
Multiple times have I filed an issue, that collects many people's "me too" and workarounds for over a year. And every month, stalebot comes and mentions everybody, so that I have to go and type in that stalebot command.
Until one day I give up, because I don't want to get those notifications anymore, or because I move to a more active project. The issue gets closed even though multiple people are affected, and all they can do is open a new one, link to the workarounds somehow, and take over the duty of fighting the bot.
Why make everyone do this? You say you don't owe me anything, but that's different from taking active step to hurt your community.
(and by you I mean stalebot users like andrew_)
We owe you nothing. You owe us nothing.
Play by the rules set in the project, fork, or don't play. The choice is yours.
If you can't take a few extra seconds to enter information in a template, why on earth should maintainers donate their time to you to triage what you're reporting?
As for the original point: I suspect every developer has encountered a bug in their code that couldn't possibly be caused by something, but ultimately was. Getting all the information requested up front in a regularly structured way, even when we think it's irrelevant, can make tracking these problems much easier.
Source here: https://github.com/andrewaylett/closedbecause.xyz, suggestions for reasons welcome, PRs even more welcome.
(Joke obvs. Sorry, couldn't resist.)
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
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.
So (1) Scrape the old, closed issues to a static website, link it from README.md. (2) Disable Issues in GitHub's repo settings.
Part 1 is somewhat complicated, because issue-to-issue linking.
But it's worse than that. Most people do not have the reading fluency to read more than a few words in a sentence without getting frustrated and confused. If your work peers and social groups consist of the 3-5% of people who aren't in that category, it can be easy to forget that.
Any time you can make something's function clear with one or two words and design, opt for that over explanation.
The average user might not be super invested in the application, they just know that something doesn't work, which is frustrating. If their only outlet for that is a bug report, the developers get overwhelmed with bad bug reports and users get the expectation that the developer is going to fix all their problems for them.
If the outlet is a feedback form instead, maybe the user can feel listened to in a small way and move on. The developer doesn't have to sift through a bunch of issues, they can just follow up if there seem to be any hot-spots that are causing a lot of frustration.
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.
You need to guide people to do the right thing based on the interface itself; people overwhelmingly don't read instructions.
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).
Many developers/admins use both FOSS and COTS, and feel the same low-effort interaction with upstream is okay in both cases. It's possible to educate a small number of your users (and to a some extent, you should try - for example your post here is a small step in that direction!), but that work is even lower-reward than answering those half-baked reports.
To deal with low-effort, good-faith user reports, in COTS scenario, you'd hire a support/TAC person (a team, eventually). For a popular/accessible FOSS project, it is possible to have something similar on a volunteer basis:
- set up IRC channel/slack/forum/mailing list for that;
- display a prominent banner asking to "please try support forum first" on your bug submission page;
- encourage people who want to contribute, but are not quite acing your codebase (yet), to hang around in the forum, help others.
However, there's this uncanny valley of somewhat popular, mostly solo maintainer projects where you get a steady stream of tickets (say one or two a week) yet there's no community to speak of, so everything falls onto you. It gets pretty annoying when you have a couple of these uncanny valley projects.
I’ve gone to a few GitHub repos to report bugs only to be met with a novel length template and just left.
Got no issue following a template to provide enough info to help solve a bug. But damn nothing worse than having a giant template with 20 questions.
Generally speaking, I don't even bother to file bug reports anymore. 70% of the time my issue is already in your issue tracker, sometimes has been for years, and nothing has been done about it despite multiple users giving you the logs and whatnot you've asked for anyway. I could be all "me too" in a vein attempt to convince you you really should fix this thing, but you're just as likely to be annoyed by the complaint and further deprioritize it in your mind.
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."
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.
No, please don't think like that.
Implement what you see fit when you planned to do it and you can ignore this.
1. You don't know how "toxic" people really are. Some of them are nice, but just put no time/understanding into their internet communication. They write and forgot what they wrote a minute later.
2. If they really need to learn something, talking to them politely "Thanks for the suggestion but...", "Could you please..." etc. will help over time. Not doing something in the fear of rewarding their behaviour is way too complex to understand.
A bit of a cop-out, IMHO. That's also true of real-life interactions: most people you'll talk to, you'll forget about 5 minutes later. I honestly don't remember if I said anything in particular to the corner store lady just yesterday, and I see her every other day. If I was a jerk to her, putting in thought or not, I was the asshole, final. Seriously, it's not that hard not being an asshole, just... don't be.
> 2. If they really need to learn something, talking to them politely "Thanks for the suggestion but...", "Could you please..." etc. will help over time. Not doing something in the fear of rewarding their behaviour is way too complex to understand.
Sure, treat people with respect. However, I'm not convinced it would be that guy's responsibility not to hurt someone's feelings, especially when that person was a jerk in the first place. I don't think we owe respect to someone who was disrespectful. The whole point is that dealing with it is a chore; having to take the time to educate people on their own behavior doesn't make it easier. I just think it shouldn't be _expected_ of maintainers to have to deal with it at all: simply closing the issue or ignoring the request should be seen as a fine response to asshole behavior.
I would have a policy of not allowing feature requests, only bug reports. Their demands gets immediately deleted. Either report a bug or GTFO - and make this the norm!
There's also the "polite" feature request, that's actually helpful. For example, a user wants a feature, and they ask if the developer would be willing to accept a pull request implementing that feature. I think this is respectful and better than sending the pull request right away.
Profit and user freedom are two different priorities. Sometimes they are compatible, more often they are not.
I am not at all money-driven; my current income is about €600/month, which is not much but a sustainable where I currently live, and in return I can work on open source/free software as I see fit. It's not what everyone would choose, but for me, it's good trade-off, right now away.
I wrote a bit about this over here last week[1], but I think we really need to think more about money instead of treating it as the devil.
[1]: https://lobste.rs/s/r5qaap/introducing_preql_new_relational#...
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.
The I read the Flappy Bird's creator story[1], I decided to stop reading the reviews all together, it's just too much stress. I'm sure a lot of users (the silent majority) appreciate and find the app useful.
[1] https://businessideaslab.com/flappy-bird-story-dong-nguyen/
> why doesn't the app do this? why is it free? are you selling our data?
These are all valid questions, in my opinion, especially the last two. Some of them could easily be answered in a FAQ section.
And no, I almost never leave reviews, so I am not one of "them".
We regularly get people giving us one star reviews and telling us the app is shit because it's not translated into Japanese, Korean, Dutch or Norwegian etc. I mean we'd love to translate it into all these languages but Norway isn't exactly the world's most dangerous country so not our main priority. We try to reach out to every user who contacts us no matter what and sometimes we send people the details about how easily to help is translate it if they can - but the usual answer is abrupt, unhelpful and dismissive.
I'm not sure how many of these things really have a toxic community per se. Instead I just wonder if you could more correctly say they have a "large community on the internet, which is usually caustic no matter the topic at hand."
What matters is 1) how you deal with things when someone is having a bad day (things can either cool down or escalate), and 2) how you deal with people who seem to be having bad days almost every day (i.e. assholes).
If you don't do anything then all communities will gravitate towards toxicity; simply because non-assholes will get tired of assholes and will stop coming back, and then all you're left with are ... assholes, and people with above-average patience.
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.
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".
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 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).
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.
---
[1] https://en.wikipedia.org/wiki/Wikipedia:Community_response_t...
https://slate.com/technology/2019/07/wikipedia-fram-banning-...
(I don't actually know if this would work, just a guess.)
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.
It is not perfectly nonpartisan, but compare it to the websites that are similar in popularity and you'll find there's no contest.
If you struggle with impulsive thoughts, anger, rudeness, you may be in need of a change in your ways, habits, and mental health. Try diet, exercise, and clean living to help your body feel right, but also meditate and allow your skill of executive function to take over. This secretary of the mind will stop you in your tracks, reallocating attention into better pursuits.
I think the key is decoupling thoughts from behaviors. It's one thing to think, "implement this basic feature already you freshman noob." It's another to let that thought pass away, without typing or saying anything.
To practice this, meditation is a good start. It teaches the simple noticing of thoughts, and practices not acting on them. And don't beat yourself up btw, if I get mean thoughts, I just laugh it off and notice the primates' mind within me. We are running aggressive chimp software 2.0, it's not very refined! You can patch it with meditation and healthy living.
I think everyone is realizing that software/tech doesn't magically solve fundamental human dynamics, no matter how much it fixes other problems. And that you need to have non-negligible resources dedicated to policing/enforcing rules so that we can have nice things.
And be grateful for those who do.
There is a world out there ready to mess up your carefully built shit, by maliciousness, honest inadvertence, people not reading the directions, people learning for the first time and making mistakes, or just sheer incompetence, or indifference.
1) If people aren't being respectful, block them.
2) If they put little effort into bug reports/feature requests and are not respectful of your free time - close the issue, link to a generic explanation why.
3) If you are not being compensated and the project burns you out: stop doing it.
There is usually nobody else who can or will do these things for you. Grow a spine, have self respect, value your time, learn from the experience.
1) you cannot control the world around you
2) you can only control how you react to the world around you
3) to tie your happiness to things you cannot control is to suffer
Once you internalize this, you will identify attempts to circumvent this truth, and why they are ultimately self-defeating.
I wonder if they ever influenced each other, or if those principles where 'discovered' independently ?
It's definitely not either/or, sometimes you can change the world a little bit by making a post that says "please be nice".
Or the way I see it: be prepared to step in shit sometimes but if street defecation is not culturally accepted, your walks will be nicer.
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.
Make someone pay for software and they always treat you far better.
I'm sure there's some cognitive reason/explanation for this.
Remember the last time you got an item for free. You probably didn't worry too much about it, because it didn't cost you anything. You didn't treat it that carefully.
Compare that to something you bought for yourself, that you had to work hard for. You probably took a lot of care for it. You probably really paid attention to ensure it didn't break.
I feel like this is the mentality difference. Something free = no value = we can treat it badly. Something not free = it has value = we are more careful with it.
The nicest customers I have for my Saas product are also the ones who have the largest accounts. The ones that pay $15 a month for a single user on the cheapest account are always the ones asking for a list of like 50 new features to be implemented yesterday or "the product just isn't gonna work for us". Yea ok, because your $15 buys you a right to own my entire roadmap... not.
They’re paying for whatever product or service they went in for. It’s not because something is free, it’s because they’ve designated certain people as servants.
I think there’s a pernicious attitude that the “free” part of open source is an entitlement to service, and that the people providing it are servants.
I think products do have the ability to make us feel an emotional response, even when free?
Apart from gifts, as mentioned by another commenter, I often seem to value things higher and be more careful with them when I know they're valuable and I got them without having to pay.
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.
Do you pay for the oxygen you breathe?
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.
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 ...
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.
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.
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.
> “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.
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.
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.
a) Using SGX (brushed aside) b) Inability to export and backup chats (ignored)
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.
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.
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.
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 wrote a comment here outlining my frustration over the lack of export ability in iOS: https://news.ycombinator.com/item?id=25763997
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.
> 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.
https://twitter.com/realsexycyborg/status/134916717100428902...
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.
* Input Method Editor
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...
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...
Non-technical people would just read "Signal isn't secure" which is BS.
iMessage isn't insecure either because you can connect a compromised USB keyboard to your Mac.
https://play.google.com/store/apps/details?id=com.abifog.lok...
Now my variant doesnt require internet access but some forks added "email keylogs to someone else" functionality.
If someone manages to install and enable that on a target's phone, then it renders Signal and all other secure apps useless.
So does installing a compromised USB keyboard or a broken Logitech receiver. Why is that Signal's problem?
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.
* 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.
> 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 isn't as good a others but at least it doesn't spy on you.
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 your comment should be consistently reposted on every single story related to Signal until they address this problem.
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.
FOSS for goblins?
The Basic Meeting List Toolbox (BMLT) is a full stack, open source solution for managing Narcotics Anonymous meetings.
More like Uruk-Hai
- https://github.com/settings/interaction_limits
- https://github.com/<user>/<repo>/settings/interaction_limits
and users can block other users
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.
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.
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.
Telegram has such person for full time, I follow them on Twitter, and their responses are usually hilarious https://twitter.com/telegram/with_replies
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!
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.
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.
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!
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.
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 "right" does not exist. Scrolling past stupid or offensive stuff is an appropriate thing to do.
"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?"
Because, y'know, that still seems like a reasonable question.
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.)
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.
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.
Minorities profit most significantly from freedom of speech.
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.
It is a coping mechanism because it makes no sense to be angry at a user that doesn't even care that much in the first place.
From that perspective it makes no sense to be angry at messages.
Doesn't always work, obviously, but it is the best way to deal with it.
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.
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.
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. :)
of course the implementation varies from product to product but is usually not obvious to the other party
Perhaps somebody needs to invent that device that allows us to punch people over the internet.
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.
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.
Edit, found it: https://www.bountysource.com/teams/whispersystems the old links did not work
Being nice doesn't mean being passive. If you see something wrong, make someone aware of it nicely and if they respond badly, flag or report them.
Be nice, be active.
Be nice, yes. Both ways.
While have a zero tolerance to anyone being even slightly annoying/belligerent.
https://framagit.org/tom79/fedilab/-/issues/498
> Fedilab is a multifunctional Android client to access the distributed Fediverse, consisting of microblogging, photo sharing and video hosting
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.
Life is full of "meanies". Cry me a river.
If someone asks why, just tell them you don't entertain any level of toxicity.
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.
Get real.
But that being said, if you don't like Signal, just don't use it.
WhatsApp had the same force behind it when it first hit mainstream. I think it signals something nefarious.
I don't remember this, mind elaborating?
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.
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.
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.
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.
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.
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.
Feels very much like an aphorism for life these days
It's called trash talk, a significant part of his sport/job before and after fights.
> I guess you can say shooting people was Billy the Kid's job, then.
No. That's law enforcements job after following the correct protocols. My good fellow are you alright?
JK please be nice y’all
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.
[0] https://projects.propublica.org/nonprofits/display_990/82450...
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.
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.
Can maintainers please be nice?
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 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 your response is perhaps a red herring.
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 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.
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.
But there's no way that "investment" makes Signal/OWS in any way beholden to them.
If you're going to get upset enough to rant about "all the time I invested in using a free app", you're going to lead a very unhappy life.
The limit is a single variable on their back end server, maybe poke them to up it to 10?
"Nice" is self-assessed. Almost everybody thinks they are being nice, and fair. Even despots think that when they self assess.
It's more constructive to have guidelines that tell people specifically what to do and not do.