何年もの間、OSSのメンテナンスで得た収入は0ユーロでした。それが当たり前だと思っていました。昨年、ようやく自分のプロジェクトを収益化する方法を調べ始め、このトークではそこで学んだことを共有したいと思います。まだお金持ちにはなれていませんが（いつかは！）、analysis-tools.devで初めて持続可能なサイドプロジェクトを作ることができました✨。

このプロジェクトや他の取り組みについて、そして持続可能性を目指す過程で犯した失敗についてお話しします。

関連リンクと資料：

• Caleb Porzioによるポッドキャスト — GitHub Sponsorsを中心にビジネスを構築するのがなぜこれほど難しいのか。
• The Changelog Podcast — Zeno Rochaと語る「オープンソースでお金を稼いでもいい」。
• Nadia Eghbalによる「私たちの重要なインフラのメンテナンス」についてのトーク。彼女はこのテーマで『Working in Public』という本も執筆しています。
• Vadim Demedesによる「Generating income from open source」 — さまざまな実例をもとにプロジェクトを収益化する多様な方法を解説しています。

トークの全文書き起こしを以下に掲載します。（長文で申し訳ありません。）

これは2020年末にWeb Engineering Meetup Aachenで行った、オープンソースでお金を稼ぐことについてのトークです。主催者のご厚意で、YouTubeチャンネルでも公開することができました。根本的な問いは「なぜGitHubで10万ドル稼げないのか？」ということです。企業スポンサー探しや、オープンソースのメンテナンスを持続可能にするまでの長い道のりについてお話しします。

もしかすると、そもそも始める気になれないかもしれません。このトークは、成功するまでに時間がかかるならオープンソースにそこまで労力をかける価値はない、と考えている方に向けたものです。正直、このトークは少し暗い内容になりました。本当はもっと勇気づけられる話にしたかったのですが、現実は厳しく、厳しいというのは本当に厳しいという意味です。

まずはこの点をしっかり伝えつつ、それでも挑戦する気持ちを持ってもらえればと思います。そもそも、なぜ私がこのテーマを語る資格があるのか。私はもう10年以上オープンソースに携わってきました。このトークは、15年前の自分自身に捧げるものでもあります。現在はデュッセルドルフに本社を置くホテル検索会社trivagoで働いています。ブログはendler.devで運営しています。そして例にもれず、私もYouTubeチャンネルを持っています。「Hello, Rust!」という名前で、2年に1本という驚異的なハイペースで活動しています。ですので、更新を見逃さないよう、ぜひチャンネル登録をお願いします。さて、今日はオープンソースについてお話しします。とても洗練された構成を用意してきました。ポイントは2つ、「私の歩み」と「収益モデル」です。

2010年まで一気に遡ってみましょう。当時の世界は今とはだいぶ違っていました。

これが当時のGitHubです。私は少し出遅れて、2010年1月に参加しました。その時点でGitHubはすでに2年目で、欲しかったユーザー名は取られていました。普段はどのプラットフォームでもmreというハンドルネームを使っているのですが、誰も使っていないことに気づき、サポートにメールで「使わせてもらえませんか」と尋ねてみました。すると「どうぞ」という返事が届きました。相手はハンドルネームdefunctで知られるChris Wanstrath、元GitHub CEOでした。この出来事ですっかりGitHubに惚れ込みました。プラットフォーム自体も、オープンソースに対して非常に実践的に向き合う姿勢も気に入りました。自分のプロジェクトでも使い始めました。スクリーンショットにあるように、例えばブログをアップロードしていました。無料でホスティングしてくれるからです。Jekyllで作って、サイトにプッシュするだけで静的生成されて公開される仕組みでした。言うまでもなく、この10年間で何も変わっていません。私のブログは今もほぼ同じ見た目です。jQueryとJekyllではなく、zolaとCloudflare Worker Sitesで作り直してはいますが、やっていることはほぼ同じです。このトークの準備にあたり、一度立ち止まって、自分がどこから来て今どこにいるのかを振り返りたいと思いました。そのために統計を見てみるのが一番だと考え、リポジトリ数の推移を調べることにしました。GitHub APIを叩いて取得したのが次のグラフです。

