GitHub puts a "Sponsor" heart icon on every public repository by default[1]. The visitor clicks it and lands on whatever you have configured. If you have configured nothing, they see "this maintainer does not currently accept sponsorships."
A more useful default for many maintainers: redirect the button to charities.
The pattern
In your repo at .github/FUNDING.yml:
yaml# Donations are redirected to UK and global humanitarian charities. # Pick whichever cause speaks to you. custom: - https://literacytrust.org.uk/donate - https://www.trussell.org.uk/get-involved/donate - https://www.mind.org.uk/donate - https://www.dec.org.uk
That is the entire configuration. GitHub renders the four URLs as named buttons in the Sponsor popover. Click any one, you land on the charity's donation page[3][4][5][6]. No money flows to you. No payment processor in your name. No tax event.
Across my twelve open-source repositories, this gives a single coordinated answer: every Sponsor button on every repo points at the same four charities[2].
Why this might be the right default
Three reasons, in increasing order of how rarely people talk about them.
Personal sponsorships are awkward at low scale. If you get one £5/month sponsor, you do not really feel sponsored, and the recipient (you) gets the awkward task of figuring out what to do with the money. For most OSS maintainers the volume is not high enough to make personal sponsorships a meaningful income; it is high enough to be administratively annoying.
The Sponsor button gets clicked by people who feel a bit guilty. Someone solved their problem with your code. They want to express thanks. The button takes that good will and makes it actionable. Pointing it at a charity converts a guilty click into a real donation, which feels good for the visitor and does no harm to you.
It side-steps tax and reporting complexity entirely. Self-employment income, VAT thresholds, Stripe verification, tax-residency rules, employer policy on side income, all the dull things that come with accepting money you did not need: none of it applies if no money flows to you.
For maintainers in tax-complicated situations (visa restrictions on self-employment, day jobs that ban side income, charitable-organisation status, university affiliation, corporate IP rules), the charity-redirect pattern is the simplest legal answer.
The four-URL limit
GitHub's custom: array caps at four URLs. You cannot list ten charities and let the visitor pick. Pick four with intention.
A balanced shortlist for UK-leaning OSS maintainers:
| Charity | Cause | Reach |
|---|---|---|
| The National Literacy Trust | Education and literacy | UK |
| The Trussell Trust | Foodbank network | UK |
| Mind | Mental health | UK |
| DEC (Disasters Emergency Committee) | Humanitarian crises | Global |
If your audience is more international, swap two of the UK charities for Médecins Sans Frontières and UNICEF. If your project is climate-themed, point at clean-air or rewilding charities. If it is dev-tooling-themed, you could include Code Club or the Raspberry Pi Foundation. The pattern works regardless.
What you give up
Two things.
Direct attribution. GitHub does not tell you who clicked the button or which charity link they followed. You will not see a "you redirected 47 donations this month" stat. The flow ends at the charity, who has no idea the click came from your repo.
Personal recognition. Some maintainers genuinely value the social signal of a paid GitHub Sponsors profile. The charity redirect skips that.
If either of those matter to you, run a personal sponsorship instead. The charity pattern is for maintainers who would otherwise leave the button unconfigured.
A small lever for tracking
If you do want some signal, use a link shortener with click analytics in front of each charity URL. With Dub, Short.io, or your own redirector:
yamlcustom: - https://go.your-domain.com/literacy - https://go.your-domain.com/food - https://go.your-domain.com/mind - https://go.your-domain.com/dec
Each go.your-domain.com/ 302-redirects to the real charity URL. The shortener gives you click counts in real time. You still cannot tell who actually donated, but you do know "this many people clicked the food bank link this month", which is a soft proxy for charitable intent generated by your work.
The TL;DR
If you maintain public OSS and you are not actively running a personal Sponsors profile, point your FUNDING.yml custom: field at four charities you care about. Four lines, one commit per repo. Costs nothing, lets visitors do something kind on the way out, side-steps the entire personal-payment-acceptance machinery.
The verbatim configuration on all twelve of my repositories is at github.com/sarmakska/Sarmalink-ai/blob/main/.github/FUNDING.yml[2]. Copy it as-is or adapt the cause list. The pattern works for any maintainer.
---
A note on this post
The numbers, code excerpts, and commit hashes referenced are real and verifiable in the linked repository. Charts are rendered from the data tables shown above each chart. Where the post draws on third-party advisories or maintainer announcements, citations link to the primary source.