這兩天，一篇名為《開源維護者的掙扎》的文章被迅速頂至Hacker News 首頁，這是Redis 作者 antirez 發布的最新博客。幾個月前，一名開源項目的維護者向antirez 發郵件，傾訴自己苦心維持項目多年，這或多或少帶來了一些心理上的負擔，因此特來尋求建議。

antirez 表示談不上給出建議，但可以寫一篇博客文章來分享對此事的看法。經過反复的思索和自我分析，他坦承“維護一個開源項目會帶來樂趣”，但“也有消極的一面”。接著，antirez 從以下幾方面對此展開描述，下邊直接採用第一人稱：

氾濫效應

當我在項目的早期收到關於Redis 的電子郵件時，仍然有足夠的時間，能夠專注於對方在消息裡試圖表達的內容，並在仔細考慮後回復自己的真實想法。

然而，當一個項目達到像Redis 這樣的流行程度，並且人與人之間的交流因為新的社交工具而變得更為容易時，作者收到的消息、issue、PR 和建議的數量也將呈指數增長。隨之出現一個普遍性問題，至少從Rsdis 的情況來看是這樣，即沒有足夠多合格的人去查看並處理社區中的這些信息。

大多數人試圖以錯誤的方式解決它：原帖發布兩週後若無回复就關閉issue、關閉所有不明確的issue，以及其他類似直接把郵件列表全部標記為已讀的做法。

事實上，處理社區反饋必須要花費足夠的時間，否則只能“假裝”項目沒有未解決的問題。為開源項目的每個子系統配備全職工作人員是奏效的，但很難實現。

那麼接下來會發生什麼？你將開始考慮哪些該被優先處理而哪些不是，你將因為自己忽略了太多事物和人而感到不安，貢獻者也會認為你是一個漠不關心的人。這種情形實在是很複雜。

通常來說，應該主要先解決關鍵問題，忽視所有新的東西，因為新的東西還未能進入核心，誰想擁有一個伴隨著更多PR 和issue 的代碼庫呢？

角色轉換

Redis 流行起來後，我的工作更多地轉變為了查看PR 和issue。這其中確實有些人會比我做得好，但大多數人的貢獻僅處於平均水平，只是解決給定問題罷了。

當我設計 Redis 時，我傾向於將它視為一個整體，畢竟這麼多年來一直在寫這個東西。所以現實是，擅長的東西往往不再有時間去做。

我的解決方法是，給自己幾週時間停止查看PR 和issue，轉而去編程或者設計，這才是我真正喜愛和享受的。但這反過來又給我帶來了更大的心理壓力，只在做自己喜歡的事情時做得很好，令人感覺很糟糕。

時間

長時間在一個項目上工作有兩個問題，至少對我而言是這樣。

第一個問題是，在 Redis 之前，我從未有過在每個工作日都工作的經驗。我總是乾一周，停兩週，接著再乾一個月，然後消失兩個月。做創造性工作需要充電，以獲得新的能量和想法。

但開始收到在 Redis 工作的報酬後，道德規範我不能再依照過去的模式，所以我強迫自己按照正常的時間表工作。這對我來說無比掙扎，而且我確信自己做得比實際能做到的要少。目前仍未找到解決方法，跟公司申請回到原先的工作模式是不管用的，因為社區的運作方式如此。

另一個問題是，從精神上講，在同一個項目中進行大量工作也是一件複雜的事情。我過去常常每六個月換一次項目，而如今十年來都在做同一個項目。我試圖通過在Redis 中部署子項目來留存創造力，先後做了 Cluster、HyerLogLogs 和一個已放棄的磁盤存儲項目，現在在做第四個。

不過，最終還是要回到issue 和PR 頁面，每天重複同樣的工作。

恐懼

我每天都在害怕自己失去對Redis 的技術領導力，不是因為我認為自己在設計和發展Redis 方面做得不夠好，而是因為我的方式與大多數用戶想要的，以及大多數IT 人員對軟件的信仰不一致。

因此，我不得不在我認為的優秀設計、功能集、開發速度、項目規模，以及大多數用戶所期望的內容之間保持平衡。

幸運的是，有一定比例的Redis 用戶完全理解Redis 的方式，所以我至少時不時會得到一些安慰。

摩擦

儘管我認為程序員中的好人佔比多過其他領域，但總還是有一些混賬。作為一個受歡迎的開源項目的領導者，將不得不面對這些人，這可能是我在Redis 開發過程中遇到的最緊張的事情之一。

徒勞

我相信軟件雖然很棒，但不會像一本存活了幾個世紀的書一樣偉大，這絕不是因為它本身不好，而是因為其中的副作用，並且，它終將被更有用的軟件替換掉。因此有時我會覺得自己做的一切終將都是徒勞的。

只停留在軟件編寫本身，而不思考軟件“大創意”的人，真的能創造新的標誌嗎？

總的來說，我能夠從事自己真正熱愛的事情多年，並且它給我帶來了朋友、認可和金錢，所以這算不上是糟糕的交易。

然而，我完全理解，一旦項目開始流行，人們就會為了維持生計而掙扎。這篇文章專門寫給你們。