Metadata for funding information

Hi all,

I am curious about the state of meta data for funding in FOSS projects and about the right direction to try to make the things move forward. What I have seen so far is two type of places, in the manifest files of package managers and in a dedicated file in the code repo.

Funding info in manifest files

Here is what I have found so far:

Funding info in a dedicated file

On Github, there is the possibility to have a FUNDING.yml file, Getting started with GitHub Sponsors | The GitHub Blog . From what I understand, it has to be in the .github folder (which is a bit specific, but not an insurmountable interop problem).

I haven’t yet figured out on how to access this info via Github API (but surely haven’t looked properly).

Also, I was wondering if there was any plan to have equivalent feature (displaying funding options) in Gitlab.

Any thoughts on this?
Thanks!
Camille

3 Likes

I haven’t done a broader analysis since the package managers started adding funding metadata to the manifests, but I’ve found crawling GitHub for FUNDING.yml files to be very valuable. I’ve taken two different approaches to this in the past.

When Sponsors first launched, I had a polling script that ran nightly and basically ran a cross-github search for any files called funding.yml and downloaded all of them that the search API would return. Sponsors was growing slowly at the time, and so I was able to build up a local data set of funding.yml files that was pretty expansive, and do an analysis for preferred funding types. I got some interesting insights from this work (PayPal was the #1 preferred custom funding type, and was far and away more popular than most of the named funding types. Patreon was the #2 named funding type behind GitHub Sponsors), but those insights are fairly dated today. This was a long-running process with thousands of API calls.

At some point I narrowed my focus and started looking for funding.yml files that were just for dependencies used by my employers. Getting these was a little more complicated on my end, but the API calls were easier. The process looked approximately like this:

  • Get a list of dependencies
  • Determine the source URL for each dependency
  • Filter the source URLs looking for GitHub URLs
  • Chunk the GitHub-based dependencies list chunks of ~ 1000 dependencies
  • Use GitHub’s GraphQL API to search for a file called ‘funding.yml’ across each list chunk

I wasn’t downloading the files for further analysis anymore, so this was a short-running process with a couple dozen API calls. In the end it told me which repos were fundable, and from there I merged in some other metadata (how widely used was it, where did we use it, etc) to determine which repos I wanted to learn more about. This approach was easier overall, IMO, but it required more up-front work.

One potential gotcha you should be aware of is that the funding.yml file could be in github.com/OWNER/REPO/.github/ or it could be in github.com/OWNER/.github/ - adding the file to a top-level .github folder in your org or user account will apply it to all of your repos. (See GitHub - babel/.github: Community health files for the Babel organization for an example).

Obviously, it’s a platform specific approach, and it won’t cover all scenarios. But depending on what you want from your investigation it’s potentially good enough. Analyzing funding.yml files will help you identify trends in the ecosystem at the cost of having some gaps in your data. If you want a comprehensive map of the landscape with no gaps, you’ll need to supplement the analysis with information from the package managers.

Hope this helps! Good luck!

3 Likes

Thanks very much @DuaneOBrien

I am also interested to know is there were any attempts at building universal convention that people can use in their repos to indicate that they need support.

The best way I can think of to push this forward is to open a discussion in projects like GitLab and https://liberapay.com/ to know their take on this problem.

Going from another end, start with a set of user stories. Like “as an author of PR that improves a public Open Source project by Facebook, I want the company to be able to see that I need funding and get a chance to support me back”.

Indeed, I would really like to have Gitlab involved in this. I think it would be great to have funding information displayed there also, like Github does.

1 Like

A search for “funding” on GitLab revealed these issues

Nothing really actionable like “implement funding metadata format” or “show funding button for open source projects”. I guess the process just lacks consistent weekly championship, because for existing contributors there are always a lot of other things that take priority. Like technical debts or maintenance routine.

It is an interesting issue in itself to track what priorities steal the goal each week for each person who is sincerely interested to see this implemented. I believe there are a lot of supporters of this idea, and at least for me personally visibility into what is more important for me every week will give a good understanding why I am not contributing to the issue that is rather critical for me.

1 Like

The main problem that I’ve seen is that there have been individual, emergent pushes to add funding metadata, but they have been ecosystem-specific. Which means that someone still has to crawl the package ecosystems for the metadata and aggregate them into a common format. The funding.yml from GitHub is the best cross-ecosystem solution to-date, but it’s already platform specific because it requires the data to be in a .github/ directory.

I don’t think we’ll ever really get a cross-ecosystem, cross-platform standard. But we could get cross-ecosystem, cross-platform tooling that aggregates the information.

I would not be surprised if @benjam and @andrew integrate that in their new https://ecosyste.ms/ project.

The data itself is just a yaml file and technically it’s in the git repo so it’s not the worst ‘standard’ for sharing this stuff.

My hope is that by scraping and presenting the data on ecosystems, and encouraging others to use that data, we can encourage others to add a funding.yaml to their repos on other platforms too.

FUNDING.yml is not bad for the start. For projects like GitLab it can be placed at the top to get this metadata lookup logic.

  • FUNDING.yml
  • .github/FUNDING.yml

The format itself covers only one story “what is the project’s $tdin”. Maybe it is not that bad, and it could be used as a pointer to more sophisticates use cases, like “who from contributors needs cash the most right now”.