如何打造国际开发者社区(如何打造国际开发者社团)

随着很多网友们针对于如何打造国际开发者社区关注越来越多，小编通过花费九牛二虎之力，终于整理出来相关问题的信息。

周洋: 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 是一个人来负责，而不是多个人。