Many projects accept donations, for example for server costs or travel expenses (conferences, meetings). You can setup recurring monthly transfers to projects whose software you use most often. Examples are the Free Software Foundation for various GNU tools or the KDE project.
You definitely can do that, but if you’re afraid that you might stand-up and forget you’re using it, then you probably shouldn’t.
It’s probably enough to just use the default trigger that locks your screen. Or, once you get comfortable with it, set it to shut down your computer. Most people don’t need to shred their FDE keys, unless they’re facing torture.
In fact, we make it difficult to use “destructive” triggers (like the LUKS Header Shredder that wipes the FDE header) and intentionally do not include the ability to switch to it in the app. To use it, you have to do a lot of extra work. So most users don’t have this issue.
I’m now on fixed income but I appreciate FOSS. I usually try to donate, especially if the project accepts bitcoin which I’ve had for a while so it costs me less. Too bad many projects don’t. That includes Wikipedia and they keep asking why I stopped.
Same. Any place asking for donations that supports Bitcoin lightning is an instant donate for me, I always give something even if it’s a small amount. Lightning fees are so low that I’m happy to give small amounts whereas otherwise I’m worried my $3 donation will turn into $0.50 by the time it reaches the organization if it’s through Paypal or whoever.
For foss apps, I mostly allow analytics to track to help the dev out more. Complete 180 for any big tech since whenever they ask for it, they sell that information to the highest bidder.
I will not use software that has analytics that I have to opt out of if there is an alternative that has analytics off by default with the ability to opt-in.
The psychology surrounding opt-out vs opt-in is very well understood, and choosing to include analytics with an opt-out structure is taking advantage of people to make development potentially easier. Not cool.
Generally people make a huge issue out of something like that (some will even call it spyware, etc).
I think the best approach is to ask the actual community of users what they’re ok with before you start. You probably want to make sure it’s opt-in as opposed to opt-out, and be very clear about what information you do and don’t collect, and make sure it’s stored securely.
It’s not even always necessarily about trust, but risk management as well. I’ve definitely coded a crash handler that exposed my database credentials in it. There’s also the network aspect of it: your ISP/job/coffee shop can see the DNS request and TLS server name from the telemetry ping. That can be used to track you, or maybe you trigger some firewall alarm at work because of the ping.
We’ve kind of just started accepting that most apps will phone home and that there’s constantly some chatter on the network from all those apps. But if you actually start looking at what all your devices and apps are doing in the background with say, a PiHole, it’s pretty shocking.
I’m not that paranoid and would certainly accept some level of telemetry if asked nicely. “Hey I’m a small dev, I appreciate receiving detailed crash reports to make the app better”. And as a developer, users might be willing to offer way more than what would be reasonable to do in the background. I might even agree to submit a screenshot on crash, but if and only if I’ve been asked before and told what it’s used for, and I get the option to disagree if I’m going to be handling private information and don’t want to risk my data be part of a stack trace.
Many people who deliberately choose open source, are also into privacy. I’m not sure what people like. But you’ll definitely face some rejection by people like me. I like to file bugreports myself. I get my apps from F-Droid and they usually strip those telemetry libraries from the source. But for people who use Obtanium or Google Play, it’ll work. I think there is a good share of users who are fine with crashreports. Maybe the majority. You could make the app ask for confirmation before sending the report. Or offer two variants of the app, one normal and one without. Or let people like F-Droid offer the latter.
If it’s more than crash reports, I think it should be opt-in rather than opt-out.
I like the old fashioned way of doing free software. Have a community around the project, a bugtracker and engage people in a discussion about future developments. I’m happy if that’s baked into an app if it’s opt-in and it’s an open backend or something simple, meaning you don’t include the whole Firebase, Crashlytics, … stuff. But it’s up to the developer. If you like it, and your audience isn’t privacy nerds, include it and see if people complain.
Or offer two variants of the app, one normal and one without. Or let people like F-Droid offer the latter.
I like the idea of providing two variant one normal & another without any analytics whatsoever on F-Droid. Users can create a issue/support ticket on GitHub providing logs themselves. Their app will not even ping back whatsoever.
I will create app with analytics with a compile switch so analytics part is not even compiled and completely stripped from the build
Yeah, the maintainers of F-Droid will probably appreciate you did the work for them.
And I think it’s a sound approach. I mean the Linux ecosystem works the same way. We have upstream developers, and distributions and maintainers who adapt the packages for the user. We can have all the diversity, modern tools and also distributions like Debian that swich everything to privacy per default because their users like that. I think the same approach works for android and I really appreciate I get to choose between F-Droid, Obtanium and the Google Play store.
I think if you use your own Matomo instance I’m way more ok with it, than if you include google.
If your app could also be used by people from the EU, you have to be GDPR complaiant as IP adresses are considered personal information. The question if crash reports are necessary (in the sense of GDPR Art. 6) hasn’t been decided yet AFAIK.
Crash reports really helps developers. A app can crash for various reason sometimes it’s the device itself(not the concern of developers) but mostly some type of bug. We use analytics to prioritise which bug to solve.
For Example:- There are 2 bugs one in share feature another in export. If lots of people use share feature, then we priorities share feature bug
No I understand, I really do. I develop myself. The thing is, if it’s opt-out, then it does not seem to be necessary. If it’s necessary, then you have to show that your interest in bug fixing outweights the users right to privacy.
opensource
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.