ご覧のとおり、2010年から2020年までほぼ直線的に増えています。2018年だけ生産性のピークだったようですが、まあそれは置いておきましょう。結局、リポジトリ数はほぼ線形に推移しています。一見、投入した労力に応じて成果が返ってくるように見えますが、実際は違います。そこには複利的な効果があります。スター数の推移を見てみると、最初はとてもゆっくりと増えていましたが、今ではほぼ指数関数的に伸びており、現在はすべてのプロジェクトを合わせて25,000スターに達しています。別の見方としてフォロワー数もあります。これは私にとっては比較的新しい指標ですが、archive.orgから統計を調べてみました（GitHubのAPIでは取得できないため）。やはり、こちらもほぼ指数関数的な増加を示しています。

労力を投入すれば、その成果に利子がついて返ってくる複利効果があるのです。これは運ではなく、積み重ねた作業の結果です。何をすべきか分かってきたということです。一方で、見て見ぬふりができない事実があります。それは、結局のところ拍手をもらっているだけだということです。これまで収益は0ドルでした。では、この努力をどう収益化するのかという疑問が当然出てきます。

そもそも、それは努力と呼べるものなのでしょうか？

皆さんはどうか分かりませんが、私は平均すると1日2〜3時間はオープンソースに費やしています。新しいプロジェクトを考えたり作ったりする時間だけでなく、メンテナンスやコードレビューも含めてです。つまり、これはれっきとした仕事であり、しかもかなりの重労働です。それをほぼ無償で行っているのです。

無償で、趣味として何かをするのは全く悪いことではありません。ただ本来、趣味であれば好きなことだけをやればいいはずです。オープンソースはそうはいきません。時には義務感が生じ、人を助けなければという責任を感じます。それが大きな部分を占めるのです。本業の傍らでそれを行うので、本当に負担になることもあります。もうお分かりかと思いますが、これを何らかの形で価値に変えるのは難しく、本当に難しいことです。ここからは、オープンソースから適切な収益モデルを構築する方法についていくつかお話ししたいと思います。先ほどのグラフを見れば分かるように、これは最初に考えるべきことではないかもしれません。しかし、収益を得たいと思う段階に達したとき、いくつかの選択肢があります。ここでは、ビジネスの一部としてオープンソースを行う話や、大企業による大規模な支援の話はしません。誰でも実践できるいくつかの方法に絞ってお話しします。1つは[GitHubでの]スポンサーシップです。通常のドキュメントに加えて有料の学習教材を提供する方法もあります。例えば、有料の動画シリーズを作るといったことです。Mozillaのようにマーチャンダイズを販売する方法もあります。オープンソース事業と並行してコンサルティングを行う方法、サービスやプラグインを提供する方法もあります。ADFSプラグインや高可用性機能の開発などは、企業向けの有料機能としてとても一般的な例です。

まずは基本から始めましょう。1つ目のポイントであるスポンサーシップについてです。スポンサーシップには2種類あります。1つ目は個人からの寄付です。個人スポンサーシップとは、まさにGitHub Sponsorsが提供している仕組みのことです。このモデルで収益を得たいなら、ファネル（漏斗）のことを考える必要があります。どうやって人々の注目を集め、それをどう収益化するかを考えるのです。すべてはプロダクトから始まります。プロダクトは何でも構いません。そこから関心が生まれ、その関心がオーディエンスを作り、そのオーディエンスが最終的にお金を払ってくれる。これが実はすべての秘密です。どんなプロダクトでもお金を稼ぐ仕組みは同じで、オープンソースでスポンサーを集めたいなら、人が欲しがるプロダクトを作ることが大切です。

