本文早些时候发表在 weexteam 的博客 https://github.com/weexteam/article/issues/73
仅从我个人角度跟大家分享一下自己参与 Weex 开源这几个月以来的感受，中间可能会有写观点是偏颇的或者片面的，希望大家指正，另外不论怎样，这些都是我心里真实的想法和感受。
有两个关键字：加速、共赢
我们提出来要开源的时候，在网上被很多人质疑过。有人质疑说这是个“KPI项目”，作者折腾完要“弃坑”了，所以就把它开源了；也有人质疑它的成色，也有人质疑“电商”的标签，是不是只有你们阿里用得到，别人都不太用得到。
我觉得开源最大的意义在于找到志同道合的人做出更伟大的事情，如果我们只是为了“弃坑”，那显然在4个月之前我们的工作就完成了，也不会有接下来的研发迭代、宣传、开发者服务和社区经营——最起码我自己从 Weex 还没有开源甚至还没有这个名字的时候就参与其中，一直参与到现在。我喜欢这个项目，也愿意接受这个项目带给我的各种刺激和挑战，他一直让我不断进步，有满满的收获。
话说回来，我确实看到很多社区的开源项目，自己厂的、友商的、个人的，确实有“弃坑”的意味，感觉源代码丢到 github 就没事了。我觉得这种开源不是没有价值，但价值是约等于 0 的。这段时间关注奥运会，也一下子想起奥林匹克之父顾拜旦老人家的一句名言：“生活的本质不在于索取，而在于奋斗！”我觉得这句话在开源社区更是如此。把代码开源出去然后撒手不管等着别人来捡，这实际上是索取，是没有意义的。关注开源项目的开发者表面上是索取，但是开发者提交的每一个 pull request、每一条 issue、甚至每一句评论和吐槽，也是在为项目做贡献。作为开源项目的参与者或作者，一定要在这方面有一个健康的心态，才能真正做出好的项目。
我还记得自己 2010 年参加 WebRebuild 交流会的时候，蒋定宇 的分享 让我印象深刻，他其中一句话我到今天还记得：
“最好的 solution 是讨论出来的”
所以如果想做出优秀的开源项目，除了摆正自己的心态，还要有一颗和别人 (甚至竞争对手和讨厌你的人) 一起共赢的心。尽可能团结一切可以团结的力量。让这个项目变得更好！
团队内部从去年双十一之后宣布开源计划，到从4月份 QCon 开始邀请开发者陆续参与进来，再到6月底正式全面开源，一共经历了大概了大半年的时间。团队是把 Weex 开源这件事情当做一个工程来认真对待的，这里可以跟大家分享一些我们背后做的准备工作：
这是集团很早就定下来的规矩，我理解这件事情更大程度上是“怕出事”，不要不小心把不该公开的信息公开出去导致集团不必要的商业损失。我觉得这理所当然，同时这只是个最低要求。
当然集团今天对待开源已经不是“怕出事”这么简单了，我自己能够感觉到，集团新成立的开源委员会，除了通过这个流程帮助开发者打消不必要的顾虑之外，更多的希望我们能够通过开源的方式让一件事加速和共赢。这是我参与 Weex 开源过程中明显感受到和之前不一样的地方。
除了上面的“硬性”准备工作之外，对 Weex 团队更大的挑战在于工作方式的转变。在阿里有句土话，“能电话不邮件”，讲求的是密切沟通、快速响应，阿里的很多团队也是因此具有其他团队不曾想象的做事决心和执行力。在开源社区，面对海量的开发者一起参与，还要做好开发者服务，这种工作方式是不合适的。我们需要大量依赖线上的、异步的、远程的、开放的工作模式。
在团队内部，我们有意识的把所有的工作讨论和任务安排，能公开出来的，就全部公开在 github issue 里。随着团队成员的增多，我们的团队有杭州、北京、广州的，大家分散办公，然后在线上沟通，把不需要当面或同步沟通的工作大方的区分出来。表面上看，异步沟通增加了团队的沟通成本，但实际上，异步沟通让能够参与进来的人变多了，而且不仅限于杭州的某一个办公区或会议室的人，彼此也可以更自在灵活的安排自己的工作和行程。这给了项目组很多想象和发挥的空间。
甚至不只是 Weex 这个项目，我希望集团层面都可以更多的尝试远程协作和异步沟通，这是一种有魔力的体验。
在筹备期间，我有幸和集团的几位开源的前辈聊到过我们的开源设想，印象最深刻的一个问题就是：
“你是否确定，如果有一天你的 KPI 里没有这个项目了，甚至你有一天不在阿里工作了，你会发自内心的去投入和维护它吗？”
我听完觉得前辈把话说到我们心坎儿里了。项目组核心团队里的每一个人，是把 Weex 简单当一份工作，还是发自内心的认同，做出来的东西我相信是完全不一样的。你会全职参与到一个项目里，还是兼职，有的时候兼职的效果更好，更健康。尤其是当我们从长计议的时候，对这几方面更加有感触。我们有大量的已经开源的项目，更新频度是大于半年的。这样的项目出发点都是很好的，但是结果很可惜。
我们在后期组建团队让更多人参与进来的时候特别思考了这个问题，今天在集团内部，Weex 的很多东西都是业务的同学在帮忙打理的。从项目组的角度，工作压力得到了分担和缓解；从个人的角度，在支持业务的同时，能够把一些比较解耦的工作拿来业余时间独自承担，松散的参与一些技术讨论，有自己的收获。这是两全其美的事情。
另外团队的既定工作安排是非饱和的，我们鼓励团员主动寻找值得参与和付出的地方，把项目的方方面面打理好，毕竟项目是完全对外的嘛，要“出去见人”总得把自己“打扮的漂漂亮亮的”。这是每个人都会有的心态。坦白讲这方面我们还不算做得特别好。所以有很多工作要继续做，也有很多空间给到团队。
我们主动联系了很多和 Weex 有共同志向或相关联的团队和事业部，大家在不同的角度能够看到更多不同层次的问题，也有各自擅长的领域和空间。我们希望在 Weex 项目组之外，把一个围绕着 Weex 的生态建立起来，他会让 Weex 变得更丰富饱满，更有意义，更有价值。
今天在阿里，Weex 杭州的团队已经只是参与 Weex 的所有人中一小部分了，不同的业务方，不同的技术层次上，都有不同的小伙伴在参与。
经过两个多月的筹备，我们于6月30日晚把项目正式开源了，我们在微博上做了个简单的宣传，但实际上团队当时内部压力是蛮大的，大家都很辛苦，所以我们搞了个小的 party，煞有介事的搬来一个“重大决策按钮”，很有仪式感的让大家一起把这个按钮按下去，把项目开源出来，尽量把这个过程搞得轻松愉悦一点。
开源之前大概就是这样，团队紧接着要面对的，是开源之后的漫长之路。
我总结的开源社区经营就是一个“帽子戏法”的过程，就像开淘宝店是一样的，有三顶帽子你需要轮流得把他带到自己头上：
如果你要开店，那么你首先需要备货，拥有用户满意的商品；然后找入口买流量，让别人看到你的商品；用户发现你的商品之后，你要有很好的承接和售后服务；等到商品卖出去了，用户肯定会给你沟通、评价和建议，这会作为你拥有更好商品的筹码。每个环节之间都是紧密联系的，哪个做得不够平衡都会很痛苦。
做开源项目也是一样，首先你要做出好的技术产品；然后通过各种技术宣讲机会介绍给别人；当开发者来到项目的首页或 github 仓库时，要做好服务，帮助开发者解答参与过程中的疑惑；然后在这个过程中收集到用户的反馈和意见再做产品的迭代改进。
包括4月份我们参与的 QCon 北京在内，团队先后参加了大大小小的很多场技术交流分享活动，同时在线上我们也在陆续写一些介绍 Weex 的技术文章，在宣传 Weex 的技术设想和理念的同时，也鼓励开发者更多的参与进来。
现在回想起来，最早接触开发者的时候，团队对自己还是太过自信了，心想我们一起研发并且准备了这么久，开发者过来看过一定觉得很厉害。没想到遇到了大家的各种挑战。而且被问到最多的问题是完全没有想到的：
“怎么让程序跑起来？”
然后就发现了一堆问题：比如 Windows 环境下的命令行问题、路径分隔符问题、Node 版本问题、Android 环境翻墙的问题、npm/cocoapods 镜像的问题、NDK 的问题、x86 模拟器的问题等等……
这里面有些是团队自己知道的，只是觉得太顺理成章了，没觉得应该写清楚，结果就让开发者们误解了；有些确实是自己的工作环境很单一，而社区里开发者们的工作环境是千差万别的；还有些是交代得不够清楚，明明知道也写了，但是没能让开发者很好的充分理解。
后来我才留意到技术社区里一个流传很久的笑话：
“所有的开源软件都有一个特点：根据官方文档的步骤是跑不起来的。”
原来 Landing Page、README 和 文档这么重要，这给了团队当头一棒，大家认为最简单的问题都折腾得很狼狈。看起来搞开源真的“不是你一片赤诚就能够面对的”
最早期我们和开发者所有的沟通基本都是通过 github issues 来进行的，这也蛮正常的，看人家开源项目都在 issues 上讨论的火热，好有气氛好羡慕，巴不得有人在我们自己的 issues 上多聊个两句，哪怕是闲聊，总比冷冷清清无人问津的好。
后来发现完全不是我们想象的那样，我们真的是想多了，实际情况是各种 issue 洪水猛兽版袭来，大家的 github 账号默认都是可以收到每个 issue 的邮件提醒的，然后瞬间邮箱就被炸瘫痪了，正常的研发迭代也被应付这些 issue 变得支离破碎。
后来我们发现其实 issue 其实并不都适合处理所有的问题，有些使用上的小问题，在 issue 上几个来回讨论清楚，一个小时甚至一上午就这样过去了。而且问题多了之后，把 issues 上正常的工作内容讨论和安排都给淹没了。
这个时候就有非常热心的开发者帮我们建立了 QQ 群、微信群等社区，这种沟通方式更直接简单，回合更快，开发者遇到一个编译不通过的问题，问题抛出来在线等个几分钟就有人帮忙回应了。这样 github issues 的压力暂时得到了缓解。
后来经过几个同学的调研，我们最终把疑难杂症的解答和及时的线上讨论放到了 gitter 上，把需要跟进的事项、发现的 bug、值得追踪探讨的话题留在了 github issues 里。这样差不多是今天团队和社区开发者们协作的最终方式了。
我们根据开发者的参与度划分了几个维度：随便看看、试一试、用起来、交流互动、参与贡献。背后的需求和服务方式应该是不一样的
随着 Weex 社区参与者的增多，我们也不需要鼓励大家有事没事写个 issue 打肿脸充胖子了，而是比较自然而合理的做各种事情。我们看到两个很好的势头：
一个是开发者在 issues 里参与了很多基于 proposal 的新功能讨论，之前团队在迭代新功能的时候是自行设计排期研发实现的，逐渐的，我们把整个技术设计的过程也透明出来并且有意识的在这个阶段放慢节奏，让这个功能经过足够充分的讨论之后，再付诸实现；
另一个是很多开发者开始在集团内网和 github articles 下写了越来越多对 Weex 的理解和相关讨论，很多文章团队自己看完都私下表示开发者们写得比我自己写得都好 [偷笑]，这也让团队的每一个人更受鼓舞，也更愿意跟社区分享自己的想法和真知灼见。
这两方面不论哪一方面，对 Weex 社区来说都是很好的迹象，也都一定程度鼓舞了 Weex 团队本身做得更好！
就像开源之后第一段提到的，Weex 团队除了宣传和服务开发者之外，还在保持有条不紊的版本迭代。去年 Weex 初期启动的时候，是一个7人左右的团队，通过不那么标准的 Scrum 的敏捷方式快速迭代。双十一过后，团队的规模扩大了，同时也有了非常专业的项目经理为团队保驾护航。我们基本保持着每个月一次迭代，每两个迭代发布一个版本的节奏，所以我们于5月份发布了0.5版本，7月份发布了0.6版本。
从0.7版本开始，随着团队默契度的提升，再加上整个社区逐步成型，也通过 proposal 讨论等机会给了团队很多回馈，我们加快了迭代频率，现在每个月都会完成一个新的版本，所以本月初我们发布了0.7版本。目前0.8版本也已经启动，正在紧锣密鼓的迭代过程中。
同时今年的双十一也要邻近了，团队针对今年双十一提出了更高的目标，具体内容这里不详细提及了，先卖个关子，请大家拭目以待。
今天，Weex 在近4个月的开源之路后，累计了5000+个star，并且保持着比较高的迭代速度和社区活跃度。我们在欣喜的同时，更多的是感恩，觉得自己应该对得起大家的这份关注和信任，继续做出更好的产品给大家。除了之前提到的各方面细节和感触，将来我们还有很多地方值得改进
借近期参加开源中国源创汇和JSConf的活动，也给了我一个机会从开源经历的角度重新审视了一些自己和团队做的事情。同时 Weex 在 github 的 star 也即将迈过 6000 大关，有一些感触，分享给大家。未来我们会继续努力，用自己的实际行动。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。