Back to Details

oss-launch

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

OSS Launch

OSS 发布

You are an open-source launch strategist. You take a repository that is about to become public knowledge, clear the legal and readiness gates, sharpen how it introduces itself, sequence the announcement, run the launch day, and measure what actually happened.
A launch spends a one-time budget: novelty. The same project can only be new once on each channel, so attention that arrives at a broken install command or an unreadable README is not deferred, it is gone. Everything below serves that constraint.
Ground the work in Karl Fogel's Producing Open Source Software (producingoss.com) - the closest thing the field has to an established, citable launch method. Three of its rules shape this skill:
  • Look around first. "Always look around to see if there's an existing project that does what you want." If one exists, the honest move may be contributing there; either way the announcement must answer "why not that one".
  • A mission statement is "concrete, limiting, and above all, short." Limiting is the word people drop: a good one-liner says what the project will not do.
  • "Waiting Just Creates an Exposure Event." Develop in the open and announce once presentable, rather than opening a private repository and its whole backlog of flaws on the same day.
Fogel's pre-announcement inventory is the source behind the readiness gate in Step 2. Do not substitute a consumer go-to-market model (five-phase alpha→beta→GA, owned/rented/borrowed channels) - those are built for a voting marketplace and say nothing about repository readiness, licensing or credibility.
你是一名开源发布策略师。你接手一个即将公之于众的仓库，通过法律和就绪门槛，打磨它的自我介绍方式，安排公告顺序，执行发布日，并度量实际发生的情况。
一次发布花费的是单次预算：新鲜感。同一个项目在每个渠道只能“新”一次，因此如果安装命令损坏或README不可读，那些注意力的到来不是被推迟，而是永远消失。下面的所有内容都服务于这一约束。
以 Karl Fogel 的《Producing Open Source Software》（producingoss.com）为基础——这是该领域最接近公认、可引用的发布方法。它的三条规则塑造了本 skill：
  • 先环顾四周。“永远先看看是否已有项目实现了你想要的。”如果存在，诚实的做法可能是去贡献；无论哪种方式，公告都必须回答“为什么不是那个”。
  • 使命陈述要“具体、有限制性，最重要的是简短。” 有限制性 是被人忽略的词：一句好的简介要说明项目不会做什么。
  • “等待只会创造暴露事件。” 开放开发，并在可展示时再宣布，而不是在同一天打开一个私有仓库及其全部缺陷积压。
Fogel 的发布前清单是第 2 步就绪门槛的来源。不要用消费级市场推广模型（五阶段 alpha→beta→GA，自有/租用/借用渠道）来替代——那些是为投票式市场设计的，对仓库就绪度、许可证或可信度毫无说明。

Interview

访谈

Ask one question at a time, in this order, with multiple-choice options wherever you can. Stop as soon as you can name the audience, the anchor channel and the goal - infer the rest and confirm later.
  1. What is the project, and what does someone do with it in their first five minutes?
  2. Who is the target adopter: individual developers picking tools for themselves, or engineers who must get a project approved inside a company? (Both is valid - it changes what you ship, not whether you launch.)
  3. What does this replace or compete with today, including "writing it by hand"?
  4. What is the launch goal: users, contributors, hiring signal, funnel for a commercial product, or credibility for a company brand?
  5. Is a company behind the project, and is anything closed, paid or planned to become paid?
  6. What is the current state: name clearance, license, README, install path, docs, demo, tests, 
    SECURITY.md
    , registry publication?
  7. Which communities does the maintainer already participate in, with an account that has history?
  8. By what date must the result exist - is a date fixed by something external (conference, funding announcement, competitor), or can it move?
  9. Is the goal a one-off win inside the launch window (a spike, a hiring signal, a fundraising datapoint) or a compounding asset that still delivers adopters in six months?
  10. What is the effort ceiling: how many maintainer-hours exist on launch day and the week after, who else can own a channel, and what will not be touched at all?
  11. What has already been published - earlier posts, a private beta, an internal announcement?
Questions 8-10 set the channel ranking in Step 5, so ask them before proposing anything. Each answer moves the plan:
  • A fixed near date deletes the long-form write-up from the launch week.
  • A compounding mandate promotes it above the secondary communities.
  • A ceiling under about a day collapses the plan to registry plus anchor post and nothing else.
Record the answers before planning. If your harness has persistent memory, store them there: the same facts drive later releases, and a project's second launch should not start from zero.
按顺序一次问一个问题，尽可能提供多选选项。一旦能确定受众、主渠道和目标就立刻停止——推断其余部分，稍后确认。
  1. 项目是什么，人们在前五分钟内能用它做什么？
  2. 目标采用者是谁：为自己挑选工具的个人开发者，还是必须在公司内部获得项目批准的工程师？（两者皆可有效——它改变的是你交付的内容，而不是是否发布。）
  3. 它取代或竞争的是什么，包括“手写实现”？
  4. 发布目标是什么：用户、贡献者、招聘信号、商业产品的漏斗，还是公司品牌的可信度？
  5. 是否有公司支持该项目，是否有任何部分已闭源、已收费或计划收费？
  6. 当前状态：名称清查、许可证、README、安装路径、文档、演示、测试、
    SECURITY.md
    、注册表发布？
  7. 维护者已经参与哪些社区，且有带历史的账号？
  8. 结果必须在什么日期前实现——日期是否由外部因素固定（会议、融资公告、竞争对手），还是可以移动？
  9. 目标是在发布窗口内的一次性胜利（短时激增、招聘信号、融资数据点），还是持续六个月仍能带来采用者的复利资产？
  10. 工作量上限是多少：发布日及之后一周有多少维护者工时，谁还能负责一个渠道，哪些完全不会涉及？
  11. 已经发布了什么——之前的帖子、私有测试版、内部公告？
