幾百個人排成一個隊伍，候在你家門外。他們耐心等待你去解答問題、聽他們的抱怨、回復 Pull Request 和 Feature Request 。

你想去幫他們所有人，但你一直拖到現在。也許你辛苦工作了一整天，或者你累了，再或者你只是想跟家人和朋友享受周末。

但你如果登陸 github.com/notifications，Notification 會不斷提醒有多少人在等著你：

當你設法找到一些空閑時間，你開門迎接第一個人（即處理第一個問題，其中可能包含不止一個人，下同）。他們足夠善意；他們想使用你的項目，但在 API 上陷入一些困惑。他們把代碼粘貼到 GitHub 評論上，但是忘記了或者不知道怎么格式化代碼，結果代碼一團糟。

還好，你編輯了他們的評論以添加代碼塊，把代碼格式化了。但仍有許多代碼需要讀。

另外，他們對問題的描述有些讓人難以理解。也許英語不是他們的母語，或者他們在書面表達上能力不足。不管怎樣，你努力去理解他們提交的文本段落。

你疲倦地看了一眼，排在隊伍后面等待的另外幾百個人。你可以花半個小時去理解這第一個人的代碼，或者你可以只是瀏覽一遍然后給出一些教程或者文檔的鏈接，說不定可以幫助他們解決問題。你還愉快地建議他們嘗試 Stack Overflow 或者 Slack 。

第二個人皺著眉頭，臉上露出不悅的神情。他們不斷抱怨你的項目如何浪費了他們生命中的兩小時，因為某個 API 沒有宣傳中的效果。他說的話很刻薄，讓你很不舒服。

你沒有在這個人身上浪費太多時間。你簡單地說道，“這是一個開源項目，且由志愿者維護。如果代碼中有 Bug，請提交一個可復現的測試案例或者 PR 。”

第三個人遇到的是一個很常見的錯誤，解決方法很簡單。你之前看到過幾次這個錯誤，但是一時想不起解決方法在哪。Stack Overflow？維基？郵件列表？在谷歌搜索了幾分鐘后，你粘貼上了一個鏈接然后關閉了這個 Issue 。

第四個人是一個定期的貢獻者。你從多個社區討論會和兄弟項目（ sibling project ）中識出了他們的名字。他們陷在一個十分晦澀的 Issue ，并提交了一個 Pull Request 來解決它。很不幸這個 Issue 很復雜，所以他們的 PR 中包含許多枯燥的段落，來解釋問題。

再一次地，你瞥了一眼還在排隊等待的幾百號人，你知道這第四個人在他們的解決方案上花了很多工夫，并且可能這個解決方案是合理的。Travis 測試通過，所以你打算只評論句“LGTM”，然后合并掉這個 Pull Request 。

然而，你之前被這類情況傷過。在過去，你合并了一個 PR 但沒有經過充分的評價，最終因為一些你沒有預見到的問題，它導致了新的麻煩。也許是測試通過了，但性能下降了 10% 。或者它引發了一個內存泄漏。或者可能這個 PR 讓新用戶對項目感到困惑，因為它使得 API 看起來過于復雜。

如果現在你合并了這個 PR，以后可能會有更多的問題，因為你為解決這個人的問題而打斷了另一個人的工作流程。所以你把它放在次要位置，等有了更多時間再去處理它。

第五個人發現了一個新 Bug，但你知道實際上它是兄弟項目中的一個 Bug 。他們說這阻礙了他們啟動 App 。你知道這是個大問題，但只是眾多問題中的一個，所以你此刻沒有時間去修復它。

你回應道，這看起來是一個真實的問題，但是它更適合在另一個 Repo 中打開。所以你關閉了他們的 Issue，把它復制到了另一個 Repo，然后你添加一個評論提示，在代碼中從哪里開始修復它。盡管你懷疑他們實際上會這個做。很少人會。

第六個人只說道“現在是什么情況/狀態？”你不知道他們在談論什么，所以你看一下上下文。關于項目中的一個長期存在的 Bug，他們在冗長的 GitHub 線程上進行了評論。許多人不同意這個問題目前的解決方案，所以產生了許多討論。

在這個特定 Issue 下有超過 20 條評論，要讀完并記住，需要花費你很長的時間。所以你僅僅回應道，“對不起，這個 Issue 開放了一段時間了，但還沒有人解決它。我們仍試著去理解問題的范圍，最好是開一個 Pull Request ！”

第七個人只是個 GreenKeeper 網站機器人。他們的問題很簡單，除了這個特殊的 Repo 中有相當碎片化的測試，且這個測試由于看起來像是謬誤的原因失敗了，所以你不得不重新測試看是否通過。你重啟了這個測試，并試圖讓自己記住在 Travis 有機會運行后再去觀察一下。

