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.
• Price the work in hours at a named rate, then map those hours to milestones you would accept being paid against, because you will be.
• Answer "why not the existing thing" explicitly. The open forms ask it outright, and a missing answer reads as no landscape research.

Plan the reporting before accepting. A sponsor renews on a thank-you post and churns quietly; a grant-maker withholds payment against a named report on a fixed schedule and reclaims what goes unspent. Charge that admin against the effort ceiling from question 8.

Gates per program, application fields, scoring criteria, post-award duties, and the programs that no longer accept applications are in references/grant-programs-and-reporting.md. Read it before naming a program to the user.

Step 2 - Brainstorm the program shape, then choose one

Enter brainstorming mode. Sketch two or three candidate programs that could hit the stated number, then recommend one and say why the others lose. Get explicit agreement before pricing anything.

The four shapes are ranked by value returned per unit of maintainer effort - effort meaning recurring maintainer hours, obligations that never end, and how hard a published promise is to withdraw. Say the efficiency order out loud rather than leaving it implied by row order. The axes disagree, so read all of them; each line is descending on its own axis, highest first.

• efficiency: visibility > gratitude > retainer > access
• value (monthly income the shape can reach): retainer > access > visibility > gratitude - visibility overtakes access wherever placement traffic runs to tens of thousands of monthly views
• effort: access > retainer > visibility > gratitude
• compliance cost: retainer > visibility > access == gratitude

Effort in magnitudes:

• Gratitude: near-zero once the page exists.

• Visibility: about an hour per sponsor for a logo commit and a placement check.

• Access and retainer: both standing jobs.

• Visibility program. Company tiers priced against real placement traffic - README, docs site, homepage. Delivery is a logo commit; income scales with the audience the project actually has. Default first shape wherever the docs or README get measurable traffic.

• Gratitude program. Low tiers, no perks, one clear ask. Right for a project with many small users and a maintainer with no spare hours, and the base layer underneath any other shape.

• Retainer program. A handful of dependent companies pay for named commitments (response times, security triage, upgrade support). Fewest sponsors, largest cheques, most obligation.

• Access program. Sponsor-only content, early access, or sponsorware. The best-documented conversion on record and the highest recurring cost - it bolts a content business onto a maintenance job. Right only when an audience already exists.

• Split the two standing jobs on cadence: access ships whether or not anyone asked, while retainer work is triggered by a dependent company's occasional need - which is why the larger cheque also costs fewer hours and ranks above it.

• Justify the compliance tie: neither access nor gratitude commits the project to a named company or puts a third party's brand on its surfaces, and both can be withdrawn from new sponsors in one commit.

• The retainer tops the compliance-cost line: an entity, numbered invoices, tax handling, and a written commitment that is expensive to break. Visibility sits second: a published price is permanent on GitHub Sponsors, and a sponsor logo needs the refusal rule from step 8 before the first one appears.

• What this order starves: the retainer. It is the only shape that reaches salary-shaped income and the only one that obligates real delivery, so it tops the value line and the compliance line at once, and the ratio buries it every round. A maintainer who only ever obeys the efficiency line stays at coffee money permanently.

• Promote the retainer above everything when question 2's answer was "replace a salary", when three dependent companies can be named, and when an entity or fiscal host already exists.

• Delete rather than demote, and say which:

  • No entity and no willingness to use a fiscal host deletes the retainer.
  • No audience beyond the repository (no docs traffic, no newsletter, no talks) deletes access.
  • A README and docs with no countable traffic delete the visibility program, since placement that cannot be measured cannot be priced.

• Most working programs are a gratitude base plus one of the other shapes; recommend a combination only when the maintainer can service both halves.

• This order is a default, not a law: it shifts with context and with who executes it.

• Re-rank it against what you already know about this maintainer before presenting it:

  • An existing newsletter or conference audience promotes access, because the distribution is already built.
  • An employer already paying for the work removes the retainer's premise.
  • A team of three can service a shape a sole maintainer has to delete.

Step 3 - Build the ladder for two buyers

A ladder serves two buyers that behave nothing alike:

• Individuals pay $5-$25 from their own pocket, decide in seconds, and want gratitude or a personal perk.
• Companies pay from a budget line, need an invoice and a named beneficiary, and want a benefit an approver can defend.

The placement-selling ladders in the reference file (Vue, Sindre Sorhus) put the individual/company boundary near $100/month; treat that split as a baseline and move it if the audience says otherwise.

These rules decide most of the ladder - the first four come from the published ladders in the reference file, the last two from GitHub's documentation:

• Price company placement by the audience it reaches, not by generosity. "Logo on a README with 20k monthly views" is a media buy an approver can sign off; "gold sponsor" is not. Sindre Sorhus publishes per-placement monthly view counts and prices against them.
• Name tiers for the buyer. "The Agency" or "Team" tells a company the tier is theirs; "Platinum" makes them guess - Caleb Porzio's own conclusion after testing his tiers.
• Never put a partial-perk tier just below the tier that converts. "If people have the option of paying $1-5/mo. instead of >$14, they will pay the lesser amount" (Porzio). A no-perk gratitude tier below the perk tier is fine and even useful.
• Expect one tier to carry the program. In both individual ladders on record, a single tier drives conversion and the others catch generosity above and below it.
• Treat published prices as permanent. On GitHub Sponsors a published tier's price can never be edited - only retired and replaced, with existing sponsors left on the old tier. Price for two years from now; the platform ceiling is $12,000/month.
• Keep the ladder short. Three to five live tiers as a baseline; the platform allows ten published monthly tiers and nobody reads ten.

Reference ladders from Vue, Sindre Sorhus and Caleb Porzio, with pri

...