姜寧，帶程式設計師前往開源“烏托邦”
在各種會議或者視訊中做自我介紹時，姜寧常常用這張照片——穿著藍白黑的格子衫，揹著雙肩包，臉上帶著笑，兩手直直地放下，任誰看一眼都能猜到，他是程式設計師。
他確實做了十幾年的程式設計師，但有一點特別的是，他為 Apache 軟體基金會（ASF）的開源專案寫程式碼。一開始，開源於他而言，不過是一份掙錢的職業。被推著走了很久之後，有一天終於意識到，在工作之外，自己要擔負起開源佈道的責任。
一開始只是組織貢獻者線下見面，後來發起了 Apache 北京本地社群， 協助成立 Apache 深圳本地社群，將 ASF 專案開發者， 與社群開源愛好者聚在一起。這兩年，他還開起了播客，以嘉賓訪談的形式，宣傳開源相關的知識和文化。
他將“Open Source Community”翻譯成“開源共同體”，稱之為程式設計師的烏托邦，是除了 996 ，程式設計師可以擁有的另一個選擇。“在這裡，程式設計師們通過郵件，程式碼評審一起交流程式設計心得， 一同協作開發足以改變世界的開源專案，在這裡，菜鳥可以夠得到高手的幫助，快速成長成為業界大牛。”
今年 3 月初，姜寧當選 Apache 軟體基金會（ASF ）2022 年度董事。他在董事競選宣言中說，“希望能夠幫助 ASF 打破地域、文化、語言的障礙”。
在開源佈道的路上，他已然看到了橫亙在面前的難以逾越的大山。縱使如此，姜寧也要踏過去。
01 成為開源佈道師
對姜寧來說，四年前的“抄襲”風波仍然在敲響著警鐘。
2017 年 6 月，華為開源了微服務框架 ServiceComb，託管在 GitHub 上。及至年底，該框架的 GO 語言版本 go-chassis 也開源了。
不料十幾天後，go-micro 的作者 Asim 前來討說法， 因為 go-chassis 使用了其部分程式碼，但沒有按照開源許可證的要求作出宣告。經過溝通之後， ServiceComb 團隊立即修改了程式碼，並得到了原作者的認可。事情到這裡似乎已經解決。
但傳到國內後，一切都變了味，輿論把它演變成了華為抄襲。
姜寧趕緊在知乎上解釋，但並沒有多少人關心事情的詳細經過，以及他們做了什麼，大部分人都盯著他們沒做什麼，以此發洩情緒，“故意”、“抄襲”、“狡辯”，即便有人發表中立觀點，也被指是在為華為洗地。百口莫辯。之後，他沒有再追上去解釋。
現在回過頭來看，姜寧正處在職業生涯轉型的關鍵時期。2017 年 1 月，做了十幾年開源程式設計師的他，來到了華為擔任開放能力中心的技術專家，成為了一名開源佈道師。“我來華為，就是要把我對開源世界的理解， 把我做開源的經驗，轉化成一些基本實踐原則，來幫助專案成長。”沒成想，卻在一年之後發生了 go-chassis 事件。
這件事不僅僅打擊了他的個人聲譽，還把公司拉下了水，被扣上“抄襲”的帽子。整個專案開發節奏也被打亂，最終 GO 語言部分的微服務框架程式碼，沒有進入 ServiceComb。
從事開源開發十多年，他也是第一次遇到這樣的事。教訓很深刻，讓他看到了很多，也學到了很多，深感開源佈道重要性。“以前做開源，是跟著大牛學習， 只需要遵守社群的規則，按部就班參與進去就可以。 但現在，要帶著沒有開源協作經驗的小朋友們一起開源，需要考慮的事情更多了。”
姜寧曾向專案團隊成員交代過，要規範使用程式碼，但很多開發者不重視開原始碼的版權，缺乏合規意識，只想快速實現功能。“以為開源的程式碼，想怎麼用就怎麼用，想怎麼改就怎麼改。這種想法是有問題的，最終是會付出沉重代價。”姜寧評判說。
事實上，在專案正式開源之前，所有自研程式碼都會用工具進行查重審查，以確認程式碼是否符合規範，但工具不能識別所有的問題。
他認為，唯有提升程式設計師的版權意識， 避免片段化引用第三方程式碼才能徹底解決這一問題。
"儘量以庫的方式來引用第三方開源程式碼。否則，很難說清楚自研程式碼和第三方開原始碼的關係，操作稍有不慎，就很容易被扣上抄襲的帽子。如果要修改第三方開原始碼，要把需求或者補丁提交到上游程式碼庫。這樣即減輕了我們維護第三方程式碼的工作量，也進一步完善了第三方開原始碼的使用生態。 ”姜寧總結道。
他也意識到，開源之後，所有問題都是敞開的，如果涉及大廠，問題會被放大，影響更惡劣。“版權意識，是每個開源人都要具備的。”
經此一事，國內更多專案開始關注開源合規的問題。姜寧也經常拿這件事來當反面案例，“不能把別人開源的程式碼拿來隨便用，要嚴格按照開源許可證的規範來。”
這場風波直接讓姜寧的職業生涯陷入了危機，但無暇顧及太多，他還有很多事要忙。就在兩個月前，ServiceComb 專案捐贈給了 ASF，進入了孵化階段。
姜寧意識到，要想讓專案從 ASF 順利畢業，除了合規發版，還需要構建起健康發展的共同體，發展外部貢獻者。而要發展外部貢獻者，就要擴大專案的影響力。影響力又是靠使用者不斷積累起來的，所以要發展更多的使用者。
他採取的方式很原始，主動跟對專案感興趣的人聊天，聊業務背景，聊實現細節，聊如何解決大家的痛點問題。起初，姜寧的內心有些抗拒——他以前是一個很少拋頭露面的技術宅，轉做社群工作後，開始還有些不適應，但隨著時間的推移， 他發現，通過這種方式，自己結識了很多志同道合的小夥伴。
“慢慢地，通過這種交朋友式的溝通交流，基於對開源專案共同價值的認同，讓人與人之間的關係緊密了起來。大家對開源共同體也產生了一定的認同感，會覺得這是我們的專案，而不是某一個人的專案。這樣貢獻者會投入更多精力進來，專案也會變得更好。”姜寧形容那種感覺，就像創業時找合作伙伴一樣，需要通過共同的目標來感召大家。
這個方法頗有效果，Apache ServiceComb 逐步吸引了一些外部貢獻者，不到一年時間就從 ASF 孵化器順利畢業，成為頂級專案。
雖然參與了很多 Apache 專案的開發， 但直到從零開始完整運作 Apache ServiceComb 專案之後，姜寧才對孵化流程中的 License 合規有了系統化的、全面的理解。 他也更加領悟到了構建開源共同體的重要性， 並堅定了向國內更多的開發者傳播 Apache 之道的決心。
2021 年， Weex 專案的社群成員不再活躍。沒有人提交社群報告，甚至連專案發版時都沒有足夠的 PMC 成員來進行投票。最終，姜寧結束了 Weex 在 Apache 的孵化，這是第一個在他手上退休的專案。他說感到很遺憾。
姜寧也希望 Weex 能夠善始善終。在此之前，已經有多個導師退出了該專案，他是堅持到最後的人。姜寧比以前更從容了，也看得開：“孵化專案失敗，我比其他導師經歷的事情，也就更多一些。”
隨著身份的轉變，姜寧對開源的認識也不一樣了。
以前，姜寧覺得，開源只是程式設計師關注的事情，大家把程式碼相關的所有東西都放在網上，誰都能看到，有興趣的人還可以參與其中，相互協作，把專案打磨得更好。“它是一種更先進的協作開發方式，給程式設計師的成長提供了一個很好的空間。”
現在的他認為，開源不單單是技術領域的問題。在把開源的成功經驗複製到企業內部的過程中，他發現，要解釋清楚開源的運作原理， 還涉及了很多社會學、經濟學的知識，它有很強的人文屬性。“從這個角度來說，我又找到一個新的，可以為之奮鬥十年的一個方向。”
開源之路並非坦途一片。正因如此，讓姜寧在開源專案孵化方面積累了很多經驗：“我們要遵守開源社群的規則和潛規則，開源許可協議是底線。此外，還有很多優秀開源實踐，可以幫助我們的專案走得更快，例如上游優先，小步快跑，社群大於程式碼等。”
02 程式設計師的烏托邦
在孵化 Apache ServiceComb 的過程中，姜寧意識到，原來通過佈道可以影響更多的人。於是在 2018 年及 2019 年，姜寧先後組織了兩次國內 ASF 貢獻者線下聚會，之後又發起了Apache 北京本地社群， 協助成立 Apache 深圳本地社群，將開源愛好者匯聚在一起，做一些有意思的事。
漸漸地，姜寧認識了越來越多的程式設計師，特殊的角色讓他成為了一個觀察者，看到了很多困在程式設計師身上的枷鎖。開源佈道的責任，就這樣在他心裡慢慢生長起來。他想，要用自己十幾年的開源經歷去告訴大家，還可以有另一種選擇。
“開源共同體是程式設計師的烏托邦。”姜寧如此認為。他將“Open Source Community”翻譯成開源共同體，而不是開源社群。
“‘社群’一詞，容易和居委會，我們居住的社群混在一起。”姜寧解釋說，“Open Source Community 既有生產者（開發人員），也有消費者（使用者）， 大家為了共同的目標（把開源軟體打磨得更好）聚在一起， 相互協作共同成長。”
ALC 北京成員聚會（2020 年 8月，北京）
他自己就是從開源世界成長起來的，最直接的收穫就是技術能力的提升。
令姜寧印象深刻的是，早年學習 ACE，看使用者手冊，學習架構模式，都是自己一個人，好不容易對它有了基本認識，然而卻沒人可以交流。接著還要花大量時間讀文件，看教程，寫程式碼，進展非常緩慢。然而在全職加入開源專案開發之後，在大牛的無私幫助下， 在與使用者交流溝通中，通過不斷解決開源專案執行的實際問題， 他發現，自己的開發水平有了顯著地提升。姜寧第一次體會到開源共同體的魔力。
他經常以此鼓勵程式設計師加入開源社群，一步一步跟著專案走，像走階梯一樣，會很紮實地成長起來。“在開源社群，會有很多大神級程式設計師扮演導師的角色，無條件地把經驗傳授給年輕的程式設計師，幫助他們找到技術拓展的空間。”
他反覆提到一個詞，辦公室政治。“在開源社群，程式設計師只要專心研究技術，而不需要考慮辦公室政治。”
“很多程式設計師都是在晚上寫程式碼。白天在幹啥？被拉著開會。”他看到，國內很多企業，專案出問題後，第一時間是開會，說是定位問題，其實往往是在互相甩鍋。“踢皮球踢了半天，問題一點沒解決。真的感覺是在浪費生命。”
開源社群不是這樣。在姜寧眼中，發現問題後，社群成員會主動 debug，不會出現推諉扯皮的情況，而且大家都是通過郵件列表公開交流，目的也都是為了解決同一個問題，所以工作效率很高。
他希望這些企業在開會這件事情上，能向 ASF 的董事會學習一下，會前大家通過非同步的方式處理相關的報告，每個月開一次，一次不到一個小時。“把開會的時間省下來，大家會更純粹一點，把自己手上的事情做好，做精，做尖。長期積累精進之後，效率可能提升十倍，百倍。”
他想，如果大家都具備開源協作的能力，工作效率會提高很多， 996 這種事情也會少很多，程式設計師的生存狀態也能變得更好，會有更多的時間去創新，做一些更有意思的事情。
這支撐著姜寧要當好開源導師，即便他知道，要改變這些事情可能沒那麼容易。“我沒有那麼強的能力，但我要告訴大家，在開源社群，你會更自由一些，更高效一些。”
姜寧認為，很多公司低效運作的一個因素，就在於中間管理層。但開源社群是扁平化的，“在這裡沒有專案經理，只有 Technical Leader”。
大公司需要有中間層來運轉，但不代表沒有弊病，他很清楚這些。姜寧一層一層看下來，中間層把下面的人做的事，包裝起來去維護他自己的位置，消耗了很多資源。做專案，程式碼還沒寫，前期規劃設計就花了一半的資源，剩下一半，大部分都放在協調溝通上。
姜寧認為：“長期下來，會讓人練就另一種能力——包裝。在企業，幹得好可能還沒有說得好。”在開源社群，所有內容都是公開的，把程式碼寫出來，交給使用者做驗證就可以了，不需要準備精美的材料向上層做彙報，就算要寫材料，頂多寫一些使用者手冊、設計文件。
而且，國內做得比較好的開發人員，可能過個三五年，就會轉行做管理，“變成大家都討厭的中間層。”這跟他在國外看到的情況恰恰相反。在 ASF 舉辦的年度社群會議上，他見到過很多很有技術激情的白鬍子老爺爺，讓他對程式設計師的職業生涯有了不一樣的認識：“給人感覺就是，程式設計師這口飯，可以吃很長時間。不像國內，認為 35 歲就不行了。”
姜寧說，更大的問題是，沒有長時間的一線程式設計經驗積累，管理層容易脫離開發層，做技術決策的時候，很難一針見血地指出問題。“如果這個人有 20 年的開發經驗， 他設計出來的框架會很穩定。初級開發人員可以直接在框架基礎上進一步修修補補，迭代更新， 不會把整個框架推倒從來。”但這樣的人在國內很稀缺。
對程式設計師來說，開源還有一個好處就是，可以長期專注於一個領域，從而沉澱自己的技術能力。姜寧認為這種長期積累是很有必要的。
他提到了具有 15 年曆史的 Apache Camel ，從誕生之日起，很多基礎架構一直都沒變，因為其創始人 James Strachan 把架子搭得很好。他還補充道，這種能力很難靠走捷徑把它學過來，而是要長時間的程式設計經驗的積累。
但國內程式設計師沒有多少可供長期從事的專案。“ 我們的專案生命週期可能就是三年， 過了三年就會被推倒，換一波人重新寫一遍。 這麼一來，我們只能做一些低水平的重複勞動。 ”這樣的情況，姜寧見的不少。而且，大部分程式碼服務於應用層面，只關注業務實現，沒有人關心這些程式碼是否寫得精巧、是否易於擴充套件，是否易於維護。
“不可能會有積累。”他說。
如姜寧所言，開源專案的程式碼生命週期會很長，從 1.0 到 2.0，再到 3.0，不斷迭代，經過十幾二十年，還一直在那兒，正如 Linux 一樣。因此，國外程式設計師專注一個專案十年二十年都是比較常見的。姜寧曾把八年的時間用在了 Apache Camel 專案上，他有一個同事，從 2006 年開始，一直在做 Apache CXF 專案，到現在已經 16 年了。
當然，開源專案也會有推倒重來的時候，但是他認為二者是不同的，這是基於之前積累的經驗、知識進行的重構，而不是低水平的重複勞動。
姜寧在很多場合說過，不喜歡碼農這個詞，那代表了重複，沒有創造力。“程式設計師應該去創造一些沒有的東西，比如工具，來提升自己的工作效率，降低自己的開發強度。”
此外，他還站在現實的角度，細數開源能帶來的好處。比如在面試時能證明你的技術能力，社群使用者幫你測試程式碼、完善文件，有的還會直接修 bug 打補丁······
03 難以逾越的大山
佈道，沒有開發那麼容易。從進入華為那天起他就知道。
以前，姜寧跟機器打交道，只要利用好網上資源，沉下心來就能學到技術獲得成長。但現在不一樣，這個新角色，要求他具備更多的軟技能，比如演講能力、表達能力、說服能力，還要去思考如何影響更多人。華為需要懂開源社群的人，而不是參與過某個具體專案的人。
他都走過來了。就連談起身份的轉變，姜寧現在都能笑呵呵說：“哎呀，其實是被逼無奈。”
但面前還有一座難以跨過去的大山。
“觀念的轉變是最難的。”姜寧說，“很多人只是把開源當成免費的、能讓他快速交活的工具。”
他能感受到，國內大部分的開源參與者都是搭便車的心理。把東西拿來用，用的過程出問題了，要麼在社群問一下，要麼自己埋頭修一修，修完了也不回饋上游。“大家不習慣和上游社群進行任何互動，而是把開源專案程式碼當一個成品，直接拿來用就完了。”
姜寧認為，參與開源要有交朋友的心態。大家是在公開的場合進行協作開發，稍微轉變觀點可以學到更多，而不僅僅是把開源專案當作完成日常工作的工具，因為那隻看到了開源表層的東西。
“開源最大的魅力是可以跟開發者交流，他們會給你帶來很多驚喜。你會發現，開源專案居然還能這樣用。”做開源專案維護者期間，姜寧最享受的事情就是回郵件。在幫助他人的同時，也加深了他對問題的理解，就像在玩打怪升級的遊戲一樣。人與人之間互動產生的思想火花的碰撞，會讓人成長更快。
在開發 Apache Camel 專案時，只要與他互動的人在北京，姜寧就會想辦法跟對方見面。不過最終見面的只有兩三個人。他覺得有點奇怪，明明有很多人下載軟體，卻看不到他們。
他鼓勵更多人跟上游交流互動，這是一個深度參與開源的機會。“要勇敢邁出第一步，只要參與進來，會有很多熱心的人幫助你。”
Apache Meetup（2018 年 10 月 上海）
對姜寧而言，在進行 ASF 專案孵化的時候會比較輕鬆，因為大部分開發者對開源運作流程有所瞭解，只要稍微引導就可以。“告訴他們，要公開透明，要用郵件列表交流，再進一步解決流程、合規等問題，最後是社群建設，把門檻降低，鼓勵更多人蔘與進來。這些方面做到位，專案自然就發展起來了。”
但要在公司內部推廣開源，姜寧說，太難了。
技術上實施起來並不難，難的是如何讓大家主動地參與開源。姜寧看到，雖然已經把程式碼放在內部公共倉，也鼓勵大家把技術用起來，但還是有很多人覺得，自己知道程式碼的執行細節就行了，不需要告訴別人開發相關的背景和知識。“他沒有體會到，公開與程式碼相關的上下文資訊 ，溝通成本會更低，協作會更容易。”
姜寧說，大量的開發者都沒有開源經歷，難以理解開源協作是一種怎樣的方式。沒有實際的體驗，大部分人都是機械地按照公司要求來做開源，領導關注事情就能落地，領導不關注的，往往做不到位。如果決策者或者推動者也沒有經歷過開源，就連溝通開源這件事本身，都可能存在很大阻力。
在很多大公司，跨部門協作也比較難。雖然每個人能力都很強，但各部門都有自己的地盤，人與人之間，就形成了一堵無形的牆。“我不跨過去，你也不要踏進來。得用各種各樣的手段才能讓各部門協同。”這讓姜寧頗為苦惱，因為在開源社群，加入進來的人都有共同目標，所以在做一件事的時候，大家都是儘量相互配合，給予鼓勵，而不是設定障礙。
不管是社群開源，還是公司內部開源，遇到的這些難題，歸根結底還是觀念問題，大家缺乏開放式協作的意識。
“只能一步一步來。”姜寧說。他能想到的解決之道，就是讓更多人蔘與到開源中來。“只要參與到開源社群裡面，就會發現，協作是一個很自然的做事方式。你幫我，我幫你，自然而然地，就能把事情做好。到時候就不需要再去改變大家的觀念了。”
“但這個過程可能要花很長時間。”他補充說，最好的方式就是，大家直接參與開源專案，邊看邊學，成長會很快。
04 開源滋養了他
在經歷過開源的暗面之後，姜寧仍然能看到開源美好的一面，堅稱“開源共同體是程式設計師的烏托邦”。作為程式設計師，他真真切切獲得過開源的滋養，經歷的開源是美好的、輕鬆的、自由的。
那是 2005 年，姜寧離開國企，進入海納（IONA）亞太研發中心，參與開發 CXF 專案。一年之後，公司把 CXF 捐贈給了 ASF。作為 Apache CXF 的初始 committer，姜寧很輕鬆地加入了 ASF。
毫無波瀾地，他的開源之旅就這樣開始了。“沒有人專門給我做培訓，就把我扔到社群裡面。別人怎麼做，我們照著那個樣子做，很多時候就是邊看邊學。我們從公司的 nobody 變成了公司的 somebody。”
在大部分人的眼中，開源都是與“志願”聯絡在一起，意味著要佔用大量業餘時間，且沒有收入。而姜寧早期經歷的開源卻不大一樣，他是拿著工資做開源，跟正常上班什麼區別。
姜寧說，自己是幸運的，沒有經歷過做開源還要考慮生計這樣的事。他曾在播客中提到：“過去十到十五年，我國開源充滿了悲壯的個人英雄主義，大部分開源專案都不賺錢，主要靠情懷。然而光有情懷，很難持續下去。“
真正讓他有成就感的，卻是另一個專案——Apache Camel。當時，Camel 想整合 CXF，作為 CXF 核心開發者的姜寧，正好也想多參與一些 ASF 專案的開發，於是就開始接觸 Camel。
為了成為 Camel 的 Committer，他老老實實地按照 CXF 中的“ Getting Involved ”提示，一邊熟悉 ASF 的工作方式，一邊不斷用提交補丁的方式“騷擾” Camel 專案中的其他 Committer，花了半年時間，最終為自己掙足了信用，在 2008 年初成為了 Committer 。姜寧說，這讓他“贏得了大家的認可， 再次體驗了一下成為 Apache committer 的快樂”。
這一次他經歷的開源，跟之前很不一樣。用他自己的話說，之前成為 Committer 是佔了 CXF 的便宜， 因為初始 Committer 不需要走 ASF 的慣用流程。而這一次，是姜寧一步步走過來的，是豐滿的，具體的。
在此期間，姜寧結識了 Apache Camel 的創始人 James Strachan。幾年後回過頭來看，那時國內開源環境並未形成，沒有什麼可借鑑的開源經驗，一切都要靠自己摸索，而 James Strachan 稱得上是姜寧的開源引路人。“他真正地擴充套件了我的視野，帶領我去追求新的前沿技術。”多年後，姜寧還在各種公開場合多次提及這位引路人。
也正是在 2008 年，IONA 被 Progress Software 公司收購，北京辦公室解散，20 多個員工都找工作去了，姜寧和另一個開發同事作為“善後”的留守人員，繼續維護這兩個專案。姜寧記得很清楚：“我們當時有 12 個開發人員，分成了兩撥。我們兩人留下，另外十個人，大部分都去了紅帽公司。”
沒了辦公室，姜寧就在家上班，做的還是那些事兒，只不過，給他發工資的，變成了 Progress Software。兩年後，他所在部門從 Process Software 獨立，成立了開源創業公司 FuseSource， 幾年後， FuseSource 被紅帽收購，姜寧也就順勢成為了紅帽員工，和 IONA 的前同事匯合了。
Apache Camel 這個專案，見證了姜寧完整的成長，從 committer 到專案 maintainer，再到 ASF member。在一則媒體採訪的視訊中，他回想起收到 ASF 的 member 邀請郵件，填完資訊登錄檔的那一刻，不禁笑了起來：“我好高興。這相當於 Apache 軟體基金會對我的認同。成為 member 之後意味著一件事，就是我可以 mentor 專案。”那是 2011 年 1 月，距離他加入 Camel 開發已近 4 年時間。
2015 年，姜寧從紅帽離職，結束了七年專職開源，在家辦公的生活。他現在經常懷念那時候——既能自主選擇工作時間和內容，又可以照顧家庭。
“我不能保證八小時全情投入，但有五六個小時，肯定是專注的。”上午八點開始工作，中午休息兩小時，之後接著工作，一直到下午四點半，這時候姜寧就要去幼兒園接孩子，然後做晚飯。
佔用了一個半小時的工作時間，姜寧就在晚上補回來，“晚上八點到十點，線上 2 小時”。儘管白天工作五六個小時，已經基本把重要的事情都處理完了。
妻子週末加班，週四才能休息，姜寧就跟著調整自己的工作計劃。“週四出去玩，比周末要好，因為時間錯開了，景區也沒那麼擁擠。”他說著說著，就笑了。
在家能把工作做好，姜寧也備受公司信任。“領導考核看的也是你交的活兒，而不是你具體什麼時間在上班。”
這與現在很多中層管理者的做法恰恰相反。“他會特別關注你是不是在摸魚，如果是在摸魚，那你肯定有問題，要不然就是工作不飽和，使勁給你加活兒。這就導致大家都沒有太多留白的時間。管理者在努力扇鞭子趕著員工往前走，員工就沒有時間去想，我下一步要做哪些事情去提高能力。這樣大家的能力提升不了，幹活的效率也越來越低。”
唯一不足的是，工作和生活分不開。郵件驅動他加班。只要使用者郵件一來，姜寧就趕緊回覆，已經形成了習慣。然而郵件一直來，一直來，妻子說他，“永遠有幹不完的活”。
十多年前，姜寧手機還不能收發電子郵件，直到諾基亞 720 手機出來。姜寧記憶深刻：”全鍵盤的手機，當時就覺得，哇塞，這個手機好好，終於可以隨時隨地回郵件了，爽很多。”手機到手後，陪妻子逛街時，他就找個角落，隔幾秒就刷一遍收件箱，盯著郵件列表上那些問題，抓自己知道的，隨時回覆。
有時也會有些小小的孤獨。他專注工作，對外的連線並不多，跟別人的語言交流很少，更多的是寫郵件，而且很多時候是跟老外交流。“在家時間長了，懂我的人比較少。當時在微博上認識了一票人，週末活動的時候見面，特別開心，可以說好多話。”
總的來說，那幾年，能夠專心做開源專案，是姜寧非常享受的一段時間，因為工作內容比較單純，自己的技術能力也在不斷增長。
05 履新之後
今年 3 月初，Apache 軟體基金會（ASF ）公佈了新的董事會成員名單，姜寧名列其中。他說自己曾經是一個佛系的技術宅，然而 ASF 董事這個新身份，卻是他主動爭取的。20 個候選人競爭上崗，最終只有 9 個人脫穎而出。
這次競選董事的宣言，姜寧花了很長時間去思考，到底要講哪些東西。最終出來的稿件，沒有什麼誇大的言辭，只是把他做過的幾件事，以及為什麼要做這些事講了出來。“讓大家去相信，我就有這樣的能力參與基金會治理。”
唯一一句口號式的句子，是他說，“希望能夠幫助 ASF 打破地域、文化、語言的障礙。”多年 ASF 開源專案孵化的經歷，給了他說出這句話的底氣。這些年，他先後幫助孵化了近 10 個來自中國的 Apache 專案。 他深知語言和文化隔閡帶來的溝通問題。
一年一度的 ApacheCon 是 Apache 專案開發者相聚一堂的好機會。但 ApacheCon 在北美舉辦，不是所有人都有機會參加，比如他自己在辦理簽證時就遇到過一些問題。於是他開始拉著 ALC Beijing 的小夥伴，把 ApacheCon Asia 辦了起來；瞭解到很多人不理解開源文化和 Apache 之道，他發起成立 Apache 本地社群，邀請國內外開源人士一起科普，辦活動，做交流，寫文章，開播客；隨著越來越多國內專案進入 ASF , 語言和文化成為中外開發者交流的一個阻礙，於是，姜寧主動擔任起導師和橋樑的角色，減少雙方之間的隔閡，讓他們更好地瞭解彼此。
在 ALC Beijing 的播客節目，姜寧與Tison（公眾號“夜天之書”主創）對話
成為 ASF 董事之後，姜寧肩上的擔子又更重了一些。工作和開源並不能嚴格分開，偶爾，姜寧也會在工作時間處理一些和基金會相關的事務，但華為沒有干涉，反而大力支援。
他也清楚地知道自己的短板：“站在董事的角度上，要推動 ASF 發展壯大，不僅需要國際化的視野，同時還要立足本土，把國內程式設計師帶動起來。我以前的專案孵化經驗，只能起到 40% 的作用，剩下 60% 的那部分，要自己去提升。”
在 ASF 擔任董事， 姜寧沒有薪資，驅動他的，是不知何時駐紮在他心裡的開源佈道的責任。以前，姜寧是一個開源的親歷者，現在是觀察者，推進者和領路人，他很樂意分享自己的經驗，來幫助他人排除一些障礙。他想讓更多人知道，開源這條路是寬廣明亮的。
問其為何要這麼做，他說：“開源是一種很好的協作方式，能讓世界各地的開發者協同起來，跨越公司，跨越國界，去做一些對整個人類都有意義的事。”
尤其是現在國際局勢緊張，很多開源社群紛紛表態站隊，姜寧很珍惜這種全球開發者協同的途徑，也想盡量去呵護這個途徑。
“開源是一個熱詞，但很多人沒有親歷過開源專案的運作，對開源的理解還比較片面，有可能被一些別有用心的人利用。所以我覺得還是要站出來，去呼籲，讓更多人理解開源，把全世界開發者協同的這條路走好。我會盡自己的力量去推動開源事業在國內國際的發展，發揮好橋樑的作用，更好地把開源精神貫徹下來。”
在開源這條路上，姜寧要做的事情還有很多，可以預見的是，要面對的難題也有很多。但沒有關係，當他帶著程式設計師前往烏托邦時，就會有很多和他一樣手持炬火的人，照亮前進的路。
【溯源】在每一場對話中，追溯關於開源的故事，認識那些極客、自由，並堅持著的開源人。
OSCHINA 推出的開源人物專訪欄目【溯源】。
溯源，意指向源頭追溯，為開源求解。問渠哪得清如許，為有源頭活水來。每一個開源參與者，都是掀起開源浪潮最鮮活的源泉。所有開源故事，共同構建著我們今天看到的開源世界。
開源剛出現的數十年裡，為開源奔走的黑客團體都在遭受來自社會主流的冷漠和排斥。即便現在的軟體行業已經大喊出“擁抱開源”的口號，問題也依然存在。
我們不知道開源貢獻者、開源佈道師，以及所有參與開源的人還會面臨多少阻礙，但給予我們信心的是，更多的人在投身開源事業。
所以 OSCHINA 希望面向開發者社群，尋找每一個積極參與開源、對開源有想法的人，瞭解他們以及他們的開源故事，窺探故事中的開源事業發展規律。
【溯源】系列文章：
01 適兕 ：成為開源佈道師
03 “工具人” 趙生宇：清北本碩，為開源從阿里辭職去同濟讀博
【溯源】專欄正在徵集開源人物故事，如果你認為自己或是身邊的人對開源做出過獨特貢獻，歡迎填寫下方問卷聯絡我們