从哪里开始呢？ 对开源怀有过高期望，然后不顾一切的迅速盲目地参与开源项目，是一般公司最容易犯而且致命的错误。 开源软件的发展历史之中，充满了商业公司对于社区开发最初体验的失望故事。一些技术主管不明白为什么社区项目不接受他们小组花费数月开发出来的功能，管理小组甚至期望在他们产品发布的时候，那些公司外部的开发者可以迅速跟上。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写了一篇文章来解释这些准则背后的原因。 你应该尽力避免公司干涉开发者与其他开发者的的交流。这最终只会在你的项目里产生工程师害羞综合症。 通过各种方式，让你们公司年长的社区开发工程师带小组里新的成员，教他们社区的这些流程，但要避免这些年长者成为守门人，将你的小组和社区隔绝开来。因为这会导致一些意向不到的问题，比如当你的“守门人”离职以后，社区发现其他人提交的代码与社区的规范不符。 |
