oss-sponsors-fundraising

开源项目赞助筹款

你负责设计开源项目的赞助计划：向谁提出请求、请求多少、提供什么回报、通过哪个平台，以及如何让维护者两年后仍有能力持续交付。

以下研究结果会影响下文的每一项决策：

• 形成薪资规模的收入来自公司，而非个人：GitHub 报告称，2022 年“近 40% 的赞助资金来自组织”；Filippo Valsorda 测算，一个被广泛依赖的库从个人赞助中获得的典型收入不到每月 1,000 美元。
• 每项承诺的回报都会成为工作，落在已经不堪重负的维护者肩上：Tidelift 的 2020 年调查显示，专业维护者中有 46% 精疲力竭，而广泛使用项目的维护者中这一比例为 58%。

获得报酬也会影响项目能做什么。Tidelift 的 2024 年维护者调查（400 多名受访者）发现，60% 的维护者没有报酬；获得报酬的维护者实施关键安全和维护实践的可能性高出 55%：发布带有来源证明的签名版本的比例为 50%，未获得报酬的维护者为 28%；启用双重身份验证的比例为 76%，未获得报酬的维护者为 68%。当维护者觉得要钱不礼貌时，可以用这些数据来说明情况。

此类数据会在文中或参考文件中标明来源；任何标注为 baseline 的数字都是本技能设定的默认值，仅供讨论的起点，绝非行业标准。

如果用户是正在决定资助哪些项目、选择什么档位的公司，那么他们找错了对象——请引导他们前往 samber/developer-relations-skills@oss-sponsors-brand-strategy，然后停止。

访谈

一次只问一个问题，尽可能采用选择题，并在确认项目、目标金额和实际交付能力后立即停止。其余内容在设计方案时再确认。

记忆：记录当前任务或项目背景中的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用其他记忆系统，则沿用该系统。将不同任务的信息放在不同的章节中。完成的任务要删除。为任务添加日期；一般项目背景无需添加日期。有些访谈回答可能因任务而异。

1. 是哪个项目？你的角色是什么——唯一维护者、团队成员，还是利用工作时间维护项目的公司员工？
2. 你希望这笔钱带来什么改变：买回一些时间、支付基础设施费用、资助某项具体交付，还是替代工资？请说出一个月度金额，估算也可以。
3. 这笔钱最晚何时必须开始到账——本季度、今年内，还是没有截止日期？
4. 你想要一次性收益（资助某项交付、会议差旅费、硬件费用），还是希望打造一项两年后仍能带来收入的复利资产？
5. 实际上是谁在使用它——个人开发者、基于它构建产品的公司，还是两者都有？你怎么知道？
6. 你能说出三家依赖它的公司吗？你怎么知道它们依赖它？
7. 目前已经有哪些支持渠道：GitHub Sponsors、Open Collective、Ko-fi、FUNDING.yml，还是都没有？
8. 你能投入多少精力？在最忙的月份，每月最多能投入多少时间来处理赞助相关事务——请说小时数，而不是意愿。你愿意作出无法撤回的承诺吗？
9. 你有法人实体吗？还是由你个人收款？在哪个国家？
10. 你能掌控哪些渠道，大致数据如何：代码仓库流量、文档站点、新闻简报、社交媒体粉丝数、会议演讲？
11. 目前是否已经有任何商业安排——付费支持、托管产品，或声称对这项工作享有权利的雇主？
12. 无论出价多少，有什么是你拒绝出售的？

回答 3、4 和 8 会重新排列步骤 2 中的方案类型菜单——把这些答案带到那里，不要再次询问：

• Q3，如果截止日期在本季度内：优先考虑感谢和曝光方案，这是仅有的在建成前就能带来收入的方案。
• Q4，如果目标是打造复利型资产：优先考虑长期赞助和曝光位，这两者在发布推广结束后仍能持续带来收入。
• Q8，如果最忙的月份也只能投入几个小时：删除访问计划。
• Q8，如果拒绝签署任何无法撤回的承诺：删除长期赞助。

记录答案。如果你的运行环境支持持久记忆，请将最终的项目方案简报存入其中；在某些平台上，档位价格实际上是永久固定的，因此后续会话不能从头重新设计赞助层级。

第 1 步 - 判断赞助是否真的是合适的手段

赞助是五种资金来源之一，opensoure.guide 列出了自己的清单：

