成立一个社区 现在转到第二个情景，如何建立一个社区。如果你决定以标准的自由软件许可证发布你的软件，首先应该决定是否让这个项目成为社区项目，并开放到哪种程度。 Simon Phipps写了一篇关于开源软件项目成长起来的不同社区类型。他把社区开发者分为这几类：核心开发者，非核心的插件开发者，负责发布和配置但不涉及开发的整合人员，最后就是软件的用户。所有这些成员有不同的需求，有不同的对待方式。 如果你想围绕你的项目建立起一个社区，下面有些你应该遵照的非常好的准则： - 控制权：如采用一些规则，来确保你来决定哪些代码可以加入你的产品代码，但你将会失去社区项目的很多优势。还有些例子，主要希望控制进入核心产品的代码版权，或者确保只有你的雇员才可以修改主分支上的核心产品代码。为了维护核心代码的版权，这是很好的做法。这当然会阻碍社区核心开发者的进入。但并不妨碍其他类型的成员，比如插件开发者或整合人员。 - 进入的障碍：社区开发者要避免设置一些障碍：使用不常见的工具，复杂费解的bug报告处理方式、功能需求提交方式、补丁接受方式和在开发之前合法的签证方式。 - 工具和架构体系：确保让你的用户有机会将他们的工作成果分发到其他用户。无论是通过某个模块，或者通过Gitorious、Bazaar之类代码控制平台都可以。让项目里的代码修改成为一项社交行为。 - 社区处理流程：创建这样一个环境，没有人会被认为是二等公民。将如何获取权限的方式文档化，比如管理bug报告的权限、将代码提交到主分支的权限或者项目网站的编辑权限。 - 相应预算：投入适当的资源--建立社区需要时间和精力，那意味着投资--主要是一些人力资源。 让一个人成为管理者，处理社区的日常事务。成立一个由10个人左右恒定的核心法人小组，用来进行决策及保障各方面的利益。就像PostgreSQL的Josh Berkus"如何杀死你的社区（中文版）"的报告。如果社区成员觉得被怠慢了，他们就会离去。 发布社区项目就像发布一项新的产品，吸引一个社区开发者比用户更久而且更难。跟公司为新产品追踪SAC一样，吸引一个开发者的花费（DAC）是衡量你的社区发展是否良好的关键因素。 开发者有很多项目可以选择，如果协作成为规范以后，他们会加速进入项目。这时你得经常考虑参与者的经验，并衡量外部开发者的价值。 一幅清晰而又瞩目的蓝图，兼有很多的开发机会，比较低的参与门槛，可以帮助降低吸引开发者的成本，也可以降低吸引新用户和付费客户的成本。 避免非常规的模式 如果采取了那些最佳策略，想抄近路，但社区的那些非常规模式证明最佳策略是错误的。如果最佳策略背后的原因被误解了，你不会得到你想要的结果。就像太平洋的贸易崇拜运动，仅仅建了很多飞机场，没有多大的市场，就希望飞机会降落。调味料终究是调味料，加太多就会毁了整盘菜。 归纳起来：当你看到下面的一些模式在你的社区或者你的合伙人出现的时候，你应该去着手应对它们。下面的模式都是很普遍而且有诱惑性的，因为它们就是所谓的最佳策略，但不合时宜。每一条都会削弱社区的健康。 这些你应该避免的非常规模式有： 1. 控制和命令 - 社区成员之间是合伙人的关系。而公司之于产品则是控制关系。当你尝试把公司的这种关系放到一个你想发展成为社区软件的产品中时，导致的结果只能是冷淡的回 应，因为其他人不想成为二等公民。类似的，加入一个你没有控制权的社区是很有挑战性的。有时你为了扩大影响，不得不用控制权来交换。 2. 水冷却器 - 当你团队过多的忙于你们的私人业务时，社区其他成员也许会怀疑你们的动机和工作优先权。在公开的邮件列表、论坛或者其他公开可读的地方时，你应当允许你的雇员和公司外部的人工作进度是一致的。 3. 无意义的讨论（Bikeshed） - 为了一个相对很小的决定，却需要经过长时间的讨论。当你感觉到社区成员正在拖你的后腿的时候，你应该知道什么结束讨论，然后开始干活。 4. 黑洞 - 有时雇佣一个社区里面已有的开发者是很有诱惑力的，因为他们拥有你想参与项目的能力。但是当心，当你雇佣社区开发者的时候，社区可能会变得更糟。因为他们本身就是在社区工作的，他们的工作本来是没有多少利益动机的。 5. 曲奇舔食者 - 想象一下，一个孩子有很多的曲奇饼干，但是吃完之前他想留下最后一块。所以他从盘子里拿出其中的一块，然后经常舔一下，确保其他人不会吃掉它。在社区项目 里也会有类似的问题 - 那些主导社区的成员经常把那些关键功能保留给他们自己开发，从而剥夺了其他成员做贡献的好机会。这就会有些人贡献过多，有些人饿死。在开发路线表里给其他 人留一些任务。你应该清楚你们想做什么，哪些你们不想做。 |
