封面故事：Apache ECharts 团队：ASF 顶级项目是怎么炼成的？
作者：凌敏
优秀的产品背后，必定有优秀的团队做支撑。《顶尖技术团队访谈录》系列采访以国内知名公司的 IT 技术团队为线索，展示他们的文化、思想与经验。本期，InfoQ 走进 Apache ECharts 核心团队，了解 ASF 顶级项目背后的故事和团队沉淀下来的开源经验。
Apache ECharts 是一个基于 Web 前端技术实现的数据可视化产品，它诞生于 2013 年，由百度 EFE 团队创建并开源，并于 2018 年 1 月捐赠给 Apache 软件基金会。2020 年年底，团队发布了全新重量级的 Apache ECharts 5。2021 年 1 月 26 日，Apache 基金会官方宣布 ECharts 项目正式毕业，成为 Apache 顶级项目。
目前，在 npm 上，Apache ECharts 的每周下载量约为 25 万，在 GitHub 的关注数也达到了 4.6 万。
ECharts 的三次蜕变
从 2012 年正式在百度内部立项到现在，ECharts 主要经历了三个发展阶段。
在早期阶段，ECharts 的核心代码主要由作者林峰贡献。2013 年 6 月和 2014 年 6 月，团队分别发布了 ECharts 1.0 和 2.0 两个大版本。彼时，ECharts 基于 html5 Canvas，是一个纯 JavaScript 图表库，并支持折线图、柱状图、散点图等多类图表展现，同时支持任意维度的堆积和多图表混合展现。
2015 年年初，随着原作者林峰离开项目，ECharts 的主要维护工作交给了沈毅、宿爽。这之后，ECharts 的核心团队也逐步趋于稳定，除沈毅、宿爽外，还有包括羡辙、俊婷、德清在内的多位技术人参与其中。至此，ECharts 正式迈入第二个发展阶段。
在进行了半年左右的小版本维护工作之后，团队成员意识到 ECharts 是时候做出改变了—— 3.0 版本要重构整个架构。之所以做下这个决定，一方面是因为彼时的 ECharts 存在很多难以修复的 Bug，另一方面，ECharts 当时的架构设计对于功能的组合和扩展并不是很灵活，经常引来开发者抱怨。
在核心团队再三权衡下，ECharts 开始进入 3.0 版本的研发中。最终历时半年，于 2016 年 1 月发布了 ECharts 3.0。此后，ECharts 团队收到了很多 issue，在高频率地迭代了几个小版本后，最终整个项目在 3.2 版本逐渐稳定了下来，而新的架构也在扩展发面发挥了不少作用，保证了 ECharts 的持续发展。
2018 年年初，ECharts 正式发布 4.0 版本，同时由百度捐赠给 Apache 软件基金会，并进入第三个发展阶段。
2020 年年底，团队发布了 Apache ECharts 5，完成五大模块、十五项特性的全面升级，围绕图表的叙事能力，在动态叙事、视觉设计、交互能力、开发体验以及可访问性等方面做了专项优化升级，让用户获得更好的数据可视化的展现效果。
在 Apache 孵化的那些日子
从加入 Apache 软件基金会孵化到正式毕业，ECharts 团队成员在协作模式、思维方式上发生了翻天覆地的变化，如何才能更好地应对这些变化？如何让项目顺利毕业？
InfoQ：会什么为选择加入 Apache 软件基金会？
A：在加入 Apache 软件基金会之前，ECharts 项目 95% 的开发者都来自百度内部，协作模式也依托于内部沟通。从项目本身的发展角度来讲，这种方式存在一系列不稳定因素。一方面，项目很容易受到其他因素影响，比如当团队其他业务比较忙的时候，很难再抽出时间来做 ECharts 项目相关工作，最终导致项目的发版很受影响。另一方面，加入 Apache 也能帮助 ECharts 吸引更多来自不同公司的开发者加入进来，从而让整个开源的生态变得更加健康。此外从开发者角度来讲，ECharts 项目加入 Apache 之后，开发者在选择产品的时候也能更有信任感，在版权方面也不会有太多顾虑。
InfoQ：加入 Apache 软件基金会后，团队在协作模式上发生了哪些变化？
A：在加入 Apache 之前，团队沟通主要是在公司内部，采用面对面讨论或是在即时通讯软件里讨论的方式。加入 Apache 之后，我们需要经常用邮件去做异步沟通，刚开始我们对这种协作模式是不太适应的。一方面，邮件沟通效率比较低，发出邮件之后，可能要等待几个小时才能收到对方的回复，有时讨论一个非常简单的问题，一来一回也需要一周的时间。另一方面，我们团队的大部分开发者都是中国人，在邮件列表里用英文进行沟通存在一定难度。
后来我们在跟 Apache 的导师以及其他有开源项目经验的人沟通后意识到，对于开源项目来说，效率并不是唯一的追求目标，怎么能吸引更多的开发者加入到我们贡献者的行列中去，才是现阶段更重要的事情。邮件列表的协作模式能让更多人知道我们的讨论内容，知道这个项目有哪些重要的事情正在发生，同时，这种协作模式也能让外界看到我们的友好姿态，更愿意参与进来。
InfoQ：除了协作模式，还发生了哪些变化？
A：最大的变化可能来自于思想上的转变。一个很明显的例子就是，我们在做 PR Review 的时候，会愿意花更多的时间去 Review 别人的代码。在过去，面对别人提交的有问题的 PR，我们会觉得与其和对方沟通具体应该怎么做，不如直接把这个 PR 关掉，自己重新提交一份正确的 PR，这样也能节省我们很多时间和精力。
但加入 Apache 后，我们也意识到如果每次都关掉别人的 PR，很可能最后维护这个项目的永远都是那么几个人，外部开发者很难参与进来。所以现在，如果别人的代码有问题，我们也会花很多时间去和对方解释，一步一步指导他怎么做，同时也有越来越多的开放文档，帮助开发者更好地加入参与进来。
InfoQ：如何才能顺利从 Apache 软件基金会毕业？需要注意什么吗？
A：从孵化到正式毕业，这个过程中有几件比较重要的事情需要维护者注意。
第一，要学会用 Apache 的方式进行发版；第二，要保证发版固定的周期；第三，要发展一些外部的贡献者，比如来自不同公司的开发者等等。以上这三点都是可评估的维度，除此之外，还要解决一些其他方面的问题，比如品牌是否被其他项目占用等等。
其实要想从 Apache 软件基金会毕业，并没有明确的指标要求，像我刚提到的发版周期，也不是一个绝对的数字上的评判。最重要的是要向 Apache 基金会证明，这个项目在没有导师帮助的情况下，也能由项目的管理委员会正常独立的运营下去。
维护开源技术项目的挑战
开源技术项目的维护离不开所有人的共同努力，如何让项目、社区发展得越来越好，是每个项目参与者必须要面对的难题。
InfoQ：您是如何理解开源的？
A：从名字上来讲，开源指的是开放源代码，把你的源代码开放在网络上，但其实这仅仅是开源的第一步。接下来，你需要让更多的人使用你的开源项目，比如，你要建立使用文档，告诉别人怎样用这个项目。如果没有这一步，没有人用你的开源项目，那么开源和不开源是没有什么区别的。
下一步，你要考虑的是，怎样才能让这个开源项目持续有活力，怎样才能吸引更多有意愿的开发者参与进来，贡献他们的想法。因为不管是个人项目还是团队项目，开发者都是有限的，项目很容易受到不稳定因素干扰，影响到发版或日常维护。通过吸引更多的开发者参与进来，项目也会更加健康，具备更长久的生命力。
其实很多开发者对于开源项目都存在一种误解，会觉得这样一个免费的项目就应该服务于他，应该无条件地第一时间响应他提出的问题，并立马解决。这样错误的预期必然会带来一定的心理落差。所以对于开发者而言，不要对项目有太多苛责，不要一味地去索取，而是要想想自己能为自己喜爱的开源项目做些什么，这对于双方都是有益的。
InfoQ：在维护开源技术项目的过程中，您遇到过哪些让您印象深刻的挑战？
A：其实挑战还是比较多的，最大的挑战可能就是如何降低开发者参与的门槛，如何减少开发者参与过程中产生的挫折感。作为开源项目的维护者，我们要做的就是在项目的开发流程中，尽量地不消磨掉开发者的热情。我们要通过一些代码架构的优化，以及项目流程的优化，来引导开发者积极贡献，提高大家参与的热情。
当然，其他方面的挑战也比较多。比如曾经有段时间，我们很头疼 issue 的维护工作，因为这是一个非常消磨意志的事情。一方面，我们每天要面对大量的 issue，我们需要充当客服角色，来回答开发者们提出的各种问题。另一方面，有些开发者提的 issue 描述得比较混乱，让人有点摸不着头脑，也不知道该怎么回答。最后，我们参考了其他非常成功的开源产品的做法，通过提供一个 H5 创建的帮助页面，给开发者一个固定的格式来填写他们遇到问题，或是他们想要的新需求。另外，我们还写了一些机器人脚本，来第一时间回复开发者提的 issue。这些工作在一定程度上也帮我们节省了非常多的精力。
InfoQ：在您看来，维护这样一个大型的开源技术项目，需要具备哪些关键素质?
A：第一，要有同理心，要多站在开发者角度去思考问题。如果我是开发者，自己在使用一些开源项目时，问题得不到解答，我的内心也会很焦急。作为开源项目维护者，应该理解开发者的这种心理，通过一些工具或方法，提高开发者的使用体验。比如，我们就会通过提供 H5 表单的方式，帮助开发者更好地提交 issue，我们也能快速解决问题，从而进一步完善用户体验。
第二，要有服务的心态，多给予开发者帮助。对于开源项目来说，如何吸引更多的开发者加入进来，是我们一直要思考的问题。一名开发者从开源项目的用户变成贡献者，是存在一个转换关系和转换比例的。要想提高转换比例，一方面，需要项目维护者先做出一个有价值的产品，当你的产品本身足够有吸引力，才能让更多的人来使用它。另一方面，维护者可以通过做一些事情来提高转换比例，比如在开发者使用产品的过程中，给他足够的帮助，让他感受到社区的温暖。受到过社区帮助的开发者，在未来的某天，也许也会去帮助社区里的其他人，把这种帮助传递下去。
第三，要有责任感，对作品和开发者负责。对一个大型的开源项目来说，任何一个很细微的改动都可能会带来正面或负面的影响，因此维护者需要具备足够的责任感，不能把问题丢给产品的使用者自己解决。
第四，要有自驱力，要有足够的热情。维护一个用户量比较大的开源项目，需要投入大量的时间和精力，自己日常的一些工作和生活也可能会被打断。因此，维护者需要具备很强的自驱力，并对项目保持热情，有时甚至还要主动、默默地承担一些事情。比如，很多时候维护者做的工作很可能会被忽略，优化升级后的一些小细节，如果不对比，使用者可能一直不会发现，也不会知道原来一个小小的细节的改动背后，维护者需要做很多次的试验和尝试，才能保证改动的正确性。
InfoQ：如何打造一个持续活跃、健康发展的社区？
A：我觉得没有一个公式能告诉你怎样把社区打造好，因为不同的项目有不同的风格，大家情况也不相同。对于 ECharts 而言，我们也一直在探索这个问题，通过这几年的建设，我们也积累了一些经验。
第一点，作为开源项目的维护者，你要对社区建设有足够的重视，而不是把它当做可有可无的事情。第二点，通过产品持续为你的用户提供价值，这样用户才愿意反哺社区，愿意与你建立信任感。第三点，通过一些具体的方法或策略，降低用户贡献的门槛。比如，你可以给用户提供更多完善的文档，做 PR Review 时对他们进行更详细的指导。最后，不管他的 PR 有没有被合入进来，都要表达对他的感谢，让他意识到他的贡献是有意义的。
最后，像 ECharts 这样由公司牵头发起的项目，能获得公司认可和持续的支持在项目发展阶段是非常重要的。我们非常感谢百度多年以来全力支持 ECharts 项目，如果不是出于对开源精神真心的认可与远见，是很难坚持做这样没有商业收益的事的。通过捐献给 Apache 软件基金会，公司希望项目能够发展出更健康的社区，最终实现不依赖于少部分核心开发者也能健康持续发展的目标。而在项目真正能实现自主可持续发展之前，公司的持续支持则是项目健康成长非常重要的因素。通过在 Apache 基金会孵化期间的磨合与学习，ECharts 项目可以说已经在一定程度上实现了自主可持续发展的目标。而百度也将继续为项目提供支持——作为公司员工和 ECharts 核心开发者，这一点对我们来说是非常鼓舞人心的。
对 Apache ECharts 的期待
从 2013 到 2021， ECharts 已走过 8 载。下一步，将走向何方？
InfoQ：如果让您给现在的 Apache ECharts 打分的话，您会打多少分？为什么？（满分 100 分）
A：可能会从功能性和开源社区两个维度来进行打分。功能性方面，我会打 80 分。虽然现在的 Apache ECharts 功能很丰富，但由于精力或其他方面的限制，我们还没有做到想象中的最好的样子。开源社区方面，我会打 65 分。虽然我们通过了 Apache 的毕业要求，但与其他像 Vue、React 或者 ThreeJS 这样成功的前端开源项目还是存在一定差距，未来我们也会继续努力。
InfoQ：接下来 Apache ECharts 会朝着哪个方向演进？目前有什么计划？
A：从总体上来说，我希望 Apache ECharts 是一个可以持续带给人惊喜感的项目。具体功能方面，接下来我们会专注在两个比较大的方向上。第一个就是持续增强我们的拓展能力，除了优化接口，带来一些更灵活的定制化之外，还要在文档和示例的引导上多下功夫。第二个就是提高应用程度，让大部分开发者能够做到开箱即用，让我们的默认设计在一些领域方向能够满足他们相应的专业性需求，当然这也需要我们在相应领域具备一定经验，这也是一个需要慢慢积累的过程。
社区方面，我们下一步会通过优化各种周边工具，以及整体的开发流程，来提升开发者的开发体验，降低开发者贡献代码的门槛。
嘉宾介绍：
羡辙 Apache ECharts VP
沈毅（pissang） Apache ECharts PMC
宿爽（爽爷） Apache ECharts PMC
王俊婷（叮叮） Apache ECharts PMC
目录
封面故事
Apache ECharts 团队：ASF 顶级项目是怎么炼成的？
重磅访谈
为什么我说低代码是“行业毒瘤”？
技术实践
顺丰科技架构升级之路
十年三次重大架构升级，微博应对“极端热点”的进阶之路
贝壳一站式大数据开发平台实践
技术管理
声网高泽华：关于技术领导力的成长点
创新研究
腾讯 AI Lab 图神经网络研究结果已经被 ICLR-2021 收录
评论 (1 条评论)