制造开源软件

如何成功运营自由软件项目

Karl Fogel


Dedication

这本书献给我的两位好朋友,我不可能忘掉他们:Karen Underhill和Jim Blandy。

Table of Contents

前言
为什么写这本书?
谁应该读本书?
资料来源
致谢
写给第一版(2005)
写给第二版(2017)
免责声明
1. 介绍
历史
私有软件和自由软件的兴起
有意识的反抗
意外的反抗
“自由”还是“开源”
现状
2. 起步
从你所拥有的开始
选择一个好名字
有一份清楚的使命陈述
声明项目是自由软件
特性和需求列表
开发状态
下载
版本控制和Bug跟踪访问
沟通渠道
开发者指南
文档
文档的可用性
开发者文档
输出和屏幕截图实例
包装主机
选择许可证并应用
“可以做任何事情的”许可证
GPL
如何为你的软件应用许可证
设置风格
避免私下讨论
防无礼于未然
实践明显的代码评审
将一个封闭项目开放时,对于改变的影响要格外敏感
通告
3. 技术基础设施
一个项目需要什么
邮件列表
垃圾邮件防护
过滤邮件
归档中的地址隐藏
身份和头管理
伟大的Reply-to辩论
两个幻想
归档
软件
版本控制
版本控制词汇表
选择一个版本控制系统
使用版本控制系统
版本化所有的东西
可浏览性
提交邮件
使用分支来避免瓶颈
信息单一性
授权
Bug跟踪
与邮件列表交互
Bug跟踪的预过滤
IRC / 实时聊天系统
机器人(Bots)
归档IRC
RSS供稿
Wikis
网站
包装主机
选择一个包装站点
匿名和参与
4. 社会和政治的基础架构
慈善独裁者
谁可以成为一个慈善独裁者?
共识为基础的民主(Consensus-based Democracy)
版本控制意味着你可以放轻松
如果无法达成共识,那么表决!
何时表决
谁进行表决?
民意调查与表决
否决权
写下所有的内容
5. 金钱
参与的类型
长期雇佣
作为一些个体出现,而不是一个整体
公开你的动机
钱不能让你可爱
契约
评审和接受变更
案例研究:CVS密码认证协议
资助非编程活动
质量保证(也成为专业测试)
法律建议和保护
文档和可用性
提供主机/带宽
市场营销
记住你正在被注视着
不要痛击竞争开源产品
6. 交流
人如其文
结构和格式
内容
基调
识别无礼
面容
避免常见的陷阱
不要发表无目的的文章
多产VS非多产的线索
主题越软,辩论越长
避免圣战
“吵闹的少数派”效应
刺儿头
处理刺儿头
案例学习
处理成长
归档的显著使用
将所有的资源视为归档
编制法律的传统
Bug跟踪系统中无对话
公开性
声明安全漏洞
接收报告
默默的开发修正
CAN/CVE号码
预通知
公开分发修正
7. 打包、发布和日常开发
版本号
版本号组成部分
简单策略
奇偶数策略
发布分支
发布分支的技巧
稳定发布版本
发布所有者独裁
变更表决
管理协作发布稳定化
发布经理
打包
格式
命名和布局
大写还是不大写
预发布
编译和安装
二进制包
测试和发布
候选发布
宣告发布
维护多发布线
安全发布
发布和日常开发
计划发布
8. 管理志愿者
从志愿者中获取最多
委派
明确区分调查和指派
指派后要继续跟踪
通知感兴趣的人
赞扬和批评
防止割据
自动化率
自动测试
将每个用户当作潜在的志愿者
像分担技术任务一样分担管理任务
补丁管理员
翻译管理员
文档管理员
问题管理员
FAQ管理员
转化
提交者
选择提交者
收回提交权限
部分提交权限
休眠提交者
避免神秘
荣誉
分叉
处理分叉
初始一个分叉
9. 许可证,版权和专利
术语
许可证的方面
GPL和许可证兼容性
选择一个许可证
MIT / X Window System License
GNU General Public License
GPL是自由还是不自由?
那BSD许可证呢?
版权分配和所有权
无为而治
贡献者许可证协议
版权转移
双许可证模式
专利
深入资源
A. 自由版本控制系统
B. 自由Bug跟踪系统
C. 为什么我要关注车棚的颜色?
D. 报告bug的样例指导
E. 版权