あなたのオープンソースを有名にする方法

 (evilmartians.com)
37 ポイント 投稿者 GN⁺ 2025-03-17 | 1件のコメント | WhatsAppで共有

オープンソースを有名にする前に知っておくべきこと

  • オープンソースで有名になったり、お金持ちになったりしたいなら、それは間違ったアプローチ
  • 人気のあるプロジェクトを作るより、ブログを書いたりカンファレンスで発表したりするほうが効果的
  • Redux と React Router は人気プロジェクトだが、メンテナーにソーシャルメディアのフォロワーが多いわけではない → プロジェクトの人気が個人の人気につながるわけではない

履歴書に書くためにオープンソースを作らないこと

  • オープンソースへの参加が必須だという認識は誤り
  • 有名になるためにオープンソースを始めても、成功は保証されない
  • 良いプロジェクトでも Star が 1 つしか付かなければ落ち込むことがある
  • 採用でオープンソース活動が役立つことはあるが、自分で新規プロジェクトを作るより 既存の有名プロジェクトに貢献すること のほうが効果的

まずは貢献から始める

  • 大きなオープンソースプロジェクトで ドキュメント修正 や バグ修正 から始める
  • コードを書くより PR を作るほうがずっと簡単
  • 良いオープンソースを作る最良の理由は 世界を変えたいから であること

オープンソースで世界を変える方法

  • PostCSS を作った理由は、CSS ツールのエコシステムを多様化し、CSS 処理をもっと簡単にするため → 成功した
  • 人気と成功は重要な要素

人気プロジェクトの秘訣

> プロジェクトの人気 = 認知度 + プロモーション + ユーザーへの利点 + 運

  • 人気のある開発者が作ったプロジェクトは、より簡単に人気を得る傾向がある → 不公平かもしれないが現実
  • 人気の原因を理解し、戦略的にアプローチする必要がある

人々がオープンソースを選ぶ方法

  • 人は合理的にツールを選ばない
  • 多くは GitHub の Star 数を見て決める
  • あるいはカンファレンスで言及されたフレームワークに従うことが多い

人々が実際に情報を読む方法

  • ユーザーは README やドキュメントを最初から最後まで読まない
  • 情報は「プログレッシブ JPEG」のように、簡潔に段階的に提供するべき
  • 最初のブロックで利点を明確に説明しなければならない

人気を得る戦略

  • ソーシャルメディアのアカウントをきちんと整える必要がある
    • 著者は最初、英語のソーシャルアカウントを作らなかったため、人々が著者を見つけにくかった
    • 英語圏以外の開発者なら 英語のソーシャルメディアアカウント を作るのが有利
    • プロジェクトが言及されるときは プロフィールリンク を提供し、ユーザーがつながりやすくするべき
  • 現実的なマインドセットを持つ
    • 運は重要だが、それがすべてではない
    • 著者は 56 個のプロジェクトのうち 4 個だけ成功
    • 人気プロジェクトを作るまでに何度も失敗を経験した
    • 成功したプロジェクトは、継続的な試行と繰り返された失敗の結果
  • 失敗を当然のものとして受け入れる
    • 人気プロジェクトは マラソン のように長い時間をかけた努力が必要
    • 失敗はプロセスの一部 → 継続的な改善と反復的な試行が必要
    • 最初から失敗を想定 して始めつつ、作業のクオリティはあきらめてはいけない

オープンソースを人気にする方法 : README

  • README とドキュメントはプロジェクトの第一印象を決める
  • ユーザーは README を通じて、プロジェクトの価値を素早く把握できる必要がある
  • README は次のような経路でユーザーの目に触れる可能性がある
    • 発表、ブログ記事、ポッドキャストなど、さまざまなプロモーション経路
    • 結局 README にたどり着くため、注意して書く必要がある
  • 読者は README を最初から最後まで丁寧に読まない
  • したがって README の冒頭でプロジェクトの価値を明確に伝える必要がある
  • 最初のブロックで、人々がプロジェクトの利点を素早く理解できるようにすべき