第八個人開了一個 Pull Request，但所在的 Repo 相當活躍，另一個維護者已經做出反饋。你看了一眼線程，你相信其他維護者會處理好，所以你標記它為已讀，然后走開繼續。

第九個人遇到的似乎是個 Bug，而你之前也沒見過。但不幸的是，他們對“這個問題實際是如何發生的”沒有提供足夠的細節。是什么瀏覽器下出現的？哪個 Node 版本？哪個版本的項目？他們用什么代碼來復現它？你讓他們做出澄清，然后關掉這個標簽。

問題不斷涌進

不一會兒，你接待了 10 到 20 個這樣的人。仍有 100 多個在排隊等待。但此刻你感到精疲力盡；每個人不是抱怨，就是有問題要解答或者是有增強的請求。

在某種程度上，這些 GitHub 通知就是不斷涌出你項目中差的一面。當他們滿意你的工作時，就不會有人建立一個 Issue 或 Pull Request。只有當他們發現有所缺失，才會如此。即使你只花了一點時間閱讀這些通知，在精神和情感上都是消耗。

你妻子觀察到在例行完這些公事之后你總是暴躁易怒。也許你發現自己總是沒緣由地對她厲聲呵斥，僅僅是心情不好。她問你：“如果開源工作這么讓你憤怒，為什么你還要做它？”你找不到一個好的答案。

你可以暫停；事實上目前你可能已經有所體會了。在過去，你曾從 GitHub 休假過一兩個星期，只為了精神健康。但最后因為有幾百個人在耐心等待（你去處理問題），不得不停止休假。

如果你過去持續跟進 GitHub 通知，你可能每天要處理 20-30 條。相反，你讓它們堆積，所以現在攢了幾百條。你感到內疚。

在過去，由于這樣或那樣的原因，你確實讓這些 Issue 堆積。你或許看到一條數個月都沒人應答的 Issue 。通常，當你返回找到那個Issue，提出這個 Issue 的人從不回應。或者他們這么回應，“我們放棄了你的項目而用了另一個，這樣我的問題就解決了。” 這讓你感覺很糟，但你明白他們的挫敗感。

你從經驗中得知，對于這些陳舊的 Issue，最實用的回應往往是只說句，“我要關閉這些舊的 Issue，如果這對你仍是個問題，或者你能提供更多的細節，請重新開一個 Issue 。”通常沒有人回應。有時候有，也僅是一個憤怒的評論，抱怨怎么讓他們等這么久。

所以現在你想更勤快地處理你的通知收件箱。幾百條太多。你渴望這個數字縮減到一百，幾十，或者甚至是神話般地清空。所以你奮力前行。

吸引新的貢獻者

在處理完足夠多這樣的 Issue 后，即使你的收件箱最終被清空，最后可能仍會積壓大量的 Bug 和 Pull Request 。標簽可以起到作用——例如，你可以把 Issue 標記為“需要復現”或“有測試用例”或者“很贊的首個補丁”。“很贊的首個補丁”尤其有幫助，因為他們常常可以吸引到新的貢獻者。

然而，你發送能吸引到新貢獻者的那一類 Issue ，往往是處理起來非常簡單的那一類，這一類 Issue 由新的志愿者去記錄，比你親自去做更有價值。你創建了一些這類的 Issue，因為你知道它的價值所在，讓新人參與到開源，當這條 Pull Request 的作者告訴你“這是我在開源社區做的第一個貢獻。” 你感覺很棒。

但你知道他們回來的希望很渺茫；通常這些朋友不會成為定期貢獻者或維護者。你懷疑是不是你哪里做錯了，你在哪方面改進，才能吸引住新的貢獻者來幫你減輕負擔。

你有一個項目幾乎就是靠自身維持的。你多年沒碰了，但有一幫維護者會回應每一個 Issue 和 PR ，所以你不必親自去。你非常感激這些維護者。但你不知道你做了什么才使得這么多貢獻者投入這個項目，而其他項目最后都是你，且只有你自己負責。

向前看吧

你不愿去創建新項目，因為你知道它只會增加你的維護負擔。事實上，這里有一種反效應，你做得越成功，在 GitHub 通知上得到的“懲罰”就越多。

你仍能回想起這種創建的快感，從零開始寫一個新項目以及解決一個之前未解決問題的喜悅。但是現在你開始衡量這種喜悅，因為任何新項目必定會從舊項目中奪走時間。你不知道是否是時候該正式摒棄你的一個舊 Repo，或者把它標記為 Unmaintained。

你不知道在你倦怠之前，這樣的情況還要持續多久。你曾考慮將開源工作作為你的白天工作，但是自從你和真正從事開源為生的朋友交流后，你知道這通常意味著，讓一個特定的開源項目作為你的白天工作。這對你無益，因為你有幾十個跨越多個領域的項目，這些都在爭奪你的時間。

