EROS 是什么?
如果您没听过 EROS，没关系，百度一下，看看 EROS 到底是什么：
emmm...
很遗憾，我们好像和某种神秘力量撞上了，所以你是永远搜不到我们的文档的。
不难看出，开源一个项目，名字很重要。
言归正传
很多开发者称 EROS 是框架，其实我认为不是。
EROS 是基于 WEEX SDK ，拓展了一系列工具，暴露了大量原生能力，让开发者使用 Vue 来开发两端的 APP，它更像是 WEEX 的另一套开发方案。
主项目地址：EROS
简单统计
- 50 + 在线 APP，涉及行业分布于区块链、资讯、医疗、招商、购物、政府、办公、直播等。
- 180+ issue，已关闭 170 个
- 拥有千人活跃开发者群（大多数 issue 胎死腹中的地方）
- 近 30 个开源项目（包含贡献者贡献的插件）
在上周，EROS star 刚刚破千。
在 Mybridge 发布6月 Vue 新晋开源项目中排名第 6。
虽然和很多优秀的项目有很大的差距，但已经是一个较好的开始，下面请欣赏，那些年我们没错过的弯路。
前期：除了混乱，还是混乱。
最开始我们是这样做的开源：
- 内部 Git 建立开发模板项目，发布到 npm。
- 内部脚手架支持 EROS 相关起服务，打包功能到 npm。
当时我们加了一个 WEEX 有一个比较大的群（里面 WEEX 的大佬也在），这个群基本上可以用“惨不忍睹”来形容，每天都有人在问问题，问不同的问题，问一个问题很快就被淹没了。
然后我们就在这个“惨不忍睹”的群里发了条小广告，当天就涌进了几十位“头铁”的开发者，然后各位也能猜到，我们的群，也成了一个“惨不忍睹”的群。。。
当时比较“经典”的几个问题
开源问题：虽然名义上是开源，代码都在 node_modules 中，也就能让开发者看看，不能参与修改。环境问题：绝大多数前端开发者完全搞不定，只有对前端熟悉的客户端开发者，有经验的开发者能运行起来demo。文档问题：文档不全，有太多情况没考虑到，也没说明。兼容问题：因为团队都用 mac，脚手架根本没兼容 windows/linux，所以很多人第一步就跪了，各种暴露出来的原生能力更是有很多兼容性问题。更新问题：对于底层的 SDK，很多命名不合理，设计不规范，每次在更新的时候都在进行断崖式更新，很多用户更新完就跑不起来了。代码问题：由于没有很多的人力去进行前期的测试，造成的过多的 BUG，也没有一个完整的demo让我们进行开发完成后的快速测试。
思考
而这段时期，进群的开发者和出群基本保持持平，这时候我们才渐渐意识到几个问题：
EROS 的开源和平时我们做项目，团队贡献插件，组件等是不太一样的，项目很多，环环相扣，耦合严重，稍微一有变动都有可能造成开发者的流失。
这与我们前期没有做好开发者调研，开源经验欠缺等有直接关系，当我们不在面向团队，而是面向开发者的时候， 之间的增量问题让我们差点手足无措。
我们对 EROS 没有一个明确的定义，没有对开发者的增长有一个很好的规划。
这个是很要命的，如果没有一个明确的定义，我们就像无头苍蝇，陷入永无止境的解决问题中，当时有一大段时间我们团队都在解决问题，甚至到晚上 12 点之后。
我们暴露出的原生能力，并不足以支撑起更多的业务。
举个例子，业务中需要上传图片的组件，你这里没有，绝大多数开发者肯定会扭头就走，这时候我们必须开发大量原生能力来留住开发者，事实也是，我们在这段时间积累并暴露了大量的原生能力。
行动
- 我们首先把所有项目源码搬到了国内的
码云上，在搬的过程中，顺道解决了上面的问题 - 脚手架兼容所有平台 文档补全，同时开设
问答板块来纪录常见问题 - 客户端全力投入 fix 兼容性 群里搜集开发者需求，客户端排优先级来实现
- 每次更新的时候都会出一篇迁移指南，通知开发者群（因为我们知道除了群外基本不会有人来用）
- 编写一个较为简单的
demo，方便测试 - 组内定期讨论，总结流程上的不足，记录下来，定期优化
- 每次开发者要崩溃的时候，都进行语言安慰，并尽可能的解答群里回答的问题，无论大小。。。
第一款 APP
终于，搬到 码云 后的第一个月，我们终于有开发者做出了第一款双端的 APP 连云港点点通 ，虽然功能很简单，但对于我们整个团队是莫大的鼓舞，真的是有开发者一次次陪我们更新，陪我们试错的，很感动。
这期间我们有哪些用户群体
- 小公司
- 外包公司
- 独立开发者
由于我们存在上面说的那些问题，导致稍微有些规模的公司是肯定不敢使用的，他们宁愿使用 RN，或者咬咬牙使用 WEEX。
中期：与开发者一起成长
我们在码云待到了11月份左右，这期间看似比较稳定：
- 已知上线 APP 和开发中 APP 近
10个左右 - 客户端稳定拓展功能 现有 BUG 解决的差不多了
- 文档也进行了补全和优化，让开发者更易懂
- 开发者群人数也在一点点增长
不成熟的稳定 = 面临无果
这种不成熟的稳定，给我们敲响了警钟：
- 我们需要把代码发布到更大的平台
- 我们需要把项目进行更多解耦 我们需要进行项目体积的优化
- 我们需要更多有经验的，有规模的团队一起参与其中 我们需要让开发过程更加迅速，开发体验更加友好
- 我们需要知道此时的开发者需要什么
随后我们做了这几件事：
- 所有项目全部迁移至
Github - 独立出来各个项目如
eros-cli,eros-publish等 - 我们用
docsify重构了文档，并补全了更多的机制介绍，让开发者更加易懂。 - 我们优化了开发流程，增加了 模拟器/真机同时单个或多个
热刷新 - 我们不在局限与 JS Bundle。 仅仅用作页面的思想，针对类 MPA 项目的不足，拓展出了
寄宿 Bundle和中介者 Bundle，减少了包体积 60%+。 - 客户端重新优化了一版底层 SDK，前端重构了一版 Widget，并优化了 api 的使用方式等。
- 我们给群里开发者发送了问卷调查，搜集目前开发者需求
- 做好新的大版本的迁移文档
问卷调查部分截图:
这番折腾过后
- 开发效率上升一个层次。
- 我们积累了更多原生能力。
- 项目之间耦合更低，更加稳定。
- 越来越多的团队加入到了 EROS。 的行列中，不泛有规模的团队，也渐渐有项目从 WEEX 迁移至 EROS。
- 我们也 EROS 也有了一定的规划。
在后续的交流中中，明显能感觉到开发效率有质的提升，这里晒出前面调查问卷的开发周期，我们不难看出，WEEX 在一定业务复杂度范围内的开发效率真的是非常高。
近期：赋予开发者更多的能力
二次稳定
完成上面的优化之后，我们又一次进入一次看似稳定时间，这段时间每周基本都会有 APP 上线，开发者也越来越多，但又暴露出来一个严重的问题：
目前虽然拓展了很多原生功能，但还是远远不能满足用户的需求，同时我们又有自己的业务要开发，很难有大量时间和经历去帮助开发者进行快速拓展。
所以我们决定推出插件化方案，让更多开发者成为贡献者。
说到插件化，很多人会问，这不是一开始就应该去考虑的吗？这也就是开头说到的问题，我们一开始并未给 EROS 一个很好的定位和规划，我们一开始想做一个大而全的“坦克”，但我们一边面对大量的业务，一边一组负责近 5 个左右的仓库，还要在帮助开发者回答问题，修复 bug，已经是非常吃力了。
形成小型社区
今年上旬我们客户端投入到了插件化方案，从设计到最终落地稳定将近 3 个月的时间，由于 WEEX 插件市场已处于基本没人维护的状态，我们并未沿用 WEEX 自身的插件方案。
同时插件化中我们也把自身 SDK 抽离成插件，把项目进行进一步解耦，用户现在只需修改依赖版本号进行升级即可，解决了用户更新困难的问题。
我们并没有做插件市场，而是大量鼓励的原生开发者来拓展插件，并上传到他们的 github 上，通过群内引导 star 和 issue 来帮助提升插件稳定性和开发者积极性。
当我们拥有了一个非常活跃的千人开发者资源，里面的开发者才会有动力开发更好的插件，而他们得到的反馈也会更快更多，如 github star。
随着插件化的稳定，群里已经不再是原来几千条信息的模样了，大部分开发者都在讨论实现，思路，同时有经验的开发者均能帮助我们解决群里绝大多数的问题，让我们轻松了很多，有更多的时间去思考，优化和拓展，而越来越多优秀的开发者贡献他们的插件，解决方案，文章等，也让我们学到很多。
大帅：教程：EROS集成到现有iOS应用 weex eros框架源码解析 - 掘金反思当下才能无问西东
最近我们又从头反思了一遍，列出几点（不是全部）目前存在的问题：
- 操作体验需要优化
- 开发模板不够灵活
- 热更新服务不够灵活
- 复杂场景下的性能问题
- 需要支撑起更多类型的应用等
- 现有项目集成方案的规划与整理
- 插件生态的品控
- 文档的易懂与国际化等
很幸运，其中有几个问题已经有开发者为我们贡献了他们的方案，让我们有了更好的借鉴，而且不在孤单。
为什么未来会要先反思当前存在的问题呢？
没有问题，可能意味着这个项目就没有未来，从前面几个不同时期来看，如果我们不在一定的阶段，站在一个比现在更高的角度反思自己，那基本不会有现在的 EROS。
对于 WEEX
很多地方都有关于 WEEX 不好的言论，这里不做任何洗白的代表 EROS 开发者说几点：
- 上手有门槛，开发有门槛，很多场景下没有原生支持是很难的。
- 毋庸置疑是个好项目，Vue + WEEX 的开发体验真的很好，效率也很高。
- 但文档不全，资料不多，和官方沟通较难等都是显而易见的问题，好比隔着一个人传话，WEEX 更应该站出来拥抱开发者，多花些时间在开发者身上，去真正体会一下开发中的痛点，去拥抱更多的场景，需求。
- 开发项目链路很长，断崖式更新问题有时候真的避免不了，但如果发生了断崖式更新，也一定要在给予开发者更新指南，抽空也更新下官方的 DEMO，尽快发布一个稳定版本。
- 对于用户经常询问的常见问题给予更详细的说明和记录。
- 应该解决更多的极端性能问题，如 iconfont 字体使用导致内存吃紧等问题。
- 暴露出更多通用的原生能力。
不过据说 WEEX 今年会有较大的更新，我们有理由相信，上面的问题会被或多或少有所改善。
同时 EROS 期望做一个子集生态，通过受众开发者的不同，能反向输出的到 WEEX，为 WEEX 的发展近一点微薄之力。
为什么要做开源？
开源的优点很多，网上说的基本都有，这里说下我们的体会，不代表其他人：
- 对于发展中公司来说，如过遇到大量/爆发式的业务增长，往往技术都会要不断迭代，甚至是推翻重来，开源即是一个需求前置的过程，随着功能的积累能覆盖更多的场景，同时也是一个提升技术底层稳定性的过程。
- 团队相关，一个良好的开源项目可以提高整个团队的稳定性，凝聚力，在开源过程中会对每个人都有更多更全面的成长（沟通，协调，自我学习，自我驱动等）。
- 提升信心，尤其是小公司来做开源，起步是非常难的，开始时很少会有开发者会看好一个没有大公司背景的开源方案。
我们还在弯路上走着，或许前方就根本就没有直路，但我们还是走着。
EROS 链接
部分产品截图
感谢
- starlife(新加坡)大前端团队
、车国大前端团队、钱保姆前端团队、shawn唐团队、凉城殇，何姐等独立开发者等插件贡献，方案输出，问题解答。 - 感谢这一年中陪我们趟坑的开发者，虽然以后可能还得继续。
- 感谢那些开源 EROS，WEEX 插件的开发者。
- 也感谢所有给出过 EROS 发展意见的开发者。
- 最后，感谢 WEEX。
