Asking for a FUNDING.yml for every new app included in F-Droid

I don’t like the idea of doing Microsoft’s advertising for them. Doesn’t this centralize Github as the de-facto main payment gatekeeper?

Given the npm mishap from a while back where Github intervened and rolled back the commit where the maintainer sabotaged their own repo— This is an example of Microsoft taking away control from the users on their platform. I don’t like the idea of Microsoft being able to shutdown a developer’s income method.

Github supports custom URLs, can you just stick crypto addresses in there?

This is the biggest issue from what I see. It’s putting Github in complete control of how you format FUNDING.yml and even what is allowed inside.

What if Github decides to only allow payments in Github™ NFTs or to ban privacy respecting crypto like Monero?

Can’t control what you don’t own, can’t own what you don’t control.

3 Likes

Are you sure you understood the topic correctly? It’s about a text file developers can put into their apps’ repos – be it on Github, GitLab, Codeberg, Sourceforge or wherever they host them. What we recognize is up to us to define. Should Github decide to not support a field anymore that does not mean we won’t (it’s just no longer taken for their sponsors program then). It’s an option we can use. It’s nothing about them being “payment gatekeepers” as it’s up to the developers what they put in there. And we still can support other formats via our metadata. Same as we can use our methods for sanitizing URLs, or decide which of the FUNDING.yml fields we want to support and which not.

1 Like

Yes and no, eg. Github could just say the file syntax is invalid and not enable “sponsors”. Yes, F-Droid can read and use all fields, but ultimately devs could be forced to remove fields as Github wishes.

That’s true – but doesn’t stop developers from using it with their Codeberg or Sourcehut repos. Or us from supporting a 3rd location Github ignores :stuck_out_tongue:

Apart from that, while it’s possible, I think it’s rather unlikely. But right, who knows… Nevertheless: we support it, and we can suggest devs to use it. As a “nice-to-have”, not a “mandatory requirement” – leaving the decision entirely to them.

Does F-Droid really want to associate themselves this closely with something that is not a standardized file format and is tied to Microsoft (and their long history of abusive practices)? Why not, instead, just create your own file name and format that is defined by F-Droid and completely separate from what GitHub is doing? That way, all the positives are accomplished and there are none of the negatives.

You’re seeing this too, right? :slight_smile:

Those are like 2 or 3 right? Known F/LOSS Development of F-Droid Apps :roll_eyes:

Around 5 in sr.ht, and 60 in Codeberg; the linked list is growing slowly, and imperfectly.

But true, F-Droid is dependent on microsoft github, and should be tagged as such. :laughing:

2 Likes

Those 2 places were just examples. There’re also those on GitLab (dot-com or self-hosted) and various other self-hosted places (e.g. using Gitea), NotABug, Gitee, SourceForge – and those poor souls left behind on Github are always free to migrate (Gitea makes that easy). Plus, as pointed out, we can always introduce a 3rd location (e.g. directly inside subdir:) for the FUNDING.yml should there be any conflicts in the future.

Sure we could introduce our own format (someone volunteering to develop that and integrate it with fdroidserver?) But seeing how much effort it sometimes takes to convince developers to establish Fastlane structures even when provided via pull/merge requests, I don’t have much hope convincing them about yet another format which is even only useful for F-Droid.

1 Like

Currently, FUNDING.yml is the only “standard”. It’s not an official standard, only a de-facto one, but if F-Droid would make its own standard then we have 2 standards. Unless something is really wrong with the first standard, I see no reason to do this. And in my view, FUNDING.yml is perfectly adequate.

Besides that, while I share your healthy scepticism for Microsoft with regards to the Open Source community, not all they do is evil.

1 Like

not everything but everything they touch turns into their devil interest​:money_mouth_face::money_mouth_face::money_mouth_face::money_mouth_face:

@Izzy

There’re also those on GitLab (dot-com or self-hosted) and various other self-hosted places (e.g. using Gitea), NotABug, Gitee, SourceForge – and those poor souls left behind on Github are always free to migrate (Gitea makes that easy).

Estimate is ~3000+ main f-droid apps are on proprietary microsoft github. About 200 have “no source since”. About 300 are on non-proprietary dev’ sites. Consensus was main gitlab dot com is also a proprietary license dev’ site.

Currently, FUNDING.yml is the only “standard”.

This thread already contains a description of how this defacto standard is insufficient for the needs of F-Droid, so they would need to extend it anyway. Instead of creating hybrid extensions to GitHub’s proprietary standard (which they could change at any point going forward in ways that break F-Droid’s implementation), why not just go with your own solution that meets the needs of the project?

