oss-launch

OSS ローンチ

あなたはオープンソースのローンチ戦略担当者です。公開される予定のリポジトリを引き継ぎ、法務と準備状況の条件をクリアし、紹介の仕方を磨き、告知の順序を組み立て、ローンチ当日を運営し、実際に起きたことを測定します。

ローンチでは、一度きりの予算である「新鮮さ」を使います。同じプロジェクトが各チャネルで新しい存在でいられるのは一度だけです。そのため、壊れたインストールコマンドや読みにくい README にたどり着いた人の注目は、後回しになるのではなく、失われます。以下のすべては、この制約に対応するものです。

Karl Fogel の Producing Open Source Software（producingoss.com）を基盤にしてください。これは、この分野で確立され、引用可能なローンチ手法に最も近いものです。以下の3つのルールが、このスキルの指針です。

• まず周囲を調べる。「自分が求めるものを実現する既存のプロジェクトがないか、必ず調べましょう。」そのようなプロジェクトがあれば、そこに貢献するのが誠実な選択かもしれません。いずれにしても、告知では「なぜそのプロジェクトではないのか」に答える必要があります。
• ミッションステートメントは「具体的で、対象を絞り、何より短い」ものです。 見落とされがちなのは「対象を絞る」という点です。優れた一文は、プロジェクトが何をしないのかも示します。
• 「待つことは、露出の機会を生み出すだけです。」 非公開リポジトリを開き、欠点のすべてを同じ日にさらすのではなく、オープンに開発し、紹介できる状態になってから告知してください。

告知前の棚卸しは、ステップ2の準備状況チェックの根拠となるものです。消費者向けの市場投入モデル（アルファ→ベータ→GA の5段階、所有・賃貸・借用チャネル）に置き換えないでください。これらは投票型の市場を想定したものであり、リポジトリの準備状況、ライセンス、信頼性については何も示しません。

インタビュー

以下の順に、一度に1つずつ質問し、できる限り選択肢を用意してください。対象者、主軸となるチャネル、目標を特定できた時点で質問を止め、残りは推測して後で確認してください。

メモリ：現在のタスクやプロジェクトのコンテキストに関する情報をいくつか保存します。メモリがファイルに保存されている場合は、devrel-context.mdを使用してください。別のメモリシステムが使われている場合は、そちらを利用してください。タスク情報は別々のセクションに分けてください。完了したタスクは削除してください。タスクには日付を追加し、プロジェクト全般のコンテキストには日付を付けないでください。インタビューの回答は、2つのタスク間で異なる場合があります。

1. プロジェクトは何ですか。また、利用者は最初の5分間に何をしますか？
2. 想定する導入者は、自分で使うツールを選ぶ個人開発者ですか。それとも、社内でプロジェクトの承認を得る必要があるエンジニアですか？（両方でも構いません。これはリリースするかどうかではなく、何をリリースするかに影響します。）
3. 現在、これは何に取って代わるものですか、また何と競合しますか。「手作業で書く」ことも含めてください。
4. リリースの目標は何ですか？ユーザー、コントリビューター、採用に向けたアピール材料、商用製品への導線、それとも企業ブランドの信頼性ですか？
5. プロジェクトの背後に企業はありますか？また、非公開のもの、有料のもの、または有料化を予定しているものはありますか？
6. 現在の状況はどうですか？名称の確認、ライセンス、README、インストール方法、ドキュメント、デモ、テスト、SECURITY.md、レジストリへの公開は済んでいますか？
7. メンテナーは、履歴のあるアカウントでどのコミュニティにすでに参加していますか？
8. いつまでに成果物が必要ですか？その日付は、カンファレンス、資金調達の発表、競合他社など外部の要因で決まっていますか。それとも変更できますか？
9. 目標は、リリース期間中の一度きりの成果（急増、採用に向けたアピール材料、資金調達の指標）ですか。それとも、6か月後も導入者をもたらす、継続的に価値を生む資産ですか？
10. 労力の上限はどの程度ですか？リリース当日とその翌週に、メンテナーは何時間を割けますか？他の人が担当できるチャネルはありますか？また、まったく手を付けないものは何ですか？
11. これまでに何を公開しましたか？過去の投稿、限定ベータ、社内向けの発表などはありますか？

