人気のあるオープンソースプロジェクトを作るためのヒント
(skerritt.blog)「ネットワーク効果：より多くの人が見つけるほど、ユーザーが増え、参加が増え、機能が良くなり、さらに有名になっていく」
人気を集めるにはどうすればよいのか？
#1. よく設計されたREADME
- 最初に簡潔に説明すること
→ これは何をするものか？
→ 自分の問題を解決してくれるか？
→ 競合よりもうまく自分の問題を解決してくれるか？
→ どうやってインストールするのか？
→ 知っておくべき基本コマンドは？
→ 助けが必要ならどこへ行けばよいか？
1.1 プロジェクトを要約して説明するヘッダーを作る
→ ロゴ：ロゴはCanvaのようなところでGIF Logoを作る
→ スローガン：1行でプロジェクトを説明する。GitHubのDescに適用すること
⇨ ひと目で伝わるように
⇨ なぜユーザーにこれが必要なのか
⇨ なぜ他のものよりこれが良いのか
⇨ 理解しやすく
⇨ 例) hugo : The world’s fastest framework for building websites
→ バッジ：小さな画像やリンクでプロジェクトを説明する
⇨ 最近の活動回数、ダウンロード数、チャットルームに何人いるか、使用バージョン、ライセンスなど
→ クイックインストール：簡単かつ素早くインストールするコマンドをすぐ見えるように表示
⇨ すでに理解して来た人がすぐ試せるように
⇨ Docker/PIPで1行インストール可能、といったことをできるだけ冒頭に表示
⇨ docker run -it --rm remnux/ciphey
→ クイックリンク（必須ではない）
⇨ Webサイト、フォーラム、ドキュメント、インストールガイド、コントリビューションガイド、Twitterなど
1.2 「What is This?」 プロジェクトを簡潔に説明する
→ 短い説明 + プロジェクトの動作を見せるGIF + 人が見たがる重要機能
→ 例) Starship：2カラムで左に重要機能の紹介、右に動作GIF
→ すべての機能を見せる必要はない。ユーザーが見たがるものだけをリストし、わかりやすく説明すること
1.3 「X vs Y」 競合と比較する
→ なぜ競合ではなくこのプロジェクトを選ぶべきかを示す必要がある
→ 長所を簡単に見られるようにすること
→ リーンスタートアップで「平均的なユーザー」より「アーリーアダプター」を先に見つけるべきなのと同じ
⇨ より良い機能があるなら、新しいツールへ乗り換えることをためらわない人たち
→ 競合がまったくいないか、現在のソリューションがあなたのものに比べて非常に複雑な場合にだけ、「平均的なユーザー」を対象にするのが適切
→ 最も簡単な方法は主要機能の比較テーブルを作ること
⇨ 言葉より数字で示すこと
⇨ 動作をGIFで比較して見せるのもよい
1.4 優れたドキュメントを作る
→ すべてのドキュメントをREADMEに入れる必要はない。更新や検索が難しくなり、READMEも見づらくなる
→ 上でインストール方法は書いたので、追加で見せるべきものは
⇨ どう実行するか
⇨ どこでドキュメントを見つけられるか
⇨ どうサポートを受けられるか
→ 実行方法はGIFで見せるのもよい
1.5 貢献方法を示し、貢献者に感謝し歓迎する
→ プロジェクトへの貢献方法
→ 過去の貢献者に感謝する
→ all-contributors のようなボットを使う
#2. 人々が望むものを作る
→ 良いREADMEは人々の関心を引き、「問題を解決」するプロジェクトは人々の会話を生み出す
2.1 まず問題、次に製品
→ 何か製品を作るためではなく、問題を解決すること
→ 「進歩は大きな飛躍だけでなく、何百もの小さな段階からも生まれる」
2.2 問題とともに生きる
→ 問題がなければ、効果的に問題を解決することはできない
→ 無作為にアイデアを生み出すより、自分の生活にある問題を観察するほうがはるかに簡単
→ 問題があるとわかれば、2つのことがわかる。実際に問題があり、他の人もそれを抱えているということ。
2.3 コミュニティで問題を見つける
→ コミュニティを見れば、人々が自分たちの抱える問題を表に出していることがある
→ 人が多いほど、より多く耳を傾けるほど、自分だけで考えるより多くのアイデアを生み出せる
→ コミュニティが抱える問題を解決するMVP(Minimum Viable Product)を作ってみること
→ コミュニティと共有し、効果を測定し、より良くすることを学び、作り直したり追加したりして改善すること
#3. 外に向けて発信する
→ うまく作っても公開しなければ誰にも見られない
→ 前の段階でコミュニティを活用していれば、幸い彼らはすでに知っていて使ってくれる
→ GitHub Starを0から1にするのは難しいが、10から100にするのは簡単
3.1 コミュニティに共有する
→ Build, Measure, Learn ループ
→ 最初の実際のリリース時には、コミュニティに必ず知らせること。彼らが友人に共有してくれるはず
3.2 News Aggregators
→ 狙ったSubreddit
→ HackerNews （訳注：GeekNews も！）
→ Lobste.rs
3.3 Awesome List
→ トピックに関連するリストを見つけてPRを送る
2件のコメント
1日でGitHubスターを500個集めた話
https://black7375.tumblr.com/post/653140399088631808/
以前に私が書いた文章です。
広報戦略を中心に書きました。
広報記事を投稿する方法や時期、開発方針と締め切り時期を決めた方法などを書いてあります。
当然の話ではありますが、オープンソースのREADMEは本当に重要です。
誰も解決できない／しない問題を解決したり、競合を上回る驚くべき機能を持つプロジェクトであっても、READMEにどう書くかによって結果は変わり得ます。
国内だけでなく海外にも知られるオープンソースがもっと増えてほしいです。
最近最も有名な国内開発者の方々が作ったオープンソースのGitHub AboutとREADMEも参考にしてみてください。
swc : "Make the web (development) faster." swc is a super-fast compiler written in rust; producing widely-supported javascript from modern standards and typescript.
fzf : fzf is a general-purpose command-line fuzzy finder.