• 就业：将开源工作纳入工作职责。
• 个人众筹。
• 项目级企业赞助。
• 商业收入：支持服务、托管、高级功能。
• 资助。

个人赞助也是实现足以维持生计的收入最慢的途径：即使是广受依赖的代码库，通常也只能获得上文所述的每月不足 $1,000。

在设计任何内容之前，请直言不讳地说明：

• Q2 = “替代一份工资”，且项目只有几百名用户：建议选择就业或商业层级，并将赞助作为补充——尽管这并非此技能的构建目标。
• Q2 = 每周买回一天时间或承担开支：赞助很合适。

以同样的方式考虑资助：具有研究、基础设施或安全方向的项目，往往比一百位每人赞助 $5 的赞助者更快获得资助。如果符合这种情况，请同时运行第 1b 步。

此处不要按效率对这五种资金来源进行排名：选择题 Q2 已经做出的选择，再对其进行排名只会造成虚假的精确性。替代工资的目标无论寻找成本如何，就业都是首选；具有基础设施或安全方向的项目，资助则是首选，而且无论投入多少精力，这两个结论都成立。资助渠道内的项目以及赞助形式，则确实需要排名。

步骤 1b - 运行资助渠道

资助并不是金额更高的赞助，而是一份有固定期限的合同：前有资格门槛，后有报告义务；合同在指定日期结束，款项则依据证明支付。应将其作为赞助计划的补充，而非替代。

先确认资格，再动笔。四项门槛导致的申请被拒数量，超过文笔欠佳造成的拒绝；面试回答 9 已经说明了其中两项：

• 许可。 每个计划都要求采用认可的开源许可证，有些还要求文档和研究成果也采用该许可证。
• 可获付款的对象。 有些与个人签约，有些要求申请者具备法人实体身份，有些只向组织付款，并要求没有所属组织的项目找到财政赞助方。
• 地理限制。 限制针对的是收款方，而不是代码：居住地偏好、国家税务居民身份、制裁排除项。
• 成熟度与范围。 基础设施基金希望资助已有依赖方的库，不接受原型；原型基金希望支持新项目；科学基金则要求证明项目已在其所属领域得到应用。

各类计划按申请和合规工作的每小时获资金额排序。可分为五类：向个人付款的直接资助、安全领域的群组资助、基础设施领域的机构资助、国家级创新基金，以及基金会科学资助。

• 效率：direct > cohort > agency > national > foundation
• 价值（每笔资助的金额）：foundation > agency > national > direct > cohort
• 工作量：foundation > national > agency > direct > cohort - 基金会要求提交意向书、受邀后提交申请书，并取得机构签字；机构资助从申请到签约要等数月；直接资助只需填写一份表格
• 合规成本：national > foundation > agency > cohort > direct

这种排序会让什么得不到关注：基金会资助，而它们是唯一会资助多年指定人力的来源。如果项目已有机构依托或财政赞助方，应提高其优先级；如果两者都没有，则应将其排除。

写给评审委员会，而不是赞助页面的读者。步骤 5 是向已经看好项目的读者展现维护者的可信度；申请书则要由评审人员依据公开标准评分，而他们往往一次要审阅几十份申请。

• 先讲项目被依赖的情况，而不是项目故事。项目普及程度、关键性，以及项目停止时哪些人会受影响，都是评分标准。
• 按明确的费率计算工作小时数，再将这些小时数对应到你愿意据此收款的里程碑，因为实际付款时确实会如此。
• 明确回答“为什么不使用现有方案”。公开申请表会直接提出这个问题；没有回答会让人觉得你没有研究过现有方案。

接受资助前，先规划报告工作。赞助方可能因一篇感谢帖而续约，也可能悄然停止合作；资助方则会按固定时间表要求提交指定报告，并扣留相应款项，还会收回未支出的资金。应将这项管理工作计入问题 8 中的工作量上限。

各计划的门槛、申请字段、评分标准、获资助后的义务，以及不再接受申请的计划，详见 references/grant-programs-and-reporting.md。向用户提及任何计划前，请先阅读该文件。

步骤 2 - 构思计划形式，再选定一个

进入头脑风暴模式。构思两到三个候选计划，看看哪些能达到指定金额，然后推荐一个，并说明其他方案为何不如它。确定价格前，先取得明确同意。

