公司开源赞助组合策略：决定资助哪些项目、用哪种分配模式…

当公司、OSPO、DevRel 或工程负责人需要制定开源赞助组合（资助哪些项目与维护者、预算多少、如何衡量回报）时使用。

适用场景

解决思路

1. 先做访谈，每次只问一个问题，尽量用多选题，直到弄清授权目标（mandate）、预算和生态后再停止；其余信息随组合成形再确认。访谈问题包括：谁在问、谁出预算（OSPO、DevRel/市场、工程或安全负责人、创始人）；这笔钱想改变什么（降低供应链风险、赢得开发者触达与信誉、让自家工程师参与、履行已公开的价值观承诺），并排出前两名；每年多少钱、雇多少开发者、预算是新增还是从既有科目挪来；何时必须上线并见效（本预算周期、下个周期、无期限）；想要一次性成果（公告、单个资助项目、签署承诺）还是三年后更强的复利资产；投入上限：谁管理、每月多少小时、是否愿签无法提前退出的多年协议；开发者是购买/选择你的产品，还是你卖给非开发者（这决定触达是营销回报还是雇主品牌回报）；你的技术栈在哪些生态、是否有 SBOM、lockfile 或可解析依赖的仓库；已有哪些在运行（赞助、基金会会员、公开承诺、两年前的一次性捐赠）；财务要求（只能刷卡还是必须采购订单、发票最低额、供应商入驻、受限地区）；是否让员工参与（提名项目、投票、工作时间贡献）；红线（许可证、竞争对手运营的项目、自家员工维护的项目、法务标记的事项）；谁审核、每年预算何时决定。
2. 把访谈答案 4、5、6 带入第 2 步的模型菜单，不要重复询问：答案 4（本预算周期内有截止日期）提升广度模型，因为它是唯一无需逐项目决策即可上线的模式；答案 5（复利目标）提升深度与基金会会员，二者在第三年比第一年更值钱；答案 6（每月仅几小时投入上限）删除员工提名基金；答案 6（拒绝签多年协议）删除基金会会员。
3. 若运行环境有持久记忆，存储得出的授权目标、预算拆分和目标清单；赞助每年续约，下次会话不应从零重新推导组合。
4. 第 1 步——先定授权目标再谈钱：选一个主目标和一本次目标，主目标用于打破后续所有平局（最后一个 5000 美元给谁、哪个指标决定续约）。四类目标：供应链保障（通常归工程或安全，默认用广度覆盖依赖图，续约看可资助依赖的覆盖率与维护者可达性）；触达与信誉（通常归 DevRel 或市场，默认在买家已用的少数项目上做深度，续约看已验证的展示位、引荐流量、无提示提及）；内部参与（通常归 OSPO 或人事，默认用员工提名基金，续约看员工贡献与每周期提名数）；公开价值观承诺（通常归 OSPO 或领导层，默认按承诺本身命名的方式，如每位开发者下限、基金会会费，续约按承诺自身条款：下限是否达成、年报是否发布）。
5. 不要把四类目标相互排名：它们是四个不同目标而非通往同一目标的四条路，访谈第二问的答案直接决定主目标；在此给比例是把虚假精确伪装成分析。第 2 步的分配模型才是通往胜出目标的路线，那些可以排名。
6. 触达的回报因买家而异：若开发者选择或影响购买，在项目 README、文档或首页的展示位就是媒体采购，可按媒体定价；若公司卖给非开发者，触达主要回报为雇主品牌与招聘，应直说并对照招聘规模定预算，而不是在评审时夸大一个没人信的营销案例。
7. 第 2 步——先头脑风暴组合形态再选定一个：进入头脑风暴模式，先不点名任何项目。1）勾画两到三个候选组合，各含分配比例、所需内部工作量、以及它刻意放弃什么；2）推荐其中一个并解释其他为何落选；3）在构建任何目标清单前取得明确同意。
8. 掌握四种分配模型（广度、深度、基金会/联盟会员、员工提名基金）并按效率排序：效率 `breadth > depth > foundation membership > employee-nominated fund`；价值（模型最佳状态下买到什么）`depth > employee-nominated fund > foundation membership > breadth`；工作量 `employee-nominated fund > depth > foundation membership > breadth`；合规成本 `foundation membership > depth > employee-nominated fund > breadth`。要口头说出效率顺序，不要只靠行序暗示。
9. 理解各模型的工作量量级：广度在解析器跑起来后近乎为零；基金会会员需约一个季度的采购与法务，之后近乎为零；深度每个项目约一周用于筛选、审批与简报，外加每年一次续约沟通；员工提名基金是常设工作——每周期运行、资格核查、组织投票、公布结果。
10. 广度：在整个依赖图上做小额自动资助，发现成本近乎为零、可见度也近乎为零；除非第 1 步的目标表为主目标指定了其他模型，否则默认作为第一步动作。深度：一份短名单，金额让维护者可规划，买到本菜单中唯一具名的维护者关系和唯一可验证的展示位。基金会或联盟会员：向再分配资金的组织缴纳会费，买到治理参与权，没有个人关系。员工提名基金：每周期固定金额，内部提名与投票，买到参与度和可辩护的筛选故事，但目标定位差；它有公开方法可参照——Duane O'Brien 与 Mandy Grover 记录的 FOSS Contributor Fund（《Investing in Open Source: The FOSS Contributor Fund》，O'Reilly，2021）。
11. 把合规成本行读作触发的审查与消耗的可逆性：会员需签法务要审的多年协议，公司无法悄悄退出；深度需把每位维护者作为供应商入驻（税表、制裁筛查、开票账期），公开赞助后撤下很尴尬；员工提名基金需公开资格与利益冲突规则及员工披露，但无第三方合同；广度通过一个平台刷卡支付、只审一次。
12. 注意这个顺序会饿死员工提名基金：它工作量最高，却买到其他模型都买不到的回报，因此按比率每轮都排最后，只遵守效率线的项目永远不会有真正参与的工程组织。当第 1 步的主目标是内部参与时，把它提升到一切之上——比率无法选中它，因为它买到的东西不出现在任何其他行。
13. 删除而非降级，并说明删了哪个：财务只接受采购订单且有发票最低额时删除广度，除非财政托管方或平台聚合方能就整个动作开一张发票——每月 10 美元的赞助永远过不了采购订单；员工不能在工作时间参与则删除提名基金；技术栈中没有基金会治理任何东西则删除会员，为邻接关系加入只是为一个公司无人坐的房间付会费。
14. 多数运行中的项目采用广度加另一个动作；只有当预算小到无法有意义拆分时才推荐单一模型。
15. 这个顺序是默认值而非定律，会随情境和执行者变化；呈现前先按你对这家公司的已知信息重新排序：已在运行提名周期的 OSPO 提升基金，因为常设成本已付；已有基金会会员则提升该基金会项目内的深度；买家本身是开发者则提升深度，因为展示位变成媒体采购而非姿态。
16. 第 3 步——定预算规模：同时引用两个每人头数字，因为它们说明不同的事。行业承诺要求会员每年每位全职等效开发者超过 2000 美元（已发布）——这是想宣称资助开源的公司的最低线，不是市场价。唯一公布实际支付额的公司报告每位开发者 3700 美元，称其“对我们获得的价值而言是相当合理的报酬”（已发布——单一自报数据点）。两者之差就是高于最低线的论据。
17. 拆分预算：一定比例给广度；一定比例给深度或提名基金；留 10-20%（自设）作为机会性资金储备——用于陷入困境的维护者、事件响应、突然变成关键负载的项目。
18. 发布前用支付机制核对拆分，因为开票的企业付款有最低额，每月 10 美元的赞助过不了（见第 7 步）。
19. 在公布总额前决定什么算数。承诺式项目拒绝把四类支付计为开源资助（已发布）：给公司控制的项目；只让付款方受益的软件；公司已雇用的维护者；返还远超最低致谢的实质利益的安排。预算常被这四类注水；把它们单列，否则公开数字经不起审查。
20. 第 4 步——构建候选清单：先做发现中机械的一半——它便宜且通常让全场惊讶。若环境能抓取 URL 并读取公司清单：1）从 lockfile、SBOM 或公开依赖解析 API 解析完整依赖树（直接与传递）；2）把每个包映射到源码仓库，然后去重——一位维护者常代表十几个包；3）按仓库拉取健康信号：维护活跃度、贡献者数量与组织多样性、发布节奏；4）为每个发现资助去向：仓库的资助清单、所有者的组织级回退、注册表资助元数据；5）在进入清单前验证每个资助链接可解析——资助页会 404、维护者会退出项目，绝不凭记忆携带资助 URL。
21. 清单每一行都是关于他人项目的声明，公司会据此公开付款；四条规则保持诚实，每条都是手工收集依赖清单会产生的失败：测量而非估算——下载量、维护活跃度、维护者数量都有 API，手工数据曾声称某包有五位以上维护者而注册表发布权只列一人，也曾把每周 1.64 亿下载的包记为 0 下载；按发布权而非仓库贡献者评估脆弱性——它们是不同人群，脆弱性取决于谁能发版而非谁曾合并过提交，贡献者图会高估数量；标记无法评估的——每个候选归为评估正常、评估有风险、或无法评估并附原因，有些注册表根本不发布维护者列表，缺数据的行不是干净的行；带上分母——报告“解析了 470 个依赖中的 412 个；58 个无源码仓库”，绝不给裸百分比——没人定义过总量的覆盖率经不起审计。
22. 判断的一半没有 API：哪些项目触达你想要的人群、在什么界面、多大流量。重要时向维护者索取展示位流量——出售展示位的维护者通常会公布或分享这些数字。
23. 第 5 步——给清单打分再砍：按四个轴给每个候选打分：暴露度（技术栈对它的依赖程度）、脆弱性（离一个人停摆有多近）、受众契合度（其用户是否像你的买家或未来雇员）、关系价值（事件期间你是否想要这位维护者的电话）。四个轴及其目标权重是自设的，要说明并让用户重新加权。可支付性不是评分项：无法收钱的项目无论多关键都出局，改为贡献而非现金的候选。
24. 然后狠砍。组合的好坏取决于它能经受的年度评审；十二个被认真续约的深度赞助胜过四十个被橡皮图章通过的（自设）。对广度动作，报告可执行的最小值——覆盖最多依赖的最少去向。
25. 明确标出取消资格项而非悄悄丢弃：供应商自有项目（钱是舍入误差）；自家员工维护的项目（若有利益冲突规则）；只能接受支持合同而你的预算只付一次性的项目；任何有正在发酵的行为或安全争议、品牌会被牵连的项目。
26. 第 6 步——定每个目标的金额：金额取自维护者公布的阶梯，绝不取自感觉合适的数字。读清每档实际给什么，再选与目标匹配的档：供应链目标通常在许多项目上用最小的经常性金额——覆盖是目标而非显眼；触达目标选展示位落在有真实流量界面的档，并对照该受众定价——没人打开的赞助者文件里的 logo 在任何价位都不是媒体采购；战略目标在项目对产品是关键负载时用自定义或开票金额超出阶梯——某项目公布的深度分配从每项目每年 1750 到 15000 美元（已发布）——差距就是教训：深度不等于统一。
27. 承诺前检查两个约束：某档的回报是某个人的经常性工作，绝不要索取维护者六个月后会怨恨的权益；当项目治理已把资金导向基金会时，资助基金会而非个人。
28. 第 7 步——宣布前先过采购：在任何目标清单定稿前检查支付路径——围绕财务无法完成的支付设计的组合一出生就是死的。以下数字来自平台计费文档与财政托管费率表，引用前重新核对。主赞助平台的开票企业计费每张发票最低 5000 美元，30 天账期，3% 服务费，3 年协议期；低于该最低额，公司刷卡或通过财政托管方走账。把组织切换为开票计费会取消其现有赞助，之后必须重新建立；把切换排在第一次赞助之前，绝不之后。财政托管方抽成（通常 3-10%）并公布账本，因此每笔付款可见。供应商入驻、税表与制裁筛查对个人维护者与对供应商完全一样——在承诺日期前启动这些文书。这笔支出记为市场、工程还是慈善捐赠会改变税务处理与审批路径；把该问题交给公司财务与法务，陈述选项，绝不给答案。
29. 第 8 步——公布政策与行为规则：在首次付款前写下并公布在维护者与员工可读之处；未公布的政策从外部看像偏袒。赞助买的是可见度、可持续性与关系——绝不是路线图位置、被合并的 PR 或优先结果；优先分诊可协商，优先结果不可。不向维护者施压接受金钱、宣传赞助或按时间表表达感激。公开为受资助项目背书的员工须披露关系。说明资格与利益冲突规则：哪些项目合格、员工自有项目是否排除、谁决定、决定如何申诉。绝不羞辱没有资助链接或拒绝收钱的项目；有些维护者刻意拒绝资助以保护自主权。说明赞助是经常性还是一次性；预算关闭时悄悄停止的赞助比从未开始的赞助造成更大的关系伤害。
30. 第 9 步——衡量、评审、续约：归因天然很弱——没人点了 README logo 就购买。改为按目标衡量存在感与关系健康，拒绝构建经不起首次审计的末次点击案例。供应链：衡量可资助依赖的覆盖比例、休眠依赖数、你提交 issue 的响应时间；忽略给出的总金额。触达：衡量已上线并验证的展示位、展示位 URL 的引荐流量、开发者调研与社区讨论中的无提示提及；忽略由 star 估算的曝光量。内部：衡量每周期贡献的员工、提交的提名、参与率；忽略基金规模。
31. 通过阈值（自设），12 个月时检查，之后每年一次：你付费的每个展示位都已上线并验证；若供应链为主目标，至少 80% 的可资助直接依赖被覆盖；每个深度受助者至少有一次付款之外的记录在案互动；受助者未提出政策违规；每个目标在预算关闭前做出续约决定。迭代组合直到通过，然后每年重跑检查。关于 80% 这条线，唯一公布更高覆盖数字的公司报告“95% 或更高”并自称首个接近 100%（已发布，自我声明）；把高于 80% 的任何数字呈现为雄心而非标准。
32. 发布简短年报说明钱去了哪里。承诺的公布格式最省事可抄（已发布）：年份、开发者人数、支付总额、每位受助者金额。这是维护者与开发者真正会读的部分，每年重新发布正是把一次性变成项目的关键。
33. 调用示例：孤立地问某档位通常是还没人问过的目标问题。先回答用户带来的窄问题，再说明它属于组合的哪一步并提供其余部分。用户说“明年我们有 8 万美元用于开源，该花在哪”——从访谈开始再到第 1 步，返回完整组合简报。“我们该以 500 还是 2000 美元档赞助 <项目>”——先问一个目标问题，再到第 6 步，返回匹配目标的档位、落地的界面、以及发给维护者的流量问题。“CTO 想要像 <公司> 那样的 FOSS 基金，搭起来”——从第 2 步再到提名规则，返回提名基金设计：每周期金额、资格过滤、谁提名、谁投票。“我们哪些依赖是能付钱的”——只做第 4 步，返回按维护者去重的已验证去向清单，以及每个覆盖多少依赖。“法务想知道我们得到什么”——第 8 步与第 9 步，返回关于赞助不买什么的政策措辞，以及按目标的指标。
34. 说明你无法检查的内容。“解析了 470 个依赖中的 412 个；58 个无源码仓库”是可用的答案；看似干净却含沉默缺口的清单不是。
35. 产出组合简报，逐节呈现，每节取得同意后再继续，包含：主次目标及打破平局的方式；预算总额、每人头核对、按模型拆分、储备；所选分配模型及其刻意放弃什么；目标排名表（项目、理由、暴露度、金额、去向、已验证）；每个目标的金额及其买到的档位与落地界面；采购支付路径、最低额、文书状态、负责人；政策（赞助不买什么、资格、冲突、披露）；按目标的衡量指标、评审日期、通过阈值；续约决定日期、什么会终止每项赞助。
36. 避免常见失败模式：资助著名项目而非脆弱项目（提名投票与直觉都偏向已有钱的项目，要刻意浮现服务不足者）；采购未清就宣布（承诺的赞助卡在供应商入驻四个月是公开的食言）；先赞助后切换计费（切换会取消现有赞助，维护者收到的取消邮件读起来像撤资）；买没人看的展示位（按名字而非按界面与流量选档）；索取影响力（把信任资产变成公司购买开源项目故事的最快方式）；赞助已死项目（18 个月无提交意味着钱改变不了什么，事前而非事后检查维护信号）；把一次性捐赠包装成项目（没有续约日期的单次公告，对它所针对的受众读起来就是营销噱头）；未验证的资助链接（付给过期去向，或列出已离开平台的维护者，会悄悄浪费预算）。

适用边界 · 注意事项

• 维护者寻求赞助的场景——应使用 samber/developer-relations-skills@oss-sponsors-fundraising。
• 会议、聚会或黑客松赞助档位——应使用 samber/developer-relations-skills@developer-event-sponsorship。
• 没有预算或授权目标、只想了解开源赞助概念的场景。