【IT168 评论】从计算机销售商到生产企业，几乎每个公司都在忙于参与开源社区。许多人失败了，然后对于开源社区满怀失望。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)是衡量你的社区发展是否良好的关键因素。

　　开发者有很多项目可以选择，如果协作成为规范以后，他们会加速进入项目。这时你得经常考虑参与者的经验，并衡量外部开发者的价值。

　　一幅清晰而又瞩目的蓝图，兼有很多的开发机会，比较低的参与门槛，可以帮助降低吸引开发者的成本，也可以降低吸引新用户和付费客户的成本。