这四种形式按单位维护者工作量所能换回的价值排序；工作量指反复投入的维护者小时数、永无止境的义务，以及撤回已公开承诺的难度。应明确说出效率排序，而不是让读者从行序自行推断。这些维度的排序并不一致，因此要逐项查看；每一行都按各自维度从高到低排列。

• 效率：可见度 > 感谢 > 长期合作 > 访问权限
• 价值（该模式可达到的月收入）：长期合作 > 访问权限 > 可见度 > 感谢——当投放位置的流量达到每月数万次浏览时，可见度的价值会超过访问权限
• 工作量：访问权限 > 长期合作 > 可见度 > 感谢
• 合规成本：长期合作 > 可见度 > 访问权限 == 感谢

工作量级别：

• 感谢：页面建好后，几乎不需要额外投入。

• 可见度：每位赞助商约需一小时，用于提交徽标变更并检查投放位置。

• 访问权限和长期合作：都是持续性的工作。

• 可见度计划。 根据实际投放流量设置公司级别的价格——README、文档站点、主页。交付内容是提交徽标变更；收入随项目的实际受众规模增长。只要文档或 README 有可衡量的流量，就应优先采用这种模式。

• 感谢计划。 低档位、无福利、只提出一个明确请求。适合拥有许多小用户、维护者又没有空余时间的项目；也可作为其他任何模式的基础。

• 长期合作计划。 少数有依赖关系的公司为明确的承诺付费（响应时间、安全问题分诊、升级支持）。赞助商最少，支票金额最大，义务也最多。

• 访问权限计划。 仅限赞助商访问的内容、抢先体验或赞助商专享内容。这是有记录以来转化效果最佳的模式，但持续成本也最高——它相当于在维护工作之外又开了一项内容业务。只有在已有受众时才适用。

• 按工作节奏区分这两种持续性工作：无论是否有人请求，访问权限模式都要持续提供内容；长期合作工作则由有依赖关系的公司偶尔提出需求后触发——因此，金额更大的长期合作所需工时反而更少，排名也高于访问权限。

• 说明合规成本并列的原因：访问权限和感谢都不会让项目对某家公司作出明确承诺，也不会把第三方品牌放在项目页面上；两者都可以通过一次提交，停止向新赞助商提供。

• 长期合作的合规成本最高：需要一个实体、编号发票、税务处理，以及一份难以违约的书面承诺。可见度排第二：GitHub Sponsors 上的公开定价是永久性的；在展示第一个赞助商徽标前，必须先按步骤 8 制定拒绝规则。

• 这种排序忽略了什么：长期合作。它是唯一能带来工资级收入的模式，也是唯一要求真正交付工作的模式，因此同时在价值和合规成本排序中居首，却在每一轮中都被效率比压制。只遵循效率排序的维护者，收入永远只能够买咖啡。

• 当问题 2 的答案是“取代工资”，能够说出三家有依赖关系的公司名称，并且已经有实体或财务托管方时，将长期合作提升到首位。

• 应删除而非降级，并说明删除哪种模式：

  • 没有实体，也不愿意使用财务托管方，则删除长期合作。
  • 除代码仓库外没有其他受众（没有文档流量、新闻邮件订阅者或演讲听众），则删除访问权限。
  • README 和文档没有可统计的流量，则删除可见度计划，因为无法衡量的投放就无法定价。

• 大多数可行的计划都是以感谢为基础，再加上其他一种模式；只有当维护者能同时承担两部分工作时，才建议组合使用。

• 这种排序只是默认方案，并非定律：它会随具体情况和执行者而变化。

• 呈现前，根据你对这位维护者已有的了解重新排序：

  • 如果已经有新闻邮件订阅者或会议受众，就提高访问权限的优先级，因为分发渠道已经建立。
  • 如果雇主已经为这项工作付费，长期合作的前提就不复存在。
  • 三人团队能够承担某种模式，而单人维护者则必须删除它。

第 3 步——为两类买家构建阶梯

阶梯面向两类行为截然不同的买家：

• 个人用自己的钱支付 $5-$25，几秒内就会做出决定，想要的是感谢或个人福利。
• 公司从预算科目中付款，需要发票和明确的受益对象，想要的是审批人能够说明理由的福利。

参考文件中的赞助展示位定价阶梯（Vue、Sindre Sorhus）把个人与公司的分界线设在每月 $100 左右；将这一划分视为基准，如果受众反馈不同，再做调整。

