Rust 社群何以走到今天?
本文有些标题党,实际想讲的内容,是我从部分 Rust 曾经的核心开发者的自述当中,所发现的 Rust 项目社群开源协同模式发展至今的一些特点。
我会从这些自述发言的内容切入和展开,对比其他社群遇到相似挑战的状况和应对方式,讨论 Rust 项目社群在协同方式维度上走到今天的沿革。
本文有些标题党,实际想讲的内容,是我从部分 Rust 曾经的核心开发者的自述当中,所发现的 Rust 项目社群开源协同模式发展至今的一些特点。
我会从这些自述发言的内容切入和展开,对比其他社群遇到相似挑战的状况和应对方式,讨论 Rust 项目社群在协同方式维度上走到今天的沿革。
昨天的文章里,我介绍了 Async Rust 当前的实现以及一个实现 Async Runtime 需要了解的概念和现有的一些实践。
文章发出后,有评论称 Async Rust 创造性工作,没有可借鉴的经验。诚然,Rust 系统编程语言的定位就决定了它与其他有运行时的语言在设计时存在巨大的不同,同类语言 C 和 C++ 在异步编程方面,受限于语言的历史包袱,相关的支持往往以三方库而不是语言级的支持出现。
不过,Rust 至少可以借鉴自己一路走来的经验。Async Rust 的主要开发者之一 @withoutboats 在今年十月份的时候写了一篇 Why Async Rust 的博文,介绍了 Async Rust 一路发展的沿革和背后的设计决策。也是这一篇文章,帮助我理解了大量 Async Rust 设计的理由,从而融会贯通地写出昨天的文章。
随着软件系统越来越复杂,一个完整的复杂软件动辄几十上百万、甚至上千万行代码,提交记录少说几千,动辄几万甚至几十万。个人再也很难有足够的时间,单纯依靠读源代码和提交历史来理解系统运行的机制。这个时候,设计文档和作者现身说法讨论设计过程,尤其是失败的设计过程,就显得尤为重要。
实际上,我认为国内软件行业前沿的水平已经能跟世界前沿竞争,差的是时间积累的底蕴和人才的绝对数量。例如,全球第一波做数据库的人,到现在几乎都是三五十年经验起步,他们通过师父带徒弟甚至带出徒孙的形式,培养出了一大批领域专业人才。这一壁垒是很难走旁门左道超越的。
所幸开源运动的发展使得我们能够无国界的接触最前沿的软件设计思想和技术实践,我们于是可以对照一个完全开放的软件系统,根据核心开源开发者的介绍,理解这些智慧和经验的结晶。
以下原文,文中的“我”是 @withoutboats 的自称。
绝大多数第一次接触 Async Rust 的开发者所写的 Hello World 程序是下面这样的:
1 | async fn say_world() { |
目前最流行的 Rust Async Runtime tokio 告诉你,只要在 main 函数前加上 #[tokio::main]
这个咒语,再把 main 函数定义成一个 async fn
函数,就可以在程序的任何地方用 async fn
和 .await
语法享受到并发编程的免费午餐了。
但是,这样的解释显然不足以满足相信 Rust 尽可能显式表达所有开销的哲学的人;也就是说,到底 async fn 里的逻辑是怎么被执行的,代码中出现 .await
的时候,Rust 程序实际在执行什么动作。
本文基于具体的异步运行时和并发库代码,介绍支持 Rust 并发模型工作的核心概念。
我在此前的多篇文章中讨论了商业开源的话题:
这些讨论当中观点的源头,除了我在商业开源公司的工作经历以外,也有对国外企业主和律师的内容的理解。其中,撰写了《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 来发布。
此前,已有其他知名开源软件公司也改用或从一开始就使用商业源码协议许可其源码公开的软件。
本文首先介绍商业源码协议的由来和内容,进而以剖析选择该协议的公司和软件的方式讨论其作用。最后,从企业开源的动机和利益权衡出发,讨论为何 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 自身的设计不解决这个问题,也不对此做建模。它只提供分支创建和合并等基本功能,而把具体的分支管理策略留给开源软件的开发者。