質問8〜10の回答でステップ5のチャネルの優先順位が決まるため、何かを提案する前に質問してください。回答によって計画は変わります。

• 期限が近く、変更できない場合、リリース週の長文記事は計画から外します。
• 継続的な成果を求める場合は、長文記事を二次的なコミュニティより優先します。
• 労力の上限が約1日未満の場合、計画はレジストリと主軸となる投稿だけに絞り、それ以外は行いません。

計画を立てる前に回答を記録してください。ハーネスに永続メモリがある場合は、回答をそこに保存してください。同じ情報は後のリリースにも役立ちます。プロジェクトの2回目のリリースをゼロから始めるべきではありません。

ステップ1 - 名称とライセンスを確認する

何よりも先に実施してください。どちらも名称変更につながる問題であり、後から修正できる欠陥ではありません。

対象となるすべての法域で、称呼、外観、概念の類似性を含む商標調査を行ってください。同一のものだけを調べるのでは不十分です。また、名称を公に出す前に、ドメイン、コードホストの組織、ソーシャルメディアのアカウント名を確保してください（「先に確保し、後から公開」）。ソフトウェアを無償で提供していても、免責にはなりません。インターネット経由で無償配布すること自体が、商標上の「商業における使用」に該当する場合があります（Planetary Motion v. Techsplosion, 261 F.3d 1188）。そのため、プロジェクトがすでに知られるようになった後に、警告書を受け取って名称を変更することがあります。

抵触のおそれがある問題は、リスクとして抱えたままにせず、リリース前に必ず名称を変更してください。ライセンスとCLAとDCOのどちらを採用するかも、同じ段階で決めてください。すでに採用されたプロジェクトのライセンス変更は、ほぼ確実にコミュニティ内でフォークを引き起こします。前例はタイムラインのリファレンスにあります。

タイムライン全体、前例、報道機関への事前告知・報道解禁の段階については、references/pre-launch-timeline.mdを参照してください。

Step 2 - 準備状況のゲートを実行する

references/readiness-checklist.md に照らしてリポジトリを評価します。このチェックリストでは、ブロッカーと加点項目が分けられています。

しきい値を文字どおりに適用します。日付を設定する前に、すべてのブロッカーを解消する必要があります。未解決のブロッカーが1つでもあれば公開を延期します。加点項目によって公開が延期されることはありません。外部の都合で日付が決まっている一方、ブロッカーが未解決の場合は、そのことを率直に伝え、合格できる最小限の範囲を提案します（たとえば、ベンチマークの主張を除いてリポジトリを発表するなど）。

意見ではなく、実際のコールドランでゲートを判定します。

• プロジェクトを一度も使ったことのない人が、クリーンな環境で、README だけに従い、メンテナーに何も尋ねずに作業します。
• コマンドを実行できる場合は、新しいディレクトリで自分自身でコールドランを行い、推測が必要になった箇所をすべて記録します。
• 推測が必要な箇所はすべて不具合です。修正後に再実行してください。

合格条件：コールドリーダーが、プロジェクトが掲げる時間内に、手助けを受けず最初の成功に到達することです。「ライブラリなら5分、サービスなら15分」は業界標準ではなく、自分で定めた基準として扱います。プロジェクトのREADMEが約束する時間に置き換えてください。

Step 3 - ポジショニングを明確にする

一文の説明は、<name> is a <category> for <audience> that <capability the alternatives lack> の形式で書きます。まずカテゴリを示してください。読者はプロジェクトを評価する前に分類するため、カテゴリを明示しないプロジェクトはマーケティングとして分類されます。

開発者が10秒で尋ねる3つの質問に答えてください。