以下规则决定阶梯的大部分设计——前四条来自参考文件中公开的阶梯，最后两条来自 GitHub 的文档：

• 公司展示位的定价应依据其触达的受众，而不是赞助者的慷慨程度。“在每月浏览量 20k 的 README 上放置徽标”是一笔审批人可以签字批准的媒体投放；“黄金赞助商”则不是。Sindre Sorhus 会公布每个展示位的月浏览量，并据此定价。
• 按买家来命名档位。“The Agency”或“Team”能让公司知道这个档位是为自己准备的；“Platinum”则让他们不得不猜——这是 Caleb Porzio 测试档位后得出的结论。
• 转化档位下方绝不能设置只提供部分福利的档位。“如果人们可以选择每月支付 $1-5，而不是 >$14，他们就会支付较低的金额”（Porzio）。在提供福利的档位_下方_设置一个不提供福利、仅表达感谢的档位是可行的，甚至很有用。
• **预计会有一个档位支撑整个计划。**现有记录中的两种个人赞助阶梯都由单个档位推动转化，其他档位则承接更高或更低金额的慷慨赞助。
• **将已发布的价格视为永久价格。**在 GitHub Sponsors 上，已发布档位的价格永远无法编辑——只能停用并创建新档位，现有赞助者则会继续留在旧档位上。定价时要考虑两年后的情况；平台上限为每月 $12,000。
• 保持阶梯简洁。将三个到五个有效档位作为基准；平台允许发布十个按月收费的档位，但没人会把十个都看完。

Vue、Sindre Sorhus 和 Caleb Porzio 的参考阶梯及其价格和具体奖励，见 references/tier-ladder-examples.md，其中也包括一个效果不佳的阶梯及其失败原因。平台限制、费用、付款和 FUNDING.yml 的运作方式见 references/platform-mechanics.md；在确定价格或平台前，请先阅读。

步骤 4 - 根据交付成本衡量每项回报，而非看其吸引力

对于每项回报，都要问：当赞助者人数达到当前的 10 倍时，这项回报每月要花多少成本？10 倍乘数是一个基准压力测试，并非测得的增长率——之所以采用这个倍数，是因为真正能促成赞助的回报，恰恰也是那些会扩展成第二份工作的回报。

回报的排序方式与形状相同，依据是赞助者买到的东西与持续交付的成本之比：

• 效率：README 或文档中的展示 > 赞助者徽章和致谢帖 > 提前体验新版本 > 私有仓库或每季度办公时间 > 每月通话、优先支持、定制工作

• 价值（促使公司签约并续约的因素）：每月通话和优先支持 > 私有仓库或办公时间 > 提前体验 > 展示 > 徽章和致谢帖——对于个人赞助者来说，低于提前体验的排序正好相反，因为徽章和致谢就是他们购买的全部内容

• 工作量：以下三个类别，按量级划分。

• **几乎为零且安全：**在 BACKERS.md 中列出名称或徽标、在 README 或文档中展示、发布致谢帖、提供赞助者徽章。

• **有上限但确实需要投入：**为每个档位提供私有仓库、每季度办公时间、提前体验新版本。

• **等同于第二份工作：**每月通话、承诺提供优先支持、为每位赞助者创作内容、定制集成。

这种排序会舍弃什么：最后一类中那些明确承诺的事项，它们是公司愿意支付长期顾问费用的唯一回报。不要把它们放进档位福利中——应将其完全移出档位体系，并通过步骤 7 单独销售，价格应与相应义务相匹配。

删除任何无法通过 10 倍测试的回报。仅面向赞助者的内容和赞助软件、优先向赞助者发布，以及达到公开阈值后再开源，都是有记录以来最能促成赞助的回报，也是最难持续提供的回报。具体机制、发布触发规则，以及绝不能设为门槛的内容（安全修复、核心库、使用项目所需的文档），请参阅 references/tier-ladder-examples.md。

步骤 5 - 将筹资请求写成范围明确的承诺

“支持我的工作”不算筹资请求。从 $5 的赞助者到拨款委员会，每位出资方都会回答同样的五个问题（opensource.guide 列出的清单）：

• 项目为何重要。
• 有哪些进展能够证明这一点。
• 相比其他选择，为何应该资助这个项目。
• 资金将用于什么。
• 资金如何才能合法拨付。

