Oss Sponsors Brand Strategy

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 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.

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. 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