AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

Apache ECharts 团队:ASF 顶级项目是怎么炼成的? | 顶尖技术团队访谈

  • 2021-06-01
  • 本文字数:5390 字

    阅读完需:约 18 分钟

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

 

相关推荐:


中国顶尖技术团队访谈录(2021年第一季)

中国顶尖技术团队访谈录(2021年第二季)

2021-06-01 08:001613

评论

发布
暂无评论
发现更多内容

设计模式之责任链模式

乌龟哥哥

5月月更

M-DAO开辟区块链全新战场,或成DAO赛道龙头

西柚子

css 学习笔记【三】浮动,不脱离文档流,继承和层叠

恒山其若陋兮

5月月更

Notification发送消息

空城机

WebApi 5月月更

拆分电商系统为微服务

小虾米

「架构实战营」

使用 Provider 改造屎山代码,代码量降低了2/3!

岛上码农

flutter ios 安卓开发 跨平台开发 5月月更

抖音打击炫富违规视频:自媒体行业的底线在哪

石头IT视角

JS Iterable object (可迭代对象)

达摩

js

字节跳动 CloudWeGo 官方微信公众号官宣了!

baiyutang

Go 开源 微服务 5月月更

在线HTML转Excel工具

入门小站

工具

干货| 四种渲染到底是啥?终于有人讲明白了!(下)

Orillusion

开源 WebGL 元宇宙 Metaverse webgpu

druid源码阅读(十)Druid keepAlive参数

爱晒太阳的大白

5月月更

Kubernetes 安全权限管理深度剖析

liuzhen007

k8s 5月月更

[Day43]-[回溯]-解数独

方勇(gopher)

LeetCode 数据结构算法

M-DAO开辟区块链全新战场,或成DAO赛道龙头

小哈区块

六、云原生可观测性

穿过生命散发芬芳

可观测性 5月月更

在线文本代码对比工具

入门小站

工具

数据库连接池 -Druid 源码学习(九)

wjchenge

Druid 数据库连接池

Druid连接池源码阅读09

石小天

ES6 之set详解

达摩

js

[Day45]-[BFS]-滑动谜题

方勇(gopher)

LeetCode BFS 数据结构算法

druid 源码阅读 9—— init 中的JMX是干啥的

张大彪

千亿级高并发MongoDB集群在某头部金融系统中的应用及性能优化实践(上)

杨亚洲(专注MongoDB及高性能中间件)

数据库 mongodb 分布式 高性能 分布式数据库mongodb

代码之外:写作是倒逼成长的最佳方式

宇宙之一粟

写作 5月月更

M-DAO开辟区块链全新战场,或成DAO赛道龙头

BlockChain先知

Redis「8」实现分布式限流与延时队列

Samson

redis 学习笔记 5月月更

一站式Dao打造工具M-DAO:门槛低、效率高

股市老人

零基础学Java第三节(基本输入输出)

编程攻略

java开发学习

[Day44]-[回溯]-括号生成

方勇(gopher)

LeetCode 回溯算法 数据结构算法

linux之sed使用技巧

入门小站

Linux

初始C语言

芒果酱

C语言 5月月更

Apache ECharts团队:ASF顶级项目是怎么炼成的? | 顶尖技术团队访谈_开源_凌敏_InfoQ精选文章