夜天之书

译序

我在此前的多篇文章中讨论了商业开源的话题：

• 《企业开源的软件协议模型实践》
• 《企业实践开源的动机》
• 《商业源码协议为何得到 HashiCorp 等企业的垂青？》
• 《企业如何实践开源协同》
• 《中国不缺好的开源开发者》“商业探索与可持续”一节
• 《开源不是商业模式》
• 《诱导转向的伪开源战略》
• 《免费增值的商业模式》

这些讨论当中观点的源头，除了我在商业开源公司的工作经历以外，也有对国外企业主和律师的内容的理解。其中，撰写了《Open Source for Business》（中文版为开放原子开源基金会律师刘伟翻译的《商业开源》）的大律师 Heather Meeker 的观点尤为重要。早在夜天之书 #6 一文里，我就引用过 Heather Meeker 的观点。

今年五月份前后，我读到了 Elastic License 2.0 and the Evolution of Open Source Licensing 一文。它是 Heather Meeker 律师带头撰写 Elastic License 2.0 协议背后的故事和自述。我深感它对于近五年商业开源软件形势发展的影响，于是向 Heather Meeker 申请了翻译本文的授权。今天终于有时间完成翻译，希望能帮助国内关注商业开源的企业家、开发者以及律师，了解发生在北美软件行业的一系列变化。

以下原文翻译。

过去数年，我从参与 Perl 6 和 Apache Flink 等项目出发，逐步进入到开源的世界当中。我在 2019 年成为 Apache Flink Committer，2020 年成为 Apache Curator 的 PMC 成员，2021 年全力投入 TiDB 社群的建设，2022 年成为 Apache 软件基金会（ASF）的正式成员和孵化器导师并接连帮助三个开源项目加入孵化器孵化，2023 年成为 Apache ZooKeeper Committer 和 Apache Pulsar PMC 成员。

在这个过程里，我持续接触到了风格各不相同的开源社群和开源开发者，并逐渐认识到中国开发者是开源运动的中坚力量之一：中国不缺好的开源开发者。

然而，当下大部分人讨论和评价中国开源的现状时，往往会认为中国开源距离全球主流水平仍有较大差距。《中国信息化周报》撰文提到，中国开源“整体呈现‘散似满天星’之势，还未形成‘聚似一团火’的强大合力”。

立足现状，我想以一个普通的开源开发者的视角，分享我所遇见的高水平中国开源开发者的形象，进而讨论从开发者个人出发，为建设好中国开源做贡献的几个可能的探索方向。

当地时间 8 月 10 日，知名开源软件公司 HashiCorp 发布一则公告，称其原先在 Mozilla Public License 2.0 下发布的 Terraform、Consul 和 Vault 等多款软件，将在未来的版本中改为使用商业源码协议，即 Business Source License 1.1 来发布。

此前，已有其他知名开源软件公司也改用或从一开始就使用商业源码协议许可其源码公开的软件。

• MariaDB 公司的产品 MaxScale 数据库代理；
• CockroachLabs 公司的产品 CockroachDB 数据库；
• Lightbend 公司的产品 Akka 框架；
• Materialize 公司的产品 Materialize 流数据库；
• Outline 公司的产品 Outline 知识库。

本文首先介绍商业源码协议的由来和内容，进而以剖析选择该协议的公司和软件的方式讨论其作用。最后，从企业开源的动机和利益权衡出发，讨论为何 HashiCorp 等一众所谓开源软件公司，最终都走向带有商业保护条款的源码公开协议。

许多语言的高性能程序库都是建立在 C/C++ 的核心实现上的。

例如，著名 Python 科学计算库 Pandas 和 Numpy 的核心是 C++ 实现的，RocksDB 的 Java 接口是对底层 C++ 接口的封装。

Rust 语言的基本目标之一就是替代 C++ 在这些领域的位置，为开发者提供 Rust 具备的安全性和可组合性优势。

Apache OpenDAL (incubating) 是 Databend 工程师 Xuanwo 开发的一个 Rust 语言实现的开放数据访问层。它的核心设计支持通过相同的对象存储 API 访问不同的存储服务（Service），并提供可扩展的中间件（Layer）来支持通用的请求重试、限流和指标上报功能。目前，包括 Databend / RisingWave / GreptimeDB / mozilla sccache 在内的多个软件都选用 OpenDAL 作为其存储访问接口。

在 Rust 核心实现的基础上，OpenDAL 提供了 Java / Python / Node.js 等不同语言的 API 绑定（Binding），以支持更广泛的生态利用 OpenDAL 已经完成的工作。例如，使用 Python 绑定，诸多大模型应用库能够在不同云厂商的对象存储服务间无缝迁移，支持用户使用任意对象存储服务。而在开发期间，则可以用内存或文件实现来模拟测试相同 API 的语义。

要在 OpenDAL 实现一个特定语言的 API 绑定，涉及到功能实现、程序库打包和发布等多个环节。本文从功能实现的角度出发，以 Java 绑定为例，讨论 OpenDAL 如何在社群力量的支持下实现 opendal-java 库。同时，重点剖析行内首个完整的 Java ↔ Rust 异步接口互操作的最佳实践。