> 質問: プロジェクトの価値を効果的に伝えられているか?

  • 人は余裕を持ってドキュメントを詳しく読まない
  • したがって、核心情報と利点を明確かつ簡潔に整理する必要がある
  • ドキュメントをうまく整理することで、ユーザー体験を改善し、プロジェクトの人気を高められる

1. ユーザーに利点を効果的に伝える

  • ユーザーにプロジェクトの利点を伝えることは、プロモーションと直接結びついている
  • 先に述べた成功の公式では、ユーザーに利点を提供すること が重要な要素

> プロジェクトの人気 = 認知度 + プロモーション + ユーザーへの利点 + 運

  • README、ドキュメント、または簡単な紹介文の中で、ユーザーへの利点を明確に伝えなければならない
  • 人気や評判ではなく実際の価値で注目されるためには、次の点を考慮する必要がある
    • 情報の読みやすさ: ユーザーが素早く要点を把握できること
    • スキャンしやすさ: 重要な情報がひと目で分かるように構成すること
    • 第一印象: 最初の数秒でプロジェクトの価値が明確に伝わること

2. メッセージを素早く効果的に伝える

  • README の最初のブロックには、次の 3 つの要素が必ず含まれていなければならない
    1. 明確な説明
    2. ユーザーにどう役立つのかを明確に示すこと
    3. 他製品との違いを明示すること
  • ユーザーがドキュメントを読むべき理由を、最初の文で明確に伝える必要がある
    • 最初の文が最も重要 → ほとんどのユーザーは最初の文だけ読んで、プロジェクトの価値を判断する
    • したがって最初のブロックで、プロジェクトの利点が明確に伝わるようにすべき
  • README の最初のブロック作成に 数日から 1 週間 ほど投資してもよい
  • PostCSS の最初のブロック作成には 約 1 週間 かかった
  • 最初のブロックに十分な努力を注ぐことで、プロジェクト成功の可能性が高まる

3. 製品を人々が理解しやすいように説明する

  • プロジェクトの説明は明確で直感的であるべき
  • かっこよく見える表現より 実質的な説明 のほうが重要
  • ❌ "Svelte is cybernetically enhanced web apps"
    • あまりにも曖昧 → 具体的にどんな利点があるのか不明確
  • ✅ "Svelte is a web UI framework with a unique compiler which generates smaller JS fixes."
    • 具体的で明確 → どんな問題を解決し、どんな利点があるのかを説明している
  • 同僚と居酒屋で話していると想像して説明を書く
    • "新しいツールを作ったの? それは何をするツール?" → 自然に説明する
  • 説明がまとまったら さらに簡潔に磨く
    • 説明を書いたあと 2〜4 回ほど推敲して短く明確に する

4. リストと太字テキストで情報を素早く伝える

  • 情報を明確に伝えるには リストと太字テキスト を積極的に活用するべき
  • Nano Stores の既存の説明（テキストブロック形式）
    • Nano Stores は、さまざまなフロントエンドフレームワークで使える状態管理ライブラリ
    • サイズが小さく、依存関係がない
  • 修正後の説明（リストと太字の強調を使用）
    • Nano Stores には次のような特徴がある:
      • 小さなサイズ: 286〜818 バイト（minified および brotlied）
      • 多様なフレームワークをサポート: React, Vue, Svelte, Angular など
      • 依存関係なし

  • 可読性を高めるポイント

    • リストを使う: 情報を構造化してひと目で把握できる
    • 太字テキストを使う: 核心情報を強調し、素早く認識できる
    • 簡潔な文章: 重要な情報だけを残し、不要な内容を削除する
      • テキストを減らしても、メッセージは明確に伝わらなければならない

5. コード例と画像を活用する

  • 複雑な概念は サンプルコード や 画像 を通じて分かりやすく説明できる
    • 「百聞は一見にしかず」という言葉のように、視覚資料は理解を助ける強力な道具

