samber/developer-relations-skillsチェック済み
SKILL DETAIL
oss-sponsors-brand-strategy
samber/developer-relations-skills/oss-sponsors-brand-strategy
Builds a company's open-source sponsorship portfolio - which projects and maintainers to fund, through which allocation model, at what amount each, and how to prove it worked. Use whenever a company, OSPO, DevRel lead or engineering leader asks which open-source projects to sponsor, how much to budget for open-source funding, whether sponsoring maintainers is worth it, how to run an employee-nominated FOSS fund, how to fund dependencies at scale, how to pick a sponsorship tier on a maintainer's ladder, or how to measure the return on money paid to maintainers - even if they only say they want to give back. Not the maintainer side of raising sponsorship - use samber/developer-relations-skills@oss-sponsors-fundraising. Not event sponsorship.
インストール · 431出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill oss-sponsors-brand-strategy
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "oss-sponsors-brand-strategy",
"evals": [
{
"id": 1,
"prompt": "I run the open source program office at Hollowpine Analytics. We have 140 full-time engineers and our CFO wants one headline number for a blog post next month: \"Hollowpine invested $X in open source in 2026.\" Here is what I want to roll into X: $90k for the loaded cost of the two engineers who maintain our own hollow-etl project on work time, $40k of cloud credits we donate to that same project's CI, $25k we pay Priya Raghunathan, who maintains the parquet-shim library and who we hired in March as a staff engineer, and $62k of actual sponsorships to outside maintainers. That is $217k. Does that number hold up, and how does it compare to what other companies spend?",
"expected_output": "A breakdown separating the one countable line from the three that do not count as open-source funding, a corrected countable total, the two published per-developer figures each labelled for what they are evidence of, and a per-head check against the company's 140 developers.",
"files": [],
"expectations": [
"Identifies that the $90k of engineer time does not count, because it funds a company-controlled project",
"Identifies that the $40k of cloud credits does not count, because it benefits the paying company exclusively or goes to a company-controlled project",
"Identifies that the $25k paid to Priya Raghunathan does not count, because she is a maintainer the company already employs",
"Confirms only the $62k of sponsorships to outside maintainers counts as open-source funding",
"Reports the countable total as $62k rather than $217k",
"Recommends reporting the excluded categories on a separate line rather than dropping them silently or folding them into the headline",
"States the per-developer floor as more than $2,000 per full-time-equivalent developer per year and attributes it to an industry pledge's membership terms rather than to a market average",
"Runs the floor against the 140-developer headcount, giving a figure above $280,000 per year",
"Flags that $62k across 140 developers falls far below that floor",
"Presents $3,700 per developer as what one company published about its own program, explicitly a single self-reported data point, never as an industry average or a market rate",
"Advises re-checking the published figures before they go into the post, because such figures drift",
"Asks which mandate the money serves, or states the headline number cannot be judged without one, rather than endorsing the announcement as framed"
]
},
{
"id": 2,
"prompt": "VP of Engineering at Nord Ledger, a payments company. Our exec team agreed on a weighting for our open source money and I want you to sanity-check it before I take it to the board: 40% supply-chain risk reduction, 30% developer brand, 20% getting our own engineers engaged again, 10% because we signed a public funding pledge last year. Budget is $310k for 2027. Turn those percentages into a portfolio for me.",
"expected_output": "A refusal to weight the four mandates against each other, a demand for one primary and one secondary mandate, and an explanation of what each mandate implies for its default allocation model and its renewal metric.",
"files": [],
"expectations": [
"Refuses to convert the four mandates into a percentage weighting, and says so explicitly rather than quietly producing one",
"States the four mandates are four different goals rather than four routes to one, so a ratio across them would be false precision",
"Requires the user to name exactly one primary mandate and one secondary mandate",
"Explains the primary mandate breaks ties later, deciding which project wins the last money and which metric renewal is judged on",
"Keeps the internal-engagement mandate and the public-values mandate distinct, noting engagement targets projects employees already touch while a values commitment targets whatever the commitment named",
"States the values or pledge mandate is judged on that commitment's own terms: the floor met and the annual report published",
"Maps supply-chain assurance to a default breadth allocation across the dependency graph, measured on coverage of fundable dependencies and reachability of maintainers",
"Maps reach and credibility to a default depth allocation on a few projects the buyers already use, measured on verified placements and referral traffic",
"Maps internal engagement to an employee-nominated fund, measured on employees contributing and nominations per cycle",
"Distinguishes mandate selection, which gets no ratio, from allocation-model selection, which is ranked and does get a budget split",
"Asks whether developers buy or choose the product before treating reach as a marketing return rather than an employer-brand return",
"Does not produce a target project list before the mandate is agreed"
]
},
{
"id": 3,
"prompt": "I lead the open source program office at Corvid Freight, a logistics SaaS. Our head of engineering wants open source funding mainly to get our own 90 engineers engaged again, because contributions have dried up and morale on the platform team is bad. Budget is $180k a year. Two constraints from finance: they pay only against a purchase order with a $5,000 invoice minimum, no company cards at all, and the people team has approved four hours a month of work time for whoever administers this. Give me the allocation.",
"expected_output": "Two or three candidate portfolios with splits and named failures, a single recommendation that promotes the employee-nominated fund above the default efficiency order, breadth deleted or conditioned on a single-invoice route, and the four-hours-a-month ceiling surfaced as a conflict.",
"files": [],
"expectations": [
"Promotes the employee-nominated fund above every other model because internal engagement is the primary mandate, explicitly overriding the default efficiency order",
"States the default efficiency order as breadth, then depth, then foundation membership, then the employee-nominated fund",
"Explains that the efficiency ratio can never select the employee-nominated fund, because the return it buys appears on no other model's row",
"Deletes the breadth motion rather than demoting it, given purchase-order-only finance, or keeps it only on the condition that a fiscal host or platform aggregator bills the whole motion on a single invoice",
"States a $10-a-month sponsorship can never clear a purchase order",
"Flags the four-hours-a-month ceiling as incompatible with an employee-nominated fund, which is a standing job: a cycle to run, eligibility to check, a vote to administer, a result to communicate",
"Presents two or three candidate portfolios with their allocation splits before recommending one",
"Names, for each candidate portfolio, what it deliberately fails at",
"Recommends one portfolio and explains why the others lose",
"Asks for explicit agreement on the chosen shape before building any target list",
"Expresses effort in magnitudes such as near-zero, about a week per project, or a standing job, rather than in currency",
"Does not recommend foundation membership without first checking whether a foundation governs anything in the company's stack",
"Sets aside a reserve of 10-20% for opportunistic funding and labels that reserve as a starting default rather than a standard"
]
},
{
"id": 4,
"prompt": "Sable Ridge Systems here. We already sponsor 23 maintainers through our organization account, all charged to my team lead's corporate card, roughly $2,400 a month in total. Our new controller wants everything on invoices going forward and has asked me to flip the organization to invoiced billing this week. Separately we are planning to announce a much bigger program, $150k, at our user conference on the 14th of next month. What is the sequence?",
"expected_output": "A warning that the billing switch cancels the 23 live sponsorships, the invoiced-billing terms spelled out, a corrected sequence, and procurement cleared before the conference date is committed.",
"files": [],
"expectations": [
"Warns that switching the organization to invoiced billing cancels its existing sponsorships, which then have to be re-established",
"States the 23 sponsored maintainers will receive a cancellation email that reads to them as a withdrawal",
"States the switch must be sequenced before sponsorships are established, never after, and identifies the current plan as the wrong order",
"Names the $5,000 minimum per invoice on invoiced corporate billing",
"Names the 30-day payment term",
"Names the 3% service fee on invoiced billing",
"Names the three-year agreement term and flags it as a commitment legal has to review",
"Notes that below the invoice minimum the company pays by card or routes money through a fiscal host instead",
"States that fiscal hosts commonly take 3-10% of funds received and pay out against a public ledger",
"Requires vendor onboarding, tax forms and sanctions screening to be started before any date is promised",
"Names announcing before procurement clears as a failure mode that becomes a broken promise in public",
"Recommends telling the affected maintainers before the switch rather than letting the cancellation email be the first they hear of it",
"Advises re-checking the platform's current billing terms before quoting these figures, because they drift"
]
},
{
"id": 5,
"prompt": "Head of platform at Thistlewood Robotics. I put together our open source sponsorship shortlist for FY27, $200k total, sorted by GitHub stars because that is the best proxy I have. Flowgraph viz library, 91k stars, everyone knows it and the logo spot is great, $60k. The language runtime we build on, 88k stars, obviously critical, $50k. Big test framework, 41k stars, our principal engineer loves it, $35k. Popular HTTP client, 33k stars, $30k. A linter, 22k stars, $25k. Two of these are maintained by companies that already have funding. Is the split right?",
"expected_output": "A rejection of the star sort and of the list's premise, a demand to start from the dependency graph, the four scoring axes with their status as defaults, the already-funded recipients flagged, and the missing long tail named.",
"files": [],
"expectations": [
"Rejects star count as a ranking input and states stars rank popularity rather than exposure or fragility",
"States the fix is to start from the company's dependency graph instead of from recall, not to do more diligence on these five rows",
"Requests a lockfile, an SBOM or a resolvable repository so direct and transitive dependencies can be resolved",
"Requires deduplicating resolved packages by owner or maintainer rather than by package, because one maintainer often stands behind many packages",
"Scores candidates on exposure, fragility, audience fit and relationship value",
"States those four axes and their weights are this skill's own defaults and invites the user to reweight them",
"Flags the two corporate-backed recipients explicitly as a disqualifier or a flagged row rather than silently dropping them, and notes the marginal effect of money on an already-funded project is near zero",
"Names the missing long tail: single-maintainer packages carrying many transitive dependencies, where a small recurring amount is genuinely load-bearing, cannot surface in a star-sorted list",
"States that no funding destination in this list has been verified, and that a phrase like a great logo spot names no surface, no traffic and no tier",
"Notes depth allocations need not be uniform, citing a published spread running from $1,750 to $15,000 per project per year",
"Asks which mandate the $200k serves before ranking anything",
"Does not deliver a corrected dollar split across the same five projects as the main answer"
]
},
{
"id": 6,
"prompt": "One of my engineers, Marisol, built a spreadsheet for our 2027 funding list. For each of our 310 npm dependencies she noted the maintainer count from the GitHub contributors graph, eyeballed the weekly download numbers, and marked anything she could not find as fine. It says the slugsafe package has 6 maintainers and near-zero downloads, and that we covered 94% of our dependencies. I want to publish that 94% in our annual report. Sanity check it for me.",
"expected_output": "A rejection of the estimated figures and the contributor-graph maintainer count, a requirement that unassessable rows be labelled as such, and a refusal to publish the bare 94% without a denominator.",
"files": [],
"expectations": [
"Rejects hand-collected estimates and requires measured figures, because maintainer counts, download volume and maintenance activity all have APIs",
"States repository contributors and registry publish rights are different populations, and that fragility depends on who can ship a release rather than on who has ever merged a commit",
"States the contributor graph overstates the maintainer count, so the 6-maintainer reading for slugsafe is not a usable fragility signal and should be checked against publish rights",
"Rejects marking unassessable packages as fine, and requires every candidate to resolve to assessed-fine, assessed-flagged, or not-assessable with a stated reason",
"States that a row with missing data is not a clean row",
"Rejects the bare 94% and requires the denominator form, for example resolved N of 310 dependencies with K having no source repository",
"Advises quoting figures verbatim from whatever produced them rather than rounding a score or a download count",
"Recommends resolving the dependency graph from a lockfile, an SBOM or a public dependency-resolution API rather than from a manual list",
"Recommends pulling a per-repository maintenance or health signal instead of a subjective judgement",
"Notes eyeballed download figures have been wrong by orders of magnitude, including being reported as zero for a package moving well over a hundred million a week",
"Requires the final answer to state what could not be checked rather than presenting a clean-looking list with a silent gap",
"Declines to endorse publishing the 94% as it stands"
]
},
{
"id": 7,
"prompt": "Finance finally released the money and I need to pay six maintainers today: the owners of quillnet, stashline, mortar-rs, pinchpoint, tessera-log and bolthole. Just give me the sponsorship URLs for each and pick a tier so I can run the cards this afternoon. Two of them I am fairly sure have no sponsor button, but I will email them and push them to set one up before end of day.",
"expected_output": "A refusal to supply funding URLs from memory, the resolution and verification order for destinations, the two unpayable projects routed to a support-in-kind list, and a refusal to pressure maintainers into enrolling.",
"files": [],
"expectations": [
"Refuses to supply funding URLs from memory and states funding links must never be carried from model recall",
"Requires each destination to be resolved before payment, checking the repository funding manifest, then the owner-level fallback manifest, then registry funding metadata, then the project's own site",
"States the owner-level fallback applies to every repository of that owner that has none of its own, and should be looked up once per owner and reused",
"Requires each URL to be fetched and verified: a live page included, a 404 or not-enrolled page excluded, a redirect followed and the final URL recorded",
"States that paying into a stale destination fails silently and wastes the budget",
"States that a project with no verified destination is out of the sponsorship list however critical it is",
"Routes the two projects with no funding link to a separate support-in-kind list such as contribution time, CI credits, hosting or security review, framed as an opportunity rather than a failing",
"Refuses to pressure any maintainer into setting up a funding link, and notes some maintainers decline funding deliberately to protect their autonomy",
"States payability is a filter rather than one of the scoring axes",
"Asks which surface each tier's placement lands on before any tier is chosen",
"Warns that card-paid organization sponsorships carry up to 6% in total fees, 3% processing plus 3% service, while personal-account sponsorships pass through at 0%",
"Does not shame or criticise any project for having no funding link"
]
},
{
"id": 8,
"prompt": "Kestrel Clinical, we sell shift-scheduling software to hospital operations directors. We use the dayforge library everywhere and its maintainer publishes a ladder: $100 Supporter puts your name in BACKERS.md, $500 Bronze puts a logo in the README, $2,000 Gold puts a logo on the docs site homepage plus a mention in release notes. My CMO says take Gold for the brand exposure. Which tier do we pick?",
"expected_output": "A mandate question first, a statement that reach here returns employer brand rather than marketing because the buyers are not developers, and a tier choice driven by the surface and its traffic rather than the tier name.",
"files": [],
"expectations": [
"Asks which mandate this sponsorship serves before recommending a tier",
"States that because the buyers are hospital operations directors and not developers, reach returns employer brand and recruiting rather than marketing",
"Advises sizing the spend against hiring rather than inflating a marketing case that will not survive review",
"Refuses to pick a tier on the strength of its name or price alone, and requires knowing which surface each tier's placement lands on",
"Recommends asking the maintainer for published or shared traffic figures on the granted surface before pricing the tier",
"States that a logo in a backers file nobody opens is not a media buy at any price",
"Notes that maintainers who sell placement usually publish or will share view counts for the surfaces on their ladder",
"Warns against requesting any benefit the maintainer will resent in six months, because a tier's rewards are recurring work for one person",
"Takes the amount from the maintainer's published ladder rather than from a number that felt right",
"Says the tier question belongs to a later step of a portfolio, and offers the mandate, budget and measurement work around it",
"States that if supply chain were the mandate, the smallest recurring amount across many projects would be correct, because coverage rather than prominence is the goal",
"Does not present the $2,000 tier as a priced media buy against a developer audience"
]
},
{
"id": 9,
"prompt": "Ambrose Yau, our CTO, wants a fund where employees pick an open source project to support. $8,000 a month, one project per month. He wants the whole company to vote in a Slack poll with the top of the list winning, and he wants to seed the first ballot with the ten projects our engineers named in a survey, mostly the big frameworks everyone has heard of. One of our staff engineers maintains ferrite-queue and it is on that list. Another candidate only sells support subscriptions. Write me the rules.",
"expected_output": "A nomination and voting design with open nominations, a contribution-earned franchise, the four eligibility filters applied before the ballot, the two ineligible candidates excluded by name, and a counterweight against the drift toward famous projects.",
"files": [],
"expectations": [
"Names the FOSS Contributor Fund as the published method and attributes it to Duane O'Brien and Mandy Grover, Investing in Open Source: The FOSS Contributor Fund, O'Reilly, 2021",
"Opens nominations to everyone with no prerequisite",
"Restricts voting to employees who made an open-source contribution during that voting cycle, and explains the franchise is earned by contributing",
"Rejects the whole-company Slack poll as the voting rule",
"Applies four eligibility filters before the ballot: in use by the company, OSI-approved license, has a mechanism to receive funds, and not maintained by an employee",
"Excludes ferrite-queue under the employee-maintained rule, or requires an explicit published conflict-of-interest exception for it",
"Excludes the subscription-only candidate because the budget pays one-off amounts",
"Runs the eligibility check before the ballot rather than after it",
"Warns that the vote drifts toward projects that already have money, and requires seeding each ballot with underserved candidates drawn from the dependency graph",
"Reuses the nomination list internally as an onboarding menu for employees who want somewhere to start contributing",
"Requires the fixed per-cycle amount to be paid promptly, because a fund that pays late loses its internal credibility first",
"Requires a published eligibility and conflict-of-interest rule plus employee disclosure before the first cycle",
"Asks who administers the cycle and for how many hours a month, treating the fund as a standing job"
]
},
{
"id": 10,
"prompt": "Draft the outreach note for me. We are putting $120k a year into quarrystone, which sits in our critical path. Our VP of Engineering wants quarterly roadmap syncs, priority handling on the eight issues we have filed, and a joint launch blog post announcing the collaboration. Legal wants a written agreement listing all of that so we can show what we are getting for the money. The maintainer is one person, Tomasz.",
"expected_output": "A refusal to ask for roadmap position or priority outcomes, the services-contract reclassification named, and a rewritten note that states the exposure, the amount, the invoicing path and what the company is explicitly not asking for.",
"files": [],
"expectations": [
"Refuses to request roadmap position or priority outcomes in the note",
"Distinguishes priority triage, which can be negotiated, from priority outcomes, which cannot be bought",
"States that an arrangement returning substantial, non-incidental benefits beyond minimal acknowledgment stops counting as open-source funding",
"States that an agreement listing deliverables is a services contract, and advises calling it and booking it as one rather than describing it as funding open source",
"Warns that asking a single volunteer maintainer for quarterly syncs and account management is how a sponsorship becomes a story about a company buying a project",
"Produces an outreach note that states plainly what the company is not asking for",
"States the exposure concretely, citing the dependency graph or SBOM showing quarrystone in the critical path, rather than generic enthusiasm",
"Names the amount, the term and the invoicing shape the company's procurement needs",
"Asks the maintainer what they need in order to invoice, such as an entity name, a purchase order or tax forms",
"Makes any placement conditional: taken if an existing tier grants it, with the sponsorship standing if it does not",
"Recommends publishing the company's funding policy, including the section on what sponsorship does not buy, before the first payment",
"Requires employees who publicly advocate for a funded project to disclose the relationship",
"Notes vendor onboarding, tax forms and sanctions screening apply to an individual maintainer as they do to any supplier, and that the paperwork starts before a date is promised"
]
},
{
"id": 11,
"prompt": "Our CMO wants a dashboard for the $240k open source program before the quarterly business review. She has asked for pipeline sourced from sponsorship on a last-click model, estimated impressions calculated from the combined GitHub stars of the projects we fund, total dollars given as the headline metric, and a share-of-voice score. Supply chain is our primary mandate and developer brand is secondary. Build it.",
"expected_output": "A refusal of the last-click and star-derived impression metrics, a measurement table organised by mandate, pass thresholds labelled as defaults, a baseline and owner per row, and the annual report format.",
"files": [],
"expectations": [
"Refuses to build a last-click attribution model for sponsorship and states nobody clicks a README logo and buys",
"Rejects impressions estimated from stars",
"Rejects total dollars given as a headline metric",
"Leads with the supply-chain measures, because that is the primary mandate: share of fundable dependencies covered, dormant-dependency count, and response time on issues the company filed upstream",
"Measures the secondary reach mandate on placements live and verified, referral traffic from placement URLs, and unaided mentions in developer surveys and community threads",
"Sets a pass threshold of at least 80% of fundable direct dependencies covered for a supply-chain primary mandate",
"Labels that 80% threshold as this skill's own default rather than an industry standard",
"Notes the only company to publish a higher coverage figure reported 95% or greater and described itself as the first to approach 100%, and presents anything above 80% as ambitious rather than standard",
"Requires a baseline captured before the first payment",
"Requires a named owner on every metric row",
"Requires every placement the company paid for to be live and verified at review",
"Requires every depth sponsee to have at least one documented interaction beyond the payment",
"Sets the first review at 12 months and annually after, with a renewal decision made for every target before budget close",
"Recommends publishing an annual report giving the year, the full-time-equivalent developer count, the total paid, and the amount per recipient"
]
},
{
"id": 12,
"prompt": "Three things before budget close. First, the maintainer of hexpath merged a change that broke our build and refused to revert it, so I want to pull that $9k sponsorship as a signal. Second, dustmote has had no commits in 26 months but we have been paying $200 a month for two years, and I would rather keep it quiet and just let it lapse. Third, we have four other sponsorships I have no time to review, so can we let them run and pick it up next year? Also, do we need to redo the whole dependency analysis or is last year's list still fine?",
"expected_output": "A refusal to end a sponsorship over a technical disagreement, dormancy accepted as a legitimate stated reason with a maintenance signal behind it, the quiet lapse refused, renewal decisions required before budget close, and discovery re-run annually.",
"files": [],
"expectations": [
"Refuses to end the hexpath sponsorship over a technical disagreement, and states that is exactly the influence the policy promised not to buy",
"Lists the legitimate reasons to end a sponsorship: the dependency is gone, the project is dormant, the mandate changed, or a policy breach",
"Treats dustmote's 26 months without a commit as dormancy, a stated reason that does justify ending the sponsorship",
"Reads dormancy from a maintenance signal rather than intuition, naming the maintained-score band of 0-3 as the disqualifying band absent a revival agreement",
"Allows funding a dormant project only as an explicit revival bet agreed with the maintainer",
"Refuses the quiet lapse and requires telling the maintainer before the sponsorship ends, with a reason and a date",
"States a silent cancellation is remembered far longer than the money was, and does more relationship damage than a sponsorship that was never started",
"Requires a renewal decision on every target before budget close rather than letting four sponsorships roll into next year unreviewed",
"Refuses to reuse last year's target list and requires discovery to be re-run annually, because dependency graphs move, maintainers hand over projects, and funding destinations go stale",
"States that last year's verified list is this year's unverified list",
"Recommends cutting the portfolio to a size the team can actually renew thoughtfully, labelling the roughly-a-dozen figure as a default rather than a rule",
"Asks whether these sponsorships were announced as recurring or one-off, because that changes what dropping them costs"
]
}
],
"trigger_queries": [
{ "query": "Which open source projects should our company sponsor?", "should_trigger": true },
{ "query": "We have $80k for open source next year. Where should it go?", "should_trigger": true },
{ "query": "How much should we budget for funding open source maintainers?", "should_trigger": true },
{ "query": "is sponsoring maintainers actually worth it", "should_trigger": true },
{ "query": "our CTO wants a FOSS fund like the one he read about, set it up", "should_trigger": true },
{ "query": "How do we fund our dependencies at scale?", "should_trigger": true },
{ "query": "Should we sponsor this project at the $500 or the $2,000 tier?", "should_trigger": true },
{ "query": "Which of our dependencies can we even pay?", "should_trigger": true },
{ "query": "Legal wants to know what we get for sponsoring open source", "should_trigger": true },
{ "query": "we want to give back to open source but have no idea where to start", "should_trigger": true },
{ "query": "How do I run an employee-nominated open source fund?", "should_trigger": true },
{ "query": "What is a reasonable per-developer amount to give to open source each year?", "should_trigger": true },
{ "query": "Our CFO asked for one number for how much we invest in open source", "should_trigger": true },
{ "query": "How do we measure the return on money we pay maintainers?", "should_trigger": true },
{ "query": "we signed the open source funding pledge last year, now what", "should_trigger": true },
{ "query": "Build our 2027 open source sponsorship portfolio", "should_trigger": true },
{ "query": "Should we join a foundation or sponsor projects directly?", "should_trigger": true },
{ "query": "How do we pick which maintainers to pay?", "should_trigger": true },
{ "query": "we pay 30 maintainers by card and finance wants everything on invoices now", "should_trigger": true },
{ "query": "Is it better to spread small amounts across all our dependencies or concentrate on a few?", "should_trigger": true },
{ "query": "help me justify open source donations to my CFO", "should_trigger": true },
{ "query": "What should we put in our open source funding policy?", "should_trigger": true },
{ "query": "our engineers keep asking why we don't fund the tools we use", "should_trigger": true },
{ "query": "How do other companies decide who to sponsor on GitHub Sponsors?", "should_trigger": true },
{ "query": "we want to sponsor the projects in our stack but don't know how to find them", "should_trigger": true },
{ "query": "what goes in the annual report of where our open source money went", "should_trigger": true },
{ "query": "Can we ask for roadmap influence if we sponsor a project?", "should_trigger": true },
{ "query": "our VP wants quarterly syncs with a maintainer we fund", "should_trigger": true },
{ "query": "How many projects should we sponsor?", "should_trigger": true },
{ "query": "we want to fund the maintainers behind our npm dependencies, what is the process", "should_trigger": true },
{ "query": "we sponsored a bunch of projects last year and nobody noticed", "should_trigger": true },
{ "query": "how do we avoid funding projects that already have plenty of money", "should_trigger": true },
{ "query": "we're sponsoring a project that hasn't shipped in two years, keep paying?", "should_trigger": true },
{ "query": "How do we end a sponsorship without burning the relationship?", "should_trigger": true },
{ "query": "our dependency list has 400 packages, who do we actually pay", "should_trigger": true },
{ "query": "What does a corporate open source giving program look like?", "should_trigger": true },
{ "query": "Should our company pay maintainers through Open Collective or GitHub Sponsors?", "should_trigger": true },
{ "query": "i want to pay the maintainer of the library our auth path depends on", "should_trigger": true },
{ "query": "do cloud credits we give our own open source project count as giving back", "should_trigger": true },
{ "query": "we need an OSPO funding strategy", "should_trigger": true },
{ "query": "how much do companies actually pay maintainers per year", "should_trigger": true },
{ "query": "our procurement only issues purchase orders, can we still sponsor maintainers", "should_trigger": true },
{ "query": "which of these five projects deserves our money", "should_trigger": true },
{ "query": "does funding open source actually help us hire engineers", "should_trigger": true },
{ "query": "we're a security vendor, would funding our dependencies reduce supply chain risk", "should_trigger": true },
{ "query": "What is the ROI on open source sponsorship?", "should_trigger": true },
{ "query": "help me design the vote for our internal open source fund", "should_trigger": true },
{ "query": "should we fund the foundation or the individual maintainer", "should_trigger": true },
{ "query": "we want to announce an open source fund at our user conference next month", "should_trigger": true },
{ "query": "who should decide internally which projects we sponsor", "should_trigger": true },
{ "query": "is $10 a month per dependency enough to matter", "should_trigger": true },
{ "query": "we keep funding the famous stuff and ignoring the fragile stuff", "should_trigger": true },
{ "query": "our sponsorship shortlist was picked by stars, is that fine", "should_trigger": true },
{ "query": "how do we verify a maintainer can actually receive our money", "should_trigger": true },
{ "query": "one of our engineers maintains a project we want to fund, is that a problem", "should_trigger": true },
{ "query": "money for maintainers, how do we structure it", "should_trigger": true },
{ "query": "what should we not promise a maintainer we are paying", "should_trigger": true },
{ "query": "our open source spend needs a review threshold before renewal", "should_trigger": true },
{ "query": "how much should we hold back for a maintainer emergency", "should_trigger": true },
{ "query": "what metrics prove our maintainer funding worked", "should_trigger": true },
{ "query": "a customer is asking us to prove the software we depend on is funded", "should_trigger": true },
{ "query": "how do I stop our open source donations reading as a one-off stunt", "should_trigger": true },
{ "query": "the board wants to know why we give money to random developers on the internet", "should_trigger": true },
{ "query": "our engineers nominated 40 projects, how do we narrow that down", "should_trigger": true },
{ "query": "we want to put money into the ecosystem our SDK sits in", "should_trigger": true },
{ "query": "budget close is in three weeks and I haven't decided renewals for the projects we fund", "should_trigger": true },
{ "query": "How do I set up GitHub Sponsors tiers for my project?", "should_trigger": false },
{ "query": "nobody sponsors my library even though it has 5k stars", "should_trigger": false },
{ "query": "What rewards should I offer my sponsors?", "should_trigger": false },
{ "query": "write my FUNDING.yml", "should_trigger": false },
{ "query": "How do I get a company to fund my maintenance work?", "should_trigger": false },
{ "query": "should I try sponsorware for my next feature", "should_trigger": false },
{ "query": "what should I charge corporate sponsors for a logo on my README", "should_trigger": false },
{ "query": "write the grant application for my open source project", "should_trigger": false },
{ "query": "How much should we pay for a gold booth at a cloud-native conference?", "should_trigger": false },
{ "query": "is sponsoring this conference worth $25k", "should_trigger": false },
{ "query": "we're sponsoring a hackathon, what should our activation be", "should_trigger": false },
{ "query": "split our event budget across six conferences next year", "should_trigger": false },
{ "query": "how do we measure booth ROI", "should_trigger": false },
{ "query": "should we sponsor a meetup series in Berlin", "should_trigger": false },
{ "query": "Plan our devrel budget across events, content and community", "should_trigger": false },
{ "query": "what should we cut first if our devrel budget shrinks 30%", "should_trigger": false },
{ "query": "defend our devrel budget at the exec review", "should_trigger": false },
{ "query": "which devrel metrics should we report to the board", "should_trigger": false },
{ "query": "Should we open source our ingestion engine?", "should_trigger": false },
{ "query": "where do we draw the open core line", "should_trigger": false },
{ "query": "MIT or Apache-2.0 for our new SDK?", "should_trigger": false },
{ "query": "do we need a CLA or a DCO for contributors", "should_trigger": false },
{ "query": "does AGPL actually protect us from cloud providers", "should_trigger": false },
{ "query": "write a GOVERNANCE.md for our project", "should_trigger": false },
{ "query": "should we donate our project to a foundation", "should_trigger": false },
{ "query": "how do we add and remove maintainers on our repo", "should_trigger": false },
{ "query": "our project is deadlocked on a decision, who breaks the tie", "should_trigger": false },
{ "query": "how do we triage the 400 open issues on our repo", "should_trigger": false },
{ "query": "plan the launch of our new open source tool", "should_trigger": false },
{ "query": "nobody is using our project three months after launch", "should_trigger": false },
{ "query": "which awesome lists should we get our library on", "should_trigger": false },
{ "query": "how often should we cut releases for visibility", "should_trigger": false },
{ "query": "onboard new contributors to our repo", "should_trigger": false },
{ "query": "rewrite our README so it converts", "should_trigger": false },
{ "query": "should our devtool be priced per seat or per usage", "should_trigger": false },
{ "query": "how do we price against our own open source edition", "should_trigger": false },
{ "query": "which business model should our open source company run", "should_trigger": false },
{ "query": "should we open our API so partners can build integrations", "should_trigger": false },
{ "query": "build a developer champions program", "should_trigger": false },
{ "query": "how do we grow our Discord community", "should_trigger": false },
{ "query": "write a case study about a customer using our API", "should_trigger": false },
{ "query": "our docs structure is a mess, audit it", "should_trigger": false },
{ "query": "write a quickstart for our SDK", "should_trigger": false },
{ "query": "draft a CFP submission for a Go conference", "should_trigger": false },
{ "query": "hire a developer advocate", "should_trigger": false },
{ "query": "what newsletters should a devrel lead follow", "should_trigger": false },
{ "query": "segment our developer users", "should_trigger": false },
{ "query": "which keywords should our developer docs target", "should_trigger": false },
{ "query": "write the changelog for release 4.2", "should_trigger": false },
{ "query": "should we push our wire format through a standards body or keep it proprietary", "should_trigger": false },
{ "query": "plan a migration guide for our v3 to v4 breaking changes", "should_trigger": false },
{ "query": "find sponsors for our developer podcast", "should_trigger": false },
{ "query": "write a sponsorship proposal deck to send to brands", "should_trigger": false },
{ "query": "how do I get brand sponsorships for my YouTube channel", "should_trigger": false },
{ "query": "set up an affiliate program for our SaaS", "should_trigger": false },
{ "query": "build a partner co-marketing plan", "should_trigger": false },
{ "query": "our corporate social responsibility report needs a charitable giving section", "should_trigger": false },
{ "query": "which charities should our company donate to this year", "should_trigger": false },
{ "query": "design an employee matching-gifts program", "should_trigger": false },
{ "query": "set up an employee volunteering program", "should_trigger": false },
{ "query": "audit our npm dependencies for CVEs", "should_trigger": false },
{ "query": "generate an SBOM for our Go service", "should_trigger": false },
{ "query": "replace our unmaintained dependencies with alternatives", "should_trigger": false },
{ "query": "write our policy for approving new third-party dependencies", "should_trigger": false },
{ "query": "negotiate an enterprise support contract with a software vendor", "should_trigger": false },
{ "query": "how do we get our vendors through procurement faster", "should_trigger": false }
]
}
references/allocation-models.md›
# Allocation models, budgets and payment mechanics
Everything attributed to a program below was published by that program, and those publications drift - re-check before quoting a figure to a user, since platform terms and pledge totals change. The worked budget split is this skill's own default, not a published figure.
## Contents
- The four allocation models
- A worked budget split
- A weak portfolio and its diagnosis
- Payment mechanics and minimums
## The four allocation models
Listed in the efficiency order the skill ranks them in: value returned per unit of internal effort.
### 1. Breadth - dependency-share
Spread the budget automatically across the dependency graph, direct and transitive.
Reference program: one observability vendor distributed $500,000 to maintainers using $4-$10/month sponsorships across its dependency graph, reaching "95% or greater coverage" of its fundable dependencies, with roughly 90% of the budget allocated through a dependency-share platform. Its own summary of the long tail: "For many of our dependencies, we are likely their first and sole sponsor."
Read that 95% as a frontier, not a norm - the same write-up calls the company "the first company to approach 100% coverage of all of our fundable dependencies". A first-year program that lands anywhere near it has done something unusual.
- Discovery cost: near zero - the graph is the target list.
- Buys: coverage, goodwill, an honest answer to "do you fund what you use".
- Fails at: visibility. $10/month rarely appears on any public surface.
- Watch for: money landing on vendor-maintained or dormant packages, unnoticed for a year.
### 2. Depth - judgement-based strategic sponsorship
A short list of projects the company is visibly load-bearing on, funded at amounts a maintainer can plan around.
The same program's published depth allocations, per project per year:
- $15,000 to a session-replay library.
- $10,000 and $6,000 to two language foundations.
- $1,750 to a web framework.
That spread is the useful part; depth does not mean uniform.
- Discovery cost: a human decision per project, plus an annual renewal conversation.
- Buys: placement on real surfaces, a named relationship, and continuity of a dependency you cannot replace quickly.
- Fails at: coverage of the long tail.
- Watch for: a list assembled from internal advocacy rather than dependency reality.
### 3. Foundation or consortium membership
Dues to an organization that redistributes to projects and infrastructure.
The one public per-head benchmark comes from an industry pledge asking members for **more than $2,000 per full-time-equivalent developer per year**, paid to maintainers and foundations. It reports **$7,270,139** raised in total, with $3M+ in the trailing year. Members include mid-size software vendors, not only large enterprises.
- Buys: governance access, standing in an ecosystem, a listing.
- Fails at: individual maintainer relationships - nobody at a project knows your name.
### 4. Employee-nominated fund (the FOSS Contributor Fund)
A fixed amount per cycle, nominated and voted on internally. This is the one model with a named, published method behind it - _Investing in Open Source: The FOSS Contributor Fund_, by Duane O'Brien and Mandy Grover (O'Reilly Media, November 2021). Several large employers run a variant; the documented reference implementation:
- **$10,000 per month** to one selected project.
- **Anyone may nominate.** Only employees who made an open-source contribution during that voting cycle may vote - the franchise is earned by contributing, which makes the fund an internal contribution incentive as much as a donation.
- Project eligibility, all four required: in use by the company; OSI-approved license; has a mechanism to receive funds; not maintained by an employee.
- Reported lessons:
- Open nominations to everyone rather than only employees with linked profiles.
- Exclude projects that can only accept a support contract or subscription when the budget pays one-off.
- The vote drifts toward famous projects, so deliberately surface underserved ones.
- The nomination list doubles as an onboarding menu for employees who want to start contributing.
- Buys: internal engagement and a selection story that survives "why them and not us".
- Fails at: targeting precision.
## What a pledge-style commitment actually obliges
Worth reading even for a company that never joins, because it is the closest thing to a published standard for reporting this spend.
1. **Pay** more than $2,000 per FTE developer per year, direct to maintainers or foundations of the company's choice.
2. **Publish** a post reporting the year, the developer count, the total paid, and the amount per recipient. The published example format is deliberately plain: "14 developers on our team", "$30,000", "$10,000 to foo".
3. **Promote** it - a link to the post, a company description under 600 characters, branding assets.
4. **Renew** by publishing a new post each year.
Four payment categories do **not** count toward it:
- Company-controlled projects.
- Software benefiting the paying company exclusively.
- Maintainers the company already employs.
- Any arrangement returning substantial, non-incidental benefits beyond minimal acknowledgment.
The last one is where a "strategic sponsorship" quietly becomes a services contract; that is a distinction finance and legal will make eventually, so make it first.
## A worked budget split
Illustrative, not published - the percentages below are this skill's defaults and exist to be argued with. A 120-developer company, reach as primary mandate and supply chain as secondary, using the $2,000/developer floor. For context on what the top of the market pays, the one company that disclosed its actual spend reported **$3,700 per developer** - nearly double the floor.
| Line | Share | Amount/year | Rationale |
| ----------------------------------- | ----- | ----------- | ------------------------------------------------------------------------------------------- |
| Breadth across the dependency graph | 25% | $60,000 | Automatic coverage; requires no annual decision |
| Depth on 8 projects the buyers use | 50% | $120,000 | Placement on surfaces with measurable traffic; averages $15,000 each, spread $5,000-$30,000 |
| Employee-nominated fund | 10% | $24,000 | $2,000/month, one project per cycle |
| Reserve | 15% | $36,000 | Incident response, a maintainer in trouble, a dependency that becomes load-bearing mid-year |
Adjust the split, never the discipline: every line names who decides it and what would end it.
## A weak portfolio and its diagnosis
> $250,000 announced in a blog post: $200,000 to a foundation membership at the top tier, $50,000 split between two projects the CTO likes. No dependency analysis. No renewal date. Placement not checked. Two of the three recipients were already funded by their corporate parent.
What is wrong with it, in order of cost:
1. **No mandate.** Nothing in the portfolio can be judged next year, because nobody said what it was for.
2. **No exposure link.** The company's actual dependency graph never entered the decision, so the supply-chain claim in the blog post is unsupported.
3. **Money to the already-funded.** The largest recipients had corporate backing; the marginal effect of the money is near zero.
4. **One-off shape.** No renewal date means it reads as a stunt to the audience it targeted.
5. **Unverified placement.** The reach claim was never checked against a surface or a traffic number.
## Payment mechanics and minimums
Platform names appear here because the numbers are platform-specific; the skill's own instructions stay generic so they survive a maintainer using something else.
- **Invoiced corporate billing** on GitHub Sponsors, the platform most maintainers publish on:
- **$5,000 minimum per invoice**, payable within **30 days**.
- **3% service fee** (the ~3% card-processing fee does not apply).
- Credit spent down over time **without expiry**.
- Under an agreement that runs **3 years** before renewal.
- **Switching an organization to invoiced billing cancels its current sponsorships**, and sponsored projects receive a cancellation email. Sequence the switch before the first sponsorship; a bulk re-sponsor tool exists but the maintainer still sees the cancellation.
- **Organization sponsorships** on that platform carry up to a 6% total fee when paid by card (3% processing + 3% service). Personal-account sponsorships pass through with no fee.
- **Fiscal hosts** (the route for projects that are not incorporated - Open Collective and similar):
- Take a percentage of funds received, commonly 3-10%, with the Open Source Collective host at 10%.
- Pay out against expenses on a **public ledger**, so every payment is visible.
- **Dependency-share platforms** (thanks.dev and similar) distribute one budget across a funder's direct and transitive dependencies (three levels deep, breadth-first, reweightable by language or org), which is how the breadth motion is executed without any outreach. thanks.dev's own funder page still blocks automated fetching, but its mechanics are corroborated via search; its fee has reportedly moved from a voluntary tip (5% per Canonical's 2023 account) toward 0% platform fee plus Stripe processing (more recent sources) - confirm the current fee before quoting one. Tidelift is the contract-shaped variant: it pays maintainers for named obligations rather than goodwill.
- **Below the invoiced minimum**, a company pays by card or through a fiscal host. A finance department that only issues purchase orders cannot send $50/month at all - decide this before designing the breadth line.
- Tax treatment differs by whether the payment books as marketing, engineering spend or charitable giving, and by jurisdiction. Present the options; route the decision to the company's finance and legal teams.
references/policy-and-measurement.md›
# Sponsorship policy, nomination process and measurement
The artefacts a sponsorship program publishes, and the numbers it reports on afterwards.
## Contents
- Public policy skeleton
- Nomination and voting process
- Outreach note to a maintainer (good and bad)
- Measurement table with a filled example
- Annual report shape
- Renewal and exit
## Public policy skeleton
Publish this on the company's open-source page before the first payment. Maintainers read it before accepting; employees read it before nominating. It is what stops the program being read as favouritism.
```markdown
# Open-source funding policy - <company>
## Why we fund
One paragraph: the mandate, in plain language.
## What we fund
Eligibility: in use by us / OSI-approved license / able to receive funds /
not maintained by our own staff. Anything else we exclude, and why.
## How much and how often
Budget shape, cadence, and whether a sponsorship is recurring or one-off.
## How a project is chosen
Who decides, on what inputs, how often, and how to ask us to consider a project.
## What sponsorship does not buy
No roadmap position. No merged pull requests. No priority outcomes.
No obligation to advertise us, thank us, or answer us faster than anyone else.
## Conflicts of interest
How we handle projects maintained by employees, by investors, or by customers.
## Disclosure
Our employees disclose the relationship when they advocate publicly for a
project we fund.
## Contact
A named human, not a form.
```
The line that does the most work is "what sponsorship does not buy". Maintainers publish the same boundary from their side; a funder who publishes it first is trusted faster.
## Nomination and voting process
For the employee-nominated model, write the rules down before the first cycle:
1. **Who nominates** - everyone, with no prerequisite. Restricting nominations to employees with linked accounts measurably suppresses participation.
2. **Who votes** - employees who contributed to open source during the cycle. Earning the vote by contributing is what turns the fund into a contribution program.
3. **Eligibility check** - run the four filters (in use, OSI license, can receive funds, not employee-maintained) before the ballot, not after.
4. **Cadence and amount** - a fixed amount per cycle, paid promptly. A fund that pays late loses its internal credibility first.
5. **Counterweight to fame** - seed each ballot with underserved candidates from the dependency graph, because open voting drifts toward projects that already have money.
6. **Reuse the ballot** - publish the nomination list internally as a menu for employees who want somewhere to start contributing.
## Outreach note to a maintainer
Most sponsorships need no outreach - you pick a tier and pay. Write to the maintainer when the amount is custom, invoiced, or tied to a placement.
**Good:**
> Hi <name> - we run <product> and <project> sits in our auth path; our SBOM shows it in every build we ship. We would like to sponsor at $1,000/month for the next 12 months, invoiced annually so it clears our procurement.
>
> To be explicit about what we are not asking for: no roadmap input, no priority on our issues, no obligation to mention us. If your top tier includes a logo on the docs site we would take it; if it doesn't, the sponsorship stands anyway.
>
> What do you need from us to invoice - an entity name, a PO, a tax form? Happy to work through your process.
**Bad:**
> Hi! We're excited to explore a strategic partnership around <project>. We'd want quarterly roadmap syncs, priority handling for our issues, and a joint blog post announcing the collaboration. Could you send over a deck of sponsorship packages?
The second note asks a volunteer for account management, implies influence over the roadmap, and treats a maintainer like a vendor with a sales team. It is also how a sponsorship becomes a story about a company trying to buy a project.
## Measurement table with a filled example
The figures below are invented to show the table's shape. No public benchmark exists for what a corporate sponsorship program should expect on any of these rows, so copy the columns and the discipline - never the numbers. Fill the baseline column from the company's own measurement before the first payment; that is the only number in the table with any authority.
| Mandate | Metric | Baseline (year 0) | Target (year 1) | Actual |
| ------------ | -------------------------------------------------------- | ----------------- | --------------- | ---------------------------------------- |
| Supply chain | Fundable direct dependencies covered | 4% | 80% | 86% |
| Supply chain | Dependencies with a dormant maintenance score | 31 | < 20 | 24 |
| Supply chain | Median response on issues we filed upstream | 19 days | < 10 days | 11 days |
| Reach | Placements live and verified | 0 | 8/8 | 7/8 (one docs redesign dropped the logo) |
| Reach | Referral sessions from placement URLs | 0 | any measurable | 2,140 |
| Reach | Unaided mentions of the program in developer communities | 0 | > 5 | 12 |
| Internal | Employees contributing during a voting cycle | 6 | 25 | 31 |
| Policy | Breaches raised by a sponsee | - | 0 | 0 |
Two disciplines make this table honest:
- Capture the baseline **before** the first payment.
- Put a named owner on every row.
What it deliberately omits is any attempt to attribute revenue: nobody clicks a README logo and buys, and a last-click model built on this channel collapses at its first audit.
## Annual report shape
Short, public, and specific. The industry pledge publishes the minimum a report must disclose, short enough that there is no excuse for skipping it:
- The year.
- The number of full-time-equivalent developers on staff.
- The total paid.
- The amount per recipient.
Its own worked example reads like "14 developers on our team", "$30,000", "$10,000 to foo". Publishing it again each year is what distinguishes a program from an announcement.
The fuller template below adds what maintainers actually read on top of that minimum:
```markdown
# Where our open-source money went in <year>
Total: $X across N destinations.
Breadth: $A across M dependencies (median $B each).
Depth: table of project, amount, why it matters to us.
Nominated fund: projects chosen per cycle, and who voted.
What we got wrong this year: one honest paragraph.
Next year: budget direction and how to reach us.
```
The "what we got wrong" paragraph is what separates a report from a press release, and it costs nothing.
## Renewal and exit
- Put every sponsorship's renewal decision **before** the budget close date, not after; a lapse caused by internal timing reads to the maintainer as a withdrawal.
- Tell a maintainer before a sponsorship ends, with a reason and a date. A silent cancellation is remembered far longer than the money was.
- End a sponsorship for stated reasons only:
- The dependency is gone.
- The project is dormant.
- The mandate changed.
- A policy breach.
Never for a disagreement over a technical decision - that is exactly the influence the policy promised not to buy.
- Re-run discovery annually. Dependency graphs move, maintainers hand over projects, and funding destinations go stale; last year's verified list is this year's unverified list.
references/sourced-numbers.md›
# Where every number in this skill comes from
Read this before quoting any figure to a user, and before defending a threshold in a budget review. Each row says whether the number was **published** by someone who ran a program, or **set by this skill** as a starting default. A default is a place to begin an argument, never an industry standard - presenting one as a benchmark is how a portfolio review gets discredited.
Published figures drift: platform terms change, pledge totals grow, programs re-publish. Re-check before quoting one.
## Contents
- Published figures
- Defaults set by this skill
- How to talk about each kind
## Published figures
| Figure | Value | Where it comes from |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Per-developer funding floor | more than **$2,000 per full-time-equivalent developer per year** | The industry pledge's membership terms |
| Per-developer actual, one program | **$3,700 per developer**, its own words: "quite reasonable compensation for the value we receive" | An observability vendor's write-up of its $500,000 program |
| Best published dependency coverage | **"95% or greater coverage of our fundable dependencies"**, claiming to be "the first company to approach 100%" | Same write-up |
| Breadth sponsorship size | **$4-$10 per month** per dependency | Same write-up |
| Depth allocations, same program | **$15,000** to a session-replay library, **$10,000** and **$6,000** to two language foundations, **$1,750** to a web framework, per year | Same write-up |
| Share of that budget routed automatically | roughly **90%**, through a dependency-share platform | Same write-up |
| Employee-nominated fund size | **$10,000 per month** to one project per cycle | The reference implementation of the FOSS-fund pattern, documented in _Investing in Open Source: The FOSS Contributor Fund_ (O'Brien and Grover, O'Reilly, 2021) |
| Fund eligibility rules | in use by the company; OSI-approved license; able to receive funds; not maintained by an employee | Same |
| Invoiced corporate billing | **$5,000 minimum per invoice**, **30 days** to pay, **3%** service fee, **3-year** agreement term | The dominant sponsorship platform's own billing documentation |
| Card-paid organization sponsorships | up to **6%** total (3% processing + 3% service); personal accounts pass through at **0%** | Same |
| Fiscal-host cut | commonly **3-10%** of funds received; the largest open-source host charges **10%** | Fiscal-host published fee schedules |
| Maintainer placement pricing | tiers priced against **published monthly view counts** of 60k, 20k and 6k on specific surfaces | A widely sponsored individual maintainer's public tier ladder |
| Health-score reading | Scorecard **Maintained** check, 0-10 | The open scorecard project's definition |
| Criticality scale | **0 to 1**, from ten weighted signals including contributor count, organizational diversity and dependents count | The open criticality-score project |
## Payments a pledge-style program refuses to count
Published alongside the per-developer floor, worth applying even if the company never joins anything. Money does not count as open-source funding when it goes to:
- A **company-controlled project**.
- Software that **benefits the paying company exclusively**.
- A **maintainer the company already employs**.
- An arrangement returning **substantial, non-incidental benefits beyond minimal acknowledgment**.
The last one is the trap. A sponsorship negotiated for deliverables is a services contract; call it that, book it that way, and stop describing it as funding open source.
## Defaults set by this skill
These are starting points, not published figures. Say so when a user asks where they came from, and change any of them the moment the user has a better reason.
| Default | Value | Why this starting point |
| --------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Opportunistic reserve | **10-20%** of the budget | Enough to fund one unplanned emergency at depth-tier size without reopening the budget |
| Split for a reach-primary program | 25% breadth / 50% depth / 10% nominated fund / 15% reserve | Puts the majority on the surfaces the primary mandate is judged on, keeps breadth alive |
| Coverage pass threshold | **80%** of fundable direct dependencies, when supply chain is the primary mandate | Deliberately below the 95% frontier above: reaching that took a dedicated program and a platform integration |
| Scoring axes and weights | exposure, fragility, audience fit, relationship value, weighted ×3/×2/×1 by mandate | A weighting that makes the primary mandate decide ties; the axes come from what funders say they buy |
| Depth portfolio size | roughly a dozen sponsorships a team can renew thoughtfully | An annual review that degenerates into rubber-stamping is worse than a shorter list |
| Dormancy cut | Maintained score **0-3** disqualifies without a revival agreement | The scorecard project's own reading of that band as likely unmaintained |
| Review cadence | first check at **12 months**, annually after | Matches the budget cycle that decides renewal |
## How to talk about each kind
- Published figure: name what it is evidence of. "One company that published its program paid $3,700 per developer" - not "companies pay $3,700 per developer".
- Default: name it as a starting point and invite the argument. "Start at 80% coverage; the only published program above that built a platform integration to get there."
- Anything you cannot place in either table: leave it out. An unsourced round number in a budget deck is the first thing a finance reviewer tests.
references/target-discovery-and-scoring.md›
# Target discovery, verification and scoring
How to turn a company's stack into a ranked, verified sponsorship shortlist. Endpoints and manifest paths move, so confirm each one against the registry's current documentation.
## Contents
- Measurement rules
- Step A - resolve the dependency graph
- Step B - map packages to repositories and maintainers
- Step C - pull health and criticality signals
- Step D - find and verify funding destinations
- Step E - collect reach signals (manual)
- Scoring rubric
- Worked shortlist
- The same shortlist done badly
- Disqualifiers
## Measurement rules
Every row of a shortlist is a claim about somebody else's project, published with money attached. Four rules keep it honest, each one a failure that hand-collected dependency lists produce.
- **Measure, do not estimate.** Maintainer counts, download volume and staleness all have APIs. Hand-collected figures have reported five-plus maintainers for a package whose registry publish rights list one, and zero downloads for a package moving 164 million a week.
- **Repository contributors are a different population from publish rights.** Fragility depends on who can ship a release, not on who has ever merged a commit.
- **Unassessable is not clean.** Every candidate resolves to assessed-fine, assessed-flagged, or not-assessable-because-X. Registries differ in what they expose; some ecosystems publish no maintainer list at all.
- **Carry the denominator.** "412 of 470 dependencies resolved; 58 had no source repository" is the honest form of any coverage percentage, and the form that survives an audit.
- **Quote figures verbatim** from whatever produced them. Rounding a scorecard number or a download count breaks reproducibility for no gain.
## Step A - resolve the dependency graph
Prefer the company's own SBOM or lockfiles when they exist; they describe what actually ships. Otherwise resolve from the published package.
A public resolution API returns a full tree - direct and transitive - in one call:
```
https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{PACKAGE}/versions/{VERSION}:dependencies
```
`ECOSYSTEM` covers npm, PyPI, Cargo, Go, RubyGems, Maven and NuGet. Each returned node carries `versionKey.name`, `versionKey.version` and `relation` (`SELF`, `DIRECT`, `INDIRECT`). Percent-encode package names: `@scope/pkg` → `%40scope%2Fpkg`.
For an application that publishes no package, read the manifest directly and resolve each declared dependency.
## Step B - map packages to repositories and maintainers
```
https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{NAME}/versions/{VERSION}
```
Take `relatedProjects` where `relationType` is `SOURCE_REPO`. Then **deduplicate by owner, not by package** - a single maintainer often stands behind a dozen dependencies, and the sponsorship decision is per maintainer. Deduplication is what produces the actionable minimum: the fewest destinations covering the most dependencies.
Batch requests (about ten at a time) and skip packages with no resolvable repository, counting them as unresolvable rather than dropping them silently.
## Step C - pull health and criticality signals
```
https://api.deps.dev/v3/projects/github.com%2F{owner}%2F{repo}
```
Returns the project's security-scorecard checks plus stars, license and open-issue count. The **Maintained** check (0-10) is the liveness proxy:
| Score | Read as |
| ----- | ----------------------------------------- |
| 7-10 | Actively maintained |
| 4-6 | Partially maintained - ask before funding |
| 0-3 | Likely dormant - money changes nothing |
For ecosystem-level importance, the open criticality-score dataset rates projects from 0 (least critical) to 1 (most critical) using ten weighted signals:
- Project age.
- Update recency.
- Contributor count.
- Organizational diversity of contributors.
- Commit frequency.
- Release cadence.
- Issue-closure and comment activity.
- Dependents count.
It is published as a public dataset and is explicitly designed to prioritize where support goes.
Fragility is the inverse read of the same data: few contributors, one dominant organization, and a high dependents count is exactly the profile where a sponsorship changes an outcome.
## Step D - find and verify funding destinations
Check in this order, once per owner:
1. **Repository funding manifest** - `.github/FUNDING.yml` on the default branch.
2. **Owner-level fallback** - `{owner}/.github` → `FUNDING.yml`, which applies to every repository of that owner that has none of its own. Look each owner up once and reuse the result.
3. **Registry metadata** - the package registry's own funding field, which may be a string, an object with a `url`, or an array.
4. **The project's site or docs**, when the first three come back empty.
Manifest keys map to destinations directly:
- A sponsorship-platform username.
- A collective slug.
- A coffee/tipping handle.
- A dependency-share handle.
- Up to four custom URLs.
**Verify every destination before it enters the list.** Fetch each URL:
- A live page is included.
- A 404 or a "not enrolled" page is excluded.
- A redirect is followed and the final URL recorded.
Never present a funding link from model memory; funding pages change, and paying into a stale destination fails silently.
A project with no verified destination is not a target. It may still deserve support in kind - contribution time, CI credits, hosting, security review - and belongs in a separate list, framed as an opportunity rather than a failing. Many maintainers do not want money.
## Step E - collect reach signals (manual)
No API exposes placement value. Collect per candidate:
- Traffic on the surface the tier grants (README, docs site, project homepage, a curated list). Maintainers who sell placement usually publish or will share these numbers - one well-known maintainer prices tiers against published monthly view counts of 60k, 20k and 6k on specific lists.
- Package download or install volume as an audience-size proxy.
- Owned channels: newsletter, chat community, conference presence.
- **Audience alignment**: do this project's users look like your buyers, or your future hires? A small project whose audience is exactly your ICP beats a large project whose audience is not - the same test creator programs apply to influencers, and it matters more than raw size.
## Scoring rubric
The axes and weights below are defaults written for this skill, not a published rubric - present them as a proposal and let the user change them. What matters is that the primary mandate is the thing that breaks ties, and that the weights are written down before the candidates are scored rather than after.
1. Score each candidate 1-5 on four axes.
2. Weight them against the mandate.
3. Record the number so the shortlist can be re-derived next year.
| Axis | Question | Weight if supply chain | Weight if reach |
| ------------------ | ----------------------------------------------------------- | ---------------------- | --------------- |
| Exposure | How much of our stack depends on it? | ×3 | ×1 |
| Fragility | How close is this to one person stopping? | ×2 | ×1 |
| Audience fit | Do its users look like our buyers or hires? | ×1 | ×3 |
| Relationship value | Would we want this maintainer reachable during an incident? | ×2 | ×1 |
Payability is a filter, not an axis. Health below the dormancy threshold is also a filter - fund a dormant project only as an explicit revival bet, with the maintainer's agreement.
## Worked shortlist
| Project | Deps covered | Maintained | Fragility | Audience fit | Destination (verified) | Amount/yr | Mandate |
| --------------------------------- | ---------------------------- | ---------- | ---------------------------- | ------------------------------- | ----------------------------------------- | ------------- | ---------------------------------------------------------- |
| CLI framework used in our SDK | 14 (1 direct, 13 transitive) | 9 | 5 - one maintainer | 4 - our SDK users read its docs | sponsorship platform, personal account ✅ | $6,000 | Reach + supply chain |
| Crypto library in the auth path | 3 direct | 8 | 4 - two maintainers | 2 | fiscal-host collective ✅ | $12,000 | Supply chain |
| Log-parsing utility | 22 transitive | 5 | 5 - one maintainer, sporadic | 1 | sponsorship platform ✅ | $120 ($10/mo) | Supply chain (breadth) |
| Data-viz library on our docs site | 2 direct | 9 | 2 - vendor-backed | 5 | none found ❌ | - | Disqualified: no destination; propose contribution instead |
Amounts sit on the maintainer's published ladder wherever one exists; the $12,000 line is a custom amount agreed by invoice because the library is load-bearing for the product. Both tables are illustrative: the projects are composites, and the numbers show the shape of a defensible row rather than a benchmark to hit.
## The same shortlist done badly
The common failure is not laziness - it is a list that looks rigorous and measures the wrong things.
| Project | Stars | Why we picked it | Amount/yr |
| --------------------- | ----- | --------------------------------------- | --------- |
| Popular web framework | 78k | Everyone knows it; great logo placement | $25,000 |
| Language runtime | 91k | Critical to us | $20,000 |
| Testing library | 34k | Our staff engineer likes it | $5,000 |
Four things are wrong with it, in order of cost:
1. **Stars rank popularity, not exposure or fragility.** None of these rows says how much of the company's stack depends on the project, or how close it is to one person stopping.
2. **The three biggest recipients are already funded.** Two are backed by a corporate parent or a foundation with paid staff; the marginal effect of the money is close to zero, and a pledge-style accounting would question whether the largest line counts at all.
3. **No destination was verified.** "Great logo placement" names no surface, no traffic and no tier that grants it.
4. **The long tail is missing entirely.** The single-maintainer packages carrying 22 transitive dependencies each - where $10/month is genuinely load-bearing - never entered the list, because they have no stars to sort by.
The fix is not more diligence on these three rows. It is starting from the dependency graph instead of from recall.
## Disqualifiers
- **Vendor-owned project.** A sponsorship is a rounding error to a funded company and buys nothing.
- **Employee-maintained project**, when the program has a conflict-of-interest rule.
- **Subscription-only recipient**, when the budget pays one-off amounts.
- **Dormant project** with no revival plan agreed with the maintainer.
- **Live conduct or security controversy.** The brand attaches to the sponsee, and the sponsorship page is public.
- **License or governance conflict** with the company's own policy.
SKILL.md›
---
name: oss-sponsors-brand-strategy
description: Builds a company's open-source sponsorship portfolio - which projects and maintainers to fund, through which allocation model, at what amount each, and how to prove it worked. Use whenever a company, OSPO, DevRel lead or engineering leader asks which open-source projects to sponsor, how much to budget for open-source funding, whether sponsoring maintainers is worth it, how to run an employee-nominated FOSS fund, how to fund dependencies at scale, how to pick a sponsorship tier on a maintainer's ladder, or how to measure the return on money paid to maintainers - even if they only say they want to give back. Not the maintainer side of raising sponsorship - use samber/developer-relations-skills@oss-sponsors-fundraising. Not event sponsorship.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# OSS Sponsors Brand Strategy
You decide where a company's open-source money goes: what mandate it serves, which projects and maintainers receive it, how much each one gets, and what the company can honestly claim in return.
Hold two facts through every step:
- Sponsorship returns on two axes at once: "brand marketing, and securing our supply chain," in Sentry's David Cramer's words on the Open Source Pledge member page. The two mandates select different projects, so a portfolio that never picks a primary one optimizes for neither.
- Developer audiences read sponsorship as a signal about the company. Money that arrives with expectations of influence costs more trust than it buys.
Route the user elsewhere when this is the wrong table:
- A maintainer looking for sponsors → `samber/developer-relations-skills@oss-sponsors-fundraising`.
- Conference, meetup or hackathon sponsorship tiers → `samber/developer-relations-skills@developer-event-sponsorship`.
Every figure below carries one of two labels:
- **(published)**: a program that ran disclosed it. Figures drift, so re-check before quoting.
- **(self-set)**: this skill offers it as a starting default, never a market rate.
See [references/sourced-numbers.md](./references/sourced-numbers.md) for the source behind each figure. Never present a self-set default to a finance reviewer as a market rate; that is the claim that gets a portfolio sent back.
## Interview
Ask one question at a time, multiple-choice where you can, and stop once you know the mandate, the budget and the ecosystem. Confirm the rest as the portfolio takes shape.
**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. Who is asking, and whose budget pays - open-source program office, DevRel/marketing, engineering or security leadership, or a founder?
2. What do you want this money to change: reduce supply-chain exposure, earn reach and credibility with developers, engage your own engineers, or meet a values commitment you have already made publicly? Rank your top two.
3. How much per year, and how many developers do you employ? Is the budget new or moved from an existing line?
4. By what date does this have to be live and showing something - this budget cycle, next one, no deadline?
5. Do you want a one-off win (an announcement, a single funded project, a pledge signature) or a compounding asset that is stronger in three years?
6. What is your effort ceiling: who administers this, for how many hours a month, and would you sign a multi-year agreement you cannot exit early?
7. Do developers buy or choose your product, or do you sell to someone else? (This decides whether reach is a marketing return or an employer-brand return.)
8. Which ecosystems is your stack in, and do you have an SBOM, a lockfile, or a repository I can resolve dependencies from?
9. What is already live - sponsorships, foundation memberships, a public pledge, a one-off donation someone made two years ago?
10. What does finance require: card payment or purchase order only, invoice minimums, vendor onboarding, restricted geographies?
11. Should employees participate - nominating projects, voting, contributing on work time?
12. What are the redlines: licenses, projects run by competitors, projects maintained by your own staff, anything legal has flagged?
13. Who reviews this, and when is your budget decided each year?
Answers 4, 5 and 6 re-rank step 2's model menu; carry them there instead of re-asking:
- Answer 4 (deadline inside this budget cycle): promotes breadth, the only model that goes live without a per-project decision.
- Answer 5 (compounding mandate): promotes depth and foundation membership, both worth more in year three than in year one.
- Answer 6 (effort ceiling of a few hours a month): deletes the employee-nominated fund.
- Answer 6 (refusal to sign a multi-year agreement): deletes foundation membership.
If your harness has persistent memory, store the resulting mandate, budget split and target list. Sponsorships renew annually and the next session must not re-derive the portfolio from scratch.
## Step 1 - Name the mandate before the money
Pick one primary mandate and one secondary. The primary breaks every tie later - which project wins the last $5,000, and which metric decides renewal.
| Mandate | Usually owned by | Default allocation model | What renewal is judged on |
| ------------------------ | ----------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------- |
| Supply-chain assurance | Engineering or security | Breadth across the dependency graph | Coverage of fundable dependencies; reachability of maintainers |
| Reach and credibility | DevRel or marketing | Depth on a few projects your buyers already use | Verified placements; referral traffic; unaided mention |
| Internal engagement | OSPO or people team | Employee-nominated fund | Employees contributing; nominations per cycle |
| Public values commitment | OSPO or leadership | Whatever the commitment names - a per-developer floor, foundation dues | The commitment's own terms: floor met, annual report published |
Keep the last two rows apart even though they often share an owner:
- An engagement mandate targets projects your employees already touch.
- A values mandate targets whatever the public commitment named, judged on that commitment's own terms.
Do not rank the mandates against each other. They are four different goals, not four routes to one, and the answer to the interview's second question picks the primary outright - a ratio here would be false precision dressed as analysis. The allocation models in step 2 are routes to whichever mandate wins, and those do get ranked.
Reach behaves differently depending on who buys the product:
- Developers choose or influence the purchase: placement on a project's README, docs or homepage is a media buy and can be priced like one.
- The company sells to non-developers: reach mostly returns employer brand and recruiting. Say that plainly and size the budget against hiring, rather than inflating a marketing case nobody will believe at review time.
## Step 2 - Brainstorm the portfolio shape, then choose one
Enter brainstorming mode before naming a single project:
1. Sketch two or three candidate portfolios, each with its allocation split, the internal work it takes to run, and what it deliberately fails at.
2. Recommend one, and explain why the others lose.
3. Get explicit agreement before building any target list.
The four models - with the numbers real programs published - are in [references/allocation-models.md](./references/allocation-models.md). They are ranked here by value returned per unit of internal effort, effort meaning administrator hours, procurement and legal review, per-project decisions that recur every year, and how hard the commitment is to exit. Say the efficiency order out loud rather than leaving it implied by row order; each line below is descending on its own axis, highest first.
- efficiency: `breadth > depth > foundation membership > employee-nominated fund`
- value (what the model buys at its best): `depth > employee-nominated fund > foundation membership > breadth`
- effort: `employee-nominated fund > depth > foundation membership > breadth`
- compliance cost: `foundation membership > depth > employee-nominated fund > breadth`
Effort in magnitudes:
- Breadth: near-zero once the resolver runs.
- Foundation membership: a quarter of procurement and legal, then near-zero.
- Depth: about a week per project to select, clear and brief, plus a renewal conversation every year.
- Employee-nominated fund: a standing job - a cycle to run, eligibility to check, a vote to administer, a result to communicate.
- **Breadth**: small automatic amounts across the whole dependency graph. Near-zero discovery cost, near-zero visibility. Default first motion unless step 1's mandate table names another one for the primary mandate.
- **Depth**: a short list funded at amounts a maintainer can plan around. Buys the only named maintainer relationship and the only verifiable placement in this menu.
- **Foundation or consortium membership**: dues to an organization that redistributes. Buys governance access, no individual relationship.
- **Employee-nominated fund**: a fixed amount per cycle, nominated and voted internally. Buys engagement and a defensible selection story, targets poorly. This one has a published method to point at - the FOSS Contributor Fund, documented by Duane O'Brien and Mandy Grover (_Investing in Open Source: The FOSS Contributor Fund_, O'Reilly, 2021).
- Read the compliance-cost line as the review triggered and the reversibility spent:
- Membership: signs a multi-year agreement legal has to review; the company cannot quietly exit.
- Depth: onboards each maintainer as a supplier (tax forms, sanctions screening, invoiced billing terms); a public sponsorship is embarrassing to drop.
- Employee-nominated fund: needs a published eligibility and conflict-of-interest rule plus employee disclosure, but no third-party contract.
- Breadth: card-paid through one platform and reviewed once.
- What this order starves: the employee-nominated fund. It tops the effort line and buys the one return no other model buys at all, so the ratio puts it last every round and a program that only obeys the efficiency line will never have an engaged engineering organization behind it. Promote it above everything when internal engagement is the primary mandate from step 1 - the ratio cannot select it, because the thing it buys does not appear on any other row.
- Delete rather than demote, and say which:
- Finance that pays only by purchase order against an invoice minimum deletes breadth, unless a fiscal host or platform aggregator can bill the whole motion on one invoice - a $10/month sponsorship never clears a purchase order.
- No employee participation on work time deletes the nominated fund.
- No foundation governing anything in the stack deletes membership; joining one for adjacency is dues paid for a room nobody in the company sits in.
- Most working programs run breadth plus one other motion. Recommend a single model only when the budget is too small to split meaningfully.
- 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 company before presenting it:
- An OSPO already running a nomination cycle promotes the fund, because the standing cost is already paid.
- A live foundation membership promotes depth inside that foundation's projects.
- Buyers who are themselves developers promote depth, since placement becomes a media buy rather than a gesture.
## Step 3 - Size the budget
Quote both per-head figures, because they say different things:
- The industry pledge asks members for more than **$2,000 per full-time-equivalent developer per year** (published) - a floor for a company that wants to say it funds open source, not a market rate.
- The one company that published what it actually paid reported **$3,700 per developer**, calling it "quite reasonable compensation for the value we receive" (published - a single self-reported data point).
The gap between them is the argument for going above the floor.
Then split the budget:
- A percentage to breadth.
- A percentage to depth or the nominated fund.
- A reserve of 10-20% (self-set) for opportunistic funding - a maintainer in trouble, an incident response, a project that suddenly becomes load-bearing.
Check the split against payment mechanics before publishing it, since invoiced corporate payments carry minimums that a $10/month sponsorship cannot clear (see step 7).
Decide what counts before you publish a total. A pledge-style program refuses to count four payment categories as open-source funding (published):
- Money to a company-controlled project.
- Software that benefits the payer exclusively.
- A maintainer the company already employs.
- An arrangement returning substantial benefits beyond minimal acknowledgment.
Budgets get padded with all four; count them on a separate line, or the public number will not survive scrutiny.
## Step 4 - Build the candidate list
Do the mechanical half of discovery first - it is cheap, and it usually surprises the room. If your environment can fetch URLs and read the company's manifests:
1. Resolve the full dependency tree, direct and transitive, from a lockfile, an SBOM, or a public dependency-resolution API.
2. Map each package to its source repository, then deduplicate - one maintainer often stands behind a dozen packages.
3. Pull health signals per repository: maintenance activity, contributor count and organizational diversity, release cadence.
4. Discover a funding destination for each: the repository's funding manifest, the owner's org-level fallback, and registry funding metadata.
5. **Verify every funding link resolves** before it enters the list. Funding pages 404 and maintainers leave programs; never carry a funding URL from memory.
Every row of the list is a claim about someone else's project that the company will publish money against. Four rules keep it honest, each one a failure that hand-collected dependency lists produce:
- **Measure, never estimate.** Download counts, maintenance activity and maintainer counts all have APIs. Hand-collected figures have claimed five-plus maintainers for a package whose registry publish rights list one, and zero downloads for a package moving 164 million a week.
- **Score fragility on publish rights, not repository contributors.** They are different populations - fragility depends on who can ship a release, not on who has ever merged a commit - and the contributor graph overstates the count.
- **Mark what you could not assess.** Every candidate resolves to assessed-fine, assessed-flagged, or not-assessable-with-a-reason. Some registries publish no maintainer list at all; a row with missing data is not a clean row.
- **Carry the denominator.** Report "resolved 412 of 470 dependencies; 58 had no source repository", never a bare percentage - coverage of a total nobody defined survives no audit.
The exact endpoints, manifest paths, fallback rules and scoring inputs are in [references/target-discovery-and-scoring.md](./references/target-discovery-and-scoring.md). If your environment cannot browse, ask the user to export a dependency list and work from it, and say which health signals you could not check.
The judgement half has no API: which projects reach the audience you want, on what surface, at what volume. Ask the maintainer for placement traffic when it matters - the maintainers who sell placement usually publish or share those numbers.
## Step 5 - Rank the list, then cut it
Score each candidate on four axes:
- Exposure: how much of your stack depends on it.
- Fragility: how close it is to one person stopping.
- Audience fit: do its users look like your buyers or your future hires.
- Relationship value: would you want this maintainer's phone number during an incident.
The four axes and their mandate weights are self-set; say so, and let the user reweight them. Payability is not a score: a project with no way to receive money is out, however critical, and is instead a candidate for contribution rather than cash.
Then cut hard. A portfolio is only as good as the annual review it can survive; twelve depth sponsorships that get renewed thoughtfully beat forty that get rubber-stamped (self-set). For the breadth motion, report the actionable minimum - the fewest destinations that cover the most dependencies.
Flag the disqualifiers explicitly rather than silently dropping them:
- Vendor-owned projects where the money is a rounding error.
- Projects maintained by your own employees, if you have a conflict-of-interest rule.
- Projects that can only take a support contract when your budget pays one-off.
- Anything with a live conduct or security controversy the brand would attach to.
## Step 6 - Set the amount per target
Take amounts from the maintainer's published ladder, never from a number that felt right. Read what each tier actually grants, then pick the tier that matches the mandate:
- **Supply-chain targets**: the smallest recurring amount is usually correct across many projects; coverage is the goal, not prominence.
- **Reach targets**: pick the tier whose placement is on a surface with real traffic, and price it against that audience. A logo in a backers file nobody opens is not a media buy at any price.
- **Strategic targets**: go above the ladder with a custom or invoiced amount when the project is load-bearing for your product. One program's published depth allocations ran from $1,750 to $15,000 per project per year (published) - the spread is the lesson; depth does not mean uniform.
Check two constraints before promising anything:
- A tier's rewards are recurring work for one person; never request a benefit the maintainer will resent in six months.
- Fund a foundation instead of an individual, when the project's governance already routes money that way.
## Step 7 - Clear procurement before announcing anything
Check the payment path before any target list is final - a portfolio designed around payments finance cannot make is dead on arrival. The figures below come from platform billing documentation and fiscal-host fee schedules; re-check before quoting. Sources and the full rules are in [references/allocation-models.md](./references/allocation-models.md).
- Invoiced corporate billing on the main sponsorship platform has a **$5,000 minimum per invoice**, payable in 30 days, with a 3% service fee and a 3-year agreement term. Below that minimum, the company pays by card or routes money through a fiscal host instead.
- **Switching an organization to invoiced billing cancels its existing sponsorships**, which then have to be re-established. Sequence the switch before the first sponsorship, never after.
- Fiscal hosts take a percentage (commonly 3-10%) and publish a ledger, so every payment is visible.
- Vendor onboarding, tax forms and sanctions screening apply to individual maintainers exactly as they do to suppliers - start that paperwork before you promise a date.
- Whether the spend books as marketing, engineering or charitable giving changes its tax treatment and its approval path. Route that question to the company's finance and legal teams; state the options, never give the answer.
## Step 8 - Publish the policy and the conduct rules
Write these down before the first payment, and publish them where maintainers and employees can read them. An unpublished policy reads as favouritism from the outside.
- Sponsorship buys visibility, sustainability, and a relationship - never roadmap position, merged pull requests, or priority outcomes. Priority triage can be negotiated; priority outcomes cannot.
- No pressure on a maintainer to accept money, to advertise the sponsorship, or to produce gratitude on a schedule.
- Employees who publicly advocate for a project the company funds disclose the relationship.
- State the eligibility and conflict-of-interest rules: which projects qualify, whether employee-owned projects are excluded, who decides, and how a decision is appealed.
- Never shame a project that has no funding link or declines the money. Some maintainers refuse funding deliberately to protect their autonomy.
- Say whether a sponsorship is recurring or one-off. A sponsorship silently dropped at budget close does more relationship damage than one that was never started.
The full policy skeleton and a nomination-process template are in [references/policy-and-measurement.md](./references/policy-and-measurement.md).
## Step 9 - Measure, review, renew
Attribution is weak by nature: nobody clicks a README logo and buys. Measure presence and relationship health instead, per mandate, and refuse to build a last-click case that will not survive its first audit.
| Mandate | Measure | Ignore |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| Supply chain | Share of fundable dependencies covered; dormant-dependency count; response time on issues you file | Total dollars given |
| Reach | Placements live and verified; referral traffic from placement URLs; unaided mentions in developer surveys and community threads | Impressions estimated from stars |
| Internal | Employees contributing per cycle; nominations submitted; participation rate | Fund size |
**Pass threshold** (self-set), checked at 12 months and then annually:
- Every placement you paid for is live and verified.
- At least 80% of fundable direct dependencies are covered, if supply-chain is the primary mandate.
- Every depth sponsee has at least one documented interaction beyond the payment.
- No policy breach was raised by a sponsee.
- A renewal decision was made for every target before budget close.
Iterate on the portfolio until it passes, then re-run the check each year. On the 80% line, the only company to publish a higher coverage number reported "95% or greater" and described itself as the first to approach 100% (published, self-declared); present anything above 80% as ambitious, not standard.
Publish a short annual report of where the money went. The pledge's published format is the cheapest one to copy (published): the year, the developer count, the total paid, and the amount per recipient. It is the part maintainers and developers actually read, and re-publishing it each year is what turns a one-off into a program.
## Invocation examples
A tier question asked in isolation is usually a mandate question nobody has asked yet. Answer the narrow question the user brought, then say which step of the portfolio it belongs to and offer the rest.
| What the user says | Where to start | What comes back |
| ----------------------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| "We have $80k for open source next year. Where should it go?" | Interview, then step 1 | The full portfolio brief below |
| "Should we sponsor <project> at the $500 or the $2,000 tier?" | Step 6, after one question about the mandate | The tier that matches the mandate, the surface it lands on, and the traffic question to send the maintainer |
| "Our CTO wants a FOSS fund like the one at <company>. Set it up." | Step 2, then the nomination rules | The nominated-fund design: amount per cycle, eligibility filters, who nominates, who votes |
| "Which of our dependencies can we even pay?" | Step 4 only | A verified destination list deduplicated by maintainer, plus the count of dependencies each one covers |
| "Legal wants to know what we get for this." | Step 8 and step 9 | The policy language on what sponsorship does not buy, and the metrics per mandate |
Say what you could not check. "Resolved 412 of 470 dependencies; 58 had no source repository" is a usable answer. A clean-looking list with a silent gap in it is not.
## Deliverable
Produce a portfolio brief, presented section by section with agreement on each before moving on.
```markdown
# Open-source sponsorship portfolio - <company>, <year>
## Mandate primary and secondary, and what breaks ties
## Budget total, per-developer check, split by model, reserve
## Model chosen allocation model(s) and what they deliberately fail at
## Targets ranked table: project, why, exposure, amount, destination, verified
## Amounts per target with the tier it buys and the surface it lands on
## Procurement payment path, minimums, paperwork status, owner
## Policy what sponsorship does not buy, eligibility, conflicts, disclosure
## Measurement metrics per mandate, review date, pass threshold
## Renewal decision date, what would end each sponsorship
```
## Common failure modes
- **Funding the famous project instead of the fragile one.** Nomination votes and gut feel both drift toward projects that already have money; deliberately surface the underserved ones.
- **Announcing before procurement clears.** A promised sponsorship stuck behind vendor onboarding for four months is a broken promise in public.
- **Switching billing after sponsoring.** The switch cancels live sponsorships, and maintainers receive a cancellation email that reads as a withdrawal.
- **Buying a placement nobody sees.** A tier chosen by name rather than by the surface and traffic it grants.
- **Asking for influence.** The fastest way to convert a trust asset into a story about a company buying open-source projects.
- **Sponsoring a dead project.** No commits in eighteen months means the money changes nothing; check maintenance signals before, not after.
- **One-off giving dressed as a program.** A single announcement with no renewal date reads as a marketing stunt to the exact audience it targeted.
- **Unverified funding links.** Paying into a stale destination, or listing a maintainer who left the platform, wastes the budget silently.
## References
- [references/sourced-numbers.md](./references/sourced-numbers.md) - every figure this skill uses, split into published and self-set, each with its source. Read before quoting any number.
- [references/allocation-models.md](./references/allocation-models.md) - the four models with published numbers, a worked budget split, payment mechanics and minimums, and a weak portfolio diagnosed line by line.
- [references/target-discovery-and-scoring.md](./references/target-discovery-and-scoring.md) - dependency resolution and health endpoints, funding-link discovery and verification, the scoring rubric, and a worked shortlist next to the star-ranked one it replaces.
- [references/policy-and-measurement.md](./references/policy-and-measurement.md) - the public policy skeleton, nomination process, annual report shape, a good and a bad outreach note, and the measurement table's layout.
- `samber/developer-relations-skills@oss-sponsors-fundraising` - the maintainer side of the same transaction.
- `samber/developer-relations-skills@developer-event-sponsorship` - conference and hackathon sponsorship.
- `samber/developer-relations-skills@oss-governance` - how a funded project's governance routes money.
- `samber/developer-relations-skills@build-in-public` - publishing the annual report the program produces.
- `samber/developer-relations-skills@open-source-company-strategy` - the company-side gates this funding decision has to clear.
- `samber/developer-relations-skills@devrel-budget-allocation` - the line item this sponsorship program draws against.