你的門外有幾百人在排隊。他們耐心地等待著你回答他們的問題、抱怨、pull requests 和 功能請求。
你想幫助他們，但是現在你要關閉它們。或許你已經辛苦工作了一整天，或者你累了，或者你只是想和你的家人、朋友享受一個週末。
但是如果你訪問 github.com/notificatio…，它會持續地提醒你有多少人正在等著你：
當你設法找到一些空閒時間後，你開啟門並接待了第一個人。他們非常善意。他們嘗試使用你的專案，但是在 API 上遇到了一些困惑。他們將自己的程式碼貼上到了 GitHub 評論區中，但是他們忘記或不知道怎樣格式化它，所以他們的程式碼非常混亂，難以閱讀。
你熱心地將他們的程式碼放到一個程式碼塊中，因此它們有一個很友好的格式。但是你仍然需要閱讀很多程式碼。
並且他們對於問題的描述也很難理解。或許這個人不以英文為母語，或者他們有殘疾使得他們很難通過寫作進行溝通。你不確定。總之，你很難理解他們釋出的這一段話。
你很疲勞。你看了看排在他後面的數百個其他人。你可以花費半個小時來理解這個人的程式碼，或者你可以選擇跳過他，只是給他一些教程和文件的連結，這些有助於幫助解決他們的問題。你也可以善意的建議他們嘗試 Stack Overflow 或 Slack channel instead。
隊伍裡的下一個人臉上皺起了眉頭。他們抱怨你的專案浪費了他們兩個小時，因為某個明確的 API 並沒有像宣傳的那樣如期工作。他們刻薄的言辭讓你感覺很不舒服。
你不想在這個人上浪費太多的時間。你簡單地回覆了：“這是一個開源專案，並由志願者志願維護”。如果程式碼中有一些 bug，請提交一個可復現的測試程式碼或者一個 PR。
接下來的一個人遇到了一個非常普遍的錯誤，但是有一個很容易的解決方案。你知道你之前見過這個錯誤，但是就是想不起來解決方法寫在了哪裡了。Stack Overflow? wiki? 郵件？Google 了幾分鐘以後，你貼上了一個連結並關閉了這個問題。
下一個人是一個長期貢獻者。你從各種社群論壇和兄弟專案中認出他們的名字。他們遇到了一個非常深奧的問題，並且提出了一個 pull request 來解決它。不幸地是，這個問題太複雜了，以至於他們的 PR 包含了好幾段文字來解釋它。
你的眼睛再一次瞥了外面仍然在排隊的幾百人。你知道這個人在他們的解決方案上做了大量的工作。並且這可能是一個合理的方案。Travis 的測試已經通過了。所以你想回復一個 "LGTM" (譯者注：Looks Good To Me.) 然後合併它。
然而，在之前你曾吃過這樣的虧。你曾經合併過一個 PR 但是並沒有完整的評估它。最後它讓你很頭痛因為你沒有預料到它帶來的問題。或許通過了測試，但是效能下降了十分之一。或者造成了記憶體洩漏。又或者因為導致了這個專案的 API 過於複雜以至於對新使用者來說容易困惑。
如果你現在合併了這個 PR，明天你可能會遇到更多的問題，因為你通過解決了這個人的（非常邊緣的）問題打破了別人的工作流。因此你決定先將它滯後，稍後當你有更多時間時你會再處理它。
下一個人發現了一個新 bug，但是你知道它實際上是一個兄弟專案中的 bug。他們說這個問題阻止他們執行應用。你知道這是一個大問題，但是隻是許多問題中的一個。你現在沒有時間來馬上修復它。
你回覆到看起來這真的是一個問題，但是在另一個 repo 裡報告這個問題更合適。因此你關閉了這個問題，並把它複製到另一個 repo 裡面。然後新增一個評論建議應該從程式碼中的哪個地方開始修復它。雖然你懷疑他們是否會這樣做。（很少啦）。
接下來的一個人只是說了一句“這是什麼狀態？”。你不確定他們到底在討論什麼，因此你檢視上下文。他們關於一個專案中的長期 bug 的評論導致 GitHub 評論板很冗長。許多人不同意這個問題原本的解決方案，所以它產生了很多討論。
在這個問題上有 20 多條評論，你需要花費很長的時間才能閱讀並理解所有的內容。所以你只是回覆了一句：“對不起，這個問題已經開啟了有一段時間了，但是到現在還沒有人解決它。我們仍在試著理解問題的範圍。一個 pull request 或許是一個好的開始。”
下一個人僅僅是一個 GreenKeeper bot。這個處理起來很輕鬆。除了這個特定的倉庫有著相當脆弱的測試，並且因為一個看起來並不真實的原因而測試失敗了，因此你為了能夠通過測試必須重新啟動它。你重啟了測試並嘗試提醒自己在稍後 Travis 能執行它時檢查一下。
接下來的那個人開啟了一個 pull request，但是是在一個相當活躍的倉庫上，因此另一個維護者已經提出了反饋。你瞥了一眼大致過程，你相信這個維護者能夠處理這個問題。因此你將它標記為已讀並繼續下一步。
下一個人在執行時出現了一個你之前從未見過的大問題。但不幸的是他們沒有提供一丁點關於問題實際發生時的細節。用了什麼瀏覽器？Node 的哪一個版本？專案的哪一個版本？使用哪些程式碼能重現它？你要求他們重新提供一些細節並關閉了這個頁面。
The constant stream
過了一段時間後，你已經處理了一二十個這樣的情況。但是仍然還有幾百個人在等待著。但是現在你已經感到精疲力盡了。每一個人都有他自己的抱怨、問題、或者是新需求。
從某種意義上來說，這些 GitHub 通知就是一個關於你的專案的的不間斷消極流。沒有人會因為對你的所作所為感到滿意時開啟一個 issue 或者是 pull request。他們只會在發現缺少一些東西時才這樣做。儘管你只花費很少的時間來閱讀他們的這些通知，但是仍然能讓你在精神上和情緒上感到疲憊不堪。
你的伴侶觀察到你在做完這些事情之後總是脾氣很壞。或許你發現自己在毫無原因的嘲笑她，僅僅是因為你的心情很糟糕。“如果從事開源工作會讓你如此生氣，為什麼你還要做呢？”她問道。你也沒有一個很好的答案。
你可以休息一下。事實上你可以已經嘗試過了。之前有一次，你遠離 GitHub 給自己放了一兩週的假期，僅僅是為了自己的心理健康。但是你知道你結束這種情況的原因是因為有數以百計的人們在耐心地等著你。
如果你保持關注並處理你的 GitHub 通知。或許每天只有 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 答案的回覆和郵件裡的問題。我基本上也不再關注那些我覺得別的維護者已經做得很好的 repo。
這種情況如此令人沮喪的原因之一是，我越來越覺得處理問題遠比實際維護一個專案要花費時間。換句話說，我經常只有時間閱讀一個問題然後說：“對不起，我現在沒時間看這個。”僅僅是這樣的回覆就已經佔用了我原本為開源預留的大部分時間。
Issue templates, GreenKeeper, Travis, travis_retry, Coveralls, Sauce Labs… 針對開源維護的問題，有這麼多的技術解決方案。我非常感激它們。如果沒有這麼多自動化工具，我將不能保持專注。但在某些時候，相比技術問題，你遇到的更多的是社交問題。一個人成不了規模。我甚至不在 前 100 個 npm 貢獻者 之列，就已經感覺到了壓力。簡直不敢想象那一百個人的感覺是什麼樣的。
我已經告訴我的伴侶，當我們決定開始擁有一個孩子時，可能我還是退出開源比較好。我不知道我怎樣才能在撐起一個家庭和從事開源之間平衡時間。我預計最終這個將解決我的問題：核選擇。我只是希望它能以一個積極的形式到來，像是開啟了我的生活新篇章一樣，而不是一個消極的形式。
結尾詞
如果你已經閱讀到這裡，並且對開源社群的問題和潛在的解決方案感興趣，或許你會想看看 Nadia Eghbal 寫的 “Roads and Bridges”，這可能是對問題最清晰和最徹底的分析。
我也樂於接受建議，但是請記住，我非常不願意在我的開源專案中將錢和勞動成果混在一起（由於傻傻的理想主義的原因）。但是我曾在 其他專案 中看到它處理的很好。
注意，儘管上邊這些都是消極的，但是我仍然感覺開源已經成為了對我的生活很有價值的補充。但我希望這是一個有用的視窗，它可以感受到如何成為你自己的成功的受害者，並且沒有完成就放下工作而感到壓力。
如果說我在開源中學到了一件事，那就是：你做的工作越多，你就越需要工作。我知道這個問題無解。
本文根據 Nolan Lawson 的《What it feels like to be an open-source maintainer》所譯，整個譯文帶有自己的理解與思想，如果譯得不好或有不對之處還請同行朋友指點。如需轉載此譯文，需註明英文出處：nolanlawson.com/2017/03/05/…
檢視更多文章，請保持關注：github.com/sqrthree/sq… 。