文章目录
- [从 LaunchBadge 到 transact-rs：SQLx 社区迈出可持续治理的第一步](#从 LaunchBadge 到 transact-rs：SQLx 社区迈出可持续治理的第一步)
从 LaunchBadge 到 transact-rs：SQLx 社区迈出可持续治理的第一步
近日，SQLx 正式发布 0.9.0 版本，相较于新增的功能，本次更新最引人关注的是 SQLx 仓库迁移到新的组织 transact-rs。作为一个长期深耕 Rust 生态的技术观察者，我来聊一聊这到底发生了什么事。
事情的前因后果
长期以来，SQLx 隶属于 LaunchBadge 这家商业公司，是该公司旗下的开源产品。
在 2020 年 12 月的时候，LaunchBadge 宣布将推出 SQLx Pro 商业计划，计划将 MSSQL、Oracle 等企业级数据库驱动作为付费功能。
站在开源维护与行业现状的视角来看，这次商业化尝试是可以理解的，也是绝大多数底层开源基础设施项目的无奈选择。
SQLx 作为 Rust 生态的标杆级数据库 crate，其维护成本极高的，比如多数据库适配、跨版本兼容、漏洞修复、新特性迭代等，这些都需要核心开发者持续投入大量时间精力。
因此，LaunchBadge 试图通过开源基础功能+付费企业功能的模式，平衡高昂的维护成本、实现项目可持续商业化运营，这在当时也得到了部分开发者的理解。
后续在 2022 年 1 月，官方再次调整商业化策略，放宽了部分限制：将 MSSQL 驱动改为 AGPL 开源协议开放，仅保留专属商业授权服务，不再完全闭源售卖。但这次策略调整依旧没能挽救商业化颓势，核心问题并未解决。
遗憾的是，这场商业化尝试最终还是失败了，SQLx Pro 的规划也随之完全搁置了。究其原因，一方面是 Rust 企业级商业化生态尚未成熟，愿意付费的企业级客户体量极小，市场需求不足以支撑商业化盈利；另一方面，SQLx 社区对这种商业化模式也有所抵触，甚至还产生了分裂，比如出现了 fork 项目 sqlx-oldapi。
SQLx Pro 计划搁置之后，LaunchBadge 调整公司整体业务重心，彻底退出 SQLx 项目的日常维护。之后，这些工作全部由核心社区开发者无偿承担。
在这次的发布公告 discussions/4271中，也印证了这一点。
这次迁移仓库的主要原因是 SQLx 已经有好几年不是由 LaunchBadge, LLC. 所有或维护了，并且从那以后非正式地转移至其主要作者的集体所有。
可以说，这次的更新标志着 SQLx 彻底剥离商业属性，完全回归开源，正式进入社区自治的时代。
SQLx 的困境
在 Rust 数据库工具生态中，SQLx 拥有绝对的头部影响力，我们通过主流开源库 Star 数据可以直观对比：
| 项目 | GitHub Stars |
|---|---|
| SQLx | 17.1k ⭐ |
| Diesel | 14.1k ⭐ |
| SeaORM | 9.7k ⭐ |
与其受欢迎的程度相比，SQLx 却始终面临着人手匮乏。社区运营、文档建设等几乎处于空白的状态。
最直观的体现是，这次 0.9.0 发布了多数据库/多租户功能与 sqlx.toml 配置文件支持。然而由于文档缺失，没有任何官方教程、实操指南可供参考，唯一的学习渠道就是手动翻阅官方仓库的 examples 示例代码。
反观竞品，Diesel 与 SeaORM 拥有完善的官方文档、场景示例、活跃社区问答。这些都是 SQLx 所缺失的、顶级开源项目必备的社区运营与文档建设能力。
当下 SQLx 社区的现状十分矛盾：顶级热度、顶级使用率，却搭配着极小的核心维护团队，这就是现阶段 SQLx 面临着的发展困境。
结语
总而言之，这次仓库的迁移对于 SQLx 绝对是一件好事，是社区迈出可持续治理的第一步。随着，项目的维护权回归于核心维护者，在未来，也期待 SQLx 社区能够补齐文档短板、完善社区规范、迭代更多实用能力。