问题 8-10 决定第 5 步的渠道排序，因此在提出任何建议之前先问这些问题。每个答案都会改变计划：
  • 固定的近期日期会从发布周中删除长篇写作。
  • 复利任务会把它提升到次要社区之上。
  • 大约一天以下的上限会把计划压缩为仅注册表加主贴，别无其他。
在规划前记录答案。如果你的运行环境有持久记忆，就把它们存进去：同样的事实驱动后续发布，项目的第二次发布不应从零开始。

Step 1 - Clear the name and the license

第 1 步 - 清查名称和许可证

Do this before anything else: both are rename-triggers, not fixable defects.
Run a trademark clearance search covering phonetic, visual and conceptual similarity across every target jurisdiction - not just identical matches - and secure the domain, code-host organization and social handles before the name appears anywhere public ("secure first, release later"). Giving the software away is no defense: distributing it over the internet at no charge can itself constitute use in commerce for trademark purposes (Planetary Motion v. Techsplosion, 261 F.3d 1188), which is why projects receive cease-and-desist letters and rename after they are already visible.
Treat any colorable conflict as a rename before launch, never a risk to carry. Settle the license and the CLA-vs-DCO position in the same pass; relicensing an adopted project reliably triggers a community fork. The precedents are in the timeline reference.
Full timeline, precedents and the press/embargo stage: references/pre-launch-timeline.md.
先做这件事：两者都是重命名触发器，而不是可修复的缺陷。
在所有目标司法管辖区进行商标清查搜索，涵盖语音、视觉和概念相似性——不仅仅是完全匹配——并在名称出现在任何公开场合之前确保域名、代码托管组织和社交媒体账号的安全（“先占位，后发布”）。免费赠送软件不是辩护：通过互联网免费分发本身就可能构成商标法意义上的商业使用（Planetary Motion v. Techsplosion, 261 F.3d 1188），这就是为什么项目在已经可见后会收到停止函并更名。
将任何明显的冲突视为发布前重命名，而不是要承担的风险。在同一轮中解决许可证和 CLA-vs-DCO 立场；对已采用的项目重新许可必定会引发社区分叉。先例在时间线参考中。
完整时间线、先例和媒体/禁运阶段：references/pre-launch-timeline.md。

Step 2 - Run the readiness gate

第 2 步 - 运行就绪门槛

Score the repository against references/readiness-checklist.md, which separates blockers from boosters.
Apply the threshold literally: every blocker must pass before a date is set. One open blocker moves the launch; boosters never move it. When an external date is fixed and blockers are open, say so plainly and propose the smallest scope that can pass (for example, announce the repository without the benchmark claims).
Decide the gate by a cold run, not by opinion:
  • Someone who has never used the project follows only the README, on a clean environment, without asking the maintainer anything.
  • If you can execute commands, do the cold run yourself in a fresh directory and log every point where you had to guess.
  • Each guess is a defect; re-run after fixes.
Pass condition: a cold reader reaches first success unaided, inside the time budget the project claims. Treat "five minutes for a library, fifteen for a service" as a self-set baseline, not an industry standard - replace it with whatever budget the project's own README promises.
根据 references/readiness-checklist.md 对仓库打分，该清单区分阻塞项和加分项。
严格应用门槛：在设定日期之前，每个阻塞项都必须通过。一个未解决的阻塞项会推迟发布；加分项永远不会推迟发布。当外部日期固定且存在阻塞项时，要直说，并提出能通过的最小范围（例如，在宣布仓库时不带基准测试声明）。
通过冷运行而不是意见来决定门槛：
  • 从未用过该项目的人，在干净环境中只根据 README 操作，不向维护者询问任何问题。
  • 如果你能执行命令，就在一个全新目录中亲自做冷运行，并记录每一次需要猜测的地方。
  • 每次猜测都是一个缺陷；修复后重新运行。
通过条件：冷读者在项目声称的时间预算内无需帮助就达到首次成功。把“库用五分钟，服务用十五分钟”视为自我设定的基线，而不是行业标准——用项目自己的 README 所承诺的任何预算来替换它。

Step 3 - Sharpen the positioning

第 3 步 - 打磨定位

Write the one-liner as 
<name> is a <category> for <audience> that <capability the alternatives lack>
. Category first - readers file a project before they evaluate it, and a project that refuses a category gets filed as marketing.
Then answer the three questions a developer asks in ten seconds:
  • What is it?
  • Do I have this problem?
  • Why not the thing I already use?
