本文结合我近期 Agentic Coding 的经验，讨论这一范式在实践当中可能遇到的问题。
首先说明，以目前 LLM AI 的能力，能够针对任意通用任务生成疑似正确（Plausible）的方案、流程或代码等，是完全可以做到的，但是以此为由声称“某某领域已死”则大可不必。因为从生成似是而非的原型，到实际经得起考验的产品，仍然存在 AI 不能覆盖的鸿沟。不过，如果你的需求并不复杂，似是而非的结果已经可以满足需求，那也很好。
例如在发扬 LLM Writes Plausible Code 的这篇文章里，作者抨击了一个号称 LLM-driven 用 Rust 重写的 SQLite 性能不行，所举的例子是一个简单任务 SQLite 原版花了 0.09 毫秒，但是重写版花了 1815.43 毫秒，也就是上万倍的差距。但是就这个简单任务而言，它也就花了一秒上下。如果你的需求就到这了，难道你会觉得一秒完成任务的这个 Rust 重写的版本有什么不好吗？
去年底读到一篇题为《配置管理：被忽视的技术债务》（下面简称《配置管理》）的文章，文章作者从产品研发的视角出发吐槽了配置管理的一系列问题：
.env 文件管理配置缺乏一致性和安全性同时，文章作者提出了配置分类的几个维度，以及设计配置项时应该考虑的几个问题。
我于是发现，配置系统的设计和不同业务的配置管理问题，确实缺乏讨论。很少有开发者认真思考过配置系统是如何工作的，好像应用程序天然就能自己加载到正确的配置。一旦应用加载到错误的配置，开发者则往往很难说出问题出在哪里。要么怪罪配置有多个来源造成混乱，要么反思配置项的设计不够合理，要么指责配置管理职责不明，莫衷一是。
我有幸在某公司工作时看到过完整流畅的配置系统和管理方案。本文将综合业务研发和配置系统研发两种角度，首先给配置下一个定义，进而为市面上的配置软件做一个分类，最后再针对上面引用的文章提到的问题做逐一评论。
如题，一个常见的问题。正好近期针对问题和相关的议题，我有几个浓缩的观点，写出来以作分享。
一直以来，资本市场常以药品研发来类比软件研发：两者都需要在前期投入巨大的不确定成本研发新品，一旦研发成功，通过专利授权和垄断销售带来的利润，不仅可以覆盖之前投入的研发成本，甚至还有巨大的盈利空间。
其中，新品药物盈利的关键就在于专利保护和垄断生产。一旦配方公开并且允许仿制药流通，药品的价格就会显著下降。由于药品的公益特性，一般而言药品专利会有时间上限，超过时间上限后即成为公共知识可以仿制生产销售。在专利期内，药品研发公司通过前述手段收回成本保持盈利。
商业软件的研发类比大抵相同。企业雇佣开发者做出专有软件之后推向市场，通过收取垄断的授权费和维护费用收回成本实现盈利。目前，没有专门的法律规定软件发布后一定时间内必须公开源码，允许任何人使用。然而，软件开源即扮演了这样的角色：向所有人公开软件源码，允许任何人出于任何目的使用、修改和发布修改后的版本。
药品专利的盈利模式会受到仿制药的直接挑战，同样地，软件专利的盈利模式也会受到开源决策的直接影响。
本文对应我在今年 RustChinaConf 2025 & Rust Global China 大会上的演讲，原标题《最速传说：四个月内基于 Rust 开发服务全球云数据库 ScopeDB》。由于近期我写的另一篇文章也使用了“最速传说”的字样，出于个人写作习惯，我把标题做了改动。
云原生技术方兴未艾已十余年，但是，云上的数据方案大多还只是将基于裸金属集群构建的系统几乎原样的搬到了云上，没能充分利用云上弹性调度的能力，以及云厂商提供的廉价对象存储。
我在开发者的未来：基于云服务构建数据基础设施一文中已经说明为何简单照搬原有架构行不通。
ScopeDB 的出现，既是为了压榨出云资源的所有优势，也是为了压缩大数据时代叠床架屋的数据流水线方案，将分析的能力带给每一个业务团队。
Rust 已经成为新时代基础软件开发的首选。基于可靠的 Rust 语言和繁荣的 Rust 生态，我们在四个月内从无到有开发出了云数据库 ScopeDB 并在全球多个可用区内上线服务客户需求。
在此过程中，我们也将自己对 Rust 生态的需求和改进持续反馈到上游项目社群，并将研发过程中衍生的独立模块以开源库的方式共享出来。
Apache 软件基金会官方已发布新闻稿，宣布 The ASF 的新徽标 “橡树叶”正式启用。本文按照我对新闻稿的理解进行翻译，非逐字翻译。
去年，Apache® 软件基金会（The ASF）宣布，为了更好地体现基金会“社群重于代码”的一贯理念，我们将更新组织徽标（Logo）和品牌体系。今天，我们荣幸地宣布推出全新的 ASF 徽标：橡树叶（Oak Leaf）。
关于 2024 年的相关公告，请参见：
Rust 标准库的 sync 模块提供了一系列并发原语，包括对应原子操作的 atomic 系列，实现 channel 通信的 mpsc 和 mpmc 等，以及对应互斥锁的 Mutex、RwLock 和 Condvar 等。
不过，这些原语都是对应同步编程模型，基于线程阻塞来实现的。如果在 Future 和 async/await 上下文当中使用，可能会因为阻塞运行时调度而成为 Async Rust 的性能瓶颈。甚至 Rust 官方定义了一条 Lints 规则，提示开发者不要跨越 await point 持有同步原语中的互斥锁资源。
换句话说，为了在 Async Rust 上下文中实现各种并发原语，我们必须在标准库 sync 模块以外另做实现。本文从 ScopeDB 开发过程中对并发原语的需求出发，介绍我们为此开发并开源的，运行时无关的异步并发原语库 Mea (Make Easy Rust)。
今天起来就看到 EMQX 将于明年初正式结束开源版产品生命周期。通常我是不评论时事的，不过最近关于产品是否应该开源的议题逐渐触达了国内先做开源产品再考虑商业化的公司，或许是一个整理过往的观点，集中提供相关思考方式的契机。
Confluent 是一家著名的 Apache Kafka 提供商，其创始人在 LinkedIn 工作期间创造了 Kafka 项目，并将其贡献给了 Apache 基金会。这一模式后来也在 Apache 软件基金会（ASF）内被多次复制，即依托于 Apache 顶级项目打造商业产品，对应的商业公司核心成员是该开源项目的维护者或原始作者。
在《应当尊重和保护开源项目的知识产权》一文中，我介绍了 ASF 的商标品牌政策。在 Confluent 创办到发展至今的十余年里，ASF 品牌管理部门就 Confluent 使用 Apache Kafka 等项目的商标品牌的问题和 Confluent 打过多次交道。后来，Confluent 总结出了一份 Apache 品牌指导手册，用于员工培训以避免因为缺乏相关知识导致的侵权行为。
原先，这个指导手册挂在 https://www.confluent.io/apache-guidelines/ 地址上。不过，就在上个月我想引用这个页面，向国内某些厂商说明，可以如何制定员工手册，指导处理 Apache 品牌的时候，我意外地发现这个页面已经无法访问了。
不过，感谢互联网记忆令使 Wayback Machine 的记录，我们还能看到两年前的快照版本。为了介绍这样一个比较彻底的，公司层面可以培训员工遵守 ASF 品牌政策的方式，我写作本文全文引用 Confluent 的 Apache 品牌指导手册（自翻译版）并做锐评。
2019 年，当时的 Baidu Security X-Lab 团队将自己研发的安全计算框架 MesaTEE 捐赠到 Apache 孵化器，并更名为 Apache Teaclave 开始孵化。
时过境迁，当时的 X-Lab 早已不复存在，其孵化提案中引用的 MesaTEE 网站也被其他实体申请占用。甚至，初始成员大多已经离开百度公司，前往新的团队开发新的安全软件。
很长一段时间里，Teaclave 都是所谓“源自中国”的 Apache 孵化项目当中孵化时间最长的项目：
不过，六年过去后的 2025 年，也就是今年，Teaclave 突然复苏。从三月开始时隔两年再次提名新的 Committer 到七月开始筹备毕业，就在一个月后，本周的 Apache 董事会议上，Teaclave 就完成所有流程正式成为 Apache 顶级项目。
本文从这样一个不太常见的开源项目演化历程出发，谈一谈开源生态里的“长期主义”以及如何在开源社群中取得进展。