Redis作者antirez：開源維護者的掙扎

這兩天，一篇名為《開源維護者的掙扎》的文章被迅速頂至 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 開發過程中遇到的最緊張的事情之一。

徒勞

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

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

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

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