Apache Kvrocks 是一个分布式 KV 数据库，使⽤ RocksDB 作为底层存储引擎并兼容 Redis 协议，旨在解决 Redis 内存成本⾼以及容量有限的问题，可以作为 Redis 的持久化变体做 drop-in 替换。

Kvrocks 起初是美图内部研发的软件，于 2019 年对外开源并独立运营。2022 年 4 月，Kvrocks 在 Champion 陈亮的推动下进入 ASF 孵化器孵化。在一年的孵化期间，参与者和用户数量翻了两番有余，同时有四名不同的 release manager 各自完成了四个符合 Apache Release 标准的正式版本发布。今年 4 月，Kvrocks 开始发起毕业流程及讨论，并最终于本月走完流程正式毕业。

我在 2022 年初经由姜宁老师提名成为 ASF 正式成员，同时也自动拥有作为孵化器导师参与 mentor 项目的资格。当时正好看到 Kvrocks 的孵化提案，阅读过后认为是个不错的项目，于是自告奋勇成为 mentor 之一。

Kvrocks 是我 mentor 的孵化项目里第一个顺利毕业的。在孵化期间，我实践了自己的开源理念，帮助项目维护者理解 The Apache Way 的理念，也参与了项目本身的开发和发展。应该说，Kvrocks 帮助我验证了很多开源软件及其社群发展的设想。本文从 Kvrocks 孵化历程和我的参与角度出发，介绍 Kvrocks 的社群状况、发展成果和未来方向。

在过去几年的投入和关注下，国产开源社群如雨后春笋一般冒了出来。今天，以 GPT 为首的 AI 新势力接过话题度的接力棒，我们可以在降温周期里回顾一下过去几年间冒出来的国产开源社群都有什么样的成绩，有些什么样共性的问题可以改进。

本文标题是国产开源社群的运营总是画风奇特，这也符合近几年来作为理论上开源社群的主要参与者，即软件开发者们的主流感受。从眼花缭乱的开源营销，到一次性开源、开关式开源的另类创新，再到同质化开源的内卷、打擂台……凡此种种，不仅和开发者熟悉的黑客精神驱动的开源运动有很大的出入，也很难说实现了开源政策想要的达到数字技术创新目标。

支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务。

《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》

从开源社群的建设和运营角度来看，我想造成这个局面的主要原因分成三个方面：运营人员的问题、核心团队开发人员的问题，以及根本的软件产品力问题。

Git 版本管理系统由 Linux 的作者 Linus Torvalds 于 2005 年创造，至今不到二十年。

起初，Git 用于 Linux Kernel 的协同开发，用于替代不再提供免费许可的 BitKeeper 软件。随后，这一提供轻量级分支的分布式版本管理系统得到了开源开发者的广泛喜爱，在大量开源项目中投入使用。如今，Git 几乎是版本管理系统的同义词。

Git 最大的创新就是轻量级的分支实现，鼓励分布式的开发者群体创建自己的分支。每个分支都是平等的，只是原始作者的分支或者实现最好的分支会被社群公认为上游，其他分支被认为是下游。下游分支的修改通过邮件列表发送补丁或 GitHub 发起 Pull Request 的方式向上游申请合并，最后大部分用户从上游分支取得源代码使用。

在这个模型下，如何协同不同分支的开发，当上游发布了多个版本，尤其是并行维护多个发布版本时，如何管理分支，就是一个亟需解决的问题。Git 自身的设计不解决这个问题，也不对此做建模。它只提供分支创建和合并等基本功能，而把具体的分支管理策略留给开源软件的开发者。

上一篇文章《Web API 简介》的落脚点是 Web API 的体验。

Web API 作为许多软件的第一道门面，提升其体验的努力从来没有停止过。今天，围绕 Web API 的开发体验和使用体验，已经成长出一个庞大的软件生态。本文以常用的 Web API 开发工具和平台为切入点，介绍当前 Web API 的开发者基础设施。

Application Programming Interface (API) 即应用程序接口。顾名思义，它是开发者访问应用程序的接口。

例如，你可以通过以下命令查询 GitHub 上特定代码仓库的元数据信息：

1

curl https://api.github.com/repos/apache/pulsar

GitHub 会返回以下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "id": 62117812,
  "name": "pulsar",
  "full_name": "apache/pulsar",
  "private": false,
  "size": 185304,
  "stargazers_count": 12577,
  "watchers_count": 12577,
  "language": "Java",
  "visibility": "public",
  "forks": 3269,
  "open_issues": 1197,
  "watchers": 12577,
  "default_branch": "master",
  // ...
}

本轮开源之风吹起迄今数年，最大的影响还是越来越多的商业公司开始探索开源方法能够如何改变自己的经营策略。

开源策略循序渐进分成使用、参与和发起。在发起开源项目实践一线的，一个是打着开源旗号的创业公司，另一个就是大型企业尤其互联网企业（大厂）。

前者我在过去的文章里已经详细讨论了他们的动机、面临的风险和应对策略。

本文将关注大厂发起的开源项目的共同特点，讨论围绕这样的开源项目聚拢起来的企业研发团队、市场运营团队、用户开发者之间常见的认知失配问题。值得说明的是，这些问题虽然是大厂开源常见的问题，却不是大厂开源独有的问题，对其他开源项目的建设也有参考意义。