你的門外有幾百号人在排隊。他們在耐心地等待着你回答他們的問題、抱怨、pull requests 和功能請求。
你很想幫助他們，但是現在你決定把門關緊。或許是因為已經辛苦工作了一整天，你累了，又或許你隻是想和你的家人、朋友好好享受一個周末。
但如果你去通路 github.com/notifications，它會一直不斷地提醒你有多少人正在等着你：
好不容易找到一些空閑時間，你打開門并接待了第一個人。他很友善，正嘗試使用你的項目，但是在 api 上遇到了一些困惑。他把自己的代碼粘貼到了評論區中，但是卻忘記或根本不知道怎麼格式化，是以送出過來的代碼非常混亂，難以閱讀。你熱心地将這些代碼進行格式化處理，但即便如此，你仍然需要閱讀很多代碼。而且可能是因為語言或溝通上的問題，他對問題的描述很難了解。
你看了看排在後面的數百個人，糾結是該花半小時來了解這個人的代碼，還是跳過他，隻是給他一些有助于解決問題的教程和文檔連結。
這時，隊伍裡的下一個人開始不耐煩了，抱怨你的項目浪費了他兩個小時，因為某個明确的 api 并沒有像之前說的的那樣如期工作。尖酸刻薄的言辭會讓你感覺很不舒服。是以，你不想在這個人上浪費太多的時間。你簡單地回複一句：“這是一個開源項目，由志願者維護。如果代碼有 bug，請送出可重制的測試代碼或送出 pr ”。
接下來的一個人遇到了一個非常常見的錯誤，你記得之前有處理過類似的錯誤，但是突然想不起來解決方法寫在哪了。到處翻找了一遍後，你粘貼了一個連結并送客。
下一位是一名長期貢獻者，你記得他的名字。他遇到了一個非常深奧的問題，并且提出了一個 pull 請求修複。不幸地是，問題很複雜，他的 pr 中包含好幾段解釋文字。想想外面的長隊，你覺得這個人在解決方案上已經做了大量的工作，并且這可能是一個合理的方案，已經通過 travis 測試。是以想回複一個 “lgtm” ，然後合并它。但是，你又想起之前有吃過類似的虧。合并過一個 pr 但沒有完整的評估它，以緻于後面出現問題讓你非常頭疼。如果你現在合并這個 pr，明天也可能會遇到更多的問題，是以決定先将它滞後，等有更多時間時再去處理它。
下一個人報告了一個阻止他們運作應用的新 bug，但你知道它實際上是兄弟項目中的一個 bug。問題很重要，但你現在沒有時間馬上去修複。是以你回複到：這确實是個問題，但在另一個 repo 裡報告會更合适。然後你關閉這個問題，并把它複制到另一個 repo 裡面，并附上一段關于修複該問題的解決方法的評論。
再下一個人隻是說了一句“這是什麼狀态？”。你不确定他到底在讨論什麼，是以要去檢視上下文。結果發現是一個長期的 bug ，許多人不同意原本的解決方案，是以在進行争議。你需要花很長的時間看完所有的評論去理順他們讨論的事情。是以你隻好回複一句：“對不起，這個問題已經有一段時間了，但是目前還沒有人解決它。如果有好的想法，一個 pull request 或許是一個好的開始。”
下一個人在運作時遇到了一個之前從未見過的大問題，但不幸的是他沒有提供一丁點關于問題實際發生時的細節。項目用的哪個版本？哪個浏覽器？要怎麼重制？你隻能要求他重新提供一些細節并關閉了這個頁面。
……
流水線
一段時間後，你已經接待了一二十個這樣的人，但仍然還有幾百個人在外面等着。每一個人都有他自己的問題和述求，這很容易讓人感到精疲力盡。
從某種意義上來說，這些通知就是一個關于你的項目的不間斷的消極流。沒有人會因為對你的行為感到滿意時打開一個 issue 或者是 pull request，他們隻會在發現缺少某些東西時才會這樣做。盡管你可能隻用花費很少的時間來閱讀這些資訊，但是仍然能讓你在精神上和情緒上感到疲憊。
家人觀察到你在做完這些事情之後總是脾氣很壞，會問你“如果從事開源工作會讓你這麼生氣，為什麼你還要做呢？”。你想了想，沒有一個很好的答案。
為了自己的身心健康，你嘗試去休息，給自己放一兩周的假。但是你會不時想到有數以百計的人在耐心地等着你。而且每天處理 20-30 消息，總比堆積上百個在那裡要強得多。而且當你回過頭處理這些堆積的問題時，他們可能已經不再關注你或者轉移到另外一個項目了。你很失望，但你也了解他們對你的失望。是以，你決定繼續回答問題，于是，一切又像開頭那樣重新開始。
招募新的貢獻者
像上面這樣處理過很多問題之後，即使你最終清空了收件箱，仍然會發現積壓了大量的 bug 和 pull request。這時，标簽可以幫到你 —— 例如，将問題标記為“需要重制”、“存在測試用例”或者 “good first patch”。“good first patch” 這條尤其有用，因為常常能吸引到新的貢獻者。
等一段時間你會發現，通常吸引新貢獻者解決的那些問題都是非常容易的問題。針對那些問題，記錄下來并且解釋如何修複它比你自己修複它還要重要。你甚至可以特意去建立一些這樣的問題，因為讓新人參與到你的開源項目中是值得的，當 pull request 的送出者告訴你“這是我第一次向開源項目做出貢獻”時，你會覺得很開心。
但通常這些人不會成為長期貢獻者或維護者，你會懷疑自己是不是做錯了，是不是能想點辦法做一些力所能及的，但卻可以吸引新貢獻者并且可以長期減輕負擔的事情。如果你之前有過一個自我維持的項目，一直有一個維護小組在幫你回複每一個問題和 pr，在極其感激這些維護者的同時，會去反思是因為做了什麼事情才有如此多的維護者參與這個項目中，而其他的項目卻隻能獨自負責。
展望未來
想到維護的負擔，你不太願意再去建立新項目了。這是一個對立的現象：你的項目越成功，你從 github 的通知那裡得到的“懲罰”就越多。
你偶爾會回憶起創作的激情，從頭開始寫一個新項目，解決之前未解決的問題時的那種喜悅。但是現在你不喜歡這種喜悅，因為任何新項目都會從舊項目中竊取你的時間。你會思考，是不是已經到了正式放棄一些舊項目或者标記它們為不再維護的時候了。
你最想要的是有更多的項目可以自我維護。你嘗試按照最佳實踐：一個 contributing.md 和一個行為準則，并熱情地向所有送出高品質 pr 的人發出邀請，給予所有者權限。
為每一個項目都做這些事情是非常辛苦的，是以，你并沒有對自己想象中的那樣勤奮，但同時又因為沒有付出足夠的努力來修複問題而焦慮。你想到自己明明可以幫助某人解決他們的問題但是反而讓他們的問題放在那爛了幾個月然後關閉它而内疚，或者明明看到某個人在倉庫發起了他們的第一個 pull request 但是沒有時間去回複而内疚，是以這可能導緻他們對開源感到失望。你因自己的所作所為感到内疚，因沒能做到的事情感到内疚，并且不想招募更多的人來分擔你的内疚。
putting it all together
上面所說的都是基于我自己的經驗，這不代表了所有從事開源軟體事業的人，但是這的确是我個人的感受。
我已經從事開源很長一段時間了（大概 7 年），我一直不願意去對外抱怨這些事情，因為我擔心這會被了解為無意義的發牢騷。畢竟，這種情況不是我自己導緻的麼？隻要願意我可以随時離開 github，我沒有義務對任何人負責。
還有人會覺得，我不應該感激嗎？我在開源方面的工作讓我獲得了名聲，被邀請在一些會議上演講，在推特有成千上萬的粉絲在聽我說的話并且高度尊重我的意見。可以說我之是以得到了微軟的工作也是因為我在開源方面的經曆。我該抱怨誰？
我知道已經有很多跟我類似的人選擇了放棄，那些曾經積極合并 pull request、修複問題的人消失的無影無蹤。對于其中一些人，我甚至都不會在他們的 repo 上打開 issue，因為我知道他們不會回複。我不會抱怨這些事情，但是我擔心我也會走他們的老路。
我現在已經采取了很多自我保護措施。我不再使用 github 的通知界面，使用郵件進行過濾。是以我可以基于項目或通知類型進行分類。而且使用郵件，也有助于我離線工作，并且在一個地方處理掉所有的事情。
我經常會收到藍色級别的郵件讓我去支援一個我已經停止維護的項目，通常情況下我不會回複他們。還傾向于忽略部落格文章裡面的評論、stack overflow 答案的回複和郵件裡的問題。造成這種情況的原因之一是，我越來越覺得處理問題遠比實際維護一個項目要費時間。換句話說，我經常隻有時間閱讀一個問題然後說：“對不起，我現在沒時間看這個”，僅僅是這樣的回複就已經占用了我原本為開源預留的大部分時間。
issue templates、greenkeeper、travis、travis_retry、coveralls、 sauce labs… 有這麼多針對開源的技術解決方案。我非常感激它們，因為如果沒有這麼多自動化工具，我将無法保持專注。但在某些時候，相比技術問題，你遇到的更多的是社交問題。一個人成不了規模。我甚至不在 前 100 個 npm 貢獻者 之列，就已經感覺到了如此壓力。簡直不敢想象那一百個人會是什麼感覺。
我已經告訴我的妻子，當我們決定開始擁有一個孩子時，可能還是退出開源比較好。我不知道怎樣才能平衡撐起一個家庭和從事開源之間的時間。我希望徹底“核毀滅”能帶來一種積極的生活方式，開啟生活新篇章。
結尾詞
如果你已經閱讀到這裡，并且對開源社群的問題和潛在的解決方案感興趣，或許你會想看看 nadia eghbal 寫的 “roads and bridges”，這可能是對問題最清晰和最徹底的分析。
我樂于接受建議，但是請記住，我非常不願意在我的開源項目中将錢和勞動成果混在一起（由于傻傻的理想主義的原因）。雖然，我曾在其他項目中看到二者很好的進行結合。
最後請注意，盡管上邊都是一些消極的話，但是我仍然感覺開源是對我的生活很有價值的補充。我希望能通過這篇文章讓你有所收獲，為自己沒有完成的工作而感到壓力。
如果說我在開源中學到了一件事，那就是：你做的工作越多，你就越需要工作。而且我知道，這個問題無解。