人気のあるオープンソースプロジェクトのメンテナーは皆大変です。見ず知らずの他人が、質問に時間通りに答えなかったり、彼らが望む答えを検索しなかったりしただけで罵倒し、オープンソースプロジェクトのメンテナーたちはしばしば精神的な病を抱えるようになります。もしあなたがオープンソースプロジェクトを持っているなら、すでに実感しているかもしれません。
Nolan Lawson はマイクロソフト Edge ブラウザの Web プラットフォーム PM です。複数のオープンソースプロジェクトに参加しています。例：PouchDB、optimize-js など。オープンソースプロジェクトのメンテナーとは、どのような体験か？彼の 7 年間の身をもって体験したことをご覧ください。
数百人が列をなして、あなたの家の外で待っています。彼らはあなたが質問に答え、彼らの不満を聞き、Pull Request と Feature Request に返信するのを辛抱強く待っています。
あなたは彼ら全員を助けたいと思っていますが、ずっと先延ばしにしています。たぶん、あなたは一日中一生懸命働いたか、疲れているか、あるいは単に家族や友人と週末を楽しみたいだけかもしれません。
しかし、github.com/notifications にログインすると、Notification は何人があなたを待っているかを絶えず思い出させます：
403件の未読GitHub通知を示すスクリーンショット
あなたが何とか空き時間を見つけて、最初の人を迎え入れます（つまり、最初の問題を処理します。その中には複数の人が含まれる場合があります。以下同様）。彼らは十分に親切です。彼らはあなたのプロジェクトを使いたいと思っていますが、API でいくつかの混乱に陥っています。彼らはコードを GitHub のコメントに貼り付けましたが、コードをフォーマットする方法を忘れたか知らなかったため、コードはめちゃくちゃです。
幸い、あなたは彼らのコメントを編集してコードブロックを追加し、コードをフォーマットしました。しかし、まだ読むべきコードがたくさんあります。
また、彼らの問題の説明は少し理解しにくいです。たぶん英語は彼らの母国語ではないか、書面表現の能力が不足しています。いずれにせよ、あなたは彼らが提出したテキストの段落を理解しようと努力します。
あなたは疲れた目で、列の後ろで待っている他の数百人を見ます。最初の人のコードを理解するのに30分かけることができます。あるいは、ざっと見て、チュートリアルやドキュメントへのリンクを提供し、彼らの問題を解決できるかもしれません。Stack Overflow や Slack を試すことを楽しく提案することもできます。
2人目は眉をひそめ、不快な表情を浮かべています。彼らは、ある API が宣伝通りの効果がなかったため、あなたのプロジェクトが彼らの人生の2時間を無駄にしたと絶えず不満を言っています。彼の言葉は辛辣で、あなたを不快にさせます。
あなたはこの人にあまり時間を無駄にしません。「これはオープンソースプロジェクトであり、ボランティアによって維持されています。コードにバグがある場合は、再現可能なテストケースまたは PR を提出してください」と簡単に言います。
3人目は非常に一般的なエラーに遭遇し、解決方法は簡単です。あなたは以前このエラーを数回見たことがありますが、解決方法がどこにあるか一時的に思い出せません。Stack Overflow？ウィキ？メーリングリスト？数分間 Google で検索した後、リンクを貼り付けてこの Issue を閉じます。
4人目は定期的な貢献者です。あなたは複数のコミュニティディスカッションと兄弟プロジェクトから彼らの名前を知っています。彼らは非常に分かりにくい Issue に陥り、それを解決するための Pull Request を提出しました。残念ながらこの Issue は複雑なので、彼らの PR には問題を説明する多くの退屈な段落が含まれています。
再び、あなたはまだ列で待っている数百人をちらっと見ます。この4人目が彼らの解決策に多くの労力を費やし、その解決策が合理的である可能性があることを知っています。Travis テストが通ったので、「LGTM」とコメントしてこの Pull Request をマージしようとします。
しかし、あなたは以前このような状況で痛い目に遭いました。過去に、十分な評価なしに PR をマージし、予見できなかった問題のために新たなトラブルを引き起こしました。たぶんテストは通りましたが、パフォーマンスが10%低下しました。あるいはメモリリークを引き起こしました。あるいは、この PR が API を過度に複雑に見せたため、新規ユーザーがプロジェクトに混乱しました。
今この PR をマージすると、この人の問題を解決するために別の人のワークフローを中断するため、後でさらに多くの問題が発生する可能性があります。だから、あなたはそれを二次的な位置に置き、より多くの時間ができてから処理します。
5人目は新しいバグを発見しましたが、実際には兄弟プロジェクトのバグであることを知っています。彼らはこれがアプリの起動を妨げていると言います。これが大きな問題であることを知っていますが、多くの問題の一つに過ぎないため、今は修正する時間がありません。
あなたは、これは実際の問題のようですが、別の Repo で開くのがより適切だと回答します。だから、彼らの Issue を閉じ、別の Repo にコピーし、コードのどこから修正を始めるかを示すコメントを追加します。ただし、彼らが実際にこれを行うかどうかは疑っています。ほとんどの人は行いません。
6人目は「今どういう状況/状態ですか？」とだけ言います。彼らが何について話しているのかわからないので、コンテキストを見ます。プロジェクトの長期にわたるバグについて、彼らは長い GitHub スレッドにコメントしました。多くの人がこの問題の現在の解決策に同意せず、多くの議論が生まれました。
この特定の Issue には20以上のコメントがあり、読んで覚えるには長い時間がかかります。だから、あなたは単に「申し訳ありませんが、この Issue はしばらく開いていますが、まだ誰も解決していません。私たちはまだ問題の範囲を理解しようとしています。Pull Request を開くのが最善です！」と回答します。
7人目は単なる GreenKeeper ウェブサイトのボットです。彼らの問題は簡単ですが、この特別な Repo にはかなり断片化されたテストがあり、そのテストは誤謬のような理由で失敗したため、通過するかどうか再テストする必要があります。テストを再起動し、Travis が実行された後にもう一度確認することを覚えようとします。
8人目は Pull Request を開きましたが、かなり活発な Repo にあり、別のメンテナーがすでにフィードバックを提供しています。スレッドをちらっと見て、他のメンテナーが適切に処理すると信じているので、既読としてマークして離れます。
9人目はバグのようですが、あなたは以前見たことがありません。しかし残念ながら、彼らは「この問題が実際にどのように発生したか」について十分な詳細を提供していません。どのブラウザで発生しましたか？どの Node バージョン？どのバージョンのプロジェクト？彼らはどのコードでそれを再現しましたか？彼らに説明を求め、このタブを閉じます。
問題が絶えず押し寄せる
すぐに、あなたは10〜20人のこのような人々を対応しました。まだ100人以上が列で待っています。しかし、この時点であなたは疲れ果てています。誰もが不満を言っているか、答えるべき質問があるか、機能強化の要求があります。
ある意味で、これらの GitHub 通知は、あなたのプロジェクトの悪い面が絶えず押し出されています。彼らがあなたの仕事に満足しているとき、誰も Issue や Pull Request を作成しません。何かが欠けていることを発見したときだけ、そうします。少しの時間をこれらの通知を読むだけでも、精神的にも感情的にも消耗します。
あなたの妻は、これらの公務を終えた後、あなたがいつもイライラしていることを観察しました。たぶん、あなたは理由もなく彼女に厳しく当たり、単に機嫌が悪いことに気づきます。彼女は「オープンソースの仕事がこんなにあなたを怒らせるなら、なぜそれをするの？」と聞きます。あなたは良い答えを見つけられません。
あなたは一時停止できます。実際、現在すでに実感しているかもしれません。過去に、精神的な健康のために GitHub から1〜2週間休暇を取ったことがあります。しかし、最終的には数百人が辛抱強く待っているため（問題を処理するために）、休暇を止めなければなりません。
過去に GitHub 通知に継続的に対応していた場合、毎日20〜30件を処理する必要があるかもしれません。逆に、あなたはそれらを積み上げたため、現在数百件が溜まっています。あなたは罪悪感を感じます。
過去に、このような理由やそのような理由で、これらの Issue を積み上げたことがあります。たぶん数ヶ月間誰も応答しなかった Issue を見たことがあります。通常、その Issue に戻ったとき、その Issue を提出した人は決して応答しません。あるいは、「あなたのプロジェクトを諦めて別のものを使いました。これで問題は解決しました」と応答します。これはあなたを悪く感じさせますが、彼らのフラストレーションを理解しています。
経験から、これらの古い Issue に対する最も実用的な対応は、単に「これらの古い Issue を閉じます。これがまだ問題である場合、またはより多くの詳細を提供できる場合は、新しい Issue を開いてください」と言うことだとわかっています。通常、誰も応答しません。時々、あるのは怒りのコメントだけで、なぜこんなに長く待たせたのかと不満を言います。
だから今、あなたは通知の受信トレイをより頻繁に処理したいと思います。数百件は多すぎます。この数字が100、数十、あるいは神話のようにゼロになることを切望しています。だから、あなたは前進します。
新しい貢献者を引き付ける
十分な数のこのような Issue を処理した後、受信トレイが最終的に空になっても、最終的には大量のバグと Pull Request が蓄積される可能性があります。ラベルは役立ちます。例えば、Issue を「再現が必要」や「テストケースあり」または「素晴らしい最初のパッチ」としてマークできます。「素晴らしい最初のパッチ」は特に役立ちます。なぜなら、新しい貢献者を引き付けることができるからです。
しかし、新しい貢献者を引き付けることができる種類の Issue は、処理が非常に簡単な種類であることが多く、この種類の Issue を新しいボランティアが文書化するのは、あなた自身が行うよりも価値があります。あなたはこの種の Issue をいくつか作成しました。なぜなら、新人をオープンソースに参加させる価値を知っているからです。この Pull Request の作者が「これはオープンソースコミュニティで私が初めて行った貢献です」と言ったとき、あなたは素晴らしいと感じます。
しかし、彼らが戻ってくる希望は薄いことを知っています。通常、これらの友人は定期的な貢献者やメンテナーにはなりません。どこかで間違えたのか、どの面を改善すれば新しい貢献者を引き留め、負担を軽減できるのか疑問に思います。
ほぼ自力で維持されているプロジェクトがあります。あなたは何年も触れていませんが、メンテナーのグループがすべての Issue と PR に応答するため、あなた自身が行う必要はありません。あなたはこれらのメンテナーに非常に感謝しています。しかし、多くの貢献者がこのプロジェクトに投資するようにしたことを知りませんが、他のプロジェクトは最終的にあなた、そしてあなただけが責任を負います。
前を向こう
新しいプロジェクトを作成したくありません。なぜなら、それがメンテナンスの負担を増やすだけだと知っているからです。実際、ここには逆効果があります。より成功すればするほど、GitHub 通知で「罰」を受けます。
ゼロから新しいプロジェクトを書き、以前は解決されなかった問題を解決する喜びをまだ思い出すことができます。しかし今、あなたはこの喜びを測り始めています。なぜなら、新しいプロジェクトは必ず古いプロジェクトから時間を奪うからです。古い Repo の1つを正式に放棄するか、Unmaintained としてマークする時期かどうかわかりません。
燃え尽きる前に、このような状況がどれくらい続くかわかりません。オープンソースの仕事を昼の仕事にすることを考えましたが、本当にオープンソースを生業とする友人と交流した後、これは通常、特定のオープンソースプロジェクトを昼の仕事にすることを意味することを知っています。これはあなたには役立ちません。なぜなら、複数の分野にまたがる数十のプロジェクトがあり、これらがすべてあなたの時間を奪い合っているからです。
あなたが最も望むのは、より多くのプロジェクトが自力で維持できることです。すべてのベストプラクティスに従おうとします。CONTRIBUTING.mdと行動指針があり、高品質の PR を提出する人に特権を熱心に譲渡します。しかし、各プロジェクトでこれを行うのも精力を消耗し、期待するほど勤勉ではありません。
また、オープンソースはしばしば特権を持つ白人男性（あなた自身のような）の専用クラブと見なされることを知っているため、罪悪感を感じます。だから、そのような問題を解決するために十分なことをしていないのではないかと心配しています。
より重要なのは、罪悪感を感じることです。罪悪感は、あなたが本来彼らの問題を解決するのを助けることができたことを知っているが、彼らの Issue を閉じる前に数ヶ月間無視したことから来ます。あるいは、誰かがあなたの Repo で最初の Pull Request を開いたが、あなたが応答する時間がなく、そのため彼らが永遠にオープンソースに参加したくなくなるかもしれないことから来ます。あなたの罪悪感は、あなたがしたことだけでなく、あなたがしなかったこと、そしてより多くの人を募集してあなたの不幸で罪悪感のある経験を共有できなかったことから来ます。
まとめる
私が言ったすべては私自身の経験に基づいています。すべてのオープンソースソフトウェア従事者を代表すると主張することはできません。これは私自身の感覚です。
私はかなり長い間（約7年間）オープンソースの仕事に従事してきました。これらの不満を不満として訴えることをずっと避けてきました。なぜなら、もっと知っているべき先輩がここで大げさに不満を言っていると理解されることを心配していたからです。結局のところ、この状況は自分で作ったのではありませんか？いつでも GitHub を離れることができます。誰とも契約していません。
また、感謝すべきではありませんか？私が従事しているオープンソースの仕事は、コミュニティでの地位を確立するのに役立ちました。会議で講演する招待を受けました。Twitter には数千人のフォロワーがおり、彼らは私の考えを聞き、私の意見を高く評価しています。マイクロソフトの仕事を得たのはオープンソースの経験のおかげだと言えます。何を不満に思うことがありますか？
しかし、私と同じ立場にいる他の多くの人がすでに燃え尽きていることを知っています。仲間たちもかつては情熱的に Pull Request をマージし、Issue を処理し、ブログを書いてプロジェクトを紹介していましたが、その後、跡形もなく消えました。そのうちの何人かについては、彼らの Repo で Issue を開くことさえためらいます。彼らが応答しないことを知っているからです。私は彼らに反対しませんが、自分が彼らのようになることを心配しています。
私は大量の自己保護措置を講じてきました。Github 通知インターフェースを使用しなくなりました。電子メールフィルターを使用して、プロジェクト（Unmaintained というカテゴリは無視できる）または通知のカテゴリ（言及されたか、私がコメントしたスレッドは通常優先権がある）に基づいて通知を分類できます。電子メールであるため、オフラインで作業し、同じ場所で事務を管理するのにも役立ちます。
私は、メンテナンスを停止してから久しいプロジェクト（例えばこのプロジェクト、私はまだ少なくとも月に1通受け取ります）でサポートを求めるメールを予期せず受け取ることがよくありますが、通常は応答しません。また、ブログ記事の下のコメントを無視し、Stack Overflow の回答やメーリングリストの下の質問に応答しないことを選択しました。また、他の人が十分にメンテナンスしていると考える Repo のフォローを積極的に解除しました。
この状況がこれほどフラストレーションを感じさせるもう一つの理由は、Issue の処理が実際のプロジェクトメンテナンスからあまりにも多くの時間を奪うことにますます気づくからです。言い換えれば、私は通常、Issue を読み、「申し訳ありませんが、今は見る時間がありません」と言うのに十分な時間しかありません。単に応答する行為が、オープンソースのために予約した時間の大部分を占めます。
Issue templates、GreenKeeper、Travis、travis_retry、Coveralls、Sauce Labs… オープンソースメンテナンスの問題を処理する技術ツールがたくさんあり、これらのツールに感謝しています。これらの自動化ツールがなければ、正気を保つことはできません。しかし、ある時点で、多くの Issue に遭遇し、その中には社会的問題が技術的問題よりも多いものがあります。一人では説明できません。私はトップ100 npm メンテナーリストに入ってさえいませんが、すでに疲れ果てています。その100人がどのような体験をしているか想像できません。
私は妻に、私たちが子供を持つつもりなら、オープンソースの仕事を諦めた方がいいと話しました。家族を育てることとオープンソースプロジェクトをメンテナンスすることを両立させる能力がないと感じ、オープンソースを諦めることが核心的な問題の解決策であると予想しています。それが、私の人生の新しい章を始めるような積極的な形で来ることを望んでいます。無礼に燃え尽きるような消極的な形ではなく。
最後の考え
ここまで読んで、オープンソースコミュニティを悩ませる問題と潜在的な解決策に興味がある場合、Nadia Eghbal の「Roads and Bridges」を研究してみるといいかもしれません。これはこの問題に対する最も明確で最も深い分析かもしれません。
私は提案も喜んで受け入れますが、オープンソースプロジェクトでお金と労働を混ぜたくないということを心に留めています（おそらくナイーブな理想主義から）。しかし、他のプロジェクトでそれが有効であるのを見たことがあります。
上記はオープンソースの消極的な面を表現していますが、私はそれが私の生活に価値ある追加であるとまだ感じており、後悔していません。しかし、この記事が皆さんに、自分自身の成功の犠牲者になることがどのような感じか、そして未完成の仕事のために重荷を感じることを理解するのに役立つことを願っています。
オープンソース参加の経験から学んだ一つのことは、より多く参加すればするほど、より多くの要求が来るということです。このような問題には、解決策がないことに気づきました。
転載请注明：デベロッパーリレーションズ »