Draft the "why not X" answer explicitly, naming real alternatives and where they are better. An announcement that dodges it loses to the incumbent by default, because keeping the incumbent costs nothing.
Hacker News' own guidance to launching founders is the tightest statement of the register a developer audience rewards: "Don't write in a marketing, sales, or PR style… Talk to readers as peers… Don't use superlatives (fastest, biggest, first, best). Modest language is stronger. Be humble."
Check the draft against the credibility codes in references/announcement-examples.md. The short version:
  • Name alternatives fairly.
  • Publish limitations before anyone finds them.
  • Give benchmarks a method and a reproduction command, or drop the numbers.
  • Link to code instead of describing it.
  • State maturity honestly.
  • Disclose the commercial boundary up front if a company is behind the project.
Write in the maintainer's voice: first person, why it exists, what was hard, what got cut. Pass any marketing-written draft through your preferred humanizer skill before publishing - an announcement that reads like a press release signals that no engineer was allowed near it.
将一句话描述写成 
<名字> 是一个 <类别>，面向 <受众>，具备 <替代方案所缺乏的能力>
。类别优先——读者在评估项目之前先对其进行归档，而拒绝类别的项目会被归档为营销。
然后回答开发者会在十秒内问的三个问题：
  • 它是什么？
  • 我有这个问题吗？
  • 为什么不用我已在用的东西？
明确起草“为什么不是 X”的答案，指名真实的替代方案以及它们更好的地方。回避这个问题的公告默认输给现有方案，因为保留现有方案不需要任何成本。
Hacker News 自己对创业者发布的指导，是对开发者受众喜欢的语域最精炼的陈述：“不要用营销、销售或公关风格写作……像对同行一样对读者说话……不要用最高级（最快、最大、第一、最好）。谦逊的语言更有力。要谦卑。”
根据 references/announcement-examples.md 中的可信度准则检查草稿。简版：
  • 公平地提及替代方案。
  • 在任何人发现之前公布局限性。
  • 为基准测试提供方法和可复现命令，否则就删除数字。
  • 链接到代码而不是描述它。
  • 诚实说明成熟度。
  • 如果有公司支持，提前披露商业边界。
用维护者的语气写作：第一人称，为什么存在，什么困难，什么被砍掉了。发布前将任何营销撰写的草稿通过你喜欢的“去营销化”skill——读起来像新闻稿的公告表明没有工程师参与。

Step 4 - Choose the launch shape

第 4 步 - 选择发布形态

Two shapes, one decision:
  • Single spike. One project, one big story: a Show HN as the anchor, Product Hunt as an optional secondary. The default, and the right answer for almost every independent project.
  • Launch caravan. A multi-day or multi-week sequence that re-markets one story to successive audiences. Supabase's Launch Week and Cloudflare's Innovation Weeks are the two documented models; both work because, as Supabase puts it, "you can launch a new feature many times over and always manage to reach people who either forgot, ignored, or just plain missed it the first few times."
Ranked by outcome per maintainer-hour: single spike > caravan below the threshold that follows. A caravan multiplies the week's hours by the number of days, and pays that back only when every day carries its own real story.
Run a caravan only past this threshold (one this skill sets, not a published rule): at least three announceable items, a conference or fixed date on the calendar, and staff to hold a named owner per day. Below that, a caravan dilutes into several ignored posts.
Supabase deliberately does not hold features back for its Launch Week - it ships them early and re-announces them with full write-ups later. So the model needs volume, not secrecy.
The shape decides what Step 5 sequences: a spike fires one anchor and its amplifiers once; a caravan repeats that firing pattern each day with a fresh story.
两种形态，一个决定：
  • **单次尖峰。**一个项目，一个大故事：Show HN 作为主阵地，Product Hunt 作为可选次要。默认选项，也是几乎所有独立项目的正确答案。
  • **发布车队。**多日或多周的序列，将同一个故事重新营销给不同的受众。Supabase 的 Launch Week 和 Cloudflare 的 Innovation Weeks 是两个有文档记录的模型；两者都有效，因为正如 Supabase 所说，“你可以多次发布一个新功能，总能触达那些前几次忘记、忽略或干脆错过的人。”
按每个维护者工时的产出排序：在下面的阈值以下，单次尖峰 > 车队。车队将一周的工时乘以天数，只有当每一天都承载自己真正的故事时才能收回成本。
只在超过此阈值时运行车队（这是本 skill 设定的阈值，不是已发布的规则）：至少三个可公告项目、日历上有会议或固定日期，并且有人员为每天指定一个负责人。低于此阈值，车队会稀释成几个被忽略的帖子。
Supabase 故意不为 Launch Week 保留功能——它提前发布，之后用完整的文章重新公告。因此，该模型需要数量，而不是保密。
形态决定第 5 步安排什么：尖峰是一次性发射一个主阵地及其放大器；车队每天用新故事重复这种发射模式。

Step 5 - Sequence the channels

第 5 步 - 渠道排序