6. 実際の統計データを使う

  • 曖昧な表現や抽象的な約束 は信頼を得にくい
    • 実際の性能、サイズ、速度などの 具体的な統計 を示す必要がある

  • 例: Nano ID における実際の統計の活用

    • サイズの証明: Nano ID は 141 バイト と小さい → 明確な数値を提示
    • 速度の証明: Nano ID は UUID より 16% 高速 → ベンチマーク結果を提示
  • 効果的な統計データ活用のコツ
    • 数値化された性能データを提供する → 信頼性を強化
    • ベンチマーク結果を明示する → 他製品との差別化を強調
    • API の性能や使い方も実例とともに明確に示す
      • 性能、サイズ、速度などは具体的な数値とデータで証明する

7. ステップごとのスタートガイドを提供する

  • プロジェクトの利点が明確に伝わったら、次は 具体的な使い方 を提供する必要がある
  • ユーザーが README を読んでプロジェクトに興味を持ったなら、自然に次のステップへ進めるべき

  • 効果的なスタートガイド作成のコツ

    • 具体的なステップごとのガイドを提供する
      • "PostCSS を使ってください" のような曖昧な説明ではなく、明確で具体的な手順 を示す
      • 各ステップで必要なコマンドや設定方法を明記する
    • 代替ルートを提供する
      • ユーザーの状況に応じて異なるアプローチ方法を示す
      • 例: PostCSS がインストールされていない場合の対処方法を追加する
    • ユーザータイプ別のセクションを用意する
      • 大規模ライブラリのユーザーと小規模ライブラリのユーザーそれぞれに合ったガイドを提供する

  • テストは必須

    • 自分で書いたガイドに従って、実際にうまく動くかテストしなければならない
      • 可能なら、プロジェクトに関する背景知識を忘れて 最初からやり直してみる
      • 問題が発生したらすぐ修正して補強する

効果的なオープンソース宣伝戦略

1. 繰り返し宣伝することの重要性

  • 多くの人が次のようなミスをする
    1. ソーシャルメディアに 1 回だけ投稿する
    2. 反応がない
    3. 落ち込む
    4. プロジェクトを中断する
  • 1 回の大規模な宣伝は効果的ではない → 段階的で反復的な宣伝が必要
  • 効果的な反復宣伝サイクル
    1. 新機能のリリース、ブログ記事、ソーシャルメディア投稿などのコンテンツを作る
    2. ユーザーのフィードバックを受ける
    3. フィードバックに基づいてプロジェクトを修正する
    4. 修正内容について新しいコンテンツを作る → 再スタート
  • 初期はユーザー数が少ないほうがむしろ有利 → ストレスなく修正できる
  • 継続的な改善と反復的な宣伝を通じて認知度を高める

2. 効果的なソーシャルメディア宣伝戦略

  • 単にリンクだけ共有したり、短い説明だけで終えたりしないこと
  • 次の 2 つを含めること
    • コード例または画像 → 人々が理解しやすい
    • 明確なプロジェクト説明 → 新しいユーザーにも理解できる

  • 宣伝文テンプレートの例

    • 新機能の発表 → 明確な説明 → コード例を含める → ソーシャルメディアで共有
    • Reddit の関連サブレディットに投稿する（各サブレディットのルールを確認）
    • Hacker News に投稿する → 初期 traction を確保できる可能性
    • Dev.to、Smashing Magazine、CSS-Tricks などに記事を書く → 露出を拡大

3. PR を通じた宣伝戦略

  • 他のプロジェクトに自分のオープンソースを導入する PR を提出する
    • 例: PostCSS は他プロジェクトへの PR を通じて宣伝に成功した
    • "必要であれば、私がこのツールを適用してみます。"
  • PR が承認されたら README に適用事例を明記する → 信頼性が高まる
  • 人気のあるプロジェクトで自分のツールが使われていると明記すれば、信頼が強化される

4. 繰り返してもスパムは禁物

  • 継続的で反復的な宣伝は必要
  • ただし スパムは絶対に避けること
    • 同じメッセージを繰り返すのではなく 新しい価値 を提供する
    • 変化や改善された内容を含めること
  • すべてのユーザーがすべての投稿を読むわけではない → 定期的にさまざまな形で繰り返し宣伝する必要がある

