本文以我正在做的 AI 知识库项目为例，介绍企业中如何同时维护一个开源版本和一个闭源企业版本。
什么是 Open Core 模式
Open Core 是一种成熟的商业模式：核心功能开源，高级功能闭源收费。
知名案例：
- GitLab：社区版开源，企业版闭源
- Metabase：基础版开源，Pro 版收费
- Sentry：可自部署开源版，也有云端付费版
开源版（Community Edition） 企业版（Enterprise Edition）
├── 基础知识库功能 ├── 开源版全部功能 ← 包含开源版
├── 单用户 ├── 多租户隔离
├── 手动上传文档 ├── 异步队列处理
└── 基础对话 ├── RBAC 权限体系
├── 数据统计分析
├── SSO 单点登录
└── 私有化部署支持
仓库结构设计
两个独立仓库
| 仓库 | 可见性 | 内容 |
|---|---|---|
github.com/你/ai-knowledge | Public | 开源版 |
github.com/你/ai-knowledge-enterprise | Private | 企业版 = 开源版 + 企业功能 |
本地配置两个 remote
# 查看当前 remote
git remote -v
# 开源版（已有）
git remote add origin git@github.com:你/ai-knowledge.git
# 企业版（新增）
git remote add enterprise git@github.com:你/ai-knowledge-enterprise.git
分支策略
开源仓库 (origin) 企业仓库 (enterprise)
master master
└── bugfix/xxx ├── feature/multi-tenant
├── feature/rbac
└── feature/analytics
核心原则：企业版 master = 开源版 master + 企业专属功能
企业专属功能只在私有仓库开发，永远不合并回开源版。
日常开发工作流
场景一：修复 Bug（两边都要）
# 在开源版修复
git add .
git commit -m "fix: 修复文件上传超时问题"
# 同时推送到两个仓库
git push origin master
git push enterprise master
场景二：开发基础功能（两边都要）
git checkout -b feature/url-parsing
# 开发完成后合并
git checkout master
git merge feature/url-parsing
# 推送到两个仓库
git push origin master
git push enterprise master
场景三：开发企业专属功能（只推企业版）
# 切换到企业仓库的本地工作区
# （企业功能建议在企业仓库单独开分支）
git checkout -b feature/multi-tenant
# 开发完成后合并到企业 master
git checkout master
git merge feature/multi-tenant
git push enterprise master # 只推企业版
# ❌ 不执行：git push origin master
一行命令同步两个仓库
在 .git/config 中配置 push 到多个 remote：
[remote "all"]
url = git@github.com:你/ai-knowledge.git
url = git@github.com:你/ai-knowledge-enterprise.git
然后：
git push all master # 一次推送到两个仓库
License 选择
开源版：推荐 AGPL-3.0
# 在项目根目录创建 LICENSE 文件，选择 AGPL-3.0
为什么选 AGPL？
- 个人和开源项目：免费使用
- 企业想基于你的代码做闭源产品：必须购买商业授权
- 有效保护 Open Core 的商业利益
对比其他 License：
| License | 别人可以闭源商用？ | 适合 Open Core？ |
|---|---|---|
| MIT | ✅ 可以 | ❌ 保护力弱 |
| Apache 2.0 | ✅ 可以 | ❌ 保护力弱 |
| GPL-3.0 | ❌ 不行 | ⚠️ 过于严格 |
| AGPL-3.0 | ❌ 不行（网络服务也算） | ✅ 最适合 |
企业版：不需要开源 License
# LICENSE 文件内容
Proprietary Software License
Copyright (c) 2026 Your Name. All rights reserved.
This software is proprietary and confidential.
Unauthorized copying, distribution, or use is strictly prohibited.
开源前的安全检查
开源之前必须确认没有敏感信息泄漏：
# 检查历史提交里有没有真实 API Key
git log -p | grep -iE "api_key|secret|password|sk-"
# 检查有没有把 .env 文件提交进去
git ls-files | grep .env
必须在 .gitignore 中忽略的文件
# 环境变量（绝对不能提交）
.env
.env.local
.env.production
*.env
# 数据库文件
*.sqlite
*.db
# 上传的文件
uploads/
# 日志
logs/
*.log
提供 .env.example 给开源用户参考
# .env.example
OPENAI_API_KEY=your-api-key-here
OPENAI_BASE_URL=https://api.openai.com/v1
DATABASE_PATH=./data/knowledge.db
PORT=3000
版本管理规范
开源版和企业版独立版本号，互不影响。
# 开源版发布 v1.0.0
git tag v1.0.0
git push origin v1.0.0
# 企业版发布 enterprise-v1.0.0
git tag enterprise-v1.0.0
git push enterprise enterprise-v1.0.0
推荐的版本号规则（语义化版本）
v主版本.次版本.补丁版本
v1.2.3
主版本：不兼容的重大变更
次版本：新增功能（向下兼容）
补丁版本：Bug 修复
团队协作中的注意事项
权限控制
| 人员 | 开源仓库权限 | 企业仓库权限 |
|---|---|---|
| 核心开发者 | Write | Write |
| 社区贡献者 | Fork + PR | ❌ 无权限 |
| 实习生 | Read | ❌ 无权限 |
代码审查流程
- 开源版：所有 PR 必须经过 Review，因为是公开的
- 企业版：内部 Review，关注企业功能的安全性和多租户隔离
不要做的事
# ❌ 不要把企业功能的代码复制粘贴到开源版
# ❌ 不要在开源版的 commit message 里提到企业功能
# ❌ 不要把 .env 里的真实 key 提交到任何仓库
# ❌ 不要在开源版中留下注释暗示"企业版才有此功能的完整实现"
总结
日常开发
↓
修复 Bug / 基础功能 → git push origin master && git push enterprise master
企业专属功能 → git push enterprise master（只推企业版）
↓
发布开源版：git tag vX.X.X && git push origin vX.X.X
发布企业版：git tag enterprise-vX.X.X && git push enterprise enterprise-vX.X.X
Open Core 模式的本质：用开源积累用户和口碑，用企业版变现。开源版越好用，企业版才越有人付费。所以开源版不是减配版，而是真正可用的完整产品，企业版只是在此基础上叠加了企业场景才需要的功能。
