夜天之书

随着应用程序从单体走向分布式微服务架构，追踪（Trace）请求在各个模块间的流转变得越来越重要。然而，现有应用系统还没充分认识到分布式追踪的价值和必要性。这很大程度上是因为生态当中缺乏一个可靠、高效且易用的分布式追踪方案。

Rust 生态尤其如此。作为一个新兴的语言生态，可供 Rust 开发者选择的追踪框架并不多。目前常用的 tokio-rs/tracing 库存在明显的生态割裂、配置负载和运行低效的问题。在研发 ScopeDB 的过程中，我们深刻认识到分布式追踪对系统可观测性及问题排查的重要性。为了解决 Tracing 存在的问题，我们基于现有开源软件分叉开发维护了 Fastrace 框架。

Fastrace 经过生产环境的高压检验，可为用户提供一致且简单的 API 体验，并能与现有的 Rust 生态无缝集成，尤其是提供了高效丝滑的 OpenTelemetry 集成体验。以下是使用 Fastrace 追踪请求的简单示例：

1
2
3
4

#[fastrace::trace]
pub fn send_request(req: HttpRequest) -> Result<(), Error> {
    // business code
}

ScopeDB 线上环境中一个分布式追踪的可视化实例：

本文先介绍分布式追踪及其价值，然后讨论 Fastrace 如何解决此前 Rust Tracing 方案中没能解决好的问题，并给出一个完整的日志追踪方案。最后，分享 Fastrace 开源背后的故事。

上周，我在视频号（啸飞吟声）上做了一期连线直播，讨论包含企业开源软件变更协议在内的商业开源相关问题。其中，有一个重要的内容，就是作为开源软件的使用者，面对上游开源软件无法持续维护，或者企业开源的软件修改协议等潜在风险时，如何保障自己的使用安全。

在此前的一篇博文《开源软件有断供的风险吗？》当中，我已经说明了开源协议不可撤销地授予接收者使用、复制、修改和分发软件的权利，以及作为开源软件的使用者，如何判断开源依赖需要自己付出哪些投入。不过，这篇文章主要是讨论抽象的依赖分类，以及开源协议在源码授权上的不可撤销性。最近 KubeSphere 删除软件文档、已发布镜像等行为，实际上受影响的主要是开源制品，即基于开源软件源代码构建的二进制软件包等等。

本文讨论开源软件使用者如何可靠地依赖开源制品。

在年初的一篇关于商业开源的博文当中，我介绍了在开发商业软件的过程中，衍生出开源公共软件库的模式。在那篇博文里面，我只是简单罗列了相关开源库的名字及一句话总结。近期，我会结合商业开源实践的最新进展，对其中一些案例做详细展开。

首先介绍的是 Cronexpr，一个小巧的 Rust Crontab 解析库。其背后的开源模式，我称之为“涓滴开源”，即将商业软件依赖的微小但完整的功能模块开源出来，供其他人使用。

自去年八月以来，我一直在 Apache 软件基金会（ASF）担任品牌管理委员会成员。近期，上海开源信息技术协会组织的首次“上海开源创新菁英奖”，评奖结果包括了若干 ASF 旗下的开源项目。然而，结果公布文章在引用这些项目时，存在部分对 ASF 品牌的误用。经由一位 ASF 中国成员报告，ASF 品牌管理委员会处理，以及与上海开源信息技术协会沟通后，今天发布了《关于 Apache 软件基金会有关项目的获奖信息更正》的公告，澄清了相关误用。

我由此想到，在过去很长一段时间内，由于 ASF 开源项目潜在的商业价值，许多公司基于 ASF 开源项目构建自己的商业产品或服务。在各个场合的宣传当中，这些公司不时有意或无意地违反 ASF 的品牌使用政策，主要表现是错误地将 ASF 品牌与其商业产品或服务关联起来。这种行为不仅误导了公众对 ASF 品牌的理解，也可能侵犯了 ASF 的知识产权。

激励创新，服务和推动高质量发展需要保护知识产权。本文结合我一年以来的经验，简单介绍开源项目的知识产权，ASF 的商标品牌政策，以及常见的侵权行为。

下周五到周日，也就是 7 月 25 日到 27 日，一年一度的 Apache 社群峰会（CommunityOverCode Asia 2025）将在北京海淀举行。

峰会的最后一天，我和 Rust 社群的伙伴们组织了 Rust 分论坛，讨论开源生态以及 Apache 项目中 Rust 的发展和应用。同样在 27 日的早晨，我会做一个题为《七年之痒：我的 Apache 故事》的主题演讲，介绍 Apache 软件基金会如何深刻地影响了我的开源之路，以及每一位工程师如何从 Apache 社群中受益。

关注峰会的朋友可能会发现，今年峰会在企业赞助商之外，还开辟了个人赞助的通道，而我就是第一位个人钻石赞助者。

本文整理自《对话 tison - 新晋国际开源基金会董事，95 后创业者》，但是内容是按照原来设计的问题列表介绍我今年的新关注点，与播客节目实际聊天的内容不完全一致。以下是问题列表：

• 你从什么时候开始想“我要成为一个程序员”这件事情？
• 你参与的第一个开源项目是什么？
• 你对哪一类型的技术更感兴趣？
• 怎么会想到去做 ASF 孵化器导师的，这件事情是不是很耗费精力？
• 如何成为 ASF 董事会成员？
• 中国人获得董事会席位是实力的体现，还是多元化吉祥物？
• ASF 对中国开发者与中国项目的态度是怎么样的？
• 中国人在 ASF 能发挥实际的影响力吗？
• 你现在的初创企业 ScopeDB 是做什么的？
• 为什么 ScopeDB 不是开源的？
• 如何看开源在软件创业中的作用？
• Position Statements by Zili Chen (@tison)

近期若干开源组织进行换届选举。在此期间，拥有投票权的成员往往会热烈讨论，提名新成员候选人和治理团队的候选人。虽然讨论是容易进行的，但是实际的投票流程和运作方式，在一个成员众多的组织中，可能会有不少成员并不清楚。

本文以 Apache 软件基金会（Apache Software Foundation, ASF）为例，介绍 ASF 所采用的投票方式。

最近一个多月没有发布新的文章，我把时间大多投入在实践验证自己在多次演讲中都描绘过的开源孪生模式上。

本文展开介绍上图提及的各个具体实践，并说明这一模式如何可持续发展。

近期，Linux 上游因为受美国出口管制条例的影响，将移除部分开发者的 MAINTAINER 权限，引起了新一轮对开源依赖的重新评估。

关于其中开源精神和社群治理的讨论，卫 Sir 的两篇文章已经讨论得比较清楚（见尾注）。本文主要从软件供应链的角度出发，回应对“开源软件的断供风险”的担忧。

简言之，开源协议只是向用户授权自由使用特定版本源代码。除此以外，大部分开源协议都明确声明不提供维保，更不承诺有一个长期迭代的上游分支。

上周在北京参与了开源社主办的 2024 中国开源年会。其实相比于有点明显班味的“年会”，我的参会体验更像是经历了一场中国开源的年度嘉年华。这也是在会场和其他参会朋友交流时共同的体验：在开源社的 COSCon 活动上，能够最大限度地一次性见到所有在中国从事开源相关工作的人。

我在本次会场上有两个演讲，分别是 Rust 分论坛上分享的《高性能 Rust 编程：如何减少数据拷贝和并发开销》，以及开源运营分论坛介绍的《商业开源如何重塑社群信任》。本文将简要介绍我的分享内容，以及参会的见闻纪实。