幾個月前，一位在系統軟體領域、擁有相當龐大且活躍社群的開源專案維護者寫信給我，說他經過這麼多年後，很難再繼續維護自己的專案，因為這樣的付出在心理上極為耗損。他想向我尋求建議，我也不確定自己是否有資格給建議，不過我告訴他，我會寫一篇部落格文章來談談我對這件事的看法。幾個星期過去了，我好幾次提筆寫這篇文章又停了下來，因為我沒有足夠的時間好好整理這些想法。現在我想我已經能夠透過剖析自己，在自身的軟弱、掙扎與對自由的渴望中找到答案——當人們長時間從事一件同時帶有負面面向的工作時，這種渴望無可避免地會侵入人心。維護一個開源專案同樣帶來許多喜悅與樂趣，我職業生涯的最近這十年無疑是令人難忘的，即使不是最棒的時光（畢竟我在新創時期玩得更開心）。不過在這裡我將聚焦於負面的一面；只是請別因此覺得它只有這些，它同樣有很多美好的部分。

洪流效應

我不相信凡事都要快速行動、快速思考、搶在時間內贏得競爭那一套。我不喜歡我們所處的這個世界，因為社群網路、即時通訊、電子郵件和排得滿滿的行程，讓人始終無法專注。因此在 Redis 專案的早期，當我還有很多時間的時候，每當收到一封關於 Redis 的電子郵件，我都能夠專注於寄件人真正想表達的內容。接著我可以回想起我們正在討論的 Redis 相關部分，最後在仔細思考之後，用我真實的想法來回覆。我認為無論從事什麼工作，大多數人都應該這樣工作。

當一個軟體專案達到像 Redis 這樣的知名度，同時人與人之間的溝通又因為新的社群工具以及你「隨時在場」服務使用者的態度而變得如此簡單時，作者收到的訊息、issue、pull request、建議的數量就會呈指數成長。同時，至少以 Redis 的情況來說，但我相信這是普遍的問題，能夠審視這些社群回饋的真正有能力的人數，成長卻非常緩慢。這就造成了明顯的壅塞。大多數人試圖用錯誤的方式來處理：靠實用主義。像是「提問後兩週內若原發文者沒有回覆，就關閉 issue。把所有描述不夠清楚的 issue 都關掉。」以及其他「收件匣歸零」之類的解法。現實是，要非常好地處理社群回饋，你必須花上所需的時間，否則你只是在假裝自己的專案只有少量的待處理 issue。如果有大量的資源可以為每個 Redis 子系統聘請核心等級的專家來全職投入開源工作，那或許可行，但並不實際。

那會發生什麼事呢？你開始越來越挑剔要看什麼、不看什麼。而你會因為忽略了這麼多事情和人而覺得自己很混蛋，同時貢獻者也會覺得你根本不在乎別人想貢獻給你的東西。這是一個複雜的局面。通常最終的結果是養成一種態度：大多只處理關鍵問題，而忽略所有新的東西，因為新東西畢竟還不在核心裡，誰會想要一個更大、帶有更多 PR 和 issue、而且程式碼庫更龐大的專案呢？更何況這些貢獻的寫法，也許比起你平常的程式風格還要迂迴複雜，帶來更多複雜度，等到那裡出現重大錯誤要追查根源時，就只能自求多福了。

角色轉換

由於上述「洪流效應」問題的影響，你突然之間也等於換了一份工作。Redis 會變得受歡迎，據說是因為我能夠設計和撰寫軟體。而現在我大部分的工作反而是去看 issue 和 pull request，而且我還覺得，很多收到的貢獻我自己可以做得更好。有些貢獻的品質會比我做得更好，因為也有比我更優秀的程式設計師在為 Redis 貢獻，但基於大數法則，*大多數*都只是為了解決提交者當下遇到的特定問題而寫的普通貢獻。相對地，當我為 Redis 做設計時，我傾向把 Redis 視為一個整體來思考，因為我寫這個東西已經好多年了。所以，你原本擅長的事情，現在反而沒時間做了。這反過來也意味著比較少有機的、大型的新功能。我的解決辦法是什麼？有時候我會連續好幾週完全不看 issue 和 PR，因為我在寫程式或做設計：那才是我真正熱愛、真正享受的工作。然而這樣做在心理上反而帶給我更大的壓力。為了做我熱愛且擅長的事，我得先覺得自己很糟。

