ClickHouse 社群基于自己的软件制作社群指标的探索，它提供了公开数据集以供访问。

然而，由于遇到了公开数据集表模式缺列，查询执行内存限制，以及数据库只读模式限制等问题，我在过去一周里试着按照 ClickHouse 官方博客的介绍，搭建起了一个属于自有的基于 ClickHouse 的 GitHub 事件数据库。

简单介绍下结果，自建数据集确实解决了上面列举的三个问题。然而，我选择的 16 核 64 GB 内存版本实例在查询性能上还不如 Playground 的性能，只是内存占用大的聚合查询 Playground 可能由于 Quota 限制无法执行。另外，我选择的阿里云上的 ClickHouse 数据库在追上游版本和一些使用体验上还是有所欠缺。最后，日常数据同步的脚本可以在 korandoru/github-adventurer 取用。

当然，我会去做这件事，还有一个不可忽视的原因是我所在的公司本身商业模式就是云上售卖数据处理服务，我希望能够基于云上的服务搭建自己的业务，体验这个流程可能遇到的各种问题。因此，本文不是一个指导手册或者技术指南，而是实现过程中每个环节的杂谈。

开源软件的用户在使用过程中遇到问题时，几乎总是先在自己的环境上打补丁绕过或快速修复问题。开源协同的语境下，开源软件以及维护开源软件的社群统称为该软件的上游，用户依赖上游软件的应用或基于上游软件复刻（fork）的版本统称为下游。上游优先（Upstream First），指的就是用户将下游发现的问题、做出的修改反馈到上游社群的策略。

网络上已经有不少文章讨论上游优先的定义、意义和通用的做法。例如，小马哥为极狐 GitLab 撰写了《Upstream First: 参与贡献开源项目的正确方式》。不过，这些文章往往是站在社群、平台或布道师的层面做笼统的介绍。本文希望从一个开发者的角度出发，由几个具体的上游优先的故事，讨论开发者角度实践上游优先策略的动机和方法。

开源社群存在的目的，主要是制造高质量的开源软件，并促进该软件的使用。为了达到这两个目标，开源社群需要调动参与者的积极性，并且协同背景多样的参与者的贡献，共同修复软件缺陷、改善软件体验、增加软件功能、组织社群活动和发展软件生态。大多数开源社群的环境里，实际进行组织协调工作的成员，就是社群的维护者（Maintainer）。

不同开源社群对角色的定位和命名有着各自的风格。Vim 社群生态丰富，但是 Bram Moolenaar 是唯一的“仁慈的独裁者”。Kubernetes 制作了一套基于 SIG 划分的从 Reviewer 到 Approver 再到 Owner 的体系。Apache 基金会的每个项目都使用 Committer + Project Management Committee 的治理结构。Rust 和如今的 Linux 采用分模块的 Team Maintainer 模式。PostgreSQL 则由整个项目级别的 Core Team + Committer 来治理。

对于刚起步的开源项目而言，这些眼花缭乱的标准背后，其实是一个大致相同的对项目维护者的标准。对于想要深入参与开源社群的人来说，理解了项目维护者的标准，也就明白该做些什么以成为一名维护者了。本文主要对这个标准的不同层面进行讨论，顺带对比上面这些经过演变的不同版本。