samber/developer-relations-skills已通过检查
SKILL DETAIL
oss-sponsors-fundraising
samber/developer-relations-skills/oss-sponsors-fundraising
Designs a maintainer-side open-source sponsorship program - the tier ladder and its pricing for individual and corporate sponsors, rewards that stay deliverable at ten times the sponsor count, funding-goal and sustainability framing, and the invoice-and-entity path a company needs before it can pay. Use whenever a maintainer asks how to get sponsors or funding for a project, sets up or fixes GitHub Sponsors, Open Collective or FUNDING.yml, writes sponsor tiers, rewards or a sponsorship page, wonders why nobody sponsors a widely used project, considers sponsorware, or wants a company to fund maintenance work - even if they only say the project is unsustainable. Not the company side - use samber/developer-relations-skills@oss-sponsors-brand-strategy.
安装量 · 420查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill oss-sponsors-fundraising
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "oss-sponsors-fundraising",
"evals": [
{
"id": 1,
"prompt": "I maintain zodiac-rs, a Rust date/time crate - 1.1M downloads a month, 3.8k stars. My GitHub Sponsors tiers have been live for about a year: $1 'thanks', $5 'name in README', $10 'name in README but bigger', $25 'name in README + I answer your questions faster', $50 'all that + a monthly 1:1 call + logo somewhere'. I make $180/month off it. I want to drop the $1 tier, bump the $50 one up to $250, and slot in a new $15 tier that gets a sticker pack, sitting just under a $20 tier I'm adding for early access to release candidates. Can you redo the ladder for me?",
"expected_output": "A rebuilt ladder that treats the existing prices as permanent, refuses the partial-perk tier placed under the converting tier, strips the unbounded rewards out of the ladder, and adds company-priced placement tiers named for the buyer.",
"files": [],
"expectations": [
"States that a published GitHub Sponsors tier's price cannot be edited, so the $50 tier must be retired and a replacement published rather than 'bumped' to $250.",
"States that sponsors already on a retired tier remain on that tier until they change or cancel it themselves.",
"Rejects the $15 sticker-pack tier sitting just below the $20 early-access tier, on the ground that sponsors offered a cheaper partial perk will take the cheaper one.",
"Notes that a no-perk gratitude tier placed below the converting tier is acceptable, so the cheap $1/$5 rungs are not themselves the problem.",
"Adds at least one company-priced tier at or above $250/month.",
"Identifies that a $50 top tier clears no corporate procurement process.",
"Removes or rewrites the '$25 - I answer your questions faster' tier, distinguishing priority triage, which can be sold, from priority outcomes, which cannot.",
"Removes the monthly 1:1 call from the ladder entirely rather than repricing it into a higher tier.",
"Flags that the $5 and $10 tiers sell the same reward at different sizes, so sponsors default to the cheaper one.",
"Replaces 'logo somewhere' with a named, specific placement an approver can evaluate.",
"Prices at least one company tier against a stated placement audience figure (monthly views or equivalent traffic) rather than against generosity.",
"Names company tiers for the buyer, for example 'Team', 'Business' or 'Agency', instead of metal names like Gold or Platinum.",
"Keeps the live ladder to roughly three to five tiers and advises pricing for about two years ahead because the prices cannot later be edited."
]
},
{
"id": 2,
"prompt": "I'm the sole maintainer of mistral-gauge, a Python library for parsing pressure-sensor logs. About 190 GitHub stars, 4k downloads a month, and maybe 60 companies use it as far as I can tell. I want to go full time on it by March - I need $7,200/month to match what I make at my day job now. Set me up on GitHub Sponsors with tiers that get me there.",
"expected_output": "A direct statement that individual sponsorship cannot reach this number at this scale, a recommendation of employment or commercial revenue as the primary instrument, and sponsorship scoped down to a supplement.",
"files": [],
"expectations": [
"States plainly that individual sponsorship will not reach $7,200/month at this project's scale, instead of designing a ladder whose numbers nominally sum to the target.",
"Cites that typical individual-sponsorship income even for a widely depended-on library sits under $1,000/month.",
"Recommends employment - open-source time written into a job - or a commercial revenue model as the primary route to a salary-shaped number.",
"Positions sponsorship as a supplement rather than the primary instrument for this goal.",
"Lists the funding instruments beyond sponsorship: employment, individual crowdfunding, project-level corporate sponsorship, commercial revenue (support, hosting, premium features), and grants.",
"Does not present those instruments as an efficiency ranking against one another.",
"Checks whether the project has a research, infrastructure or security angle that would make a grant the dominant route.",
"Establishes whether dependent companies can actually be named before proposing any corporate tier.",
"Still proposes a minimum gratitude base layer or basic sponsorship setup rather than refusing to help at all.",
"Does not assert that the March deadline is reachable through sponsorship income alone.",
"Asks clarifying questions one at a time rather than delivering the whole interview as a block.",
"Warns against publishing a $7,200 funding goal, since a goal stuck at a low percentage for a year reads as a project nobody supports."
]
},
{
"id": 3,
"prompt": "Good news - a fintech called Northvale Systems emailed me. They use my TypeScript validation library across three of their services and their platform lead says they can sponsor at $400/month, but their finance team will only pay against a purchase order and a numbered invoice. We're on an organization account on GitHub Sponsors with about 30 individual sponsors at $5-$25 each. How do I set this up so the money actually lands?",
"expected_output": "A correction that $400/month cannot be invoiced through the platform, a fiscal-host or larger-ask route, the cancellation warning on switching billing modes, and the payable checklist.",
"files": [],
"expectations": [
"States the invoiced-sponsorship minimum of $5,000 per invoice on GitHub, so $400/month cannot be taken that way.",
"Recommends either sizing the ask up to clear that floor or routing the payment through a fiscal host that can issue invoices.",
"Warns that switching an organization to invoiced billing cancels its existing sponsorships, which then have to be re-established.",
"Notes that invoices are payable within 30 days, or that the invoiced sponsor agreement runs three years before renewal.",
"Names the organization-account fee structure: up to 6%, being 3% credit-card processing plus a 3% service fee, with the credit-card portion removed under invoiced billing.",
"Works through the payable checklist: a legal entity or explicit contractor arrangement, the payer's expected tax form, ability to issue a numbered invoice, bank details for transfer, and a named beneficiary.",
"Notes that fiscal hosts generally charge 3-10% of funds received, with Open Source Collective at 10%.",
"Suggests raising the ask above $400/month given dependence across three named services, rather than accepting the first number offered.",
"Warns that a fiscal host is itself a continuity risk and recommends writing the exit-and-transfer plan before it is needed.",
"Does not simply tell the maintainer to send Northvale the public sponsorship link.",
"Recommends logging Northvale's budget month and opening the renewal conversation a full cycle ahead.",
"Recommends selling Northvale named commitments with numbers rather than goodwill."
]
},
{
"id": 4,
"prompt": "Drafting the rewards for my ladder, I have 14 sponsors today. Planning on: $10 - name in BACKERS.md; $30 - monthly 30-minute 1:1 video call with me; $75 - priority support, I answer your issues within 24 hours; $200 - I'll build one custom integration a quarter for you; $400 - everything above plus your logo in the README. Sanity check these before I publish them?",
"expected_output": "Every reward run through a ten-times sponsor-count cost test, the second-job rewards removed from the ladder and rerouted into a priced retainer, and the safe rewards kept.",
"files": [],
"expectations": [
"Applies an explicit stress test asking what each reward costs per month at ten times the current sponsor count, roughly 140 sponsors.",
"Identifies the $30 monthly 1:1 call as a second-job reward and removes it from the ladder.",
"States the scale problem concretely - monthly calls at around 140 sponsors consume a working week or more per month.",
"Identifies the $75 24-hour response promise as an unbounded guaranteed-response-time commitment that does not belong in a self-serve tier.",
"Identifies the $200 quarterly bespoke integration as a second-job reward and removes it from the ladder.",
"Routes the named commitments - response times, security triage, upgrade support - into a separately priced corporate retainer with a written scope instead of a ladder perk.",
"States that these tiers are priced far below the obligation they create, or prices the equivalent retainer well above $400/month.",
"Keeps the near-zero rewards: name in BACKERS.md, README or docs logo, sponsor badge, thank-you post, release-notes mention.",
"Places the README logo reward at a company-sized price rather than at the top of an individual ladder.",
"Names the bounded-but-real middle bucket - private repository per tier, quarterly group office hours, early access to releases, sponsor-only newsletter - as the safe alternative to the removed rewards.",
"Notes that the ten-times multiplier is a stress test, not a measured growth rate or forecast.",
"States the reward efficiency order, leading with README or docs placement ahead of badges and thank-you posts, early access, private repositories or office hours, and monthly calls or priority support last."
]
},
{
"id": 5,
"prompt": "I'm about to ship v3 of harborctl. Thinking of doing this: sponsors at $20+ get the v3 binaries and the new docs site a month before everyone else, and I'd hold back the two CVE patches I've got queued for the same month so people have a real reason to sign up. I'd open v3 to everyone once I hit 250 sponsors - though honestly if it's going well at 250 I'd probably push that to 400. Worth doing?",
"expected_output": "Early access to v3 accepted, the security patches and documentation refused as gating material, and the published release threshold held fixed.",
"files": [],
"expectations": [
"Refuses to gate the two CVE patches behind a sponsor tier under any timing.",
"Refuses to gate the documentation needed to use the library.",
"Accepts early access to the v3 release itself as a legitimate sponsorware reward.",
"States the governing rule as gating convenience and never necessity: the core library, its security fixes and the documentation needed to use it stay open.",
"Rejects moving the release threshold from 250 sponsors to 400 once it has been published.",
"States that the release trigger must be published up front and honoured, because a threshold that keeps moving costs more goodwill than the revenue is worth.",
"Requires a genuinely useful free path, linked from the documentation, as the discovery route into the paid tier.",
"Recommends shipping gated content on a cadence, since a one-off gated release buys one month of sponsorship while a batch shipped with each release buys a subscription.",
"Tells the maintainer to budget production time for the gated content.",
"Tells the maintainer to check licence and employer constraints before gating anything derived from work someone else owns.",
"Notes that sponsorware is among the best-converting rewards on record and among the most expensive to keep delivering.",
"Applies the ten-times sponsor-count cost test to the ongoing gated-content commitment."
]
},
{
"id": 6,
"prompt": "Something is broken here and I can't see it. pgwatch-lite does 900k downloads a month on npm, three Series-B startups have it pinned in their public lockfiles, and two of their engineers file issues on us most months. Our sponsorship page is nice - I wrote it carefully, the tiers go up to $2,000. Total income: $35/month from four individuals. Everyone keeps telling me to rewrite the page copy. What am I actually missing?",
"expected_output": "A diagnosis that findability and the corporate lane are the failure, not the ladder copy, with a concrete audit of the funding metadata, links and health signals plus a named outreach target list.",
"files": [],
"expectations": [
"Directs the work to findability and the corporate lane first, rather than rewriting the sponsorship page copy.",
"States that when usage is proven and income is near zero, the ladder is rarely the problem.",
"Checks for .github/FUNDING.yml on the default branch.",
"Checks that the repository sponsor button is enabled in repository settings.",
"Checks the organization-level fallback at {owner}/.github for a stale or wrong FUNDING.yml.",
"Requires every funding link to be fetched and verified live, noting that a 404 removes the project from a funder's list entirely.",
"Tells the maintainer to fill the npm manifest funding field, not only the repository file.",
"Explains automatic dependency-share sponsorship, where a funder covers most of their fundable dependency tree at roughly $4-$10 each with no outreach required.",
"States that having no funding mechanism is a hard filter in funder programs, not merely a low score.",
"Recommends checking the OpenSSF Scorecard 'Maintained' score and fixing commit and release cadence before pitching if it reads dormant.",
"Puts a funding link within about two clicks of every surface users already touch: repository sponsor button, README, docs footer, release notes.",
"Turns the three Series-B startups into named outreach targets, recording the lockfile and issue evidence per company.",
"Does not treat sponsorship page views as the success metric, measuring conversion per surface instead."
]
},
{
"id": 7,
"prompt": "I live in Cordoba, Argentina. Solo maintainer, no company, no association, nothing - money would come to me personally. tessellate, my mesh-generation library, gets used by a few university labs in Europe and a couple of hardware startups. Someone told me I should apply to the Prototype Fund and the Chan Zuckerberg one. Help me put those applications together.",
"expected_output": "Both named programs rejected on published eligibility gates before any prose is drafted, with programs that can actually pay an individual with no entity named instead.",
"files": [],
"expectations": [
"Rejects the Prototype Fund on eligibility, naming its German tax residency requirement for the lead applicant.",
"Notes the Prototype Fund also requires a selected team to form a German GbR, and cannot pay companies, associations or universities.",
"Rejects Chan Zuckerberg Initiative EOSS on eligibility, stating its grants go to organizations only and are not permitted to individuals.",
"Notes that CZI EOSS requires demonstrated impact on biomedical research, which a mesh-generation library does not obviously meet.",
"Names at least one program that can pay an individual with no legal entity, such as NLnet or the Open Technology Fund.",
"Flags NLnet's 'European dimension' as a knock-out criterion that must be argued rather than assumed.",
"Runs the four qualifying gates before drafting: licence, who can be paid, geography, and maturity or scope.",
"States that a grant is a fixed-term contract with an eligibility gate in front and a reporting duty behind, not a larger sponsor.",
"Recommends running the grant lane alongside a sponsorship program rather than instead of it.",
"Notes that organization-only programs can sometimes be reached through a fiscal host or a named fiscal sponsor the program already accepts.",
"Does not begin drafting application prose before the eligibility gates are settled.",
"Raises the post-award reporting and compliance admin as a recurring cost to budget against the maintainer's available hours."
]
},
{
"id": 8,
"prompt": "NLnet's next deadline is coming up and I think I'm eligible - ferrolink is a low-power mesh networking stack, I'm in Lisbon, it's MIT licensed, and I'd apply as an individual. I want to ask for 48,000 euros to spend a year hardening it. I've drafted an opening that starts with how I got into this back in 2019 and why maintaining it alone has been so hard. Where do I take it from here?",
"expected_output": "The opening rewritten toward dependency and criticality, the budget expressed as hours at a named rate mapped to milestones, and the program's disclosure and payment mechanics surfaced.",
"files": [],
"expectations": [
"Rewrites the opening to lead with the dependency - prevalence, criticality, and who breaks if the project stops - rather than the maintainer's personal story.",
"States that a proposal is scored against published criteria by a reviewer reading dozens in one sitting, unlike a sponsor page written for a reader who already likes the project.",
"Prices the work in hours at a named rate rather than as a lump sum.",
"Maps those hours to milestones the maintainer would accept being paid against.",
"Requires an explicit answer to 'why not the existing thing', noting the open application forms ask it outright and a missing answer reads as no landscape research.",
"Names NLnet's published scoring weights - technical excellence and feasibility, relevance and impact, cost effectiveness - or warns that the rate will be questioned in a second stage.",
"Notes that 48,000 euros sits inside NLnet's 5,000-50,000 euro first-grant band, and that asking above 50,000 can condition payment on an independent security audit and the resolution of its findings.",
"Notes NLnet's generative-AI disclosure requirement, including prompts and logs, and that non-disclosure is likely to get the proposal rejected.",
"States that NLnet pays nothing upfront, with milestones fixed in a memorandum of understanding and payment requested on reaching one.",
"Requires every deliverable to ship under a recognised open licence.",
"Notes the 500,000 euro lifetime cap per recipient.",
"Lists the recurring application fields to draft once and reuse: budget and effort breakdown, comparison to existing and historical efforts, expected technical challenges, ecosystem and users, other funding past and present, and milestones with beneficiaries."
]
},
{
"id": 9,
"prompt": "Setting up a goal on GitHub Sponsors today. I'm at $210/month right now. I want to put '$5,000/month = I go full time' on the page as the goal - it's aspirational but it tells people the story. I already post monthly revenue updates on my blog anyway. Go?",
"expected_output": "The permanent-disclosure consequence of an amount goal stated, the sponsor-count alternative offered, and the first goal resized to something that closes this quarter.",
"files": [],
"expectations": [
"States that an amount goal publicly and permanently displays monthly sponsorship income, and treats that as a disclosure decision rather than a UI toggle.",
"Offers the sponsor-count goal as the alternative that keeps income private.",
"Rejects $5,000 as a first goal from a $210/month base and recommends a first goal that closes this quarter.",
"States that a completed goal is worth more than an ambitious one stuck at a low percentage for a year.",
"Notes that a goal cannot be edited below what has already been achieved.",
"Notes that a retired goal cannot be reactivated and must be replaced with a new one.",
"Notes that only one goal can run at a time.",
"Reconciles the goal type with the maintainer's existing public revenue posting rather than treating the two as unrelated decisions.",
"Converts the goal into units a reader recognises - a maintenance day a week, a named infrastructure or code-signing bill, a dated deliverable - rather than a bare number.",
"Does not simply configure the $5,000 amount goal as asked."
]
},
{
"id": 10,
"prompt": "Our top sponsor pays $2,400/month, about 45% of what we bring in. Their staff engineer opened an issue on Tuesday and pinged me today asking whether it can jump the queue, and separately their pull request from last month is still open because it doesn't handle the Windows path case. They've been polite about all of it but their renewal is in six weeks. What do I tell them?",
"expected_output": "A boundary held on merge decisions and outcomes, a sellable triage alternative offered, the boundary published, and the concentration exposure named.",
"files": [],
"expectations": [
"Distinguishes priority triage, which can be sold, from priority outcomes, which cannot.",
"States that contributions are judged on technical merit whether or not the author sponsors the project, so the pull request stays blocked on the Windows path case.",
"Refuses to treat sponsorship as buying roadmap control or merged pull requests.",
"Recommends publishing the boundary alongside the tiers rather than handling it privately per sponsor.",
"Keeps the sponsor list, the roadmap and the review queue as separate artefacts.",
"Flags the 45% concentration as approaching the point where one sponsor dominates the program's income.",
"Recommends growing the next tier down to reduce that concentration before the renewal exposure matters.",
"Recommends stating a conflict-of-interest rule naming which sponsors would be refused and who decides.",
"Offers a concrete acceptable alternative, such as faster acknowledgement or triage of filed issues, or a named support commitment sold as a separate retainer.",
"Does not propose a compromise in which the sponsor's pull request is merged or their issue's outcome is guaranteed."
]
},
{
"id": 11,
"prompt": "Here's my situation, tell me what program to build. quillstream is an audio DSP library. The docs site does 41k views a month, the README about 12k. I have a newsletter with 9,200 subscribers. No company, no association - money would hit my personal bank account and I am not willing to set up an entity or go through a fiscal host, it's too much paperwork. In a genuinely bad month I have maybe two hours for anything sponsor-facing. I don't need the money fast, but I want something that's still paying me in two years.",
"expected_output": "Two or three candidate programs sketched, the ruled-out shapes deleted with reasons named, and a visibility program on a gratitude base recommended and priced against the stated traffic.",
"files": [],
"expectations": [
"States the shape efficiency order out loud: visibility ahead of gratitude, ahead of retainer, ahead of access.",
"Emits separate orderings for value and effort rather than collapsing them into a single blended rank.",
"Deletes the retainer shape outright, naming the absence of an entity and the refusal to use a fiscal host as the reason.",
"Deletes the access shape outright, naming the two-hour bad-month effort ceiling as the reason, despite the 9,200-subscriber newsletter that would otherwise promote it.",
"Says explicitly that these shapes are deleted rather than demoted or parked at the bottom of the list.",
"Recommends the visibility program as the primary shape, priced against the 41k docs views and 12k README views.",
"Adds a gratitude base layer beneath the visibility program.",
"Names what the efficiency order starves - the retainer, the only shape that reaches salary-shaped income - and states the conditions that would promote it.",
"Sketches two or three candidate programs and says why the losing ones lose, rather than presenting a single option.",
"Seeks explicit agreement on the chosen shape before pricing any tier.",
"Ties the recommendation back to the stated compounding two-year mandate, which promotes the visibility placement.",
"States that visibility delivery costs roughly an hour per sponsor for a logo commit and a placement check, which fits inside the stated ceiling."
]
},
{
"id": 12,
"prompt": "Ten months into the sponsorship program for nimbus-orm. Numbers: $4,100/month recurring right now, $2,350 of that from one sponsor, a logistics company. $31,800 raised cumulatively since launch, which I'm honestly pretty proud of. 2.1k new GitHub stars this year. No company tiers occupied besides the logistics one. I shipped the funded audit tool six weeks late and the quarterly office hours slipped twice. Am I doing well?",
"expected_output": "A verdict against the program's pass threshold: concentration and delivery both failed, cumulative and star figures discarded, and the right metrics requested.",
"files": [],
"expectations": [
"Fails the program against the concentration condition, since $2,350 of $4,100 is roughly 57% and exceeds the 50% line.",
"States that the 50% line comes from freelance client-concentration practice and is a self-set threshold rather than an open-source funding norm.",
"Fails the program on delivery, since the funded commitment shipped late and the quarterly office hours slipped.",
"Discards the $31,800 cumulative total as the wrong measure and asks for recurring monthly amount with its trend over six months instead.",
"Discards the 2.1k new stars as a metric of the funding program.",
"Asks for the sponsor count split between individual and company sponsors.",
"Asks for monthly churn, the median tier, and the top sponsor's share of income.",
"Treats the concentration as a risk to fix before growing rather than as a sign of success.",
"Names the review cadence as 90 days and then quarterly.",
"Measures conversion from each surface carrying the funding link rather than page views.",
"Notes that only one occupied company tier means the corporate lane was never really opened."
]
},
{
"id": 13,
"prompt": "I run platform engineering at Calderwood Analytics, we have 240 engineers. We've budgeted $180k a year to put into the open-source projects we depend on and I need to decide which projects get it and how much each one should get. Can you work out the tiers we should buy and how we pick the projects?",
"expected_output": "Recognition that this is the funder side of the table, a handoff to the company-side sibling skill, and no maintainer-side program work performed.",
"files": [],
"expectations": [
"Identifies that the user is on the company side of the table, deciding which projects to fund, not the maintainer side being funded.",
"Routes the user to the company-side sibling skill samber/developer-relations-skills@oss-sponsors-brand-strategy.",
"Stops rather than continuing into the maintainer workflow.",
"Does not run the maintainer interview questions about project role, goal amount or delivery capacity.",
"Does not design a sponsorship tier ladder for the user to publish.",
"Does not produce the maintainer-side sponsorship program brief.",
"Does not ask the user to name three companies that depend on their project.",
"Does not advise the user on setting up GitHub Sponsors, FUNDING.yml or a fiscal host as a recipient of funds."
]
},
{
"id": 14,
"prompt": "I've got one target: Brightmoor Logistics. Their public repos show my library in two services, and one of their engineers has filed six issues this year. I want to send them something this week. Here's my draft - 'Subject: Sponsorship request. Hi, I maintain langfold, an open-source library used by thousands of developers. Maintaining it takes a lot of unpaid time and I'm asking companies that use it to support my work on GitHub Sponsors. Any amount helps! Here's the link.' Tighten it up for me?",
"expected_output": "The draft rejected rather than edited, replaced by an email naming the evidence of dependence, the risk, the named commitments and a price, sent to a person with a budget.",
"files": [],
"expectations": [
"Rejects the draft outright rather than editing it, identifying that it asks for charity, addresses nobody in particular, names no dependence, and offers nothing a budget owner can justify.",
"Names the specific evidence of dependence in the rewritten email: the two services visible in public repos and the engineer's six filed issues.",
"Addresses a named person with a budget and an exposure - platform lead, staff engineer, head of security - rather than a generic address.",
"Frames the ask against a budget line that already exists: supply-chain security, marketing reach, or engineering support.",
"Sells named commitments with numbers - a security-report acknowledgement window, a published release cadence, named major-version upgrade support - rather than goodwill.",
"States a price in the email rather than asking for 'any amount'.",
"Offers a route when the first budget line is wrong, such as asking whether security or platform engineering is the better door.",
"Confirms the payable prerequisites before sending: entity or contractor arrangement, tax form, numbered invoice, bank details.",
"Identifies that outreach only wins the judgement-based strategic sponsorship mechanism, and that dependency-share, employee-nominated funds and foundation or pledge membership are won differently.",
"Notes that Open Source Pledge members commit more than $2,000 per employed developer per year, so budget already exists looking for legible recipients.",
"Offers a one-page prospectus rather than a slide deck, including the section on what sponsorship does not buy.",
"Plans the renewal: logs the budget month and sends a short proof-of-value note each quarter."
]
}
],
"trigger_queries": [
{ "query": "how do I get sponsors for my open source project", "should_trigger": true },
{ "query": "set up GitHub Sponsors for my library", "should_trigger": true },
{ "query": "what tiers should I offer sponsors", "should_trigger": true },
{ "query": "nobody sponsors my project even though everyone uses it", "should_trigger": true },
{ "query": "write me a FUNDING.yml", "should_trigger": true },
{ "query": "should I do sponsorware for my next release", "should_trigger": true },
{ "query": "my top sponsor tier is $50, is that too low", "should_trigger": true },
{ "query": "how much should I charge a company for a README logo", "should_trigger": true },
{ "query": "I'm burning out maintaining this library for free", "should_trigger": true },
{ "query": "how do I get a company to pay me to maintain my library", "should_trigger": true },
{ "query": "is Open Collective or GitHub Sponsors better for us", "should_trigger": true },
{ "query": "what should my sponsorship page actually say", "should_trigger": true },
{ "query": "I want to go full time on my open source project", "should_trigger": true },
{ "query": "help me apply for an NLnet grant", "should_trigger": true },
{ "query": "which open source grants can I apply to with no company", "should_trigger": true },
{ "query": "a sponsor wants their issue prioritised, what do I say", "should_trigger": true },
{ "query": "should I publish my monthly sponsorship income as a goal", "should_trigger": true },
{ "query": "our sponsorship income has been flat for months, what's wrong", "should_trigger": true },
{ "query": "rewrite my sponsor tiers", "should_trigger": true },
{ "query": "can I raise the price of a GitHub Sponsors tier later", "should_trigger": true },
{ "query": "how do companies actually pay open source maintainers", "should_trigger": true },
{ "query": "write an email asking a company to sponsor my library", "should_trigger": true },
{ "query": "what rewards should I give sponsors", "should_trigger": true },
{ "query": "do I need a legal entity to accept sponsorship money", "should_trigger": true },
{ "query": "should we incorporate or use a fiscal host for project funds", "should_trigger": true },
{ "query": "how do I split sponsorship money between three maintainers", "should_trigger": true },
{ "query": "my project is unsustainable and I'm about to archive it", "should_trigger": true },
{ "query": "how do I make my repo show up in funders' dependency scans", "should_trigger": true },
{ "query": "what's a realistic monthly number from GitHub Sponsors", "should_trigger": true },
{ "query": "design a sponsorship program for my Rust crate", "should_trigger": true },
{ "query": "we get 2 million downloads a month and $12 in donations", "should_trigger": true },
{ "query": "should I put early access to releases behind a sponsor tier", "should_trigger": true },
{ "query": "how do I ask for money without sounding desperate", "should_trigger": true },
{ "query": "is it okay to sell priority support to sponsors", "should_trigger": true },
{ "query": "what do I put in a sponsorship prospectus", "should_trigger": true },
{ "query": "how do I find the companies that depend on my package", "should_trigger": true },
{ "query": "our Open Collective has $41 in it", "should_trigger": true },
{ "query": "how do I price a docs sidebar logo placement", "should_trigger": true },
{ "query": "should my funding goal be a number of sponsors or an amount", "should_trigger": true },
{ "query": "monthly calls for $25 sponsors, good idea?", "should_trigger": true },
{ "query": "my FUNDING.yml link is dead, does that actually matter", "should_trigger": true },
{ "query": "how do I get onto a company's FOSS fund ballot", "should_trigger": true },
{ "query": "what does an employee-nominated open source fund require", "should_trigger": true },
{ "query": "explain how invoiced sponsorships work on GitHub", "should_trigger": true },
{ "query": "a company wants to pay us by purchase order", "should_trigger": true },
{ "query": "our sponsor asked for exclusivity over the project", "should_trigger": true },
{ "query": "should I take money from this particular company", "should_trigger": true },
{ "query": "help me write a grant proposal for my library", "should_trigger": true },
{ "query": "Prototype Fund or Sovereign Tech Fund for my project?", "should_trigger": true },
{ "query": "how long does it take to actually get an open source grant", "should_trigger": true },
{ "query": "do I have to report back after getting a grant", "should_trigger": true },
{ "query": "what metrics tell me if my sponsorship program is working", "should_trigger": true },
{ "query": "one sponsor is most of our income, is that a problem", "should_trigger": true },
{ "query": "we raised $40k in total, are we doing well", "should_trigger": true },
{ "query": "I want a retainer deal with the companies using my library", "should_trigger": true },
{ "query": "how much can I charge for maintenance commitments", "should_trigger": true },
{ "query": "release to sponsors first then open source it later, does that work", "should_trigger": true },
{ "query": "can I put the docs behind a sponsor tier", "should_trigger": true },
{ "query": "what should I never sell to a sponsor", "should_trigger": true },
{ "query": "my project has no funding button anywhere", "should_trigger": true },
{ "query": "how do I make maintaining this thing pay", "should_trigger": true },
{ "query": "the money for this library has to come from somewhere", "should_trigger": true },
{ "query": "our maintainers are unpaid and it's starting to show", "should_trigger": true },
{ "query": "can I get paid for triaging issues rather than writing code", "should_trigger": true },
{ "query": "we want a corporate tier but don't know what to put in it", "should_trigger": true },
{ "query": "what's the maximum I can charge on GitHub Sponsors", "should_trigger": true },
{ "query": "our fiscal host is shutting down, what now", "should_trigger": true },
{ "query": "how do I keep sponsors from thinking they own the roadmap", "should_trigger": true },
{ "query": "draft a one page pitch for the companies using our SDK", "should_trigger": true },
{ "query": "should we add a Ko-fi button as well", "should_trigger": true },
{ "query": "how do I turn 500k weekly downloads into actual income", "should_trigger": true },
{ "query": "which surfaces should carry our funding link", "should_trigger": true },
{ "query": "write the tier descriptions for our sponsorship page", "should_trigger": true },
{ "query": "we launched sponsorship six months ago and nothing happened", "should_trigger": true },
{ "query": "is it worth chasing corporate sponsors at our size", "should_trigger": true },
{ "query": "which of our npm dependencies accept GitHub Sponsors?", "should_trigger": false },
{ "query": "scan our lockfile and tell us which maintainers we could fund", "should_trigger": false },
{ "query": "we're a company deciding how to allocate our open source budget across projects", "should_trigger": false },
{ "query": "how much should we sponsor each project we depend on", "should_trigger": false },
{ "query": "what does our company actually get out of sponsoring open source", "should_trigger": false },
{ "query": "should our company sponsor maintainers or just hire them", "should_trigger": false },
{ "query": "write our corporate open source sponsorship policy", "should_trigger": false },
{ "query": "how do we announce publicly that we sponsor these maintainers", "should_trigger": false },
{ "query": "find sponsors for our developer conference", "should_trigger": false },
{ "query": "what should a gold sponsor of our meetup get", "should_trigger": false },
{ "query": "price the booth packages for our hackathon", "should_trigger": false },
{ "query": "we want to sponsor a developer conference, which one", "should_trigger": false },
{ "query": "build a sponsorship prospectus for our DevOps event", "should_trigger": false },
{ "query": "how much does it cost to sponsor a booth at a big cloud conference", "should_trigger": false },
{ "query": "raise a seed round for our developer tools startup", "should_trigger": false },
{ "query": "write our pitch deck for VC investors", "should_trigger": false },
{ "query": "how do I fund my wallet with USDC", "should_trigger": false },
{ "query": "find a charity in Seoul I can donate to", "should_trigger": false },
{ "query": "write a grant application for our university research lab", "should_trigger": false },
{ "query": "how do I get brand deals for my YouTube channel", "should_trigger": false },
{ "query": "how much should I charge for a podcast ad read", "should_trigger": false },
{ "query": "set up a Patreon for my illustration work", "should_trigger": false },
{ "query": "launch a Kickstarter for our hardware device", "should_trigger": false },
{ "query": "how should we price our SaaS tiers", "should_trigger": false },
{ "query": "open core or source available, which model", "should_trigger": false },
{ "query": "should we charge for our CLI or keep it free", "should_trigger": false },
{ "query": "design the pricing page for our API product", "should_trigger": false },
{ "query": "what's the right free tier limit for our developer tool", "should_trigger": false },
{ "query": "usage based or seat based pricing for a devtool", "should_trigger": false },
{ "query": "how do we build a business around our open source project", "should_trigger": false },
{ "query": "should we relicense to BSL", "should_trigger": false },
{ "query": "MIT or Apache 2.0 for our new library", "should_trigger": false },
{ "query": "someone is selling our AGPL code, what are our options", "should_trigger": false },
{ "query": "write a CLA for our contributors", "should_trigger": false },
{ "query": "set up a technical steering committee", "should_trigger": false },
{ "query": "how do we add maintainers without losing control of the project", "should_trigger": false },
{ "query": "write our project's governance document", "should_trigger": false },
{ "query": "should we donate the project to a foundation", "should_trigger": false },
{ "query": "how do we join the CNCF", "should_trigger": false },
{ "query": "write our code of conduct enforcement process", "should_trigger": false },
{ "query": "plan the launch of our open source project on Hacker News", "should_trigger": false },
{ "query": "how do we get our library to 10k stars", "should_trigger": false },
{ "query": "where should we announce our v1", "should_trigger": false },
{ "query": "get our package trending on npm", "should_trigger": false },
{ "query": "rewrite our README so it converts", "should_trigger": false },
{ "query": "what should go above the fold in our README", "should_trigger": false },
{ "query": "add the right badges to our README", "should_trigger": false },
{ "query": "optimize my GitHub profile page", "should_trigger": false },
{ "query": "write my GitHub profile README", "should_trigger": false },
{ "query": "should I start posting weekly updates about building this", "should_trigger": false },
{ "query": "I want to share our revenue publicly every month", "should_trigger": false },
{ "query": "how transparent should our devlog be", "should_trigger": false },
{ "query": "triage the 400 open issues on our repo", "should_trigger": false },
{ "query": "write an issue template that filters out the noise", "should_trigger": false },
{ "query": "how do we onboard first time contributors", "should_trigger": false },
{ "query": "write our CONTRIBUTING.md", "should_trigger": false },
{ "query": "how do we keep our contributors from burning out", "should_trigger": false },
{ "query": "measure the health of our developer community", "should_trigger": false },
{ "query": "what KPIs should our devrel team report", "should_trigger": false },
{ "query": "how do we attribute signups to our developer content", "should_trigger": false },
{ "query": "how should we split our devrel budget across channels", "should_trigger": false },
{ "query": "justify our devrel headcount to the CFO", "should_trigger": false },
{ "query": "hire a developer advocate", "should_trigger": false },
{ "query": "how do I become a devrel engineer", "should_trigger": false },
{ "query": "write a CFP abstract for a Go conference", "should_trigger": false },
{ "query": "prepare me for a podcast interview about our tool", "should_trigger": false },
{ "query": "write a customer case study about a developer using our API", "should_trigger": false },
{ "query": "write the changelog for v4.2", "should_trigger": false },
{ "query": "write an upgrade guide for our breaking changes", "should_trigger": false },
{ "query": "identify and reward our top community champions", "should_trigger": false },
{ "query": "improve our employer brand so more engineers apply", "should_trigger": false },
{ "query": "should we push our wire format through the IETF", "should_trigger": false },
{ "query": "how do we get our spec adopted as an industry standard", "should_trigger": false },
{ "query": "compare our developer experience against our two competitors", "should_trigger": false },
{ "query": "map the journey from docs visit to first API call", "should_trigger": false }
]
}
references/corporate-sponsorship-path.md›
# The corporate sponsorship path
Everything in this file exists because individual sponsorship plateaus: a widely depended-on library's typical income through personal sponsorship sits under $1,000/month, "at least 12 times less than the alternative" of a senior engineering salary (Filippo Valsorda). Valsorda cites $355k in New York at the 90th percentile, $232k in London, $163k in Berlin.
The same argument's evidence for the status quo: `ua-parser-js`, at 6.5k stars, held $41.61 on Open Collective, and the Log4j2 maintainer had three GitHub sponsors. Company money is a different motion, not a bigger tier.
Scale check on the individual channel, from GitHub's own reporting: more than $100 million has flowed through GitHub Sponsors since 2019 to over 70,000 maintainers and organizations from more than 280,000 sponsors, and in 2022 nearly 40% of that funding came from organizations. A large channel with a small median.
## Contents
- Why companies pay
- Finding the companies that depend on you
- The two funder motions
- Outreach: weak and strong
- The one-page prospectus
- The payable checklist
- Renewal
## Why companies pay
Companies fund maintainers from budget lines that already exist, and the pitch has to name one:
- **Supply-chain security.** Companies pledging support for maintainers budget upwards of **$2,000 per employed developer per year**; the movement reports **$7.27M** raised in total, $3M+ in the trailing year, with members including Sentry, Sanity, Zerodha, Posit, AG Grid and Mux. One founder states the return directly: sponsorship pays back "in two major ways: brand marketing, and securing our supply chain."
- **Marketing reach.** Placement priced against real traffic is a media buy, and media budgets renew annually.
- **Engineering support.** Named commitments - security-report handling, review and release timelines, upgrade support - are bought as risk reduction, not charity.
What the money buys, in the words of a maintainer who invoices companies directly: "security practices, like two-factor authentication and mandatory code review; updates to keep up with the evolution of the ecosystem; reliable timelines for reviewing and merging or rejecting contributions; support and troubleshooting for filed issues and bug reports; quality standards; careful handling of security reports; adoption of standards; even a succession plan." The realistic price band he names for that package is **0.3x to 1x of a market engineering salary**.
## Finding the companies that depend on you
In rough order of signal strength:
1. **Dependency graphs and reverse-dependency listings** - who ships your package in production code.
2. **Public repositories and lockfiles** on the company's own organization.
3. **Issues and pull requests filed from company email domains or accounts** - they already have an engineer paying attention.
4. **Job posts naming the technology** - a company hiring for your library depends on it structurally.
5. **Conference talks and engineering blog posts** describing an architecture built on it.
Twenty well-qualified companies beats a mailing list. Record for each: the evidence of dependence, the likely budget line, and a named contact.
## The two funder motions
Sophisticated funders allocate in two ways at once, and the maintainer captures them differently:
- **Breadth.** Small automatic sponsorships across the whole dependency tree - one company covered "95% or greater coverage" of its fundable dependencies at $4-$10 each, noting "for many of our dependencies, we are likely their first and sole sponsor". Captured with **zero outreach**: a `FUNDING.yml`, package funding metadata, and a live funding link.
- **Depth.** Judgement-based amounts to projects the company depends on heavily - examples from the same $500,000 programme: $15,000 to the library underpinning one of its products, $10,000 and $6,000 to two language foundations, $1,750 to a framework. Captured by being **visibly load-bearing for that company's product**, which is what the outreach below argues.
Two further mechanisms sit alongside them, and neither is won by pitching a sponsorship page:
- **Employee-nominated funds.** A fixed monthly budget awarded to one project per cycle by internal nomination and vote (Indeed's is $10,000/month). Captured by the engineer inside the company who already uses the project - see [funder-scan-and-eligibility.md](./funder-scan-and-eligibility.md) for the four eligibility rules a candidate must satisfy.
- **Pledge and foundation membership.** Open Source Pledge members commit more than $2,000 per employed developer per year to maintainers and foundations; the movement reports $7.27M raised in total. Captured indirectly, by being a recipient of the foundation or platform that money flows through.
## Outreach: weak and strong
**Weak - do not send:**
> Subject: Sponsorship request
>
> Hi, I maintain libfoo, an open-source project used by thousands of developers. Maintaining it takes a lot of unpaid time and I'm asking companies that use it to support my work on GitHub Sponsors. Any amount helps! Here's the link.
It asks for charity, addresses nobody in particular, names no dependence, and offers nothing a budget owner can justify.
**Strong:**
> Subject: libfoo maintenance - support tier for <Company>
>
> Hi <Name>, I maintain libfoo. Your `api-gateway` and `billing` services depend on it (visible in your public repos), and three of your engineers have filed issues this year, so this is likely load-bearing for you.
>
> I currently maintain it in evenings. I'm setting up a small number of company support tiers so the projects that companies actually run in production get a defined level of service: security reports acknowledged within 48 hours, a published release cadence, and named support for major-version upgrades. $1,000/month, invoiced annually, logo in the README and docs.
>
> If maintenance risk on this dependency is worth removing, I can send a one-page summary and an invoice this week. If sponsorship is the wrong budget for it, is security or platform engineering the better door?
Why it works:
- Names the dependence with evidence.
- Names the risk.
- Names the service.
- Names the price.
- Offers a route when the first budget line is wrong.
## The one-page prospectus
One page, no slide deck:
1. **What the project is** and who depends on it - with two or three named or categorised adopters.
2. **Usage evidence** - downloads, dependent repositories, notable deployments.
3. **Who maintains it** and how much time it currently gets.
4. **What sponsorship funds** - bounded commitments with numbers, not "more development".
5. **Tiers and prices**, with what each placement is worth in traffic.
6. **How to pay** - entity, invoicing, tax form, currency, minimum.
7. **What sponsorship does not buy** - roadmap influence, merged pull requests, exclusivity.
Section 7 raises the price rather than lowering it: a maintainer who will not sell neutrality is a safer dependency.
## The payable checklist
Companies pay recipients that fit their existing process. Before the first outreach, be able to answer yes to all of these:
- A legal entity or an explicit personal-contractor arrangement, in a country the company can pay.
- The tax form the payer's jurisdiction expects.
- The ability to issue a numbered invoice with payment terms.
- Bank details for transfer, not only a card-based donation page.
- A named beneficiary and a stable contact address.
- A fiscal host, where the project is multi-maintainer or the money should not land on one person's tax return.
- Awareness of the platform floor: invoiced sponsorships through the main platform start at **$5,000 per invoice**, so anything smaller must route through a fiscal host.
The maintainers who get paid are not the most deserving; they are the ones a finance department can process without an exception.
## Renewal
Corporate budgets are annual, so the renewal is decided months before it lapses.
- Send a short proof-of-value note each quarter: what shipped, what was triaged, what the sponsorship covered.
- Log the customer's budget month and open the renewal conversation a full cycle ahead.
- Watch concentration: when one sponsor exceeds half the program's income, the project is a contractor with a single client. Grow the next tier down before the exposure matters.
references/funder-scan-and-eligibility.md›
# Funder scans, eligibility rules and where the money lands
What a corporate funder's tooling reads before a human ever sees the project, the published eligibility rules of employee-nominated funds, and the continuity risk attached to whichever entity receives the money. Figures are verified against the sources named inline.
## Contents
- What the scanners read
- Payability signals
- Employee-nominated fund eligibility
- Disqualifiers a funder applies
- Where the money lands, and how it can disappear
- Self-audit pass
## What the scanners read
Funder-side tooling resolves a dependency tree and enriches every node with health data, then a human ranks the shortlist. Three signals do most of the ranking:
- **Dependency relation.** Resolution APIs (deps.dev and equivalents) mark each node `SELF`, `DIRECT` or `INDIRECT`, across npm, PyPI, Cargo, Go, RubyGems, Maven and NuGet. Direct dependencies get read; transitive ones mostly get the automatic $4-$10 breadth sponsorship.
- **OSSF Scorecard, _Maintained_ check (0-10).** The usable liveness proxy: 7-10 reads as actively maintained, 4-6 partial, 0-3 likely dormant. A project that has gone quiet for a quarter looks dormant to a scan even when the maintainer is simply busy - a small, regular commit and release cadence is what keeps the score honest.
- **OpenSSF Criticality Score (0-1).** Weighted from project age, update recency, contributor count, organisation diversity, commit frequency, release cadence, issue-closure and comment activity, and dependents count. Published as public datasets and explicitly built to direct support and security resources.
None of these can be gamed usefully, and trying is a bad trade. Treat them as a mirror: a low _Maintained_ score before an outreach campaign predicts the objection the buyer will raise.
## Payability signals
- `.github/FUNDING.yml` on the default branch, with an **org-level fallback**: `{owner}/.github` → `FUNDING.yml` applies to every repository of that owner that lacks its own. A stale org-level file silently overrides nothing but covers everything else - check both.
- Registry metadata: npm's `funding` field (string, object with `url`, or array). Funder tooling reads manifests as well as the repository.
- Every link gets **fetched and verified live** by the funder before it enters their list. A 404 removes the project from the list entirely.
- **No funding mechanism, no target.** This is a hard filter in every documented program, not a scoring input.
## Employee-nominated fund eligibility
The FOSS-fund pattern (Indeed's FOSS Contributor Fund, also run at Microsoft, Spotify and Sourcegraph) allocates a fixed budget to one project per cycle - **$10,000/month** at Indeed. Only employees who contributed to open source during that cycle may nominate or vote.
Indeed's published eligibility rules, all four required:
1. The project is in use by the company.
2. It carries an OSI-approved license.
3. It has a mechanism to receive funds.
4. It is not employee-owned (their conflict-of-interest rule).
Two consequences for a maintainer:
- The nominator is an employee who already uses the project, so the engineer filing your issues is the person who puts you on the ballot - worth knowing when you decide how to treat that engineer's bug report.
- The vote drifts toward famous projects, which programs try to correct by surfacing underserved ones; a small library wins on a nominator's story, not on its star count.
A project that can only accept a support contract or a subscription is excluded from these funds outright - a fixed one-time budget needs a recipient it can pay once.
## Disqualifiers a funder applies
- Corporate-maintained projects: the money is a rounding error to the vendor and buys nothing.
- Support-contract-only or subscription-only recipients, when the budget is one-time.
- Employee-owned projects, wherever a conflict-of-interest rule exists.
- License or governance mismatch with the funder's own policy.
- Recent maintainer conduct incidents or a dependency-hijack history - the sponsor's brand attaches to the sponsee.
## Where the money lands, and how it can disappear
| Route | Fit | Live risk |
| -------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Personal account on the platform | solo maintainer, no entity, no fee on personal accounts | tax and legal liability sit on one individual; multi-maintainer splits get awkward |
| Own legal entity | invoicing companies directly, several maintainers | setup and accounting cost; charity status is not a given (see below) |
| Fiscal host | receiving money without incorporating; typically 3-10% of funds, 10% at Open Source Collective | the host itself can fail |
Two documented cautions:
- **A fiscal host can dissolve and take your money's home with it.** The Open Collective Foundation (a US 501(c)(3) host charging 5%) announced dissolution on 28 February 2024, effective 31 December 2024, giving its 600+ collectives until 30 September 2024 to spend down or transfer funds.
- **The separately named Open Source Collective** - a distinct 501(c)(6) hosting only OSS projects - was unaffected. Confirm which entity actually holds your funds, and write the exit-and-transfer plan before you need it.
- **Charity status is not a formality.** Yorba applied for US 501(c)(3) status in December 2009 and was denied on 22 May 2014 - roughly four and a half years - the IRS reasoning that its open-source licenses authorise use "for any purpose, including nonexempt purposes such as commercial". Risk-averse projects route through an already-recognised fiscal host instead of filing from scratch.
When money is shared between maintainers, separate the roles the money pays for. The Django Software Foundation funds a Fellowship for triage and administrative work rather than feature development, which keeps "paid to keep the lights on" apart from "paid to decide direction".
That split is the documented friction point when some maintainers are paid from project funds and others are not. A public ledger (Open Collective and similar) adds real-time accountability and exposes each maintainer's compensation to the community; that trade is a decision, not a default.
## Self-audit pass
Baseline checklist - this skill's synthesis of the signals above, not a published rubric. Run it before any corporate outreach and once a quarter afterwards:
1. Funding link present in `.github/FUNDING.yml`, verified live today, and consistent with the org-level fallback.
2. Package-manifest funding metadata filled in every ecosystem the project publishes to.
3. Scorecard _Maintained_ score checked; if it reads dormant, fix the cadence before pitching.
4. A named legal route to receive money - entity, contractor arrangement or fiscal host - with the tax form ready.
5. An invoice can be issued this week, with bank details, for an amount above the platform's invoiced floor.
6. License OSI-approved and stated in the repository, so an employee nomination cannot fail on rule 2.
7. If several maintainers share the money: spending authority written down, and roles the money pays for named.
references/grant-programs-and-reporting.md›
# Grant programs, gates and reporting
Confirm a program's open status, its figures and its residency rules on its own page before writing anything. Calls open and close on their own schedules.
## Gates, by program
Each entry reads: who it can pay / the gate that rejects most applicants / published size.
- **NLnet Foundation, Open Internet Stack funds (formerly branded NGI Zero, whose Entrust/Core/Commons calls are now permanently closed).** "individuals, research organisations, non-profits, public institutions, companies of any size and type", no entity needed / a "European dimension" is a knock-out criterion, and code, hardware and documentation ship under recognised open licences / €5,000-€50,000 for a first grant, €500,000 lifetime cap per recipient, spread across three thematically named programmes (Restack, CodeSupply, ELFA), each with its own rolling deadline on the 3rd of every odd month.
- **Sovereign Tech Fund (Germany).** Maintainers, companies and communities anywhere / existing, widely deployed base technology only: "We do not finance the development of prototypes" / €50,000 minimum project cost, no published maximum, though independent reporting notes individual awards reaching roughly €1M in practice.
- **Prototype Fund (Germany).** An individual or a team of up to four that must form a GbR: "Payments to companies, associations, universities... are not possible" / German tax residency for the lead, plus a fixed annual window / up to €95,000 per team for the six-month regular phase (€47,500 solo), with an optional four-month second stage adding up to €63,333 team / €31,667 solo.
- **Open Technology Fund.** "Individuals or organizations (for-profit or nonprofit) of all ages", contracted directly / OFAC-sanctioned countries excluded, and the project must serve internet freedom / $10,000-$900,000 over up to 24 months on the Internet Freedom Fund.
- **Chan Zuckerberg Initiative EOSS.** Organisations only: "Grants are not permitted to individuals, only to organizations" / demonstrated impact on biomedical research / $50,000-$200,000 a year for two years, indirect costs capped at 15%.
- **Alfred P. Sloan Foundation, Open Source in Science.** Not individuals, not generally for-profits / funds "tooling, institutions, economic models, and incentives" around research software rather than individual projects / unpublished, and no unsolicited full proposal is reviewed.
- **GitHub Secure Open Source Fund.** A maintainer in a region GitHub Sponsors supports / fixed sessions, prioritising maintainers deep in the dependency tree / $10,000, staged across the sprint and two check-ins.
- **FLOSS/fund.** Individuals and organisations globally / a published `funding.json` manifest is a submission prerequisite, and barely used projects are not considered / $10,000 minimum, $100,000 a year maximum.
## Getting paid with no legal entity
The entity question settles eligibility before proposal quality does.
- **No entity needed.** NLnet pays each person on a grant directly and accepts a pseudonymous application until award. The Open Technology Fund contracts with the applicant.
- **Organisation-only programs.** Route through a fiscal host, or name a fiscal sponsor the program already accepts. CZI's EOSS names NumFOCUS and Code for Science & Society, requires one secured by the full-proposal deadline, and warns that fiscally sponsored applications may be eligible for only a subset of its co-funders.
- **Incorporating** is the slowest route, and only the Prototype Fund forces it, requiring a selected team to found a German GbR.
## What the application asks for
Recurring fields across the open forms. Draft each once, reuse across programs:
- Summary of the project and the expected result.
- Budget as a task and effort breakdown, the rate applied, and expenses. Expect the rate to be questioned.
- Comparison to existing and historical efforts, what differs here, and whether contributing to one instead was considered.
- Expected technical challenges, and the applicant background and prior contributions that de-risk them.
- Ecosystem: dependencies, main users, how you will engage them.
- Other funding, past and present. Some programs refuse work another public body already funds.
- Milestones for the funding period, and who benefits, how many.
- Generative-AI disclosure where asked. NLnet wants the prompts and logs, and warns non-disclosure is likely to get the proposal rejected.
Two-stage programs ask far less up front. Sloan takes a two-page letter of inquiry by email and can take eight weeks to reply. CZI's EOSS letter of intent carried a summary, the value to the field, a landscape analysis and the repository list; budget, personnel, milestones, evaluation indicators, institutional sign-off and a diversity statement were asked of invited applicants only.
## Criteria worth writing to
- NLnet: technical excellence and feasibility 30%, relevance, impact and strategic potential 40%, cost effectiveness 30%, then a second stage of clarifying questions on rate justification and sustainability.
- Sovereign Tech Fund: prevalence, relevance to societal sectors, vulnerability (whether the maintenance is structurally underfunded), public interest, feasibility, and demonstrated expertise or maintainer endorsement.
- Prototype Fund: fit, degree of innovation, feasibility within six months, social benefit, chances against existing products, and absence of double funding.
## After the award
- **NLnet.** Nothing upfront: milestones fixed in a memorandum of understanding, payment requested on reaching one. Every deliverable ships under an open licence, and a grant over €50,000 may have payment conditioned on an independent security audit and the resolution of its findings.
- **Sovereign Tech Fund.** Invoices, approved then paid within about 30 days. Progress reports are tied to invoicing, in a format agreed with the program manager and as light as an email linking pull requests, plus a final write-up of impact, challenges and next steps.
- **Prototype Fund.** Instalments for work performed, released at the start of each quarter, retroactively. Owes attendance at a Berlin kickoff and Demo Day, a short plain-language report the funder publishes, and a sustainability follow-up about a year later.
- **CZI EOSS.** Paid to the institution or fiscal sponsor, never to an individual. Owes annual reports that may be made public, alongside uptake indicators the funder pulls from repositories, issue trackers, package registries and community forums.
- **Sloan.** Paid to an institution. Owes interim reports of two to four pages and a final of at most ten, under set headings, plus financial reports of amount received, expended and unexpended, with any balance over $500 returned.
- **GitHub Secure Open Source Fund.** Owes a three-week security sprint at five to ten hours a week, milestones agreed with a program manager, and 6- and 12-month check-ins that release the remaining money.
- **FLOSS/fund.** Owes public acknowledgement linking the fund.
## Cross these off before spending an afternoon on them
- Mozilla Open Source Support: "on indefinite hiatus and is not currently accepting applications", with the Mozilla Technology Fund named as the alternative.
- Google Season of Docs: concluded after six years.
- Sloan's Better Software for Science: completed, succeeded by the narrower Open Source in Science.
references/platform-mechanics.md›
# Sponsorship platform mechanics
Fees, minimums and limits change. If you can browse the web, confirm any number before the user commits to it.
## Contents
- GitHub Sponsors: tiers
- GitHub Sponsors: goals
- GitHub Sponsors: fees, eligibility, accounts
- Invoiced sponsorships (corporate procurement)
- FUNDING.yml
- Fiscal hosting and Open Collective
- Dependency-share and obligation platforms
- Choosing a platform
## GitHub Sponsors: tiers
- Up to **10 published monthly tiers** and **10 published one-time tiers**. Publishing all twenty is possible and always a mistake - three to five live tiers is what people read.
- Maximum tier price **US$12,000/month**. Custom amounts may carry a recommended or minimum amount; the minimum applies to recurring and one-time alike.
- **A published tier's price cannot be edited.** Repricing means retiring the tier and publishing a replacement; existing sponsors remain on the retired tier until they change or cancel. Design the ladder for two years out.
- Each tier carries a reward description plus an optional welcome message explaining how to claim the reward - the welcome message is where delivery instructions belong, not the tier blurb.
- A tier can grant its sponsors access to a **private repository** (organization-owned, admin access required; only personal accounts can be invited). This is the native mechanism for sponsor-only content - anything more elaborate means building an app that checks sponsorship status through the API.
## GitHub Sponsors: goals
- Two goal types: a **number of monthly sponsors**, or a **monthly amount**. One goal at a time.
- An amount goal **publicly displays monthly sponsorship income**. Treat it as a permanent disclosure decision, not a UI toggle.
- A goal cannot be edited below what has already been achieved, and a retired goal cannot be reactivated - only replaced with a new one.
## GitHub Sponsors: fees, eligibility, accounts
- **Personal accounts: no fee** - 100% of the sponsorship reaches the developer.
- **Organization accounts: up to 6%** - 3% credit-card processing plus a 3% service fee. Invoiced billing removes the credit-card portion.
- Eligibility explicitly covers non-code work: bug reports, issue triage, code, documentation, leadership, business development, project management, mentorship and design. A documentation maintainer or triager qualifies.
- Region-gated, with a waitlist for unsupported regions. Confirm the maintainer's country is supported before building the program around this platform.
## Invoiced sponsorships (corporate procurement)
- **Minimum $5,000 per invoice**, payable within 30 days. Credit does not expire and is spent down over time.
- The 3% service fee applies; the credit-card fee does not.
- Switching an organization to invoiced billing **cancels its existing sponsorships**, which must then be re-established - expect a gap and warn the sponsor.
- The invoiced sponsor agreement runs **three years** before renewal.
Consequence for program design: a company that can only pay against a purchase order cannot send $50/month. Either size the ask to clear $5,000, or receive it through a fiscal host that issues invoices.
## FUNDING.yml
Location: `.github/FUNDING.yml` on the default branch. The sponsor button must also be enabled in repository settings (Settings → General → Features → Sponsorships).
```yaml
github: [maintainer-one, maintainer-two] # one org plus up to 4 developer usernames
open_collective: project-name
ko_fi: username
liberapay: username
patreon: username
polar: username
buy_me_a_coffee: username
thanks_dev: u/gh/username
tidelift: npm/package-name # platform-name/package-name
issuehunt: username
community_bridge: project-name # LFX Mentorship
custom: ["https://example.com/sponsor"] # up to 4 URLs
```
- One username per external platform. Quote any URL containing a colon.
- Where the package ecosystem supports funding metadata (for example the npm manifest's `funding` field), fill it too - funder tooling reads manifests as well as this file.
## Fiscal hosting and Open Collective
- A collective cannot hold money itself: a **fiscal host** holds the funds and pays approved expenses, letting a project transact without incorporating.
- Open Source Collective charges **10%** of funds received; hosts generally range **3-10%**.
- Money leaves as **expenses approved by core contributors**, recorded on a public ledger. Full transparency is a trust asset and a privacy constraint - every payment to the maintainer is visible.
- The alternative, receiving money personally, puts tax and legal liability on one individual and makes multi-maintainer splits awkward.
## Dependency-share and obligation platforms
- **thanks.dev** distributes a funder's budget across their dependency graph, direct and transitive, three levels deep, breadth-first; funders can reweight by language or GitHub org. Maintainers get paid without pitching anyone - the requirement is being findable and payable. The vendor's own FAQ and account/settings pages are JS-rendered and login-gated, so its mechanics are corroborated via search instead (Jamie Tanna's product-requirements analysis, a Hacker News thread where co-founder Armin Nehzat describes a 5% minimum tip that a funder can raise up to 100%, and Canonical's own account of an actual invoice quoting the same 5% commission). A single third-party comparison site claims a 0% platform fee with only Stripe processing costs passed through, but that claim traces to no statement from thanks.dev itself. Confirm the fee directly on the funder's own thanks.dev account or settings page - the live setting, not the marketing site - before quoting one.
- **Tidelift** pays recurring amounts for _obligations_ (security response, maintenance, metadata quality) rather than goodwill. Closer to a contract than a donation, and it survives the sponsor's enthusiasm fading.
- **Polar, Ko-fi, Liberapay, Buy Me a Coffee, Patreon, IssueHunt** cover one-off, content-driven or bounty-driven funding. Patreon is the historical route for content rewards; Ko-fi and Buy Me a Coffee suit low-friction one-time thanks.
## Choosing a platform
| Situation | Use |
| ------------------------------------------------------ | --------------------------------------------------------------------- |
| Solo maintainer, personal income, no entity | GitHub Sponsors personal account (no fee) |
| Multi-maintainer project, shared budget, public ledger | Fiscal host (Open Collective or equivalent) |
| Company sponsor paying by purchase order | Invoiced sponsorship (≥$5,000) or an invoice from the fiscal host |
| Small library, no audience to pitch | FUNDING.yml plus package metadata; harvest dependency-share platforms |
| Selling named commitments, not goodwill | Obligation platform, or a direct retainer contract |
Two platforms is the practical maximum: one for individuals, one that can issue invoices. More than that splits reporting and confuses the ask.
references/tier-ladder-examples.md›
# Tier ladders, rewards and sponsorware
Real published ladders, what each one is actually selling, a weak ladder with its diagnosis, the sponsorware rules, and a filled brief.
## Contents
- Ladder 1: project at ecosystem scale (Vue.js)
- Ladder 2: individual maintainer selling placement (Sindre Sorhus)
- Ladder 3: individual maintainer selling content (Caleb Porzio)
- Weak ladder and diagnosis
- Reward catalogue by delivery cost
- Sponsorware rules
- Filled ladder section
## Ladder 1: project at ecosystem scale (Vue.js)
| Tier | Price/month | Reward |
| ---------------------- | -------------------- | ---------------------------------------------------------------------------------------- |
| Global Special Sponsor | custom, limited to 1 | above-the-fold logo on the homepage, plus a shoutout from an account with 320k followers |
| Platinum | $2,000 | prominent logo on the homepage, in the docs sidebar and in the core READMEs |
| Gold | $500 | large logo on the homepage and in the core READMEs |
| Silver | $250 | medium logo in `BACKERS.md` |
| Bronze | $100 | small logo in `BACKERS.md` |
| Generous Backer | $50 | name listed above other individual backers |
| Individual Backer | $5 | name listed |
What it sells: **attention it demonstrably owns**. Every tier is a placement, ordered by how many people see it. Scarcity is used once, at the top.
Individuals are served by two cheap tiers at the bottom and never mixed with the company ladder.
Do not copy this shape onto a project with no homepage traffic - the ladder works because the placements are worth the money.
## Ladder 2: individual maintainer selling placement (Sindre Sorhus)
| Tier | Price/month | Reward |
| -------- | ----------- | ------------------------------------------------------------------------------------------------------------- |
| $5 / $10 | | sponsor badge on profile |
| $50 | | name in the "Top Supporter" section of a thanks page |
| $100 | | company logo on one chosen repository, plus the thanks page |
| $200 | | logo on two chosen repositories |
| $800 | | logo on Awesome Node.js (20k views/month) and Awesome Electron (6k views/month), plus two chosen repositories |
| $1,000 | | logo on the main Awesome list (60k views/month), plus the above |
What it sells: **an ad rate card with published traffic numbers**. Naming the monthly views is what turns a donation request into something a marketing budget can approve. Logo placements exclude text and UTM parameters - a boundary worth copying, since it keeps the repository from becoming an ad unit.
## Ladder 3: individual maintainer selling content (Caleb Porzio)
Two tiers only: **$7** with no perks ("just say thanks"), and **$14/month** unlocking private screencasts. He tested $9 before settling on $14. Result at the time of writing: 535+ sponsors, $112,680/yr, having gone from roughly $40k to over $100k in about three months once the screencast tier launched.
What it sells: **an ongoing content subscription**, renewed with each release. Three of his conclusions transfer directly:
- "You can build the greatest tool on the internet, but it means nothing if no one's paying attention to you." The audience precedes the offer.
- "If people have the option of paying $1-5/mo. instead of >$14, they will pay the lesser amount." Never place a partial-perk tier just below the converting tier.
- Name tiers for the buyer - "The Agency" implies business use; "Platinum" implies nothing.
## Weak ladder and diagnosis
```
$1 - Thank you!
$5 - Thank you + your name in the README
$10 - Your name in the README, bigger
$25 - Name in README + I'll answer your questions faster
$50 - All of the above + monthly 1:1 call + logo somewhere
```
Everything wrong with it, in order of damage:
1. **No company tier.** The top price is $50; the companies depending on this project cannot buy anything, and $50 clears no procurement process.
2. **A 1:1 call at $50.** At 40 sponsors that is a working week per month, sold at a rate no consultant would accept. It is the first thing to break, in public.
3. **"Faster answers" sold at $25.** Priority _outcomes_ cannot be delivered honestly and poison the review queue for everyone else.
4. **Four tiers selling the same reward at different sizes.** Nothing distinguishes $5 from $10 except font size, so everyone picks $5.
5. **"Logo somewhere."** A benefit an approver cannot evaluate is a benefit nobody buys.
6. **Prices that cannot be raised.** On GitHub Sponsors these five are permanent until retired and replaced.
Rewritten:
- $5: name in BACKERS.md.
- $25: name + thanks-page listing.
- $250: logo in the README (traffic: N/month).
- $1,000: logo in README and docs, quarterly office hours.
- $4,000: the above plus 48-hour security triage and named upgrade support.
## Reward catalogue by delivery cost
| Cost at 10x sponsors | Rewards |
| -------------------- | ------------------------------------------------------------------------------------------------------------ |
| Near zero | name in `BACKERS.md`, README or docs logo, sponsor badge, thank-you post, release-notes mention |
| Bounded | private repository per tier, quarterly group office hours, early access to releases, sponsor-only newsletter |
| A second job | monthly 1:1 calls, per-sponsor content, bespoke integrations, guaranteed response times without a contract |
| Never sell | roadmap control, merged pull requests, priority outcomes, exclusivity over the project's direction |
Apply the test to every reward before it is published: _what does this cost every month at ten times today's sponsor count?_ Anything in row three either becomes a priced retainer with a written scope, or it does not ship.
## Sponsorware rules
Sponsorware: release new work **to sponsors first**, then open-source it at a published threshold (a sponsor count, an amount, or a date). Documented to have added $11k/yr within days for one maintainer, and repeated successfully by others in the same ecosystem.
- **Publish the release trigger up front and honour it.** A threshold that keeps moving costs more goodwill than the revenue is worth.
- **Gate convenience, never necessity.** Tutorials, templates, early access and tooling are fair game. The core library, its security fixes, and the documentation needed to use it are not.
- **Keep a genuinely useful free path**, linked from the docs - it is the discovery route into the paid tier.
- **Ship on a cadence.** A one-off gated release buys one month of sponsorship; a batch shipped with each release buys a subscription.
- **Budget production time**, and check licence and employer constraints before gating anything derived from work someone else owns.
## Filled ladder section
```markdown
## Ladder - libfoo (Python HTTP client, 4.2k stars, docs ~18k views/month)
| Tier | Price | Reward | Delivery cost/month at 10x |
| ----------------------------------------------------------------------------------------------- | ------ | -------------------------------------------------------------- | --------------------------------- |
| Backer | $5 | name in BACKERS.md | ~0 (scripted) |
| Supporter | $25 | name in BACKERS.md + thanks page | ~0 |
| Team | $250 | small logo in README + docs footer | 10 min/quarter |
| Business | $1,000 | large logo README + docs sidebar, quarterly group office hours | 1 h/quarter |
| Infrastructure | $4,000 | above + 48h security triage + named upgrade support | ~4 h/month, capped, written scope |
| Not for sale: roadmap priority, merged PRs, exclusivity. |
| Converting tier: Team. Gratitude tiers sit below it; no partial-perk tier between $25 and $250. |
```
SKILL.md›
---
name: oss-sponsors-fundraising
description: Designs a maintainer-side open-source sponsorship program - the tier ladder and its pricing for individual and corporate sponsors, rewards that stay deliverable at ten times the sponsor count, funding-goal and sustainability framing, and the invoice-and-entity path a company needs before it can pay. Use whenever a maintainer asks how to get sponsors or funding for a project, sets up or fixes GitHub Sponsors, Open Collective or FUNDING.yml, writes sponsor tiers, rewards or a sponsorship page, wonders why nobody sponsors a widely used project, considers sponsorware, or wants a company to fund maintenance work - even if they only say the project is unsustainable. Not the company side - use samber/developer-relations-skills@oss-sponsors-brand-strategy.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# 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](./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 prices and exact rewards, are in [references/tier-ladder-examples.md](./references/tier-ladder-examples.md) - including a weak ladder and why it fails. Platform limits, fees, payout and FUNDING.yml mechanics are in [references/platform-mechanics.md](./references/platform-mechanics.md); read it before naming a price or a platform.
## Step 4 - Size every reward against delivery, not appeal
For each reward, ask: what does this cost every month at ten times the current sponsor count? The ten-times multiplier is a **baseline** stress test, not a measured growth rate - it exists because the rewards that convert are exactly the ones that scale into a second job.
Rewards rank the same way shapes do, by what a sponsor buys against what it costs to keep delivering:
- efficiency: `README or docs placement > sponsor badge and thank-you post > early access to releases > private repository or quarterly office hours > monthly calls, priority support, bespoke work`
- value (what makes a company sign and renew): `monthly calls and priority support > private repository or office hours > early access > placement > badge and thank-you post` - for an individual sponsor that line reverses below early access, since the badge and the thank-you are the entire purchase
- effort: the three buckets below, in magnitudes.
- **Near-zero and safe:** name or logo in a `BACKERS.md`, README or docs placement, a thank-you post, a sponsor badge.
- **Bounded but real:** a private repository per tier, quarterly office hours, early access to releases.
- **A second job:** monthly calls, priority support promises, per-sponsor content, bespoke integrations.
What this order starves: the named commitments in that last bucket, which are the only rewards a company will pay retainer money for. Do not promote them into a tier perk - move them out of the ladder entirely and sell them through step 7, where the price matches the obligation.
Cut any reward that fails the ten-times test. Sponsor-only content and sponsorware, release to sponsors first, open-source at a published threshold, are the best-converting rewards on record and the most expensive to keep shipping. The mechanics, the release-trigger rule, and the things that must never be gated (security fixes, the core library, the documentation needed to use it) are in [references/tier-ladder-examples.md](./references/tier-ladder-examples.md).
## Step 5 - Write the ask as a bounded commitment
"Support my work" is not an ask. Every funder, from a $5 sponsor to a grant committee, answers the same five questions (opensource.guide's list):
- Why the project matters.
- What traction proves it.
- Why fund this over the alternative.
- What the money buys.
- How it can legally be disbursed.
Convert the goal into units a reader recognises - one maintenance day a week, the CI and code-signing bill, a named deliverable with a date. Set the first funding goal where it closes this quarter: a completed goal is worth more than an ambitious one stuck at 4% for a year.
Choose the goal type deliberately:
- A sponsor-count goal keeps income private.
- An amount goal publishes monthly revenue permanently and cannot be walked back.
If the user has a build-in-public practice, keep the two consistent.
Write the page in the maintainer's own voice, then run it through your preferred humanizer skill - sponsors buy the maintainer's credibility, and campaign copy spends it.
## Step 6 - Make the ask unavoidable, and the project machine-findable
Sponsorship money arrives through three paths, each needing its own configuration and each worth a different amount for what it costs:
- efficiency: `FUNDING.yml and manifest funding metadata > funding links on the surfaces users already touch > health signals that survive a funder's shortlist`
- value (money the path can route to the project): `health signals > funding links > FUNDING.yml`
- effort: `health signals > funding links > FUNDING.yml` - a Scorecard-driven cleanup is a quarter of work, the links are an hour, the file is near-zero
Do the first two now, in that order. What this order starves is the health-signal work, which is what a corporate fund or foundation program actually reads before allocating; promote it when such a program is the named target, and treat the rest of this section as its prerequisite.
- **The ask people read.** A funding link within two clicks of every surface a user already touches: repository sponsor button, README, docs footer, release notes, CLI or error output where appropriate. A page nobody reaches converts nobody.
- **The graph funders scan.** Sophisticated funders allocate across their dependency tree automatically - Sentry's $500,000 programme reached "95% or greater coverage" of its fundable dependencies at $4-$10 each, and was "likely their first and sole sponsor" for many of them. Being present in that scan costs one file: `.github/FUNDING.yml`, plus package-manifest funding metadata where the ecosystem supports it.
- **The shortlist a program builds.** Corporate funds rank candidates on machine-readable health data before any human looks - OpenSSF Scorecard and Criticality Score, dependent counts, contributor diversity. A missing or dead funding link is a hard filter at that stage, not a low score: an unfundable project is dropped whatever its criticality.
Verify every funding link resolves, and check the org-level fallback (`{owner}/.github`) is not pointing somewhere stale. Dead sponsorship links are common and silently cost the whole channel.
The signals those scanners read, the eligibility rules of employee-nominated funds, and a self-audit pass over them are in [references/funder-scan-and-eligibility.md](./references/funder-scan-and-eligibility.md). FUNDING.yml keys and syntax are in [references/platform-mechanics.md](./references/platform-mechanics.md).
## Step 7 - Open the corporate lane
Individual tiers will not reach a salary-shaped number; the companies that depend on the project will. This lane is a different motion, not a bigger tier.
Companies route money through four mechanisms, each won differently:
- Automatic dependency-share: won by being findable - step 6 already did this.
- Judgement-based strategic sponsorship: won by being visibly load-bearing for that company's product.
- Employee-nominated funds: won by the engineer who already files your issues nominating you.
- Foundation or pledge membership: won by being a foundation's recipient, not by pitching.
Only the second is won by outreach; know which one you are aiming at before writing to anyone.
- efficiency: `dependency-share > employee-nominated funds > strategic sponsorship > foundation membership`
- value (cheque size per company won): `strategic sponsorship > foundation membership > employee-nominated funds > dependency-share`
- effort: `foundation membership > strategic sponsorship > employee-nominated funds > dependency-share` - membership is a quarter or more of process, a strategic pitch is a week per target, a nomination is one message to an engineer who already knows you, and dependency-share is the near-zero file from step 6
Strategic sponsorship is the same shape step 2's ranking starves, arriving one layer down: it is where the retainer-sized cheques live, and the efficiency line buries it every time. Spend the week per target only against companies whose product visibly depends on the project.
The mechanisms and their numbers are in [references/corporate-sponsorship-path.md](./references/corporate-sponsorship-path.md).
Run the outreach for that second mechanism as a sequence:
1. Identify dependent companies from dependency graphs, public repositories, job posts naming the technology, and issues filed from company domains.
2. Address a person with a budget and an exposure - platform lead, staff engineer, head of security - never a generic address.
3. Frame the ask against a budget line that already exists: supply-chain security, marketing reach, or engineering support. Open Source Pledge members commit more than $2,000 per employed developer per year, and that money is looking for legible recipients.
4. Sell named commitments, not goodwill. Valsorda's list of what a company actually buys:
- Two-factor authentication and mandatory code review.
- Ecosystem-keeping-up updates.
- Reliable review and merge timelines.
- Support on filed issues.
- Careful handling of security reports.
- "even a succession plan."
5. Clear procurement before pitching: an entity, a tax form, a numbered invoice and bank details get processed; a donate button does not. Invoiced sponsorships through GitHub carry a $5,000 minimum per invoice, so smaller asks route through a fiscal host instead.
6. Plan the renewal: budgets are annual, so a proof-of-value note mid-cycle is part of the program, not a courtesy.
Check that the payment route also survives, not just that it works today. A fiscal host is itself a continuity risk: the Open Collective Foundation's 2024 dissolution gave its 600+ collectives seven months to move their funds.
When several maintainers share the money, decide who authorises spending before the first payment lands, and separate "paid to keep the lights on" from "paid to decide direction" - the Django Software Foundation funds a Fellowship for triage and administrative work for exactly that reason. A fiscal host's public ledger also exposes each maintainer's compensation; say so before choosing one.
Outreach templates, the one-page prospectus shape, and the payable checklist are in [references/corporate-sponsorship-path.md](./references/corporate-sponsorship-path.md). Entity and host continuity detail is in [references/funder-scan-and-eligibility.md](./references/funder-scan-and-eligibility.md); the full entity/foundation decision belongs to `samber/developer-relations-skills@oss-governance`.
## Step 8 - Write down what money does not buy
Publish these boundaries alongside the tiers, before the first sponsor arrives:
- Sponsorship buys visibility, gratitude and named commitments - never roadmap control or merged pull requests. Contributions are judged on technical merit whether or not the author pays.
- Priority _triage_ can be sold; priority _outcomes_ cannot.
- The sponsor list, the roadmap and the review queue stay separate artefacts.
- A maintainer who declines funding to protect autonomy has made a legitimate choice, not a mistake.
State any conflict-of-interest rule now: which sponsors would be refused, and who decides.
## Step 9 - Measure the program, not the applause
| Question | Metric | Ignore |
| --------------------- | ---------------------------------------------------------------- | ----------------------- |
| Is it growing? | Recurring monthly amount, trend over 6 months | Cumulative total raised |
| Who is paying? | Sponsor count split individual vs company | Stars, followers |
| Is it durable? | Monthly churn; median tier; share of income from the top sponsor | One-time spikes |
| Does the ask work? | Conversion from each surface carrying the funding link | Page views |
| Was the promise kept? | Funded commitment shipped on time; rewards delivered | Thank-you replies |
**Pass threshold (self-set)**, checked at 90 days and then quarterly:
- Recurring monthly income grew versus the previous quarter.
- Every published reward was delivered on time.
- No single sponsor exceeds 50% of income.
- At least one company tier is occupied, if any company depends on the project.
The 50% line comes from freelance client-concentration practice rather than from open-source funding norms; say so if the user treats it as a rule. Failing it is a concentration risk to fix before growing; failing the fourth condition means the corporate lane in step 7 was never really opened.
Diagnose income problems by where the ask fails:
- Income flat while traffic grows: the ask placement is wrong (step 6).
- Ask everywhere and income still flat: the reward is wrong for the buyer (steps 3-4).
## Invocation examples
Typical asks, and where each one enters the workflow:
- _"I maintain a Rust crate with 900k monthly downloads and no funding page - how do I set this up?"_ → interview, then steps 1-6 in order; hold step 7 until dependent companies can be named.
- _"Three funded startups ship our library and nobody sponsors us."_ → steps 6 and 7 first. When usage is proven and income is zero, the ladder is rarely the problem; findability and the absence of a company tier usually are.
- _"Should I release the new CLI to sponsors first for a month?"_ → step 4, then the sponsorware rules in [references/tier-ladder-examples.md](./references/tier-ladder-examples.md).
- _"Rewrite our tiers, the top one is $50."_ → step 3, checked against the weak ladder and its diagnosis in [references/tier-ladder-examples.md](./references/tier-ladder-examples.md).
- _"A sponsor is asking us to prioritise their issue."_ → step 8, and publish the boundary before the next tier goes live.
## Deliverable
Produce a program brief, presented section by section with agreement on each before the next.
```markdown
# Sponsorship program - <project>
## Goal monthly target, what it buys, by when
## Instrument fit why sponsorship, and what else was recommended
## Audience individual vs company mix, named dependent companies
## Ladder tiers, prices, rewards, delivery cost per reward
## Platform where money is received, fees, entity, payout path
## Ask page copy, funding goal and type, surfaces carrying the link
## Corporate lane target list, contact, pitch, paperwork status
## Boundaries what sponsorship does not buy, refusal rules
## Measurement metrics, review date, pass threshold
```
## Common failure modes
- **Publishing a price you will regret.** Unchangeable on the main platform; a $10 top tier caps the program until it is retired and replaced.
- **A ladder for individuals only.** The money is in company tiers, and a company cannot buy a tier that does not exist.
- **Rewards that outgrow the maintainer.** Monthly calls at 12 sponsors are pleasant; at 120 they end the program.
- **A sponsorship page nobody can reach.** No sponsor button, no README link, no FUNDING.yml - invisible to both humans and dependency-graph funders.
- **Selling roadmap influence.** Converts fastest, destroys neutrality, and invites every other user to distrust the review queue.
- **A goal that never moves.** An unreachable first target reads as a project nobody supports; set one that closes this quarter.
- **Gating the project itself.** Sponsorware on convenience is fine; a paywall on the library, its security fixes or its documentation is a licence-adjacent betrayal of the users who got you here.
- **Going quiet after the money arrives.** Sponsors renew on evidence; a silent quarter is a cancelled sponsorship.
## References
- [references/platform-mechanics.md](./references/platform-mechanics.md) - tier and goal limits, fees, invoiced minimums, FUNDING.yml keys, fiscal hosting, dependency-share platforms.
- [references/tier-ladder-examples.md](./references/tier-ladder-examples.md) - three real ladders with prices and rewards, a weak ladder and its diagnosis, sponsorware rules, and a filled example.
- [references/corporate-sponsorship-path.md](./references/corporate-sponsorship-path.md) - the four funding mechanisms, target identification, outreach email (a weak one and a strong one), prospectus shape, payable checklist, renewal note.
- [references/funder-scan-and-eligibility.md](./references/funder-scan-and-eligibility.md) - the health and payability signals funder tooling reads, employee-nominated fund eligibility rules, entity and fiscal-host continuity risk, and a self-audit pass.
- [references/grant-programs-and-reporting.md](./references/grant-programs-and-reporting.md) - eligibility gates and published sizes per grant program, the recurring application fields, published scoring criteria, post-award reporting duties, and the closed programs.
- `samber/developer-relations-skills@build-in-public` for the transparency practice a public revenue goal commits to.
- `samber/developer-relations-skills@readme-optimization` for the README real estate the ask competes for.
- `samber/developer-relations-skills@oss-distribution-strategy` for growing the audience a visibility tier is priced against.
- `samber/developer-relations-skills@devtools-business-model` for whether sponsorship income can substitute for a revenue model at all.
- `samber/developer-relations-skills@oss-monetization` for what a maintainer can sell instead when sponsorship will not reach a salary: a paid add-on, support, content or a license move.
- `samber/developer-relations-skills@oss-maintainer-sustainability` for when the real problem is the maintainer's load, which money alone does not cut.