これをオープンソースに置き換えると、プロジェクトを作ることはリポジトリを作ることに当たり、スターはオーディエンスの関心を示します。オーディエンス自体はフォロワー（個人のフォロワーや企業のフォロワー）で構成され、そのフォロワーが最終的にスポンサーになるかどうかが決まります。スターは人気を測る指標としては不完全だと承知しています。人によって使い方が違うからです。例えば、後で見返すためのブックマークとして使う人もいれば、開発者の努力に感謝して付ける人もいます。それでも、大まかな目安としては有用です。

では、次のことを考えてみてください。私のスター数、フォロワー数、そしてスポンサー数です。今の私の「ファネル」について考えてみましょう。先ほどお伝えしたように、私は25,000スターと約1,000人のフォロワーを持っていますが、そのうちスポンサーは3人です。つまり、スターに対するスポンサーの比率は0.01です。かなり厳しい数字です。1人の支援者を得るのに約8,000スターが必要ということになります。「もしかして自分だけなのか？」とも考えました。上位1,000人のGitHubメンテナーなら違うのではないかと。しかし、結果は全く同じ構図でした。上位1,000人のメンテナーのスポンサー数を見ても、やはり厳しい現実が浮かび上がります。例えば中央値を見ると、1人あたり3,421人のフォロワーがいるにもかかわらず、スポンサー数の中央値はゼロです。計算が正しければ0%です。平均で見ても、フォロワー数は5,430人（Linus Torvalds氏が平均を押し上げているため）で、スポンサー数は平均2.8人、つまり0.5%です。私よりは少し高いですが、ほぼ同じ水準です。さらに考えてみてください。GitHubのユーザー数は4,000万人ですから、上位1,000人のメンテナーはコミュニティ全体のわずか0.0025%に過ぎません。そのトップ層でさえ、GitHubでの収入の中央値は実質ゼロなのです。

それ自体が最大の問題ではないかもしれませんが、2019年のGitHubの収益が3億ドルだったことを覚えておいてください。昨日Hacker Newsでこんなコメントを読みました：

GitHubでスポンサーを募っていますが、月に2ドルという素敵な収入があります。税引き後はもちろんさらに少なくなるので、本業は欠かせません。

つまり、この仕組みは明らかに機能していません。オープンソースを収益化する別の方法を考えるか、GitHub Sponsorsがより普及するのを待つか、どちらが先かという話です。ここで1つだけ簡単に触れておきたいのが「sponsorware」という考え方です。比較的新しい概念で、まだ聞いたことがない方もいるかもしれません。私は個人的にとても気に入っています。簡単に言うと、プロジェクトを作って非公開のままにしておきます。一方でTwitterや他のプラットフォームで「こんなものを作っています。早期アクセスが欲しければスポンサーになってください」と発信します。そして、スポンサー数や収入などが一定の閾値に達したら、プロジェクトを公開するのです。最初に紹介した、オープンソースで10万ドル稼いでいるという例は、まさにこの手法を実践している人のものです。彼はプロダクトやサービスを作り、それについて発信し、最終的に誰でも使えるようにオープンにしているのです。

この手法にはいくつかの利点があります。1つ目は、あなたのミッションを本当に信じてくれる人たちから早期にフィードバックを得られることです。2つ目は、常に無償で働く必要がなくなること。3つ目は、プロジェクトを通じてオーディエンスや盛り上がりを作り出せることです。デメリットは、筋金入りのオープンソースやフリーソフトウェア信奉者にとっては、このやり方が理念に反する点です。ソフトウェアは最初から何の条件もなくオープンであるべきだ、と考えるからです。ですので、この点については自分自身で判断する必要があります。私も試してみました。スポンサー限定で共有する早期アクセスプログラムを用意しています。[最初にsponsorwareとして作ったのは]GitHubの統計を取得するツールで、[このトークで紹介した統計も]そのツールで作成しました。これを成功させるには大きなオーディエンスが必要だと思います。これだけの労力をかける価値があるか、それとも最初からオープンにして別の収益モデルを考えるかという問題です。ただ、非常に興味深い概念だと思いますし、今後もっと目にするようになるかもしれません。どんなものかイメージが湧き、名前も覚えていただけたかと思います。

