GitHuber.info 团队出品
前言
不知道从什么时候开始，GitHub 成为了潮流，没有个把 Star 上街都不好意思和人打招呼。由于做了 GitHuber.info，我们有机会接触到很多 GitHub 的数据，加上@Python 爱好者 的建议，的建议，我们决定自己抓取、分析数据，做一个报告出来，让大家对中国开发者在 GitHub 上的现状有更具体的了解。
目前 GitHub 上的注册用户数量已经超过 1000 万，为了准确我们抓取了所有用户的个人信息并从中筛选出了所有中国开发者、中国组织和美国开发者、美国组织，然后抓取了他们所有的公开项目信息进行分析。
报告的内容分为三个部分，第一部分是中国开发者的现状，第二部分是中美开发者的对比，第三部分是国内优秀开源项目作者的采访。
第一部分从个人信息、项目信息和组织信息三个方面对中国开发者进行了统计，由于数据量是大长尾，我们将相似的区间进行了合并，让图的可读性更高。
第二部分同样从个人信息、项目信息和组织信息三个方面对中美开发者进行了对比，希望借此让大家更了解我们和美国开发者之间的异同。
第三部分我们采访了几个国内优秀开源项目的作者，我们有意选择了不同类型的项目，从而可以展示不同的开源项目发展路线，让不同类型的开发者都能有所收获。目前国内的开源环境还处于发展期，仍有很多方面需要探索，希望借此抛砖引玉让大家深入思考开源。
由于我们是第一次做这样的报告，加上一些时间、设备方面的限制，并没有做出我们期望的所有报告内容和展示效果。不过从题目就可以看出来，这个报告我 们会一直做下去。失败的事情太多了，也不差我们这一件。不过万一成功了呢，万一为大家带来一些价值呢？想做的事情还是要去试一试的。
这是 1.0 版，之后我们还会根据大家的反馈不断完善和更新内容，因此我们非常希望大家能提出各种意见和建议，微信微博邮件网站，想用哪个都可以，我们会全部记录下来。
非常感谢栾俊清和夏天晗，作为 GitHuber.info 团队的一员，大家为这份报告付出了太多；感谢所有接受采访的作者，在百忙之中抽出时间来耐心回答我们一连串的提问；感谢各位顾问，为这份报告提出了很多有 用的建议——虽然并不是每个人都会发声，但是即使作为观众，也给我们带来了无尽动力；感谢何斌协助挖掘数据；最后，还要感谢看报告的每一个你，报告本身毫 无价值，是你们的注视给它注入能量，让它能够发光，谢谢你们，谢谢大家！
梁杰
2015. 1.29
中国开发者数据统计
个人信息
从上下两幅图中可以看出中国区程序员的活跃时段，右侧的图例是 GitHub 的各个事件，最高的灰色是 Push，次高的橘黄色是 Watch。可以看出，每周六的活跃度最低，周日的活跃度比周五还高。每天的活跃度有三个高峰：上午、晚上和半夜，半夜的最高，可见大家都是夜猫子。
polyrabbit 用过 129 种语言，原因是他的项目 polyglot 中包含一个编程语言的语料库，其中收集了各种语言的代码段。
由于项目中可能包含第三方库，所以统计出的语言数会稍大于实际使用的语言数。不过即便如此，还是有很多人掌握多门语言。
之所以使用字节而不是行数，是因为从 GitHub 的 API 拿到的就是字节。此外，我们也认为字节比行数更精确一些。
可以看出绝大多数开发者的总代码量集中在 10 万~100 万字节这个区间，可以在这里统计一下你的代码量，看看处于哪个区间。
去 Fork 和不去 Fork 的差别非常之大，去掉 Fork 之后基本上数量都会下降一个数量级，可见大家非常喜欢 Fork。在我们的理解中，Fork 就表示你想要给项目提交代码，如果只是关注的话 Star 就完全够用了，Fork 过来项目还会干扰查看自己项目。
Fork 最多的那个朋友有 8000 多个项目，很难想象打开自己项目列表的时候是一种什么体验，大家可以去体验一下。
绝大多数开发者的粉丝数都没有超过 10 个，超过 1000 个粉丝的开发者极其少见。事实证明，互粉最多只能走到第三个区间，到第四个区间必须要有优秀的开源项目，GitHub 是一个靠代码说话的地方。
Star 数的统计显示大多数开发者的 Star 数都在 500 以内。Star 就像收藏夹，内容太多反而会影响使用。目前已经有了一些不错的 Star 项目管理工具，比如 oh my star，可以借助这些工具充分发挥 Star 的价值。
关注的价值在哪里？似乎是可以看看大神们每天都在做什么。不过 GitHub 作为一个程序员的社交平台，在交互方面似乎还是稍重了一些，并不能像微博那样易用，用 GitHub 的 API 实现一个移动版是个不错的选择。
项目信息
单个项目的代码量大多集中在 1 万到 10 万字节这个区间， 前端项目大多短小精悍，或许与此有关。之后我们会统计不同语言的项目代码量分布，看看各个语言的繁琐程度。
分⽀⽅面，⼤量的项目都在 3 个以下，这反映出⼤部分项目还是纯个人开发，并没有达到需要规范分支的程度。随着项目的不断膨胀，分⽀的管理也会变成很重要的⼀环。
PR 和 Issue 的分布并不意外，90% 的项目几乎没有 PR 和 Issue。在采访李成银的时候我们也讨论过这个问题，反馈对一个开源项目来说非常重要，即使没有能力提 PR，也可以尽量提 Issue，让项目越走越好。
| 项目 | Star 数 |
| vinta/awesome-python | 9083 |
| numbbbbb/the-swift-programming-language-in-chinese | 8078 |
| julycoding/The-Art-Of-Programming-By-July | 5500 |
| astaxie/build-web-application-with-golang | 5452 |
| Trinea/android-open-project | 5408 |
| justjavac/free-programming-books-zh_CN | 4749 |
| tommoor/tinycon | 4231 |
| astaxie/beego | 3678 |
| greatfire/wiki | 3677 |
| binux/pyspider | 3602 |
组织信息
组织部分总体的分布趋势和项目很类似，不过各项统计按比例来算要比项目信息稍差一些。按理说组织中的项目应该更容易吸引成员参与，从而在 PR、Issue 上有更好的表现。反过来说，目前中国的组织并没有充分发挥组织的作用，对开源项目的发展推动不大。目前国内的优秀开源项目主要还是依靠线下团队的合作开 发，距离美国开源项目的众包模式还有些差距。
| 项目 | Star 数 |
| ecomfe/ECharts | 5240 |
| haiwen/seafile | 2625 |
| fastos/fastsocket | 2558 |
| railsbp/rails_best_practices | 2545 |
| alibaba/tengine | 2429 |
| cNode.js/nodeclub | 2226 |
| nomad/cupertino | 2166 |
| allmobilize/amazeui | 2140 |
| springside/springside4 | 2087 |
| nomad/shenzhen | 2038 |
#p#
中美开发者对比
个人对比
图中左侧图例由上至下的顺序就是语言的排名，饼图中顺时针方向也是语言的排名。
可以看出 JavaScript 和 CSS 占绝对优势，两者加起来接近 1/3。中美差别比较大的是 Java 和 Ruby，这两个语言的排名几乎完全对称。作为国内的大热门 Java 排在前面并不奇怪，但是另一个大热门 PHP 却并不靠前，甚至还比美国区的 PHP 使用率低，似乎国内的 PHP 爱好者们并不太热衷于开源。
右侧是中美个人统计的对比，第一张和第三张图中美的分布非常相似，第二张和第四张图中稍有差别，在第一个区间中国的比例要小于美国，其他区间中国的比例要大于美国。
第一个区间是不活跃的用户，可以看出美国的不活跃用户比例比中国大。从第二个区间开始是活跃用户，中国的比例大于美国。
之所以会出现这样的情况，主要是因为美国开发者的数量很大。我们过滤出的中国开发者约 6 万 7 千人，而美国开发者有约 36 万人，在这种情况下，美国有更大比例的不活跃用户也可以理解，量的上升往往带来质的下降，希望在总量相当的时候我们仍能在比例上领先。
项目对比
左侧是中美项目统计的对比，可以看到三张图的对比结果非常类似：在第一个区间中国的比例大于美国，其他区间中国的比例往往远小于美国。
后几张图中的对比结果表示美国的活跃项目量全面大于中国，从第二个区间开始美国的比例最多可以达到中国的三倍，这意味着绝对数量的比例在十倍以上。
总体来说，个人信息的对比上美国稍弱于中国，但是项目对比上要强于中国，说明美国的活跃用户其活跃度确实比中国高很多。
代码量的对比比较特别。我们统计到的中国区项目量大约是 22 万，美国区项目量大约是 100 万，也就是说美国的绝大多数代码都集中在第二和第三个区间，其数量远大于中国。
从分支数来看，美国和中国的对比相差不多。不过相比之下分支数量更加集中在第二个区间。前面我们说过量的上升往往会导致质的下降，从这个角度来说，目前我们的量和质都处在劣势，还需要不断发展。
组织对比
组织的对比我们稍有劣势。我们统计出 2500 个中国区组织和约 25000 个美国区组织，也就是说美国的组织数是中国的十倍。人数是中国的四倍，组织数却达到了十倍，组织的各项指标也要强于中国，可见美国区的组织整体形式很好。
各项平均值对比
#p#
国内优秀开源项目作者采访
G：介绍一下你自己吧。
林峰：林峰，开源中国 @Kener-林峰，GitHub @kener ，微博 @Kener-林峰，百度商业前端通用技术组，数据可视化方向负责人，资深前端研发工程师。喜欢设计，热爱编程，ZRender，ECharts 作者，目前专注于数据可视化方面的研究工作。
G：能否简单介绍一下 ECharts 以及它的应用场景？
林峰：数据可视化产品有很多，ECharts 定位在满足可复用的商业数据可视化需求，与业界已有的 Highcharts、FusionCharts 同级别的产品，当然他们都是成熟的商业收费产品，我们免费开源了，才起步，完善程度还有不小的差距。但不谦虚的说，ECharts 高度个性化和交互能力在不少方面已经成为了业界领先，拖拽重计算、大规模散点图获得了国家专利，数据视图、值域漫游、子地图模式也都是业界首创，独有的功 能。至于应用场景就比较广了，不同行业都有各种需求。互联网就不用多说，报表系统、运维系统、网站展示，只要有数据展现的需求基本都能使用。像传媒，数据 新闻在近几年也被越来越多的提及，财新网走得很前，他们是最早使用 ECharts 作为数据新闻的可视化工具。各行各业其实都有营销展示、企业品牌宣传、运营收入的汇报分析等各种各样的应用场景，不管大数据是否被过渡热炒，数据确实已经 成为很多企业最受重视的财富之一，有数据的地方基本都会有这方面的需求。
G：最初是怎么想到开发 ECharts 的呢？
林峰：我进入百度的时候被分配到一个对公司举足轻重的产品：凤巢系统。2 年多的摸爬滚打从菜鸟变成了高级菜鸟，成了凤巢前端的技术负责人，整天跟各种数据打交道，开始知道了数据的价值和力量，那是 2012 年末，大数据这名词才刚刚浮出水面，数据可视化更是（至少在国内）未被流传，乔帮主不让i系列上运行 Flash 加上 HTML5 开始火热，我们需要寻求一个解决方案，用于凤巢系统数据报表的可视化展现，用于对凤巢系统用户体验监控数据的可视化展现等等，编程+设计+数据的结合的仿 佛为自己量身定制，于是就转向了数据可视化的研究。百度前端领袖人物 Erik 回归后组建了商业前端的通用技术组，特意的规划出数据可视化方向，我也就顺理成章的从凤巢技术负责人的角色转到现在的角色，然后就挖了一个很深很深的坑 （ECharts 的功能设计），之后近 1 年的时间里就开始与团队一起一点点的填上这个坑。
G：ECharts 发展到现在，俨然成为国产最佳开源项目，大家一定都很好奇 ECharts 是如何走到今天的，能聊聊这个过程吗，有哪些你印象深刻的事件呢？
林峰：最佳不敢当，只是一直在认真的做一件自己感兴趣，对公司也对领域有价值的事情而已。这是 ECharts 的第 19 个月，每天习惯性的看看 ECharts 的 Star 数，每到整百的时刻就记录一下仿佛已经融入到生活里。感谢领导们的信任让我们团队大多都可以随心所欲的工作，我们不用担心查岗，没事出去参加个交流甚至跑 去看个展览熏陶一下啦，喜欢的话在咖啡厅呆上一天也都可以。这种信任给予的自由并没有减少工作时间或降低效率，我相信我们团队的小伙伴们都早已习惯了随时 随地工作（餐厅、地铁、机场甚至医院），关键的是大家也愿意自发的工作，或许这也是造就 ECharts 很多天马行空的 feature 诞生的因素，已经数不清有多少个大晚上 hi 里突然蹦出小伙伴创造的杰作（我们早已穷尽了相互吹 NB 拍马屁的词语了），也忘记了自己多少回半夜突发灵感爬起来敲代码了。编程本身就是一件创造性的工作，更不用说我们做到还是一件与艺术结合的事情，如果你并 不真正喜欢，只把他作为朝九晚五的差事，你也就不会有创造力了。
很感谢陪伴 ECharts 一路走来的各位，沈毅，祖明，董睿，宿爽，红启，杨骥，叮叮，黄悦，同兵，太云，周扬，世威，胡瑶，德城师兄，李湛总，志敏总，陈为老师等等，当然，可能 还包括您。所有印象深刻的事件也都与你们有关，ECharts 1.1.0 发布微博是我们第一条转发过 500 的微博（还好没被抓）。1.3 后我们被誉为“可视化领域的后起之秀”出现在各大主流技术媒体上，拿下了当年中国 10 大热门开源项目。1.4 后已经有了三种不同编程语言的 ECharts 版本，Why ECharts 的分享在R语言，数据库等大会上出现。2.0 前夕我们在公司各大电子屏上面放了“比 ECharts 更好用的图表即将出现”的宣传海报引来很多关心我们的朋友“声援”，一个不大不小的惊喜，2.0 发布我们刷了微信几乎所有与大数据相关的大V公众号头条，这是我们对自己发起的挑战和超越。2014 年 6 月 30 我们为 ECharts 办了第一个生日会，从此有了小鲸鱼的形象。2.0 后我们团队基于 ECharts 的应用百度图说上线开始公测。北京、上海、广州、杭州、武汉、哈尔滨、西安，各种活动，各种公司，已经数不清做过多少次分享了。我们还带着小鲸鱼去了硅谷 让美帝同学知道我们的厉害，我们去了广州，在酒店里我们通宵的准备了第二天的分享，还把图说正式发布了，让我们高兴的是活动第二天上了广州日报的头条。 2.1.8 ECharts 的英文官网终于上线也开启了我们国际化的征程，成为了中国第一个也是目前唯一一个入选了 GitHub Explorer Data Visualization 板块的开源项目，短短 2 个月后 Jaroslav Benc 带来了 Datamatic ECharts edition （英文版的图说）让我们倍感压力，老外（此处为尊称）程序员太 NB 了！登录 GitHub 热门榜单，star 破 5000，百度人气、知识图谱、世界杯等合作项目的上线等等，回想起来历历在目，有太多值得纪念的时刻，感谢有你。
G：ECharts 目前还面临哪些问题呢，未来有什么发展计划吗？
林峰：对我们自己项目升级和维护来说，代码体积，特性功能耦合在主模块里是最大的问题，要进一步的打散，更细粒度的拆分，提供动态、按需组装的能力。
对开发者项目开发来说，更详细友好的文档，帮助，我想我该做些教程了（已经计划半年了...)。
对图表阅读使用方来说，移动设备优化，艺术美感的提高，大数据性能响应。ECharts 2.2 已经做了大量移动设备优化工作，ECharts-m （ECharts Mobile 版）很快就要跟大家见面了，其他的事情先卖个关子，很快大家就会看到更好玩的 ECharts。
G：ECharts 的发展过程中应该也遇到过很多困难吧，你是如何克服它们的呢？
林峰：永远都有未完成的任务列表，这是我写 ECharts 以来一直提到的，我曾经极度怀疑我是永远没法把这个任务列表清空的，现在我是深信不疑了-_-。
不管团队还是个人，能力和时间在某段日子里总会是有限的，能做和可做的事情有很多，可以也应该收集尽量多的需求和反馈，但要学会辨别哪些是真实需求哪些是伪需求甚至是不合理的需求，不要被用户左右，学会做减法，保持自己的节奏。
另外就是很多人看到来自百度的不管什么东西，上来先劈头盖脸的一句“真是谷歌有什么百度出什么啊”，也不管好坏与否，接着补刀“一看就是山寨 xx 的货色，跟 xx 比弱爆了”，一开始我还去礼貌的跟他们回复一句我们的不同啦，特色啥的。他们还会接着找茬，上手调不通就骂文档，不符合他的预期就说有 bug，后来我发现完全没必要浪费这个时间伺候他们。做好自己的事情就行，忍并随他去吧，当你把事情做好了他们就会慢慢的闭嘴的，他们如果真的需要 ECharts，那些文档就能解决的问题写得再烂他早晚也会自己找到或者从各种途径问到的。
这可能会怠慢了一些人，但我后来明白了，把精力放在更该做的事情上是对更多人的负责，用祖明同学的话，这是“我们指尖上的责任”。
G：可以总结一下 ECharts 的发展模式吗？比如先从兴趣出发最后得到公司支持，或者从诞生就由公司支持和运作等等。如果其他开发者也想遵循这个模式的话，有什么话想对他们说吗？
林峰：ECharts 怎么来的各位自己去看缘起吧，我很幸运，这事本身就是自己的兴趣，也是公司的需要，遇到各种好领导放任自如的让我随意发挥，并且当事情越做越大的时候能够不断的给于支持和帮助。
做好一个项目，最最重要的，团队的力量，要找到那些志同道合，才华横溢的小伙伴与你并肩，ECharts 团队是个跨部门的虚拟组织，我们面向百度全体 FE 招募，组建时我立了个规矩，“如果你忙或者没时间做这件事情，请暂时离开，我们随时欢迎你归来”，刚开始几个月我两周清一次场，各种进进出出，但半年后团 队就基本稳定至今了，用叮叮的话我们也成了一个小小的 family。
G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？大家都听过开源、GitHub，但是就像那些大道理一样，真正做的时候往往无法进行结合，你觉得程序员应该如何充分利用 GitHub 呢？
林峰太有意义了，学习啊！看大牛们的代码是一种幸福，从模仿到领悟到融入自己的程序里，这就是成长。身边很多大牛们都把 GitHub 视为游乐场或者玩具店，不是说儿戏了，是要有玩家的态度和享受玩的快乐，要在上面学会折腾，GitHub 上有无数好的项目，多动手，多折腾，尝试融入到这些开源社区去做些贡献，一开始哪怕就是跟 Issue 凑热闹，给些使用反馈，文档错别字纠正都是有意义的，然后就是贡献自己的想法，帮助别人解决问题，当你开始贡献代码，或许你就能体会到开源对你的意义。
G：2014 年国内开源界涌现出很多优秀的开源项目，大多数似乎都有公司的介入，这一点上国外的优秀开源项目也很类似，往往有大公司的程序员是核心贡献者。你觉得公司在开源项目中扮演的是什么角色呢？在当前国内的大环境下，如何在公司中做一个成功的开源项目呢？
林峰：对公司来说是贡献者也是获益者，公司是不会无缘无故启动一个跟自身业务无关或者自己都用不到的项目。好的项目能获得更多人的关注、反馈、代码 贡献，开源后如果能让这个项目发展更好不仅对公司自身项目需求有意义，甚至可以让公司在某个领域确立自己的技术领导地位（想想看 Android，Linux，jQ，Bootstrap），这无疑是对公司极好的事情。
公司是否可以运作一个开源项目跟公司状况和基因有关，这个真不好说。只能说一点，在公司内做开源项目，这个项目本身是否对公司带来价值是关键，短期的长期的都最好要有。
PS：我们离成功还远着呢，还没到分享成功经验的时候。
G：介绍一下你自己吧。
李成银：我叫李成银，工作 7 年了吧。以前在百度待过，现在在 360，以后嘛还不知道。以前是做后端的，现在主要在做前端以及 Node.js 这边的一些东西。我自己想做并且一直在做的是一些工程化、工具化、流程化方面的东西，希望可以提升团队的开发效率。
G：为什么要开发 ThinkJS？
李成银：使用 Express 的时候感觉框架功能有限，无法快速实现特定的业务需求，此外，Node.js 自身的异步写法并不好写也不好用，再加上之前用过 ThinkPHP，于是就想开发一个使用 Promise 的类似的 Node.js 框架。
G：ThinkJS 是如何发展起来的呢？
李成银：最初是作为兴趣来做，并不是一开始就准备当做一个项目来写。到 2014 年 4 月份的时候发现这个项目在公司内外都有很多人在用，大家也确实有这样的需求，于是就继续做下去，并明确了当做部门的正式项目来做。2014 年 9 月 22 号 1.0 正式发布，标志着 ThinkJS 成为一个正式的开发项目。1.0 之前主要是实现了我个人的一些想法，但是之后作为部门的正式项目，部门会有更多时间和人力的投入，也会考虑 merge 一些 PR。
G：ThinkJS 为什么决定采用开源的形式来做呢？
李成银：实际上现在不涉及公司机密的东西公司都是鼓励开源的。对于前端来说，本来代码就是藏不住的，既然藏不住何不把它开源出去，用更好的心态来拥 抱它。这其实也是 GitHub 上前端项目最多的原因。虽然 ThinkJS 是一个后端框架，但是因为我们有这样一种心态，所以一开始做的时候就很自然的决定要开源。
G：开源给 ThinkJS 带来了什么呢？
李成银：开源可以带来更多的用户，从而可以发现更多我们内部使用无法发现的问题和需求，让项目可以发展的更好。此外，开源项目对团队和维护者本身有 很大的提升作用。开源项目除了技术还有很多东西要做，比如写文档、和用户交流等等，这些事情实际上会锻炼很多重要的能力，长远来看对于开发者个人的发展有 很大好处，之后做更大的事情时就会发挥出效果。
我也很不喜欢写文档，写完文档代码变了就必须更新。但是实际上很多用户都是只看文档不看代码的，因此你的文档质量直接影响到项目的上手难度和使用效果。
G：ThinkJS 有没有受到公司方面的帮助呢，比如推广？
李成银：ThinkJS 实际上是以部门的形式开源，并不是以公司的形式开源。这样做的好处是更加自由一些，而且和公司的关系并不是特别紧密，这对于项目本身的发展是一件好事，因 为如果项目和公司关系非常紧密的话，一旦项目的负责人离职，项目就很可能无法继续发展。虽然这样做可能会减少一些公司方面的支持，但是长远来看对项目的发 展更有利，主要的支持来自社区。
G：ThinkJS 是如何从一个个人项目转变成部门的正式项目呢？
李成银：主要有两方面原因，一方面是当时已经有一些人在用 ThinkJS，我们看到了这个项目的实际效果，再加上 Node.js 越来越热，我们觉得这个项目未来有很好的发展前景，因此就变成了部门的正式项目。这其实是一个很自然的过程，从个人兴趣出发的项目如果在实际使用中得到大 家的认可并且有很大潜力的话，就很可能会被部门认可。
相对来说，产品型的项目更容易得到认可，因为产品类型的项目更容易看到效果，技术类型的项目有时候很难统计使用情况，有些公司并不会公开他们使用的技术。不过总体来说，只要一个项目能体现出它自己的价值，就很容易变成部门的项目。
G：你觉得国内的开源现状如何呢？
李成银：目前国内的开源项目基本上都是团队内部在开发，即使是非常成功的项目 PR 也非常非常少，所以目前来说国内的开源环境仍然不够活跃不够开放。一个项目出来会被很多人骂，不过关键就是别人骂了我们我们还不知道，也就无法改进。我们 觉得骂本身不是坏事，说明用户还是需要你的项目的，只是项目不够好而已。但是关键是骂也要去 Issue 里骂，这样我们才能看到。总体来说国内的开源环境已经比之前要好了，Issue 多起来了，PR 也有一些，不过目前来说还不够成熟，不能像国外的项目一样能够通过 PR 完成很多功能。
其实也不能怪大家，国内和国外的工作情况就不一样。国外大家把编程当兴趣来做，工作也没有国内这么忙，所以有更多的时间和兴趣投入开源项目中。国内 经常加班，压力很大，大家对于开源的热情就不高，更多的是把开源项目当做一个宝库，遇到问题的时候去找现成的解决办法，而不是参与其中。
此外，大家更喜欢用国外开源项目还有一个原因，就是国外的项目更加稳定，不太容易出现项目无人维护的情况。国内的开源项目有时候开发者会放弃并停止 更新，这样依赖这些项目构建的项目就会很难处理，而国外的开源项目即使维护者停止更新，他也会找到其他人继续维护，比如前段时间的 Express，这就让用户很有安全感。
G：请简单介绍一下你自己吧。
林顺：林顺，Cocos2d-x 的联合创始人，从小喜欢玩游戏，暴雪粉，星际死忠粉，最近爱上风暴英雄，喜欢不受打扰写代码，喜欢数码电子。
G：Cocos2d-x 大家应该都听过了，说实话我第一次听到它的时候还以为是国外的开源项目，后来知道是国人开发的时候非常惊讶。虽然 Cocos2d-x 在国内已经非常有名，不过对于大多数没有接触过游戏的开发者来说可能不太了解，你能介绍一下 Cocos2d-x 以及由它延伸出的整条产品线吗？
林顺：Cocos2d-x 是专业的跨平台移动游戏引擎，采用 MIT 协议，从 2010 年 7 月提交第一行代码到 GitHub 就是完全开源免费的，目前在全球超过 25% 的市场份额，而在中国这一份额超过 70%，全球超过 40 万的开发者正使用该引擎开发游戏。X 代表着 Cross，为开发者提供了跨平台支持，采用 C++ 语言编写一次游戏逻辑即可编译到 iOS、Android 以及更多手机平台上运行，并且运行性能是最高效的。2012 年初 Google 赞助 Cocos2d-x 团队创建了 Cocos2d-html5 分支，并在 Zynga 的帮助下完成了 JSB（JavaScript Binding）产品的开发，实现了 JS 脚本游戏一次开发，不仅能跨原来 Cocos2d-x 支持的所有平台，还能发布到 Web。
目前 Cocos2d-x 的工具链已经覆盖了游戏从新建项目一直到游戏 SDK 接入、打包发布的全过程，集成开发工具 Cocos Studio 支持快速原型构建和验证，调试脚本代码和应用打包使用 Cocos Code IDE，AnySDK 高效快速接入海量渠道。此外，Cocos 社区还有 Cocos Play 和 Cocos Runtime 来实现游戏的点击即玩效果，提升游戏转化率。2015 年 3D 和 3D 编辑器将是 Cocos2d-x 的发展重点，秉承最高效，体积最小的优势，提供更强大的 3D 功能，支持用户使用 Cocos2d-x 的 3D 版本做出优秀的 3D 游戏作品。
G：Cocos2d-x 应该从诞生开始就是由公司在运作的项目吧，最初公司为什么选择做游戏引擎，又是如何决定把它开源的呢？
林顺：Cocos2d-x 从最开始就是完全开源、免费，当时 Cocos2d-x 项目的目标是为我和王哲所在的操作系统公司提供游戏内容。一个新操作系统，全新的生态，没有很好的游戏内容，一点都不高大上，而是高处不胜寒，所以我们开 发 Cocos2d-x 这个跨平台的开发工具，让开发者可以快速的将游戏发布到 iOS 的同时，能快速、低成本的发布到 Android，最后顺手一编，将游戏内容也导入我们的操作系统，实现零落差同步导入最优秀的游戏内容。
G：目前在国外已经有一套很成熟的公司参与开源甚至主导开源的模式，但是在国内这还是一个比较新的概念。开源本身的不确定性和公司需要的可控性应该是矛盾的，触控科技是如何处理这个矛盾呢？
林顺：开源引擎在不确定性和可控性上并没有很大的矛盾，目标都是提高效率，降低成本，更好的为商业游戏开发服务。
开源游戏引擎的好处是可以从社区获得最直接的需求，接地气，推动产品往正确的方向快速发展；社区的代码贡献者也能共同分享他们的成果，从而加速产品 升级。Cocos2d-x 的发展离不开触控科技《捕鱼达人》系列游戏的推动，《捕鱼达人1》基于 Cocos2d-x v1.0，引擎所有技术上的坑是捕鱼游戏最先趟平的，国内各种奇葩机型的适配和性能优化，也都是基于捕鱼达人进行验证。
G：Cocos2d-x 整条产品线发展到现在的规模和知名度，你觉得开源在其中起到了什么作用呢？
林顺：开源在里面有决定性的作用，首先开源社区的需求驱动模式，为我们提供了最好的需求参考，其次，来自全世界超过 300 位的优秀工程师在为引擎贡献代码，这是一笔无法估算的财富，如果不是因为开源模式，我相信没有哪家公司能让这么多的优秀工程师在为同一个项目贡献代码。最 后，开源免费的模式，让更多人能从中受益，他们的口口相传才造就了今天 Cocos2d-x 的口碑和用户基础。
G：什么事都是有利有弊，你觉得公司主导的开源项目相比个人或者社区主导的开源项目利在哪里，弊又在哪里呢？
林顺：有公司或者资本提供支持的开源项目，相对于个人或者没有资本支持的开源项目的优势：有更多的资源投入，对开源项目的后期发展至关重要，允许有 更多专职的研发人员，产品的迭代周期和质量也能得到很好的控制，提供更加持续长久的维护，可以让开源产品走的更高、更远。至于弊端，那就得看对开源项目的 态度，如果本着服务行业，推动行业升级，用开放的心态来做开源项目，并不会存在着什么弊端，全世界范围内也并不乏有各个公司支持的开源项目。当时我们的操 作系统公司做的不好了，引擎项目发展的却是很好，愿意投资我们的有好几家，但是最后还是觉得陈昊芝思路很开放，能坚持不把一个开源的项目做成闭源商业项 目，最终和他一起做，一路走来，也发现我们当初的选择是最正确的。
G：如果其他公司也想走开源路线，有什么话想对他们说吗？
林顺：非常欢迎一起加入开源路线，开源项目不论是对个人和对公司，能学习到很多宝贵的知识，社区里汇集的智慧是巨大的宝贵的，国外资深程序员教你两 招，你就能发现原来代码还能这么写，框架还能这么设计优雅。另外，和社区做好互动，有效采集用户需求和反馈，是推动开源项目往正确方向发展的关键，也是产 品化和易用化的捷径。
G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？程序员应该如何充分利用 GitHub 呢？
林顺：参与开源项目对于程序员来讲是一种高效、快速学习成长的方法，不仅如此，如果你是一个技术爱好者，参与开源项目你有可能找到自己的兴趣，擅长结合点。当然，如果能找到和商业的结合点，进而从事自己喜欢的工作，那就更爽了，这点是很难得的。
一般有秩序的开源社区都提供很好的知识和经验交流平台，深入参与到开源项目中，对个人的技术成长和视野会有很大的帮助。
GitHub 在全球的火爆程度无需多表，提供非常高效的项目开发协作机制，是了解开源项目运作机制的很好入口。在 GitHub 上，开发人员可以随时与全世界的人共享代码，也允许接受来自全球不同地方的人贡献各种 idea，代码片段，也是社区交流的基础，越来越多的开源项目迁移到 GitHub 上。最后，欢迎各位加入 Cocos2d-x 开源项目社区，成为我们社区的一份子，实现自己的游戏梦想。
G：请简单介绍一下你自己吧。
小鱼：大家都叫我小鱼，在大部分需要 ID 的网站叫一般用 sofish。法学院毕业后，就一直写代码。
G：你做过很多开源项目，我们就聊聊 Star 最多 Pen 吧。Markdown 相关的项目非常多，不过 Pen 这样的项目我确实是第一次见到。简单介绍一下 Pen 的用途吧。
小鱼：Pen 是一个支持 Markdown 的可视化（实时编译）编辑器。
写 Pen 是因为当时觉得百姓网用户发贴的体验应该更好一点，刚好 GitHub 当时有一个 ZenPen 的项目很火，准备用。不过这货代码耦合度太高，CSS / JS 也分不开，还不能自定义功能。觉得非常鸡肋，无奈就只能自己写。目标就是编辑的时候与发布结果一样，真正的 WYSIWYG，并支持自定义功能，CSS / JS 也好分开。而刚好 Markdown 的一些语法比较简洁，就直接支持了。当时上了 Trending，GitHub 的员工给提了一个非常给力的 PR，支持显示 Markdown。
不过后来觉得太麻烦，没集成在产品上，也就一直没更新。直到 Teambition 在用，严清同学贡献了很多代码，也解决了很多隐藏的 Bug。
G：最初是如何想到要做 Pen 这么一个项目呢？做得过程中有什么有意思或者让你印象深刻的事情呢？和我们分享一下吧。
小鱼：像上面说的，直接原因是工作需要。我的大部分开源项目，除了 Typo.css，直接原因都是想把工作中一些功能抽象成模块，顺路就开源了。像最早的 AliceUI 是已经大面积用在了支付宝上，才开源的。要说印象深刻，我觉得开源的项目一定要用在某个产品上，特别是商业项目，才能变的真正好用，因为无论是开源还是闭 源都需要保证质量的动力，而工作就是动力之一。任何没真正用在商业产品上的开源项目，都是要慎用的，也称不上好。
G：Pen 是如何获得这么多的 Star 呢，你有做过什么相关的推广吗？
小鱼：没有，就是发了一下微博和 V2EX，然后就好多人关注了。
G：作为中国区排名前十的开发者，你平时的工作应该也很忙吧，你是如何在这种情况下完成 Pen 这个项目的呢？
小鱼：工作也忙的，不过不会完全没有时间。我人生中最忙的阶段似乎是在写我这句话的前 6 个月内，因为做产品的同时要带人，常态是回到家都是 10 点以后，因此最近也没什么产出，除了 m.ele.me 已经上线，并没有什么开源项目。相比构思 Pen 应该是什么样的，体验要达到什么程度，写 Pen 花的时间并不多，300 行代码对我来说难度并不大。顺路说下，ZenPen 当时应该是几千行级别的，但功能没有 Pen 好。
G：你觉得作为个人开发者来开发和维护一个开源项目难度大吗？中间有没有想要放弃的时候呢？
小鱼：难度还是要看项目吧。不过我相信人多不一定能解决问题，因为技术问题普遍都有天花板，对于核心思想和技术，大多情况下应该是由更少的人产出 的。思想定了，核心技术定了，添加功能可能并没有想象中那么难。而对于有没有放弃，我通常是这样想的，最差的可能就是放弃。坚持会发生很多美好的事情，比 如写博客。如果有很多紧要的事，时间不多，有时候也只能放弃，只做觉得紧要的。
G：你觉得纯个人开发开源项目和有公司背景的开源项目比起来有什么本质的区别呢，作为一个开发者应该如何选择？
小鱼：本质上都是开源。个人并没有统计过个人开源的东西更成功，还是公司开源的东西更成功。不过像 ElasticSearch 大多代码都是一个人写的，非常成功；Docker 是一个公司维护的，非常成功；Bootstrap 是 2 个人开发的，公司维护的，非常成功。本质上我觉得是开源的产品真正有用，就会有人用；如果有公司给时间和金钱支持，那相当好；而最好的是有一个社区，大家 一起维护。比如你可以在 Google 上找到关于 jQuery 的几乎所有答案，这就是社区的力量。所以如果你有一个好的项目，那么尝试培养一个社区，比一个人写，或者只有公司支持没有人开发的僵尸项目好。
G：如果有人也想走纯个人的开源路线，有什么话想对他们说吗？
小鱼：做一个有用的产品比是否开源，是不是个人的都更有意思，如果可能，请只生产让这个世界更美好的东西。
G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？程序员应该如何充分利用 GitHub 呢？
小鱼：开源是一种共享的精神。意义可能有很多种。让别人受益，自己得到改进反馈，让更多人从代码认识你，诸如此类，于每个人不同。开源并没有直接改变过我的生活，不过我喜欢写写代码，还能帮到人，于我已经是很大的乐趣，而有乐趣的生活就是我的意义。
对于 GitHub，他只是工作/协作平台，这样的平台还有更多选择。不过我一直用它，是因为其他产品都做的太丑，无论是细节还是体验，而我更愿意选择好用的工具，即使付费。
G：请简单介绍一下你自己吧。
尤雨溪：我叫尤雨溪，目前在一家创业公司 Meteor 任职，做全栈式 JavaScript 框架的开发。之前则是在 Google 纽约的 Creative Lab，主要负责 HTML5 的界面原型开发。
G：MVVM 的框架现在也有不少，Vue 有什么独特之处吗？
尤雨溪：Vue 相对于其他 MVVM 框架，最主要有两个特点：1. 原生 JS 对象即模型；2. 面向组件的开发模式。其他嘛就是比较轻量，侵入性比较低，容易上手。
G：最初是如何想到要做 veu 这么一个项目呢？做得过程中有什么有意思或者让你印象深刻的事情呢？和我们分享一下吧
尤雨溪：最初是因为在原型开发的过程中，需要一个轻量、简单的框架来提高开发效率，但当时并没有符合我需求的框架。我当时研究了 Knockout, Angular 和 Ractive，但他们各自有各自我不喜欢的地方：Knockout 不能用原生 JS 对象做 model，Angular 太庞大，有很多我不需要的东西，Ractive 的 API 最符合我审美，但它当时没有组件系统。另外一点就是我在看这些项目源码的时候觉得数据绑定的实现很有意思，很想自己写一个来加深理解。整个过程其实是比较 随意的，一开始并没有什么计划，就是一点一点尝试去写，内部设计改过无数次，到 0.11 更是彻底重写了一遍。
G：Vue 是如何获得这么多的 Star 呢，你有做过什么相关的推广吗？
尤雨溪：一开始刚发布 Vue 的时候，主要是通过国外的一些软件开发新闻聚合站点，比如 HackerNews, Reddit，以及一些前端开发博客 / newsletter。实际上就是发个链接上去看运气，之后除了维护一个官方 twitter 账号之外并没有做什么刻意推广。我觉得个人开源项目能否获得长期关注，很重要一开始发布的那一波是否能够产生一个好势头，后面基本都是自然增长。当时 Vue 发到 HackerNews 之后被顶到了首页，这可能是最关键的一个契机，因为 HN 带来的流量和关注度实在太厉害了，而且受众全都是开发者。另一方面就是我在 Vue 的文档站点上也下了不少功夫，好的文档表现的是开发者的诚意，第一印象也很重要。
G：做一个框架应该要投入不少时间精力吧，你是如何安排时间来实现它的呢？
尤雨溪：确实花了不少精力，有段时间我几乎所有的业余时间都花在上面了。当然因为 Vue 也用在工作上的一些项目里所以也有理由在工作时间里分配一些。我做 Vue 其实是有些周期性的，可能会有几个月特别投入，实现一些比较大的改进，然后会有几个月专注于别的事情，对 Vue 只是改改 bug。
G：你觉得作为个人开发者来开发和维护一个开源项目难度大吗？中间有没有想要放弃的时候呢？
尤雨溪：这要看项目的规模了。一般来说适合个人维护的项目，最好是专注于解决一个较小的专门问题的库，否则可能会占用过多精力。项目的规模大到一定 程度以后，最好是由社区或者团队来共同维护。说实话 Vue 现在的 issue 增长速度已经挺累人的了，好在现在也有很多社区开发者会积极地帮忙回答问题，让我省了很多精力。
G：你觉得纯个人开发开源项目和有公司背景的开源项目比起来有什么本质的区别呢，作为一个开发者应该如何选择？
尤雨溪：有公司背景的开源，其背后肯定是有商业利益的推动，所以只要公司的商业利益和项目的发展状况是正相关的，这个项目就会有比较稳定的财力和人 力支持。但这类项目通常更受公司决策的影响，对社区的意见不如个人开发的项目来得敏感。个人觉得选择一个项目的时候是个人还是公司开发并不是关键，关键是 看背后的公司/个人是否靠谱。
G：如果有人也想走纯个人的开源路线，有什么话想对他们说吗？
尤雨溪：我觉得做个人开源因为精力有限，所以需要专注，更需要对自己做的项目的定位有明确的理解，确保自己做的东西确实解决了一个痛点，这样花的精力才有意义。
G：最后来聊聊开源吧，你觉得开源对大多数普通程序员来说意义何在呢？程序员应该如何充分利用 GitHub 呢？
尤雨溪：我觉得开源的意义对于普通开发者来说，可以看别人的源码学习自然是最主要的了。在 GitHub 上利用高级搜索去搜自己语言排在前列的项目和开发者，可以学到很多东西。另外每周看看 trending 的新项目也可以发现很多好东西。另一方面，尽可能多地开源自己的代码也有好处，因为这可以迫使你对自己的代码保持一个高水准的要求，而不是得过且过。
参与人员
(按姓氏笔画排名)
团队成员：
梁杰、栾俊清、夏天晗
顾问：
胡少阳、李靖、李松峰、李涛、林峰、卢俊祥、阮一峰、唐巧、响马、周裕波、justjavac (迷渡)、sofish
采访嘉宾：
李成银、林峰、林顺、尤雨溪、sofish
