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 万。

从 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 软件基金会孵化到正式毕业，ECharts 团队成员在协作模式、思维方式上发生了翻天覆地的变化，如何才能更好地应对这些变化？如何让项目顺利毕业？

A：在加入 Apache 软件基金会之前，ECharts 项目 95% 的开发者都来自百度内部，协作模式也依托于内部沟通。从项目本身的发展角度来讲，这种方式存在一系列不稳定因素。一方面，项目很容易受到其他因素影响，比如当团队其他业务比较忙的时候，很难再抽出时间来做 ECharts 项目相关工作，最终导致项目的发版很受影响。另一方面，加入 Apache 也能帮助 ECharts 吸引更多来自不同公司的开发者加入进来，从而让整个开源的生态变得更加健康。此外从开发者角度来讲，ECharts 项目加入 Apache 之后，开发者在选择产品的时候也能更有信任感，在版权方面也不会有太多顾虑。

A：在加入 Apache 之前，团队沟通主要是在公司内部，采用面对面讨论或是在即时通讯软件里讨论的方式。加入 Apache 之后，我们需要经常用邮件去做异步沟通，刚开始我们对这种协作模式是不太适应的。一方面，邮件沟通效率比较低，发出邮件之后，可能要等待几个小时才能收到对方的回复，有时讨论一个非常简单的问题，一来一回也需要一周的时间。另一方面，我们团队的大部分开发者都是中国人，在邮件列表里用英文进行沟通存在一定难度。

后来我们在跟 Apache 的导师以及其他有开源项目经验的人沟通后意识到，对于开源项目来说，效率并不是唯一的追求目标，怎么能吸引更多的开发者加入到我们贡献者的行列中去，才是现阶段更重要的事情。邮件列表的协作模式能让更多人知道我们的讨论内容，知道这个项目有哪些重要的事情正在发生，同时，这种协作模式也能让外界看到我们的友好姿态，更愿意参与进来。

A：最大的变化可能来自于思想上的转变。一个很明显的例子就是，我们在做 PR Review 的时候，会愿意花更多的时间去 Review 别人的代码。在过去，面对别人提交的有问题的 PR，我们会觉得与其和对方沟通具体应该怎么做，不如直接把这个 PR 关掉，自己重新提交一份正确的 PR，这样也能节省我们很多时间和精力。

但加入 Apache 后，我们也意识到如果每次都关掉别人的 PR，很可能最后维护这个项目的永远都是那么几个人，外部开发者很难参与进来。所以现在，如果别人的代码有问题，我们也会花很多时间去和对方解释，一步一步指导他怎么做，同时也有越来越多的开放文档，帮助开发者更好地加入参与进来。

A：从孵化到正式毕业，这个过程中有几件比较重要的事情需要维护者注意。

第一，要学会用 Apache 的方式进行发版；第二，要保证发版固定的周期；第三，要发展一些外部的贡献者，比如来自不同公司的开发者等等。以上这三点都是可评估的维度，除此之外，还要解决一些其他方面的问题，比如品牌是否被其他项目占用等等。

其实要想从 Apache 软件基金会毕业，并没有明确的指标要求，像我刚提到的发版周期，也不是一个绝对的数字上的评判。最重要的是要向 Apache 基金会证明，这个项目在没有导师帮助的情况下，也能由项目的管理委员会正常独立的运营下去。

开源技术项目的维护离不开所有人的共同努力，如何让项目、社区发展得越来越好，是每个项目参与者必须要面对的难题。

A：从名字上来讲，开源指的是开放源代码，把你的源代码开放在网络上，但其实这仅仅是开源的第一步。接下来，你需要让更多的人使用你的开源项目，比如，你要建立使用文档，告诉别人怎样用这个项目。如果没有这一步，没有人用你的开源项目，那么开源和不开源是没有什么区别的。

下一步，你要考虑的是，怎样才能让这个开源项目持续有活力，怎样才能吸引更多有意愿的开发者参与进来，贡献他们的想法。因为不管是个人项目还是团队项目，开发者都是有限的，项目很容易受到不稳定因素干扰，影响到发版或日常维护。通过吸引更多的开发者参与进来，项目也会更加健康，具备更长久的生命力。

其实很多开发者对于开源项目都存在一种误解，会觉得这样一个免费的项目就应该服务于他，应该无条件地第一时间响应他提出的问题，并立马解决。这样错误的预期必然会带来一定的心理落差。所以对于开发者而言，不要对项目有太多苛责，不要一味地去索取，而是要想想自己能为自己喜爱的开源项目做些什么，这对于双方都是有益的。

A：其实挑战还是比较多的，最大的挑战可能就是如何降低开发者参与的门槛，如何减少开发者参与过程中产生的挫折感。作为开源项目的维护者，我们要做的就是在项目的开发流程中，尽量地不消磨掉开发者的热情。我们要通过一些代码架构的优化，以及项目流程的优化，来引导开发者积极贡献，提高大家参与的热情。

