第一章 总则¶
第一条 制定依据
本章程依据《量潮科技基本章程》、《量潮云产品研发章程》和《量潮云 DevOps 章程》制定，旨在建立量潮云产品线的开源管理规范。
第二条 目的
为建立量潮云数字资产的开源策略与社区治理规则，在保障核心产品竞争力的前提下推动技术共享与生态建设，特制定本章程。
第三条 适用范围
本章程适用于量潮云（qtcloud）产品线所有面向公众的数字资产开源活动，包括但不限于代码库、文档站、数据档案、工具链、SDK 等。
第四条 定义
（一）开源仓库，指在公开的代码托管平台上设置为公开访问的仓库。
（二）内部仓库，指仅限组织成员访问的非公开仓库，包含核心业务逻辑与未公开数据。
（三）外部贡献，指非组织成员通过 Pull Request 或 Issue 等方式对开源仓库提交的修改与建议。
（四）许可证，指定义仓库内数字资产使用、修改、分发权限的法律文件。
第二章 开源策略¶
第五条 开源决策原则
量潮云数字资产的开源与否按以下原则决策：
（一）核心业务逻辑：包括产品核心的商业模式、定价算法、竞争性数据处理逻辑等，不予开源。
（二）基础设施与工具链：包括 CLI 工具、自动化脚本、构建配置、SDK 等，应当优先考虑开源。
（三）文档与教程：包括产品文档、教程、示例代码等，应当开源以降低用户使用门槛。
（四）数据档案：包括业务分类、资产定义、契约等结构化数据，按 第六条 决定开源与否。
（五）衍生项目：由内部代码衍生出的通用解决方案，经管理层评估后可独立开源。
第六条 数据档案开源规则
数据档案（data/ 目录内容）的开源遵循以下规则：
（一）模式与定义：Schema 定义、分类体系、资产模型等结构性元数据，应当开源。
（二）实例数据：包含具体客户信息、业务量的实际数据，不得开源。
（三）配置与契约：产品端的配置模板与契约定义，应当开源；包含密钥、凭据的配置不得开源。
第七条 许可证选择
量潮云开源仓库的许可证选择遵循以下规则：
（一）代码仓库：默认 Apache-2.0。选择前须评估许可证对商业使用的限制与保护程度。
（二）文档仓库：默认 CC-BY-4.0。
（三）数据仓库：默认 CC-BY-4.0，具体根据数据类型评估选取。
（四）多组件仓库：各组件须明确标注各自许可证，不得在仓库级混用冲突许可证。
第三章 闭源资产保护¶
第八条 冰山之下资产定义
开源仓库对外展示的内容（代码、文档、数据）为"冰山之上"资产。以下内容属于"冰山之下"资产，不得开源：
（一）客户原始信息、项目内部记录、未脱敏的业务量数据。
（二）内部决策过程、管理沟通记录、跨部门协作中的未公开上下文。
（三）处于验证阶段的商业模式、定价策略、竞争性洞察分析。
（四）从内部系统（工作日志、审计记录、员工反馈等）中产生的未公开知识。
（五）未在章程或档案中正式定义的隐性经验和实践方法。
第九条 开源与非开源的边界规则
开源边界的管理应当遵循以下规则：
（一）开源仓库应当仅包含经过审核和脱敏的最终结果，不得包含产生该结果的中间过程与内部上下文。
（二）从内部仓库向开源仓库迁移内容时，应当通过 squash 提交或定向导出，确保不泄露内部上下文。
（三）合作伙伴或客户通过闭源渠道获取的信息，不得以开源方式二次分发。
（四）开源仓库的维护者应当定期审查仓库内容，确保没有暴露"冰山之下"资产的敏感信息。
第十条 护城河维护责任
开源策略的最终目标是建立进攻型护城河，而非防守型护城河。进攻型护城河的核心在于内部创新效率持续高于外部模仿效率：
（一）开源仓库的迭代速度应当始终领先于外部 fork 和衍生项目的跟进速度。
（二）核心团队应当持续投入于"冰山之下"资产的建设（内部治理、数据积累、协作流程），使其难以在脱离内部环境的情况下复制。
（三）开源仓库的版本发布应当与内部知识资产的同步更新相结合，确保外部看到的内容始终是内部已超越的版本。
第四章 仓库管理¶
第十一条 仓库命名规范
开源仓库的命名应当遵循以下规则：
（一）仓库名应当清晰表达其功能或内容，不包含版本号。
（二）与公司内部项目相关的开源仓库，应当使用 qt- 前缀。
（三）工具型仓库应当使用动名词结构（如 qt-deploy、qt-init），库型仓库应当使用名词结构（如 qt-sdk-python、qt-cli）。
第十二条 仓库治理模式
开源仓库应当按以下模式管理：
（一）组织管理：量潮云的开源仓库统一托管在 quanttide GitHub 组织下，不得以个人账号托管。
（二）维护者：每个开源仓库应当至少指定一名维护者，负责仓库的日常管理、Issue 响应和 PR 审查。
（三）合并权限：外部贡献者提交的 PR 须经维护者审查后方可合并。内部成员的 PR 在 CI 通过后可由自身合并。
（四）存档：不再维护的开源仓库应当归档（Archive），README 中注明归档日期与替代方案（如有）。
第十三条 仓库必备文件
每个开源仓库应当包含以下文件：
（一）README.md：项目说明、快速开始、贡献指南入口。
（二）LICENSE：许可证全文。
（三）CONTRIBUTING.md：贡献指南。
（四）CHANGELOG.md：版本变更记录。
（五）.gitignore：Git 忽略规则。
缺少以上任一文件的仓库不得标记为正式发布状态。
第五章 贡献管理¶
第十四条 Issue 管理
开源仓库的 Issue 管理应当遵循以下规则：
（一）Bug 报告须包含复现步骤、环境信息和预期行为。
（二）功能请求须说明使用场景与预期价值。
（三）维护者应当在 7 个工作日内对新的 Issue 做出初步响应。
（四）长时间无活动的 Issue 应标记为"待关闭"并在 30 天后关闭。
第十五条 Pull Request 管理
外部贡献的 PR 管理应当遵循以下规则：
（一）PR 应当关联 Issue，并在描述中说明修改内容与测试结果。
（二）PR 须通过 CI 检查方可合并。
（三）维护者应当在 14 个工作日内完成 PR 审查。
（四）涉及核心业务逻辑的 PR 不得直接合并，须经管理层评估后决定是否纳入内部仓库。
第十六条 社区行为准则
开源仓库应当遵守以下社区行为准则：
（一）尊重所有参与者，禁止人身攻击、歧视性言论和骚扰。
（二）技术讨论应当基于事实和论据，不进行无建设性的争辩。
（三）违反行为准则的参与者，经警告无效后可采取临时或永久封禁。
第六章 版本与发布¶
第十七条 开源版本与内部版本的关系
量潮云开源仓库的版本发布应当遵循以下规则：
（一）开源仓库的版本号与内部仓库的版本号各自独立管理，无需对应。
（二）开源版本可以包含内部版本的子集，但不得包含未公开的商业策略与竞争性分析。
（三）内部仓库的 commit 历史不得直接暴露到开源仓库。从内部仓库向开源仓库迁移代码时，应当通过 squash 提交或定向导出，确保不泄露内部上下文。
第十八条 开源版本的发布流程
开源仓库的版本发布参照《量潮云 DevOps 章程》执行。此外还须满足以下条件：
（一）许可证文件已确认并在仓库根目录存在。
（二）所有第三方依赖的许可证兼容性已评估。
（三）README 已更新并包含版本说明。
（四）CHANGELOG 已区分社区可见的变更与内部变更。
第七章 附则¶
第十九条 章程效力
本章程经公司治理机构审议通过，自发布之日起生效。
第二十条 解释权
本章程之解释，应遵循开放与保护兼顾之基本原则。各项条文不得被解释为阻碍合理的开源社区建设或为开源设置不必要的障碍。