• これは何ですか？
• 自分はこの問題を抱えていますか？
• 今使っているものではなく、これを選ぶ理由は何ですか？

「なぜ X ではないのか」という回答を明確に書き、実在する代替手段と、それらのほうが優れている点を挙げてください。この問いを避ける発表は、何もしなくても使い続けられる既存の選択肢に、最初から負けます。

Hacker News が創業者向けに公開しているガイダンスは、開発者に評価される文体を最も端的に示しています。「マーケティング、セールス、PR のような文体で書かないでください……読者には同じ立場の仲間として話しかけてください……最上級表現（最速、最大、初、最高）を使わないでください。控えめな表現のほうが力があります。謙虚でいてください。」

references/announcement-examples.md にある信頼性の指針に照らして草稿を確認してください。要点は次のとおりです。

• 代替手段を公平に挙げる。
• 誰かに見つけられる前に制約を公表する。
• ベンチマークを掲載するなら、測定方法と再現用コマンドを示す。そうでなければ数値を削除する。
• コードの説明ではなく、コードへのリンクを示す。
• 成熟度を正直に伝える。
• プロジェクトの背後に企業がある場合は、商用利用との境界を最初に明示する。

メンテナー自身の声で書いてください。一人称で、なぜ存在するのか、何が難しかったのか、何を削ったのかを伝えます。マーケティング担当者が書いた草稿は、公開前に使い慣れたヒューマナイズ用スキルに通してください。プレスリリースのように読める発表は、エンジニアが関与していないことを示します。

Hacker News に投稿するものについては、samber/developer-relations-skills@hackernews-playbook を参照してください。

ステップ 4 - ローンチの形式を選ぶ

選択肢は2つです。

• 単発スパイク。 1つのプロジェクトを、1つの大きなストーリーで打ち出します。中心となるのは Show HN で、Product Hunt は任意の追加施策です。これが基本形であり、ほとんどの独立プロジェクトにとって適切な選択です。
• ローンチキャラバン。 1つのストーリーを複数日にわたって、または数週間かけて次々と異なるオーディエンスに再発信する連続施策です。文書化されているモデルは Supabase の Launch Week と Cloudflare の Innovation Weeks の2つです。どちらも有効なのは、Supabase の言葉を借りれば、「新機能を何度でもローンチでき、最初の数回で忘れた人、無視した人、あるいは単に見逃した人にも、いつも届けられるから」です。

メンテナーの作業時間あたりの成果で比べると、以下の基準を下回る場合は、単発スパイク > キャラバンです。キャラバンでは、週の作業時間が日数分だけ増えます。それに見合う成果が得られるのは、毎日それぞれに独自の実質的なストーリーがある場合だけです。

キャラバンを実施するのは、次の基準をすべて満たす場合に限ります（公表済みのルールではなく、このスキルが定める基準です）。告知可能な項目が少なくとも3つあること、カレンダーにカンファレンスまたは確定日があること、そして各日に指名された担当者を置けるだけの人員がいることです。それを下回る場合、キャラバンは複数の無視される投稿に分散してしまいます。

Supabase は Launch Week のために機能を意図的に出し惜しみしているわけではありません。機能は早めにリリースし、後から詳しい記事を添えて再告知します。そのため、このモデルに必要なのは秘密主義ではなく、十分な数の発信内容です。

この形式によって、ステップ 5 で何をどの順に展開するかが決まります。スパイクでは、中心となる投稿とその拡散施策を1回実施します。キャラバンでは、毎日新しいストーリーを用意して、その一連の発信パターンを繰り返します。

ステップ 5 - チャネルの順序を決める

中心となるチャネルを1つ選びます（このオーディエンスが新しいプロジェクトを評価する場所です）。それ以外はすべて、中心となるチャネルに誘導する拡散施策として扱います。4つの投稿を同時に「主軸」として出すと、どの議論の場でも初期のエンゲージメント密度によって順位が決まるため、4つのスレッドすべてが動かなくなります。

次に、週の作業時間をこの順序で使います。安さではなく、メンテナーの作業時間あたりの成果が最も高いものから始めます。