繰り返し宣伝する理由

  • 人は合理的にツールを選ばない
  • 繰り返し宣伝することで認知を自然に形成できる
  • 長い時間をかけて認知を積み上げてこそ成功の可能性が高まる

おまけ

1. プロジェクトが有名になったときの問題解決法

  • プロジェクトが人気を得ると、対処すべき issue が爆発的に増えることがある
  • 自分ひとりですべての問題を解決しようとすると負担が大きくなり、気分の落ち込みや生産性低下につながることがある

  • 解決策

    • すべての問題を自分で解決しようとしない → ユーザーに PR 作成 を勧める
    • "この問題を解決したいなら PR を送ってもらえますか?" と依頼する
    • 問題対応に割り当てる時間（例: 1 日 15 分）を設定し、その時間内だけで処理する
    • 難しい問題はすぐ解決しようとせず、"解決策を検討中です" と返答する → ユーザーは問題を認識していると分かるだけでも安心する
    • ドキュメント修正もユーザーに任せられる → "この部分を修正してもらえますか?" と依頼する

2. ネガティブなフィードバックへの対処法

  • ネガティブなフィードバックはモチベーション低下につながりうる
  • プロジェクト初期のネガティブなフィードバックはやる気をくじき、人気が高まると自信を弱めることもある

  • 対応戦略

    • 感情的に反応しないこと
    • 批判に対して質問する → "なぜ B が A より良いと思うのですか?" と聞くこと
    • 批判は単なる感情の吐き出しである場合も多い → ユーザーと対話して信頼を築く
    • 批判を通じて改善の機会を得られる

3. 競合プロジェクトが現れたときの対処戦略

  • 競合プロジェクトが登場しても心配する必要はない
  • 競合プロジェクトが出てくると、次のような利点がある
    • プロジェクト維持の負担から解放される可能性がある
    • 競争によってより良いソリューションが生まれることがある → 結局はユーザーにも利益
  • オープンソースの究極の目的は世界を変えること → 独占や支配ではない
  • 競合プロジェクトの登場 → より良いツールの誕生 → Win-Win の状況

最終まとめ

人気のあるオープンソースを作り、可視性を確保する方法

  1. オープンソースを作る最良の理由は、有名になることや履歴書の強化ではなく 世界を変えるため である
  2. 良いアイデアが人気プロジェクトになる保証はない
  3. オープンソースプロジェクトの人気の公式 = 認知度 + プロモーション + ユーザーへの利点 + 運
  4. ソーシャルメディアのアカウントは活性化し、検索しやすくし、英語など広く使われる言語で書くべき

効果的なドキュメント作成法

  1. README とドキュメントは、友人に説明するように明確で自然に書くべき
  2. 強調テキスト、リスト、体系的な構成で複雑な情報を段階的に伝える
  3. 実際のベンチマークやコード例など 具体的な証拠 を提示するべき
  4. 可能であれば、初心者と上級者に合わせた具体的なスタートガイドを提供する

宣伝戦略

  1. 1 回の大規模な宣伝より、反復的な宣伝のほうが効果的 → リリース → フィードバック → 改善 → 反復
  2. 定期的に投稿しつつ、スパムは避けること
  3. コード例や画像を含んだ投稿を書く
  4. 他のプロジェクトに PR を提出して宣伝効果を最大化する

プロジェクトが有名になったときのヒント

  1. すべての問題を自分で解決しようとせず、ユーザーが PR を提出するよう促す
  2. 問題対応のための時間を決めて管理する（例: 1 日 15 分）
  3. ネガティブなフィードバックがあれば、質問を通じて対話を試みる
  4. 競合プロジェクトを恐れないこと → 競争によってむしろ責任から自由になれることもある

関連記事

1件のコメント

 
roxie 2025-03-28

少しずつ内容は異なるものの、遠目に見れば繰り返しに見えるような宣伝が許容される場所を見つけることも重要だと思います。たとえばTwitterです。