Karl Fogel
Computers & Technology
制造开源软件
Free
Description
Contents
Reviews

在聚会上,当我告诉别人我写自由软件时,人们不再是一副茫然的表情。他们会说,“哦,开源软件—就像linux?”我使劲地点头:"对!我就是做那个的。"不再被凉在一边的感觉真好。要在过去,下面的一个问题通常会是这个:“你靠那个怎么挣钱?”为了回答他们,我必须概述开源软件的经济学:有一些组织对某个特定软件的存在感兴趣,但他们不需要卖拷贝,而是确保这些软件能够免费获得并且有人维护,能够作为工具而不是商品使用。

然而之后的问题不再总是同钱有关。开源软件[1]的商业案例不再是如此神秘,许多的非编程人士已经了解到—或至少不再惊奇—确实有一些人被雇佣全职做开源。于是,我越来越频繁地被问到的第二个问题是:“那么,开源软件是怎么运作的?

我手头没有现成的满意的答案,更困难之处在于当我试图给出一个时,我意识到它是一个多么复杂的题目。运行一个自由软件项目完全不同于商业运作(想像一下必须时常同大部分你从未谋面的志愿者们商讨产品的特性的情景! )。由于某些原因,也和传统的非盈利组织不同,也不同于一个政府。与上述事物有许多相似性,但我渐渐得出了一个结论,自由软件是独一无二的。有许多事情可以与之比较,但没有一个与之完全等同。实际上,即使对于自由软件项目可以“运行”的假设也是一种引申。一个自由软件项目能被开启,并且会受到对此感兴趣的团体的强烈影响,而且它的资产不属于任何一个个人或团体,会源源不断从某些地方冒出对此感兴趣的人,所以它不会被—任何人—单方面地终止。每个人都有无限的权利,每个人又都没有权利。它形成了这样一种有趣的动态平衡。

这就是我要写此书的原因。自由软件运动已经进化出了一种独特的文化,一种信奉个人能够让软件做任何事情、自由为中心信条的思想,这种自由的结果并不是让每个人对代码各行其事,而是是狂热的合作。实际上,在合作中竞争也是自由软件运动中最有价值的技巧之一。管理这样的项目就是处理一堆庞大的合作关系,在这里个人能力不仅是和他人一起工作,而且包括通过一条崭新的合作方式对软件做出实际的贡献。这本书试图描述实行这种方式所需要的技术。它不会包含全部,但却是重要的起步。

优秀的自由软件本身就是极有价值的目标,我希望那些在本书中寻找创造成功软件方法的读者能够得到满意的答案。除此之外,我想传达那种纯粹的快乐,来自同充满活力的开源软件开发团队的合作,来自通过开源软件所鼓励的直接方式与用户的交流。成为一个成功的自由软件项目的一分子是有趣的,这才是驱动整个系统运转的终极动力。

Language
English
ISBN
Unknown
制造开源软件
前言
为什么写这本书?
谁应该读本书?
资料来源
致谢
免责声明
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. 版权
The book hasn't received reviews yet.