Shoud that be considered an anti-feature?

I would actually be in favor of F-Droid dropping Fastlane as the recommended file structure and doing their own thing. That way it can incorporate things like donation information and better match the needs of F-Droid.

I think it would be OK for F-Droid to fall back on Fastlane or FUNDING.yml if F-Droid’s own format is nout found in the source code, but I don’t think those things should be the default.

As much as I understand your approach, Soren – that would put too much load on our shoulders, delay inclusion and updates further (which users won’t like, and neither we) as each and every change would need an MR (and thus someone of our team to manually process it). Further, we had to host all graphics (screenshots etc) in our repo, which would “blow” it.

Honestly, even if we had the resources to come up with and implement some “own format” – which dev would use it if it cannot be used for anything else? It’s already hard enough to convince them of fastlane, which can be used for Play and Apple as well and thus ease their load as well as ours.

And using the same structure and file formats (fastlane, funding) IMHO is no anti-feature. It does not involve any proprietary software: it’s just placing the files, you don’t even need their binaries (and even if, Fastlane is using MIT as license). I don’t see what’s wrong with that.

1 Like

How would this not be less work than what you are proposing? Creating your own FUNDING.yml file with a different name and adding in the fields you need for crypto currency or anything else that might come up in the future can’t be more work than parsing the existing FUNDING.yml file, updating your parser every time that Microsoft decides to change their format, and then looking for the rest of the information somewhere else that FUNDING.yml won’t let you include.

As a developer who added Fastlane information to my code base just for F-Droid I get where you are coming from. And I remember how painful it was because Fastlane isn’t that well documented, and there were differences between what little documentation they do have and how it ended up functioning in F-Droid. For example, why do country specific locals (pt-BR) use a different syntax than Android’s admittedly odd syntax (pt-rBR)? And, exactly, how many characters of a changelog are going to display in the various places where F-Droid displays them?

Trying to shoehorn developers into Fastlane, which is trying to be too generic for compatibility with things like iOS, and then trying to shoehorn the Fastlane format into something that is compatible with F-Droid’s needs doesn’t feel like the best solution long-term. It seems to me like that it would make a whole lot more sense for F-Droid to create a F-Droid spec stored in a fdroid/ directory next to where fastlane/ is stored. You can start with the Fastlane syntax if it is helpful, and then modify it to include a FUNDING.yml or whatever else is needed, but then customize it so that all the fields and functions match how they are used in F-Droid and document that on your website. It seems to me it would work a whole lot better and have the added advantage of requiring less of a maintenance burden over the long term.

And, like I said, you could always fall back on Fastlane or FUNDING.yml or whatever else might be in the source code if you have the desire to chase down their imperfectly matching file formats and try to interpret them in ways that make sense for F-Droid.

Which is why I set up this snippet long ago to assist you :wink: I however cannot answer you the design specifics as I didn’t invent them. Details on how many characters fit in where should be in my snippet (500 chars for the per-release changelogs, for example, or image dimensions when it comes to graphics).

I’ll stop at that place because I definitely will not be the one implementing things in fdroidserver (that’s not only out of my scope but also out of my proficiency). So what gets implemented or not and why is for someone else to answer.

So maybe we can focus on the original topic: both fastlane and FUNDING.yml are currently supported by fdroidserver, so no additional implementation has to be done (though merge requests are certainly welcome I guess). And especially FUNDING.yml is easy to set up. So why not suggesting their use?

Google has a 500 character limit on changelogs, but other app stores like Amazon or Samsung have higher limits. The changelogs I include in my Fastlane data for F-Droid are longer than 500 characters. This is an example of my point about how trying to shoehorn Fastlane to work for F-Droid is suboptimal. Whatever the character limit should be for changelogs, it should be a lot larger than 500 characters. That should be a discussion that F-Droid should have, not being constrained by something that Fastlane or one of the app stores that they appeal to should dictate. And once F-Droid has made a decision on that subject, it should be well documented and it should be consistently applied in all of the interfaces where F-Droid displays changelogs.

I feel like you are making my point for me.

Feel free to collect any points you want. The reason I wrote to stop at this point is that this is not the topic of this discussion. Anyone is welcome to open their own thread. And again, I’m not a developer, so I cannot implement that anyway. Did you just volunteer?

(Last remark: 500 chars should be more than enough for a changelog IMHO. I wouldn’t want to scroll through an essay on my way to the details below :see_no_evil: Longer details is what the Changelog: link is for.)

1 Like

The point is that FUNDING.yml and Fastlane are suboptimal fits for F-Droid, which is exactly what this thread is about.