導讀
作者是 Python 的核心開發人員，從2002年開始，十四年來自願用業餘時間為 Python 語言添磚加瓦。但這種活雷鋒行為並沒有得到開發者們的理解，很多人甚至用命令的口吻要求活雷鋒們再苦再累也得免費為自己勞動。
很多人會命令開源專案維護者趕緊修復這個或那個 bug、逼迫維護者們要滿足自己不合理的功能請求、稍有不順就要對開源專案維護者們進行人身攻擊。要求別人為自己免費勞動，就是在剝奪別人的時間，就是謀財害命啊。作者休息一個月，在本文中思考了開源社群人與人的協作關係、基本禮貌等問題。
2016年10月1日，我決定中止對 Python 社群的維護工作，到現在已經有1個月了。從2002年6月我參加 python-dev 以來，我幾乎將所有的精力都用在了維護 Python 開源專案上，即使是節假日，我們也會通過 Email 來工作。到目前為止持續14年了，這對我來說是一次重大的突破。
為什麼我會暫停維護社群的工作？
之所以在堅持了14年之後，做出這樣一個艱難的決定，源於7-8月期間發生的一些事情，讓我開始思考是否還需要繼續下去。
剛開始維護 Python 社群時，使用者只是讓我幫助修復 bug。但如果我沒有及時修復，就會連續不斷地收到 Email ，傳達他們因我沒有及時給予解決的不滿情緒，認為給了我足夠的時間與期望，但我還不願意幫助他們解決問題。
記得那時 Python 3.5.2 版本存在的一個 bug 還沒來得及修復，新版本 3.6 就釋出了，導致在新版本中也存在這個 bug。於是，就有非核心開發人員說，應該設定一個釋出限制條件 [譯者注：即前一個版本的bug沒有修復，則後續版本不能釋出]。也有使用者評論，修復一個 bug 只是舉手之勞，而我卻不願意去處理。要知道，不是所有的 bug 都是很容易就修復的，尤其是當它跨越多個版本的修復的時候。
當我試圖解釋 Python 修復 bug 的複雜性時，立馬就有人開始指責我在找藉口。兩個月後，我在Twitter上也看到了同樣的抱怨：所有這些都因為某個用於非主流 shell 的 venv 啟用指令碼出現了一個bug（換句話說，這並不影響Python的執行，系統不會因為這個問題出現異常）。而他們始終都沒有試著去了解保持 Python 功能正常的困難度有多大。
緊接著我收到了有關問題追蹤器的反饋——為什麼它要提議對語義進行修復？在某個星期六的早上，我在回覆中解釋了為什麼要這麼做，以防有人認為這是bug，然後浪費一整個週末去修復。但事與願違，我的好心解釋被誤以為是我在試圖阻止他們為社群做貢獻。（後來這些使用者在瞭解真相後向我道歉了）。
作為 Python 語言的開發者及社群的管理者，我覺得，基於 Python 語言的一些執行緒使用的比較多。卻很少使用者向我反饋這方面的使用情況。在維護過程中，每當我看到社群使用者之間用言論互相攻擊的時候，我都非常沮喪，覺得自己沒有將社群維護好。
當我看了Nadia Eghbal’s Road and Bridges 關於福特基金會的 OSS 維護報告，我才認識到這十多年默默無聞的付出和忍受是種浪費。（我覺得每個開源的專案使用者都應該讀讀這份報告）。報告清晰的闡述了社群使用者之所以毫無時間概念的向我提出工作要求，只因我一直自願加班為他們解決問題而且不求回報。久而久之，他們認為這是理所當然的，我就應該及時解決他們反饋的任何問題。報告也就這一現象做出了說明，大多數人希望我在業餘時間能夠幫助他們，實際上就是找一些理由讓我處理與Python專業相關的問題。（自我加入Microsoft以來，我接觸了各種形式的業務內容，Python是我工作的一部分，我這麼一干就是14年）。
開源工作的類比解釋
對於我們這些專案維護者的工作境遇，有很多人知道後一定覺得不可思議。（說是所有的維護者也不誇張。目前為止，我還沒有見過那個維護者沒有受到虐待的。）為了便於理解，我試圖做個類比來解釋。
設想一下，你還是童年時期，有一天想到了一個新的非常有趣的遊戲（可能是棋盤遊戲，也可能是遊樂場玩的其他遊戲）。於是你將這個遊戲的形式和規則告訴了小夥伴們。小夥伴們覺得特別有趣都玩了起來。而這時，又有一群新的小夥伴想要加入，於是你重新介紹了一遍遊戲……隨後，越來越多的的小夥伴想要加入，而每次你都要介紹一遍遊戲。為了省事，同時也為了讓更多的小夥伴可以參與進來，你決定花時間和經費做一個使用手冊，裡面包含遊戲內容和規則。這樣，只要有小夥伴想要加入，直接看手冊就可以學會這個遊戲的玩法。
隨後，就有人開始建議將遊戲進行改進，增加一些內容或規則。你覺得很有道理，於是採納了建議，更新規則後重新制作了手冊，再發給有需要的人。後來，一直有改進的要求提出，你需要不斷去完善，修改，重新制作手冊。為了將遊戲做得更完善，你絲毫不介意這些建議增加了你的工作量。
然而，又來了一批不認識的小夥伴，要求你必須增加一條“打人”的規則。你對這種命令式的態度非常不滿，而更為重要的是，你並不想在遊戲中增加暴力元素。你很委婉地拒絕了這個建議，於是對方就開始對你進行攻擊，攻擊完後還隨手拿走了遊戲手冊。看到自己的勞動成果被如此粗暴的對待，你心裡當然很難過。
面對刁難，如何調整心緒？
現在假設，Python 就是這個遊戲，而要求改變規則的是一些軟體開發者。這些開發者不停地向你提各種各樣的需求：“這需要改變，”或“你應該改改這個。”他們不認可你的作法，也不聽任何的解釋。一旦他們不再堅持了就會直接離開，但這並不代表他們認為你是對的。因此，當有人和你說“你為什麼要這麼做”的時候，最好的回應就是不做任何回應。。
除了不停質疑我並且不斷向我反饋的使用者以外，同樣讓我感到心累的是，還有些 Python 使用者總覺得我應該理所當然地免費為他們提供服務。而他們的損失再不濟也就是自己動手下載並安裝這個程式。（如果你用的是Linux的話，就不必費這個力氣，因為 Python 已經安裝好了，所以只要往終端中敲入“ python ”這 6 個字母啟動直譯器就行了）。
我花了大量的時間開發 Python 供使用者免費使用，卻總有一些使用者的態度感覺像是他們買了這個商品，我必須給他們提供“售後服務”。他們認為使用我的 Python 是幫助我提升知名度，我要知恩圖報。而事實是，我花時間和精力開發出這些程式碼，供他們免費使用，就是我送給他們的一份禮物。但在這些使用者眼裡，似乎我還需要搭上往後更多的時間和精力無償幫助他們。
我的看法
當我參加一些 Python 相關的會議的時候，我從來不會覺得人們對我的設計思路不滿或者對 Python 感到厭惡。當然，我也會遇到一些極端的人，當他們知道我是誰後，會對我說些難聽的話。但我完全可以將他們無視，而接觸那些熱於工作並支援 Python 的人。
一年當中，大概有兩個星期的時間，我能得到一些正面的評價，但剩下幾十個星期就不是這樣了。雖然PyCon 上的也有使用者會說“謝謝我對工作的付出”，但大多數時候，當我花時間幫他們解決問題後，只能得到輕描淡寫的“謝謝”。線上上，不管是從核心開發人員還是常規參與者那裡，我聽得最多的就是，我能不能滿足他們對xx或xx的需求，當然也有一些日常問候，但這在少數。有人說，10 個善意的舉動才能抵消 1 個惡意舉動帶來的傷害，但我認為善與惡的分量不是通過 10:1 能體現的。
開源工作的群體關係
接下來我該怎麼辦呢？我並不想停止對Python的貢獻。我在社群結識了不少朋友，每當我宅在家裡的時候，我們就會線上上交流一些有趣的事情。可現在，有些事情必須要改變。但在知道我需要改變的是什麼之前，我必須端正考慮問題的方式才能避免事情出現偏差。
首先，我將開源軟體視為開放式的開發，即在分享軟體的同時，也應分享維護該軟體的責任。這意味著，我不會像其他免費軟體一樣將原始碼開放視為必要的條件，而是以此為方式促成與軟體使用者的合作，使軟體更易維護。而這一切的成功取決於認真履行義務的專案維護者與其他使用者之間的關係。
讓我們看看這種關係涉及的不同型別的使用者。最大的群體是那些甚至不使用這一專案的人，他們通常會問我們，這個專案他們的系統能用嗎？一旦他們發現這個專案不適合他們的時候，他們可能會說：“我根本就沒法用，垃圾！”而不會意識到這款軟體本來就不是為所有人打造的。每當這時候，專案維護者都不能進行回擊，否則情況會更糟。
第二類群體就是專案的真正使用者，他們通常會向專案維護者諮詢一些解決問題的方法。所以，他們的存在可以推動專案更好地進行。然而，當他們要求專案維護者代替他們解決問題時，他們可能會失望。就像我們前面說到的，開源需要人們相互合作以維護專案。這就意味著使用者可以向專案維護者提出改進的建議，但他們不能要求維護者必須一定得這麼做。換句話說，你可以問：“你有考慮新增這一功能嗎?”但是不能說：“你必須新增這項功能”，因為專案維護者都是志願者，他們分文不收地貢獻了這個專案，但這不代表他們要聽命於你。
第三類群體是bug的提供者，他們會將在使用過程遇到的問題反饋給維護者。所以，bug提供者通常都會希望，社群能有一個專門的區域用以反饋bug問題，最好還能對bug進行分類。而專案維護者希望的就是，bug提供者不要要求他們必須將所有bug都修復。然而，當一個bug被反饋很多次的時候，還是要引起重視，因為問題可能很嚴重。對於bug提供者，有關鍵的兩點我想告訴你們：第一，每天都有很多bug被反饋，你的反饋只是萬千中的一個，不要太拿你的bug當回事；第二，bug的出現可能會影響你的使用情況，但修復它並不是一件容易的事，所以你要耐心等待。
第四類群體是補丁修復者。對他們的管理是最為困難的，因為補丁修復的工作只有在專案維護者允許時才能實現，而在這之前，補丁修復者需要做很多工作來檢查安全隱患。對於專案維護者來說，他們一定要給補丁修復者更多耐心，因為稽核所有的補丁並不容易，而且不是每項補丁都能被修復。我承認這一層關係是Python專案需要改進的，因此，我正努力將專案轉移到GitHub上，使補丁的稽核工作更加順利。
其實，專案維護者之間也存在著聯絡。作為一個專案的直接代表，我們之間相互依賴，相互監督，同時也要支援其他使用者試圖維護專案的行為。而我們之間最棘手的問題就是達成共識，因為每個人的想法都會不一樣。
對未來的期望
離開志願者服務一個月後，我希望能對社群做些改變，以便下次我請假離開是為了去度假，而不是因為職業倦怠。接下來，我會把工作重心放在增加我與社群的合作上。
在與使用者之間的關係問題上，我認為不用刻意去改變，順其自然就好。我仍然會在空閒時間查閱使用者發給我的電子郵件，以便最快地解答他們的問題。（我通常選擇晚上和週末碼程式碼，不過也得看心情。）
而我與bug提供者的關係，之後將會出現很大的改變，因為我打算停止修復bug。雖然我很感激他們願意花那麼多時間來找bug，但修復bug是件很基礎的工作，卻需要花大量的時間。所以我決定把它留給那些技術初學者去做，當是實踐學習，然後把我的時間花在更重要的事情上，比如維護社群內的另一種關係。
而這另一種關係就是我與補丁修復者之間的關係，我不斷地改進Python軟體工程實踐，以便其他人也能有機會學習Python原始碼（這也是我要將專案轉移到GitHub上的原因）。所以，如果我把時間花在了修bug上，我就沒時間做專案，也沒有時間進行 Python 的協作和維護工作。因此，放棄bug修復，而專注於維護與補丁修復者之間的關係，不僅給了使用者學習與實踐的機會，也給了Python專案提升與發展的機會。
至於我與專案維護者之間的關係，我認為不會有什麼變化。除了就某個技術問題進行討論時，可能會出現場面失控的情況，其他時候，我們的關係還是很融洽的。
這一個月的思考：
- 我清楚地認識到開源就是對一個專案進行合作，然後相互分擔維護的工作；
- 如果有人向我提出來了不合理的需求，我沒有義務必須對他進行回應，因為他不是我的僱主；
- 為更好地分攤專案維護工作，我需要停止bug修復工作，而專注於補丁稽核。