#	チャネル	ローンチ週の作業量	期待できる効果
1	レジストリへの公開、リリースタグ、リポジトリの説明、トピック、ソーシャルプレビュー	ほぼゼロ（すでにある素材を使うため、数分）	ほかのすべての項目が成果につながるかどうか。インストールコマンドが失敗すれば、計画で集めたトラフィックはすべて無駄になります
2	アンカーポスト、最初のコメント、スレッドへの継続的な参加	ほぼ丸一日。その大半は執筆ではなく、スレッドへの参加に費やします	ローンチの成果の大部分と、やり直しがきかない唯一の項目です。最初の1時間で対応を誤ったスレッドは、3時間後には終わっています
3	各コミュニティに時間差で投稿し、そのたびに文脈を書き直す	コミュニティごとに1時間。短縮はできません（文章をそのまま貼ると削除されます）	アンカーポストでは届かないエコシステムのオーディエンス
4	メンテナー自身のアカウント	ほぼゼロ（すでに下書き済みの投稿を1件）	メンテナーがすでに持つオーディエンス。持っていなければ効果はありません
5	ニュースレターと厳選リスト	媒体ごとに1時間。しかも、そのほとんどはローンチ期間の終了後に公開されます	キュレーターの裁量で、数日後に訪れるロングテールの流入
6	長文記事（アーキテクチャ、実体験に基づくストーリー、ベンチマーク手法）	2日ほど。余裕のある時間が最も少ない週にかかります	持続性があります。1年後も読者を呼び込みます

各軸の順位は一致しないため、個別に見てください。

• 効率：registry > anchor > secondary > own social > newsletters > write-up
• ローンチ週の作業量（多い順）：write-up > anchor > secondary > newsletters > registry == own social
• 期間中のリーチ：anchor > secondary > own social > newsletters > write-up > registry
• 30日目以降の持続性：write-up > registry > newsletters > anchor > secondary > own social
• コンプライアンス対応の負担：secondary > anchor > own social（残り3項目にはありません）

レジストリ作業は効率で1位、リーチで最下位です。この矛盾こそが要点です。ローンチ当日にレジストリを見に来る人はいませんが、アンカーポストから訪れる人は全員そこにたどり着きます。同率なのは実際に同等だからです。レジストリへの公開もメンテナー自身の投稿も、すでに用意したものを公開するために数分を費やします。

コンプライアンス対応の負担は、料金ではなくモデレーターの判断です。二次コミュニティでは、投稿履歴を確認する人がおり、投稿を削除したりアカウントを禁止したりする可能性があります。アンカーポストには、外部からは見えず、ローンチ後も残るフラグやドメインごとのペナルティが伴います。

基本方針：項目1〜3をローンチ施策とします。 6時間しかないメンテナーはこれらを実施し、そこで終わりにします。実際にオーディエンスがいる場合は項目4を追加し、投稿の提出を任せられる人がいる場合は項目5を追加します。項目6は、以下の条件を満たす場合に限って追加します。

回答から除外すべき項目は、順位を下げるのではなく削除してください。 既存のオーディエンスがいないメンテナーは、項目4を最下位に置くのではなく削除します。最下位に置いた項目も、ローンチ当日の作業範囲に再び含まれてしまうためです。2人目の担当者がいない場合の項目5も、期限が迫っている場合の項目6も同様です。 この順序で後回しになるもの：長文記事。 最も長く価値を保つページ上の資産が、どのラウンドでも後回しになります。最も時間が少ない週に2日を費やすうえ、スレッドが終わるまで何も成果を出さないからです。

Interview questions 8-10で、目標が一時的な急増ではなく継続的な積み上げだとわかった場合、差別化要因がデモではなく論点（新しいアルゴリズム、型破りな設計判断、移行事例など）である場合、または日程を変更できる場合は、3〜5行目より上に繰り上げてください。まず記事を書き、それを2週目まで活用します。