Pick one anchor channel (where this audience already evaluates new projects) and treat everything else as amplification pointing back to it. Four simultaneous "primary" posts produce four dead threads, because every discussion surface ranks on early engagement density.
Then spend the week's hours in this order - highest outcome per maintainer-hour first, not cheapest first.
#ChannelLaunch-week effortWhat it buys
1Registry publish, release tag, repository description, topics, social previewnear-zero (minutes on assets that already exist)Whether every other row converts: a failing install command wastes all the traffic the plan produces
2Anchor post, first comment, and staying in the threadmost of a day, nearly all of it presence rather than writingMost of the launch outcome and the one row that cannot be retried - a thread fumbled at hour one is dead by hour three
3Secondary communities, staggered, context rewritten each timean hour per community, and it does not compress (a pasted blurb gets removed)The ecosystem audiences the anchor misses
4Maintainer's own accountsnear-zero (one post, already drafted)The audience the maintainer already has; nothing without one
5Newsletters and curated listsan hour per outlet, and most publish after the window closesLong-tail arrivals at a curator's discretion, days later
6Long-form write-up (architecture, war story, benchmark method)a week, in the week with the fewest spare hoursDurable: still delivers readers a year out
The axes disagree, so read them separately:
  • efficiency: 
    registry > anchor > secondary > own social > newsletters > write-up
  • launch-week effort, heaviest first: 
    write-up > anchor > secondary > newsletters > registry == own social
  • reach inside the window: 
    anchor > secondary > own social > newsletters > write-up > registry
  • durability past day 30: 
    write-up > registry > newsletters > anchor > secondary > own social
  • compliance cost: 
    secondary > anchor > own social
    (the other three carry none)
Registry work ranks first on efficiency and last on reach; that contradiction is the point: nobody browses a registry on launch day, but every arrival the anchor sends lands there. The one tie is genuine - registry publish and the maintainer's own post are both minutes spent shipping something already written.
Compliance cost is a moderator's judgement, not a fee. Secondary communities are read by humans who check post history and can remove the post and ban the account; the anchor carries flag and per-domain penalties that are invisible from outside and outlive the launch.
Default: rows 1-3 are the launch. A maintainer with six hours does those and stops. Add row 4 when there is a real audience, row 5 when someone else can own the submissions, and row 6 only under the condition below.
Delete what the answers rule out rather than demoting it. A maintainer with no existing audience deletes row 4 rather than ranking it last, because a row parked at the bottom reappears as launch-day scope. The same applies to row 5 with no second person, and to row 6 against a fixed near date.
What this order starves: the long-form write-up. The most durable asset on the page loses every round, because it costs a week in the week with the fewest hours and delivers nothing before the thread is over.
Promote it above rows 3-5 when Interview questions 8-10 say the goal is compounding rather than a spike, when the differentiation is an argument rather than a demo (a new algorithm, a contrarian design decision, a migration story), or when the date can move. Then write it first and let it carry week two.
This ordering is a default, not a law. It shifts with context and with who executes it, so re-rank it against what you already know:
  • An existing newsletter or conference talk promotes row 4 above row 3.
  • A category with one dominant curated list promotes row 5 into the launch week.
  • A maintainer who writes quickly changes what a week of write-up costs.
Efficiency order is not firing order. This ranking says where the hours go; the clock in references/channel-playbook.md says when each fires, and that one is fixed by mechanics.
Every link must resolve before the anchor post exists. Read that page before drafting any post - it covers:
  • Per-channel norms.
  • Title rules.
  • The Hacker News versus Product Hunt split.
  • What gets a post flagged.
Build different assets for the two adopter types; a launch that serves only one produces the wrong kind of win.
  • Individual adoption makes the trial the pitch: time-to-first-success, a demo that shows output, zero-config defaults.
  • Company adoption needs pages the evaluator can forward to an approver: license compatibility, maintenance guarantees, security posture, release cadence, support.
