# 市场营销
虽然大多数开源开发者不愿意承认,但市场推广确实有用。好的营销活动*可以*为开源产品创造良好的氛围,即使此时顽固的编码者因为一些无法说明的原因,对于软件还没有清晰肯定的思路。这里我不会讨论一般意义的市场营销的军备竞赛动力学。所有参与到自由软件的公司最终都会发现自己需要考虑如何营销自己、软件或他们与软件的关系。下面是在进行这种努力时如何避免落入陷阱的建议;请看[Chapter 6, *交流*](# "Chapter 6. 交流")的[the section called “公开性”](# "公开性")。
### 记住你正在被注视着
为了让志愿开发者社区一直站在你一边,*非常*重要的一点是不要说任何不能确定正确的事情。作出任何声明前要仔细审核,并要为公众提供独立检查该声明的方法。独立事实检查是开源项目的主要组成部分,它不仅仅适用于代码。
很自然,没有人会建议公司作出未验证的声明。但是在开源活动中,通常会有不可思议的大量拥有专业技能的人去验证声明—这些人也都有高速的宽带接入和足够的社会联系,可以用一种危险方法发布他们的发现,他们一定会这么干。当Global Megacorp化工的工厂污染了河流,只有经过训练的科学家可以验证,他们也会受到Global Megacorp科学家的反驳,让公众抓耳挠腮而不知如何考虑。而另一方面,你在开源世界中的行为不仅是可见的和可记录的;也很容易被许多人独立的检查,得出他们自己的结论,并口头传播这些结论。这种交流网络一直都在;那是开源操作的本质,他们可以用来传播任何信息。如果不是不可能,反驳通常很困难,特别是当某人所说的是正确的。
例如,如果你们确实这么做了,可以称你的组织“资助了项目X”。但是,如果大多数代码是外人写的,不要称自己为“X的制造者”。相反地,如果任何人都可以看到版本库只有少量代码变更来自于组织之外,不要声明已经有了一个深入参与的开发者社区。
不久之前,我看到一个知名计算机公司的一次声明,说明他们以开源许可证发布了一个重要的软件包。当最初的声明发出之后,我看了一下他们的公共版本控制版本库,发现其中只有三次修订。换句话说,他们只是做了一次代码的初始化导入,之后没做什么事情。此事本身没有什么好担心的—毕竟,他们只是做了声明。没有理由期待会立刻发生大量开发活动。
不久之后,他们作出另一次声明。下面是将名称和数字替换后声明:
> *我们很高兴的宣布经过Singer社区严格的测试,Linux和Windows版本的Singer 5已经做好生产使用的准备。*
很想知道是什么社区进行的“严格测试”,我回到版本库去看最近的变更历史。项目还在修订3,很明显,他们没有发现*任何一个*值得在发布前修订的bug。考虑到社区测试一定是记录到了其他地方,接着我检查了bug跟踪系统。发现刚好有6个开放的问题,其中四个已经打开了几个月。
当然,这是乞丐的信仰(不可信)。当测试者在一个大型和复杂的软件上认真推敲一段时间,他们一定会发现bug。即使bug的修正不会进入即将到来的版本,人们还是希望有一些版本控制活动会作为测试过程的结果出现,或至少是一些新的问题。很显然,在开源许可证声明和第一次开源发布声明之间没有发生任何事情。
重点不是说这个公司在社区测试问题上说了谎。我不知道他们到底做了没有。但是他们很明显*像*是在欺骗。因为,无论是版本控制版本库还是问题跟踪系统,都没有任何迹象来说明所谓的严格测试曾经发生过,这个公司要么不要过早的声明,要么提供一些测试结果的明确链接(“我们发现了278个bug;点击此处看详细内容”)。后一种方法可以让任何人迅速掌握社区活动的级别。就像前面说的,我只有了几分钟就确定了这个社区测试的真相,它没有在任何常见的地方留下痕迹。那样不会花费太多力气,我确信我不是唯一保持疑惑的人。
当然,透明性和可验证性也是准确信用的重要部分。关于这些内容可以看[Chapter 8, *管理志愿者*](# "Chapter 8. 管理志愿者")的[the section called “荣誉”](# "荣誉")。
### 不要痛击竞争开源产品
要忍住不要发表关于竞争开源软件的负面意见。可以做的是提供负面的*事实*—也就是通常在一些好的比较图表上可以轻易确定的断言。但是最好避免不太严格的本性的负面特征,有两个原因。首先,这样会点燃论战而脱离有建设意义的讨论。其次,更重要的,在*你的*项目的一些志愿开发者会转向为竞争项目工作。开始并不是很明显:项目都在同一个领域(这也是为什么他们会竞争),拥有专业技能的开发者会在任何可以发挥专业才能的地方作出贡献。即使没有直接的开发者重叠,也很可能你的项目的开发者会与关联项目的开发者相识。他们维护建设性的个人关系的能力会被负面营销信息所束缚。
在开源世界中,痛殴闭源产品中的竞争者是可以广泛接受的,特别是如果这些产品是微软制造。个人来讲,我为这种趋势感到悲哀(虽然如此,这种直接基于事实的比较没有任何错误),不仅仅是因为这样很粗鲁,也因为这样很危险,让一个项目开始相信它自己的夸夸其谈,并忽视竞争者实际上可能更加优越的方式。通常情况下,可以仔细观察市场声明的效果,因为这也会发生在你自己的开发社区。人们可能因为市场美元的支持而丧失客观性,无法看清自己软件的真正力量和弱点。一个很可能出现的情形,某个公司的开发者会公开展示自己对于某个市场声明的无辜,甚至是直接在公共论坛。很明显,他们不应当直接跳出来否决市场营销信息(除非它事实上是错误的,尽管人们希望此类事情能够尽早被捕获)。但是他们可能会一次次的取笑这种行为,这也是将开发社区的其余部分带回地球的一个方法。
- 前言
- 为什么写这本书?
- 谁应该读本书?
- 资料来源
- 致谢
- 免责声明
- 1. 介绍
- 历史
- 现状
- 2. 起步
- 从你拥有的开始
- 选择许可证并应用
- 设置风格
- 通告
- 3. 技术基础设施
- 一个项目需要什么
- 邮件列表
- 版本控制
- Bug跟踪
- IRC / 实时聊天系统
- RSS供稿
- Wikis
- 网站
- 4. 社会和政治的基础架构
- 慈善独裁者
- 共识为基础的民主(Consensus-based Democracy)
- 写下所有的内容
- 5. 金钱
- 参与的类型
- 长期雇佣
- 作为一些个体出现,而不是一个整体
- 公开你的动机
- 钱不能让你可爱
- 契约
- 资助非编程活动
- 市场营销
- 6. 交流
- 人如其文
- 避免常见的陷阱
- 刺儿头
- 处理成长
- Bug跟踪系统中无对话
- 公开性
- 7. 打包、发布和日常开发
- 版本号
- 发布分支
- 稳定发布版本
- 打包
- 测试和发布
- 维护多发布线
- 发布和日常开发
- 8. 管理志愿者
- 从志愿者中获取最多
- 像分担技术任务一样分担管理任务
- 转化
- 提交者
- 荣誉
- 分叉
- 9. 许可证,版权和专利
- 术语
- 许可证的方面
- GPL和许可证兼容性
- 选择一个许可证
- 版权分配和所有权
- 双许可证模式
- 专利
- 深入资源
- A. 自由版本控制系统
- B. 自由Bug跟踪系统
- C. 为什么我要关注车棚的颜色?
- D. 报告bug的样例指导
- E. 版权