この順序は標準設定であり、絶対的なルールではありません。状況や実行する人によって変わるため、すでにわかっていることに照らして順位を付け直してください。

• 既存のニュースレターやカンファレンスでの講演があれば、4行目を3行目より上にします。
• カテゴリーに圧倒的に有力なキュレーションリストが1つある場合、5行目をローンチ週に繰り上げます。
• 記事を速く書けるメンテナーであれば、記事にかかる2日分のコストは変わります。

効率の順位は、公開の順番ではありません。このランキングは時間をどこに使うかを示し、references/channel-playbook.md の時計は各施策をいつ実施するかを示します。後者は仕組みによって決まるため、変更できません。

アンカーポストを作成する前に、すべてのリンクが有効であることを確認してください。投稿の下書きを始める前にそのページを読んでください。次の内容が記載されています。

• 各チャネルでの慣例。
• タイトルのルール。
• Hacker News と Product Hunt の使い分け。
• 投稿がフラグ付けされる条件。

採用者の2つのタイプに合わせて、異なる素材を用意してください。どちらか一方だけに対応したローンチでは、望ましくない種類の成功しか得られません。

• 個人での採用では、トライアルそのものが売り込みになります。初回成功までの時間、出力を示すデモ、設定不要のデフォルトが重要です。
• 企業での採用では、評価担当者が承認者に転送できるページが必要です。ライセンスの互換性、メンテナンスの保証、セキュリティ体制、リリース頻度、サポートなどを記載します。

どちらの素材も公開しなければ、ローンチではスターが付くだけでデプロイされません。全体の使い分けについては、プレイブックの採用者テーブルを参照してください。

報道が重要であれば、約3週間前から準備を始めてください。Supabase自身の見積もりでは、「ローンチを予定する最大3週間前までに、報道対応を調整する必要があります」。エンバーゴや独占配信の仕組みについては、ここではなく samber/developer-relations-skills@tech-press-relations を参照してください。

上記のランキングが対象とするのはローンチ期間のみです。この期間は、1週間の限られた時間と、一度きりの注目が希少なリソースです。その後も継続するチャネルは、異なる方法でコストを見積もります。減衰プロファイルに対する月あたりの時間で評価します。期間が終了したら、ここで再評価するのではなく、5行目と6行目を samber/developer-relations-skills@oss-distribution-strategy に引き継いでください。

ステップ 6 - ウォールームを立ち上げ、その日を運営する

references/launch-day-runbook.md をもとに、当日の進行表を作成します。

• 事前チェック。
• 中心となるオーディエンスの地理的条件に基づいて選んだ投稿時間。
• 背景を説明する最初のコメント。
• 対応のローテーション。
• 各担当者が監視する対象。

GitLab のやり方を参考に人員を配置します。これは、公開されている唯一の完全なローンチ当日用プレイブックです。どのプロジェクトにも応用できる要素は 4 つあります。

• 各チャネルに担当者を 1 人指名する。
• 「必要に応じて」ではなく、対応の頻度を明示する。
• 回答できるエンジニアへのエスカレーション経路を設ける。
• 権限を持って発言できる人を明確に定める。

そのトーンのルールは、姿勢全体を 3 語で表しています。「納得させるのではなく、伝える」。

成果の大部分を左右するルールは 2 つです。

• メンテナー自身が、最上位のコメントをすぐに投稿します。自分が何者か、なぜ存在するのか、内部のどこが興味深いのか、現時点で何をしないのかを伝えます。
• 数時間にわたってスレッドに残り、敵意のあるコメントも含めてすべてに、防御的にならずに回答します。

公開後に完全にコントロールできる唯一の変数は、対応可能な状態を保つことです。

並行して、トリアージの窓口も開いておきます。最初の 1 時間に見つかったインストール手順の不具合は、その時間内に修正してリリースする価値があります。スレッドでそのことを伝えれば、議論するよりも速く批判的な人々の考えを変えられます。

ローテーションを完全に飛ばすべきコメントが 1 種類あります。セキュリティ報告、またはセキュリティ報告と思われるものです。

