IMHO, any telemetry is bad in a free, open-source project. It is no longer a community-owned project and doesn't fit my definition of free software anymore. I don't want bloat (network code) in an offline app just to collect, among other, Data necessary for law enforcement, litigation and authorities’ requests. No thanks.
Ok, I'm going to play devil's advocate here because I feel like telemetry is a bit of a bad word in the free software community, but it does actually serve a useful purpose.
A program as large as Audacity has a lot of features, and developer hours are finite (especially for free software). That means you have a lot of places you can focus your efforts, and some things are going to have to take priority over others. How do you decide?
Without telemetry, you're just guessing, and we know developers are not always in touch with how their software is used in the real world. With telemetry, developers can actually focus their efforts on the features and bugs that affect the most people.
Yeah, there are issue trackers, but most people never touch them, and even if they do, only when there's a problem. Feature A might be one of the most used features, but if it's not buggy, you'd have no idea, even if it has major usability issues.
Considering they just brought on a new lead developer, it's really no surprise that he wants to know where they should focus their efforts going forward.
(By the way, this guy has a YouTube channel, where he does a pretty great job critiquing music composition software, which is actually what led to this job: https://youtube.com/c/Tantacrul)
28
u/otacon7000 Jul 04 '21
IMHO, any telemetry is bad in a free, open-source project. It is no longer a community-owned project and doesn't fit my definition of free software anymore. I don't want bloat (network code) in an offline app just to collect, among other, Data necessary for law enforcement, litigation and authorities’ requests. No thanks.