I have no horse in this race, but wouldn't it be better to keep crash reports in there? Of course it should be disabled by default, and it would never be uploaded. That way individuals can raise issues and attach the crashreports if they need to.
Branding any of this as telemetry then creating a bunch of immediately abandoned forks is a joke.
Before you say “well make this opt-in” - that doesn’t work for crash reporting nor does it really work for auto-updating.
Things change. The internet needs Javascript, distributing desktop apps using electron makes a lot of sense and developers need automated feedback. Please stop.
This part is not inherently true. Only time will tell how Audacity reacts, and they could very well have an UnGoogled-Chromium/Codium situation on their hands.
My point is that a fork can be abandoned by users even if the project is still active.
Edit: to be clear, other software is often used instead of audacity. It isn't as well known as say photoshop, or maybe even inkscape.
https://public-001.gitsense.com/insights/github/repos?p=comm...
The user crsib appears to be the main contributor to audacity, so I would have to imagine others would have to pick up the slack for a fork to be viable.
cookiengineer also changed 71 files
https://public-001.gitsense.com/insights/github/repos?p=comm...
so he/she will have to constantly monitor these files moving forward, for the fork to be stable/similar to audacity/audacity, which I am not sure if he/she/others are interested in doing this for the long term, but I guess time will tell.
Full disclosure: I'm the creator of the tool that I linked to
Similarly, crash reporting being opt-in works very well. On crash you present the user with a crash report, they review it - and can send if they desire to. Throw in a lil’ “don’t ask again” checkbox and you’re good to go.
I don’t see anyone forking that in outrage.
It's like this because it is an overwhelming benefit to someone who is selling something. Not because it is necessarily overwhelmingly what people want.
Some other market outcomes I'm unhappy with: ad tracking, excessive plastic packaging, cheap goods - expensive repairs, all sodas are at least twice as sweet as they need to be.
When there are options, I choose otherwise. If an option I've come to rely on changes to be something I don't prefer - i'll raise a stink.
Audacity doesn't need to phone home for that.
Very different
This is funny because usually whenever i see that mentioned to excuse negative behavior it isn't really about the market speaking but about the market staying silent :-P
The project lead said he had no say about the telemetry and couldn't turn it down. For me, that makes is a business decision and not a technical one. This is to monetize, not to help me.
It’s crash reporting and update checking. Stop getting so outraged over such minor things.
More people think open source means “I can be VP of product without showing up to work” than “I can roll up my sleeves and help make the hard thing I want happen”.
- system instability - just plain data deletion and/or loss - features not working at all, or quarter-baked - previous free feature moved to premium or behind the paywall - incompatibility with previous files - just plain resetting my previous settings and customizations to defaults - arriving with the wrong language (based on keyboard layout or location vs my OS-chosen one) - somebody was frelling bored, so decided to move the position or change a keystroke of the function in the menus - just "because" or "it boosts engagement" or some similar crappy excuse - plain spyware/malware delivered as an "update" (with app betwixt updates being sold to spammers/scammers) - app/program sold in the mean time, with the new one preferring to siphon all the telemetry possible (all options conveniently on by default) - messing up my file or action associations
...and probably 12 other things that don't cross my mind at the moment.
I will bloody update my hardware and my installed (or portable-d) software whenever the frell I please. I cannot stand the mommy-gloves and mommy-stance I am subjected to
I do not have will nor time to battle with that. My largest "attack surface" in any/all meanings of the word comes from auto-updatijg. So, off with your hea-- auto-updates.
I've been blocking/filtering all auto-updates and all Internet access to all apps/programs/OSes where ever possible. Whenever possible, I use portable versions that don't require installation, and I have a huge software library; letting things run amok is not an option.
I've been doing it for a decade now (in different, but ever enlarging scope), and I've never been happier. Nothing breaks. Things work. AS THEY SHOULD. And nobody forcefeeds me the crap 95% of the "common folk" are subjected to.
Yes, this is a rant. And the topic is a sore one. I'm just so, so, so bloody sick of it.
I thought it self-evident in my post that I expect the software in question to notify me of a new version, provide the cumulative change log, and offer me an update (plus even an auto-update, but only as an option).
Software that did that (let's call it "polite" software), got its net access (for limited aforementioned uses). And if it was a piece of software I particularly found useful and non-clashing with my stances, I sometimes even enabled the telemetry (because it might help improve it).
What I cannot stand is being forcefed those. They break everything when I least expect it, and when I most need the things to function and function fast (e.g. auto-update on program start VS offered update on close). Most (90? 95%?) of my catalog is specific (and offline) use only, so eventual issues usually do not affect me.
Often used software I update on a more regular schedule, but still - almost exclusively manually (by downloading the new portable version). OS is updated once I'm done with a project or whatever I was doing in that duration - meaning when I can temporally afford to be frelled in the posterior by Microsoft's updates, and spend an hour fixing stuff... such as figuring why the bloody gamepads are now suddenly preventing my monitors from going to stand-by, thus messing up my presence & tracking software, thus messing up my home automation recipes. (If you are impacted, it's the 2019-timestamped XBox driver; revert to something ancient [find it somewhere], and "lock it" down by listing device identifiers via group policy.)
To sum up, in simplified terms - any frell-up resulting from an auto-update impacts me 100% (and costs me time, nerves, will to live) VS extremely low percentage of being affected by the critical security vulnerability du jour (and especially taking into account security and precautions I practice).
Constantly-used and online-required software has its own, different set of "rules" (security, precautions, guidelines, etc.). Don't mistake my ire at a certain type of an unfortunately too common (mis)use of a feature (in my specific circumstances and use cases and scenarios) as an irrational blanket refusal of absolutely everything under that category.
(Note: typing on a phone, so due to editing troubles my chain of thought might be all over the place.)
However, what I do not stand for is auto-updates without my explicit knowledge and explicit consent, because it regularly messes up my... well, my "anything and everything". (Insert specific xkcd instance about breaking-workflow here.)
Therefore, due to personally-experienced and ever-widening common abuse of the mechanic (and ever-encroaching march on my privacy and rights on & from all fronts), I am less and less willing to even consider giving the pieces of software I actually enjoy the benefit of the doubt (aka useful telemetry).
Please notice - my original reply was (exclusively) addressing the specific portion of one of the preceeding user's comments "pushing" for the auto-update mechanism as mandatory (and not to the Audacity's issues/attempt/approach specifically). From my perspective, it seems that you and the previous commenter are addressing my replies as a full and all-encompassing description of the whole of my approach and practices (and I have specifically said that isn't the case in the comment above this one).
Additionally, there is an assuming of the non-use of any (or a combination, or all) of the myriad of the additional layers of protection available to any semi-advanced user [e.g. Tor, purpose-configured browser, proxy, VPN, etc.] while obtaining the software in the first place (and/or subsequent instances), and that the software in question could be "gotten" from alternative and directly unrelated locations if need be. If true, that assumption would be in error.
Those are my needs, not the software's. The software has no needs. And if I don't mind the bugs and aren't interested in "improvements," I'm not actually concerned with the software's feelings.
When I say this, I'm assuming I'm not talking about networking software, but if you had your way, every piece of software on my computer would be networking, and reporting my usage (however it opaquely defines that) to strangers. I don't want to have a lifelong relationship with the person who wrote the sudoku program I installed from my distro's repo. I really don't want to get owned five years from now because that person needed to "improve" it when I didn't ask.
Software needs not do any such thing. Developers may want this thing, but users absolutely do not need it, and neither does software.
You don't need to perpetually run the latest release to "stay relevant". All of my workstations are still on Catalina and they're fine.
This is a fundamental principle of human interaction -- ask first before touching someone's stuff.
Imagine if there is a buffer overflow in Audacity, meaning someone can take over your machine with a malformed sound file. I'd want to know about that ASAP -- not after a month.
On average, I believe most users benefit from an automated check for updates. It should be possible to disable it, but we should first worry about keeping users safe.
They should still ask first, at first run. I actually enable update checks for a lot of things, if I'm given the option up front. I'll submit crash reports and even periodic telemetry if I know that the crash reporting system doesn't download and run arbitrary code, shows me everything that will be submitted, and allows me to omit needlessly identifying details (e.g. custom kernel strings).
Some projects (KDE) make it really hard to submit crash reports, by requiring an account, etc. It must be optional, it must be easy, and it must be transparent. Then users will volunteer crash reports and stats. Respect breeds respect.
Nowhere in that paragraph was their any technical reason that someone concerned with both getting crash fixes but avoiding crash reporting themselves should be told they can't have them both.
Also, opt-in silent updates don't inconvenience anyone. The user gets whichever situation they are most comfortable with.
Opt-in crash logs and opt-in silent updates should both be logged for easy user perusal.
--
None of this inconveniences developers or users.
--
The problem with any centralization of non-opt-in unlogged data gathering is it creates completely unnecessary hazards and trust problems.
Once an organization is pulling data, that data is now available to (1) incentivize the organization to use it in ways the subjects many never have considered, (2) incentivize the company to increase the amount of data they pull for good or ill, (3) is potentially a target for security breaches, and (4) is a potential target for governments to coercively surveil users by accessing the data or encouraging more data to be pulled.
None of the problems in the last paragraph will be apparent to users until they have already suffered damage. So concern about non-opt-in unlogged data gathering is extremely prudent.
Audacity hasn't really changed in the last 5 years. It's still good.
I doubt I would miss anything I need if I somehow didn't update for a couple of years.
Even on consumer desktops these kinds of updates are simply not critical.
It doesn't seem so weird to me to have an application ask for permission first. Something most applications do anyway.
Nevertheless, it's good to know they've chosen an opt-in construction for Audacity!
Do you think the SQLite developers have ever felt like they need automated crash reporting from their users? (see https://corecursive.com/066-sqlite-with-richard-hipp/ , which got discussed recently: https://news.ycombinator.com/item?id=27718701 ) And SQLite accepts way richer input (SQL queries) from users than Audacity does (audio files).
There are many ways to reduce bugs. Extensive coverage-guided testing, like SQLite does, is one. Automated fuzzing is another. Writing in languages with strong type systems that let you statically verify the program's behavior is another. Collecting crash reports is another, and it's certainly one valid way, but it's not the only way.
It's pretty clear that Audacity's users, in aggregate, aren't that concerned about needing crashes fixed - or at least are less concerned about it than about their privacy. Maybe Audacity already is sufficiently bug-free for their needs!
While I also think that the "telemetry" argument is overblown, and I think automated updates are basically table stakes, and I wholeheartedly agree with you re JS and Electron, I think it's entirely reasonable for users to say that they don't find automated crash reporting valuable, and I don't think that it's particularly reasonable for developers to say "We know better than you."
Also, with SQLite, it seems the major people reporting bugs are people who have paid support contracts with drh, which most likely requires sending identifying information.
I don’t think the rest of the comment warrants much discussion, but I wanted to point that out.
You mean Fossil? We use it, it works great for us, doesn't get in the way, doesn't require constant rtfm. Also you could just clone the repo if you want to test. It exports to git.
If SQLite is low-quality software, but the manner in which it is low-quality does not involve crashes, then that does not contradict my claim. There are a lot of ways software can have bugs other than crashes: incorrect behavior, confusing defaults, missing features, inaccurate or nonexistent documentation, poor API design, etc. Automated crash reporting can't help with any of that. If you discovered that "SELECT * FROM users WHERE paid = 1" returns unpaid users too, that's a really bad bug, but no automated crash reporter could possibly tell the SQLite developers about it.
I do agree with you that users of software at scale don't report bugs and so you can't rely on them reporting bugs; I'm just pointing out that there's no reasonable way around it except for crashes, and there are other ways to address the specific use case of crashes.
There is an unreasonable way around it: add an analytics framework that tracks every click and mouse movement and keystroke your users do. There are web analytics libraries that do exactly this and let you replay your users' behavior. I hope we all agree that Audacity should not do that.
(By the way, if I go to https://sqlite.org , there's a "Support" link at the top that tells me to use their forum. You can then click on the forum link, click "New Thread," and click "Remain Anonymous," and there's apparently a way to post things. I guess this forum does actually use Fossil internally according to the message at the bottom, but it seems really straightforward to me, so I am surprised at your claim that this is confusing....)
I don't want any software on any of my machines to auto-update.
Auto-update is a remote code execution vulnerability, as Solarwinds demonstrated.
> Things change. The internet needs Javascript,
I browse the web with javascript off, on Edward Snowden's recommendation.
No, you stop. It absolutely does NOT need this functionality. Is it nice? sure. But it should be opt in and prompted, not opt out and automatic.
> that doesn’t work for crash reporting
It does.
> nor does it really work for auto-updating.
Good.
> The internet needs Javascript
No it doesn't. The ad economy depends on it to bypass consent. Do not confuse that with the ad economy requiring it to function nor does it mean the internet requires it. Again, is it useful? of course, there are many instances where it can (keyword can) enhance the experience, but it is not necessary for 99% of applications (no, your infinite scroll SPA is not a necessary function). Is it necessary? Absolutely not.
> and developers need automated feedback
No they dont.
The only things you're referring to are necessary for are forcing things by your users without their knowledge or consent, and for superfluous flair and form. It's possible to build opt-in, privacy respecting, informed consent software diagnostics and telemetry without forcing this nonsense on them, especially with respect to the topic at hand, which is not a web application, but an offline native desktop application.
The web and mobile world is plagued with prompts stating that "X needs to access your data Y" or "X needs permission Z" to "do the job".
Worst part of it? Developers and architects are often the first ones to believe this nonsense.
When you're surrounded by developers, users and managers who believe in werewolves, best thing to do is just to nod :)
> No it doesn't.
Do you prefer the web from 1995? No youtube, no github, no google docs, no google maps, no real-time in-browser messengers/chats, no hangouts/google_meet/jitsi, etc. etc.?
However the Internet isn't the Web, so certainly the Internet doesn't need Javascript.
Also neither does the web, but for sites that can provide functionality which wouldn't be possible without javascript it can be a nice optional feature. Though all of the examples you gave either do not need javascript (youtube, github) or are better as native apps (google docs, google maps, IMs).
I mean, even if you were fine with that, nowadays pretty much everything is available on Linux too and crossplatform development tools for native applications existed for decades already.
Industry practices collapse under the weight of their own complexity and people argue on HN about it with absolutely no context on the real issue, just presupposed bugbears like “privacy”. Video at 11.
JavaScript is the single worst thing to happen to computing in its history. Maybe not the language itself - it’s fine enough for its purposes - but the industry deciding that its purposes overlap with a wildcard glob is a huge mistake that we will be paying for long after everyone in this conversation is deceased. It’s annoying that you credit that situation to JavaScript and laud it given what else comes with doing everything in a browser (enabling the surveillance economy, inadvertent network dependencies, computers running at about 5% ability, etc etc)
They exist since decades, but apparently C and C++ are even more hated than JavaScript.
Since you’ll probably pedant me with several names I can already think of, it’s worth remembering that existing does not imply easing burden nor being useful beyond a README and a weekend jog.
So lets spend ourselves some time that you can get yourself improving your Electron skills instead.
I can give you computers running slower. As for the surveillance economy, I am not sure why you think that installing someone else's crap on your computer is preferable compared to running that crap in your browser and blowing most of it away every time you leave the site (or blowing it away completely by clearing your browser's storage). As for network dependencies, websites are now perfectly capable of running offline, while native apps may need network access for doing anything useful as much as a browser app does.
As a developer, I would rather write once and run everywhere. As a user, I would rather not install hundreds of megabytes of someone else's "apps" that could have been a web page on my computer, other than the bare necessities that I am comfortable with. Nor do I particularly care to update those installed apps locally, downloading hundreds of megabytes more or having the risk to run into software version issues. Having vim on my machine is fine. Having Facebook, or Twitter, or Reddit is not.
Each distribution is a snowflake, and now GNOME even considers UI design tooling something worthwhile killing in name of GtkBuilder with raw XML, exactly what UI/UX designers have asked for.
You can use HTML, Canvas, and CSS to do just about everything you mentioned.
Video is easy. In pure HTML: <video autoplay loop muted playsinline src="..."></video>. No Javascript (or even CSS) required. You can certainly expand on that as well.
Google Maps does not require Javascript to provide it's core and common functionality either: https://appelsiini.net/2008/google-maps-without-javascript/ You would have to make some changes, but core functionality still exists.
Github does not require Javascript to function. You can toggle JS off and still use it pretty much as is, and the features that do break are trivial to implement without it.
Interactive realtime chat does not require javascript. https://github.com/kkuchta/css-only-chat , and the same principals can be applied to online docs and editors as well.
Javascript is the norm because it has inertia behind it - largely due to circumstance more than any inherent natural benefit, not because it has some secret sauce that the internet needs that couldn't be easily replaced should it be Thanos-meets-Tron-Crossover Snapped out of existence.
A much stronger argument in favor of Javascript would not be pointing to all the good things you can do with it, but rather, with how well and optimized and streamlined doing those things with Javascript is these days. Just to clarify, I'm not saying Javascript is the problem, but rather, the abuse of it, and that abuse would still be an issue if other technologies replaced it one day.
I use the internet with JS toggled off by default as a result of the rampant abuse of dark patterns (for example, the Google Search Suggested Alternatives box that is served below the sponsored result(s) that always "conveniently" expands after a short delay to push the first actual result down the page and replaces it with yet more sponsored content), 3rd party/cross site abuses (Malware), as well as the overabundance and omnipresent ad-spam. Sites that break as a result of my opt-in JS browsing is usually a sign it's not worth my time. Sometimes I'm proven wrong, but sites that can fallback gracefully and display some basic info without JS are usually the worst offenders..
TL;DR: Yes, in a way, I do prefer "the web from 1995", where Javascript isn't everywhere, and only present in places that I specifically whitelist, because it's all too often abused to negatively impact my experience instead of enriching it.
Calling any of this as anything other than Telemetry data is factually incorrect
The movement around forking is NOT just over this new privacy policy, but is a culmination several actions by the new owners of the project to go agaist some very basic norms of Open Source stewardship. Further they are more or less giving the Linux Maintainer community a "FU" over their use of custom / modified version wxwidgets which makes packaging the 3x version of Audacity problematic for many linux distribution for security reasons.
As to the statement that "opt-in does not work with crash reporting" Sure it does, Many applications (including Microsoft, and Mozilla) have a dialog that ASKS the user if they would like to submit crash reporting data to the vendor on a per crash basis, There is LITERALLY zero technical reason for automatic, opt-out crash reporting
Well Audacity thought it would work for them: https://github.com/audacity/audacity/pull/836
Crash reporting is more of a problem than telemetry. Any report that contains the contents of memory may end up leaking confidential data. That data may be considerably more sensitive than an analysis of how the software is being used. The end user should be informed of the risk, be able to review the data being shared, and have the right to block it.
As for updates, there are distribution models where this is handled by a third party. In some cases, a list of packages is downloaded so the only way for the third party to know whether something is installed is when an update is retrieved. In other cases, a list of software is sent to the third party but it is a trusted third party (e.g. Google, rather than a random app developer).
I'd trust a random app developer way more than an ad company whose data processing consent flow is intentionally annoying and still does not comply with the GDPR.
Obviously this applies to offline tools and not web browsers.
Am I so old that even the mere concept of beta testing doesn't make sense anymore?
Crash reporting: Why not just generate a crashreport-date.txt and allow the user to save it and email it to you? Why should they be forced to report it?
nobody does this. It’s such an utterly naive statement and exactly in keeping with others in this discussion. It also doesn’t catch non-terminating errors.
> Why not stay on old version or rely on package managers which do that for you?
Why would you want this? This also doesn’t work for Windows.
Because maybe an old version works good enough for your needs. Every software having auto updates is the reason package managers don't catch on on windows. Then you see every single software having bulky planned tasks/start on boot auto updaters.
>nobody does this
Core/crash dumps are exactly that.
>It also doesn’t catch non-terminating errors.
Why wouldn't it?
Why?
Isn't your decision to run this software some kind of consent to let it perform its basic stuff?
And if so, how far down that slope is it reasonable to go before trying to claim that crypto-mining is also an essential part of off line audio editing software?
It's not like program will stop working when it tries to send crash report without internet connection (if handled correctly).
>I guess the question is - is online telemetry and crash reporting reasonable considered and expected to "it's stuff" for an offline audio editing program?
For me - yes.
Yes, I do consider crash report as a part of software maintenance efforts and I have nothing against sending
critical data e.g at which place it crashed & e.g basic informations like OS, Hardware, GPU/Sound drivers version.
Should there be a way to disable that communication? Yes, and there is.
Beyond all that - if you are seeking the level of anonymity that would require evading program update checks or crash submissions - then you should probably lock down your network as your biggest worry is probably not your open source audio software.
Still, a good question is how you're getting updates in the absence of automatic updates (and for software whose goal is parsing binary file formats, chances are high that if you aren't getting updates, you have a pretty big privacy problem already). If you have no auto-update code but you're telling users to download new versions from, say, GitHub, then GitHub gets their IP addresses anyway.
I think hiding from GitHub is not something that average person does
but if you want to do it, then feel free to purchase 3$, then type
`ssh -D 8080 root@linux`, use SOCKS Proxy in Firefox's Network settings and here's your new IP
Here we'll only hear the strong pro-privacy views because that's the news.
Did you use computers 15 years ago? Linux desktop and open source tools? Nothing had this crap back then, and some of it was pretty good. Audacity itself is an example!
Open source software is not a commercial product. You don't need to prioritize and optimize for engagement or market share or any such crap. Just fix what you want, fix what you can, interested capable users will contribute attempted fixes for their own problems and you incorporate them if they make sense to the project.
I don't think telemetry has ever resulted in good software, it just pushes everything towards being an iPad with one button on it. Only skilled tasteful developers make good software, and that was true long before telemetry existed.
[1] https://errors.ubuntu.com/ [2] https://developer.fedoraproject.org/tools/abrt/about.html
Actual fixes overwhelmingly come from individuals manually reporting weird lockups and backtraces, often taking the initiative to bisect the issue to a particular commit.
Audacity has been around for 21 years, has generated a strong following from a wide range of users, and is one of the most widely-loved FOSS projects. It achieved said status without telemetry for 21 years.
People keep saying the telemetry thing is "overblown", but there is clearly a large number of us who simply don't want it. It doesn't need it, and the past 21 years have demonstrated that.
I believe when you make crash reports / telemetry disabled by default then you lose a lot of reports,
thus make your life harder as a developer that wants to deliver high quality solution for as many OSes, hardwares, configurations, blabla.
I don't have problem that e.g my IDE would report how many files and lines of code my project has, because it may allow devs to make better decisions.
Perhaps I should have been clearer. I think something similar to Firefox's crash reports. If a crash happens, prompt the user and show them the report, and finally, let them decide. Perhaps even take out the networking features and open the default client with an attachment or a path of the report so they can be attached to a github issue.
So, like Audacity?
Having said that, Sentry integration is another matter.
How? I only know Sentry as the backend tool you use to analyze the uploaded crashdumps? Or do you mean that a "crash report" could be something smaller than a minidump? (although I personally think a minidump is not a bad compromise)
Different people have different needs and different levels of sensitivity to this sort of thing.
Personally, I don't want my offline audio editor talking to anything without asking. But since Audacity doesn't do that, this will be what I use instead.
If Audacity were to ask before sending data, a good chunk of people wouldn't be upset. But it doesn't, so here we are.
Also — and I've said it before — automatic "telemetry" and crash reporting is just lazy. It also lacks context. If you want to know what your users' experience is like, just ask them.
What successful ways can you envision that a software developer ought to be asking their users for their experience, when the software is available for free without restriction upon download or use?
How would you ensure that users who are satisfied with the way Audacity is working will take an equivalent amount of time to report their satisfaction as users who aren't satisfied with the way Audacity is working, so that your feedback is representative of the userbase as a whole rather than of the vocal subset that have problems? Would you advise Audacity to stop trying to measure or assess its users and their opinions, and instead simply do whatever they think is best for Audacity without harvesting user data?
If Audacity truly accepted the view that the product should never report a single byte of information back to them and that they should never attempt to collect any data whatsoever about their users, then they would be forced to make decisions about Audacity without those users' data (including their opinions!), even if those decisions could end up being disliked or contentious among a subset of the users. At that point I expect they would likely determine that product autoupdate and feature usage metrics are a valuable feature for the product and not of concern to most users, and then ship those — regardless of the cries of outrage from the subset that hold contradictory opinions — because, after all, that subset demanded not to exist to Audacity, and so their wish is fulfilled.
How can the vocal contingent of Audacity users who say "my existence should remain unknown to those who make the software I use" expect to have their opinions considered relevant, when they specifically demand not to be considered as existing at all?
All of the things you bring up are solved problems. They were solved years ago and the feedback methods continue to be used today by quality software companies. Just because Audacity and its owners choose the lazy route doesn't mean it's the only route.
Programmers and the companies they work for should stop trying to normalize telemetry. It's not normal.
Either products make decisions without telemetry, or they make decisions with telemetry. Either products make decisions without user input, or they make decisions with user input. You do not name any specific feedback methods that do work as a solution to this, and certainly I see none in use in projects such as Homebrew or Audacity that are cited as acceptable to you.
What "quality software companies" offer a feedback method that does not stir outrage among those who incorporate it into their products and/or efforts, when their feedback is not treated with priority and urgency? Every software company I've seen, small or large, has angry users who complain that their opinion has not been treated as correct by software companies, and those users congregate on forums and reiterate their pet peeves every day or week or month, in the futile hopes that this clamor will somehow influence the software company (which, generally, it does not). You do not address at all my concern about biased-towards-complaints data resulting from in-product surveys or feedback methods, and you do not explain how feedback methods unsupported by telemetry can measure the true amplitude of complaints rather than being biased by how loudly the squeaky wheels squeak.
You have failed to provide any supporting evidence for your argument that these are 'solved problems', and instead framed your unsubstantiated view as if it's fact. That isn't a viable approach at Hacker News, and I hope you'll take the time to correct it.
Is it reasonable to expect Audacity developers to just ask all of their users "Hey, how are things? Are things crashing? How and why?" I'm not sure if you've ever tried to diagnose a user's crashing issues, but, especially with non-technical users, you're likely to get responses like "A dialog popped up but I closed it, I don't remember what it said", or "I wasn't doing anything and it just crashed out of nowhere".
Automatic crash reporting is like night and day; sometimes, you can even find and fix problems before your users get a chance to report the crash (if they even bother to do so, which most don't).
> If Audacity were to ask before sending data, a good chunk of people wouldn't be upset. But it doesn't, so here we are.
From the pull request: https://github.com/audacity/audacity/pull/835
> Just to reiterate, telemetry is completely optional and disabled by default. We will try to make it as clear as possible exactly what data is collected if the user chooses to opt-in and enable telemetry. We will consider adding the fine-grained controls that some of you have asked for.
In other words, Audacity is asking before sending data and people are upset regardless, apparently due to just general ignorance about the situation thanks to some people blowing it out of proportion and describing it inaccurately.