更多深度文章，請關注雲計算頻道：https://yq.aliyun.com/cloud
在實體世界，路與橋等基礎設施的建設，人們都非常重視。在思想觀念上，比如說“要想富，先修路”，已深入人心。在資金保障上，人們也毫不吝啬，比如說，亞投行的建立、“一帶一路”戰略的确立，都是把基礎設施的重視，提升到非常顯赫的高度。
可是，在數字世界呢？
支撐整個數字世界“縱橫捭阖”的各類“基礎設施”——軟體，特别是占據大半壁江山的開源軟體，比如，大到你常用的linux、android，中到大資料常玩的hadoop、spark、hbase，小到accumulo、ace、bahir、bigtop、coveralls、travis、sauce labs、kafka、knox、lens、libcloud、logging、zookeeper等等，數以萬計的、你可能都叫不上名字的開源軟體，是它們，正以“潤物細無聲”地方式，讓你每天可以愉快地“玩耍”着手機，浏覽着新聞、刷着朋友圈、逛着淘寶網……，這些數字基礎設施的背後勞作，你曾經重視過嗎？
天上不會無緣無故地“掉下來個林妹妹”！那麼，又是誰，在背後默默無聞地維系着這些數字基礎設施的運轉呢？
當然是那些“意氣風發”、“技高八鬥”、“樂于助人”的開源項目參與者：contributor（對開源項目送出過部分有用代碼的貢獻者）和committer（對開源項目核心子產品和系統架構開發有較大代碼貢獻的技術大咖）。
但“意氣風發”、“技高八鬥”、“樂于助人”等，這些都是光鮮的表象。作為社會人，這些開源項目維護者，他們和普通人，一樣有七情六欲、一樣有喜怒哀樂，一樣有五味雜陳！
nolan lawson，就是這樣的人！
一把辛酸淚，誰解其中味啊？
每次登入github時，nolan總能看到一大堆令人頭大的、數以百計的維護通知（notifications），等待自己處理，此情此景，都好似有一萬匹草泥馬，在胸中奔騰。
善良如你，nolan也想提供幫忙，可是白天上了一天班，已經累得像狗一樣好不好，晚上回到家，心有餘而力不足啊。好不容易熬到周末，本想和自己的狐朋狗友，去郊外踏踏青、吹吹牛，扯扯淡，享受一下生活，可眼下費時費力的忙，到底幫還是不幫？内心好糾結。
這，就是一個開源項目維護者，時常面臨的尴尬！
在維護開源軟體時，nolan還會遇到各位形形色色的人群，具體說來如下幾類：
第一類人，他們用你的項目，可能由于某些api（應用程式接口）語焉不詳，他們比較困惑，于是來github詢問。可令人惱火的是，他們貼出來的代碼，連個規整的格式都沒有。有沒有“同志”有這樣的同感：<b>别人寫的代碼，是天下最難懂的“閱讀了解”！</b>特别是沒有注釋的情況下！
還有就是，可能是由于語言溝通的問題，導緻很多問題的描述，了解起來異常困難。
how are you（怎麼是你）？how old are you(怎麼老是你)？
一番折騰，你可能還是不懂對方的問題是什麼？無奈的你，隻能甩給他某個文檔或某個教程給他，或者建議他去stack overflow和 slack去試一試。
第二類人，他們在提問時，已經是怒氣沖沖了。他們會說，你丫咋還不回複他的問題。由于你提供的api有問題，已經浪費他生命中寶貴的兩個小時了！
最最讓人火大的就是tm這種人！這時的你，唯一能脫口而出的話就是：你大爺的，老子上輩子欠你錢，是伐？
然而，對這種人，你不必浪費時間，要壓下怒火，然後禮貌但絕不想再次搭理的回複：“這是一個開源項目，由自願者維護，如果代碼有問題，請送出一個可驗證的測試用例或送出一個pr（pull request）。
小編注：在這裡，簡單解釋一下，“pull request”直譯就是“拉回請求”，即如果你想向某個開源代碼庫repoa貢獻代碼，首先你要請求将repoa克隆一份，開辟（fork）一個新的分支repob，然後在repob上修正你認為有問題的代碼，然後送出給github平台。如果原始代碼庫管理者a，認為你修改的代碼是有價值的，就會稽核通過，然後将分支代碼repob，重新“拉回”到主幹repoa上去（即合并你的代碼，作為主幹代碼），在了解這個流程後，将“pull request”翻譯成“請求代碼合并”是不是更合理呢？當然，在知乎上，也有大神将其翻譯為“老司機，帶帶我！”，是不是也很傳神呢？你的翻譯是啥，不妨也說說呗！
言歸正傳，維護開源項目時，還會遇到第三類人。他們在使用開源項目時，可能會遇到一個非常常見的錯誤。其實，隻需翻翻文檔中的常見問答（q&a），或檢視一下以往的郵件清單，或花幾分鐘時間谷歌一下，度娘一下，一切都能輕易搞定。可他們偏偏任性不這樣，甯願做一個廉價的“伸手黨”！問你，問你，不停地問你！問你妹啊！
相比于“伸手黨”，第四類人就要好很多，他們就是普通的代碼貢獻者（contributor）。他們呢，小有名氣，猶如大俠，技藝高超，俠肝義膽，常常出沒于在各種論壇之中。有時，他們會就某個隻有内行才懂的議題，發起一個pr，并對其中的某個問題進行修複，然而由于這個議題過于複雜，以至于在他們的pr中，不得不用很大的篇幅來解釋他們的所作所為。
當你有點“稀裡糊塗”地認可這個pr之後，并回複lgtm（look good to me），然後将其合并到主代碼庫。
但是，問題來了！
當你沒有充分評估某個pr，而将其合并到代碼主庫，最終會帶來很多不可預見的新問題。比如說，雖然測試用例通過，但項目的整體性能卻降低了10個數量級，這時你會抓狂的。再比如說，一旦合并某個pr後，也會對老使用者造成無盡的困擾。因為更新版的api發生了變化，老使用者依據這個開源項目解決問題的工作流程，可能也會發生變化。這種持續不斷地變化，會讓老使用者的體驗非常不好！
還有一類人，也屬于代碼貢獻者（contributor），他們發現了項目中一個新的缺陷（bug），并做了修複。但實際上，這個bug其實你是知道的，它存在于該項目的某個子項目之中，然後當你告知他們，希望他們能在子項目裡去pr修複這個問題時，他們時常會“一騎紅塵”，再也不搭理你。
現在，在github中，你看出了contributor和committer二者的差別了吧：contributor是對開源項目做出過貢獻的人，他們有技術，有激情，但大多數contributor的激情，常常會在一兩次貢獻之後，就“一瀉千裡”。而committer則不同，他們是contributor的更新版，有技術，也有激情，最重要的是，他們激情長青，會持續不斷地輸出貢獻
……
還有一類人，他們一開始就興緻勃勃的開啟一個pr，但實際上，他們修正的問題，其實早已有其它維護者完美解決了，但他們現在還一片鬧騰，也是醉了！
還有一些人，他們的抱怨，的确是可以了解的。
你是知道的，由于開源項目維護者的精力，實在有限，有些問題，有可能幾個月過去了，都還沒有來得及去處理，是以他們的抱怨是：“3個月前，我咨詢你的問題，現在我自己搞定了。其實，解決的方案其實很簡單，那就是——哥不再用你的項目了。你的項目，俺用不起，還躲不起嗎？”
哇，哇，哇，一腔老血，奪口噴出……
此外，還有很多形形色色的開源項目使用者，他們的問題、他們的抱怨，他們的pr，源源不斷地來，解決一批，來一批，“此恨綿綿無絕期”。
這種場景常常令人非常沮喪，每次在維護一邊開源項目後，lawson感覺“整個人都被掏空”了。在諸如github這樣的開源平台上，存在這樣一個悖論，那就是：<b>越成功，越受罰！</b>
這是因為，如果你的開源項目越成功，别人關注、使用并回報的問題，也就越多，你為此就會遭受“懲罰”——付出更多的時間、更大的精力，來維護這個項目！
如果簡單粗暴地不搭理這些問題吧，lawson就會感到有很強的負罪感：可能自己的舉手之勞，就對别人有很大幫助呢？可自己再怎麼“舉手”，也隻有兩隻啊？數以百計的問題，撲面而來，如果都是春風細雨般的處理，等不到“夏天”，自己的人生就可能“挂掉”。
但如果總是由“負罪感”驅動來完成某件事，你覺得自己的人生，還會灑滿陽光嗎？
到後來，lawson開發了兩種政策，簡單說來，就是：
1）自衛，展開說就是“自我防衛”。不看（或者說不敢看）github上的維護通知，而是通過郵件過濾、分類處理大部分通知，做到離線（offline）維護，一切等到有空再說。這是因為，在上班時間，你還要為老闆每天給你發的薪水負責。在空閑時間，你還有媳婦要陪！
然後，盡量吸引更多的貢獻者（contributor）參與其中，經過考核後，然後将部分contributor提升為committer。你知道嗎？<b>日理萬機，其實是個貶義詞，那說明你笨，不懂得管理！</b>
2）自慰，展開來說就是“自我安慰”。天下沒有白做的工。做了開源項目，自己不也受益匪淺嘛？首先來說，自己積累了不少社群聲望，由此，還登上大會上作報告，并在推特（twitter）上，有數以萬計的粉絲，一呼百應。到後來，由于有了開源項目的經驗，還在微軟找到了工作，這一切，不都是拜開源所賜嗎？
嗯，其實吧，做開源，也挺好！
黑夜中，點燃了一支煙，深深地吸了一口，然後緩緩吐出，吹煙袅袅升起……
lawson并不知道，維護開源，自衛和自慰，到底哪一個先來？