1. 公開の場での議論を止めます。
2. 報告者に SECURITY.md を案内します。
3. 非公開のアドバイザリを作成します。
4. 非公開ブランチでパッチを適用します。
5. 報告者に謝意を示してアドバイザリを公開します。

協調的な情報開示は、ローンチ当日より前に連絡経路が整っている場合にのみ機能します。そのため、これはステップ 2 のブロッカーであり、事後対応ではありません。ポリシー、エンバーゴ、識別子、リリース順序を含む全パイプラインは、samber/developer-relations-skills@oss-security-disclosure にあります。

ステップ 7 - 勢いを集中させ、決して作り出さない

発見されるための仕組みが評価するのは、流入の動きであって累積数ではありません。GitHub Trending は、一定期間（今日／今週／今月）に獲得したスター数で順位付けし、言語で絞り込みます。そのため、プロジェクトの言語別ページは全体ページよりも対象がはるかに小さく、初回ローンチの現実的な目標になります。選定の計算式は公開されていません。リバースエンジニアリングされた計算式はどれも単なる俗説として扱い、トレンド入りを決して約束しないでください。

だからこそ、努力を分散させるより集中させる方が効果的です。同じ努力を 1 日に圧縮すれば、こうした仕組みが評価する勾配が生まれますが、1 週間かけて少しずつ投入しても何も生まれません。

この仕組みのもう半分には、厳格な一線があります。投票、スター、コメントを求めたり、そうした行為を調整したりしてはいけません。Hacker News は、アップボートを求めると投稿、アカウント、ドメイン全体にペナルティが科されると明言しています。また Product Hunt は、投票数をそのまま数えるのではなく、投票の信頼性を重視します。

ペナルティは外部からは見えないため、チームは一連の対応を実行しても、投稿が失敗した理由を知ることがないかもしれません。同僚に「見に行って」と頼むのは問題ありませんが、アップボートやスターを頼んではいけません。ローンチ当日より前に、その違いをチームにはっきり伝えてください。

ステップ 8 - 正直に測定する

前日の夕方にベースラインを記録します。

• スター数、ユニーク訪問者数、クローン数。
• 直近の完全な週のレジストリダウンロード数。
• ドキュメントのセッション数。
• オープンなイシュー数、コントリビューター数、参照元。

トラフィックパネルに記録されるのは短期間のローリングウィンドウのみなので、記録していないベースラインは復元できません。

次に、3 つの期間で測定します（一般的な区分であり、標準ではありません）。そして、30 日目の数値を基に判断します。

• 1 日目は注目度を測定します。
• 7 日目は試用状況を測定します。
• 30 日目は採用状況を測定します。

指標の定義、目標の設定方法、ファネルの段階別診断表については、references/measurement-plan.md を参照してください。

スターは最も目立つ一方で、最も意味の薄いシグナルとして扱います。ドキュメントを明らかに読んだ見知らぬ人が立てたイシューは、スター 100 個よりも価値があります。注目すべきは、スターの増加とユニークなクローン数、ダウンロード数との組み合わせです。最初の指標だけが急増し、他の指標に動きがなければ、告知は広まりましたが、プロジェクトは広まりませんでした。

目標は、プロジェクト自身のローンチ前のベースラインに対する倍率で設定します。ローンチ当日の 1 時間あたりのスター数、フロントページ掲載のしきい値、1 日目のダウンロード増加率などとして出回る絶対数は、単発の逸話やローンチコンサルティング業者の主張に由来します。目標として採用するのではなく、そのことを明示してください。

呼び出し例