将目标转换成读者熟悉的具体单位——每周一天的维护工作、CI 和代码签名费用，或注明日期的具体交付成果。把首个筹资目标设在本季度能够完成的水平：完成的目标比设得雄心勃勃、却一年都停留在 4% 的目标更有价值。

有意选择目标类型：

• 赞助者人数目标能让收入保持私密。
• 金额目标会永久公开月收入，且无法撤回。

如果用户有公开构建的习惯，就要保持两者一致。

用维护者自己的口吻撰写页面，然后用你偏好的 humanizer 技能润色——赞助者购买的是维护者的可信度，而宣传文案会消耗这种可信度。

步骤 6 - 让赞助请求无处不在，让项目便于机器发现

赞助资金通过三种途径到账，每种途径都需要单独配置，且相对于投入成本，回报各不相同：

• 效率：FUNDING.yml 和清单中的赞助元数据 > 用户常用页面上的赞助链接 > 能经受资助方初选的健康度指标
• 价值（该途径能为项目引入的资金）：健康度指标 > 赞助链接 > FUNDING.yml
• 投入：健康度指标 > 赞助链接 > FUNDING.yml——由 Scorecard 驱动的清理工作需要几周，添加链接需要一小时，而添加文件几乎不费工夫

现在按此顺序完成前两项。这样会暂缓健康度指标相关工作，而企业基金或基金会项目在拨款前实际会审查这些指标；如果目标明确为此类项目，就应优先推进这项工作，并将本节其余内容视为前置条件。

• 人们能看到的赞助请求。 在用户常用的每个页面上，都应能在两次点击以内找到赞助链接：仓库的赞助按钮、README、文档页脚、发行说明，以及适用时的 CLI 或错误输出。无人访问的页面无法带来转化。
• 资助方扫描的依赖关系图。 资助方会自动向整个依赖树分配资金——Sentry 的 $500,000 计划覆盖了“95% 或以上可获资助的依赖项”，每项资助 $4-$10，而且“对许多项目而言，这很可能是其首个也是唯一的赞助方”。只需添加一个文件即可让项目出现在扫描结果中：.github/FUNDING.yml；如果生态系统支持，还应在软件包清单中添加赞助元数据。
• 项目计划生成的候选名单。 在任何人类审查之前，企业基金会根据机器可读的健康度数据对候选项目排序——包括 OpenSSF Scorecard 和 Criticality Score、依赖项目数量、贡献者多样性。此阶段，缺失或失效的赞助链接会成为硬性筛选条件，而不是低分：无法获得资助的项目无论其关键性如何都会被剔除。

确认每个赞助链接都能正常打开，并检查组织级备用配置（{owner}/.github）是否指向过时位置。失效的赞助链接很常见，而且会悄无声息地让整个渠道失效。

这些扫描器读取的指标、员工提名基金的资格规则，以及相关自查步骤，详见 references/funder-scan-and-eligibility.md。FUNDING.yml 的键和语法详见 references/platform-mechanics.md。

步骤 7 - 开辟企业资助渠道

个人赞助等级无法达到薪资规模的金额；真正能做到的是依赖该项目的公司。这个渠道的运作方式不同，并不是简单地提高赞助等级。

公司通过四种机制拨款，每种机制的获胜方式各不相同：

• 自动按依赖关系分配：靠让项目便于发现来获得——步骤 6 已经完成这项工作。
• 基于判断的战略赞助：靠让项目明显成为该公司产品的关键依赖来获得。
• 员工提名基金：靠已经为你提交问题的工程师提名来获得。
• 基金会或承诺计划会员资格：靠成为基金会的受助方来获得，而不是靠推销。

只有第二种需要主动联系；在联系任何人之前，先弄清楚目标是哪一种。

• 效率：按依赖关系分配 > 员工提名基金 > 战略赞助 > 基金会会员资格
• 价值（每个成功合作公司的支票金额）：战略赞助 > 基金会会员资格 > 员工提名基金 > 按依赖关系分配
• 投入：基金会会员资格 > 战略赞助 > 员工提名基金 > 按依赖关系分配——会员资格申请流程至少需要一个季度；针对单个目标公司的战略推介需要几天；提名只需给一位已经认识你的工程师发一条消息；按依赖关系分配则只需添加步骤 6 中那个几乎不费工夫的文件

