After a discussion with @Izzy, we came to the conclusion that it could be a good idea to ask for a FUNDING.yml file inside the repo as well. This file is what’s used by Github to store the information for their GitHub Sponsors program, and this information then appear under the button “Sponsor” in a GitHub repo. You have to register with GitHub to have a Sponsor Button. Otherwise, even if there is FUNDING.yml in your repo, the button “Sponsor” won’t appear. I collected some useful templates and information here.
F-Droid is already reading this file (it has to be inside a .github folder, or directly at the root of the repo). The information are taken from this FUNDING.yml file and added in the index, and then the information appear ! (example with TrailSense, the donate information don’t appear in the metadata file because they are taken directly from the FUNDING.yml file)
So far, most of the repos with a FUNDING.yml file have one because they subscribed to the GitHub Sponsors program.
We think it could be a good idea to ask for a FUNDING.yml file (before including the app in F-Droid, or during the RFP) even if the developer didn’t registered with GitHub Sponsors because :
I don’t see any disadvantage. This would still be a lower priority suggestion for the RFP and the new apps. If the developer doesn’t want this file in its repo, we’ll keep the donate information in the F-Droid metadata.
Then in the future, I’ll spend some time to contribute this FUNDING.yml file to the upstream repos of apps already in F-Droid, so we can remove most of the donate information form our metadata.
What do you think? Should we add a hint about FUNDING.yml files in the Issues of the RFP repo and actively decentralize the handling of donate links ? Does anyone see any counter-indications?
For not-github, we would put the file at the root at the repo. Like I said in my post, F-Droid is already checking the root of repos for this FUNFING.yml file, it’s the easiest way since it’s already implemented, no need for a subdirectory for repos outside of GitHub.
After a discussion with @Izzy, we came to the conclusion that it could be a good idea to ask for a FUNDING.yml file inside the repo as well.
@Poussinou I’d say just put a note in issuebot and tell developers “Hey, if you support donations, consider putting a FUNDING.yml file in your repo”.
What about not-Github? There will be a .gitlab/funding.yml or .sourcehut/funding.yml or .codeberg/funding.yml ?
@Licaon_Kter FUNDING.yml is a GitHub-created standard and the standard implies putting it either at the root or in .github in a repo. Supporting those (as we already do) seems fine for now.
I think supporting .gitlab, .sourcehut, .codeberg, etc. would be a bad idea because then we’ll force GitHub’s standard onto those other platforms. However, if those platforms document you can put it in .gitlab or whatever, sure, because then that service decided to support it in their namespace.
There is another problem. FUNDING.yml doesn’t support Bitcoin or Litecoin, but F-Droid does.
Do we try to add new entries to the FUNDING.yml format for the cryptos or other ways to donate, or should we separate the source, put the crypto information in the F-Droid metadata and the rest in the FUNDING.yml file?
Things missing in FUNDING.yml can still be kept inside our YAML metadata.
Another option might be available only if Github ignores unknown entries by default, in which case we could suppose simply adding them (ideally using the same “keys” as in our YAML). But while this sounds fine at first glance: what if Github (as the ones defining the standard) at some point decides to add the very same service, but by using a different name? So maybe better stick to our YAML for those.
Yes, it will stay a small recommendation ! For example, if the developer has no option to donate, we won’t ask for an empty FUNDING.yml file, it makes no sense.
If we want to add new entries in the funding.yml file, we would need to make a try on a repo first. And yes that’s right, GitHub can break the Sponsor button whenever they want if the yml file contains unknown entries…
Asking never hurts (unless you ask for hurt ) You could ask neutrally if the format is extensible and how to add support for yet unlisted possibilities. You could also ask whether it would “break things” when you add your own – but that would only be one side of the medal, whether your addition breaks their sponsor display. This might also happen the other way around. Say you add “bitcoin” as a string, then later they add “crypto” as an array with bitcoin, litecoin etc. inside. Will be a mess to clean up
I think it’s the good discussion to ask if we can add new entries. Apparently, GitHub is showing a warning message if the FUNDING.yml file is not well formated, aka there are weird entries that are not recognized.
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.
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.
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
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.
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.
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.
) You could ask neutrally if the format is extensible and how to add support for yet unlisted possibilities. You could also ask whether it would “break things” when you add your own – but that would only be one side of the medal, whether your addition breaks their sponsor display. This might also happen the other way around. Say you add “bitcoin” as a string, then later they add “crypto” as an array with bitcoin, litecoin etc. inside. Will be a mess to clean up 
