Oss Sponsors Fundraising

OSS Sponsors Fundraising

You design the sponsorship program of an open-source project: who is being asked, for how much, in exchange for what, through which platform, and how the maintainer stays able to deliver it in two years.

Findings that shape every decision below:

• Salary-shaped income comes from companies, not individuals: GitHub reports that in 2022 "nearly 40% of sponsorship funding came from organizations"; Filippo Valsorda measured typical individual-sponsorship income for a widely depended-on library at under $1,000/month.
• Every reward promised is recurring work for an already stretched maintainer: Tidelift's 2020 survey put burnout at 46% of professional maintainers, 58% for maintainers of widely used projects.

Getting paid also changes what the project can do. Tidelift's 2024 maintainer survey (400+ respondents) found 60% of maintainers unpaid, and paid maintainers 55% more likely to implement critical security and maintenance practices: signed releases with provenance 50% versus 28%, two-factor authentication 76% versus 68%. Use that when the maintainer feels asking for money is impolite.

Figures like these name their source inline or in the reference files; any figure marked baseline is this skill's own default, a starting point to argue with, never an industry standard.

If the user is a company deciding which projects to fund and at what tier, this is the wrong side of the table - route them to samber/developer-relations-skills@oss-sponsors-brand-strategy and stop.

Interview

Ask one question at a time, multiple-choice where you can, and stop as soon as you know the project, the goal amount, and the honest delivery capacity. Confirm the rest as you design.

Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

1. Which project, and what is your role - sole maintainer, one of a team, or a company employee maintaining it on work time?
2. What do you want the money to change: buy back hours, cover infrastructure costs, fund a specific deliverable, or replace a salary? Name a monthly number, even a rough one.
3. By what date does that money have to be arriving - this quarter, this year, no deadline?
4. Do you want a one-off win (a funded deliverable, a conference trip, a hardware bill) or a compounding asset that still pays in two years?
5. Who actually uses this - individual developers, companies building products on it, or both? How do you know?
6. Can you name three companies that depend on it, and how you know they do?
7. What is already in place: GitHub Sponsors, Open Collective, Ko-fi, a FUNDING.yml, nothing?
8. What is your effort ceiling: how much sponsor-facing work can you absorb per month, in a bad month - hours, not intentions? Would you sign a commitment you cannot walk back?
9. Do you have a legal entity, or would money come to you personally? Which country?
10. What surfaces do you control, with rough numbers: repository traffic, docs site, newsletter, social following, conference talks?
11. Is anything commercial attached already - paid support, a hosted product, an employer with a claim on the work?
12. What would you refuse to sell at any price?

Answers 3, 4 and 8 re-rank step 2's shape menu - carry them there instead of re-asking:

• Q3, a date inside this quarter: promotes gratitude and visibility, the only shapes that pay before they are finished being built.
• Q4, a compounding mandate: promotes the retainer and the visibility placement, both of which keep paying after the launch push stops.
• Q8, an effort ceiling of a couple of hours in a bad month: deletes the access program.
• Q8, a refusal to sign anything unwalkable: deletes the retainer.

Record the answers. If your harness has persistent memory, store the resulting program brief there; tier prices are effectively permanent on some platforms, and later sessions must not redesign the ladder from scratch.

Step 1 - Test whether sponsorship is even the right instrument

Sponsorship is one funding instrument among five, opensource.guide's own inventory:

• Employment: open-source time written into a job.
• Individual crowdfunding.
• Project-level corporate sponsorship.
• Commercial revenue: support, hosting, premium features.
• Grants.

Individual sponsorship is also the slowest route to a living wage: the under-$1,000/month figure above is what it typically yields even for a widely depended-on library.

Say this out loud before designing anything:

• Q2 = "replace a salary" and the project has a few hundred users: recommend employment or a commercial tier, with sponsorship as a supplement - even though that is not what this skill builds.
• Q2 = buying back a day a week or covering costs: sponsorship fits well.

Check grants the same way: a project with a research, infrastructure or security angle often clears a grant faster than a hundred $5 sponsors. When it does, run step 1b alongside the rest.

Do not rank those five instruments against each other by efficiency here: a ranking would be false precision over a choice question 2 already made. A salary-replacement goal makes employment dominant whatever it costs to find, an infrastructure or security angle makes a grant dominant, and both verdicts hold at any effort level. The programs inside the grant lane, and the shapes inside sponsorship, do get ranked.

Step 1b - Run the grant lane

A grant is not a larger sponsor. It is a fixed-term contract with an eligibility gate in front and a reporting duty behind: it ends on a date, and it pays against proof. Run it alongside the sponsorship program, never instead of it.

Qualify before writing. Four gates reject more applications than weak prose does, and interview answer 9 already settles two of them:

• Licence. Every program requires a recognised open-source licence, several extending it to documentation and research output.
• Who can be paid. Some contract with an individual, some need a legal entity, some pay an organisation only and expect a fiscal sponsor when the project has none.
• Geography. The restriction binds the recipient, not the code: residency preferences, national tax residency, sanctions exclusions.
• Maturity and scope. Infrastructure funds want a depended-on library and refuse prototypes, prototype funds want new work, science funds want demonstrated use in their own field.

Programs rank by money won per hour of application and compliance work. Five families: direct funds paying an individual, cohort security funds, agency infrastructure funds, national innovation funds, foundation science grants.

• efficiency: direct > cohort > agency > national > foundation
• value (money per award): foundation > agency > national > direct > cohort
• effort: foundation > national > agency > direct > cohort - a foundation wants a letter of inquiry, an invited proposal and an institutional signature, an agency runs months from application to contract, a direct fund is one form
• compliance cost: national > foundation > agency > cohort > direct

What this order starves: the foundation grants, the only ones funding years of named headcount. Promote them when the project already has an institutional home or a fiscal sponsor, and delete them when it has neither.

Write to the committee, not to the sponsor page. Step 5 sells a maintainer's credibility to a reader who already likes the project; a proposal is scored against published criteria by a reviewer reading dozens in a sitting.

• Lead with the dependency, not the story. Prevalence, criticality and who breaks if the project stops are scored criteria.