もう1つは企業スポンサーシップです。これは諸刃の剣です。企業スポンサーシップとは、企業がお金を出してくれる代わりに、何かを求めてくることを意味するからです。追加のサポートを求められたり、バグ修正を期待されたりと、なんだか彼らのために働き始めているような感覚になることもあります。とはいえ、近年多くの企業がオープンソースにかなりの額を投資しているのも事実です。例えば大手2社を見ると、FacebookとGoogleは寄付を集めるプラットフォームであるOpen Collective上で、それぞれ生涯で17万7,000ドルと84万5,000ドルをオープンソースに投資しています。これは本当に素晴らしいことです。もっと多くの企業がそうすべきです。ただ、ちょっとした余談というか、愚痴になりますが、私はこれらの企業がやっていることは少なすぎると思っています。

Facebookの昨年の収益は700億ドル、Googleは1,600億ドルでした。決して恥ずかしい数字ではありません。だからこそ、これが本当に精一杯なのかと疑問に思うのです。もちろんGoogleはMozillaなど他のプロジェクトにも寄付をし、ミートアップを主催するといった活動もしています。しかし、2人のスタンフォードの学生が検索エンジンを作ろうとしていた当時、PythonやWebサーバー、Linuxが存在しなければ、今のFacebookやGoogleは存在したでしょうか。Fortune 500企業は、自分たちがどれほどオープンソースに依存しているか、そしてどれだけ多くの人々がインフラの重要な部分を支える少数の人々に依存しているかを、本当に理解していないのではないかと感じることがあります。

オープンソースへの投資はまだまだ足りないと思っています。多くの人が想像するオープンソースの姿は、左のパネルのように大勢のエンジニアが一室に集まって最善の構築方法を議論している光景かもしれません。しかし現実は、夜遅くまでバグ修正に取り組む一人の人間が、信念だけで続けているというのが実態に近いです。世間の認識はおそらく間違っており、重要なインフラを支えているのは本当に小さなグループなのです。時にはそれが非常に厄介な事態を招きます。私が子供の頃から憧れてきた2人が、このことについて率直に語っています。1人はPythonのrequestsの中心的なメンテナーであるKenneth Reitz氏、もう1人はキーバリューストアRedisの作者であるantirez氏です。1人はフロントエンド、もう1人はバックエンドの世界からです。2人とも、大規模なオープンソースのメンテナーになることの重圧がいかに早く燃え尽き症候群につながるかを語っています。インターネットは眠りません。あなたも眠れなくなります。常にチケット、機能要望、プルリクエスト、issueが届きます。常にやることがあります。しかも、それに加えて他のあらゆる責任もこなさなければなりません。だからこそ、あっという間に燃え尽きてしまうのです。私が深く尊敬している人物がもう1人います。Mark Pilgrim氏です。『Dive Into Python』の著者で、かつてインターネット上から自分に関するすべてを削除する、いわゆる410（Gone）を実行した人物です。これには実際に「infocide（情報自殺）」という言葉もあります。彼はエコシステムにうんざりしてしまったのです。Rubyコミュニティをご存知なら、『Poignant Guide to Ruby』の著者である_why氏を覚えているかもしれません。彼も似たようなことをしました。antirez氏の言葉に注目してみましょう。「Redisの仕事でお金を受け取るようになってからは、以前のような働き方を倫理的に続けることはできなくなった。だから自分を無理やり通常の勤務時間で働くようにした。これは何年もの間、私にとって大きな葛藤だった。しかも今となっては、そのせいで本来できるはずのことより少なくしかできていないと確信している。でも、これが現実なんだ」。彼は、そうした働き方を強いられ、十分に成果を出せていないのではないかという罪悪感を抱えているように感じられます。私にはそこに燃え尽きの兆候が見えます。これがオープンソースとお金の愛憎関係です。お金を受け取れば、それは仕事になります。しかし、ほとんどの時間はコードを書いているわけではありません。トークの準備をし、プルリクエストをレビューし、issueを確認し、StackOverflowで質問に答え、Discordで議論し、YouTubeやカンファレンスでマーケティングを行うのです。オープンソースで人気が出ると、2つの選択肢しかないように感じます。1つは抑うつ、もう1つは燃え尽きです。プロジェクトが成功しなければ、突然自分は失敗作で、間違いだったと思い込みます。スターはゼロ、誰も気に入ってくれない。一方で成功すれば、みんなが気に入ってくれますが、今度は抱きしめられて窒息しそうになります。本当に不幸な状況です。そうした責任に押しつぶされないようにするには、明確な境界線を引き、どちらの毒を飲むかを選ばなければなりません。企業をスポンサーとして受け入れる際には慎重になる必要があります。ここで、うまくいった一例と、そこに潜むリスクを紹介したいと思います。今年の初め、ずっと先延ばしにしてきた本格的なプロジェクトにようやく取り組み始めました。