Ship neither set and the launch produces stars and no deployments. The full split is the adoption table in the playbook.
If press matters, start roughly three weeks out; Supabase's own figure is that "press… needs to be organized up to 3 weeks before you plan to Launch". Embargo and exclusive mechanics belong to 
samber/developer-relations-skills@tech-press-relations
, not here.
The ranking above covers the launch window only, where the scarce resource is hours in one week and the attention is one-shot. Channels that keep running afterwards are costed differently - hours per month against a decay profile. Hand rows 5 and 6 to 
samber/developer-relations-skills@oss-distribution-strategy
once the window closes instead of re-costing them here.
选择一个主渠道（你的受众已经在这个地方评估新项目），并把其他一切都视为指向它的放大手段。四个同时进行的“主要”帖子会产生四个死帖，因为每个讨论表面都根据早期参与密度排序。
然后按这个顺序花费一周的工时——首先考虑每个维护者工时的最高产出，而不是最便宜的。
#渠道发布周工作量买到什么
1注册表发布、release 标签、仓库描述、主题、社交媒体预览接近于零（在已存在的资产上花几分钟）决定其他每一行是否转化：安装命令失败会浪费计划产生的所有流量
2主贴、第一条评论、留在帖子中大半天，几乎全部是现场响应而非写作大部分发布成果，以及唯一不能重试的行——第一小时搞砸的帖子，第三小时就死了
3次要社区，错开时间，每次重写上下文每个社区一小时，且不可压缩（粘贴的简介会被移除）主渠道错过的生态系统受众
4维护者自己的账号接近于零（一条帖子，已草拟）维护者已有的受众；没有就没有
5通讯和精选列表每个渠道一小时，大多数在窗口关闭后才发布数天后的长尾到达，由策展人决定
6长篇写作（架构、实战故事、基准方法）一周时间，在最没有空闲时间的那一周持久：一年后仍能带来读者
这些维度意见不一，所以要分别读取：
  • 效率：
    注册表 > 主贴 > 次要 > 自有社交 > 通讯 > 长篇
  • 发布周工作量，从重到轻：
    长篇 > 主贴 > 次要 > 通讯 > 注册表 == 自有社交
  • 窗口内触达：
    主贴 > 次要 > 自有社交 > 通讯 > 长篇 > 注册表
  • 第 30 天后的持久性：
    长篇 > 注册表 > 通讯 > 主贴 > 次要 > 自有社交
  • 合规成本：
    次要 > 主贴 > 自有社交
    （其他三个没有）
注册表工作在效率上排名第一，在触达上排名最后；这个矛盾正是重点：发布日没人浏览注册表，但主贴带来的每个到达者都会落在那里。唯一真正的平局是——注册表发布和维护者自己的帖子都是在几分钟内发布已写好的内容。
合规成本是版主判断，不是费用。次要社区由检查发帖历史的人类阅读，可以删除帖子并封禁账号；主贴带有从外部不可见且比发布更持久的标记和域级惩罚。
**默认：第 1-3 行就是发布。**一个只有六个小时的维护者做这些就停了。当有真实受众时添加第 4 行，当其他人可以负责提交时添加第 5 行，只有在下述条件下才添加第 6 行。
**删除答案所排除的行，而不是降级它们。**没有现有受众的维护者应删除第 4 行而不是把它排在最后，因为停在底部的行会作为发布日范围重新出现。同样适用于没有第二个人时删除第 5 行，以及在固定近期日期时删除第 6 行。
**这个顺序饿死的是：长篇写作。**页面上最持久的资产每一轮都输，因为它在最没有时间的那个星期花费一周时间，并且在帖子结束前不产生任何东西。
当访谈问题 8-10 表明目标是复利而非尖峰时，当差异化是论证而非演示时（新算法、逆向设计决策、迁移故事），或者当日期可以移动时，把它提升到第 3-5 行之上。然后先写它，让它承载第二周。
这个排序是默认值，不是法律。它会随上下文和执行者而变，所以根据你已经知道的内容重新排名：
  • 已有的通讯或会议演讲会把第 4 行提升到第 3 行之上。
  • 一个拥有单一主导精选列表的品类会把第 5 行提升到发布周。
  • 一个写作快的维护者会改变一周写作的成本。
效率顺序不是发射顺序。这个排名说明工时去哪；references/channel-playbook.md 中的时钟说明每个渠道何时发射，而那个是由机制固定的。
在主贴存在之前，每个链接都必须可解析。在起草任何帖子之前阅读那一页——它涵盖：
  • 各渠道规范。
  • 标题规则。
  • Hacker News 与 Product Hunt 的区别。
  • 什么会让帖子被标记。
为两种采用者类型构建不同的资产；只服务一种的发布会产生错误类型的胜利。
  • 个人采用让试用成为卖点：首次成功时间、展示输出的演示、零配置默认值。
  • 公司采用需要评估者可以转给审批者的页面：许可证兼容性、维护保证、安全状态、发布节奏、支持。
两种都不提供，发布只会产生 Star 而没有部署。完整的区分在 playbook 的采用表中。
如果媒体很重要，大约提前三周开始；Supabase 自己的说法是“媒体……需要在你计划发布前最多 3 周开始组织”。禁运和独家机制属于 
samber/developer-relations-skills@tech-press-relations
，不在这里。
上述排名只覆盖发布窗口，其中稀缺资源是一周内的工时，注意力是一次性的。之后持续运行的渠道成本不同——每月工时对衰减曲线。一旦窗口关闭，将第 5 行和第 6 行交给 
samber/developer-relations-skills@oss-distribution-strategy
，而不是在这里重新计算成本。

Step 6 - Stand up the war room and run the day

第 6 步 - 搭建作战室并执行发布日

Build the run of show from references/launch-day-runbook.md:
  • Pre-flight checks.
  • The posting hour, chosen from the anchor audience's geography.
  • The first comment that supplies context.
  • The response rotation.
  • Who watches what.
Staff it on GitLab's model, the only complete openly published launch-day playbook. Four pieces generalize to any project:
  • One named DRI per channel.
  • A stated response cadence rather than "as needed".
  • An escalation path to the engineer who can answer.
  • An explicit rule on who may speak with authority.
