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

洪流效應

我不相信什麼快速行動、快速思考、搶在時限內贏過競爭對手那一套。我不喜歡我們所處的這個永遠無法專心的世界——社群網路、即時通訊、電子郵件，再加上行程滿檔。所以在 Redis 專案早期，當我還有很多時間的時候，每當收到一封關於 Redis 的來信，我都能專注去理解寄件者到底想表達什麼。接著回想我們正在討論的 Redis 相關部分，最後在仔細思考後，用我真實的想法回覆。我認為不管從事什麼工作，大多數人都應該這樣工作才對。

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

那麼會發生什麼事？就是你開始越來越挑著看，決定什麼要看、什麼不看。而你會因為忽略了那麼多事情、那麼多人，覺得自己是個爛人，同時貢獻者也會覺得你根本不在乎別人想給你的東西。這是個很複雜的局面。通常最終的結果，就是養成一種態度：只處理關鍵問題，忽略所有新東西，因為新東西還不在核心裡，誰會想要一個更大、然後有更多 PR 和 issue 的程式碼庫？而且那些程式碼的寫法，或許還比你平常的風格來得更迂迴，所以帶來更多複雜度，等到那裡出現嚴重 bug 要追根究柢時，就自求多福吧。

角色轉換

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

時間

至少對我而言，長時間投入同一個專案有兩個相關的問題。

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

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

另一個問題是，從心理層面來說，長時間做同一個專案也是件很複雜的事。過去我每六個月就會換一個專案。現在我卻做了同一件事十年。在這方面，我試著透過在 Redis 內部開子專案來維持理智。有時做 Cluster，有時做 disk-storage（現在已經放棄了），還有 HyerLogLogs 等等。基本上這些都是能為專案帶來價值，但在獨立來看又是不同東西的事物。但最終你還是得回到 issue 和 PR 的頁面，每天處理同樣的事情。「Replica is disconnecting because of a timeout」之類的。來，再查一次吧。

恐懼

我一直有種恐懼，害怕失去對專案的技術主導權。不是因為我覺得自己不夠格去設計與演進 Redis，而是因為我知道我的做法與以下兩者並不一致：1）相當多使用者想要的東西。2）多數 IT 人對軟體的認知。所以我必須不斷在「我認為好的設計、功能組合、開發速度（慢）、專案規模（精簡）」與「多數使用者期待我交付的東西」之間取得平衡。幸好有一部分 Redis 使用者完全理解 Redis 之道，所以至少不時還能得到一些安慰的話語。

摩擦

有些人就是徹頭徹尾的混蛋。他們無處不在，這很自然，而且要問我的話，我甚至覺得在程式設計領域，好人比其他領域多得多。但無論如何，你總是會遇到一定比例的混帳。作為一個熱門開源專案的領導者，不管用什麼形式，你都得去面對這些人，而這或許是在 Redis 開發過程中，我做過壓力最大的事情之一。

徒勞

有時候我覺得，軟體雖然很棒，卻永遠不會像寫一本能流傳數百年的書那樣偉大。不是因為它本身不夠偉大，而是因為它附帶的副作用就是「有用」……而當有更有用的東西出現時，它就會被取代。我也希望能有時間去做其他事情。所以有時候我覺得，我所做的一切，終究是徒勞的。我們會設計、撰寫系統，然後新的系統又會出現；但一個人如果只是待在「寫軟體」的層面，而不是待在「軟體的大想法」層面，真的能留下什麼新的印記嗎？有時候我會想，我或許本來有能力去鑽研大想法，但因為我專注於寫軟體，而不是思考軟體，所以沒能發揮那方面的潛力。這基本上跟冒牌者症候群相反，所以我想我對自己的評價還挺高的：抱歉，我應該謙虛一點。

話說回來，我能夠在這麼多年裡做著自己真正熱愛的事，它帶給我朋友、肯定與收入，所以我不想說這是一筆糟糕的交易。但我完全能理解那些在專案開始受歡迎後，苦苦掙扎著要維持下去的人。這篇部落格文章，就是獻給他們的。