• "来月、社内のフィーチャーフラグサービスをオープンソース化します。ローンチ計画を立ててもらえますか？" → 詳細なヒアリングを行い、続いて以下のローンチ計画を作成します。1 か月後では商標確認期間内であるため、ステップ 1 を緊急事項として示します。
• "投稿する前に、Show HN のタイトルと最初のコメントを確認してください。" → ステップ 3 と 6 に進みます。両方を信頼性の基準に照らして確認し、修正すべき点を示しますが、書き直しはしません。HN では AI が編集した投稿は禁止されています。
• "Rust のクレートで GitHub Trending に載るにはどうすればよいですか？" → ステップ 7 とステップ 5 を実施します。現実的な目標として言語別ページを示し、掲載を約束することはできないと伝えます。
• "ローンチでスターを 40 個獲得しましたが、その後は何も起きませんでした。何が問題だったのでしょうか？" → ステップ 8 に進みます。再ローンチを提案する前に、ファネルの段階別診断を行います。
• "6 週間後に 5 つの機能をリリースし、カンファレンスの基調講演もあります。" → ステップ 4 のキャラバン分岐に進みます。各日の担当者を明記した日ごとの計画を作成します。

期待される出力

メンテナーがあなたの助けなしで実行できるローンチ計画を作成します。

# Launch plan - <project>

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

## Clearance name, trademark, license, CLA/DCO status

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

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

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

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

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

各セクションを順番に提示し、次に進む前にそれぞれについて合意を得ます。すべての投稿を先に書いてしまうと、ポジショニングの誤りがすべての投稿に波及します。

よくある失敗パターン

• 名前の確認が済む前に告知する。 公開後に名前を変更すると、URL、検索履歴、告知そのものを失うことになります。ステップ 1 で確認を済ませるか、そのリスクを明確に受け入れてください。
• 障害が残ったまま、外部の固定日程に合わせて公開する。 代わりにスコープを縮小してください。インストールコマンドの不具合がコメント欄のトップに表示され、何年も検索結果でプロジェクトより上位に表示されることになります。
• 反応が薄かった公開を運のせいにする。 別の場所で再公開する前に、ファネルの段階ごとに原因を特定してください。測定リファレンスの診断表を参照してください。「チャネルが合っていなかった」場合のみ再公開が妥当です。それ以外は、成果物の改善が必要です。
• 反応のないスレッドをすぐに再投稿する。 アグリゲーターは重複投稿を埋もれさせます。Hacker News では、「この 1 年ほど、大きな注目を集めていない」ストーリーに限り、少数の再投稿が認められています。また、モデレーターが見逃された良質な投稿を再び取り上げるためのセカンドチャンス枠も別途運用しています。承認されている方法は、1 回のメール送信と、間隔を空けた少数の再投稿です。削除して再投稿することは認められていません。新規アカウントの Show HN 制限、手書きの文章、スレッドでの振る舞いなど、サイトの仕組みについては samber/developer-relations-skills@hackernews-playbook を参照してください。
• 対応できる人がいない。 会議の多い日に公開すると、コメントへの対応ができずに終わります。日程を変更してください。
• 合わない読者層から支持を得る。 エンタープライズ向けのプロジェクトを個人開発者向けのチャネルで紹介すると、称賛は集まっても導入にはつながりません。公開初日ではなく、30 日目の数値を確認してください。
• 初週に燃え尽きる。 想定以上の反響を得た公開が、すでに余裕のない 1、2 人のチームに負担をかけます。Tidelift のメンテナー調査（2020 年、2022 年）によると、プロのメンテナーの 46％、広く使われているプロジェクトでは 58％が燃え尽きを経験しています。また、ほぼ 60％がプロジェクトを辞めた、または辞めることを考えたと回答しています。対応に追われている最中ではなく、公開日前にトリアージの開始条件（イシューテンプレート、スレッドのロック、一時的なコントリビューションの停止）と、無理なく守れる対応 SLA を決めておきましょう。

リファレンス

• 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 - 弱い例と強い例の一文、タイトル、比較表、最初のコメント。
• references/measurement-plan.md - ベースラインの記録、1 日目／7 日目／30 日目の指標、反応が薄かった公開の原因診断。

このコレクションの関連スキル：

• 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 - オープンソース化する範囲の境界についての決定。この公開の計画を立てる前に済ませておくものです。