open-source-marketing

オープンソースのマーケティング

このスキルは、気取らずにオープンソースプロジェクトをマーケティングする方法を紹介します。GitHub の最適化、コミュニティの構築、コントリビューターの体験、ローンチ戦略、持続可能な成長を取り上げます。

---

始める前に

まず、オーディエンスのコンテキストを読み込みます。 .agents/developer-audience-context.md を読み、次の点を把握してください。

• このプロジェクトを使うのは誰か（役割、技術スタック、課題）
• ツールをどこで見つけるか（コミュニティ、ソーシャルメディア、検索）
• どんな代替手段があるか（なぜ乗り換えるのか）
• OSS をどのように評価するか（スター、活動状況、ドキュメント、コミュニティ）

コンテキストファイルがない場合は、先に developer-audience-context スキルを実行してください。

---

OSS マーケティングの考え方

効果があること、ないこと

効果があること	効果がないこと
開発の過程を公開する	「自分のプロジェクトを見て」とスパムを送る
実際の課題を解決する	課題を探してから解決策を作る
心からコミュニティに参加する	見返りを期待したフォロー／フォロー解除
優れたドキュメントと DX	「コードを読めばわかる」
コントリビューターを称える	自分だけの功績にする
継続的に存在感を示す	ローンチして姿を消す

成長の方程式

Growth = (Real value) × (Discoverability) × (First-use experience)

いずれかの要素がゼロなら、成長もゼロです。

---

GitHub の最適化

優れた README

README はプロジェクトのランディングページです。最適化しましょう。

構成：

# Project Name

[One-line description that explains what it does]

[Badges: build status, version, license, downloads]

[Screenshot or GIF showing it in action]

## Why [Project Name]?

- ✅ [Benefit 1 - specific, not fluffy]
- ✅ [Benefit 2]
- ✅ [Benefit 3]

## Quick Start

