Publish to F-Droid

[aha999]

F-Droid is an app-store that hosts free and open source android apps for download (like google play but only for FOSS), which builds apps directly from source code, so apps are matching source code and are transparent. If you published your app to F-Droid. i think that the number of users will increase as it's very convenient, findable and easy to update. Most of the FOSS android apps are on F-Droid as far as i know and it's great!

• F-Droid documentation for developers: instructions

• If you're fine with publishing it on F-Droid, you could create a Request for Packaging.

• Requests for packaging: RFP

[zbejas]

Portarius will not be uploaded to F-Droid.

[IzzySoft]

Technically you're absolutely correct, @zbejas – no app is ever "uploaded" to F-Droid; F-Droid builds apps from their resp. sources. So are you opposed to that – or would you be OK with F-Droid including your app? Sounds a bit strange to make a FOSS app and not allowing FOSS-like distribution. The license you've chosen explicitly allows that, btw 😉

[zbejas]

Technically you're absolutely correct, @zbejas – no app is ever "uploaded" to F-Droid; F-Droid builds apps from their resp. sources. So are you opposed to that – or would you be OK with F-Droid including your app? Sounds a bit strange to make a FOSS app and not allowing FOSS-like distribution. The license you've chosen explicitly allows that, btw wink

I am not opposed to that @IzzySoft . However, I don't really use F-Droid, so I didn't really read more than some of the FAQ. I don't really want to bother with any problems in the future if I decide to include any third party (Google for example) services. I can put in a request for packaging, but what happens if I add anything later that is not FOSS?

[IzzySoft]

Fair enough, @zbejas – and yes, if you'd add non-free dependencies, F-Droid could no longer update your app (exceptions to that exist where a packager finds a way to get rid of that in the build recipe like e.g. replacing Google Analytics with a stub; but if it's something needed for core functionality, this option does not exist).

OK, a middle way does exist, to a degree. Let me take a look, IIRC your app meets the inclusion criteria of my repository which is the second-largest one currently with close to 1k apps and a bit more lenient (part of the idea is to give apps which are "so close but not close enough" a chance, and also serve as a stepping stone on the way to F-Droid.org – hundreds of apps have meanwhile "passed through"):

• size: 22M < 30M ✔️
• libs: no offending lib reported by my scanner < 4 tolerated ✔️
• license: GPL-3.0-or-later = OSI/FSF approved FOSS license ✔️
• APK file available at tagged releases ✔️
• description and screenshots available so it's clear what the app is about ✔️
• not part of an "excluded category" ✔️
• proper versioning: ❌ package: name='si.zbe.portarius' versionCode='1' versionName='1.0.2' – versionName is fine, following semantic versioning but this is not the first release and versionCode is still set to 1 (please remember to always increase versionCode before tagging a new release and building its APK – Google will require the same for PlayStore (you did not notice yet because you only uploaded a single version yet, but would hit this stopper with the next one). versionCode is what Android uses internally to tell versions apart – so the combination of applicationId+versionCode must be unique)

All in all, it seems your app seems even to meet F-Droid's stronger inclusion criteria – though to be sure about that we'd need to see the full scan results of F-Droid scanners (my scanner is only part of that) which e.g. also watch out for "blobs" to ensure all the source is there to build the app without using any pre-compiled stuff. Meanwhile, your app passed all checks in my repo and will show up here with the next sync around 6 pm UTC – if you like what you see there, you're welcome to pick a badge to link there e.g. from your Readme. Updates are fetched within 24h of your tagging a new release and adding the APK to it (please make sure to have the versionCode fixed then so users will receive update notifications).

As said: yes, please go ahead and open an RFP with F-Droid. F-Droid just requires you're not opposed to inclusion (no need in fighting each other; though technically the license allows distribution, fights just consume energy better spent on productive things on both sides). Ideally, the dev actively supports inclusion – so if e.g. build issues come up we can hope for support. If you plan for non-foss elements in the future, hopefully you will consider build flavors right from the start to have one flavor that stays FOSS and F-Droid can build from 😉

Disclosure: I'm one of the F-Droid maintainers.

[zbejas]

Glad we came to some sort of understanding @IzzySoft. The versioning was done badly at the start, and I had no clue why on Play Console it said that versions 1.0.1 and 1.0.2 are the same, so I think I already fixed that part in 1.0.3 and forward in git releases too(1.0.3+5 is the version code for this one), will be 1.1.0 when released as a stable version.

Do correct me if I'm wrong.

[IzzySoft]

Ah, you already ran into that. Glad you already applied the correct solution then: 1.0.3+5 sounds fine (basically, everything with a versionCode > 1 would do for the next release – just remember to always increase it with the future ones).

So yes, that would work – and yes, that was exactly what I had in mind: same versionCode for Android means it is the very same version, so no "store" would accept it for update. As it's still a thing happening not only to "junior Android devs" and more often than you'd think, I've implemented a dirty work-around in my repo (quarantining the existing APK and replacing it with the new) – but that only helps new users to get the latest version from the start, there would be no update notifications ever.

[zbejas]

Thank you for your tips.
With this, I will close this issue.