時間

對我而言，長時間投入同一個專案會帶來兩個問題。

第一，在 Redis 的經歷之前，我*從來*沒有在一生中每週每天都工作。我可以工作一週、停兩週，然後工作一個月、再消失兩個月。一直都是這樣。人們需要充電、獲得新的能量與靈感，才能從事創造性的工作。而高水準的程式設計就是他媽的是一份極具創造性的工作。Redis 本身在最初的兩年就是這樣被創造出來的，也就是專案演進速度最快的那段時間。因為我只在想工作的時候工作的總生產力，遠大於被迫每天穩定工作時的生產力。

然而，當我獨自經營自己的公司時，我的工作倫理允許我擁有非常不連續的行程。一旦我開始收錢來維護 Redis，以我的倫理標準就不再可能維持過去的那種模式，所以我開始強迫自己按照正常的作息來工作。對我而言，這麼多年來這一直是巨大的掙扎。而且我確信正因為如此，我的產出比我原本能做到的還要少，但事情就是這樣運作的。我從未找到解決這個問題的方法。我可以跟 Redis Labs 說我想回到過去的行程，但那行不通，因為到了這個階段，我真正需要「負責」的對象是社群，而不是公司。

另一個問題是，就心理層面而言，長時間投入同一個專案也是一件很複雜的事。過去我每六個月就會換一個專案。現在我卻做了同一件事十年。在這方面，我試圖透過在 Redis 內部開設子專案來維持自己的理智。有一次我做了 Cluster，另一次是 disk-storage（現在已經放棄了），還有一次是 HyerLogLogs，諸如此類。基本上這些都是能為專案帶來價值、但單獨來看又是不同東西的事物。但最終你還是得回到 issue 和 PR 的頁面，每天處理同樣的事情。「Replica 因為逾時而斷線」之類的。我們再來調查一次吧。

恐懼

我一直有點害怕會失去對這個專案的技術主導權。不是因為我覺得自己在設計和演進 Redis 方面不夠好，而是因為我知道我的做法與以下兩者並不一致：1）相當多使用者想要的東西。2）多數資訊領域的人對軟體的認知。所以我必須不斷在以下之間取得平衡：我認為好的設計、功能集合、開發速度（緩慢）、專案大小（精簡），以及多數使用者期待我交付的東西。幸好有一部分 Redis 使用者完全理解 Redis 之道，所以至少偶爾我還能得到一些安慰的話語。

摩擦

有些人就是十足的混蛋。他們無處不在，這很自然，而且如果你問我，我甚至覺得程式設計領域的好人比其他領域還要多。但你終究還是會看到一定比例的爛人。作為一個熱門開源專案的領導者，無論如何你都得與這些人正面交鋒，而這或許是我在 Redis 開發過程中做過最有壓力的事情之一。

徒勞感

有時候我覺得，軟體雖然很棒，卻永遠不會像寫一本能流傳數百年的書那樣偉大。不是因為它本身不夠偉大，而是因為它的副作用就是它很有用……而當有更有用的東西出現時，它就會被取代。我也希望能有時間去做其他事情。所以有時候我覺得，我所做的一切終究是徒勞的。我們會設計並撰寫系統，而新的系統也會不斷出現；但任何只停留在寫軟體、而非停留在「軟體的宏大理念」上的人，真的能留下新的里程碑嗎？有時候我會想，我或許本來有能力去鑽研宏大的理念，但因為我專注於撰寫軟體而非思考軟體，所以沒能發揮那方面的潛力。這基本上與冒牌者症候群相反，所以我想我對自己有點自視過高：對此我應該更謙虛一點，抱歉了。

話雖如此，我能夠多年來從事自己真正熱愛的事物，並因此獲得朋友、肯定與收入，所以我不想說這是一筆糟糕的交易。然而，我完全能理解那些在專案開始受歡迎後，苦苦掙扎著想維持下去的人們。這篇部落格文章就是獻給他們的。