夜天之书

今天，在许多开源软件项目乃至任何稍带开放性的项目的宣传中，我们经常能看到营销内容包含“共建”的字样，似乎说了这个魔法的词汇，项目就能迎接纷至沓来的“共建者”，其乐融融地“一起做大蛋糕”。

然而，现实情况却是作为被营销对象的开发者日渐对这个词失去兴趣到产生反感。一眼看到某个项目营销言必称“共建”，心里就默默给它扣分拉黑甚至拉黑。共建的神话是如何产生的，为什么这个口号今天不能吸引和凝聚开发者呢？

Community of Peers 可以翻译成『同侪社群』，意即社群由地位相同的成员组成，这是 Apache 软件基金会（ASF）的开源理念之一。

ASF 强调个体组成社群，每个成员代表他们自己而不是其所属的组织。不管成员是否受雇参与贡献，社群视角下他们都是一视同仁的志愿者。尽管只有 Committer 才有合并代码的权限，只有项目管理委员会（PMC）成员才能对项目的关键决议投有效票，但是除此以外，成员内部是真正平等的。ASF 的开源项目不存在『仁慈的独裁者』，项目管理委员会主席（PMC Chair）也只是承担代表项目向董事会报告的职责，而不意味着其他独特的权限。

这样的理念非常符合传统文化所推崇的『和而不同』与『周而不比』。理解这一点，能够帮助我们在参与认同『同侪社群』理念的开源社群的时候如鱼得水；相反，如果一味追求『和光同尘』，或者把等级观念带到这些社群当中，则容易寸步难行。

上周末在给 Apache Ratis 的代码库上 Maven Wrapper 的时候，项目作者 @szetszwo 对 Pull Request (PR) 当中代码的合规问题和实现问题提出了一些问题。虽然这些问题并不难回答，但是我第一时间的反应却是“这么明显的答案，实在是懒得回复”。进而我又想到，如果是线下集中办公或者面对面 workshop 的情形，这些问题不到五分钟就能讨论清楚，而这两类不同环境当中开发者的表现差异，正好是接触和适应远程工作与开源协同的一个门槛。由此，我想讨论一下远程工作、开源协同与饱和沟通的问题。

去年十一月，我成为了 Apache Pulsar 社群 Committers 的一员。

成为 Committer 之前和之后，我都积极参与了代码仓库上 Issue 和 Pull Request (PR) 的处理回应和评审。去年十二月期间，我把未解决的 Issue 和 PR 数量分别从接近 2000 个和 400 个，在动态增长的情况下缩小到了小于 1000 个和接近 200 个。

关于如何高效地、分门别类地处理社群积压的议题和补丁，我可能会用另一篇文章来讨论。本文想讲的是在这个过程里我产生的另一个想法，那就是如何分析在这类过程中产生的活动，从而判断社群的健康情况呢？

我在《企业开源该选什么软件许可证？》一文当中，已经从软件许可证的角度讨论过不同协议对企业开源的意义。

不过，那篇文章主要是从许可证内容出发的，即先给定了协议，分析完协议细节，再判断是否符合企业和计划公开的软件的情形。本文从企业开源的不同诉求和风险出发，结合现存的企业组织实践，重新讨论源码公开第一步就要面临的选择软件协议问题应该如何决策。

首先说一下结论：最终我选择了基于 Arch Linux 的 Garuda Linux 发行版作为基础来搭建自己的 Linux 开发机。

燃烧了过去一周的空闲时间，我终于定制好了自己的 Linux Desktop 环境。

虽然 Linux 经常被拿来跟 Windows 和 Mac OS X 相比较，但是 Linux 本身只是一个操作系统内核，为了满足用户能作为日常桌面系统使用的需求，还需要添加很多额外的功能。例如，作为内核的 Linux 只提供了识别网卡与其通信的能力，具体如何建立和维护网络链接，如何在开机时自动连接，如何设置网络代理，不同于 Windows 和 Mac OS X 有成熟友好的图形管理界面，Linux 的用户是需要自己搭配定制的。同样，硬盘分区、格式化文件系统、设置引导程序、安装显卡驱动和配置输入法也是如此，需要 Linux 用户自行定制。

这种定制，还不是简单的只有一种办法实现，所有人都有一致的体验。由于 UNIX 哲学里的机制与策略分离，以及 Linux 生态中大量软件是自由软件的缘故，用户经常会发现“解决问题的办法不止一种”。甚至极端一些，“解决问题的框架”也不止一种。以输入法为例，Linux 生态的输入法框架至少包括 IBus 和 Fcitx5 两种。只有框架显然是不足以完整使用输入功能的，因此还需要有对应的输入法实现，输入法在不同的图形化界面（框架）下的集成，以及补充输入法能力的词库和其他支持。