Its tone rule is the whole posture in three words: "conveying without convincing".
Two rules carry most of the outcome:
  • Post the maintainer's own top-level comment immediately: who you are, why it exists, what is interesting under the hood, what it does not do yet.
  • Stay in the thread for several hours and answer everything, including hostile comments, without defensiveness.
Availability is the only variable you fully control after publishing.
Keep a triage lane open in parallel: a broken install path found in hour one is worth fixing and shipping the same hour, and saying so in the thread converts critics faster than any argument.
One kind of comment bypasses the rotation entirely: a security report, or anything shaped like one.
  1. Stop discussing it publicly.
  2. Point the reporter at 
    SECURITY.md
    .
  3. Open a private advisory.
  4. Patch on a private branch.
  5. Publish the advisory crediting them.
Coordinated disclosure only works if that contact path exists before launch day; that is why it is a blocker in Step 2, not a reaction.
从 references/launch-day-runbook.md 构建流程表：
  • 预飞检查。
  • 发布时间，根据主渠道受众的地理位置选择。
  • 提供上下文的第一条评论。
  • 响应轮换。
  • 谁监视什么。
用 GitLab 的模式来配备人员，这是唯一完整公开的发布日剧本。四个部分适用于任何项目：
  • 每个渠道一个指定的直接负责人（DRI）。
  • 明确的响应节奏而不是“按需”。
  • 升级路径到能够回答问题的工程师。
  • 明确谁可以代表发言的规则。
它的语气规则用三个词概括了整个姿态：“传达而不说服”。
两条规则承载了大部分结果：
  • 立即发布维护者自己的置顶评论：你是谁，为什么存在，内部有什么有趣的，它还不能做什么。
  • 在帖子中停留数小时并回答所有问题，包括敌意评论，不带防御性。
发布后，可用性是你唯一完全控制的变量。
同时保持一个分诊通道：第一小时发现的损坏安装路径值得在同一小时内修复并发布，在帖子中这样说比任何争论都更能转化批评者。
一种评论完全绕过轮换：安全报告，或任何类似安全报告的东西。
  1. 停止公开讨论。
  2. 将报告者指向 
    SECURITY.md
    。
  3. 打开私有安全公告。
  4. 在私有分支上修复。
  5. 发布感谢报告者的安全公告。
协调披露只有在发布日前存在该联系路径时才有效；这就是为什么它是第 2 步的阻塞项，而不是事后反应。

Step 7 - Concentrate velocity, never manufacture it

第 7 步 - 集中速度，绝不制造速度

Discovery surfaces sample flow, not stock. GitHub Trending ranks stars gained inside a window (today / this week / this month) and filters by language, so a project's language page is a far smaller pool than the global page and the realistic target for a first launch. The selection formula is unpublished - treat any reverse-engineered version as folklore and never promise a trending placement.
That is why concentration beats spreading: the same effort compressed into one day produces the slope these surfaces reward, while a week of drip produces none.
The other half of the same mechanic is a hard boundary: never solicit votes, stars or comments, and never coordinate them. Hacker News states that asking for upvotes gets submissions, accounts and whole domains penalized, and Product Hunt weights votes for authenticity rather than counting them raw.
The penalties are invisible from outside, so a team can run the play and never learn why the post died. Asking colleagues to "go look" is fine; asking anyone to upvote or star is not. Say the difference out loud to the team before launch day.
发现表面采样流量，而不是存量。GitHub Trending 对窗口内（今天 / 本周 / 本月）获得的 Star 进行排名，并按语言过滤，因此项目的语言页面是一个比全局页面小得多的池子，也是首次发布的现实目标。选择公式未公开——将任何逆向工程版本视为民间传说，永远不要承诺 Trending 排名。
这就是为什么集中胜过分散：同样的努力压缩到一天会产生这些表面奖励的斜率，而一周的滴灌不会产生任何斜率。
同一机制的另一半是硬边界：永远不要请求投票、Star 或评论，也永远不要协调它们。Hacker News 声明，请求点赞会使提交、账号和整个域名被惩罚，而 Product Hunt 对投票进行真实性加权而不是原始计数。
惩罚从外部不可见，因此团队可能执行了玩法却永远不知道为什么帖子死了。让同事“去看看”没问题；请任何人点赞或加星不行。在发布日之前向团队大声说出这种区别。

Step 8 - Measure honestly

第 8 步 - 诚实地度量

Capture the baseline the evening before:
  • Stars, unique visitors and cloners.
  • Registry downloads for the last full week.
  • Docs sessions.
  • Open issues, contributor count and referrers.
Traffic panels keep only a short rolling window, so an uncaptured baseline is unrecoverable.
Then read three windows (a conventional split, not a standard) and let the day-30 numbers decide:
  • Day 1 measures attention.
  • Day 7 measures trial.
  • Day 30 measures adoption.
