你在使用哪种编程语言?快来投票,亲手选出你心目中的编程语言之王 了解详情
写点什么

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

2021 年 6 月 01 日

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 年 6 月 01 日 08:00794

评论

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

阿里/腾讯/京东等大厂Java近十万道最新面试题已被收录成册

周老师

Java 编程 程序员 架构 面试

少儿学编程系列---如何使用turtle画风车

cloudcoder

基于matlab的控制系统与仿真1-传递函数图像的绘制

AXYZdong

matlab 2月春节不断更

玩转写作平台-公众号文章出圈福利~

InfoQ写作平台官方

InfoQ 玩转写作平台 出圈攻略

窥探未来不是梦,python数据分析轻松实现

小Q

Python 学习 编程 面试 数据分析

电力行业区块链技术应用和产业布局

CECBC区块链专委会

区块链

Python基础之:数字字符串和列表

程序那些事

Python 字符串 Python基础 Python3 程序那些事

翻译:《实用的Python编程》02_03_Formatting

codists

Python 人工智能 后端 数据结构与算法 格式化

程序员成长第十一篇:弄懂需求

石云升

需求 28天写作 2月春节不断更

第五章作业

Kasn

产品经理 产品经理训练营

2020-我的技术之路:创业公司中的研发效能与技术赋能

王下邀月熊

前端 后端 2020年总结

阿里巴巴云原生应用安全防护实践与 OpenKruise 的新领域

阿里巴巴云原生

容器 运维 云原生 k8s 调度

区块链电子证照应用平台,区块链电子证照平台建设方案

13530558032

工作日志-2-22

一锅水端平

音频社交的变声,应用了哪些算法?

拍乐云Pano

RTC 语音聊天室 clubhouse 音频社交 变声

常用的Date与LocalDate转换工具

废材姑娘

Java

颠覆技术-智能合约的说明文

CECBC区块链专委会

区块链

区块链药品溯源平台-区块链医药追踪溯源

13530558032

青帮大佬杜月笙的另一面及其后代现状

wbliu85

(干货)玩转写作平台 - 优质作者推荐几大法则!!

InfoQ写作平台官方

InfoQ 玩转写作平台 上线规则

算力蜂系统开发|算力蜂软件APP开发

开發I852946OIIO

系统开发

Git 教程--git stash命令

生之欢愉,时间同行

git 程序员 git stash

Spark Shuffle 内部机制(二)

hanke

大数据 spark 开源框架

Git教程--git diff命令

生之欢愉,时间同行

git 程序员

(干货)玩转写作平台-优质文章推荐五大爆点!

InfoQ写作平台官方

InfoQ 玩转写作平台 上线规则

LeetCode题解:213. 打家劫舍 II,动态规划(缓存偷盗状态),JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

第五章学习总结

Kasn

产品经理 产品经理训练营

一文读懂区块链产业最新发展趋势

CECBC区块链专委会

大数据

什么是供应链,供应链有哪些核心指标

学志

技术 指标体系 供应链 电商平台

全新角度剖析--iOS面试

如何拿到大厂offer——C++后台学习路线

赖猫

c++ Linux 面试 后台开发 后端开发

围绕“三个问题”开展的网易云音乐数据基础建设

围绕“三个问题”开展的网易云音乐数据基础建设

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