Expanding on funding.yml - how are the maintainers funded?

#1

funding.yml is used by github and lives in a .github folder in your git repo. There is the first-party Github sponsors, but also third-party “supported” items, plus you can add a custom entry that is just a link:

github: [octocat, surftocat]
patreon: octocat
tidelift: npm/octo-package
custom: ["https://www.paypal.me/octocat", octocat.com]

GitHub Docs page »

So, for starters, we should encourage stricteq and similar links in custom. It’s hidden behind the “Sponsors” button, which isn’t quite the right terminology.

Adding a FUNDING.md file

The meat of my idea that I’d love feedback on is this.

Can we suggest that people start adding a new file in the root of their repos that talks about how the project / the maintainers are funded / supported?

Here are two examples:

Bob maintains this library for his own needs. Donations are welcome but not necessary. Paid support or feature requests can be considered, please contact Bob if interested

Or:

Alice maintains this application as her day job. Your donations and commercial license purchases enable her to work on it full time, keep it bug free, and implement new features. Donations, sponsorships, and professional support, as well as custom development and implementation, are all available through Alice and the partners listed below.

I envision a handful of templates.

The goals are:

  • encourage people to signal how and if they want funding, how people can help with cash
  • promote maintainer and third party consulting around it
  • help build a community of people who want to be have open source software as their day job

Example found in the wild:

musl-wiki

musl has a Patreon to fund maintenance and development by the main project author, Rich Felker.

Other code contribitors have also performed porting and implementation of new functionality by contract. If there is functionality you need and want to fund that is or might be in the scope of the project, or that could be met with a side project (for an example, see musl-nscd), please get in touch.

What do you think of this idea?

1 Like
#2

On funding.yml: Yeah, I should probably set the system up to give people a nudge toward adding data there, at least if they already use it. I’m not sure I actually like funding.yml or GitHub’s implementation. Funding information is fundamentally something I want people to read, not machines. But I’m not going to fight it and win.

On a funding-specific text file: Folks have definitely been interested in this. I may or may not have proposed something similar.

I think the troubles are twofold:

First, folks trying to plan this out as a kind of standard or convention have fallen down deep, dark wells of overengineering, semantics, metadata schemas, and the like. I’ve seen definitions for various ways of describing project support from Mozilla and at least one other org. I wasted a good bit of time on one myself once, when the idea was still to make package.json a universal dumping group for all manner of project metadata.

Second, the gravitational pull of README is just too strong. It has already swallowed a great many LICENSE files, which used to stand alone, and made them ## License sections.

Fundamentally, if you want to get a message across, the way to do that is to put it right at the top of README.md, the one file people can actually be expected to look at now and then and services can be expected to try to render. Preferably with an eye-catching graphic or at least some standout formatting.

SomePackage.js

:fireworks::fireworks::fireworks: Buy a license to use this at work! :fireworks::fireworks::fireworks:

Similar themes came up in discussion of the funding metadata schema for package.json. We ended up shipping something that boiled down to “put links for calls to action here”. There were proposals to integrate a rather extensive metadata standard that went well beyond that, with all kinds of information corporate users might want to quantify the “risk” in a package.