We can't both want OSS to improve and resist giving feedback. I think the possible UX improvements are worth giving them some data, as long as the scope remains limited (which it should, since it's OSS and we can see what gets sent).
We can't both want OSS to improve and resist giving feedback. I think the possible UX improvements are worth giving them some data, as long as the scope remains limited (which it should, since it's OSS and we can see what gets sent).
Companies have existed for centuries without needing constant telemetry... we have many methods that do not require telemetry: surveys, emails, forums etc.
In fact, there is a subreddit here [0] that the devs/owners could easily ask questions.
[0] - https://old.reddit.com/r/audacity
Edit: Also, I think people are totally jaded with telemetry. There are some companies that take data whether you want them to or not so people are naturally wary... what's to stop them pushing out an update that grabs a massive pile of sensitive data and then when the backlash starts, they throw their hands up and say "sorry"... much like Google do/have done.
And if you're fine with software from the 1700s, you're welcome to use that, but if you want UX improvements to Audacity, there's only so much that can be done without telemetry.
Edit: >but if you want UX improvements to Audacity
You insinuated that the only way to improve the UX (your comments insinuates that it needs improving) is to use telemetry
Whoever wrote: > > > but if you want UX improvements to Audacity, there's only so much that can be done without telemetry.
Oh look, seems to have been some guy called "stavros". Anyone you know?
(I mean the 1980s, just to stave off any attempts to send me back in time to observe computing in the 18th century).
Like, what do people think they want the telemetry for? Are they planning to sell the treasure trove that is "how many people clicked on the 'select audio sink' button" to the highest bidder?
You can tell them "do it without telemetry" all you want, but in the end it's just not going to be as good as if they had feedback.
Also, Apple was selling Apple IIs for the modern equivalent of $5,000. I'm sure Audacity could achieve some great in-person UI studies is people were willing to pay that kind of money.
Qualitative (usability testing and other observation methods up to and including ethnography) can give us the why (users seem to do what we didn't expect).
Modern UX design can make use of both modes of user research such that they support each other. I.e discover the what via quant and understand it better via qual, to land at a solution.
Or discover both why and what via qual, and then determine severity (how many users get stuck in a given way) via quant.
But of course, there needs to be explicit consent such that trust is not breached, no matter how inconsequential the data collected is considered to be. The decision belongs to users.
Apparently there wasn't consent.
Edit: Ideally, should anonymised usage data in OSS projects be public? Such that we can see the data and design decisions made based on it? Perhaps this would generate more of the trust that was desired here.
Sure, I also want it to stop, but there are so many doing it.
Really? That's a weak argument if ever I heard one.
Perhaps it's time to take a stand and say "no more!"
What's to stop them adding in something else later that "accidentally" grabs IP addresses, and sends them "accidentally" to their third party analytics company who doesn't give a shit about your privacy. That company then takes their other data, joins it all together and adds to the picture of you that you never asked them to create!
When you open this door, there is no closing it.
The argument comes down to this (for me, at least): You got the software to this point without telemetry. Why do you need it now? Is the application all of a sudden unusable?
Edit: I forgot! They already take your IP address but my point still stands!
Correction: rustup (rust installer) did collect telemetry but it seems to be removed now. https://github.com/rust-lang/rustup/issues/341 The reputation may stick, as we know :) No worries now.
They have done everything wrong.
banning use of the for under 13s not a good move IMHO.
They have a load of money and want to know how audacity is used?
How about just ask?
The fact that they are collecting this data now subjects them to COPPA requirements, thus the restriction to people over 13. If they hadn't started collecting data, they would not have had to comply with that restriction.
The original Reddit post (Discussion - https://news.ycombinator.com/item?id=27727150) stated Audacity would collect data necessary for "law enforcement, litigation". That doesn't sound like telemetry for improving the app.
You're really bending over backwards here.
By every metric they collect new Reddit is better than old Reddit.
From my perspective new Reddit is low density user hostile crap.
We are not even talking about tracking for ads or for surveillance. It is only about logs for crash analysis and UX improvement.
- Users ask for things which are not actually good, and so the UI becomes worse.
- User feedback is difficult to consolidate, and so the mass of the user feedback makes the product worse.
- Users think they know what they want, but actually don't, and so the product becomes worse.
Is it really so hard to just ask people? No need to spy on them. Also I don't think spying on them will improve the product. Telemetry has limited value in the first place.
The right time to ask if anyone will be using a specific portion of the app is when the feature is being proposed, not after it's been implemented and released. Replacing discovery up front with post-release telemetry is a sure way to lose money.
Conversely, if you're not making that mistake, then you don't really need telemetry to tell you what you already know.
Having worked on a variety of user-facing products for several years, I can tell you that it is hard. It depends on your audience but typically many users don’t report problems. If they do, they don’t give you enough details to diagnose the issue. And why should they? They’re not knowledgeable in how your system works. So you have to reach out to them and ask for more information. Maybe they need to reproduce the problem to give it to you. If you’re unlucky, they won’t be able to reproduce it. Even if they were able to, you have now taken more of their time.
The ask could be as simple as “hey this went wrong, but you can click here to send us the error info and someone will get back to you” and many users will STILL not share the information. You might think that they must not care that much but often times you’d be wrong. Users can be surprisingly irrational at times.
"Security is a process, not a product" applies equally to privacy, itself a domain of security.
A developer of an email client wishes to use telemetry to figure out which IMAP features are most worth supporting. They could, say, log every IMAP server you connect to. Or instead run an IMAP ID command and log the response. Or they could ship the CAPABILITIES response verbatim. Or maybe they could carefully parse the CAPABILITIES response and only report the existence of specific tokens (which may include capabilities not yet supported by the client) back as telemetry.
There's a gradient of scuminess going on there, all to (purportedly) track the same information. What matters for privacy concerns is the choice of data being tracked; how it's actually collected and transmitted is comparatively unimportant. So what you really want is someone to approve the choice of what to track, which isn't what a third-party library or service is likely to give you. And you don't need to necessarily route it through a third party; if we're talking about open-source software, the data that's being tracked is public knowledge--an organization that reviews telemetry and gives a stamp of approval would be sufficient to achieve the same ends.
But even then, I suspect many people are going to have different ideas as to what data is safe to track. Even the list I gave for tracking IMAP, I fully expect that there exists sharp disagreement about whether some of those entries would be okay for telemetry purposes.
Sometimes projects take their cue from enterprise.
Hypothetically, if Microsoft can’t count how many SharePoint installations they have active and on what version, telemetry could help them plan a roadmap. Only that inch is often taken and stretched into a mile.
I also used Firefox Nightly for a while because of the massive performance improvements at that time. As Audacity claims they're doing it for UX improvements, it would be easy to get frequent Audacity users interested in a beta build featuring tracking but also all the improvements being tested.
[0] https://www.networkworld.com/article/3185461/windows-insider...
In an audio program one often uses a set of filter by default, which aren't that important.
Important is the filter I use once in a while and in that specific situation is making a huge difference.
Unqualified usage counters lead t wrong conclusions.
Someone I know well created one such, based on a common reporting template of a major Free Software project, after realising that the template itself was based on information readily obtained from the system. Fleshing that out a bit resulted in an automatic syste self-documentation tool. They'd introduced it to the support group at one former company, and informal feedback several years later was that this was the principle diagnostic utility for the team. There was no ongoing telemetry, merely a "here's the script, run it and send us the output". (If necessary, the output could have been automatically emailed or transmitted by other means.)
There are now several of these, the "About This Mac" utility on OSX, as well as several for Linux, of which I'm aware.
No, they're not app-specific diagnostics, but precisely the same principles apply.
So clearly they think they need them for some reason.
Look at how android can ask, and many OSS apps can ask, to send reports via approved side channels, like email.
Or how people can report wishes for apps to issue trackers.
Telemetry is more about usage patterns, and many don't want that.
Also, for decades devs have designed perfectly usable software, without telemetry.
It's just not even remotely required. Wanted maybe, but not required. And the whole bug reporting/user usage patterns thing is a red herring.
For example, how is it possible that Audacity even exists, got stable, and used enough to be bought, without telemetry, if it is so vital??
> For example, how is it possible that Audacity even exists, got stable, and used enough to be bought, without telemetry, if it is so vital??
The obvious answer to this is "nobody said Audacity isn't good, this is about getting better".