# Apache ECharts 社区 ## （一）2021 Apache ECharts 社区健康实践 2021 年对于 Apache ECharts 来说是非常特殊的一年。2021 年 1 月 26 日，ECharts 项目从 Apache 软件基金会毕业成为顶级项目。在毕业后不到一年的时间中，Apache ECharts 项目管理委员会承担起了维护社区健康、确保项目稳定持续更新的重要责任，也在实践中累积了关于开源社区建设的一些经验，希望可以给其他项目带来一些启发。 Apache ECharts 项目拥有大量的用户群体：在 npm 平台，每周的下载量约为 40 万次；在 GitHub 上，有 15 万个项目依赖 ECharts；来自社区开发的第三方周边项目多达七千多个。连续四年获得 OSC 中国十大最佳人气开源项目称号。 庞大的用户群体与 ECharts 不断精益求精完善产品息息相关。在 2021 年 1 月发布的 ECharts 5 大版本通过五大模块、十五项特性的全面升级，着力加强了图表的叙事能力，让开发者可以以更简单的方式，讲述数据背后的故事。 Apache ECharts 的新特性包括： - 丰富的图表类型：提供开箱即用的 20 多种图表和十几种组件，并且支持各种图表以及组件的任意组合。 - 强劲的渲染引擎：Canvas、SVG 双引擎一键切换，增量渲染、流加载等技术实现千万级数据的流畅交互。 - 专业的数据分析：通过数据集管理数据，支持数据过滤、聚类、回归，帮助实现同一份数据的多维度分析。 - 优雅的可视化设计：默认设计遵从可视化原则，支持响应式设计，并且提供了灵活的配置项方便开发者定制。 - 健康的开源社区：活跃的社区用户保证了项目的健康发展，也贡献了丰富的第三方插件满足不同场景的需求。 - 友好的无障碍访问：智能生成的图表描述和贴花图案，帮助视力障碍人士了解图表内容，读懂图表背后的故事。 ## （二）组织结构与成员构成 Apache ECharts 社区遵循 Apache 软件基金会的组织架构。Apache 软件基金会项目的组织结构非常扁平，主要分为项目管理委员会（Project Management Committee，PMC）以及 Committer。 Committer 是对项目有“写权限”的人，这也通常意味着，对项目有长期较大的贡献因而项目充分给予信任地赋予了“写权限”。 PMC 成员首先是 Committer，在此基础上，需要对项目的发展建设负责。具体来说，包括发展新的 Committer、PMC，维护项目商标、品牌问题，向基金会定期汇报项目近况等等。Apache 软件基金会项目的大多数决策由项目投票决定，PMC 成员的投票每人一票，具有相同的权重。 除了 ECharts 项目从百度捐献给 Apache 软件基金会之初的项目贡献者，在孵化期间以及毕业后，项目共发展了 4 位新 PMC 成员以及 10 名新 Committer。新加入的成员不仅给项目带来了更多持续贡献的力量，也让来自不同公司、不同背景、不同国家的人共同参与到项目的讨论和发展中，为 Apache ECharts 的多元化健康发展起到重要作用。 ## （三）社区开源治理 Apache 软件基金会奉行“Community Over Code”（社区比代码更重要），因为我们相信，一个健康的社区更有可能为项目的长期发展起到重要作用。 每个社区或许都希望有更多使用者能成为贡献者，但具体要如何去做呢？以下是我们在实践中得到的比较重要的几点： 1. 相信社区力量 项目的核心开发者总是对项目有更深入的理解，但这也往往会给他们带来这样一种误解：比如认为社区贡献的代码质量不够高，审阅、评价他们的代码以及反复的指导时间可能比自己重写还高。不可否认的是，有时候这的确是事实。但是，如果对项目有深刻理解的人不愿花费时间和精力去给不太熟悉项目的人解释更好的做法的话，那么社区的贡献者对项目的理解也永远只能停留在初级的认识程度。相反，如果核心开发者愿意指导社区开发者，虽然一开始花的时间比较多，但是慢慢将更多社区成员发展为项目的贡献者，那么对于项目长期而言，显然是有非常大价值的。 之所以把“相信社区力量”放在第一条，是因为我们相信，对于社区的真实观点（而非宣称的观点）将直接体现在我们处理社区问题的方方面面，也将根本性地改变社区对待项目的态度。建立起彼此信任的前提，是核心团队首先愿意相信社区力量能够带来的价值，以及愿意用实际行动赢得社区的信任。 2. 降低贡献门槛 另一方面，对于新的贡献者而言，提出第一个 Pull Request 也是需要很大勇气的：我只不过是一个才接触这个项目一星期的小白，我真的有可能发现一个 bug 并修复了它吗？我的 PR 会不会把一个这么多人用的项目搞挂了？如果我的 PR 被拒绝了，会不会很丢人？ 从 Apache ECharts PMC 的角度，这显然是多虑了。因为我们认为：对项目不同了解程度的用户可以为项目提供不同程度的帮助，即使是初学者也可以帮忙修复一些简单的问题；项目有自动持续集成测试，并且 PR 在合入前一定会由项目 Committer 通过，并且在发布前进行仔细测试；项目 Committer 会尽力在 PR 中指导如何修改，而不是第一时间关闭 PR。 但是，用户未必知道我们的想法。因而，更重要的是，为了让社区开发者明白他们的担心是多虑了，我们还需要用行动来做出改变。比如，我们为一些 issue 增加了难易程度的标签，引导 issue 的提出者以及其他想要为项目做贡献的开发者从容易的 issue 做起。这不仅可以让提出 issue 的人更快地解决自己的问题，也能让开发者增加提 PR 的信心，逐步完成更具挑战的任务。 并且，社区应该对于非源码的贡献（比如文档、教程、宣传等）给予认可，因为它们对一个产品的价值同样是非常大的。 此外，我们还通过文档、文章、微博、视频等方式，让开发者了解以上这些信息，让为项目做贡献这件事不再神秘而艰难。 3. 提供优质产品和服务 一个好的产品本身对于提高贡献意愿显然是至关重要的。开发者通常都是因为对一个项目有需求、或喜爱一个项目而开始他们的首次贡献。 但是，对于开源产品来说，往往容易忽视的，是对服务的重要性的认识。如果一个项目的核心团队对用户怀着“你一个免费用户有什么资格要求我们提供优质服务”的心态，那么这个项目很可能会失去用户，更何谈吸引开发者。虽然由于人力有限，我们无法在第一时间解决所有用户的需求，但是我们仍然可以做到及时给出反馈，甚至让用户自己参与到贡献中，加快问题的解决。 另外，有些时候我们觉得没有精力解答用户问题也是因为一些很初级的问题频繁被问及。相比于埋怨用户为什么连这么基本的问题都要问，我们不妨反思一下自己的文档是不是做到了很好的可发现性，从根本上解决这些问题才是改善用户体验的关键。 4. 对社区贡献及时给出正反馈 虽然看起来非常简单（事实上也的确很简单），在 PR 合入评论中的一句感谢，相比于网页上“PR 已被合并”的冰冷说明，更可能让贡献者感性地认识到自己贡献的价值，继而可能在将来为项目贡献更多。 诸如此类的例子还很多，很多时候它们都不怎么花时间或金钱，却行之有效。理由也很简单，因为大多数人都需要得到他人的认可（而他们也的确值得这点）。我们需要的只是在处理社区问题的时候多从“体验”而非纯粹理性的角度去思考。当然，你的确可以将此作为一种“技巧”，但是我们相信，发自内心地认同社区贡献是一切社区经营的关键（参考第一条）。 ## （四）小结 以上是 Apache ECharts 在 2021 社区建设方面的一些心得，但我们也相信这些理念在很大程度上和其他项目也是相通的，并且其中很多也是已经有不少项目在实际践行着的。我们希望在即将到来的 2022 年，在社区的共同治理下，将 Apache ECharts 带到一个新的高度。