战略赞助正是步骤 2 的排序所忽略的那一类机会，只不过下沉了一层：稳定的长期大额支票就在这里，而效率排序每次都会把它埋没。只针对产品明显依赖该项目的公司，投入时间逐一接洽。 相关机制及其数量见 references/corporate-sponsorship-path.md。

按以下步骤开展针对第二种机制的外联：

1. 从依赖关系图、公开仓库、提及该技术的招聘信息，以及使用公司域名提交的问题中，找出依赖该项目的公司。
2. 联系有预算且承担相关风险的人，例如平台负责人、资深工程师或安全主管；不要联系通用邮箱。
3. 将请求与已有的预算项目挂钩：供应链安全、营销触达或工程支持。Open Source Pledge 成员承诺每年为每位在职开发者投入超过 $2,000，而这笔资金正需要明确的接收方。
4. 推销有明确内容的承诺，而非善意。Valsorda 列出了公司实际购买的内容：
   • 双重身份验证和强制代码审查。
   • 跟进生态系统变化的更新。
   • 可靠的审查和合并时间表。
   • 对已提交问题提供支持。
   • 谨慎处理安全报告。
   • “甚至包括继任计划。”
5. 推介前先确认采购流程：实体资质、税务表格、编号发票和银行信息都能进入处理流程；捐赠按钮则不行。通过 GitHub 开具发票的赞助每张发票至少为 $5,000，因此较小的请求应通过财政托管方处理。
6. 规划续约：预算按年编制，因此在周期中途提交价值证明说明是计划的一部分，而非客套。

确认支付渠道本身也能长期维持，而不只是目前可用。财政托管方本身就是一种连续性风险：Open Collective Foundation 于 2024 年解散，给其 600 多个集体七个月的时间来转移资金。

如果多位维护者共同管理这笔资金，应在首笔款项到账前决定由谁授权支出，并区分“为维持运营而付费”和“为决定方向而付费”——Django Software Foundation 正是出于这个原因，为分类处理和行政工作提供 Fellowship。财政托管方的公开账本也会披露每位维护者的报酬；选择托管方前应说明这一点。

外联模板、单页提案的结构和付款检查清单见 references/corporate-sponsorship-path.md。实体与托管方的连续性详情见 references/funder-scan-and-eligibility.md；完整的实体／基金会决策应交由 samber/developer-relations-skills@oss-governance 处理。

步骤 8 - 写明资金买不到什么

在首位赞助方加入前，随赞助级别一并公布以下界限：

• 赞助可换取曝光、感谢和明确列出的承诺，但绝不能换取路线图控制权或已合并的拉取请求。无论作者是否付费，贡献都应依据技术价值进行评判。
• 可以出售优先 分类处理，但不能出售优先 结果。
• 赞助方名单、路线图和审查队列应保持为相互独立的内容。
• 维护者为保护自主权而拒绝资金，是合理的选择，不是错误。

现在就明确任何利益冲突规则：哪些赞助方会被拒绝，以及由谁决定。

第 9 步 - 衡量项目本身，而不是喝彩声

问题	指标	忽略
项目在增长吗？	每月经常性收入、6 个月趋势	累计筹款总额
谁在付费？	按个人和公司划分的赞助者数量	Star 数、关注者数量
项目可持续吗？	每月流失率；档位中位数；来自最大赞助者的收入占比	一次性收入峰值
筹款请求有效吗？	每个带有筹款链接的页面所产生的转化率	页面浏览量
承诺兑现了吗？	按时交付的资助承诺；奖励已交付	感谢回复

及格线（自行设定），在 90 天后检查，此后每季度检查一次：

• 每月经常性收入较上一季度有所增长。
• 所有已公布的奖励均按时交付。
• 任何单一赞助者的收入占比都不超过 50%。
• 如果有公司依赖该项目，则至少有一个公司档位有人选择。

50% 这条线源自自由职业者的客户集中度管理惯例，而非开源资助规范；如果用户把它视为规则，请说明这一点。未达标意味着存在需要在扩大规模前解决的集中度风险；未达到第四项则意味着第 7 步中的企业渠道实际上从未真正开放。

根据筹款请求失效的位置诊断收入问题：

• 流量增长但收入持平：筹款请求的放置位置不对（第 6 步）。
• 到处都放了筹款请求，收入仍然持平：奖励不符合买家的需求（第 3-4 步）。

调用示例