\`\`\`bash
npm install project-name
\`\`\`

\`\`\`javascript
// 5 lines that show immediate value
\`\`\`

## Installation

[Detailed installation for all platforms]

## Usage

[Core usage patterns with examples]

## Documentation

[Link to full docs]

## Contributing

We love contributions! See [CONTRIBUTING.md](CONTRIBUTING.md).

## License

[License type] - see [LICENSE](LICENSE)

README のチェックリスト

要素	重要な理由
わかりやすい名前	覚えやすく、検索しやすく、綴りやすい
一言での説明	「[対象者]向けの[種類]で、[何をする]」
バッジ	第三者からの評価、健全性の指標
ビジュアル	GIF ＞ スクリーンショット ＞ なし
クイックスタート	最初の価値を得るまでの手順が5行未満
なぜこれを使うのか	代替手段との違い
インストール	すべてのプラットフォームに対応し、コピーして使える
例	作り物ではなく、実際のユースケース
ドキュメントへのリンク	詳細情報を確認できる
コントリビューション	コミュニティからの参加を歓迎する

リポジトリの最適化

要素	ベストプラクティス
説明	最大100文字で、キーワードを豊富に含める
トピック	見つけやすくするため、関連タグを5～10個設定する
ウェブサイト	ドキュメントまたはランディングページへのリンク
リリース	セマンティックバージョニングと変更履歴
Issue	バグや機能要望向けのテンプレート
Discussions	コミュニティでの質問と回答のために有効にする
スポンサー	資金援助を募る場合は有効にする

Issue と PR のテンプレート

バグ報告テンプレート：

---
name: Bug Report
about: Report a bug to help us improve
---

## Bug Description
[Clear description]

## Steps to Reproduce
1.
2.
3.

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

## Environment
- OS:
- Node version:
- Package version:

## Additional Context
[Screenshots, logs, etc.]

機能要望テンプレート：

---
name: Feature Request
about: Suggest an idea for this project
---

## Problem
[What problem does this solve?]

## Proposed Solution
[How would you like it to work?]

## Alternatives Considered
[Other approaches you've thought about]

## Additional Context
[Examples, mockups, etc.]

---

コミュニティの構築

コミュニティの場

プラットフォーム	最適な用途	設定の手間
GitHub Discussions	質問と回答、告知	少
Discord	リアルタイムチャット、コミュニティ感	中
Slack	企業コミュニティ	中
フォーラム（Discourse）	非同期で検索可能な議論	多

まずは GitHub Discussions から始めましょう。アクティブユーザーが50人以上になったら、Discord を追加します。

コミュニティの原則

原則	実践方法
迅速に対応する	Issue には48時間以内に返信する（「確認します」だけでも構いません）
コントリビューションを称える	すべてのコントリビューターに公開の場で感謝する
透明性を保つ	ロードマップを共有し、決定の理由を説明する
期待値を設定する	メンテナーの応答に関する明確な SLA を設定する
新しい参加者を歓迎する	good first issue ラベルを付け、メンタリングを行う

コントリビューターのファネル

User → Star → Issue → PR → Regular Contributor → Maintainer

各段階の移行を最適化します。

移行	改善方法
ユーザー → スター	優れた README、価値をわかりやすく示す
スター → Issue	わかりやすい Issue テンプレート、歓迎する姿勢
Issue → PR	good first issue ラベル、CONTRIBUTING.md
PR → 継続的な貢献	迅速なレビュー、前向きなフィードバック
継続的な貢献 → メンテナー	信頼、オーナーシップの共有

---

コントリビューターの体験

CONTRIBUTING.md に欠かせない内容

# Contributing to [Project]

First off, thanks for considering contributing! ❤️

## Quick Start

1. Fork the repo
2. Clone your fork
3. Install dependencies: `npm install`
4. Create a branch: `git checkout -b my-feature`
5. Make your changes
6. Run tests: `npm test`
7. Commit: `git commit -m "Add my feature"`
8. Push: `git push origin my-feature`
9. Open a Pull Request

## Development Setup

[Detailed setup instructions]

## Code Style

- We use [Prettier/ESLint config]
- Run `npm run lint` before committing
- [Other conventions]

## Commit Messages

We follow [Conventional Commits](https://conventionalcommits.org/):
- `feat: add new feature`
- `fix: resolve bug`
- `docs: update readme`
- `chore: update dependencies`

## Pull Request Process

1. Update docs if needed
2. Add tests for new features
3. Ensure CI passes
4. Get one approval

## Good First Issues

Look for issues labeled `good first issue` — these are great starting points!

## Questions?

Open a Discussion or reach out on Discord.

「Good First Issue」戦略

本当に取り組みやすい課題を作成します。

良い例	良くない例
「X 関数に TypeScript の型を追加する」	「コードベース全体をリファクタリングする」
「README の誤字を修正する」	「パフォーマンスを最適化する」
「Y メソッドのテストを追加する」	「断続的に発生する CI の失敗をデバッグする」
「依存関係 Z を更新する」	「RFC の機能を実装する」

「Good First Issue」ごとに、次の内容を含めます。

• 背景と重要な理由を説明する
• 関連するコードファイルへのリンクを掲載する
• 期待される成果を説明する
• コメントでサポートを申し出る

---

公開戦略

公開前チェックリスト

タスク	完了？
README を仕上げる	☐
クイックスタートが動作する	☐
ドキュメントがある	☐
3 つ以上の例／デモがある	☐
テストがすべて成功する	☐
ライセンスを選定する	☐
CONTRIBUTING.md	☐
Issue テンプレート	☐
ソーシャルプレビュー画像	☐
GitHub トピックを 5～10 個設定する	☐

公開当日の手順

タイムライン：

時間	アクション
前日	README の最終確認、投稿内容の準備
公開日の朝	HN への投稿（最適な時間帯：PT の午前 6～8 時、火～木曜日）
+1 時間	Twitter のスレッド
+2 時間	関連するサブレディットに Reddit で投稿
終日	すべてのコメント／質問に返信
終業時	皆に感謝し、指標を共有

プラットフォーム別の戦術

Hacker News：

• タイトル：内容が分かりやすく、誇張しない（「Show HN: X — Z 向けの Y」）
• 最初のコメント：動機や技術的な判断について説明する
• 数時間は返信できるようにしておく
• アップボートを求めない（即座に台無しになります）

Reddit：

• 関連するサブレディットを 2～3 個見つける（r/programming だけにしない）
• まずルールを読む
• マーケターではなく、コミュニティの一員として参加する
• 本当に役立つ背景情報を共有する

Twitter/X：

• スレッドの構成：問題 → 解決策 → デモ → リンク
• GIF／動画を含める
• 関連アカウント（フレームワークの作者など）にタグ付けする
• 開発過程を公開しながら進める取り組みを共有する

Dev.to / Hashnode：

• 「これを作った理由」という記事を書く
• 技術的な詳しさと個人的なストーリーを盛り込む
• 自分のブログからクロスポストする

公開後

期間	注力点
第 1 週	すべてのフィードバックに返信し、バグを修正する
第 2 週	ブログ記事：「公開から学んだこと」
第 3 週	定期的な更新を始め、新機能をリリースする
1 か月目	コミュニティの構築、コントリビューター向けドキュメントの整備
継続的に	一貫した活動、定期的なリリース

---

持続可能な成長

成長施策

施策	労力	効果	期間
SEO に最適化されたドキュメント	中	高	3～6 か月
インテグレーションのチュートリアル	中	高	1～2 か月
カンファレンスでの講演	高	中	3～6 か月
比較コンテンツ	低	中	1～2 か月
ゲストブログ記事	中	中	1～2 か月
ニュースレターでの紹介	低	低～中	2～4 週間
Twitter での活動	中	中	継続的

OSS のコンテンツ戦略

コンテンツの種類	目的
「X を作った理由」	公開の経緯、動機
「X 対 Y 対 Z」	比較検索からの流入を獲得する
「Y から X への移行」	競合製品のユーザーを獲得する
「X +［人気ツール］」	インテグレーションに関する検索からの流入を獲得する
「［企業名］における X の利用方法」	ソーシャルプルーフ、実際の使用例
「X のパフォーマンスベンチマーク」	技術的な信頼性

燃え尽きを防ぐ

リスク	対策
課題が多すぎる	返信 SLA の期待値を設定する
機能の要望	公開ロードマップ、RFC プロセス
メンテナーが 1 人だけ	共同メンテナーを積極的に募る
常時対応のプレッシャー	24 時間 365 日の対応ではなく、「オフィスアワー」を設定する
否定的なフィードバック	行動規範、モデレーション

---

重要な指標

見栄えの指標と価値の指標

見栄えの指標	価値の指標
スター	アクティブな Issue と PR
フォーク	継続的に貢献するコントリビューター
ダウンロード数	週ごとのアクティブユーザー数
Twitter のフォロワー数	コミュニティのエンゲージメント

追跡する指標

指標	確認場所
スター数の推移	GitHub Insights、Star History
クローン数	GitHub Traffic
参照元	GitHub Traffic
npm のダウンロード数	npm-stat.com
コミュニティの規模	Discord/Slack のメンバー数
コントリビューター数	GitHub Insights
イシューへの応答時間	手動で追跡

---

ツール

ツール	用途
Octolens	GitHub、HN、Reddit、Twitter、Stack Overflow 全体で、プロジェクトへの言及を監視します。競合プロジェクトを追跡します。質問をしているコントリビューターを見つけます。
Star History	スター数の推移を追跡します
npm-stat	ダウンロード統計
GitHub Traffic	閲覧数、クローン数、参照元
Shield.io	動的なバッジ
All Contributors	すべてのコントリビューターを称える
Probot	GitHub のワークフローを自動化します

---

関連スキル

• developer-audience-context — ユーザーが誰なのかを把握します
• community-building — Discord/Slack コミュニティを構築します
• devrel-content — 関連コンテンツを作成します
• developer-advocacy — カンファレンスでの講演、ポッドキャスト
• hacker-news-strategy — HN でリリースし、交流します