PostCSS作者が教える「自作のオープンソースを成功させる方法」（翻訳）
はじめに
私はかれこれ20年以上オープンソースに携わっており、多くの有名なオープンソースプロジェクト（月あたり数百万ダウンロードのレベル）を手がけてきました。オープンソースを成功させる秘訣はあるのでしょうか？
本記事はそんなあなたが待ち焦がれていた、あなたのオープンソースソフトウェアを有名にするためのガイドです、それも正しい形で。「いいアイデア=人気が出る」は正しいのでしょうか？（ヒント: オープンソースについて語られる夢は、たいていまったくのホラ話です）
私は、Evil Martiansでリードフロントエンド開発者を務めているAndrey Sitnikと申します。
今日は、私がオープンソースを手がけ始めた頃を振り返ります。私がこの世界に飛び込んだ頃は、現在とかなり状況が異なっていました。その証拠に、私にとって最初のオープンソースプロジェクトはGitHubにすら置かれていませんでした。代わりに、当時はSourceForgeに置かれていたのです。GitHubが誕生する4年前のことでした。
カメラ目線をキメた若き日のAndrey Sitnik。
やがてオープンソースの長い旅をすることになろうとは、たぶん知らない。
いずれにしろ、SourceForgeは不十分と感じていたので、数年後、ついにGitHubが登場したときには真っ先にこのサービスに飛びつきました。そのおかげで@aiという素敵なユーザー名をゲットできたのです（ささやかな自慢）。
（ところで、あるカンファレンスでSourceForgeアカウントをお持ちの方は？と尋ねたところ、手を上げたのはたった1人でした）
とまあそういうわけで、私もいろいろやってきました。20年以上オープンソースの世界にどっぷりと浸かり、それなりに成功を収めてきました。私の手がけたプロジェクトは、方向性が近いものもありますが、多様性も大きいので、そうしたプロジェクトが成功したのは単なるまぐれ当たりではないと確信しています。
私の主なOSSプロジェクトのダウンロード数、これは月あたりの数値です！
あなたにもできます。だからこそ、私が培ってきた経験の一部を共有して、皆さんのオープンソースプロジェクトを普及させるお手伝いをしたいのです。
しかし、その前に話しておかなければならないことがあります。
🔗 人気目当てでオープンソースをやらないこと
現実的に考えてみましょう。有名になりたい、リッチになりたい、道行く人にクールな開発者と噂されたい、そんな理由でオープンソースを作ってみたいと思っているそこのあなた。おそらくそれは戦う場所が間違っています。
とはいうものの、有名になりたいなら他にもっと効果的な方法があることだけは一応触れておきましょう。たとえば、カンファレンスで講演したり記事を書いたりする方法もあります。
記事を書くのは、オープンソースプロジェクトをアピールして詳しい内容を共有し、人々の考え方を変える手段として優れています。幅広く注目を集めることはもちろん、潜在的には長期的に注目を集め続けることも可能になります。
さらに、カンファレンスで公演するための準備と実戦のガイドも別記事で解説しています。
他にも、自社でミートアップを主催するためのガイドも別記事で公開しています。
開発者が記事を書くためのガイドもあります。
オープンソースで有名になったからといって、必ずしも従来のような名声を得られるとは限らない例を見るために、ReduxとReact Routerを取り上げることにします。本記事執筆時点では、どちらのプロジェクトも6万を超えるスターを獲得しています。
Reduxの現在のメンテナーであるTim Dorrですら、Xでのフォロワー数は5,000人程度です。
これほどの人気を得ているにもかかわらず、プロジェクトの現在のメンテナーであるTim DorrのX.comのフォロワー数は5,000人弱程度です。公平のために申し上げると、Timは同プロジェクトのメンテナーであって作者ではありませんが、それでもよく知られているプロジェクトであることは変わりません（ですから、オープンソースへの愛を込めてTimをフォローしてやってはいかがでしょう）。
🔗 履歴書を飾るためにオープンソースをやらないこと
誰もが知っておくべきことは他にもあります。それは、オープンソースの夢は、多くの場合まったくのホラ話だということです。理由の1つを説明しましょう。
「オープンソースに参加しなきゃ」という話はよく耳にします。しかしその割に、なぜオープンソースに参加しなければならないのかという理由についてはあまり耳にしません。
「参加しなければならない理由は、参加しなければならないものだからです」。理由については、もうこれで十分おわかりいただけましたよね？
このようなもろもろの話の結果として、オープンソースを行う理由よりも、どうやってオープンソースを行うかという方法論にばかり話題が集中しがちです。その結果、「オープンソースプロジェクトに向いた優秀なアイデアを思いついて、とにかくプロジェクトを実際に立ち上げれば、後は万事OK」という雑な回答で済まされることもあります。
ありがちな言い訳（あ、もしうまくいかないことがあるとしたら、それはあなたのアイデアがよくなかったということだからね）
多くのエンジニアは、まともに活動しているGitHubアカウント（つまりオープンソースへの健全な貢献を含む可能性のあるアカウント）を持っていなければ雇ってもらえないと感じているので、オープンソースで華々しく成功しなければというプレッシャーは強まる一方です（しかしどんなに素晴らしいプロジェクトでも、スターを付けてくれたのがあなたのおばあちゃん👵だけだったらズーンと落ち込むかもしれませんが）。ともあれ、多くの人がオープンソースについてこのように感じているということです。
とにかく、採用担当者はあなたのオープンソースのコミット履歴をチェックするでしょうが、そっちで頑張るよりも、大きなプロジェクトに貢献したり、β版でドキュメントやバグを修正したりする方がよいでしょう。
🔗 飛び込む前にまず貢献してみよう
ここは、今後のために自信をつけたい人向けのアドバイスです。
いきなり最初から独力でプロジェクトを立ち上げるよりも、既に確立された大規模プロジェクトをお手伝いする方がずっと簡単です。
たとえば、RustやReact関連の多くのプロジェクトには、それぞれの作者が書いたドキュメントがありますが、それが必ずしも作者の意図を伝えるために最適ではないこともあります。そう、作者は使い方を知っていて当然ですが、一般ユーザーのようにゼロから学習する必要がなかったので、ユーザー側の視点がドキュメントに足りない可能性があります。こうしたドキュメントの改善に貢献すれば、自分の履歴書に追加するチャンスです！
- ✅ 有名プロジェクトのドキュメント修正を手がけた
- ✅ ベータバージョンを使い、バグを修正した
あるいはプルリクエストを作成しましょう。アプリやプロジェクトを構築するよりずっと気楽にできます。
いろいろ申し上げましたが、オープンソースに本気でかかわるのであれば、なぜそうするのかという理由をいつでも明快に説明できるようにしておく必要があります。私の意見としては、「世界を変えたい」という動機付けこそがオープンソースを作る理由として最も優れていると思います。
🔗 オープンソースで世界を変える方法
大胆なことを承知で申し上げると、あなたが手掛けるオープンソースが歴史に残るレベルで世界を根底から変革する可能性はもちろんありますが、次のような経過をたどる可能性もあります。
私がPostCSSを作ったときの目標は、CSSツールの多様性を広げ、CSS処理ツールを作成するための基盤やエコシステムを作り上げることでした。そしてプロジェクトは成功を収めました！
世界を変革する私の試みは完了したのです！
しかし、自分のプロジェクトを使って世界を何らかのレベルで変えたい場合、プロジェクトを軌道に乗せるうえで人気も非常に重要な要素でもあると思われます。
🔗 「いいから早く人気を得る秘訣を教えてよ！」
はい、ではここではっきりさせておきましょう。
「アイデアがよくても、それで成功が約束されるわけではありません」
この基本的な真実を噛みしめて、それでも皆さんがくじけずについてこられるなら、オープンソースの人気を得るための有効な公式を実際に見ていくことにしましょう。
公式: あなた自身の人気 + プロモーション + ユーザーにとってのメリット + 運 = プロジェクトの人気
おそらく、ここでちょっと悲しい問題にお気づきでしょう。あなた自身の人気と、プロジェクトの人気には、やや相互循環的な関係が存在するのです。
残念ながら、現実にはプロジェクトが有名になるのは（開発者が優秀だからではなく）開発者が既に有名だったからであることが多いのは、これが理由です。言い換えれば、彼らは成功のために既存の社会資本を活用したにすぎません。
こういう潜在的な人生の不公平さについてあれこれ考えるよりも、現実をありのままに分析してみることにしましょう。
🔗 オープンソースのソリューションはどうやって選ばれているか
オープンソースのソリューションはどうやって選ばれるのかという点について少し議論してみましょう。多くの人が「ツールは合理的な判断に基づいて選ばれるものである」と考えるのは無理もありません。テック業界では一見筋が通っていそうですが、しかしこの考え方は、完璧に、明らかに、間違っています。
ここで思考実験をしてみましょう。最近立ち上げたプロジェクトは、どんな経過をたどりましたか？
- 可能なフレームワークや言語をすべて使って小さなプロトタイプを作ってみたか？
- 試した言語はいくつだったか？
これはもちろん場合によりますが、現実には、ほとんどのプロジェクトは単にスター数の多いフレームワークから開始しているのです。開発者は、GitHubでスターの多いフレームワークを見繕ってそれを根拠に選んだり、カンファレンスで見かけたフレームワークを元に選んでいるに過ぎないのです。
🔗 ドキュメントがどのように読まれるかを理解する
次のセクションの内容（プロジェクトのREADMEやドキュメントがどのように読まれるか）についての前提となる知識を、今のうちに説明しておきたいと思います。
人間は、書かれているものを端から順に1行ずつお行儀よく読むことはありません。絶対にありえないのです。
そうではなく、人間が説明文なりドキュメントなりREADMEなりを読むときには、まるでプログレッシブJPEGの解像度がじわじわと上がっていくように段階を踏んで理解する必要があります。そしてこの効果は、ちょうどマトリョーシカ人形のように、詳細度のレベルが上がるたびに発生します。そしてどの段階でも、読者の集中を損ねてしまう可能性があります。
読み進めていて、どこが長所でどこが強みなのかさっぱり見当がつかなければ、誰だって読むのをやめてしまうでしょう。
人間はドキュメントをそうやって拾い読みするものなのです。
だからこそ、ドキュメントを書くときは、最初に大まかな概要を示し、次にもう少し細かいスケールで説明し、その次はもっと詳しく説明する、というふうに段階を踏んで構成しましょう。
一度にではなく、徐々に理解させるのがコツです（ただし冗長にならないよう簡潔に！）。
人間は、（こちらが期待するように）ドキュメントを見た通りに読むのではなく、こんなふうに読んでいることを理解しましょう。
しかし、ユーザーがこのドキュメントをぱっと目にしたら、以下のように緑でハイライトされた部分だけを拾い読みするでしょう。
計画を立てるときは、このことを念頭に置いておきましょう。
🔗 人気とは
それでは、より実践的な問題に移ることにしましょう。
まずは重要な質問から。実際に人気を得るにはどうしたらいいのでしょうか？TikTokではどうすればいいでしょうか？（既に禁止されていなければの話ですが）。
まずは、テック業界で多くの人がよく試すアプローチについて話しましょう。
🔗 SNSを適切に扱う
まず、SNSメディアのアカウントを持っていること、そしてそのアカウントを適切に運用していることを確認しておきましょう。
これについて思い出す私の失敗談があります。当初の私は英語のSNSアカウントすら持っていなかったため、人々が私のツールを見つけたときに誰をフォローしたらよいのかわからず困ってしまったのです。そこで、あなたが英語ネイティブでない場合は、SNSで英語用のアカウントを作っておくことをおすすめします。
さらに、人々が私のプロジェクトに言及しようとしても、当初は私のプロファイル情報が見当たらなかったため、戸惑わせてしまいました（もちろん今はあります）。
SNSアカウントの治安を健全に保つことは、あらゆる面で有用です。
🔗 現実を見据えた心構えを見失わないこと
公式の「運」の部分については、ここで解説するのがよさそうです。
さて、「良いアイデア=人気のプロジェクト」が正しくないのであれば、何が正しいのでしょうか？「運」の要素が大きいのは間違いありませんが、運だけで本当にすべてが決まってしまうのでしょうか？
さてさて、私は4つの有名プロジェクトを運営しています。しかし、私が手がけているプロジェクトはこれだけではありません。
言葉を尽くして説明するより、1枚の画像の方が説得力が増す場合もあります。私の打率がどれほどのものかを以下の図でご覧ください。
人気の出なかったプロジェクトは52件、人気を得たプロジェクトはわずか4件です。
成功したプロジェクトは、多くの場合短距離走というよりマラソンになるものです。自分が作ったプロジェクトが1つ残らず失敗して草も生えなくなる可能性もあることを覚悟しておくのは適切だと思いますが、プロジェクトを成功させるには、1にも2にも、多くの犠牲をいとわずに粘り強く何度でも挑戦を繰り返すしかありません。挑戦を繰り返してこそ「運気」は上昇するのです。
プロジェクトを立ち上げるときは、失敗の可能性も見越して「ダメでもともと」と覚悟しておくことが心構えとして正しいとも言えるでしょうが、もちろん、だからといって手を抜いてよいことにはなりません！
🔗 オープンソースプロジェクトの人気を高めるREADMEの書き方
次は、成功するための基本的な準備について話しましょう。
「はい知ってます、つまりドキュメントやREADMEの冒頭にはツールのインストール方法をみっちり書くのがベストなんですよね、善は急げ、早速やってみます」ちょ、ちょ、ちょっと待った！
潜在的なユーザーがプロジェクトに対して抱く第一印象は、READMEとドキュメントで決まります。実際、カンファレンスでの発表やブログ記事、ポッドキャストなどでどんなに心を込めて宣伝しようとも、潜在的なオーディエンスの大半は真っ先にREADMEとドキュメントに集まってくるものです。だからこそ、READMEとドキュメントは十分に時間をかけて練り上げておく必要があります。
すべての道はREADMEに通ず、です。
MastodonだろうとXだろうと見に行く先は変わりません。
既に述べたように、読者はREADMEを上から順に1行ずつ丁寧に読んだりしませんが、そのプロジェクトが自分たちにとってどんなメリットがあるのかを手っ取り早く理解したいと思っているものです。
セルフチェック: 自分のプロジェクトの価値を効果的に伝えるために十分手を尽くしましたか？
プロジェクトの人気を高めるには、どんなメリットがあるのかがひと目でわかるようにする必要があります。READMEの冒頭のブロックを見ただけでわかるようにしておくのが理想的です。
同様に、ユーザーはドキュメントをじっくりことこと時間をかけて1行ずつ読み込むような悠長なことはしません。現実はまったく逆で、ユーザーがそんなことに時間をかけるはずがありません。だからこそ、ドキュメントをきちんと整備して読みやすくしておくことが重要なのです。
この点についてさらに詳しく見ていきましょう。
🔗 1: ユーザーにどんな点が嬉しいかが伝わるように工夫する
メリットをユーザーに直接伝えることは、多くの意味でプロモーションに直結します。先ほどの公式を思い出して、太字部分に注目してみましょう。
公式: あなた自身の人気 + プロモーション + ユーザーにとってのメリット + 運 = プロジェクトの人気
READMEやドキュメントであろうと宣伝であろうと、世間ではメリットよりも人気ベースでプロジェクトを選ぶという非合理的な判断がまかりとおっています。そんな非合理的な世界で、邪魔なノイズを取り除いてソリューションのメリットをユーザーに効果的に伝えるにはどうしたらよいでしょうか？
これに対する正しい回答は1つではなく、複数のパートに分かれています。さらに人間が情報を消費するときの振る舞いにも関連します（特に、「素早く読めるか」「楽に読めるか」、そして「初めて目にしたときの第一印象」が優先される点にご注意ください）。
🔗 2: メッセージを短時間で効果的に伝える方法を徹底的に理解する
では具体的に考えてみましょう。冒頭のブロックには以下の3つを盛り込むべきです。
- ひと目でわかる明確な説明文
- その製品はどんな点が嬉しいか
- 他の類似プロジェクトと何が違うか
最初の段階で、このドキュメントは読む価値があるのだということを明確に伝えましょう。
最も重要なのは第1パラグラフです（最初のパラグラフしか読まない人はざらにいます）。そのプロジェクトに価値があるかどうかは、この第1パラグラフで判断されるのですから、ここには特に力を入れる必要があります。
現実の例を私のPostCSSプロジェクトで見てみましょう。
PostCSSは、JavaScriptプラグインでスタイルを変換するツールです。（明快な説明）
これらのプラグインを用いることで、CSSをlintでチェックしたり、CSS変数/ミックスイン/今後のCSS構文のトランスパイル/インライン画像などをサポートできるようになります。（何に役立つか）
PostCSSは、Wikipedia/Twitter/Alibaba/JetBrainsなどの業界のリーディング企業によって使われています。PostCSSのAutoprefixerプラグインも人気のCSSプロセッサの1つです。（重要である理由）
ここでは難解な「技術用語」を避けて、同僚と話すときのような平易な口調で書きましょう。
別の例を以下のNano IDで示します。
ドキュメントのなるべく最初の段階で価値を理解してもらうことが、成功を最大化するうえで非常に重要なので、この部分には十分時間をかける価値があります。まるまる1週間かけてもいいくらいです。
PostCSSでは、ドキュメント冒頭のブロックを書くのに1週間かけました（#201）。
🔗 3: 製品の説明は、それが何なのかがひと目でわかるように書く
先ほどの例に続いて、今度はあまりよくない例を見ていきましょう。
ここではSvelteを見てみることにします。Svelteは素晴らしいフレームワークなのですが、どんなふうに説明されているでしょうか？
Svelteはサイバネティックに拡張されたWebアプリです
❌ これではよくわからない！
上はクールで楽しそうには見えますが、どこが優れているかがちゃんと説明されていると思えますか？
もう一工夫してみましょう。
Svelteは、より小さなJS修正を生成する独自のコンパイラを備えたWeb UIフレームワークです。
✅これならわかる
よい説明文を書く方法について私からアドバイスしたいと思います。
あなたが同僚とバーで飲んでいるところをシンプルに想像してみましょう🍻。「あのさ、新しいツールを作ったそうだけど、それって要するに何をするものなの？」
するとあなたは、同僚にそのツールについて現実の人間の言葉で平易に説明するでしょう。そしてその説明を元に、オープンソースプロジェクトの説明文を作ればよいのです。
飲みの席でそこそこうまく説明できるようになったら、さらに容赦なく説明文をカットして切り詰めましょう🪚 🪚 🪚 🪚。そしてさらに2〜4回はカットしましょう。
🔗 4: 箇条書きや太字を使って要点をさっと押さえられるようにする
以下の文を見てください。
Nano Stores is a tiny state manager for React, React Native, Preact, Vue, Svelte, Solid, Lit, Angular,
and vanilla JS. It uses many atomic stores and direct manipulation. It's small, between 286 and 818 bytes (minified and brotlied).
It has zero dependencies.
Nano Storesは小さなステートマネージャーであり、React・React Naive・Preact・Vue・Svelte、Solid、Lit、Angular、素のJSで利用できます。Nano Storesは多くのアトミックなストアと直接操作を利用します。Nano Storesは286〜818バイトという小さなサイズです（最小化とbrotli圧縮後）。
上の文でも、要点は一応わかるといえばわかります。
今度は以下の文を見てください。
前者と後者のどちらの方が楽に情報を読み取れるかについては、ほとんど議論するまでもないでしょう。
しかし読者が本腰を据えて内容を精査するときでも、太字のところだけを表示して後は隠したとしても、本当に伝えたいメッセージはちゃんと伝わります。
🔗 5: サンプルコードと画像も忘れず添えること
効果的なサンプルコードやイラストが添えられていれば、文章で読むよりも認知の負荷が少なくて済みます。結局、1枚の画像は1000の言葉に匹敵するのです。
だからこそ、画像を活用しない手はありません。
🔗 6: 本物の統計情報を、本物とわかるように掲載する
繰り返しますが、掲載する統計情報は「本物」を使いましょう。
ふわっとした約束や「概念止まりの統計」では信用を勝ち取れません。これは、他の製品との違いを際立たせたい場合に特に重要です。
プルリクに書くような折り目正しい文を長々と書くくらいなら、ズバリ本物のベンチマークを掲載しましょう。
たとえば、Nano IDのコードサイズがいかに小さいかを私が主張するときの方法を見てみましょう。
Nano ID READMEのある1行を緑色のボックスで強調表示している様子。
この行は、ライブラリが小さいという主張を裏付ける明確な統計の例です（この場合は141バイト）。
同様に、以下のようにベンチマークを掲載することで、いかに「高速か」を示すこともできます。
Nano ID READMEの別のリスト項目を緑色のボックスで強調表示した様子。
この場合の主題は速度ベンチマークで、UUIDよりも16パーセント高速です。
自分のオープンソースソフトウェアの強みの1つがAPIなら、以下のようにAPIも掲載しましょう。
// Reduxの場合
switch (action.type) {
case 'INCREMENT' :
return state + 1
case 'DECREMENT' :
return state - 1
default:
return state
// Storeonの場合
store.on( 'INCREMENT', ({ count }) → ({ count: count + 1 3))
store.on( 'DECREMENT', ({ count }) → ({ count: count - 1 }))
🔗 7: 最後に、そこから続けてステップバイステップのガイドを掲載する
このようにして、未来のユーザーに、あなたのプロジェクトについての説明を読みすすめるべき理由を短時間で効果的かつ明確に伝えることができれば、ユーザーはその先を読む気になってくれます。
私からのアドバイスは、使い方に関する「ステップバイステップのガイド」を書くのは、ここまでのお膳立てが終わってからにすること（かつお膳立てが終わるまでは書かないこと）です。
繰り返しますが、読んでくれる人の貴重な時間を無駄にしてはいけません！
私のREADMEでは、「PostCSSを使いましょう」という一般的な説明だけで終わらせずに、以下のように非常に具体的な指示も続けて記載しています。
上の画像は、ステップ5のPostCSSの具体的な利用法が漠然としていて不親切ですが、
ステップ5をさらに細かなステップで説明した下の画像はわかりやすく、ヒントやその他のコンテキストや情報も盛り込まれています。
もちろん、読み進めるときの道筋は必要に応じて変更します。
ステップバイステップガイドの一部が緑色のボックスで強調表示されている様子。
この場合は代替パスが主題であり、たとえばユーザーがまだPostCSSをインストールしていない場合の
対処方法などが説明されています。
可能な場合は、特定のユーザー向けのセクションを作成してもよいでしょう。
READMEで、大きなライブラリの場合手順と小さなライブラリの場合の手順を比較している様子。
以上がすべて終わったら、実際に読み進めることで読みやすさをテストする必要があります。これは絶対に省略してはいけません！
テスト方法の1つは、頭をまっさらにしてプロジェクトのことをいったん全部忘れておいてから、初めて読む人の気持ちになってガイドを読み進めることです。
🔗 実践的なプロモーション
さて、良質なREADMEもドキュメントも整備されて文章もきちんと整い、自分の頭も冴えています。次は何をすればよいのでしょうか？
多くの人がこの段階で以下のようなミスをします。
- SNSメディアに1件ポストする
- まったく反応なし
- 落ち込む
- やめてしまう
ここで何をしくじっていたのかというと、「じっくり」プロモーションを実践していなかったのです。言い換えると、大々的に花火を打ち上げるのは大きな間違いである可能性もあります。プロジェクトのプロモーションは段階を踏んで辛抱強く繰り返しましょう。
プロモーションのためのやりとりには、以下の内容を盛り込むべきです。
- 活動内容（機能リリース、SNS投稿、記事など）に関するコンテンツや情報
- ユーザーからの反応（フィードバック）
- フィードバックに基づいたプロジェクト修正
- 修正に関するコンテンツを作成したり、製品で新しい成果を目指す（1.に戻る）
信じてください。皆さんが素晴らしいプロジェクトを作り上げて、その成果を発表する準備が何もかも整ったと感じられたとしても、実のところ、まだその段階にすら達していない可能性があるのです。
だからこそ、プロモーションは継続が肝心なのです！
私がやってきたことで説明するなら、プロジェクトを改善できるのは、ユーザーからフィードバックをもらってこそです。プロジェクトの初期段階ではユーザー数が少ない可能性が高いのですが、その方がストレスにならずに問題を気楽に修正できるので、むしろ「良い」状態といえます。
作業を繰り返していくうちに、こうした状況を変えることが可能です。
次の段階では、やりとりで以下のようなことも起きるようになるでしょう。
- 何か大きな成果を生み出せた
- フィードバックが増えた
- 修正すべき項目も増えた
🔗 SNSや記事で効果的にプロモーションする
多くの人が、オープンソースに関するSNS投稿を書くときに、単にリンクを貼って済ませるか、さもなければ難解な説明をくどくど付け加えたりしがちです。
こうした方法では不十分だとしたら、SNS投稿をどんな方法で改善できるでしょうか？
以下の実践的な方法を行いましょう。
- サンプルコードや画像を貼る。
これによって読みやすくなり、印象もよくなります。 -
製品の説明をわかりやすく記載する。
新機能について書くときも、初めて読む読者のことを考えて、プロジェクトを最初から説明しましょう。
ここで、私がかつてSize Limitというプロジェクトの大規模アップデートを発表したときのSNS投稿を見てみましょう。これはかなりしっかりしたテンプレートとして使えると思います。
よいSNSポストは、「新機能」「プロジェクトの概要」「サンプルコードやスクリーンショット」で構成されているものです。
この順序で配置することが不可欠です。
このように整えたSNSポストを、まずは自分の好きなSNSで公開しましょう（ところで本記事執筆時点ではBlueskyの人気はまだ続いていますが、その原因となった「あの」容疑者もまだ存続していますね）。
次はRedditに投稿しましょう。投稿を受け入れてくれるサブRedditを探して、そこに投稿すること（サブRedditごとに投稿ルールが異なる場合もあるのでご注意）。少々手間はかかるものの、自分のプロジェクトに合うコミュニティを見つけておくのは価値ある投資となるでしょう。
Hacker Newsで注目を集めるのはなかなか大変かもしれませんが、何しろ読者数がものすごく多いので、とにかく一度読んでみることを強くおすすめします。
次に、投稿した内容を詳しく説明した完全なブログ記事を書きましょう。以下のようなサイトは一般からの投稿も受け付けていますし、編集者がアドバイスしてくれることもあります。ぜひ、もうひと頑張りして挑戦してみましょう。
🔗 プルリクでプロモーションする
さて、いよいよここからがお楽しみです。
勇気を出して、自作のライブラリをフィーチャーしたプルリクをよそのプロジェクトでオープンしましょう（実際、私はPostCSSをこうやってプロモーションしました）。
考えてみてください、自分が優秀なライブラリを作ったのであれば、それは「人助け」になるのです。人々を「退屈させている」のではなく、世のため人のためになることをしているのです。
さらに、彼らが実際に自分のプルリクを適用してくれたら、自分のプロジェクトのREADMEに彼らのプロジェクト名を掲載しましょう。人々はビッグネームに敬意を払うものですし、名前が掲載されることで悪い気はしないものです。
🔗 次の一手: 継続、継続、ひたすら継続（ただしスパム行為は厳禁！）
ここからは、以上の作業をひたすら繰り返します。
- コードやREADMEやドキュメントを改善する
- アナウンスを流す
- ブログ記事を書いたりカンファレンスで発表したりする
- フィードバックを受け取る
- フィードバックを元にプロジェクトを改善する
ただし、こうした作業ではスパム行為は禁物です！「定期的に投稿を繰り返す」のと「スパム」は大違いです。
同じ文面を繰り返ししつこく投稿するのではなく、ユーザーにとって価値のあるさまざまな情報をその都度盛り込み、プロジェクトが途絶えずに継続していることを伝えましょう。
人々はSNSのあらゆる投稿に目を通すわけではないので、定期的に投稿する習慣を身につけて、ユーザーにそのことを印象付けるのも大事です。
たとえば、あなたが作ったツールの全容を余すことなくポストで見事に説明できたとしたら...開発者たちが泣いて喜ぶようないい話を書き上げたとしたら...
あなたにもそんなことができる可能性はあるのです！
逆に、その日の夕べにワインを楽しんでいたユーザーが、あなたの渾身の作品を「ふーん」と流し見ただけで終わってしまう可能性もありえます。
だからこそ、投稿は辛抱強く定期的に継続することがとても重要なのです。
本記事冒頭で、人がどのようにして技術スタックを選択するかという話を思い出しましょう。選択は合理的に行われますか？それとも非合理的に行われるのでしょうか？
非合理という闇深い森を突破するには、投稿を定期的に繰り返すことが肝心なのです。
🔗ボーナス:「やべ、おれ有名になっちゃったよ、まいったなぁどうしよう？」
おめでとうございます！ついに成功しましたね。🤝
プロジェクトに全身全霊を注ぎ、かつ常識を失わないよう刻苦勉励した甲斐あって、とうとうあなたのオープンソースプロジェクトは人気が爆発し、成功が転がり込んできました。
しかし人気が出れば出たで、今度は別の問題が持ち上がります。文字通り（GitHubなどの）issueが続々と積み上がってくる可能性があります。issueがたまりすぎてくると、何だか自分がメンテナー失格のような心持ちになってゲッソリしてしまいます。
そのせいで鬱状態になったら、生産性がガタ落ちになるかもしれません。
罪悪感のループでは、「答えのない大量のissue」「メンテナー失格だと自分を責める」
「鬱による生産性の急降下」「答えのないさらに多くのissue」という4つの段階が繰り返されます。
こんなときは、どうしたらいいでしょうか？
まず、issueを報告してくれたユーザーの代わりに自分が何から何まで抱え込むのはやめましょう。ここはオープンソースの世界であり、メンテナーをただでこき使おうとしているわけではないのですから。
つまりここは、ユーザーがプロジェクトで何かやってみたいと思うのなら、やっても構わない世界なのです。そしてメンテナーはそうしたユーザーの自主性を促すべきです。自分で何もかも抱え込むのではなく、「ではプルリクを送ってもらえますか？」とシンプルに聞いてみれば済む話です。
Andrey Sitnikがコメントで「GitHubで言及されたissueを採用するために
プルリクをオープンしてもらえますか？」と尋ねている様子。
それから、issueの処理については、たとえば毎日15分なら15分と時間を決めて、それを超えないように心がけましょう。
難しいissueがやってきたら、「うん、これは難しい問題ですね」とシンプルに認めればよいのです。
実際、issueに対して何らかの反応を示してあげることで、「あなたを無視していませんよ、あなたの存在をちゃんと認識していますよ」と伝えるのは、人間社会において一般によいことです。あなたがissueに対して解決方法を示せなかったとしても、issueに返信すること自体が問題解決になります。人は、単に自分の話に耳を傾けて欲しいときもあるものなので、解決できなくてもレスを付けることには意味があります。
ユーザーの懸念に対してAndrey SitnikがGitHubコメントで返信している様子。
無視せずに相手の話を聞いてあげることが大事な場合もあります。
オープンソースのメンテナー向けのアイデアとして、ユーザーにドキュメントの更新をお願いしてみる方法もあります。
Andrey SitnikがGitHubコメントでユーザーにドキュメント更新を依頼している様子。
🔗 ボーナスその2: ネガティブフィードバックへの対策
あなたの心を削ってくるネガティブフィードバックには、どう対処したらよいでしょうか？あなたのツールが一部で嫌われているとしたら？
ネガティブフィードバックはいつ起きても不思議ではありませんし、タイミングによらず悲しい結果に終わる可能性もあります。
プロジェクトのしょっぱなにネガティブフィードバックがやってくると、モチベーションをごっそり削られる可能性もあります。人気が出てきた後でも、ネガティブフィードバックがやってくれば不安になったり疑心暗鬼になったりする可能性もあります。
以下の残念なフィードバックを見てみましょう。
底意地の悪いGitHubコメントがプロジェクトを真っ向から口汚く批判しています。つらい。
さぞやつらかったでしょう。心中お察しします。
はっきり申し上げますが、ネガティブフィードバックは人の魂を根本から傷つける非道な行為です！
しかし何かしら打つ手はあるものです。とりあえず批判者には丁寧に質問する形で対話してみましょう。「なるほど。恐縮ですが、AがBより優れている理由を教えていただいてもよいでしょうか？」
PostCSS 8への移行を疑問視する批判者とSNSでやり取りする方法の例。
オープンソースの作者であるAndrey Sitnikからの質問と回答。
嫌がらせをしてきた相手が、実は自分の苦しみをぶちまけたかっただけで、本当は嫌がらせのつもりではなかった、ということもありえます。苦しみを打ち明けるのに、あなた以上にふさわしい相手は他にいるでしょうか？ですから、彼らの相手をすることを恐れてはいけません。
🔗 ボーナスその3: オープンソースにおける「ライバル」に関する最終メモ
かくして、あなたのプロジェクトは成功したものの、今度は競合プロジェクトが続々と出現したらどうしましょう？。
結論から言えば、ライバルを恐れないでください。
なぜなら、考えようによっては「1: もう自分のプロジェクトの面倒を見なくて済む」「2: 同じ（または近い）ビジョンを共有し、自分のよりも優れたソリューションが代わりに世界を変えてくれる」のですから、八方丸く収まるWin-Winな話じゃないですか😊。
本記事の冒頭で申し上げたように、つまるところ、オープンソースに取り組む最大の理由は、成功を独占することでもなければ、世界でただ1つの花になることでもなく、世界を変革することに尽きるのですから。
🔗 まとめ
オープンソースを普及させて知名度を高めることを理解するためのコツ:
- オープンソースを作る理由として最も優れているのは「世界を変革したいという動機」であって、有名になりたいとか履歴書を飾りたいとかではない。
- どんなにアイデアが優れていても、それだけでプロジェクトの成功が約束されるわけではないことを理解するのが重要。
- オープンソースが成功するには人気が重要であり、成功の公式は「プロジェクトの人気=あなた自身の人気 + プロモーション + ユーザーにとってのメリット + 運」である。
- SNSアカウントは積極的に運営し、見つけやすくなるよう工夫し、母国語以外の幅広い言語（英語など）も網羅すること。
ドキュメント作成のベストプラクティス:
- ドキュメントやREADMEは、バーで飲み友だちに説明するときのように明快かつ自然な文体を心がけること。
- 「太字」「箇条書き」を適切に活用し、ユーザーが深く読み進めるに連れて複雑な世界が段階的に見えてくるよう心がけること。
- 「裏付けのある本物の」証拠を添えること（実際の重要なベンチマーク結果や、価値がよくわかるコード例など）。
- 入門用のガイドを準備すること。
可能であれば具体的な活用事例も用意すること。
自己PRのコツ:
- 「でかい花火を一発打ち上げておしまい」にしないこと。
プロモーションは辛抱強く継続的に行い、「リリース」「フィードバック対応」「改善」の繰り返しを絶やさないこと。 - 定期的にSNSにポストすること（ただしスパムにならないよう注意！）。
- SNSにポストするときはコード例や画像を添えること。
- 自分のライブラリを使ってくれている他のプロジェクトにプルリクを送って貢献しよう。
プロジェクトが既に成功を収めた方向けのヒント:
- 自分一人で何もかも抱え込まないこと。
改善を求めるユーザーにはプルリク送信を推奨しよう。 - issueを解決するための時間を適宜確保すること（1日15分など）
- ネガティブフィードバックには「どうしたらよくなりますか？」と質問で返そう。
- ライバルをむやみに恐れないこと。
ライバルは、ことによればオープンソースにおけるあなたの責務を解放してくれるありがたい存在になるかもしれません！😉
概要
元サイトの許諾を得て翻訳・公開いたします。
日本語タイトルは内容に即したものにしました。