做爲一個開源軟件的做者是一種什麼樣的感覺？

• 原文地址：What it feels like to be an open-source maintainer
• 原文做者：Nolan Lawson
• 譯文出自：做爲一個開源軟件的做者是一種什麼樣的感覺？
• 譯者：根號三

你的門外有幾百人在排隊。他們耐心地等待着你回答他們的問題、抱怨、pull requests 和 功能請求。

你想幫助他們，可是如今你要關閉它們。或許你已經辛苦工做了一成天，或者你累了，或者你只是想和你的家人、朋友享受一個週末。

可是若是你訪問 github.com/notificatio…，它會持續地提醒你有多少人正在等着你：

screenshot showing 403 unread GitHub notifications

當你設法找到一些空閒時間後，你打開門並接待了第一我的。他們很是善意。他們嘗試使用你的項目，可是在 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… 。