从计算机销售商到生产企业，几乎每个公司都在忙于参与开源社区。许多人失败了，然后对于开源社区满怀失望。Dave Neary 通过研究那些失败案例，总结出一些教训，教我们哪些可以做，哪些不应该做。现在，开源软件的社区开发者，已经不再仅仅包含那些穿拖鞋着装随意的极客，也有正规Linux公司的职员。我下面的结论也都是基于以上事实。
据最近一篇关于贡献Linux内核代码公司的分析文章得出的结论，像Novell，IBM，Intel，Nokia和德州仪器等公司都在很正式地参与开源软件的开发，LiMo基金会正鼓励其成员参与上游社区项目。这说明，与社区合作而不是孤立，可以避免数百万美元打水漂，没带来什么潜在影响。 社区开发者的多样性，对于开源项目的长期生存能力是非常重要的。当然公司放权后，也很难让社区开发者集中于他们自己的项目，或者是影响社区维护者的开发方 向。Linux内核或者GNOME就是这样的，大家相互协作，没有人是占据主导的。Sun和AOL虽然完全采用了社区开发，但是至少和社区开发者没有培养 起一种互助互利的关系。还有其他许多例子，我们很少听说过公司仅仅实验性的参与社区开发，然后退回到闭门造车去，或取消对于社区开发的实质投资。当然也有 反面例子，比如Xara，在2005年开源了他们针对Linux的部分主打产品“Xara Xteme”，但是在2006年晚些时候，又悄悄的放弃了在社区项目上的所有投资。 到底哪里做错了？哪些是公司转向社区开发投资战略最普遍而且最致命的错误？如何避免？而且避免这些不一定保证成功，只是让你可以免于像他们那样失败。 从哪里开始呢？ 对开源怀有过高期望，然后不顾一切的迅速盲目地参与开源项目，是一般公司最容易犯而且致命的错误。 开源软件的发展历史之中，充满了商业公司对于社区开发最初体验的失望故事。一些技术主管不明白为什么社区项目不接受他们小组花费数月开发出来的功能，管理小组甚至期望在他们产品发布的时候，那些公司外部的开发者可以迅速跟上。Chris Grams曾经把此类问题归结为锯木匠汤姆的社区参与模型，公司总是希望别人可以帮他们把工作都做了。首先要确保你不会误入这些陷阱。 建设好社区软件需要耐心，有时你把自己的所有东西都做好了，但你还有些东西你没办法做好。 所以，从哪里开始？在参与社区开发之前，你首先得好好想想你究竟想得到什么？开源是否能让你的产品增长，让你的发布渠道得以拓宽，最终获取业内领先的地位？ 你是否需要在你的平台上引入一些系统开发者？你是否需要为了降低成本而在你的产品里采用现有的开源项目，或是自己开发，以便它能满足你的需要？所有这些目 标，或者所有那些参与开源项目的原因，需要特定的策略和工具来裁定是否成功。事实上，你成功与否取决于你的目标。 有两种普遍的情形可以选择，一种是公司加入现有的开源社区，另一种是自己建立一个与你的产品相关的社区。 加入社区 加入社区，并赢得信任和声誉都需要耐心。在参与社区工作之前，首先你需要理解社区的组织结构。谁是领导人，哪些是他们的优先项目？如果社区文化不符合你的商业目的，肯定会在最初就影响你加入社区的决定。 如果你发现可以加入这个项目的工作，而且项目的目标与你的一致（至少不是完全不一样），那你就应该开始辛苦工作了。比如，HP公司很早就开始支持Linux，当然也作为支持他们自有产权Unix-HPUX的花费。十年以后，HP卖出的Linux服务器占到所有Linux服务器的40%。相反，Sun公司在2005年决定建立一个独立的的社区，用以发布GPL兼容（Linux内核的许可证）的开源版本OpenSolaris。从一开始到Sun被Oracle收购，Sun都没有建立起实际独立的开发者社区。在2010年，Oracle实际上关闭了OpenSolaris项目。 当你决定参与的时候，你已经选择了你要工作的项目。接下来，最重要的决定是你们公司谁来参与这个项目，这经常被高层所忽视。这些参与项目工程师的行为代表的 是你们公司。他们的工作包括：获取项目维护者的信任，引导项目的开发路线，确保他们的工作被接受，保证你们公司的商业目的。 参与项目人选是非常重要的。就像前GNOME基金会的前执行主管Stormy Peters曾经写的：公司不是个人。换句话说，公司从来不能作为软件开发社区的成员，但是个人可以。公司可以成为项目制度上的伙伴，可以参考Beatles和 Karl Fogel之间的例子，金钱买不来感情（或者说社区的支持）。 现在你有一些工程师在参与社区项目，然后呢？对于工程师参与行为，Havoc Pennington在1999年写了一些非常好的建议。简而言之，就是“在罗马，就按照罗马人那样做事”。 许多社区经常有他们行为规范的文档，比如Linux内核和GNOME模块项目，有名为HACKING的文件放在源代码文档，还有邮件列表准则，开发者都可以参考。对于大多数社区来说，这些规范可以概括为“顺着惯例走，不要打破它”。GNOME项目的创始人和Novell公司开发平台的副总裁，Miguel de Icaza写了一篇文章来解释这些准则背后的原因。 你应该尽力避免公司干涉开发者与其他开发者的的交流。这最终只会在你的项目里产生工程师害羞综合症。 通过各种方式，让你们公司年长的社区开发工程师带小组里新的成员，教他们社区的这些流程，但要避免这些年长者成为守门人，将你的小组和社区隔绝开来。因为这会导致一些意向不到的问题，比如当你的“守门人”离职以后，社区发现其他人提交的代码与社区的规范不符。 成立一个社区 现在转到第二个情景，如何建立一个社区。如果你决定以标准的自由软件许可证发布你的软件，首先应该决定是否让这个项目成为社区项目，并开放到哪种程度。 Simon Phipps写了一篇关于开源软件项目成长起来的不同社区类型。他把社区开发者分为这几类：核心开发者，非核心的插件开发者，负责发布和配置但不涉及开发的整合人员，最后就是软件的用户。所有这些成员有不同的需求，有不同的对待方式。 如果你想围绕你的项目建立起一个社区，下面有些你应该遵照的非常好的准则： - 控制权：如采用一些规则，来确保你来决定哪些代码可以加入你的产品代码，但你将会失去社区项目的很多优势。还有些例子，主要希望控制进入核心产品的代码版权，或者确保只有你的雇员才可以修改主分支上的核心产品代码。为了维护核心代码的版权，这是很好的做法。这当然会阻碍社区核心开发者的进入。但并不妨碍其他类型的成员，比如插件开发者或整合人员。 - 进入的障碍：社区开发者要避免设置一些障碍：使用不常见的工具，复杂费解的bug报告处理方式、功能需求提交方式、补丁接受方式和在开发之前合法的签证方式。 - 工具和架构体系：确保让你的用户有机会将他们的工作成果分发到其他用户。无论是通过某个模块，或者通过Gitorious、Bazaar之类代码控制平台都可以。让项目里的代码修改成为一项社交行为。 - 社区处理流程：创建这样一个环境，没有人会被认为是二等公民。将如何获取权限的方式文档化，比如管理bug报告的权限、将代码提交到主分支的权限或者项目网站的编辑权限。 - 相应预算：投入适当的资源--建立社区需要时间和精力，那意味着投资--主要是一些人力资源。 让一个人成为管理者，处理社区的日常事务。成立一个由10个人左右恒定的核心法人小组，用来进行决策及保障各方面的利益。就像PostgreSQL的Josh Berkus"如何杀死你的社区（中文版）"的报告。如果社区成员觉得被怠慢了，他们就会离去。 发布社区项目就像发布一项新的产品，吸引一个社区开发者比用户更久而且更难。跟公司为新产品追踪SAC一样，吸引一个开发者的花费（DAC）是衡量你的社区发展是否良好的关键因素。 开发者有很多项目可以选择，如果协作成为规范以后，他们会加速进入项目。这时你得经常考虑参与者的经验，并衡量外部开发者的价值。 一幅清晰而又瞩目的蓝图，兼有很多的开发机会，比较低的参与门槛，可以帮助降低吸引开发者的成本，也可以降低吸引新用户和付费客户的成本。 避免非常规的模式 如果采取了那些最佳策略，想抄近路，但社区的那些非常规模式证明最佳策略是错误的。如果最佳策略背后的原因被误解了，你不会得到你想要的结果。就像太平洋的贸易崇拜运动，仅仅建了很多飞机场，没有多大的市场，就希望飞机会降落。调味料终究是调味料，加太多就会毁了整盘菜。 归纳起来：当你看到下面的一些模式在你的社区或者你的合伙人出现的时候，你应该去着手应对它们。下面的模式都是很普遍而且有诱惑性的，因为它们就是所谓的最佳策略，但不合时宜。每一条都会削弱社区的健康。 这些你应该避免的非常规模式有： 1. 控制和命令 - 社区成员之间是合伙人的关系。而公司之于产品则是控制关系。当你尝试把公司的这种关系放到一个你想发展成为社区软件的产品中时，导致的结果只能是冷淡的回 应，因为其他人不想成为二等公民。类似的，加入一个你没有控制权的社区是很有挑战性的。有时你为了扩大影响，不得不用控制权来交换。 2. 水冷却器 - 当你团队过多的忙于你们的私人业务时，社区其他成员也许会怀疑你们的动机和工作优先权。在公开的邮件列表、论坛或者其他公开可读的地方时，你应当允许你的雇员和公司外部的人工作进度是一致的。 3. 无意义的讨论（Bikeshed） - 为了一个相对很小的决定，却需要经过长时间的讨论。当你感觉到社区成员正在拖你的后腿的时候，你应该知道什么结束讨论，然后开始干活。 4. 黑洞 - 有时雇佣一个社区里面已有的开发者是很有诱惑力的，因为他们拥有你想参与项目的能力。但是当心，当你雇佣社区开发者的时候，社区可能会变得更糟。因为他们本身就是在社区工作的，他们的工作本来是没有多少利益动机的。 5. 曲奇舔食者 - 想象一下，一个孩子有很多的曲奇饼干，但是吃完之前他想留下最后一块。所以他从盘子里拿出其中的一块，然后经常舔一下，确保其他人不会吃掉它。在社区项目 里也会有类似的问题 - 那些主导社区的成员经常把那些关键功能保留给他们自己开发，从而剥夺了其他成员做贡献的好机会。这就会有些人贡献过多，有些人饿死。在开发路线表里给其他 人留一些任务。你应该清楚你们想做什么，哪些你们不想做。 快乐的耕耘你们的社区 社区软件开发会成为你们产品很好的助推器，也是很好的加分经历。在已有的社区项目上工作可以节省时间和金钱，帮助你们比其他方式更快更好地推出产品。原来做 产品时，是双选题--“自己做或者买别人的”，现在已经完全变成三选题--“自己做、买别人的或者分享别人的”。如果你是在 Android，MeeGo，Linaro还是Qt上做开发，你肯定会理解社区开发是很重要的。当你拥抱开源运动以后，你会发现投资资源变宽了，你的声誉 与日俱增，你已经培养起了给与与的良性关系，所有人都是赢家。而这所有的关键点是，你应该把社区所有成员当做你们产品开发的合伙人。 避免那些危险的诱惑，投入适当的时间和精力，你最终会得偿所愿的。就像园丁耕耘他们的植物，使用适当的肥料、工具和资源，待到春暖时，百花就会盛开。 作者：Dave Dave Neary 是maemo.org的文档管理员，是GNOME基金会的长期成员。他已经在IT行业里工作10年以上，主导和组织多个软件和社区。他尤其钟情于自由软件和技术。 |