当然，其他方面的挑战也比较多。比如曾经有段时间，我们很头疼 issue 的维护工作，因为这是一个非常消磨意志的事情。一方面，我们每天要面对大量的 issue，我们需要充当客服角色，来回答开发者们提出的各种问题。另一方面，有些开发者提的 issue 描述得比较混乱，让人有点摸不着头脑，也不知道该怎么回答。最后，我们参考了其他非常成功的开源产品的做法，通过提供一个 H5 创建的帮助页面，给开发者一个固定的格式来填写他们遇到问题，或是他们想要的新需求。另外，我们还写了一些机器人脚本，来第一时间回复开发者提的 issue。这些工作在一定程度上也帮我们节省了非常多的精力。

A：第一，要有同理心，要多站在开发者角度去思考问题。如果我是开发者，自己在使用一些开源项目时，问题得不到解答，我的内心也会很焦急。作为开源项目维护者，应该理解开发者的这种心理，通过一些工具或方法，提高开发者的使用体验。比如，我们就会通过提供 H5 表单的方式，帮助开发者更好地提交 issue，我们也能快速解决问题，从而进一步完善用户体验。

第二，要有服务的心态，多给予开发者帮助。对于开源项目来说，如何吸引更多的开发者加入进来，是我们一直要思考的问题。一名开发者从开源项目的用户变成贡献者，是存在一个转换关系和转换比例的。要想提高转换比例，一方面，需要项目维护者先做出一个有价值的产品，当你的产品本身足够有吸引力，才能让更多的人来使用它。另一方面，维护者可以通过做一些事情来提高转换比例，比如在开发者使用产品的过程中，给他足够的帮助，让他感受到社区的温暖。受到过社区帮助的开发者，在未来的某天，也许也会去帮助社区里的其他人，把这种帮助传递下去。

第三，要有责任感，对作品和开发者负责。对一个大型的开源项目来说，任何一个很细微的改动都可能会带来正面或负面的影响，因此维护者需要具备足够的责任感，不能把问题丢给产品的使用者自己解决。

第四，要有自驱力，要有足够的热情。维护一个用户量比较大的开源项目，需要投入大量的时间和精力，自己日常的一些工作和生活也可能会被打断。因此，维护者需要具备很强的自驱力，并对项目保持热情，有时甚至还要主动、默默地承担一些事情。比如，很多时候维护者做的工作很可能会被忽略，优化升级后的一些小细节，如果不对比，使用者可能一直不会发现，也不会知道原来一个小小的细节的改动背后，维护者需要做很多次的试验和尝试，才能保证改动的正确性。

A：我觉得没有一个公式能告诉你怎样把社区打造好，因为不同的项目有不同的风格，大家情况也不相同。对于 ECharts 而言，我们也一直在探索这个问题，通过这几年的建设，我们也积累了一些经验。

第一点，作为开源项目的维护者，你要对社区建设有足够的重视，而不是把它当做可有可无的事情。第二点，通过产品持续为你的用户提供价值，这样用户才愿意反哺社区，愿意与你建立信任感。第三点，通过一些具体的方法或策略，降低用户贡献的门槛。比如，你可以给用户提供更多完善的文档，做 PR Review 时对他们进行更详细的指导。最后，不管他的 PR 有没有被合入进来，都要表达对他的感谢，让他意识到他的贡献是有意义的。

最后，像 ECharts 这样由公司牵头发起的项目，能获得公司认可和持续的支持在项目发展阶段是非常重要的。我们非常感谢百度多年以来全力支持 ECharts 项目，如果不是出于对开源精神真心的认可与远见，是很难坚持做这样没有商业收益的事的。通过捐献给 Apache 软件基金会，公司希望项目能够发展出更健康的社区，最终实现不依赖于少部分核心开发者也能健康持续发展的目标。而在项目真正能实现自主可持续发展之前，公司的持续支持则是项目健康成长非常重要的因素。通过在 Apache 基金会孵化期间的磨合与学习，ECharts 项目可以说已经在一定程度上实现了自主可持续发展的目标。而百度也将继续为项目提供支持——作为公司员工和 ECharts 核心开发者，这一点对我们来说是非常鼓舞人心的。

从 2013 到 2021， ECharts 已走过 8 载。下一步，将走向何方？

A：可能会从功能性和开源社区两个维度来进行打分。功能性方面，我会打 80 分。虽然现在的 Apache ECharts 功能很丰富，但由于精力或其他方面的限制，我们还没有做到想象中的最好的样子。开源社区方面，我会打 65 分。虽然我们通过了 Apache 的毕业要求，但与其他像 Vue、React 或者 ThreeJS 这样成功的前端开源项目还是存在一定差距，未来我们也会继续努力。

A：从总体上来说，我希望 Apache ECharts 是一个可以持续带给人惊喜感的项目。具体功能方面，接下来我们会专注在两个比较大的方向上。第一个就是持续增强我们的拓展能力，除了优化接口，带来一些更灵活的定制化之外，还要在文档和示例的引导上多下功夫。第二个就是提高应用程度，让大部分开发者能够做到开箱即用，让我们的默认设计在一些领域方向能够满足他们相应的专业性需求，当然这也需要我们在相应领域具备一定经验，这也是一个需要慢慢积累的过程。

社区方面，我们下一步会通过优化各种周边工具，以及整体的开发流程，来提升开发者的开发体验，降低开发者贡献代码的门槛。

点个在看少个 bug 

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/