実は、2015年12月にGitHubで静的解析ツールのリストを作り始めました。静的解析ツールとは、コードの改善を助けてくれるツールのことです。調べてみると、そうしたツールは驚くほどたくさん存在しました。まずは集め始めることが第一歩でした。当時は深く考えていませんでしたが、時が経つにつれ、そのリストはとても人気になりました。このグラフを見ると、スター数は時間とともにほぼ直線的に増加しているのが分かります。2018年になると、これは単なるGitHubプロジェクト以上のものになるのではないかと真剣に考え始めました。多くの人に「ここからもっと何かを作りたい」というアイデアを話しました。最後の一押しをしてくれ、やる価値があると確信させてくれたのがJakubでした。彼は「ウェブサイトにしてみたら？」と言ってくれました。そして2週末ほどかけて、ウェブサイトを作りました。Gatsbyで作られていますが、技術的なことは重要ではありません。とにかく作って、どうなるか見てみることにしたのです。現在は500のツールを掲載しており、初期の反応はとても良いものでした。皆さんに気に入ってもらえたようです。初日だけで72万リクエストがあり、その後1週間ほどで約150万リクエストに達しました。素晴らしいことでした。突然、このプロジェクトに興味を持ってくれる人が増えたのです。そこでスポンサー探しを始めました。スポンサーになってくれた企業は特別です。彼らは私たちのミッションを信じてくれていますが、同時にオープンソースがどういうものかも理解しています。彼らは私たちに自分たちのツールを宣伝してほしいと期待しているわけではありません。開発者に売りたいので、開発者の記憶に残りたいのです。「やあ、あなたは開発者ですよね。私たちはこんな素晴らしいツールを作りました。ぜひチェックしてください！」というように。しかも、オープンソースに理解のある企業として見られるようにもなります。これはWin-Winだと思います。ただ、常にうまくいくわけではないことも付け加えておきます。企業の中には、単に安い広告枠として期待するところもあります。クリック数がそれほど多くないと分かると、すぐに離れていってしまいます。一方で、1〜2年後に報われるかもしれない投資だと理解してくれる企業もあります。そうしたミッションを理解してくれる企業には本当に感謝しています。ただ、企業が求めるものは個人が求めるものとは違います。企業は請求書を求めます。税務上控除できるものを求めます。きちんと運営を続け、メールにも迅速に対応してくれる相手を求めます。つまり、そうした義務が生じるのです。その手助けをしてくれるプラットフォームの1つがOpen Collectiveです。オープンソースプロジェクト向けの501c6プログラムがあり、フィスカルホストとして機能します。つまり、請求書発行などの事務手続きをすべて代行し、公式な運営主体となってくれるのです。オープンソースのメンテナーやコントリビューターとして[活動の対価を得たい]場合、Open Collectiveに請求書を送ることになります。