你最想要的是更多的項目可以自身獨立維持，你嘗試去遵守所有的最佳實踐：你有 CONTRIBUTING.md 和行為指導，你熱情地交出擁有的特權，給任何提交高質量 PR 的人。然而每個項目都這么做，也很耗費精力，所有你沒有你期望的那樣勤奮。

你也為此感到內疚，因為你知道開源常常被看做是有特權的白人男性（比如你自己）的專屬俱樂部。所以你擔心你做的還不夠，去解決那樣的問題。

更重要的是，你感到內疚：內疚來自于你知道你本可以幫助有些人解決他們的問題，但你讓他們的 Issue 在關閉前被無視了好幾個月，或者有人在你的 Repo 開了他們第一條 Pull Request，但你沒有時間去回應，這可能因此讓他們沮喪到永遠不想再參與開源。你的內疚是因為你已做的事情，也是因為你沒做過的事情，以及因為你沒能招募到更多的人分享你的不幸而有負罪感的經歷。

集中到一起

以上我說的一切都是基于我自己的經驗。我不能聲稱自己代表所有開源軟件工作者，這是我自己的感覺。

我從事開源工作已經有很長一段時間了（大約 7 年），我一直不愿去抱怨任何這些牢騷，因為我擔心會被理解為是本應了解更多的前輩在這里夸張地發牢騷。畢竟，這種處境不是我自己造成的嗎？我可以隨時離開 GitHub；我沒有跟任何人簽合約。

還有，我不該感激嗎？我從事的開源工作幫助我在社區樹立了地位。我獲得了在會議做演講的邀請。在 Twitter 上我有幾千號粉絲，他們傾聽我的想法，并對我的意見給予很高的評價。可以說，我得到微軟的工作是因為我的開源經歷。我還有什么可抱怨的？

然而，我知道許多其他處在與我同樣位置的人都已倦怠。伙伴們也都曾熱情地合并 Pull Request ，處理 Issue，寫博客展示他們的項目，之后就消失得無影無蹤。對于其中有些人，我甚至不愿在他們的 Repo 中開 Issue 。因為我知道他們不會回應，我不反對他們，但我擔心自己會變成他們一樣。

我已經采取了大量的自我保護措施。我不再使用 Github 通知接口——我使用電子郵件過濾器，這樣我可以基于項（Unmaintained 這一類可以忽略）或者通知的類別（提到過的或者我評論過的線程通常會有優先權）來分類通知。因為是電子郵件，這也有助于我離線工作和在同一處管理事務。

我常常會出乎意料地收到在項目上請求支持的郵件，而這個項目我停止維護已經很久了（例如這個項目，我仍至少每月會收到一封），而通常我都是不回應。我還選擇忽視我博文下的評論，不回應 Stack Overflow 的回答和郵件列表下的問題。我還積極地取消關注了那些我認為其他人維護得足夠好的 Repo 。

這種情況如此令人沮喪的另一個原因是，你越來越發現處理 Issue 從項目實際維護中奪去太多時間，換句話說，我通常只有足夠讀取Issue，然后說“對不起，我此刻沒有時間看”的時間。僅僅是回應的行為，就會占據我為開源預留的大部分時間。

Issue templates、GreenKeeper、Travis、travis_retry、Coveralls、Sauce Labs… 有太多技術工具可以處理開源維護問題，我很感激有這些工具。如果沒有這些自動化工具，我就不可能保持頭腦清醒。但在某些時候，你會遇到很多 Issue，它們里面涉及的社會性問題比技術性問題更多。一個人不足以說明。我甚至沒有進到前100位 npm 維護者榜單，我就已經累覺不愛了；我無法想象那 100 個人是什么體會。

我已經告訴我妻子，如果當我們打算開始要孩子，我還是放棄開源工作為好，我覺得自己沒有能力兼顧撫養家庭和維護開源項目，我預料到，放棄開源才是我核心問題的解決方案。我只希望它會以一種積極的形式到來，就如開始我人生新的篇章，而不是以一種消極的形式，比如毫不客氣地倦怠。

最后的一點思考

如果讀到這里，你對困擾開源社區的問題和潛在的解決方案感興趣，你可能會想研究下 Nadia Eghbal 的《Roads and Bridges》。它可能是對該問題最清晰最深入的分析。

我也樂于接受建議，盡管我在心中牢記我不愿在開源項目中把金錢和勞動混在一起（也許是出于天真的理想主義）。但我曾在其他項目中看到它是有效的。

請注意，盡管上文表達了開源消極的一面，但我仍覺得它是我生活里一個有價值的補充，我沒有任何后悔。但我希望這篇文章對大家有幫助，讓你們看到成為自身成功的犧牲者是什么感受，以及你會因為未完成的工作而感到沉重。

我從參與開源的經歷中學到的一點就是：你參與越多，對你的要求就越多。我意識到這樣的問題，并沒有解決方法。