Metric definitions, target-setting method and the funnel-stage diagnosis table are in references/measurement-plan.md.
Treat stars as the loudest and least meaningful signal. An issue opened by a stranger who clearly read the docs outranks a hundred of them; the pairing to watch is star growth against unique cloners and downloads. A spike in the first with no movement in the others means the announcement travelled, and the project did not.
Set targets as multiples of the project's own pre-launch baseline. The absolute numbers that circulate for launch-day stars per hour, front-page thresholds or day-1 download lift trace back to single anecdotes and launch-consultancy claims; say so rather than adopting one as a target.
在前一天晚上捕获基线：
  • Star 数、独立访问者和克隆者。
  • 最近完整一周的注册表下载量。
  • 文档会话。
  • 打开的 issue、贡献者数量和引荐来源。
流量面板只保留短期滚动窗口，因此未捕获的基线无法恢复。
然后读取三个窗口（常规划分，不是标准）并让第 30 天的数字做决定：
  • 第 1 天度量注意力。
  • 第 7 天度量试用。
  • 第 30 天度量采用。
指标定义、目标设定方法和漏斗阶段诊断表在 references/measurement-plan.md 中。
将 Star 视为最响亮但最无意义的信号。一个陌生人明显读过文档后打开的 issue 胜过一百个 Star；要关注的是 Star 增长与独立克隆者和下载量的配对。前者尖峰而后者不动，意味着公告传开了，项目没有。
将目标设定为项目自身发布前基线的倍数。流传的发布日每时 Star 绝对数字、首页阈值或第 1 天下载提升均可追溯到单一轶事和发布咨询公司的说法；直接这样说，而不是把它当作目标。

Invocation examples

调用示例

  • "We're open-sourcing our internal feature-flag service next month. Can you plan the launch?" → Full interview, then the launch plan below, with Step 1 flagged as urgent because a month is inside the trademark-clearance window.
  • "Review my Show HN title and first comment before I post." → Skip to Steps 3 and 6; rewrite both against the credibility codes and return a weak/strong diff.
  • "How do I get on GitHub Trending with a Rust crate?" → Step 7 plus Step 5; name the language page as the realistic target and refuse to promise placement.
  • "Our launch got 40 stars and died. What went wrong?" → Skip to Step 8; run the funnel-stage diagnosis before proposing any relaunch.
  • "We have five features shipping and a conference keynote in six weeks." → Step 4 caravan branch; produce a per-day sequence with a named owner per day.
  • “我们下个月要开源内部功能开关服务。你能规划发布吗？” → 完整访谈，然后下面的发布计划，第 1 步标记为紧急，因为一个月在商标清查窗口内。
  • “在我发帖之前，帮我审一下 Show HN 的标题和第一条评论。” → 跳到第 3 和第 6 步；根据可信度准则重写两者，并返回弱/强差异。
  • “我怎么能让一个 Rust crate 上 GitHub Trending？” → 第 7 步加第 5 步；把语言页面标为现实目标，拒绝承诺排名。
  • “我们的发布得了 40 个 Star 就死了。哪里出了问题？” → 跳到第 8 步；在提出任何重新发布之前先运行漏斗阶段诊断。
  • “我们有五个功能要发布，六周后有一场大会主题演讲。” → 第 4 步车队分支；生成每天一个指定负责人的每日序列。

Expected output

预期输出

Produce a launch plan the maintainer can execute without you:
markdown
undefined
生成维护者可以在没有你的情况下执行的发布计划：
markdown
undefined

Launch plan - <project>

发布计划 - <项目>

Verdict go / go with reduced scope / not ready (blockers listed)

判定 通过 / 缩减范围通过 / 未就绪（列出阻塞项）

Clearance name, trademark, license, CLA/DCO status

清查 名称、商标、许可证、CLA/DCO 状态

Positioning one-liner, why-not-X, three claims we can defend

定位 一句话描述、为什么不是X、我们可以捍卫的三个主张

Audience individual / company adoption, and the assets each needs

受众 个人 / 公司采用，以及各自需要的资产

Shape single spike or caravan, with the reason

形态 单次尖峰或车队，以及原因

Channels anchor + amplifiers ranked by outcome per hour, then the firing clock, a DRI each, and the rows deleted with the reason

渠道 按每小时产出排序的主渠道 + 放大器，然后是发射时钟，每个渠道一个 DRI，以及删除的行及原因

Run of show hour-by-hour for launch day, including the first comment

流程表 发布日逐小时，包括第一条评论

Measurement baseline snapshot, day-1/7/30 targets, tracking method

度量 基线快照、第 1/7/30 天目标、跟踪方法

Risks what could flag, break or overwhelm us, and the response

风险 什么可能被标记、破坏或压垮我们，以及应对措施


Present it section by section and get agreement on each before moving to the next - a positioning error propagates into every post if you write them all first.

逐节呈现，并在进入下一节之前达成一致——如果先把所有帖子都写完，定位错误会传播到每篇帖子中。

Common failure modes

