开源项目发布期后的持续分发组合设计：当采用停滞…

适用于开源项目已过发布窗口后，维护者要回答人们如何持续发现项目、为何采用变平、该投哪些注册表或 awesome 列表、发布频率如何影响曝光，并在有限工时内安排分发渠道的场景。

适用场景

解决思路

1. 明确边界：本技能只决定渠道组合；一次性发布事件交给 samber/developer-relations-skills@oss-launch，持续透明实践交给 samber/developer-relations-skills@build-in-public，单注册表执行交给 samber/developer-platform-skills 的 playbooks。
2. 访谈时一次只问一个问题，能多选就提供多选，直到能说出生态、采用者类型和真实产能后立即停止。
3. 问项目是什么，以及今天别人如何安装或添加它。
4. 问它发布到哪些生态：一个语言注册表、多个、二进制、容器镜像、编辑器或浏览器扩展、宿主产品插件。
5. 问采用者是谁：为自己选择的个人开发者，还是必须在公司内获得审批的工程师；两者都有效但会改变渠道组合。
6. 问分发需要产出什么：用户、贡献者、赞助、商业产品漏斗、招聘信号、标准制定。
7. 问每月真正可用且长期可持续的维护者工时，而不是第一个月热情期的工时；问还有谁能执行其中一部分，以及停止后多少可回退。
8. 问结果是否必须在某个日期前落地：融资决策、会议、企业采购中的交易、资助报告，还是期限开放。
9. 问目标是一次性胜利可供展示，还是无需继续投入也能持续回报的复利位置；回答两者是预算拆分而不是一个答案。
10. 问现有已就绪的东西：注册表、列表、第三方包、镜像、集成、市场列表；以及尝试过但没产生结果的事。
11. 问当前基线：下载量、唯一克隆者、依赖者、来源来源，以及在哪里读取。
12. 问禁区：原则上拒绝的渠道、许可或雇主限制、要触达的地区、竞争对手地盘。
13. 问未来两个季度会有什么变化：1.0、改名、重写、商业产品、企业采购中的交易，计划要据此定时。
14. 用问题5、6、7先设定渠道排序：硬截止日期提升快速生效家族，降低需要完整发布周期才能到达安装路径的下游打包和依赖位置；复利要求反转并删除创作者播种；低工时上限直接删除每发布税家族而不是缩小；不接受不可逆承诺则删除下游打包。
15. 记录访谈答案；如果运行环境有持久记忆，把生态、采用者类型、产能和拒绝渠道存进去，后续发布和兄弟技能会复用。
16. 步骤1：在计划任何新渠道前，先测量已经在运行的分发渠道，遵循 references/coverage-audit.md。
17. 预期审计发现两类问题：一个半配置的基础渠道，例如空关键词槽、缺链接、描述早于当前定位；以及两三个完全错误的列表；在提出新渠道前先修复，约一小时工作量。
18. 不要对这些修复相互排名：它们总共一小时且都必须做，排序是假精确；排名从步骤2开始，因为那里才是真正互斥的选项。
19. 步骤2：显式进入头脑风暴模式并说明正在头脑风暴，此时不要提出计划。
20. 使用 Bullseye 框架，来自 Gabriel Weinberg 和 Justin Mares 的 Traction 2015，并在前面加一圈：Foundation ring 是一次设置、缓慢衰减、提升其他渠道收益的渠道，包括注册表元数据、规范仓库表面、文档入口、类别真正被浏览的一两个列表；便宜、复利、非可选。
21. 加入 Test ring：2 到 3 个候选渠道作为限时实验，每个有明确成功信号和结束日期。
22. 加入 Core ring：一旦测试证明有效，就值得持续投入的单一渠道。
23. 做两个 OSS 适配：预算单位是小时而不是美元；多个 OSS 渠道是一次设置而非活动型，这正是 Foundation ring 存在的原因。
24. 用 references/channel-catalog.md 扩展外圈列表：十一个家族，每个包含它奖励什么、成本、衰减曲线；编号是目录不是排名。
25. 在提出组合前先按默认效率排序家族，即每维护者小时回报：registry metadata 大于 release stream，大于 dependency position，大于 machine-readable surfaces，大于 curated lists，大于 code-host surfaces，大于 trust signals，大于 extension marketplaces 等于 connector hubs，大于 downstream packaging，大于 creator seeding。
26. 单独读取 effort 轴，即每月经常性小时，最重到最轻：creator seeding 大于 extension marketplaces 等于 connector hubs，大于 downstream packaging，大于 curated lists，大于 code-host surfaces，大于 trust signals，大于 release stream，大于 registry metadata 等于 machine-readable surfaces，大于 dependency position。
27. 单独读取个人采用价值轴：dependency position 大于 registry metadata，大于 extension marketplaces，大于 curated lists，大于 release stream，大于 creator seeding，大于 machine-readable surfaces，大于 code-host surfaces，大于 connector hubs，大于 downstream packaging，大于 trust signals。
28. 单独读取公司采用价值轴：downstream packaging 大于 trust signals，大于 dependency position，大于 connector hubs，大于 registry metadata，大于 release stream，大于 extension marketplaces，大于 machine-readable surfaces，大于 curated lists，大于 code-host surfaces，大于 creator seeding。
29. 读取合规成本轴：downstream packaging 大于 connector hubs，大于 trust signals，大于 extension marketplaces；打包不可逆，已发布 distro 包无法撤回；hub 以许可证白名单和签名审查为门槛；trust signals 发布后要承担披露 SLA；市场监管条款仅需接受且可通过下架逆转；其他七个家族没有这种暴露，所以该轴不是对全部十一个家族排序。
30. 说明 effort 指的是经常性成本，是稀缺资源；dependency position、trust signals 和 connector hubs 的入口成本相反，是一次集中投入后几乎无需持有；引用成本时必须说明指哪一种。
31. 保留真实并列：extension marketplaces 与 connector hubs 的成本形状完全相同，都有供应商审查门槛、针对维护者无法控制的宿主版本的每发布兼容税、宿主移动时同样的有害衰减，只是受众不同。
32. 保留另一个真实并列：registry metadata 与 machine-readable surfaces 都是对项目已发布产物做措辞工作，没有第三方介入。
33. 有意打破一个近并列：curated lists 对个人采用略胜 release stream，因为列表触及陌生人，而发布流主要触及现有依赖者；它的新采用价值是间接的，通过 last published 活性代理体现。
34. 明确指出这个顺序会饿死什么：downstream packaging 在效率上接近底部，却在公司采用价值上最高，而且是经典有害衰减家族；陈旧包不会沉默，会持续把一年旧版本发给计划瞄准的评估者。
35. 当四个条件全部满足时，把 downstream packaging 提升到除基础环外一切之上：公司采用是声明目标；安装单元是独立二进制或容器镜像而不是别人依赖文件里的库；发布卫生已足够让第三方打包者维持，从而把经常成本移出维护者；维护者接受不可逆性。
36. Creator seeding 排在最后是排名生效而不是被饿死：它的成本是无人能替代的经常关系工作，停止推销就停止回报；只在有日期里程碑且序列阶段1和2已成立时才提升它。
37. 默认顺序不是法律，会随生态、目标和执行者变化；根据访谈答案重新排名，并明确指出哪个答案移动了哪个家族。
38. 如果已有 distro 维护者打包项目，则入口成本已付、经常成本在别人身上；把 downstream packaging 移入 Foundation ring，把工时花在保持该打包者最新的发布卫生上。
39. 如果生态中有一个主导注册表，则 registry metadata 和 release stream 吸收大部分可发现性；curated lists 和 code-host surfaces 下降几位。
40. 如果没有工时做任何经常性工作，则顺序坍缩为一次设置家族：registry metadata、machine-readable surfaces、已获得的 dependency position；所有需要月度清扫的家族都删除而不是缩小。
41. 如果默认假设被某个优势消除，例如已认识 curator 或 hub 维护者、雇主内部打包、共同维护者做发布工程，则把该优势支付入口成本的家族移到最前。
42. 删除绝不降级：被维护者约束排除的家族完全离开排名，并在计划的 Refused 部分点名；被排除渠道停在底部会读作以后，并在下季度重新变成范围。
43. 然后提出 2 或 3 个候选组合，绝不是一个计划；三种常见形状是 Coverage-first，即广泛 Foundation ring 且无 Core，押注到处准确存在胜过任何深度；Ecosystem-depth，即专注一个语言社区，在该社区安装处打包和列出；Downstream-first，即打包进目标公司已经信任的渠道，通常公司采用目标需要它。
44. 对候选组合也按同轴排名：效率为 coverage-first 大于 ecosystem-depth 大于 downstream-first；effort 为 downstream-first 大于 ecosystem-depth 大于 coverage-first；个人采用价值为 ecosystem-depth 大于 coverage-first 大于 downstream-first；公司采用价值为 downstream-first 大于 coverage-first 大于 ecosystem-depth。
45. 合规成本不在组合之间排名：只有 downstream-first 携带暴露，且已在家族层定价；downstream-first 是高一层的同种饥饿案例，效率最后，却在决定审批者是否签署的轴上第一；coverage-first 效率领先只是因为多数项目到达时 Foundation ring 未填，一旦修复差距缩小，由采用者类型决定而不是比例。
46. 给每个组合每月小时成本、它服务的采用者类型和它放弃什么，然后推荐一个并说明理由；让维护者先选，再详述任何内容。
47. 步骤3：对每个候选渠道做 adoption test，书面回答四问：经常成本，即永久保持准确所需每月小时；衰减行为，即被忽视时是变不可见可接受，还是变主动错误有害，例如列表、包、镜像发旧版本；可观察信号，即若有效哪个数字会动以及在哪里读；Kill date，即何时重评以及什么结果会退役它。
48. 对第三个问题没有答案的渠道是爱好而不是渠道；只有经常成本真正符合声明产能时才采用有害衰减渠道；公开拒绝渠道，并从步骤2排名剪掉，书面拒绝包含渠道、原因、重启条件，是交付物；停在最后的渠道每季度都会被重新争论，点名拒绝则不会。
49. 步骤4：把渠道匹配到采用者类型；个人采用中，发现来自搜索、生态浏览和口碑，安装命令是转化点，因此优化注册表可发现性、一行安装路径、生态阅读列表中的存在和零摩擦默认值。
50. 公司采用中，评估者找到项目，但审批者决定，工件代理或审查委员会可以直接阻止安装；分发意味着通过公司已信任的渠道可安装，并且 legible，即审批者无需问任何人就能验证许可证、版本承诺、安全联系人、发布节奏和工件签名。
51. 用 Geoffrey Moore 的 Crossing the Chasm 1991 理解第二条路径：务实买家想要同细分同行参考，而在有人先采用前不存在；实际形式是可见的具名采用者墙，让现有使用可见是分发动作而不是虚荣，一个具名公司采用者胜过一千个匿名下载。
52. 同时服务两条路径的渠道对两者价值不同；步骤2的两个价值排序已经为这种差异定价。
53. 把 legibility 论证锚定在评估者自称重视的因素，即陈述偏好而不是已证采用驱动；引用 Larios Vargas 等人在 ESEC/FSE 2020、DOI 10.1145/3368089.3409711、115 名从业者中的 highly influential 排名：成熟度或稳定性 62%，可用性 55%，文档 51%，许可证 45%，活跃维护 44%；其中四个是分发计划不改代码也能让其可见的；完整排名和限制见 references/published-findings.md。
54. 步骤5：排序计划而不只是排名；使用三阶段默认并按访谈答案调整；阶段1是 Foundation，第 1 到 4 周，修复审计发现的元数据和陈旧列表；如果公司采用是目标，同轮发布最低信任姿态：签名发布、构建来源、发布 SBOM、含披露路径的 SECURITY.md、CI 中的自动化供应链评分。
55. 阶段2是 Passive discovery，第 1 到 3 个月，做无需经常支出即可复利的表面：找到细分中最高 fan-in 的 hub 项目并争取采用或一等适配，建立 used by 墙，并通过社区盟友进入代码托管 topic 表面而不是自提交。
56. 阶段3是 Active seeding，持续进行，仅在阶段1和2成立后：维护 3 到 5 个 newsletter 或播客关系，按季度日历推进，附 demo 或 sample repo；赞助位要明确区别于编辑报道。
57. 把步骤2效率顺序重读为日历，用到达效果的时间决定并行：被动发现放第二，因为回报周期长；主动播种放最后，因为经常成本高；唯一采用者条件翻转在阶段1内：trust signals 对个人采用效率低、对公司采用接近顶部，所以信任姿态要么前四周发布，要么完全不进计划；它是一次性成本解锁整个买家细分，绝不该用于驱动流量然后卡在采购。
58. 四个触发会改变计划：企业采用尽管文档强仍停滞，说明阻塞是采购而不是认知，先升级信任姿态再加认知渠道。
59. 星标速度快但使用和留存平，说明公告传播了安装没有，这是 onboarding 问题，把预算移到文档。
60. 一个 hub 项目驱动大多数传递使用，投资该关系和归因，而不是更多小集成。
61. 监管修复请求压力飙升时，把披露 SLA 正式化而不是个人吸收负载；预期它来自下游公司要求，因为 EU CRA 约束制造商而非上游维护者：报告义务从 2026 年 9 月开始，SBOM 技术文档从 2027 年 12 月可执行。
62. 步骤6：把发布流当成渠道；发布广播给维护者否则触达不到的人，每个接收者都会行动：依赖更新机器人向下游仓库开 PR，打包者流水线因新 tag 触发，feed 采集 newsletter 收录，watchers 在通知中看到，评估者把注册表 last published 字段读作活性代理。
63. 因此发布节奏是分发决策，changelog 是分发资产。
64. 遵循由该机制推导出的节奏规则，属于实践推理而非测量发现：承诺可预测的最大间隔，例如修复在 N 周内落地，绝不要承诺强制最小间隔；把小改动批成一个可读发布；安全修复 out of band 且快速发布。
65. 避免空日历发布，因为它会变成下游噪音 PR，并训练维护者自动合并或忽略这个直接触达现有用户的唯一渠道。
66. 长期沉默即使项目已完成也通不过活性代理；廉价修正是 README 中明确声明 stable, maintained, low change rate；保留具名里程碑，例如 1.0、重写、改名，作为发布窗口关闭后重返认知渠道的合法理由。
67. 步骤7：写出维护者无需你也能运行的计划，输出形状包括：Distribution plan - <project>；Position today，含审计发现、当前到达来源、基线数字和日期；Adopter，说明个人、公司或两者以及各自需要什么；Foundation ring channels fixed now，含确切缺口；Sequence stages 1-3，含日期和重排触发；Test ring 2-3 experiments，含假设、信号、结束日期、成本；Core channel，即唯一持续渠道以及为何胜出；Refused channel、原因和重启条件；Release rhythm，含最大间隔、里程碑计划、changelog owner；Review sweep cadence for decaying channels，含季度重新决策；Threshold check，每个阈值通过或失败及数字。
68. 逐节呈现计划并在写下一节前获得同意；错误的采用者判断会传播到下面每个渠道选择，在第二个标题处发现远比第九个标题处便宜；工作示例和弱强条目见 references/distribution-plan-example.md。
69. 调用示例一：下载在 Show HN 后持平，先访谈再做覆盖审计；通常预期是半填注册表页面，而不是缺少渠道。
70. 调用示例二：是否进入 Homebrew 和 Debian，先问采用者类型；装在 virtualenv 里的语言库通常不，瞄准公司笔记本的独立二进制则是下游打包计划。
71. 调用示例三：发布 VS Code 扩展，不应只靠一个市场；双发布到 Microsoft marketplace 和 Open VSX，因为 Cursor、Windsurf、VSCodium 和 Gitpod 默认使用 Open VSX。
72. 调用示例四：连接器在自家 GitHub 时，若供应商 hub 是他们的用户安装处，则应该进入，但先读支持层级；见 catalog family 11。
73. 调用示例五：OpenSSF Scorecard 高于 7 是否会增长下载，没有证据支持；把它作为采购赋能向公司内部销售。
74. 调用示例六：每月只有 3 小时，则产能是绑定约束；提出 foundation-only 组合，并公开拒绝 Test ring。
75. 分两层测量分发，因为很少能清晰归因：Coverage 是你控制、今天可审计的事实；Arrival 是按季度对步骤1基线观察的行为趋势。
76. 按阈值约束计划并迭代直到通过；只有第一个阈值有已发布政策支持，其余是本技能设定的门槛，报告时必须说明：Sourced，即审计中发现的每个陈旧列表都要在添加新渠道前修复或移除，因为 curated lists 和 distro repositories 按已发布政策丢弃读作未维护的项目。
77. 采用门槛而非行业标准：如果公司采用在范围内，要求供应链评分高于 7，并且工件证明为绿色；没有公开标准定义通过分，本技能为企业审查采用该门槛，只作为采购门槛，绝不作为采用预测。
78. 本技能自设基线：每个注册表 100% 填满元数据字段，包括 description、keyword slots、categories、license、repository、docs、homepage、funding；总经常成本最多为声明月产能的 60%，为清扫和意外留空间；每个渠道都有 owner、每月小时估计、明确信号和审查日期；没有计划清扫的有害衰减渠道不得进入。
79. 最后明确报告阈值检查；计划因产能失败不需要纪律，它只是多了一个渠道。
80. 对每个声明标注置信度，因为维护者要花稀缺小时；references/published-findings.md 保存引用和每项研究的限制。
81. 证据支持：四个开发者中有三个在采用或贡献前会考虑 stars，36.7% 的人 star 项目是因为已经使用过，来自 Borges 和 Valente，JSS 2018，791 名开发者；可见使用是真实社会证明杠杆，但同一调查显示推广会驱动 stars，所以 star 数既测量触达也测量 merit。
82. 证据支持：只有 27.5% 的 npm 包被其他包依赖，来自 Wittern 等，MSR 2016；这是 2016 年 npm 快照，应信任偏斜而不是具体数字；进入被依赖核心是结构性优势。
83. 证据不支持：供应链评分、签名和来源作为采用驱动尚未确立，成熟度和资金会混杂每个明显相关关系；badges 作为增长杠杆也不成立，第一个 badge 只带来小幅且非持续提升，来自 Trockman 等，ICSE 2018，npm；要重视行为胜过自报，优先读依赖和下载数据而不是调查偏好，并记住两者都可博弈。
84. 常见失败模式：Spray-and-pray 列表，一个周末提交二十个，一年后全陈旧；三个被维护的表面表现更好且成本更低。
85. 常见失败模式：混淆发布与分发；发到注册表只是桌面筹码，在那里可发现并通过用户已用渠道可安装才是工作。
86. 常见失败模式：把信任工作推销成增长；签名和 SBOM 移除采购阻塞，承诺下载提升会设置下一次安全请求来偿还的失败。
87. 常见失败模式：把 stars 当结果；stars 测量注意力和推广触达，下载、依赖者、克隆者和陌生人 issue 才测量分发。
88. 常见失败模式：规划超过产能；项目成功时产能会缩水，支持负载先增长，要按最差现实月份规划。
89. 常见失败模式：从不退役任何东西；季度审查有权杀死渠道，才能让组合留在产能内。
90. 按家族处理陷阱：自提交到 curated code-host surfaces、把下游包当成自己的、节奏表演、一份描述到处复制、信任外部趋势工具等，都列在 references/channel-catalog.md 中它们所属的家族下。
91. 使用参考资源执行：references/channel-catalog.md 说明十一个家族各自奖励、成本、衰减曲线和陷阱；references/coverage-audit.md 覆盖清单、元数据检查、覆盖和到达指标；references/distribution-plan-example.md 给出工作示例、弱强条目和拒绝；references/published-findings.md 给出所有 sourced claim 背后的研究和政策以及它们不能证明什么；samber/developer-relations-skills@readme-optimization 优化所有渠道指向的仓库表面；samber/developer-relations-skills@changelog-writing 写发布说明；samber/developer-relations-skills@coding-agent-docs-optimization 执行 family 10 的机器和 agent 可读表面。

适用边界 · 注意事项

• 不适用于一次性发布活动，应使用 samber/developer-relations-skills@oss-launch。
• 不适用于持续透明或 build-in-public 实践，应使用 samber/developer-relations-skills@build-in-public。
• 不适用于单个注册表或平台的具体执行手册，应使用 samber/developer-platform-skills 中的 playbooks。