|
編集者注：オープンソースは簡単そうに見えます。やりたいならやるだけ、そうでしょう？そうかもしれません。しかし、オープンソースで成功したいのであれば、先人たちの教訓に耳を傾ける必要があります。オープンソースプロジェクトの作成は、単にコードを書くだけではありません。実際、最も難しいのはコード自体を書くことではなく、どのようにプロモーションやマーケティングを行うか、どのようにメンテナンスを行うか、そして荒らしにどう対処するかです。Formidableのオープンソースディレクターは、ほろ苦いオープンソースガイドの中でこう言っています。「オープンソースを心から愛していないなら、オープンソースプロジェクトに参加しない方が良い」と。
こんにちは、ケンです。 私は Formidable のオープンソース ディレクターです。 私のことを聞いたことがあるなら、それはおそらく次のいずれか、または両方の理由でしょう。
今日は2つ目の点に焦点を当てます。最近（そして過去にも）、多くの人からオープンソースに関するアドバイスを求められたので、今日はそれについて書こうと思いました。 その前に、オープンソースの問題に取り組みたい理由と私の個人的な経験についてお話しします。 OSS（オープンソースソフトウェア）を書くべき理由 オープンソースがあなたとあなたのキャリアに利益をもたらす理由はたくさんあります。
私のOSS体験 認めます。私は史上最悪のオープンソースメンテナーです。最悪ではないかもしれませんが、最高だったことは一度もありません。 私はオープンソース プロジェクトの管理を何度か失敗しましたが、かなりの数のプロジェクトをうまく作成していなければ、そういったことは起こらなかったでしょう。 しかし、私はプロジェクトの失敗から何かを学び、そこから得た洞察を次回のより良い成果に活かしてきました。これについては後ほど詳しく説明します。確かに上達していますが、読者の皆さんにも私の失敗を繰り返すのではなく、そこから学んでいただければ幸いです。 典型的なOSSの経験と比べると少し変わっているので、私の経験を簡単に概説することにしました。信じられないかもしれませんが、これまでのキャリアの中で、自分が関わったプロジェクト以外に貢献したプロジェクトは20件にも満たないと思います。 私の最初のOSSプロジェクトは、おそらく最も成功したプロジェクトだったと思います。当時は広告代理店で働いていて、ニューヨークの大手ファッションブランドのEコマースウェブサイトを構築していました。私はチームのシニア開発者で、主にJavaScriptの開発を担当していました。jQueryの時代に戻りましょう… ファッションEコマースの興味深い点の一つは、カルーセルの豊富さです。しかも、非常に複雑で野心的なデザインになっていることがよくあります。既存のカルーセル/スライドショーライブラリは、提示されたデザインに対応できるほど柔軟ではありませんでした。そこで、CoffeeScriptを使って独自のカルーセルを一から書き始めました。うまくいきましたが、もちろん、同僚からの評価は上がりませんでした。 そこで、明確なニーズがあることに気づきました。デザイナーがどんなデザインでも対応できる、柔軟性が高く、しかも使いやすく変更しやすいカルーセルプラグインが必要だと考えたのです。そこで、みんなのためにプラグインを作りました。そして、これがとても便利だと気づきました。だったら、他の人の時間を大幅に節約できるのもいいじゃないか、と。そこでオープンソース化したのです… 結果は、確かに人々の時間を大幅に節約し、皆に気に入ってもらえたようでした。リリース後数ヶ月で、その人気は急上昇しました。私はまだOSSに馴染みがなく、自分の製品を皆が使ってくれるのを見るのが待ちきれませんでした。そのため、非常に熱心に取り組んでいました。問題の修正や新バージョンのリリース、そして誰にも真似できない製品にするために、徹夜で作業することさえ厭いませんでした。 この記事はヒントを提供することが目的であり、私自身のストーリーを語るものではないので、あまり詳しくは触れません。最終的に、プロジェクトのメンテナンスをやめました。いくつかアナウンスもしました。転職したので、カルーセルはもう必要ありません。あの問題はもう解決しませんでした。Reactが登場し、私は長年Reactを研究していたので、jQueryのようなものにはもう興味がありませんでした。 でも、一番大きな原因の一つは、私が疲れ果てていたことでした。働きすぎたんです。コメント欄のみんなは、メリーゴーランドを使うべきじゃないとか（私はお金を稼ぐためにやっているプロジェクトごとにメリーゴーランドを一つずつ持っていて、全部手作りなんですが）、太ったとか、妻が怒ったとか、独善的なことを言っていました。 それ以来、私は様々な分野で人気のあるライブラリをいくつか作成し、それぞれ異なる問題を解決してきました。最大の懸念の一つは、クリック率の低さを心配して、二度と人気のあるライブラリを書けなくなるのではないかということです。今のところ、その不安は何とか避けていますが、時折、おかしなことをしてしまうこともあります。しかし、今でも乗り越えられないのは、Carouselプロジェクトの管理です。インターネットの半分の人々を失望させてしまったような気がしました。 そこで、以下では、いくつかの経験を皆さんと共有し、皆さんが後悔を残すことなく、それらを活用して成功するプロジェクトを作成できるようにしたいと思います。 はじめる オープンソースはスピーチによく似ています。多くの人は、自分が売っているものに十分な価値があるとは思っていません。それは全くのナンセンスです。もし「インポスター症候群」について読んだことがあるなら、これは全くの真実です。誰もが独自の知識基盤を持っており、誰もすべてを知っているわけではありません。あなたが売っているものを必要としている人は必ずいるのです。 私には2つの強みがあります。1) オープンマインドであること、2) 自分に自信があるので、とにかく書き留めるだけです。しかし、この2つの点は多くの人にとって難しいことに気づきました。 私の提案： 最悪の事態って何だろう？批判される？いいかい、君。たとえ完璧で、最も便利で、最も印象的なコードをGitHubに載せたとしても、どうなると思う？ 嫌な奴がやって来て文句を言うだろう。それは避けられないことだ。最悪のシナリオでも、何かを学ぶことはできる。誰かが「おい、これだとパフォーマンスがひどく悪くなるぞ」と言うかもしれない。「えーと、プログラミングの仕方がわからないから、諦めて、もうやめる」と言うか、「おお、アドバイスありがとう。修正したから、今は良くなった」と言うか。改善する側になりなさい。 では、何を開発すべきでしょうか？これは何百万ドルもの価値がある質問です。 私の見解はこうです:
それではパッケージ化の方法についてお話しましょう... API設計 あなた自身のアイデアがあるとしましょう。問題を抱えていて、それを解決しました。でも、他の人にも使ってもらいたいですよね？あなたのアイデアを他の人に使ってもらうためのヒントをいくつかご紹介します。 まず、既存の技術と競合他社の技術を検討してください。他のライブラリが同じ機能を提供している場合は、何か違うものが必要です。例えば、次世代のLodashを開発したいとしましょう。さあ、頑張ってください。しかし、それだけでなく、Lodashから市場シェアを奪うには、魅力的な何かが必要です。Lodashよりも小さく、高速で、より優れたAPIを備えている必要があります。これで、私がなぜこのようなことをしているのかお分かりいただけたでしょうか？ API設計においては、バランスが重要です。設定不要ですぐに使えるライブラリを作成しても、変更したいという要望が出てくるでしょう。また、最も柔軟で設定可能なライブラリを作成しても、Tobias Koppers/Sean T. Larkinのような状況になり、設定作業が必要という要望が出てくるでしょう。（Sean、ごめんなさい。私はそうせざるを得ませんでした。バージョン4はかなり良い出来です。） 使いやすさと必要な設定の完璧なバランスを求めています。何よりも、シンプルでわかりやすく、使いやすいものを選びましょう。やり過ぎると、周りの人をイライラさせてしまいます。 私が好きなことの一つは、ソースコードを非常に明確に、しかし巧妙に書かない書き方をすることです。こうすることで、他の人が貢献しやすくなります。意味に基づいて名前を付け、自己満足的なプログラミングは避け、何かを作る場合は、その理由をコメントアウトしてください。 しばらくコードを一行も書いていませんでしたが、ようやく思い描いたモックAPIが完成しました。実際のAPIに仕上げるには時間がかかりますが、やりがいのある目標です。APIが完成したかどうかは、きっと分かります。なぜなら、その時に初めて、そのAPIを好きになり始めるからです。 リリース準備完了 問題を解決し、適切にパッケージングしたら、いよいよリリースです。しかし、リリースする前に、他の人に使ってもらうためにいくつか準備が必要です。 ちゃんとしたドキュメントを書いてください。 これは冗談ではありません。ドキュメントはこれまでで最高のものにしなければなりません。上から目線は避けてください。冒頭には見出し、リンク、索引などを用意してください。初めてこのツールを実行するまでの、骨の折れる詳細を説明する導入セクションも必要です。APIのあらゆる詳細を、途方もなく詳細な言葉で記述する必要があります。 メソッドがある場合は、想定されるパラメータ、型、戻り値の型をドキュメント化する必要があります。そのメソッドの機能を説明し、使用方法を示す例を挙げてください。ライブラリは、他のユーザーが簡単に使用できるようにしてください。 どのように貢献するのかを説明してください。また、これらのコンパイル手順をすべてどのように実行するのかを説明してください。他のプロジェクトやコンセプトを参照する場合は、リンクを貼ってください。リンク可能なものを参照する場合は、リンクを貼ってください。 徹底的かつ詳細なアプローチをとると、まったく異なる結果が得られます。 ちゃんとテストを書いてください。 注意深く聞いてください。テストの範囲が適切なレベルであることを確認する必要があります。その理由は次のとおりです。
以前、テストをせずにライブラリをリリースしてしまったのですが、ポール・アイリッシュから「テストをしてくれたら嬉しいよ」と言われました。当然のことながら、私は「おお、ポールだ！」と喜び、テストを書き始めました。そして、テストを書いた後、なんと15個のバグを発見しました！ポール、ありがとう！ 何か書いたことがあるなら、テストを書き続けてください。お願いします。まさに最高のおまけです。時間と労力を大幅に節約できます。 テストを記述して Travis または任意の継続的インテグレーション プラットフォーム上にセットアップしたら、あとは安心できます。 使用タイプ テストで見逃されるバグは、型チェックで検出できます。JSを型付けしないことは、シートベルトなしで運転するようなものです。さらに、TypeScriptやFlowを使う人が増えていますが、それらはすべて型が既に用意されていることを前提としています。型を使ってライブラリを作成し、エクスポートして型を提供すると、きっと感謝するでしょう。後から誰かに型をアノテーションしてもらうこともできますが、その型はサードパーティ風だったり、時代遅れだったり、間違ったものになったりするかもしれません。それはあなた次第です。 リポジトリ（コードリポジトリ）の前提条件
えっと、READMEですね。LICENSE.txtは必ず含めてください。そうしないと、コードベースを使えない人が出てきます。MITライセンスを使用してください。自分でライセンス条項を書こうとするのはやめましょう。MITライセンスのみを使用してください。さあ、書いてください。 CONTRIBUTING.mdは、プロジェクトの進め方を示すのに最適な場所であるだけでなく、行動規範へのリンクや追加にも最適な場所です。コンセプトに賛同するかどうかに関わらず、行動規範に必ず追加してください。そうすることで、安心して貢献し、参加してくれる人が現れるでしょう。また、後々問題が発生した場合に、気に入らない人を排除すべき理由を説明するのにも役立ちます。 錦織に花を添える 素晴らしいドキュメントを書き、API も適切に設計され、前提条件もすべて整い、コードベースをきちんと見せる準備が整っているとしましょう。しかし、まだいくつかコメントがあります。 バッジ。コードベースを印象的に見せるのにバッジほど効果的なものはありません。バッジが多すぎるのは明らかに良くありませんが、役に立つものをいくつか含めれば、それは正当な評価となり、あなたがコードベースに気を配っていることを示すことができます。 npm バージョン、テスト ステータス、カバレッジ データなども非常に役立ちます。 さらに、Markdownは生のHTMLをサポートしているので、リポジトリのタイトルをより美しく仕上げることができます。コンテンツを中央揃えにしたり、引用符を追加したり、スタイルを調整したりしましょう。 本当に金メダルを獲得したい場合は、このリンク (https://github.com/kentcdodds/all-contributors) から学び、貢献者エントリを追加してください。 プロジェクトに貢献してくれる人々と知り合えるのは本当に素晴らしいことです。 リリースとマーケティング さあ、準備は万端！いよいよデビューです！新しいライブラリを他の人に見てもらい、使ってもらうにはどうすればいいでしょうか？ 私の提案は非常に具体的です。月曜日の午前0時（東部標準時）に公開されます。これはヨーロッパでは一日の終わり、ニューヨークでは昼食の時間、サンフランシスコではまだ早朝で、まだ何も終わっていない時間帯です。この時間帯には、多くのユーザーがインターネットをスクロールしているはずです。 発表の仕方としては、まずはTwitterかなと思います。思い切って発信してみてください。 キーボードで CSS を書くのに飽きていませんか? なんと、Xbox コントローラーで書けるようになりました! 「スタック トレースにイライラしていませんか? これを VR で追跡するとしたらどうしますか?」 さあ、始めましょう。ただし、魅力的なものにする必要があります。画像や動画を使いましょう。機能と使用すべき理由を明確にし、リンクを貼ってください。手順は以下のとおりです。
コードベースの人気度はフォロワー数や彼らに宣伝する技術方向性によって左右されるかもしれませんが、これらは一般的に効果的な戦術です。Twitterユーザー以外にも、HN（Hacker News）やRedditへの投稿も効果的です。 さらに、必要に応じて、特に企業バナーでリリースを発表する場合は、リリースと並行してブログ記事を公開することもできます。長めの形式でも構いません。 大胆に、自信を持って、コンテンツに十分なスペースを割く準備をしましょう。 維持する いつもこの部分が私の経験の中で一番辛い部分なので、本当に気が重いです。でも、失敗から学んだ教訓を皆さんにシェアしたいと思います。読んでいただければ、これから何が起こるか少しは分かってもらえると思います。 これでライブラリが公開されました。次に以下の2つのことが起こる可能性があります。 1. 失敗しました。 誰が気にする？これは私にもよくあることだ。とにかくやり直せばいい。物事がうまくいかないこともある。それは必ずしもあなたの能力が低いとか、アイデアに欠陥があるということではなく、タイミングが悪かっただけ。重要なのは、それをやり遂げたこと、そして正しくやり遂げたことだ。次に何かを開発するときは、もっと良い準備ができて成功できるだろう。自分を励ましてあげて、次回は頑張って！ 2. ヒットしました。 こういう時こそ本当に困る時です。みんながあなたの作品を気に入ってくれて、Twitterでリツイートしてくれるんです。常にバグを修正し、質問に答え、自分のアイデアを擁護し続けなければなりません。これについて、いくつか考えがあります。 まず、あなたのライブラリを改良することに興味がある人がいたら、その人をメンテナーに任命してください。繰り返しますが、 ライブラリを微調整することに興味がある人がいたら、その人をメンテナーにしてください。 理由はこうです。時が経ち、新しい技術が登場し、問題は変化します。あなた自身も変化します。しかし、リポジトリは残ります。委任すれば、必ず悪い状況に陥ります。メンテナンスに疲れ果て、プロジェクトに不満を抱き、最終的には負担になってしまいます。信じてください、このタスクは委任しましょう。 次に、人との付き合い方についてお話ししたいと思います。 これはオープンソースの最も重要な部分の一つであり、しばしばコードを書くことよりも重要です。待ってください、人々はあなたを批判するでしょう。彼らは皆、批判する権利があると考えています。彼らはあなたのプロジェクトを公然と軽蔑するでしょう。 あの人たちは地獄に落ちろ。 このプロジェクトにはすでに多くの時間を費やしてきたので、今は他のことにエネルギーを注ぎたいと思っています。信じてください、あのトロールどもは地獄へ落ちてしまえばいいんです。 ただし、荒らしには注意が必要です。荒らしのように見える人が、実際にはそうではないこともあります。覚えておいてください。あなたはコードを全世界に向けて公開しているのですから。誰もがあなたの母国語を話すわけではないことを忘れないでください。 ロシア語で書かれたリポジトリに貢献したいとします。でも、ロシア語がわかりません。そこでGoogleで「『これが実装されるタイムラインです』を翻訳」と検索します。すると、例えばロシア語に翻訳された内容は「これはいつ完成するのですか？」という意味だったとします。一見すると、「一体この人、どうしたの？」と思うかもしれません。しかし、インターネットでは意味がうまく伝わらないことに気づき、翻訳後はさらにひどい状況になります。 これに注意してください。相手が怒っているのではなく、単にあなたの言葉が話せないだけという場合もあります。 それに加えて、プルリクエスト（PR）には堅牢なCI（継続的インテグレーション）を導入し、質問に回答し、PRテンプレートを用意しておくことが最善のアドバイスです。コードベースでは多くの質問やPRに遭遇するでしょう。それらをうまく管理するには、いくつかの基本的なルールが不可欠です。私のアドバイス：
一度限りのバグの中には、発見する時間が十分になかったものもあります。ユーザーにバグの存在と、それを簡単に特定できることを証明してもらい、問題解決のための時間を確保しましょう。 さらに、CONTRIBUTING.md のどこかで、PR を処理する前に、Issues セクションの人たちとアイデアを議論してみる価値はあります。世の中で一番悲しいのは、決して受け入れられない PR を処理するために、誰かが多大な労力を費やしてしまうことです。 プルリクエストの受け入れについて言えば、このセクションで最後に伝えたいのは、他の人の要求に応じる必要はないということです。私はユーザーに譲歩したせいで、APIの作成に多大な労力を費やしました。 多くの場合、一部の人は自分の孤立した問題を解決するためだけに何かを求めますが、その問題はコミュニティ全体にとって何の価値もありません。APIに変更を加える際は注意が必要です。極端なニーズを持つ人がAPIを台無しにしてしまうからです。グライダーのリモートコントロールシステムを開発している人の問題を解決することではなく、コアライブラリを適切なものにすることに集中してください。 ああ、嘘でした。あと一つ。セマンティックバージョニングを正しく使いましょう。 お願いします。そうしないと、みんな気が狂ってしまいます。プッシュ通知もあります。そしてバージョンノートもあります。詳細なバージョンノートです。リポジトリが進化するにつれて、関係者に何が起こっているかを常に知らせることが重要です。 透明性、明確性、そして情報提供を徹底してください。何かを拒否する前に猶予期間を設けてください。ライブラリに投資したユーザーが、変更によってアプリケーションに問題が発生した場合、不満を抱くでしょう。ライブラリの更新は、思いやりを持って行いましょう。 結論は ここまで読んで、私がOSS（オブジェクトストレージサービス）だけでなく、文章を書くのも苦手だということはお分かりでしょう。でも、誰かに書いてほしいと頼まれたので、書いてみました。この長々とした記述が、オープンソースプロジェクトをリリースしたいと考えている方々の時間を節約し、気分を害さずに済むような、少しでもお役に立てれば幸いです。 ここには多くの落とし穴がありますが、その一つ一つに対処できれば、あなたの人生は私よりもずっと楽になり、成功する可能性もずっと高くなります。 最後に、もう一つアドバイスがあります。本当にやりたいのでなければ、やらないでください。やらなければならないことのように思わないでください。やらなくても仕事は見つかります。やらなくても優秀な開発者になれます。私はライブラリ開発から多くの恩恵を受け、心から楽しんできましたが、ライブラリ開発に費やした自由な時間は二度と取り戻せません。その時間を家族と過ごしたり、趣味に没頭したり、収入につながる何かに使うことができたはずです。やりたいからやってください。開発に情熱を持っていなければ、おそらく成功はないでしょう。 |