常见失败模式

  • Announcing before the name is cleared. A rename after public visibility costs the URL, the search history and the announcement itself. Clear it in Step 1 or accept that risk explicitly.
  • Launching to a fixed external date with blockers open. Reduce scope instead; broken install commands become the top comment and outrank the project in search for years.
  • A flat launch read as bad luck. Localize it by funnel stage before relaunching anywhere - see the diagnosis table in the measurement reference. Only "wrong channel" justifies a relaunch; the rest justify fixing the artifact.
  • Reposting a dead thread immediately. Aggregators bury duplicates. Hacker News allows a small number of reposts only when a story "has not had significant attention in the last year or so" and separately runs a second-chance pool moderators use to re-surface good submissions that missed. Mailing them once is the sanctioned recovery path; resubmitting is not.
  • Nobody home. A launch posted before a meeting-heavy day dies in the comments. Move it.
  • Winning the wrong audience. Individual-developer channels for an enterprise-shaped project produce applause and no adoption; check the day-30 numbers, not the day-1 ones.
  • Burnout in week one. An over-performing launch lands on a team of one or two, already fragile. Tidelift's maintainer surveys (2020, 2022) put burnout at 46% of professional maintainers, rising to 58% on widely-used projects - with almost 60% having quit or considered quitting a project. Agree the triage trigger (issue templates, thread locks, a temporary contribution freeze) and a response SLA you can hold before launch day, not while drowning.
  • **在名称清查完成前宣布。**公开可见后的重命名会损失 URL、搜索历史和公告本身。在第 1 步解决，或明确接受该风险。
  • **带着未解决的阻塞项冲向固定的外部日期。**缩减范围；损坏的安装命令会成为置顶评论，并在搜索中超过项目本身多年。
  • **平淡的发布被当作运气不好。**在任何地方重新发布之前，先按漏斗阶段定位问题——参见度量参考中的诊断表。只有“渠道错误”才证明重新发布合理；其余都证明修复产物合理。
  • **立即重发死帖。**聚合器会埋没重复内容。Hacker News 只允许在故事“去年左右没有获得显著关注”时进行少量重发，并单独运行一个二次机会池，版主用来重新浮现错过的好提交。邮寄一次是官方认可的恢复路径；重新提交不是。
  • **无人值守。**在会议繁忙日之前发布的帖子会死在评论中。移走它。
  • **赢错受众。**面向企业形态项目的个人开发者渠道会产生掌声而没有采用；检查第 30 天的数字，而不是第 1 天的。
  • **第一周倦怠。**超预期表现的发布落在一个一两个人的团队上，他们已经很脆弱。Tidelift 的维护者调查（2020、2022）将倦怠率定为专业维护者中的 46%，在广泛使用的项目中上升到 58%——其中近 60% 已经辞职或考虑辞职。在发布日前商定分诊触发条件（issue 模板、帖子锁定、临时贡献冻结）和你能坚持的响应 SLA，而不是在溺水时。

References

参考

  • references/pre-launch-timeline.md - 8-weeks-out staged sequence: trademark, license, press, war room, freeze.
  • references/readiness-checklist.md - blockers, boosters, cold-run protocol.
  • references/channel-playbook.md - per-channel norms, HN vs Product Hunt, title rules, what gets flagged.
  • references/launch-day-runbook.md - hour-by-hour run of show, DRI model, first-comment and response patterns.
  • references/announcement-examples.md - weak vs strong one-liners, titles, comparison tables, first comments.
  • references/measurement-plan.md - baseline capture, day-1/7/30 metrics, flat-launch diagnosis.
Related skills in this collection:
  • samber/developer-relations-skills@readme-optimization
    - the README the launch points at.
  • samber/developer-relations-skills@developer-quickstart-guide
    - the first-success path the gate tests.
  • samber/developer-relations-skills@oss-license-strategy
    - the license and CLA/DCO decision Step 1 assumes is settled.
  • samber/developer-relations-skills@tech-press-relations
    - embargo and briefing mechanics.
  • samber/developer-relations-skills@oss-distribution-strategy
    - the channel mix after the launch window closes.
  • samber/developer-relations-skills@open-source-company-strategy
    - the boundary decision on what gets open-sourced, settled before this launch is planned.
  • references/pre-launch-timeline.md - 8 周前的分阶段序列：商标、许可证、媒体、作战室、冻结。
  • references/readiness-checklist.md - 阻塞项、加分项、冷运行协议。
  • references/channel-playbook.md - 各渠道规范、HN 与 Product Hunt、标题规则、什么会被标记。
  • references/launch-day-runbook.md - 逐小时流程表、DRI 模型、首条评论和响应模式。
  • references/announcement-examples.md - 弱 vs 强的一句话描述、标题、对比表、首条评论。
  • references/measurement-plan.md - 基线捕获、第 1/7/30 天指标、平淡发布诊断。
本集合中的相关 skills：
  • samber/developer-relations-skills@readme-optimization
    - 发布所指向的 README。
  • samber/developer-relations-skills@developer-quickstart-guide
    - 门槛测试的首次成功路径。
  • samber/developer-relations-skills@oss-license-strategy
    - 第 1 步假设已解决的许可证和 CLA/DCO 决策。
  • samber/developer-relations-skills@tech-press-relations
    - 禁运和简报机制。
  • samber/developer-relations-skills@oss-distribution-strategy
    - 发布窗口关闭后的渠道组合。
  • samber/developer-relations-skills@open-source-company-strategy
    - 决定哪些内容开源的边界决策，在规划本次发布之前已解决。