これは双方にとって最善の形だと思います。非常に透明性の高いプロセスなので、企業は常に状況を把握でき、煩雑な財務処理を自前で抱える必要がありません。一方で、対外的な見せ方をしっかり磨く必要もあります。企業はあなたをスポンサーすることで何が得られるのかを明確に知りたがりますし、あなたはそれを分かりやすく示さなければなりません。おそらく最も重要なページは、あなたのウェブサイトではなく、GitHub上のスポンサーページです。そこでは支援ティアの内容を説明しています。私たちは3つのティアを用意しています。1つ目は中小企業やフリーランス向けです。露出を得られ、オープンソースに友好的なテック企業として認知されます。月額100ドルです。中間のティアは、より大きな企業向けのカンパニースポンサーです。バッジも付与されますが、さらに宣伝したい静的解析ツールについてのブログ記事も提供します。ただし、それがスポンサー記事であることは透明性を持って明記します。最後に、一番上まで行くとフルコンテンツ制作のティアがあります。動画ワークショップなどが該当しますが、まだこのティアのスポンサーはいないので、詳しくお話しできません。ただ、ぜひ挑戦してみたいですし、得られるものに対して本当にお得だと思います。

いずれにせよ、これらは今日からでも始められることです。オープンソースへの取り組み方を大きく変えなくても、こうした仕組みを整えて様子を見ることができます。誰からも反応がなくても、それはそれで構いません。リストにあるそれ以外の項目は、どちらかというと上級者向けです。オーディエンスが必要になるので、まずはそこから始めるのが良いでしょう。

有料の学習教材は、私たちがanalysis-tools.devで今後動画コースとして取り組もうとしていることです。tailwindのような企業はこれを驚くほど上手くやっており、学べる点が多くあります。マーチャンダイズについては、ブランドが必要です。ですので私には向いていませんが、MozillaやYouTubeのCoding Trainのような存在なら、十分に実現できるでしょう。コンサルティングも常に選択肢の1つです。ただし、かなりの労力がかかり、本当に好きなことから離れてしまう可能性もあり、完全に仕事になってしまいます。本当にやりたいかどうか、よく考える必要があります。エンタープライズ向けサービスは、ビジネスとして運用でき、特別な要件が生じるような上位1%のプロジェクトにとって、非常に高度で[興味深い]選択肢です。まずは上から順に試していくのが良いと思います。まずはオーディエンスを作ることから始めましょう。GitHubでオーディエンスを作ってTwitterに流すよりも、Twitterでオーディエンスを作ってGitHubに呼び込む方がおそらく簡単です。あ、そういえば、難しいって言いましたっけ？暗い雰囲気で終わりたくはありません。強調しておきたいのは、もし今日から始めるとしても、私はまた同じことをやるということです。オープンソースに貢献するのに、今日ほど良い時期はありません。おそらく明日はさらに良い時期になるでしょう。突然、はるかに多くの人が関心を持ち、プロジェクトの立ち上げもずっと簡単になっています。VSCodeやGitHub Actions、無料ホスティングなど、無料のツールがすべて揃っています。ほとんどお金をかけずに、これほど多くのことが実現できるのは本当に驚くべきことです。ぜひ挑戦してみてください。最悪、何が起こるでしょうか？誰も気に留めない？それなら、私と同じです。ただ、今日から始めたい方のためにいくつかヒントがあります。1つ目のヒントは「宿題をしっかりやる」ことです。多くの人は学ぶことから始め、次に何かを作り、そして輪を閉じようとします。しかし、ここで1つ重要なピースが欠けています。嫌う人もいる言葉ですが、いずれ好きになるはずです。それはマーケティングです。マーケティングは人によって意味が異なりますが、私にとっては「知ってもらうこと」です。あなたが発信しなければ、誰か他の人が発信してしまいます。あなたは素晴らしいのですから、それに気づく必要があります。あなたの[プロジェクトのことを]最初から知っている人はそう多くないかもしれません。だからこそ、もっと語るべきです。カンファレンスでも、Twitterでも、友人に伝えるだけでも構いません。貢献や支援をお願いしてみてもいいでしょう。コミュニティでは、マーケティングをすると本気ではないと眉をひそめられることもありますが、私はそうは思いません。賢く、忍耐強く、情熱のある人たちがマーケティングをすれば、世界はより良くなると思っています。なぜなら、間違いなく悪意のある人たちはマーケティングをしているからです。ですので、宿題はしっかりやりつつ、オープンソースのメンテナーになることはビジネスを運営することであり、あなた自身がプロダクトなのだと覚えておいてください。なぜ誰かがあなたをスポンサーしたいと思うのかを考える必要があります。あなた自身がその答えを持っていなければ、相手に分かるはずがありません。ファネルのことも考えてみてください。例えば、人々はどうやってあなたを見つけるのでしょうか。人に見つけてもらう一番の方法は、おそらくYouTubeチャンネルを始めることです。

