I want to talk about analytics and my view on Audacities incentive to add analytics in the next release.

Many people seem to be enraged by the sheer idea of adding analytics. And in some parts of the FOSS world analytics are a no-go, for example, F-Droid (FOSS android appstore) forbids any kind of tracking that isn't OPT-IN. As a user I can understand this, I also wouldn't want any tracking behind my back and by disallowing any of it without prior consent they prevent any corner cases or discussions. From a developer's point of view, I think it's creating some problems.

I'm in the process of adding crash reporting (analytics) to my app on f-droid. In an opt-in style where you get a dialog on start asking about your preferences. The reason is simply that users won't report crashes, yes even on f-droid where you have to get at least the store itself onto your phone. So you could expect people to have more technical knowledge. My experience is that you might even know them personally and they will mention these only weeks later when you ask them specifically. Of course at this point there is no knowledge anymore of what happened and a crash report will always have more details about the exact circumstances. So yes, I'll add crash reporting. And you will get one of these annoying dialogs at startup that ask you whether you believe in the lord and savior jesus about your preferences and you probably click away mindless like all the other times.

I also added an android API survey before that, because I can't decide whether or not I want to support some old API version when I don't know how many of my users might still use something from 8 years ago. I might run into Survivorship bias but if people that want this supported click "no" on a dialog explaining why I want this data and don't say something, I might as well call them nonexisting.

Just ask your users

Somebody mentioned on lobsters (sadly the whole post got deleted) that you might just ask your userbase about their usage and needs, opening a discussion about the future of the project. My counterargument is that - looking at audacity - your typical user won't reply to such discussions. You will lose those people that just want to record some audio and edit it, which don't know anything about hardware or software. So if you want any usage data, you'll a) have to give them a dialog multiple times and b) ask them technical details they might not know. You will lose those people and only know about the power users that might already be reporting issues on their own. You should also make this discussion, but it's not enough when you create more than some dev tools.

Dog feeding

This also comes down to another point: Dog-feeding your own software won't work up until a certain point. I can't test all of the possible device configurations for my app and the audacity people probably don't have all the different audio setups/hardware their users have. So collecting usage data about this can help prioritize some features and detect common hardware that they might want to buy or test more thoroughly. Most importantly they want to detect crashes. This ultimately also makes it far easier to develop new features as you know that if something goes sideways you will know about it fast and detailed from your crash reports. I personally got word about issues in f-droid apps even half a year after they got patched because people simply didn't update. Without those analytics, it might as well be half a year until you even know about this problem.

Developing for other people

There is another interesting point here. I don't personally use all the software I write and I think for certain systems it might be for the greater good to still maintain or develop them even if you don't use them by yourself (and thus rely even more on your users data/reports). Maybe just to keep it running until somebody takes over or writes something better. I can certainly imagine that some of the people working for audacity are pretty good in what they do, but don't record any audio at all (or don't do so anymore) in their private time. So at this point the project and users need these people, but not vice versa. And I think many people will have scratched their personal itch far earlier than the point in time where their software took of in the OSS community. And the only options are to abandon the project or keep developing it unless somebody wants to take over. Even if you don't use it anymore, or not in the way that other people do. For example, I don't think that the developers of the static site generator for this blog do really need all of the features and options they added so it can be used by a wider audience. So they might even be dogfooding, but not every corner of the software. And I really appreciate that they still decided to build it with all the bells and whistles that are required to make it more than your pet project.

Last but not least the tracking is opt-in also for builds, so the typical linux user won't see this at all. It'll certainly only show for exactly the people that install audacity via their website which are probably the less technical users.

Closing

Yes, I also don't like that the audacity folks seem to adopt google/yandex for analytics. I don't know whether they don't want to or cannot maintain their own instance of tools like sentry. Also, why would you trust them more with collecting your IP than google? Whether trading UUID-based tracking with IP collection to identify one-off users was a good idea is another topic. But I really do appreciate the work they do and if opt-in, (basically) non-linux analytics makes their life easier I have no right to complain.

It's still much more trustworthy than the analytics opt-in I got shown by the grammarly browser plugin while checking this blog post. Which wants my login and logout usage, basically tracking when I have my browser open and which can scrape every website.

Image of analytics agreement for tracking login times