周洋: Hello 大家好，我是 Andrew。接下來的時間里我們會與 Kevin 聊聊有關“如何打造國際化開發者社區” 的話題。Kevin 有多年的國際開發者社區運營經驗，曾是 Meteor 社區的活躍貢獻者，也是國內最早一批 Meteor 技術棧布道者。現在是 iHealth 的 CTO。Kevin 與大家打個招呼吧。
Kevin: 各位大家好，我是 Kevin。很高興頭一次參加直播活動，對于我來說還是蠻新鮮的，聽說直播在中國比較流行，我還是頭一次體驗，所以還挺興奮的，我以前一聽直播還以為都是些長得漂亮的小姑娘穿少點兒，再唱唱歌，攝像機前跳個舞什么的。但唱歌兒這種事跟我這油膩大叔好像沒有什么關系。現在發現這樣討論技術也挺好的呀，我覺得很榮幸，謝謝各位。
可能有些人還知道我，因為以前來中國做過一些開源社區的普及工作，可能有的人還知道我原來在 Meteor 技術社區做過布道。當時他們叫我掃地僧來著，后來明白這是牛人的意思。我最近這幾年在 iHealth 做 CTO，也一直在開源社區做貢獻，對國際開源社區還是比較了解的。現在我加入了亦來云社區，加入社區熱心貢獻者行列，我很興奮能跟大家在一起分享。
今天主要的分享內容是介紹一下通常在國際上比較流行的開源社區的組織方式，如何去獲取社區成員尤其是開發者，如何讓他們能夠有興趣的參與，以及核心團隊成員如何準備資料文檔，能讓別人容易去參與，我把這個叫做 Community friendly，怎么讓社區能夠友好，這個是我今天講的主要話題。
另外一個主要話題是如何能讓跨國跨時區的協作開發比較順利進行，這個還是有點難度，這也是我之前在 iHealth 做 CTO 這些年來所面臨的問題，因為 iHealth是美國加州、中國、新加坡和法國四個國家在一起協作做的跨國項目。之間遇見了很多很多的困難和挑戰，不光是語言文化方面還包括協作工具，溝通方式等等，我們遇到這些困難再自己想辦法解決，然后組織出一些還算是有效的經驗吧，所以也在這兒跟大家共享一下。
昨天在 Elastos 北京辦公室跟大家分享了 iHealth 是如何做跨國協作，我們用了一些什么樣的工具以及如何來組織，聽了以后大家還是蠻興奮的，所以我就想推廣給更加廣闊的群體。因為之后 Elastos 是不是能夠成熟發展，成為一個成功的系統，完全倚仗于咱們亦來云開發者社區的各位，完全倚仗大家的共同協作，眾人拾柴火焰高嘛，所以我希望大家一起來把這個事兒做起來。這個就是我今天分享的目的。
周洋: 接下來我會問一些問題來請 Kevin 分享，也歡迎大家提出自己的問題參與互動。建立國際化開源社區，大家可能多數是遠程工作的，這和我們平時到公司上班很不一樣。那么我們怎樣分工，怎樣同步去解決一個問題。效率上會有影響嗎?
Kevin: 這個問題很有意思，我最近這幾年參與的項目基本上也全部都是去中心化的。現在咱們做 Elastos 是一個叫 Decentralized 去中心化的項目，我們要打造一個去中心化的社區，我們自己的開發環境如果不是去中心化的，如何去說服別人來用我們去中心化的解決方案?所以我們自己先得把自己的開發工作變成去中心化的，這個十分重要。
如果理解這句話呢?從表面上看公司沒有固定的辦公室，也沒有所謂的總部，也沒有美麗的前臺小姐，也沒有人事行政保安什么的，完全是大家在自己喜歡的地方，自己喜歡的時間，通過軟件的協助來協同開發，所以這個跟我們傳統意義上軟件開發的協作模式有了很大的區別。
我可以舉幾個例子， IPFS 是去中心化協作的存儲平臺，這在世界上還是挺有名的。這個團隊的成員沒有固定的辦公地點，開發者來自世界各地，他們也不一定互相見過面，大家都是在各自的國家，各種的時區，在自己喜歡的工作環境下，通過遠程協作的方式去共同貢獻代碼把項目推進起來。
乍一聽好像挺難的，因為平時大家在一個辦公室下協同都還有很大困難，那么這些人都分布在不同的地方，不同的時區，大家工作、休息時間都不一樣，怎么能夠一塊兒系統的工作呢?解決問題的關鍵點是我們必須有一套行之有效管理工具和管理方法讓大家來共同遵守規則，這樣每個人才能高效地去工作，也不至于影響到很多人，這就是今天我要分享的第一塊內容。
首先需要我們理解兩個概念，就是關于通訊，你們一定知道同步和異步Synchronize and Asynchronize 這兩個概念。同步是我們大家都在一個地方，把時間 block 住，在同一時間只做一件事情、討論一個問題，直到把這些解決了才進入下一個步驟。異步是把一件事情分成好多的小細節，然后分成幾個不同階段，在每一個小階段里由一個人來解決，他不會依靠另外一個人解決問題，當他遇到一個情況不能繼續進行的時候，他就把它放到一個隊列里邊，然后執行下一個任務，直到這個隊列可以繼續進行的時候再把剛才級升到一半任務放到自己的最尾端，然后有時間再去執行。
舉個形象簡單的例子:Java Script 語言的特點就是不可以被阻擋的單線程，如果靠遠程的 Http請求做運行的函數，如果時間比較長，它不會像 Java 那樣等待著執行結果送回來它再繼續進行，而是它會把這個 Call出去以后就把結果放在一個回調函數里面并擱到隊列的結尾，它先執行下面的子任務，直到這個回調函數的結果回來以后放到隊列下面，它有時間輪到那個地方了再去執行。
我們日常工作中也可以這樣，只有少數很緊急的事情需要我們必須得立刻把其他所有事情都停下來，集中精力辦大事，這是中心化的做法。大部分時候我們是完全可以把它分解成小任務，然后分散給大家各自執行，如果子任務執行過程需要等待別人的反饋，你就把它停在這里，相當于斷點一樣，給個回調函數放到自己的任務列表的下面，自己再做下一個任務。只要任務的安排足夠合理，每個人都可以自己十分高效地向前工作，而不用每個人坐著等，影響大家共同的工作，這就是較合理的工作安排。
合理工作安排我們其實已經有很多很成熟的這些工具來使用，大家都在用的代碼管理工具 Github 有很多的部分，比如像Issue 還有 Wiki 等都可以來參與任務管理。其他任務管理工具包括像 JIRA 這些大家用的比較多，也是很不錯的一個工具。另外產品經理真的很重要，要把整個 Feature 和 Bug 分在一個Issue 里，每個Issue 不要太長，最好是可以讓 Developer 在一天之內最長不超過兩天能夠完成，如果這個任務很大得想辦法變成子Issue 的小Issue，讓它變得比較短。而且Issue 執行過程中他有時候會有些Dependency，比如要解決這個問題先要解決另一個問題，如果有 Dependency 的話 Developer 在執行這個Issue 時會把它 Re-assign 給另外一個人，然后自己去做自己名字下的下一個Issue。這種工作的結果就很像 Java Script 的無阻塞單線程模型，每個人任何時刻都是有事情繼續往前做，而不會在等著同步完成這個東西。
如果產品項目是這樣規劃的，會發現一個很有趣的現象，每個人都在比較忙但是又不是特別忙的工作，就是比較從容的在做這個事情，而不會是全部人都放下手里的事情集中在一起解決問題。傳統的方式很多時候大家就互相等著，實際上效率是降低的，所以這就是集中和分散的兩種不同工作模式，集中的模式大家都停下來干一件事，對于這件事情而言可能是效率高的，但是從總體進度來講不見得是快的，集中精力辦大事是好的，但對于整體效率則不一定。
Jerry: 協作的需求怎么協商呢?會不會多個人同時在開發同一個功能?
Kevin: 我先回答后半截問題再回答前一個問題，不會發生多人同時開發一些功能這個情況，因為在 Issue 的時候你建立了一個Issue 要把它 Assign 給一個人，每個人都可以改變它的狀態，如果用 JIRA 的話就更容易做，這個軟件功能更強大。你在做一個Issue 的時候它就放到你的名下了，如果這個Issue 在別人名下你最好爭取這個人同意，再把它拿到你的名下來做，也就是保證每個Issue 是一個人來負責，而不是多個人。
我通常不建議分配Issue 的人把同一個Issue 分給超過一個人，比如兩三個人。其結果就很可能變成三個和尚沒水喝的結局，大家反正還有另外倆人，天塌了高個子扛著，沒人去做就麻煩了。所以就把它分給一個人，如果他說他不能解決再把它 Re-assign 給另外一個人。如果一旦分到個人頭下的話，就不會發生多人同時開放一個工作的情況了。(每個人都不要去做不在自己名下的Issue)如果一個功能很大，一樣可以把它分成幾個小功能，每個功能是由一個人單獨開發，而不是把整個功能分給十個人。聽起來好像很協作，其實這叫不協作，沒有人是責任人就更麻煩了。
如果Issue 規劃的好，結果就是每個人的任務變得很簡單，我的任務就是每天打開電腦解決掉我自己名下這些Issue，如果解決了就交給別人去測試，如果不是我解決的或者我被卡住了需要別人解決，我就把它 Resign 給別人。總之每個人手里一直都有任務做，而且每個人都自己解決自己的任務。
協作的需求如何協商這個是比較重要的話題，剛才我前半截兒提到了產品經理或者項目經理在這邊就十分重要。他的主要任務就是從客戶這邊把需求或者自己的設計拿出來后，把它分解到具體的 Feature，這個是一個很重要而且還不是很容易的工作。因為剛才我講了，每個 Feature 的開發時間要有一個大概靠譜的估計。當然估計一個軟件開發時間是很難的，所以產品經理需要對這個產品開發十分了解，這才叫一個合格的產品經理。
產品經理面對的是Developer，他把這些需求劃分成為不同的Issue，然后每天要跟蹤各個Issue 的執行情況。他的任務要看哪些被阻礙時間比較長，比如在一個人名下停了超過三四天的時候他就要了解一下有沒有遇到什么困難，是這個人一直解決不了呢，還是說他忘了把它送給其他人來做，包括也要看誰手里沒有Issue 了，那就給他分布一些任務過來等等，這他的重點工作。
關于工作效率的問題，還是說 Java Script，你們要是寫過就知道，雖然這個語言是低效的，不像是 C++ 這種語言直接可以很快的被 CPU 執行。但是 Node.JS Server 執行的效率十分高，它高的原因就是剛才我說的原因，它是異步執行，它不會被阻塞，CPU 總是有事兒干，一旦它在等待的時候到最后會把等待任務Callback 以回調函數的方式放到最后邊它就是繼續執行下一個任務。這種情況下，對于整體來講是十分高效，如果你們做過 Node.JS 程序或者對比 Java Server來講，Java Server 通常很難達到超過百分之四十或五十的這種 CPU 占用率。Node.JS 程序達到了百分之六七十、七八十也都很正常，并沒什么特別之處。
剛才講異步的好處大家都理解，同步的壞處大家也能很容易理解，因為同步大家就要等待，總體效率會比較低。但是多很多東西是必須同步才能解決的，常見的比如說大家在一起需要討論Feature 技術實現方案等等，像這種情況恐怕就沒有辦法用異步來實現。這種情況下是必須得通過同步來完成的就是剛剛講的Synchronize 方法，Synchronize 的方法在一個好的開源社區項目中能夠盡可能少地被使用。少的意思是盡可能節約著用，什么意思呢?就是它是一種高成本的方式，尤其是對于那些異地、跨國、跨時區的協作來講，先不說 Face to Face，哪怕是同一個時區，通過遠程開 Zoom 的時候(Zoom 是一個會議系統，待會會跟大家介紹)時間上能到湊一起就是挺難的一件事情。
周洋: zoom.us
Kevin: 舉個例子，之前我們 iHealth 就已經是在四個國家三個時區了，美國加州西海岸硅谷、中國和新加坡一個時區、法國，這三個地方都差八個小時。地球是圓的這誰也改變不了。所以你在任何一個時間想找三個人的地方的人同時開會，都是不可能的，總有一個地方的人是在睡覺的。那么你非要開這個同步的會議，那么就是得有一個人做出點犧牲，要么睡晚點，要么早起點兒，反正我經常屬于被犧牲的那一種，早上七點鐘起來，趁著法國還沒睡覺，中國也還醒著的時候，這時大家開個會。所以這個成本很高，總得有人去做點兒委屈。
如果你要想面對面的開會，那成本就更高了，總得有人跨過要么大西洋，要么歐亞大陸飛到另外一個洲去開會，咱先不說酒店機票成本，就光跑一趟倒時差對大家的工作效率就會產生影響，這些都是巨大的成本。所以大家要把必須要同步才能解決的問題降到最小。最必需的東西，比如開會，討論，甚至于面對面開會這些都是需要珍惜使用的時間。
在這里有一些規矩，剛剛提到的Zoom 這是一個會議工具，我們用Zoom 較多，因為通話質量比較好而且它在中國也可以用。約定時間這個事情也是很有技巧的，在很多情況下大家對時區的概念不是很明顯，中國是一個時區，哪怕是在新疆也用北京時間。在美國就有五個時區，還差三個小時，所以經常會發生大家討論問題的時候要帶時區。
跨時區工作的人一定要有一個概念，你跟別人約定一個時間的時候通常要帶個時區在后邊兒，比如現在美國我們約時間通常說上午十點 EST 或者 EDT。我得給個具體的日期是哪天或者星期幾，通常不會說明天上午八點，因為明天上午八點這個事兒對于在不同的時區的人，聽起來是不一樣的概念，你的明天上午八點對他來說也許是后天，也許是今天，所以一定要給一個具體的時區，才能把時間約定好。
有些工具比如Google Calendar，是Google 組件里面的一個像 Gmail 一樣可以幫大家約定會議的工具，它的好處是你每天可以把自己工作和不能工作時間都標出來。如果這個時間是 Available，那么別人就可以把這個時間Book，然后跟你進行討論，把這個時間定一個會議時間，我們每個人的 Calendar 是可以分享的。你想跟他開會時候，就看這個人是Available 還是 Not Available 能不能跟你開會，這樣的話那就省了很多時間。所以這個就是工具的用處，起碼光這一件事兒，就節約了每天至少十幾分鐘來討論你有沒有時間開會這件事情，這就是一個挺大的工具進步。關于遠程協作的問題我差不多說完了。
Jerry: 產品經理來做 Issue 的劃分，在國際化開源社群里面產品經理是非常重要要求非常高的，那么這個重要的角色一般要怎么產生呢?另外還有測試的問題怎么做?
Kevin: 一般來說，幾乎是在項目中最有經驗和技術背景的一個人，而且還能夠和客戶交流。很多產品型的企業 CEO 自己就是個產品經理，這是一個非常高的角色，而且這個產品經理還不能不懂技術，不懂技術的話就沒有辦法劃分issue。所以不是很容易找到這樣的角色。
另外測試問題是個大話題，在開發這里有幾種測試，第一個是程序開發者自己要寫單元測試，這個是必要的但同時也是最難做到的，因為有些開發者認為東西能跑就行了，覺得單元測試浪費很多時間所以不愿意寫單元測試。我對這件事情的解決方案是這樣的，我不需要覆蓋百分之七八十的代碼，我只要覆蓋百分之五到百分之十的，這些代碼是十分難以被測或者十分重要的代碼，我用單元測試解決。所以如果你寫單元測試，就務必把很重要的核心代碼的所有可能性都要測到，這就是我的一個建議。
這個建議如果翻譯過來更容易理解的意思就是，有的代碼容易從界面中測到，比如這段代碼他如果出錯了用戶馬上就能看結果，而且你很容易查，像這樣的代碼恐怕在整個軟件中應該是超過半數的，這種比較容易的沒必要寫單元測試。另一部分是很難被測到的，即使能用這個代碼也是用的很少的幾個 Scenario，這種情況下，如果你指望測試員去測試恐怕是測不到的。尤其是如果這段代碼還很重要，如果錯了對整個系統有巨大的影響，就需要仔細思索單元測試的問題。
當然這個問題通常也是留給產品經理或者是資深的架構師來確定哪一部分代碼是必須要完善單元測試的，對于這些單元測試的代碼，你就要仔細寫所有可能的Scenario，邊界條件都要測到。這就是一個紀律，這個代碼如果沒有測試到沒有授權出了問題，那問題就比較大了。這塊可以舉一個很有趣的例子，也是聽美國的大牛們給我講的，這個例子是，我求兩個數的均值，a 是個(無符號)整數 b 是個(無符號)整數。我讓 c 等于這兩個數的平均值，所以c = (a + b)/2， c 是不是這個平均值?大家是否認為 c = (a + b)/2 這個很簡單的等會出錯?我先停一會兒聽你們的反應。
周洋: c 是 uint 的話，負數就錯了。
Kevin: 周洋贊一個。確實這段代碼是有錯的，c 在某些邊界條件下會出錯，如果你們是老程序員或者經歷過這種類似的折磨就知道當a和b兩數都很大的時候加起來會超過(正)整數最大值，會變成負數，我剛剛忘了提醒了這是個 uint，所以正確的是用它的差去補就可以了。就是這樣的一個代碼，我第一次被人家問的時候我就沒想出為什么會錯。這就是邊界條件，要通過測試才能容易發現這種很難被解決的問題，所以單元測試很重要。
下面說用戶的 Integration Test 持續集成，這個實際也是單元測試的一種集成方式，好處是你每次提交代碼的時候都會自動跑一下。首先這編譯要通過包括你Code Liner，檢查你的電腦不符合規范的一些問題，如果有不規范的、不通過的重改才能提交，提交了以后就到下一步的部署服務器，部署上去以后不會進入立刻就生長的環境，是先進入Staging。
Staging 中文大概叫后臺，意思是沒有正式上線服務器的一個測試狀態，測試服務器里面運行另外一整套的面對生產環境下的一種測試工作。如果沒有通過的話，一樣會打回來，它就不會部署到生產環境下。如果這個部署的是已經通過了，然后我們測試人員已經手工測試過以后才會真正的部署或者叫灰度部署到生產環境下。這樣的產品質量就會比較高，而且部署后還有 Rollback Plan，就是如果出了問題怎么能退回來，比較保守可靠的做法是灰度。
周洋: 大家交流應該都是使用英文吧。假如我英文交流不太流利，僅能讀懂開發文檔，表達簡單問題。有什么好建議或者方法能幫助快速提高表達能力，與國際開發者溝通嗎?(使用英語去想問題)
Kevin: 英語是一個很大的問題。不用避諱，因為我自己也是這么過來的，我生在中國，你看我中文講這么利索，這不是后來學的，后來學中文不會講這么好。在中國讀的書，清華畢業的又在北京工作了幾年，然后移民去了加拿大后來又移居美國。所以走南闖北不少地兒，后面的后半生基本是在講英語。我很了解，對于生在中國沒有太多機會去跟國際接觸，本來也就不太愛講話，主要跟計算機和蒼老師在交流(學習日語?)。
這種情況下，要想提高英語的方法有沒有呢?有人說你去美國待幾年就有了。也對也不對，去美國是個好機會，但是去美國不講英語也大有人在，也不能說到了美國英語都會好，這個事兒不成立，完全取決于自己。那么我想說的是，如果你不去美國，你就沒有機會去用英語跟別的社區進行交流嗎，不是的。
我發現一個很有趣的現象就是說和聽英語，不是很容易，至少對于很多中國、東方語言來講。但是讀和寫相對來說，還是比較容易跨越的一個難度。我知道很多的 Developer 讀英文文檔，甚至寫英文的注釋還不錯。我當時為了讓中國團隊的員工盡量適應英文的這種思維方式，就用 Slack，一個協同工具，你面對的人，往往是不會講中文的，大家企業內部通信全部是Slack，每天大量的 Message，像瀑布一樣流下來。對于中國員工也一樣，所以被迫適應，沒有時間去翻譯。學語言一定不要翻譯，而是要用那個語言去思維。
在 Slack 里面跟同事討論問題時，你是不可能有時間去翻譯的。只能是 English in，English out。這個時間過快就迫使你的大腦使用英語那一片去想問題。而且不要去做處理，進來的英語馬上轉述回去。這樣的一個訓練，對于提高英語的語感十分有效果，我自己的感受是說，不見得要求你說得很流利，其實也不太可能。如果你十三四歲以后去英語國家的話，你這一輩子英語中國口音是改不了的。我在美國一張嘴他們就知道我是從中國來的，口音是改變不了的，但是不影響我在那兒生活和工作。
我對大家的期望值也是這樣，你沒有必要去學個什么英語班。你能夠用英文想一個問題，用英文的方式考慮，拿鍵盤把它打出來，這就是巨大的一個改進。而且如果你能夠用英文去想問題，那么即使你今天是用鍵盤敲，一旦有機會必須用嘴說的時候，你馬上就知道該怎么說了，因為你腦子里是用英文在想。所以我建議是大家花更多的時間來換你的語言環境，可以讀英文的文檔，可以寫英文的注釋、文件，就用英文寫，不要試圖去翻譯。而且隨著工作的需要，你有更多的機會跟國際的同事用英語交流，快速地用鍵盤去聊。
有一天你發現你不用想就可以快速地這樣交流的時候，你離用嘴去說英文就不那么遠了，一旦發現有機會就說，你會發現這個東西比你原來想的容易很多。另外還需要有點強制性，因為人都有惰性，只要用一個方便的語言能夠表達了，就不愿意用一個比較難的語言。之前在 iHealth 也出現這個問題，中國員工在美國比例比較高，大于百分之四十。我就習慣在辦公室公開場合跟大家用中文說話，但辦公室還有其他很多不會講中文的人。他們會覺得被忽略，影響工作情緒，結果這些人就可能會慢慢的離開這個公司。
而新招的人如果感覺到這種情緒，可能就不愿意參加這個公司。除非他也是講中文的人。結果這個公司的文化就慢慢變成中國文化了。這是我極不愿意看到的一個事情，因為我一直是強調公司要國際化。各種各樣的族裔均衡，所以我們訂了一個 Policy: 在公開場合，比如辦公室內部、公開的區域里，英文是唯一的語言。小屋里邊兒聊，出去聊，不關我事。開會時一定是英語，也是官方語言。我們嚴格執行這一條，效果還不錯，公司講英語的員工仍然是多數，沒有變成中國公司。要是想跟國際社區交流、要看世界，尤其是科技領域，英文就是一個通用語言。
如果你會講英語的話，看到的世界跟你只看中國的世界是不一樣的，你看到的媒體、看到的新聞來源，也不再是那些經過機構篩選過的新聞內容，你對世界會有一個更加客觀的認識。這一點的收獲，遠遠要超過你為了學英語花的那些時間的成本。
另外有一個人，我們要大贊一下，就是咱們的韓老師、韓鋒博士，亦來云聯合創始人。他去年第一次去美國的時候，英文還差的比較遠，點菜等各方面都還不知道該怎么講。最近幾個月時間，他在哥倫比亞大學做訪問學者，一直很膽大敢說，用英文演講，跟國會議員、哈佛劍橋的人用英文去表達自己的理念。現在的英文水平很快已經不可同日而語了。這是一個很好的榜樣。韓鋒老師，我敢保證比咱們群里大部分人年齡要大，在這種情況下，他都勇敢地用英文去跟這些陌生的老外去交流，用英文表達自己的觀點，面對臺下這么多人講演。這種精神，是十分可貴，值得學習的。
周洋: 談談社區的建設，團隊核心成員怎樣與社區互動，什么樣的工作適合交給
社區來做?
Kevin: 以亦來云為例，亦來云的成功與否，最關鍵的不完全取決于技術，而取決于是否有很多開發者愿意來用亦來云開發自己的 DApp。而這又取決于另一個因素，即亦來云是不是容易讓他來用，是不是提供了足夠的文檔，說明材料，視頻教學等等。如果你沒有提供，還想要人來開發，這是很困難。所以要把一個核心產品變得大家易用，即 Community Friendly。
而這件事我認為最好由社區的人來做，因為他們既是用戶也是體會最深的人，也是需求最旺的人。他們來參與這個事情是比核心開發人員做更適合。因為社區成員關注的，不完全是內部 Core Team 關心的東西。Performance， Security，不見得是他們最關注的。他們最關注的是，是否 Community Friendly，是不是友好，所以這些事情我覺得適合社區來做。而核心開發的部分，如果能夠有一些比較靠外圍的部分也可以拿給社區做。但是特別核心的部分因為需要核心團隊十分 Intensive 高強度的工作，需要密集的交流的工作就不太適合在遠程由社區成員來做。
從社區的運營來講，可以舉一些例子，比如 Meteor(一個開源項目)，它是一個很流行的開源社區項目，是做 Application 的工具，幾年來每個月都花一個下午時間在他們總部舉行聚會，社區的核心成員基本都會來，跟著核心開發人員在一起建立面對面的關系，跟核心成員討論怎么建設社區包括技術的問題、產品的一些要求，互動等等。晚飯以后，就是對外公開全球直播。分兩部分，一部分是團隊的人介紹產品開發進度，新功能，未來計劃，社區工作等。另一部分由社區的活躍份子，或者用這個產品開發軟件的人來花幾分鐘講講他們做的項目，展示給全球社區的成員。給這些社區活躍份子有一個露臉的機會，同時他們也可以提出對產品的建議等等，這是很好的活動。
會議結束以后在大家會一起聊天交流，公司會提供場地啤酒，零食等，讓這個社區團結的比較緊密，除此之外，他們在全球還有其他活動，很多時候是由各地的活躍社區自己組織的。比如倫敦那邊的社區活躍份子他們自己來組織，有時美國這邊會派個人去一塊兒參與，有時就遠程視頻參與。所有活動都有錄像，在網上都可以看到，是可以追溯的，每年都記錄了大量的資料，IPFS 也是一樣。
IPFS 是比較新的項目，他們是視頻會議，總部基本就沒人，每周有個線上的會議。全球社區的人都在線上的會議上，大家上 Youtube 可以搜索到 IPFS 的大量視頻資料，比如討論項目進展等，有 All Hands Meeting即所有人都可以參加的會議，有一些是 Core Team Meeting 即核心團隊的會議，由核心的人物，開發人員來討論。All Hands Meeing 和 Community 是任何人都可以參加，獻計獻策。所有的開發工作都在 Github 上完成的。
對于社區的活躍份子有很多種參與的方法。深入了解的可以參加核心代碼開發，幫忙找問題，然后提交Issue。或者自己改好代碼，直接Pull Request，提交給核心團隊，核心團隊主要任務就是 Merge，核心團隊發現這個問題解決的很好，就Merge 這個 Pull Request。所以判斷一個 Github 的項目是不是好可以參考幾點:
1.Star 的數量，Fork 的數量，代表的它的關注度和參與程度。用類比的方法來解釋一下 Github 參與的流程，比如考試，老師改卷的場景，你做的試卷就像倉庫Repo，試卷的錯誤，相當于程序里的 Bug。老師把你的試卷拿過來，相當于先 Fork。在你的卷子上做一些修改批注，相當于 Git Commit。最后把改好的試卷給你，相當于發 Pull Request，你拿到試卷重新改正錯誤，相當于 Merge。
2.Community Members(社區成員)的數量。社區成員越多越好，不用擔心大家
問一些很傻的問題，沒有問題是傻的，最關鍵的是社區里得有活躍度，即每天有很多人都會在上面問答交流，社區就很熱鬧，這樣很好。
團隊成員需要帶頭做貢獻，社區成員就能看到，然后其他一些社區成員或多或少做出點貢獻就可以引發更多的社區成員參與進來為社區做出貢獻。如果所有做貢獻都是團隊成員做的，而社區成員只管使用的話，那我認為這個社區做的不夠好，因為這樣就沒有交互，即一些人在干活而一些人在免費使用，如果項目變成這個樣子，未來這個項目維護就是有困難了，因為一定是眾人拾柴火焰高。點火的人是社區核心成員，他們把任務、把要做的事情、理念說清楚，然后提供一些最基礎的初級代碼，而更多的任務是靠眾人拾柴。大家都參與進來，你做一個測試，幫我挑個 Bug，我幫你改幾行代碼，寫一個視頻的導航，做一個推特(Twitter)的推廣，這樣越來越多人參與，才能把火燒旺燎原。
這點在有了區塊鏈或者加密貨幣后，社區建設比以前更容易了，比如，像(Meteor)這樣的社區，因為他沒有加密貨幣，大家做貢獻完全出于義務，也就是說我是相信這個Idea，覺得你(社區)做的是對的，然后我就愿意做貢獻，愿意花時間，比如跑中國來跟大家做分享，包括我參與翻譯(Meteor)這本書都是完全義務的，他們沒給我任何獎勵，除了送我幾件 T 恤。但是有了虛擬貨幣之后。情況就會好很多，比如 IPFS 這個項目對應的幣是文件幣(File Coin)，有了這些幣的話獎勵就容易多了。
因為社區里的人也是幣的持有者，他們從經濟利益考慮，也希望這個幣能夠增值。社區項目做得好，自己的財富也跟著增長。所以社區成員跟核心開發成員還有基金會、公司，大家形成了一個利益共識:共同把代表社區的幣做成高價值。在這種前提下，大家很容易把社區的事情做好。所以一旦達成這個共識，這個社區就會活躍發展。
這種新型的組織形式，叫 DCO (Decentralized Collaborative Organization) 意思是分散的有激勵機制的協作機構，這個跟公司的概念有比較大的不同。公司里有老板、有董事會、有股東、有員工，員工按馬克思的話講，就是被雇用出賣勞動力給資本家，資本家剝削剩余價值，這種情況下就有對立群體出現:資本家和工會，工會說我干活是掙錢，公司好不好，跟我壓根兒沒什么關系，公司好了，老板掙錢我也不多掙，公司不行了，換一家公司我接著打工。利益達不到共識，就出現了很多問題，或者出現很多管理的手段，出現了所謂的打卡上下班。這種絕對沒有人性的，屬于資產階級滴著血的管理方法，就屬于對大家的不信任。
資本家怕員工不好好干活，怕你偷懶，各種各樣的監督都來了，這都沒用，屬于奴隸制社會。現在的都叫 DCO，大家是共同的目的，所有的開發者，社區成員，不管你是拿工資、拿幣、啥都不拿的參與者，大家都共識，我們必須把這個社區搞好，把幣值弄上去。哪怕你手里有幣但不會做什么，你可以幫著吆喝，吸引更多韭菜們進來，也算是做貢獻。大家一旦達成這種共識了，那么干勁就足了，你用不著逼著人去做這做那的，大家干勁兒足著呢，給資本家干活跟給自己干活，那是完全不同的，所有人都覺得這個干活是對自己有利的，那自然就努力干活了。
所以在這種激勵機制下，形成共識，分布式分散式遠程辦公才可以成為現實，每個人的工作時間，實際上是更長了不是更短了。節約下來的通勤時間用于工作、甚至是睡覺、陪女朋友逛街，都比在路上擠著強，降低浪費，降低污染，同時提高工作效率又提高生活質量，皆大歡喜。另外關于異步團隊，以后亦來云在美國會有一個基地，建立一批人在美國跟中國協作，為了讓這些人能有機會在一起，有更多面對面的協作，我們可能會每年讓中國團隊到美國去輪換著工作一段時間，然后可能每年還會有一兩次，我們找一個地方環境優美的地方，大家來個 Retreatment，有一周時間互相交流討論。這是我們的計劃之一。
周洋: 要激勵社區取得成功，才能共同成功是吧?
Kevin: 對，激勵社區獲得成功才是共同成功，這是大家的共識。團隊成功，社區也成功，大家共同獲得利益。以亦來云為例，亦來云本身是一個(Operating System) 操作系統。他的成功取決于在上面運行的 DApp (Decentralized Application)，這些 DApp 成功了，我們才有價值，才有意義。那么要使它們有價值，就是社區要成功，社區成功才能讓我們的 ELA變好，所以大家是目的是一致的，要想達到這個目的，需要大家共同協作，共同獲益。這就是 DOC (Decentralized Collaboration Oranzation 去中心化協作組織) 的概念。
程序人生: 可不可以在社區把區塊鏈技術應用起來，比如 Token激勵?
Kevin: Token激勵我們目前還沒有想好怎么做，怎么把團隊的貢獻跟Token 放在一起。以及中國比較流行的 Airdrop(空投幣)，比如大家加群，就空投一些幣。即使純粹為了熱鬧，也是值得的，但更重要的是投給有貢獻的人，而不是說還不知道ELA三字母什么意思的人就分了一些幣。我覺得以后就把幣投給真正為社區做貢獻的人，給他們 Token 激勵。我相信以后在社區里，我們會大量的開展這樣的工作。但具體怎么做，我目前還沒想好，具體我們怎么計算這些Token 激勵，后面大家會知道。
周洋: Elastos 托管在 Github 上，使用 Github 有什么好建議? 什么是正確的姿勢?
Kevin: 有很多很多建議，一個建議是相對于傳統的軟件開發公司或者團隊而言，都有內部Repository 和外部 Repository，一定要把測試做完，才把完整的代碼向對外公開，經常一個版本搞仨月，然后一個 Push 過來又改了二十萬行代碼，這個不是社區的方式。社區的方式往往是在做的過程所有東西都是公開的，都是Work in Progress，而且有些事情社區可以參與進來。
而且在 Github 上，還要有 Community Friendly (社區友好) 意識，就是讓社區成員能夠更多參與進來。團隊的文檔要寫清楚，因為將來的開發者來自世界各地，大家都要用你寫的這部分東西來解決問題。所以對應的文檔、說明都是需要格外清楚的，讓別人能夠明白，這點十分十分重要，這就要看你的意識有沒有做到Community Friendly。
還有根據我自己的個人經驗，這個不見得有普遍性，就是關于代碼行注釋：代碼行里面做的注釋有沒有用？我知道很多人認為這個是好的、有用的，所以要求寫注釋在代碼行里。我的個人經驗，不太贊成這個做法。主要的原因是寫代碼的時候加的注釋的意思是對的，但是在隨后的開發過程之中，很容易發生缺陷，為了趕時間就把缺陷代碼改了，但是你真的會去改注釋嗎?
很多人在大多數情況下就是把代碼改了能跑就完事兒了，誰都不去關心這個注釋到底是不是已經過期了，我經常看自己的代碼和別人代碼都發現這個代碼和注釋壓根兒沒什么關系，注釋是可能的 4、5 年前寫的，代碼改了無數個版本，注釋卻沒人去動它。這種情況反而造成更多的麻煩，我試圖去理解這個代碼，看這注釋還更混亂，所以這個壞的結果比好的結果還要大。因此我不太建議寫注釋，除非真能保證你每次修改代碼時，還能把注釋一塊兒讀一下并進行需要更新。
那這個問題怎么解決?我的建議或者我們已經在實行的建議:在每次提交要小提交，不要一次提交一萬行代碼，這是很蠢的。你改了任何一個小的 Issue 都要去提交一次，而且這個提交的注釋里面要帶上 Issue 編號。Github 里面有個 Blame的功能，Blame 中文應該叫指責和譴責吧，但我覺得這個翻譯不是很準確。意思就是看到一段代碼，通過 Blame 就能找到這個代碼什么時候、被誰在哪次被提交的。Blame 的好處是知道當時是為了哪個 Issue 來提交代碼的。如果這個形成一條規矩的話，在未來程序員參與到開源社區，參與者能很容易理解你的代碼，知道你為什么要這么寫，當時解決什么問題。
(小編批注:Git 中的“Blame”特性描述了文件的每一行的最近一次修改信息，包括修改內容、作者和時間等;可用于追蹤某軟件新特性的添加及引起 Bug 的提交操作;)
要想實現這個有幾條關鍵點：
1. 每個Issue 十分清楚，不能太大或太小了，太小意義不大，一個Issue 五分鐘還不夠麻煩的，每個Issue 力度要合理，當然也有可能確實是很簡單，那就沒辦法。
2. 提交的注釋里面一定要帶 Issue 編號。我不允許或者不建議，開發者去提交沒有 Issue 的代碼。或是提交注釋里面寫:修復了一個缺陷。這跟沒說一樣，沒有任何幫助。一定要找得到出路，能夠跟蹤、能夠追查回去，代碼為什么改，要解決什么問題，這些是必要的。有這個要求了，我相信大家在寫代碼或者日后回頭再讀代碼時候，就有很大的幫助。
這是多年被自己和別人的代碼殘害的經驗集中，應該說是血的教訓，是這么多年總結出來的。我認為這樣的強制要求是有幫助的，雖然對于很多開發者來講還是挺難適應的一個過程，但是未來會體現到它的好處。你得到好處就會堅持下去的。
裕臣: 亦來云現在有開發者論壇嗎?
Kevin: 亦來云現在有開發者論壇，咱們這個就是其中一個，另外我們還會建立更多社區。我主要負責全球社區，所以主要關注英文這邊，Reddit 我們已經有賬號了，Medium 也已經有了，Youtube 頻道也很快會建立。另外呢，還有很多社區愛好者自己建立的跟亦來云相關的社區，我已經知道有一個Elastosjs.io 網站，未來還會有Elastosfan.com 或 Elastosfan.io，肯定會有更多交流社區。我希望在未來我們在 Google 里搜索 Elastos 的時候，我會看到無數個鏈接，來自于不同的國家和不同的人，不同的愛好者以自己的熱情來維護這個社區。
我剛剛加入亦來云社區，也算是對亦來云剛開始了解，我自己遇到了很多困難，我相信大家也都遇到過。亦來云是個很大的項目，它有好多子項目，我一開始到咱們 Github 上，看到很多各種各樣的 Project 我就沒明白他們的關系是什么，跟我們陳榕老師兄講的那個 Idea 怎么去一一對應。直到我上周在上海、這周在京跟開發者對面對面的交流，現在明白了。我覺得這方面我們還有點欠缺，因為以前可能沒有足夠的時間去做。
以前項目趕的比較緊，大家都沒有時間來維護這些東西或者沒有人督促這件事情，我希望把我的解決方案用在咱們社區里面。我會寫很大量的 Github 文檔，也會找一些人共同幫著來做。我們就先點個火吧，在這個社區里邊先找些熱情的人一塊做。我剛剛舉的都是英文的例子，當然中文也一樣都是同樣的做法，只是語言文字不一樣。我希望社區的人一起來參與，能夠分一些任務大家一起來做。
周洋: 我這最后一個問題，遠程工作需要什么樣的品質?社區喜歡什么樣的人?
Kevin: 首先關鍵是自我管理能力。說點題外話，我也在中國接受的教育，中國的教育跟西方有比較大的區別就是中國人對于自覺性的培養不是很夠，大家從小就被管著，很多東西都需要被管理才能干，一旦不管理就不知道該干什么了。這個跟西方社會是本質上是有區別的，以美國為例，你們要是在美國生活過就知道美國是一個十分去中心化的國家。
美國的州政府不歸聯邦政府管轄，市政府也不歸州政府管轄。大家全是在小范圍、小集體的運作，有自己不同的法律、自己去做決策。這個和中國的民主集中制是不一樣的。我只想說要能夠適合遠程工作的人要真正的會自我管理，一定要在沒人當面管理的情況下能夠自覺地完成任務。
要是一開始沒有自覺性或者管理能力不夠怎么辦?這個情況一定有，我們經歷過這事情有一定的經驗，有工具能干這事，像剛才提過的 Zoom 這個工具。我們的辦法也挺簡單粗暴，對與那些我們認為或者自己也覺得自己不能被管控的人，我們就要求他上班的時候需要打開視頻，因為我們希望能看見人，你也能看到你的同事在屏幕上，當你需要跟別人討論問題的時候，只需要在屏幕上點他一下跟他說話就行了。
這種工具的好處是雖然也沒有解決異步和同步的問題，但是它至少讓人們能夠感覺到自己還在集體里面工作，對工作不要太松懈，不會孤單的一個人工作，這個還是不錯的。IPFS 這個項目也是一樣的，一個屏幕打開就有二十幾張臉，干啥的都有，當你不能工作了、困了要睡覺了或者你現在想出去干點什么事兒，你就把它關了就行了，你也可以在日歷里標出來，然后大家都知道你不在了就不會再煩你。
我覺得社區喜歡的就是咱們在座的這些人，你們在社區里面提問、有貢獻，這是社區最喜歡的人。如果從開發者的角度來說我希望是有技術實力的開發者更多的加入社區來共同開發。因為亦來云這個項目是很大的，光靠咱們這三五十號人是很難做出來的，而且要做得好更難，一定需要大家眾人拾柴，需要有技術背景的人一塊兒參與。大家有錢的捧個錢場，有人捧個人場，能幫我們找點兒 Bug 也行，這些都是幫助。所以我們什么人都需要，只要大家共識、意識一致就沒問題，都歡迎。
程序人生: 去中心化區塊鏈技術和中心化 Web 技術如何結合?
Kevin: 這種結合我不知道你們有沒有過足夠溝通，我們有一個叫Elastos.NET(.Trinity) 的項目在 GitHub 上，我現在可以先簡單介紹一下，這是亦來云很核心的東西，它可以被認為是一個被修改、改造過的瀏覽器，它把 Chromium (Chrome 瀏覽器的內核)做為基礎，然后我們去掉了它跟外界直接網絡通訊的部分，然后取而代之的是我們的 Runtime 也就是 Elastos RT (作者補充: RT 是一個總的運行環境. 里面包含各種模塊，比如 Carrier，包括 Trinity 那個改造過的瀏覽器，直播的時候說的比較混淆，特此更正一下)
這樣的話 Web app 就不能直接的跳過 Runtime 去跟 Server 或者在外面的任何一個機構直接聯系，它只能去跟 Runtime 聯系。Runtime 提供的功能包括像 DID 這種去中心化的 ID 認證；包括像 Carrier 是點對點的加密通訊，很像是 Telegram、電驢或者迅雷這類的東西；還包括了跟 Token 有關的工具，才可以付錢、收錢；還包括了跟 IPFS 類似的存儲。總之，一個完整 DApp，它需要操作系統的支持，我們都把它放到里邊通過RT的這種Car遠程調用的方式把它結合在瀏覽器里面。
那么對于開發 Dapp 的人來講，用Java Script 即可，用你熟悉的比如 React，Angular， VUE.js都可以，然后我們給你提供一個Javascript 的Object。你通過對這個Object 的調用就能實現支付、點對點的數據傳輸、音頻傳輸、視頻傳輸、用戶認證等等，這些都是不需要中心化服務器的后臺支撐，這些所有功能都集成在里面。那么對于Dapp 開發者而言，你們就有了一種全新開發 DApp的方式。
傳統的 DApp 開發方式，比如以太坊用 Solidity 開發智能合約，用Web3.js 做連接橋，然后從 Web 去調用的這種方式，我現在認為已經是傳統方式了，雖然才兩年。跟咱們在 Elastos 提供的方式就有本質的區別了，因為在我們的瀏覽器內核里跑Web或Dweb的話，它是被安全沙箱隔離，我們禁止你訪問一些外部的東西，因為都通過我們這個沙箱來管理的話能夠大大提高你App 的安全性。一個方面是避免 App 被外部感染。另一方面呢，也防止 App 被壞人利用了去影響別人，比如發起 DDOS 攻擊，陳老大以前演講經常會他提到這個概念就是沙箱和 DDOS攻擊，來避免發生 DDOS 攻擊的情況。
由于是個封閉的沙箱環境它還可以比較容易實現版權確權認證。舉個例子，未來你可以在線發布付費觀看的電影、視頻節目。由于是在沙箱里面，所以你就沒有辦法是把它解密導成一個 Mp4 文件然后去盜版，因為它拿不出來。當然如果對著屏幕拍我管不了，就是說從我們這個系統這邊我們做到這一點，所有的播放都是需要付費 ELA 來觀看，這樣的話可以解決盜版的問題，這就是一個例子。
另外由于我們這個沙箱的 App 之間是點對點加密通訊，比如說我們要開發像Telegram 這樣的 DApp，我們在兩個點之間的傳輸是可以穿越防火墻、可以直接發現、可以加密傳輸不會被截獲或者是翻譯的，提高了數據的安全性，你可以把你的私鑰從一個點傳輸到另外一個點中間不會被截獲。這個在以前的通訊，包括微信、Telegram 都不能保證，但是我們可以保證。我只是舉了一兩個例子，后面還有很多。
還有 DID， DID 就是一個去中心化的一個 ID 認證系統，以前我們的 ID 認證，比如你用微信認證、用新浪認證、用 Google 認證，都需要去中心化服務器去驗證，他如果服務器倒了你這邊就通過不了。DID 不需要，DID 完全是分散的。總之，一句簡單的話講，Elastos 給 DApp 開發提供了一個新的、前所未有的、簡單和安全可靠的操作系統。
對于開發者而言不再需要去研究很多底層的區塊鏈技術，對于普通開發者只是想做一個 Application 而已，還逼著我去搞清楚橢圓曲線算法，實際上真是不需要。你不需要搞這種東西因為 Elastos RT 都搞好了，你就老老實實地寫你的 DApp，用Javascript 用自己熟悉的開發框架來做就完了，你的 App 就可以跑在我們亦來云的操作系統上，為你的客戶提供服務，我們大家共榮，就是這么一個概念。這個是我簡短的、對于 Elastos 的這個操系統和 RT 的一個介紹。
我再補充一下剛剛那個話題，剛才那個問題是如何結合去中心化和 Web 結合?我們除了提供這個以外，我們還可以另外一個選擇，在 Github 有一個叫Elastos.NET.Carrier.Nodejs.SDK，這個項目是上禮拜五在上海建立的，它是給Carrier 來做 NodeJS 的一個包，來給借鑒 Nodejs 寫Server 的人用的，它可以認為是上面這種完全沙箱之外，提供了一個半隔離半去中心化的這么一個臨時解決方案。
它的目標是讓傳統應用與區塊鏈結合，比如說你已經有 B/S 結構的應用，也想利用區塊鏈的這個技術來做一些事情，比如支付等等。但是如果我告訴你這個App需要重寫放到 Elastos 里，就會覺得還挺難的，并且這個過度成本有點太高。那么我給你提供Nodejs 這個方案，代碼不用改，加一個Object 加一個庫就行了，然后你就實現了部分 RT 的功能。
今后希望社區來共同建設，我只是有了想法起了個頭，現在美國有幾個朋友已經開始往里貢獻了，你們如果有興趣可以一塊兒參與貢獻。這貢獻除了貢獻核心代碼以外也包括你可以在上面開發幾個 Hello world，如果它能跑就可以把代碼加進去，我們是一個去中心化的協作系統，所有東西都是 Open 的，同時也歡迎各種各樣的應用。
程序人生: 現在能上應用了嗎?
Kevin: 我覺得 Elastos 的開發進度夠快了，但是目前還沒有到已經Ready 的程度，不光是文檔沒到位，代碼也還有些沒有完成的地方，包括整個框架也有些東西。我估計應該在幾個月之內就有應用開發了。我希望大家多關注，希望你們做的應用能放上來，我們會把它掛在 Github 上，全部歡迎。
之后計劃在清華搞一個黑客大賽，也是鼓勵大家用 Elastos 開發一些小東西。上個月在硅谷我們也搞了一個生態大會，像快牙、熊貓綠能等幾家公司，都會來Elastos 上開發，無論是企業還是個人，我們也都歡迎，大家一起往社區里添磚加瓦，我很希望你們每天都能在 Github 上給我提 Issue，我會很高興的，就證明我沒白費口舌講這些東西。
程序人生: 將來會有 Java SDK 開發包嗎?
Kevin: 我們現在有安卓的開發包是Java 的，在 Elastos Github 上的命名規則大家可以很容易看得到是 Elastos 開頭，后面是.net 就是跟通訊有關的，再后面的是操作系統，比如.Android 和 .IOS，然后再是.SDK。所以按照這個命名規則你可以看到Elastos.Net.Carrier.Android.SDK，看到這個名字你就能明白它是 Elastos 這個項目里邊跟通訊有關的，而且是 Carrier 這個 Project，然后是.Android 的，所以這個操作系統是在安卓上跑的，然后再是.SDK，說明它是 SDK。所以“程序人生”的問題說將來會有 JAVA SDK 開發包嗎?Yes！我們現在就有，但只是 Carrier這一個子項目，我們其他的項目陸續都會把開發包放出來，所以你現在就可以先試一下 Carrier ，這是剛出來的，可以體驗一下。
最后，我再說一下現在社區人怎么貢獻?
我現在建議，你們每天去看看咱們的Github，試圖編譯使用一下我們這個產品，如果能在上面開發軟件嘗試下最好。我相信你們會遇到一些困難，就像我剛才講的我們現在還做得不夠好。我希望各位把自己的問題，用 Github Issue 提出來，我們去針對性的進行解決，這樣就有社區開發者和核心開發者的交互。我們把這些問題都解決了，大家用起來就方便了，或者說你自己發現了一些使用的小技巧，也可以用 Issue 的方式提建議。這就是大家對這個社區目前可以做的貢獻，未來可以做更多的貢獻。這就是我今天講的這個目的。謝謝大家!
