OpenSIPS 引入“贡献模块”机制
内容提要
OpenSIPS 新增 modules-contrib 目录，用于收纳社区贡献模块。核心团队仅监督集成合规与明显安全问题，不再负责完整审查和功能验证，维护责任回归作者与社区。贡献模块默认不编译安装，需显式构建，不影响现有部署，成熟后可移入常规模块目录。此举旨在减轻核心团队压力、加快社区功能进入主干，但成效取决于社区维护意愿与审查执行力度。
延伸解读
维护责任重新划分的实质
OpenSIPS 将模块分为核心维护与社区维护两类，贡献模块的缺陷修复、新特性与支持主要由作者和社区承担。核心团队仅监督许可证、文档、构建合规及明显安全问题，完整审查与功能验证不再必要。这实质是把“谁的代码谁维护”的隐性规则显性化，缓解核心团队因 PR 增多带来的长期维护压力。
对现有部署的零影响设计
贡献模块默认不编译、不安装，使用与常规模块相同的 API 和配置方式，但需通过 make modules-contrib 或单独指定模块构建。Debian/RPM 打包也独立为 opensips-modules-contrib 等包。这意味着现有生产环境升级时不会被动引入未充分验证的组件，运维方可在需要时显式安装，风险可控。
过渡层机制的关键变量
modules-contrib 被设计为可流动的过渡层：模块经充分测试和社区采纳后可移入常规模块目录，转由核心团队维护。但机制成效取决于两个变量：社区是否愿意长期维护自己提交的模块，以及核心团队能否坚持审查标准、避免该目录沦为低质量模块集中地。若执行不力，可能仅起缓冲作用而非推动生态。
值得关注的生态观察窗口
对评估 SIP 基础设施的团队而言，modules-contrib 目录的实际活跃度可作为观察 OpenSIPS 社区生态健康度的窗口。该机制在 Asterisk、FreeSWITCH、Kamailio 等项目中也有类似困境背景，OpenSIPS 以独立目录加独立打包开出中间路径。后续可关注贡献模块的更新频率、缺陷修复响应及移入常规模块的数量。
Q&A
OpenSIPS 新增的 modules-contrib 目录是做什么用的？
modules-contrib 目录用于收纳由社区主导开发与维护的贡献模块，与核心团队维护的常规模块（modules/ 目录）分开管理。
贡献模块和常规模块在维护责任上有什么不同？
常规模块由核心开发团队维护；贡献模块由作者与社区承担主要维护工作，核心团队仅以“尽力而为”的方式监督集成合规性（许可证、文档、构建要求）并排查明显安全与稳定性问题，不负责完整代码审查和功能验证。
贡献模块默认会被编译安装吗？对现有部署有影响吗？
不会。贡献模块默认不编译也不安装，既有部署环境在未显式安装新包的前提下不受任何影响，升级不会被动引入未经充分验证的组件。
如何单独编译和安装某个贡献模块？
可以使用 make modules=modules-contrib/<模块名> modules-contrib 进行编译，再用 make modules=modules-contrib/<模块名> install-modules-all 安装。例如 cachedb_perf 模块即可按此方式单独构建安装。
贡献模块以后有可能变成常规模块吗？
有可能。贡献模块若经过充分测试、审查并被社区采纳，后续可被移入常规的 modules/ 目录，转为由核心团队维护，因此 modules-contrib/ 更像过渡层和观察区，分类并非永久标签。
OpenSIPS 为什么要引入贡献模块机制？
因为新模块 PR 数量持续上升，合并模块意味着核心团队要接手长期维护与用户支持，而团队规模有限。新机制将维护责任明确分给作者与社区，旨在减轻核心团队压力、加快社区功能进入主干。
贡献模块在打包分发上是怎么处理的？
Debian 与 RPM 打包基础设施已更新，贡献模块以两类软件包分发：opensips-modules-contrib 聚合所有无外部依赖的贡献模块（Debian/Ubuntu 上可用 apt install opensips-modules-contrib 安装），opensips-module-contrib-<module> 则面向依赖外部库的单个模块。
贡献模块机制可能面临哪些风险或挑战？
其效果取决于两个变量：一是社区是否真的愿意长期维护自己提交的模块，二是核心团队能否坚持审查标准、避免 modules-contrib/ 沦为低质量模块的集中地。若执行不力，该机制可能仅起到缓冲作用而非推动发展。
