# 开源发布方案

## 目标

这个方案的目标不是单纯把代码公开，而是把当前项目整理成一个可以稳定吸引用户、形成口碑、为后续商业化导流的开源产品。

适用定位：

- 英文 PDF 听读工具
- 低延迟逐句朗读阅读器
- 普通 CPU 可部署的本地 TTS 阅读方案

## 开源策略

推荐采用“开源核心版，保留商业增强版”的结构。

### 建议开源的部分

- PDF 阅读器基础能力
- 指定位置起播
- 逐句朗读
- 文本高亮联动
- 日间/夜间模式
- 本地 TTS 接入层
- 单机部署能力

### 建议保留的商业能力

- 支付功能
- 配额管理
- 组织与团队空间
- 商业后台
- 高级统计报表
- SaaS 托管平台能力
- 私有部署支持服务

## 许可证建议

### 推荐方案

- `AGPLv3`
- 对商业客户再提供商业授权

这种方式的优点：

- 可以公开传播
- 能限制第三方直接拿去做闭源商业化
- 为后续商业授权保留空间

### 可选方案

- `MIT`

只有在你明确希望项目尽可能广泛传播、并接受别人直接商用时，才建议使用 `MIT`。

## 开源前必须完成的整改

### 安全整改

1. 清理敏感信息
- 去除 [config.py](/home/service/reader_pro/config.py:1) 中的默认数据库密码
- 使用 `.env` 和 `.env.example`
- 检查历史提交中是否已泄露敏感信息，必要时重置密钥

2. 去除弱口令和默认账号
- 禁止初始化默认 `admin/admin`
- 首次启动时要求手动创建管理员

3. 升级认证安全性
- 将 `sha256` 密码哈希替换为 `bcrypt` 或 `argon2`
- Cookie 在 HTTPS 环境下使用 `secure=True`
- 增加基础登录限流

4. 收紧跨域和接口访问
- 不再默认 `CORS = *`
- 对上传、生成、管理接口增加限制

### 仓库整理

1. 删除不应提交的文件
- `audio_cache/`
- 临时日志
- 本地数据库配置
- 历史无关调试文件

2. 增加忽略规则
- `.env`
- 缓存音频
- 上传文件
- 日志
- 本地数据库文件或导出

3. 规范目录结构
- `docs/`
- `deploy/`
- `scripts/`
- `static/`
- `app/` 或保持当前结构但补充说明

## README 建议结构

建议在 GitHub 首页直接讲清楚“是什么、为什么有价值、怎么跑起来”。

推荐结构：

1. 项目名称
2. 一句话介绍
3. 截图/GIF 演示
4. 核心功能
5. 为什么不同于普通 PDF 阅读器
6. 技术架构
7. 快速部署
8. 环境变量说明
9. Roadmap
10. License

### 一句话介绍示例

一个面向英文阅读场景的 PDF 听读工具，支持指定位置起播、逐句朗读和高亮联动，基于本地 ONNX TTS，普通 CPU 服务器即可部署。

## 演示内容建议

开源项目能不能传播，很多时候取决于演示是否直观。

建议准备：

- 首页截图
- PDF 阅读界面截图
- 点句播放动图
- 高亮跟读动图
- 日间/夜间模式切换图
- 服务器部署说明图

如果可以录一个 `30-60 秒` 演示视频，效果会明显更好。

## 对外传播文案建议

传播时不要把重点放在“我做了个 PDF 工具”，而是放在“解决了什么问题”。

推荐传播角度：

- 我做了一个适合英文精读和听读的 PDF 阅读器
- 普通 CPU 就能跑的本地 TTS 听书方案
- 点哪句读哪句，适合论文、电子书和英语材料精读
- 不依赖昂贵 GPU 的低成本听读工具

## 推广渠道建议

### 技术和开源圈

- GitHub
- V2EX
- 掘金
- 少数派
- Hacker News
- Reddit 的 self-hosted / productivity / language learning 板块

### 学习用户圈

- 英语学习社群
- 雅思托福社群
- 考研英语社群
- 教师和培训机构群体
- 小红书
- B 站

## 开源版本功能边界建议

为了后续商业化，建议从一开始就划清免费版和商业版边界。

### 开源免费版适合保留

- 本地部署
- 基础用户系统
- 基础阅读和播放
- 基础音色和参数

### 商业版适合增强

- 更强后台
- 更高并发
- 更完整权限体系
- 团队功能
- 统计和分析
- 在线托管
- 专业支持

## 发布节奏建议

### 第一阶段：整理发布

目标：

- 完成安全整改
- 补齐 README
- 补齐部署文档
- 发布第一个公开版本

时间建议：

- `1-2 周`

### 第二阶段：获取反馈

目标：

- 收集 issues
- 收集用户真实使用反馈
- 找到最受欢迎的功能点

时间建议：

- `2-4 周`

### 第三阶段：商业导流

目标：

- 在 README 和官网中加入托管版、私有部署、商业支持入口
- 建立咨询转化路径

时间建议：

- 开源后立即开始

## 开源发布检查清单

### 必做

- 敏感信息清理
- 删除缓存和无关文件
- 补齐许可证
- 补齐部署文档
- 补齐截图和演示
- 增加 `.env.example`
- 增加 `.gitignore`

### 强烈建议

- Docker Compose
- Nginx 反向代理示例
- 常见问题说明
- 性能测试结果
- 版本发布说明

## 预期结果

如果执行得当，开源后的合理预期不是短期赚钱，而是：

- 获得首批真实用户
- 验证目标场景
- 提升可信度
- 积累 GitHub Star 与口碑
- 为后续托管版和私有部署版导流

## 总结

这个项目适合开源，而且开源本身就是最好的第一阶段营销方式。但要把开源当作产品发布，而不是简单上传代码。重点不是代码有多少，而是你是否把“价值、部署、边界、演示、可信度”讲清楚。