周洋: 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 的方式提建议。这就是大家对这个社区目前可以做的贡献，未来可以做更多的贡献。这就是我今天讲的这个目的。谢谢大家!
