2 ms·
It sounds outrageous until you realize: 1. The F-Droid team has a set of checks that they perform: a. Is the app open source? b. Does the app do things t
by igneo676 5y ago
It sounds outrageous until you realize:
1. The F-Droid team has a set of checks that they perform:
a. Is the app open source?
b. Does the app do things that the user might not want? ie access non-free services
2. Sometimes, to get around #1, special forks of projects are created so that apps can be included in F-Droid
3. The volume of new applications seem small enough that the F-Droid team can keep up just fine. The only problem I've seen w/ F-Droid resource problems are updates that take days to show up
4. As other have mentioned, you can opt out by running your own repository. Nothing is locking you into the F-Droid primary servers
I appreciate the additional curation F-Droid brings and I love the fact that I can tell other people to use F-Droid unreservedly and know they won't get anything spammy or freedom restricting
- lucideer 5y ago1.a & 1.b can be done without a custom build system as long as source is available. One could have strict requirements to the sourcecode submission to enable automation of those checks if that were an issue, without needing any custom build compliance. > The volume of new applications seem small enough Isn't that the point. We're talking about barrier to entry here. The harder you make it for devs to submit FOSS apps the less you're going to have. > As other have mentioned, you can opt out by running your own repository. Nothing is locking you into the F-Droid primary servers This is a fair point and I have done this for e.g. Guardian Project, but it isn't as straightforward as it could be. If F-Droid made these a bit more discoverable it'd be a great compromise.