夜天之书

许多语言的高性能程序库都是建立在 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",
  // ...
}

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

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

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

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

本文从软件系统、学术论文和出版书籍三个方面介绍研究学习类似 Apache Flink 的流式系统的参考材料。

3 月 31 日，马斯克如约开源了一系列推特推荐算法代码。

前几天，一篇名为《开源商业模式是个伪命题》的文章横空出世，看似犀利的观点却没有引起激烈的反驳。无论是开发专有软件的企业，还是重度投入到开源软件开发的企业，都认同开源本身并不是企业作为软件及服务提供商的商业模式。

行业当中有这样的共识并不奇怪。如果你在国际互联网上搜索『开源商业模式』关键字，其结果从 2016 年起就几乎被『开源不是商业模式』所统治。本文老调重弹，从开源为什么不是商业模式，不是商业模式的开源在企业运作中扮演什么角色，以及围绕开源软件存在哪些商业模式做出讨论。