もちろん、もっと簡単な方法もあります。

[まず、]他のプロジェクトを手伝うという手が常にあります。コーダーである必要すらありません。デザインが得意なら、デザイナーを必要としているオープンソースプロジェクトが山ほどあると断言できます。驚くほど多いです。小さなプロジェクトのロゴを作ることから始めて、少しずつ認知を得ていくのも良いでしょう。もう1つは、楽しむことです。オープンソースでお金を稼ぐのが難しいと分かっていれば、それは逆に解放的でもあります。自由に実験でき、創造的になれるということです。やはり、楽しむことが一番大切なのだと思います。

2つ目は、自分が愛せるものを作ることです。結局は自分の自由時間を使うのですから。誰かがプロジェクトを見つけてくれる確率はそれほど高くありません。だからこそ、本当に興味を持てるものであるべきです。もし信じられないと感じたら、次に進めばいいのです。信じられなくなったプロジェクトを手放しても構いません。誰もそのことであなたを責めたりはしません。もし責める人がいるとすれば、それは嫌な人たちであり、そんな人たちに囲まれる必要はありません。

3つ目は、友好的な人を見つけることです。コミュニティとともに成長していくからです。プロジェクトを支えてくれ、ゆくゆくは負担を軽くしてくれるメンテナーになってくれるような人を求めたいところです。一人のメンテナーを見つけるのに何年もかかることもあります。だからこそ、常に友好的でいて、相手の立場に立って考えてみてください。できれば一歩踏み込んで手を差し伸べましょう。例えば、相手のプルリクエストにmasterブランチを再統合してあげるといったことです。代わりにやってあげるのです。迷ったら、ありがとうを二度伝えてください。

4つ目は、オーディエンスを育てることです。
積極的なマーケティングも1つの方法ですが、親しみやすく、誰もが参加しやすい存在であることもまた方法です。難しい質問があるときや、オープンソースを始めたいときに頼られる人になりたいものです。誰かの初めてのプルリクエストを手助けする人になるのです。彼らはその恩を千倍にして返してくれます。これまで出会った中で最も素晴らしい人たちは、質問に対して常にオープンで、見返りをほとんど求めません。そうした人たちのことは心から大切に思うものです。いざというとき、あなたはその人たちを思い出すでしょう。「一緒に働くには最高の人だ。心から推薦できる」と伝えることになります。これがいわゆるリード（見込み）です。

最後に、長期的に取り組むことです。良いことには時間がかかります。私の場合は10年かかりました。あなたなら5年、あるいはもっと短く済むかもしれません。ただ、一夜にして成功するようなものではないでしょう。これは本当に長期的な投資なのです。