典型的筹款请求，以及它们在工作流中的切入点：

• "我维护着一个每月下载量达 90 万次的 Rust crate，但没有筹款页面——该怎么设置？" → 先访谈，再依次执行第 1-6 步；在能说出依赖该项目的公司之前，暂缓第 7 步。
• "三家已获融资的初创公司都在发布我们的库，却没人赞助我们。" → 先执行第 6 步和第 7 步。如果使用情况已得到验证但收入为零，问题通常不在档位阶梯；往往是项目不易被发现，而且没有公司档位。
• "要不要先向赞助者发布新的 CLI，一个月后再公开？" → 第 4 步，然后参照 references/tier-ladder-examples.md 中的赞助者优先规则。
• "重写我们的档位，最高档是 $50。" → 第 3 步，并参照 references/tier-ladder-examples.md 中的薄弱档位阶梯及其诊断。
• "有赞助者要求我们优先处理他们的问题。" → 第 8 步，并在下一个档位上线前公布边界。

交付成果

逐节提供项目简报，并在进入下一节前就当前内容达成一致。

# Sponsorship program - <project>

## Goal monthly target, what it buys, by when

## Instrument fit why sponsorship, and what else was recommended

## Audience individual vs company mix, named dependent companies

## Ladder tiers, prices, rewards, delivery cost per reward

## Platform where money is received, fees, entity, payout path

## Ask page copy, funding goal and type, surfaces carrying the link

## Corporate lane target list, contact, pitch, paperwork status

## Boundaries what sponsorship does not buy, refusal rules

## Measurement metrics, review date, pass threshold

常见失败模式

• 公布了日后会后悔的价格。 在主平台上无法更改；最高档为 $10 会限制整个计划，直到该档位退役并由新档位取代。
• 档位阶梯只面向个人。 资金来自公司，而公司无法购买不存在的档位。
• 奖励超出维护者的承受能力。 每月与 12 位赞助者通话令人愉快；但达到 120 位时，整个计划就难以为继。
• 没人能找到赞助页面。 没有赞助按钮、没有 README 链接、没有 FUNDING.yml——人们和依赖关系图中的资助方都看不到。
• 出售路线图影响力。 这种方式转化最快，却会摧毁中立性，还会让其他所有用户都不再信任问题审查队列。
• 目标永远不变。 第一个目标遥不可及时，看起来就像没人支持这个项目；设定一个能在本季度完成的目标。
• 把项目本身设为付费门槛。 为便利功能提供赞助者优先访问没有问题；但对库本身、安全修复或文档设置付费墙，就近乎背弃了许可证，也背弃了成就你今天的用户。
• 收到资金后就不再更新。 赞助者会依据实际进展续费；一个沉寂的季度意味着赞助会被取消。

参考资料

• references/platform-mechanics.md - 层级和目标限制、费用、开票最低金额、FUNDING.yml 键、财政托管、依赖项分成平台。
• references/tier-ladder-examples.md - 三个包含价格和奖励的真实层级梯度、一个薄弱梯度及其诊断、赞助即发布规则，以及一个填写完整的示例。
• references/corporate-sponsorship-path.md - 四种资助机制、目标识别、外联邮件（薄弱版本和优秀版本）、计划书结构、付款清单、续约说明。
• references/funder-scan-and-eligibility.md - 资助方工具会读取的健康度和可付款性信号、员工提名资助的资格规则、实体及财政托管连续性风险，以及自查流程。
• references/grant-programs-and-reporting.md - 各资助项目的资格门槛和已公布金额、重复出现的申请字段、已公布的评分标准、获资助后的报告职责，以及已结束的项目。
• samber/developer-relations-skills@build-in-public：公开收入目标所要求的透明实践。
• samber/developer-relations-skills@readme-optimization：申请内容与之竞争的 README 展示空间。
• samber/developer-relations-skills@oss-distribution-strategy：扩大按曝光度定价所依赖的受众群体。
• samber/developer-relations-skills@devtools-business-model：赞助收入是否能完全替代收入模式。
• samber/developer-relations-skills@oss-monetization：当赞助收入不足以达到薪资水平时，维护者可以改为出售的内容：付费附加功能、支持服务、内容或许可证调整。
• samber/developer-relations-skills@oss-maintainer-sustainability：问题真正出在维护者负担上时的应对思路，因为单靠资金无法减轻负担。