这样的环境催生了 Linux 生态的两大特点。

其一是 Linux 生态中的软件往往是开放源码的。这不仅仅是 GNU/Linux 的出生带来的号召力，也是面对种类繁多的生态的最佳选择。例如，在其他桌面系统和手机系统上都广为人喜爱的搜狗输入法，在 Linux 生态当中只支持有信创动力加持的 Ubuntu 系列系统，且仅提供 deb 安装包和仅兼容 Fcitx 输入法框架。在 Ubuntu 上游试图把默认输入法框架从 Fcitx 改成 Fcitx5 的时候，搜狗一家公司没有人力支持，也未开源代码允许社群支持，最终一再拖延上游的更新计划。反观开放源码的 Rime 输入法，则在第一时间得到社群爱好者的支持，社群共建完成了对新框架的集成。

其二是 Linux 存在数量巨大的发行版提供商。前面提到，要想基于 Linux 内核搭建一个完整的桌面环境或服务器，需要做一系列的定制化。虽然这种定制化给予了用户极大的自由，以至于近乎每个问题都不只有一种解决方案，但是很多时候，用户只是想要一个能够满足桌面环境下个人需求，或服务器环境下生产需求的，类似 Windows 或 Mac OS X 的集成系统。Linux 发行版主要的工作，就是打包一系列应用软件和工具链，提供给用户一个开箱即用的“操作系统”。

在所有 Linux 发行版当中，占据主要份额的是 Arch Linux 系和 Ubuntu 系。

Ubuntu 发行版由 Canonical 公司提供商业支持，提供了用户友好的图形化安装界面，并且针对尝鲜用户、个人桌面用户和企业服务器用户设计了专门的开箱即用路线。由于 Ubuntu 已经定制了相当部分的应用框架和应用软件，Ubuntu 系的其他发行版更像是不同品牌商在预装 Windows 操作系统之后提供一些自己的捆绑软件。

相较之下，完全由社群维护的 Arch Linux 发行版奉行极简之道。它只提供最基础的安装程序和 AUR 中央软件库，并辅以完善的 Wiki 文档帮助用户自行定制 Linux 系统。Arch Linux 系的发行版除了都使用 AUR 软件库以外（甚至 Manjoro Linux 都选择了自建软件库），从图形界面到每个功能软件的选择，都可以是大相径庭的。

从上面的例子当中，我们可以看到，开源软件的用户群体明显的分成两类：一类是使用 Arch Linux 发行版的，追求自由使用和修改软件，也有意愿和能力做定制化的，我们可以称之为黑客（Hackers）；另一类是使用 Ubuntu 发行版的，期望提供商直接交付一揽子解决方案的，或者在商用层面需要乙方兜底的，我们可以称之为顾客（Customers）。

开源软件的商业化，主要瞄准的是顾客的需求，通过满足顾客的需求收费。黑客群体往往只在生态繁荣上做贡献，并不直接参与商业化的进程。

春节在家整理存书，发现了当时在拼多多做业务开发工作的时候，用来帮助理解互联网企业服务架构的若干书籍。这些书里的技术方案可能有一定的落后，但是对于帮助新入职场的互联网公司程序员，了解一个典型的互联网企业核心服务架构，以及治理服务和分化出数据团队的过程里会发生的技术服务体系变化，还是很有帮助的。这里做一个分享。

自由软件运动已经发展了近四十年。从最初的 GNU 工具集，到 Linux 操作系统，再到 OpenJDK 和 Telegram 等软件，使用 GNU GPL 系列许可证的自由软件在许多领域当中发挥了关键乃至不可提到的作用。

然而，GPL 系列许可证本身，尤其是 3.0 版本经由律师之手重新修订发布以后，其内容已经很难为开发者所理解。尤其是具体条款的拟定背景，GPL 系列许可证不同的版本的区别机器动机，单从条款本身去分析，很容易让人摸不清头脑。

其实，贯穿 GPL 系列许可证的理念，是每个版本都包含或隐式包含的讨论软件自由的序章。自由软件运动的发起人 Richard Stallman 正是出于对软件自由的追求，才撰写了 GNU 通用公共许可证（General Public License, GPL）。从软件自由的角度出发，我们才能更好地理解自由软件运动的目标，以及 GPL 系列许可证条款的意义。

前段时间，我出于兴趣试着做了一个需要登录鉴权才能访问的个人网站，最终以 Docusaurus 为内容框架，Next.js 做中间件，Vercel 托管网站，再加上 Auth0 作为鉴权解决方案，实现了一个基本免费的方案。这里做一个分享。