金钱
本章仔细检查了如何为自由软件环境带来资金。这不仅仅是在自由软件中被支付工资的开发者的目标，也是他们的经历，那些需要理解开发环境社会动态性的人的目标。在接下来的章节中，假定收件人（你）是被付费的开发者，或者是管理这类开发者的人。对于二者的建议基本相同；如果不同，有意的读者可以从上下文中分清。
对自由软件开发来说，公司投资已经不是一个新的现象。许多开发被非正式的资助。当一个系统管理员写了一个网络分析工具来辅助她的工作，然后把它发布到网络，接受来自其他系统管理员的bug修正和特性贡献，这就产生了一种非正式的合作组织。这个合作组织的资金来自系统管理员的薪水，而它的办公室空间和网络带宽是捐助的，尽管是通过其所工作的默默无闻的组织。这个组织从投资中获益，当然，尽管开始时他们不会意识到这一点。
现在的一些变化是这种力量已经更加正式。公司已经观察到开源软件的好处，在他们自己的开发中直接参与其中。开发者也更能预期真正重要的项目至少能获取到捐助，甚至可能是长期的赞助。而金钱的出现并没有改变自由软件开发的基本动力学，它已经极大地改变了发生事情的范围，无论是从开发者的数量来说，还是每个开发者贡献的时间。对于项目的组织，以及参与者的交互也有影响。这个问题不仅关于金钱如何花费，也关于如何测量投资回报。他们也关于管理和过程：公司层级指挥结构和自由软件项目中半集中的志愿者社区能够以相近的生产率工作？他们认可“生产率”的含义？
财政支持通常会受到开源开发社区的欢迎。它可以减少项目面对混乱势力的弱点，这一点经常让项目在起飞之前就被清除，因此它可以让人们更希望给软件一个机会—他们感到正在一项至少会再干6个月的工作上花费时间。毕竟，可靠性从来都是最有感染力的因素。假定IBM支持了一个开源项目时，人们就会更容易设想这个项目不会失败，而他们的因此所自发的投入反而会去实现这个会成为事实的预言。
然而，资金也会带来控制的感觉。如果处理不好，金钱会让项目分裂为圈内和圈外开发者。如果未付酬的志愿者感到设计决策或特性添加仅仅是由出价最高者决定的，他们会转而投向那些感觉更像是由知识精英管理的，不象是为了某个他人利益进行未付酬劳动的项目。他们绝不会在邮件列表中公开抱怨。相反，随着志愿者逐渐不再努力被重视，来自外部的声音也会越来越少。小规模活动的吵闹还会继续，会以bug报告和偶尔的小修订形式出现。但是再也不会有任何大规模的代码贡献和来自外部的设计讨论参与。人们意识到他们是如何被期望的，而且也会按照这个预期行事。
尽管需要小心的使用金钱，并不意味着不能购买影响力。大多是可以的。技巧是不能直接购买影响力。在一个直接的商业交易中，你使用金钱交换你所需要的。如果你需要添加一个特性，你签署一个协议，为此付款，然后它就会被实现。在开源项目，不会如此简单。你可以与某些开发者签署协议，但是他们需要欺骗自己—和你—如果他们保证你付费的工作会被开发社区接受，仅仅因为你为此付了费。这个工作只应该根据事实，以及与社区对于此软件的长远规划的符合程度来完成。你可以对这个长远规划发表意见，但你不应该是唯一的声音。
所以金钱不能购买影响力，但是可以购买导致影响力的东西。最明显的例子是程序员。如果雇佣了好的程序员，他们逗留了足够长的时间，以获取社区中的软件经验和信誉，那么他们就可以使用其他成员一样的方式影响项目。他们会有一个投票，或者如果人数太多，他们会有投票集团。如果他们在项目中受到尊重，他们会有超越投票的影响力。被支付的开发者没有必要掩盖他们的动机。毕竟，每个希望修改软件的人都有自己的目的。你公司的原因并不比其他人的缺乏道理。只是给与公司目标的砝码取决于代理人在项目中的状态，而不是公司的规模、预算或商业计划。
参与的类型
开源项目被资助有许多不同的原因。这个列表中的条目并不互斥；通常一个项目的财政支持会出自这里的多个，甚至全部的动机：
分担负担
拥有相关软件需要的不同组织经常会发现他们在重复投入，包括在内部重复编写类似的代码，以及从私有供货商购买类似的产品。当他们意识到事实真相后，这些组织会集中他们的资源，并创建（或加入）到一个开源项目，并为他们的需要调整。好处是明显的：开发的代价被分担了，而对所有人利益则增长了。尽管这个场景凭直觉应该大多数是非盈利组织所做的，但是即使对于盈利竞争者也具有战略意义。
例如：和
提高服务
当一个公司出售的服务依赖于某个开源程序，或因为某个开源程序而更加具有吸引力，很自然这个公司会有兴趣保证程序能够活跃的维护着。
例如：CollabNet对于的支持（免责声明：是我的日常工作，但是也是这个模型的完美实例）。
支持硬件销售
计算机和计算机组件的价值和之上的软件直接关联。硬件销售商—不仅是整机销售商，还包括外围设备和芯片制造商—都发现让高质量的自由软件运行在他们的硬件上对客户来说非常重要。
暗中削弱竞争者
有时候公司支持特定的开源项目作为对竞争者产品的暗中破坏，无论竞争产品本身是否开源。争夺竞争者的市场份额通常不是参与开源项目的唯一原因，但却是一个因素。
例如：（不，这不是OpenOffice存在的唯一理由，但是这个软件至少部分的回应了微软的Office）。
市场营销
让你的公司与流行的开源应用联系在一起，是简单而且好的品牌管理。
双重许可证
双重许可证会为希望将软件作为自己私有软件的一部分进行销售的客户提供传统私有许可证，同时为开源范围使用的客户提供自由许可证（见的）。如果开源开发者社区是活跃的，软件可以广泛领域获得调试和开发的好处，尽管公司仍然保持支持一些全职程序员的特许权。
两个著名的例子是MySQL，相同名称数据库软件的制造商，以及Sleepycat，提供Berkeley数据库的发布和支持。他们都是数据库公司并不是巧合。数据库软件通常会集成到应用中，而不会直接交给用户，所以非常适合双重许可证模型。
捐赠
一个广泛使用的项目有时可以获得可观的捐助，包括来自个人和组织的，只需要有一个在线的捐赠按钮，或者有时通过销售诸如咖啡杯、体恤和鼠标垫之类的品牌商品等等。小心一点：如果你的项目接受捐赠，在得到之前要计划好如何使用这些钱，并在项目网站中注明。在实际花费之前保留，可以让关于如何分配钱的讨论变得十分顺利；但不管怎样，如果有明显的分歧，最好把它找出来，这还是很学术的东西。
投资者的商业模型不是它与开源社区如何联系的唯一因素。二者的历史关系也很重要：这个公司开始了这个项目，或者它联合了现有的开发力量？在这两种情况下，投资者都需要赢得信誉，但是，不令人意外，在后一种情况下需要的更多。组织需要对项目的未来有清晰的目标。公司希望保持领导地位，或仅仅是成为社区的一个声音，从而能够引导而不必控制项目的方向？或者它只是希望有一些提交者，能够修复客户的bug并能够不费吹灰之力的将变更置入公共版本？
当你阅读后面的指导方针时要留意这些问题。他们可以应用到自由软件项目中的此类组织参与，但每个项目都是一个人类环境，因此没有完全相同的。在某种程度上，你需要跟着感觉演奏，但是遵从这些原理会增大结果符合你想法的可能性。
长期雇佣
如果你正在管理开源项目中的程序员，要尽量保持足够的时间，这样他们才能获得足够的技术和政治技能—最少也需要几年时间。当然，没有项目，无论是开源还是闭源，都可以从轮换程序员中获益。新来者搞清楚窍门需要的时间在不同环境下各不相同。但是在开源项目中的代价更加巨大，因为离开的开发者不仅带走了他们的知识，也带走了社区中的他们的地位和其中建立的人际关系。
开发者已经积累的信誉不能够传递。一个新来的开发者不能继承来自离开者的提交权限（可以本章后面的），如果新的开发者还没有提交权限，在获得这个权限之前它只能提交补丁。但是提交权限只是所失去的影响中最容易度量的表现。一个长期的开发者也知道邮件列表中所有以前达成和未达成一致的讨论。一个新的开发者，没有这些对话的记忆，也许会再次发起某些讨论，这会损失在组织中的信誉；其他人会奇怪为什么“他们什么也记不住？”新的开发者也对项目特性没有太多政治感觉，所以也不能象老手一样迅速和平滑的影响开发方向。
通过指导契约的程序来训练新手。新的开发者第一天就可以与公共开发社区直接交流，从bug修正和清理任务开始，这样他们可以逐渐熟悉代码基并在社区获取声誉，尽管此时他们还不能在设计讨论中蹦出火花。一个或多个有经验的开发者应当一直负责解惑的任务，阅读新手在开发列表中的每一篇帖子，即使是经验丰富的开发者通常不会注意的内容。这可以帮助团队在新手搁浅之前定位潜在的暗礁。私下的幕后鼓励和忠告也会非常有益，特别是当新手不习惯大量的代码平行同级评审的时候。
当CollabNet雇佣新的开发者为Subversion工作时，我们会坐在一起为新人找一些打开的bug来练练手。我们会讨论解决方案的技术要点，并让至少一个有经验的开发者来评审（公开的）新开发者的补丁（也是公开的）。我们通常不会在主开发列表公开之前查看这个补丁，虽然，如果情况特殊，我们可以如此。重要的是，新开发者经历公开评审的过程中，在熟悉代码基的同时，也需要习惯于接受来自完全是陌生人的批评。但是我们会调整时机，保证我们的评审会在补丁发出之后立刻出现。这样列表中出现的第一个评审就是我们的，这可以帮助我们确立其他评审的基调。它也可以加强一个概念，也就是这个新人需要认真对待：如果其他人看到我们花时间提供详细的评审，并包含完整的解释和归档中合适的参考，他们会意识到正在进行一种培训，并意味着一个长期的投资。这可以帮助他们对那个开发者保持正面的态度，至少会花费更多的时间回答问题和评审补丁。
作为一些个体出现，而不是一个整体
你的开发者必须力求在项目的公共论坛中以一个单独的参与者出现，而不是一个单独的公司。这不是因为作为一个公司出现本身固有的一些负面含义（好的，或许有一些，但那不是本书所讨论的）。而是因为开源项目的结构配备只能处理个人实体。一个单独的贡献者可以讨论、提交补丁、获取信誉、表决等等。而一个公司不能。
此外，因为分布式的行为方式，你避免了对于刺激性中央集权的敌对。让你的开发者在邮件列表中意见并不一致。鼓励他们经常评审他人的代码，尽可能的公开，就象他们是任何其他的人。阻止他们象一个集团一样表决，因为如果你这样做，其他人就会感觉到，根据一般的原理，一定有一个有组织的力量在控制他们。
实际的非中央集权和假装的是有区别的。在特定环境下，让你的开发者协同一致会非常有用，而且如果必要还必须在幕后进行协调。例如，当发出提议时，让许多人尽早跳出来表示认可，得出正在达成共识的印象会有助于提议的进展。其他人会感到提议的动量，如果他们反对，他们需要阻止这个动量。因此，人们只会在有好的原因时才会提出反对。如果能够慎重对待反对意见，这样的精心安排也没有错。私下协议的公众表现不会因为经过预先的协调而变得不够诚实，只要他们没有用这个方法来扼杀反对意见就不会有太多害处。他们的目的仅仅是阻止那些喜欢保持个性的人提出反对意见；更多相关内容可以看的。
公开你的动机
尽可能公开你的组织的目标，不要因此而让商业秘密妥协。如果你希望项目能够获得某个特定的特性，例如你的客户要求这个特性，那么就应该在邮件列表中坦率的说出来。如果客户希望保持匿名，实践中这种情况很多，至少要询问一下客户是否愿意以未命名的方式使用他们的实例。开发社区对于你为什么这样做的原因了解越多，就会对你提议的事情越感到舒服。
这与直觉背道而驰—得到容易甩掉难—知识就是力量，你的目标别人知道的越多，他们就越有可能超越你的控制能力。但是那种直觉在这里并没有错。通过公开支持这个特性（或是bug修正或其他任何东西），你已经亮出了底牌。现在唯一的问题是你能否成功的引导社区来分享你的目标。如果你仅仅是表明你需要它，而不能提供任何表明原因的切实例子，你的论点就会很脆弱，而人们会开始猜疑其隐藏的动机。但是如果你能够提供现实的场景来展示为什么提议的特性是重要的，就可以有力的影响辩论的效果。
为了看清楚这样做为什么有效，考虑另外一种选择。关于新特性或新方向的讨论会非常耗时和烦人。人们提出的论点经常会变成“我个人希望X，”或曾经流行的“根据我多年作为软件设计师的经验，对用户来说，X是极端重要的/一个无用的花边功能不会让任何人满意。”可以预料到，现实用例的缺乏不仅不会缩短或缓和这种辩论，而会扯得离实际用户体验越来越远。如果没有一些增补的力量，那么最终的结果很可能需要由口才最好、坚持最久或地位最高的人决定。
对于有许多客户数据的组织，你有机会提供这种增补的力量。你可以作为无法达到开发者社区的数据的信息管道。不必因为那些支持你愿望的信息事实而感到窘迫。大多数开发者个人没有他们所写软件如何使用的广泛经验。每个开发者都会按照自己的怪异方式使用软件；只要有其他的使用模式，她就会凭直觉并臆断之，而且事实上，她们知道这一点。通过提供包含可观用户数量的可信数据，你就象为整个公共开发社区提供了氧气。只要你提供的例子是正确的，他们就会狂热的欢迎它，就会推动事情往你希望的方向发展。
关键是提供正确的例子。不要因为你要应付大量需要某特性（或以为他们需要）的用户，就坚决要求你的特性，也就是你的解决方案必须实现。相反，你必须将你最初的帖子关注于问题，而不是一个特定的解决方案。详细描述你的客户遇到问题的细节，尽可能提供你已经完成的分析，以及你能想到的可行性方案。当人们开始考虑不同方案的效果时，你可以继续通过提供数据来支持或反对她们的意见。你在心里可以有一个特定的解决方案，但是不要在开始单独提出来以期望获得特殊的考虑。这不是欺骗，这只是标准的“诚实代理人”的行为。毕竟，你的真正目标是解决问题；一个解决方案只是达到目标的一种方法。如果你选中的解决方案确实更好，其他开发者最终会识别出来—她们会出于自愿的跟进，肯定比你通过威逼她们实现更好。 （当然，也有可能她们找到了更好的方案。）
这不是说你不能说出你看好某个方案。但是你必须耐心的查看你所做的分析反复成为公共开发列表的中心。不要在列表中说“是的，我们试过这种方式，但是因为原因A、B和C，它是行不通的。当你彻底了解它后，解决它的唯一办法是...”问题不是它听起来很傲慢，而是让人觉得你对此问题已经研究了许多未知的（但是，人们会假设有很多）分析资源，只是一切都在门后面。它让人觉投入的精力白费了，或许已经做出了决定，而公众都不是有利害关系的人，这是招致怨恨的好方法。
自然，你知道你自己在某个问题上所投入的力量，而这些知识从某种意义上来说是一种劣势。它让你的开发者处于和邮件列表中的其他人些许不同的心理空间，减弱了开发者从那些普通人的视角看待这个问题的能力，这些普通人没有像开发者那样考虑过这个问题。你越早能够让所有人用与你相同的术语考虑问题，这种差距就会越小。这种逻辑不仅适于个人技术情形，而且适用于更广泛的让你的目标尽可能清晰的授权。未知总比已知的更不稳定。如果人们理解了为什么你希望你所希望的，即使他们不认可，在与你交谈时也会感到舒服些。如果他们不能指出何事让他们愤怒，他们会假定最坏的情况，至少有时候。
你不能宣传所有的事情，当然，人们也不会期望你如此。所有的组织都有秘密；或许会因为利益，但是没有利益也会如此。如果你必须发起这样一个过程，而无法揭示任何原因，那就提供你在这种不利条件下最好的论点，并接受你将不会在讨论中获得你期望影响力的后果。这是让你不必为开发社区支付薪水的一个折衷手段。
钱不能让你可爱
如果你的项目有付费的开发者，一定要尽早设置钱可以购买什么东西的指导方针。这并不意味着你需要每天在邮件列表中说明两次来重申你的高尚和不腐的本性。你只需要在恰当的时机放松由钱导致的紧张。你不需要从一开始就假设存在这种紧张；你只需要说明有这种可能性。
一个完美的例子就是Subversion项目。CollabNet在2000年开始了Subversion，从一开始它便是项目主要的投资者，为多个开发者提供薪水（免责声明：包括我）。项目开始后不久，我们雇佣了另一个开发者Mike Pilato，参与开发工作。此时，编码工作已经开始。尽管Subversion还处于早期阶段，但已经有了一个开发者社区和许多基本的规则。
Mike的到来突现了一个有趣的问题。Subversion已经有了开发者如何获得提交权的政策。首先，他需要在开发邮件列表中提交一些补丁。当有了足够的补丁后，其他提交者看到新贡献者知道自己所做的事情，某人就会提议他直接提交（这个提议是私下的，就像所描述的）。如果提交者们同意，其中的某人就会邮件通知新的开发者，并为他设置直接提交访问项目版本库的权限。
CollabNet是专门为Subversion项目雇佣了Mike。他们已经对他足够了解，对于他的编码技巧和在此项目所作的准备毫无疑问。此外，志愿者开发者已经与CollabNet雇员有了非常好的关系，看起来如果我们直接在雇用Mike当天就赋予他权限也不会有什么反对意见。但是我们知道我们正在设置一个先例。如果我们按命令给Mike提交权利，我们会说CollabNet有权无视项目的指导方针，只是因为它是主要的投资者。这种行为的害处未必立刻显现出来，它会导致非付费开发者逐渐感到被剥夺了投票权。其他人自己赢得他们的提交权利—而CollabNet只需要花钱买。
所以Mike赞成象其他志愿开发者一样，在没有提交权限的情况下开始了在CollabNet的雇佣工作。他在公共列表中发布补丁，在其中可能会受到，实际上也确实受到了所有人的评审。我们在列表中也说过我们是故意这样做的。经过Mike数周的扎实活动，某人（我不记得是否是CollabNet开发者）提议给他提交权限，而他被接受了，当然，我们知道他会被接受。
那种类型的一致性会让你确信钱不可以买到一切。这种确信是技术讨论中珍贵的流通货币：可以免于以后让某人的动机被怀疑。在辩论最激烈时，人们有时会寻找非技术的方式来赢得战斗。项目的主要投资者，因为涉足较深并且显然会对项目采取的方向十分关注，会展示出比大多数人更广的目标。通过从一开始就一丝不苟的遵守项目方针，投资者就可以获得和所有人一样的影响力。
（Danese Cooper的blog上有关于提交权限的类似故事。Cooper是Sun
Microsystem的“开源Diva”—我相信这是她的官方头衔—在她的blog中，她描述了Tomcat开发社区让Sun在控制提交权限时对Sun的人员和非Sun的人员一视同仁。）
创始人对所有人使用相同规则的需要意味着慈善独裁统治模型（见的）在投资面前有一点难于实施，特别是独裁者为主要的投资方工作的情况。因为独裁有一些规则，投资者很难证明遵守了社区标准，即使事实如此。这确实不是不可能；只是需要项目领导者既能够从投资方也能够从外围开发者的视角看待事物，并依此行动。即使那样，也最好能在后口袋有一个非独裁管理的提议，准备好在社区的不满扩散时掏出来。
契约
在自由软件项目中的契约需要小心处理。理想状况下，你希望一个承包者的工作被社区接受并打包进入公共发布版本。在理论上，谁是承包者并不重要，只要他的作品足够好并满足项目的指导方针。理论和实践一般也是一致的：一个通过贡献好的补丁展示自己的完全陌生人通常能将代码置入软件当中。问题是，一个完全的陌生人很难为非琐碎的改进或新的特性贡献好的补丁；一个人必须首先和项目的其他人进行讨论。讨论的时间不能精确预测。如果承包者根据小时付费，你最终可能会付出超过预期的费用；如果他是通过总费用支付，那么他最终会做出超过承受能力的工作。
这里有两种方式。较好的一个方法是根据以前的经验，对讨论过程的长度做出一个有根据的推测，并要考虑到出错的延误，并根据这些信息完成契约。这也有利于尽可能的将问题分离为许多小的独立的区块，增加每个区块的可预测能力。另一个方法是为每一个发布的补丁单独契约，然后将补丁的被接受当作公共项目一个独立的事件。这样编写契约就可以很容易，但是只要你依赖这个软件，或至少在这个补丁或对应功能进入主线的这些时间里，你必须承担维护单个补丁的责任。当然，即使是你中意的方法，契约本身不能要求代码必须可以接受补丁，因为那会包含出售一些不能销售的东西。 （如果项目的余下成员不希望对这个特性提供支持？）然而，契约可以要求真诚地投入以获得社区接受的机会，也就是在社区认可的情况下被提交到版本库。例如，如果项目编写了代码变更的标准，契约可以参考这个标准并指明作品必须达标。在实践中，这通常会超出每个人期望的方式。
最好的策略是雇佣项目的一个开发者—最好是提交者—作为承包者。这可以看作是购买影响力的一种形式。但是并不是表面上那样的不道德。一个开发者对于项目的影响力主要取决于他的代码质量和与其他开发者的交互。他作为承包者完成特定工作的举动并不会提升他的状态，当然也不会降低，尽管这样会让人们对他更加仔细的审视。大多数开发者不会因为返回不当或广泛反对的新特性而让自己的长期位置经受风险。实际上，当你雇佣一个这样承包者时，一定程度上你会得到，或者说一定会得到一些关于哪些变更会被社区接受的忠告。项目的优先级也会得到些许转变。因为优先级只与哪个人有时间完成哪个任务有关，当你为某人的时间支付时，会导致他们工作的优先级提前一些。这是经验丰富的开源开发者都理解的一个事实，至少他们中的某些人会将精力投入到承包者的工作上，仅仅因为它看起来将要完成，所以他们希望去帮助正确完成。或许他们不会编写任何代码，但是他们还是会讨论设计并评审代码，这些都非常有用。出于以上原因，承包者最好是那些已经参与到项目的人。
这样立刻凸显了两个问题：承包协议必须是私密的吗？如果不是，你应当为你在社区中造成的不安而感到担忧吗？你为某些开发者提供了承包合同，为什么不是其他人呢？
如果可以，最好将合同公开。否则，承包者的行为与社区中的其他人相比会看起来有些奇怪—或许他突然对一些过去从未表现出兴趣的特性展示出了不可理解的高优先级。当人们询问其原因时，他怎样才能避免说出他是根据合同编写代码，同时回答的让人信服。
与此同时，你和承包者都不应该表现的仿佛其他人应当把你的安排看得过重。我见过一些承包者招摇着进入开发列表，自认为他们的留言应该被更加郑重的对待，仅仅因为他们是支付薪水的。那种态度也是对于项目其他人的一种信号，承包者看重合同这件事—而不是合同导致的代码—本应当是重要的事情。但是从其他开发者的视角，只有代码有意义。在任何时候，注意力应该保持在技术问题上，而不是谁给谁付薪水的细节。例如，Subversion社区的一个开发者用一种优雅的方式处理承包。当在IRC讨论他的代码变更时，他会在旁白（通常是在私有备注，一种IRC privmsg，发送给其他提交者）中提及他是被支付薪水完成特定bug或特性。但是他也一直表现出无论如何他都会作出那些变更的印象，并很高兴金钱可以让他完成那些工作。他可以表露客户的身份，也可以不表露，但是无论怎样，他没有详述合同。他关于此事的备注只是一个对于如何完成工作的另类技术讨论的修饰。
那个例子也展示了开放承包合同带来益处的另一个原因。会有多个组织为开源项目资助承包，如果他们都知道其他人的目标，他们可以更好的调配资源。在上面的例子中，项目最大的创建者（CollabNet）没有以任何方式参与这种计件承包，但是当知道有人为某些bug修正提供资助时，CollabNet便将其资源转向到了其他bug上，从整体上大大提高了项目的效率。
其他开发者会憎恨这些因为薪水而为项目工作的人吗？通常情况下不会，这些得到支付的人都是社区值的尊敬的成员。没有人会期待承包工作会公平的分发给所有的提交者。人们理解长期关系的重要性：从事承包的不确定性会导致一旦你发现某人值的信赖，你就不太会只是因为公平性而找其他人。可以这样想一下：你第一次雇佣时，不会有抱怨，因为你必须选出某人—不能雇佣所有人不是你的错。此后，当你第二次雇佣此人时，那只是常识：你已经了解了他，上一次是成功的，为什么要承担不必要的风险？因此，只雇佣一个或两个人，而不是将工作分散开，这是非常自然的。
资助非编程活动
编程只是开源项目的所有工作的一部分。从项目志愿者的视角，这是最明显和迷人的部分。很不幸，这意味着其他活动，例如文档、正式测试等等，是可以忽略的，至少与私有软件相比，投入了更少的精力。公司组织有时可以弥补这件事，通过投入一些他们内部软件开发时的基础架构到开源项目。
在公司内部过程和公共开发社区之间的转换是成功的关键。不过这种转换也不是轻而易举的：通常二者并不是一场接近的比赛，这种区别只能通过人为干预连接起来。例如，公司会使用与公共项目不同的bug跟踪系统。即使使用相同的跟踪软件，其中存放的数据也会大不相同，因为一个公司需要的bug跟踪与自由软件社区完全不同。位于某一跟踪系统的信息在映射到另一个系统时，必然要删除机密部分，从另一个方向来说，则是要添加。
本小节余下部分关于如何构建和维护这种联系。最后的结果必定是开源软件运行的更加平滑，社区会认可公司对于资源的投资，也不会感到公司掌控事情往自己的目标发展有什么不适合。
质量保证（也成为专业测试）
在私有软件开发中，一般都有一组人专注于质量保证：寻找bug、性能和扩展性测试、接口和文档检查等等。作为一般的原则，此类活动一般不会被自由软件项目的志愿者社区积极的追求。部分原因是很难为测试之类的不起眼工作找到志愿者，也因为人们总是假定他们有一个大的用户社区，可以给项目好的测试覆盖，以及性能和扩展性测试，也因为志愿者经常无法使用必要的硬件资源。
有很多用户等价于有许多测试者的假设并不成立。诚然，有时候分配测试者在普通环境中进行基本功能测试有一点用处：bug会在用户的日常操作中迅速被发现。但是因为用户只是期望把事情完成，他们不会有意识的开始探索程序未知的最新功能。此外，当他们在一个简单的场景发现了一个bug，他们经常悄悄的实现这个场景，而不会去报告这个bug。大多数没有意识到，你的客户（驱使你进行软件开发的人）对于软件的使用模式会与普通用户的使用模式在统计学上有显著的不同。
专业的测试团队可以迅速发现此类bug，和他们在私有软件时一样容易。真正的挑战是将测试团队的结果以有用的形式反馈给公众。在内部测试部门中，通常有自己报告测试结果的方法，也需要使用公司特定的术语，或与特定客户和他们数据集相关的专业知识。这种报告对于公共bug跟踪并不适合，一方面是因为其格式，另一方面是因为机密性。即使你公司的内部bug跟踪软件与公共项目相同，仍然需要对此问题发生的公司特定的评论和元数据变更进行管理（例如，提升某个问题的内部等级，或者设定其为特定客户进行解决）。通常情况下，这些注释是机密的—有时候他们甚至不会展示给客户。但是即使没有机密，他们对于公共项目也没有意义，因此公众不想因此分散注意力。
核心bug报告本身对于公众非常重要。实际上，来自测试团队的bug报告会比普通用户的报告更有价值，因为测试团队是在为发现问题进行探测，而普通用户不是。因为你不太可能从任何其他来源获取这样的bug报告，你一定希望将其保留并发布给公众。
为此，如果他们愿意，或者可以将内部测试报告的问题转化到公共跟踪系统中，QA部门可以在公共问题跟踪系统中归档问题。转化仅仅意味着使用不涉及用户特定信息（重现的处方会使用用户数据，当然要假定用户对此认可）的方式描述bug。
推荐让QA部门在公共跟踪系统直接填写问题。这样会让公众对你公司的投入更加感激：有用的bug报告和技术贡献一样会增加你的组织的信誉。这样也给了开发者一个与测试团队直接交流的渠道。例如，如果内部QA团队监控着公共问题跟踪系统，一个开发者可以为一个可量测bug（开发者没有资源自己测试）提交修正，并为该问题提交一个说明询问QA团队查看该修正是否起到了预期的效果。也许会遇到一些开发者的抵制；最好情况下，程序员会把QA当作必要的魔鬼。通过发现显著的bug，填写复杂的报告，QA团队可以轻易的达到这个目标；另一方面，如果他们的报告甚至没有来自普通用户社区的报告质量高，那么让他们与开发团队直接交流也没有什么意义。
无论哪一种方法，一旦公共问题已经存在，原来的内部问题就应当在技术内容中引用公共问题。管理层和有薪开发者根据需要，或许可以继续关注包含公司特定注释的内部问题，但是使用公共问题可以让所有人看到对应的信息。
你应当会预期有额外的成本。维护一个bug的两个问题，将会比一个时耗费更多的工作。好处是，将有更多的程序员将会看到这个报告，并且能为这个解决方案作出贡献。
法律建议和保护
公司，无论是盈利或非赢利，恐怕是唯一在自由软件中将精力投入到法律问题上的实体。单个开发者通常理解多种开源许可证的微妙，但他们没有时间和资源去对版权、商标和版权法进行详细研究。如果你的公司拥有法律部门，可以通过否决代码的版权状态来帮助项目，并可以帮助开发者理解可能的版权和商标问题。如何帮助的具体形式将会在讨论。主要是确保法律部门和开发社区的交流，如果发生这种交流，主要是因为完全不同的双方都有相互的渴望。在偶然情况下，这两组人会互相讨论，每一方会假定拥有另一方没有的领域特定知识。一个好的策略是在中间设定一个联络，在任何需要的时候进行转化。
文档和可用性
文档和可用性都是开源项目著名的软肋，尽管我认为，在文档方面，自由和私有软件的差距被夸大了。然而根据经验，大多数开源软件缺乏一流的文档和可用性研究。
如果你的组织希望为一个项目弥补这个差距，最好雇佣一些不属于项目常规开发者，但可以与开发者进行有效率交流的人。不雇佣开发者有两个原因：首先，你不会从项目带走开发时间；其次，距离项目过近的人通常不是编写文档或研究可用性的最佳人选，他们很难从外部视角观察软件。
然而，从事该工作的人还是有必要与开发者进行交流。找到的人需要拥有与编码团队交流的技能，但不必对软件过于专业而无法移情于普通用户。
一个中等用户很可能是编写好文档的合适人选。实际上，本书发行第一版后，我收到开源开发者Dirk Reiners的一封电子邮件：
关于金钱::文档和可用性的一些意见：当我们要花一些钱
并决定我们最需要的是编写初学者教程时，我们雇佣了一
个中级用户。他刚刚经历了系统的入门，所以能够记住问题
，但是因为已经通过问题，所以他知道如何描述问题。这样
他就可以编写一些只需由核心开发者进行少量修正的内容，
同时还是会覆盖开发组会认为‘非常明显的’而遗漏的内容。
他的案例甚至更好，随着他的工作，引入了许多用户（学
生）进入系统，所以他组合了许多人的经验，有时候某些事
看起来只是好运当头，恐怕不是在任何情况下都有效。
提供主机/带宽
对于不使用包装主机的站点（见的），提供服务器和网络连接—以及更重要的系统管理帮助—会是重要的辅助。即使这是你的组织为项目所做的唯一工作，也是一种获取公共关系回报的适度有效的方法，尽管，它不会带来任何对于项目方向的影响。
你可能会在项目主页发现一个广告条或致谢，用以感谢提供主机的公司。如果你通过设置主机，让项目网址位于公司域名之下，那么单纯通过URL你就获得了额外的联系。这会导致大多数用户认为软件与你的公司有关，即使没有在开发中作出任何贡献。问题是，开发者也会意识到这种关联的趋势，会对项目位于你的领域感到不适，除非你能贡献出除带宽以外的更多资源。毕竟，现在有很多存放主机的地方。社区会最终感觉到这种隐含信用分化与主机带来的便利并不相配，并将项目带到别的地方。所以，如果你希望提供主机，要这样做—不但要计划投入更多，更要细心的考虑声明投入多少。
市场营销
虽然大多数开源开发者不愿意承认，但市场推广确实有用。好的营销活动可以为开源产品创造良好的氛围，即使此时顽固的编码者因为一些无法说明的原因，对于软件还没有清晰肯定的思路。这里我不会讨论一般意义的市场营销的军备竞赛动力学。所有参与到自由软件的公司最终都会发现自己需要考虑如何营销自己、软件或他们与软件的关系。下面是在进行这种努力时如何避免落入陷阱的建议；请看的。
记住你正在被注视着
为了让志愿开发者社区一直站在你一边，非常重要的一点是不要说任何不能确定正确的事情。作出任何声明前要仔细审核，并要为公众提供独立检查该声明的方法。独立事实检查是开源项目的主要组成部分，它不仅仅适用于代码。
很自然，没有人会建议公司作出未验证的声明。但是在开源活动中，通常会有不可思议的大量拥有专业技能的人去验证声明—这些人也都有高速的宽带接入和足够的社会联系，可以用一种危险方法发布他们的发现，他们一定会这么干。当Global Megacorp化工的工厂污染了河流，只有经过训练的科学家可以验证，他们也会受到Global Megacorp科学家的反驳，让公众抓耳挠腮而不知如何考虑。而另一方面，你在开源世界中的行为不仅是可见的和可记录的；也很容易被许多人独立的检查，得出他们自己的结论，并口头传播这些结论。这种交流网络一直都在；那是开源操作的本质，他们可以用来传播任何信息。如果不是不可能，反驳通常很困难，特别是当某人所说的是正确的。
例如，如果你们确实这么做了，可以称你的组织“资助了项目X”。但是，如果大多数代码是外人写的，不要称自己为“X的制造者”。相反地，如果任何人都可以看到版本库只有少量代码变更来自于组织之外，不要声明已经有了一个深入参与的开发者社区。
不久之前，我看到一个知名计算机公司的一次声明，说明他们以开源许可证发布了一个重要的软件包。当最初的声明发出之后，我看了一下他们的公共版本控制版本库，发现其中只有三次修订。换句话说，他们只是做了一次代码的初始化导入，之后没做什么事情。此事本身没有什么好担心的—毕竟，他们只是做了声明。没有理由期待会立刻发生大量开发活动。
不久之后，他们作出另一次声明。下面是将名称和数字替换后声明：
我们很高兴的宣布经过Singer社区严格的测试，Linux和Windows版本的Singer 5已经做好生产使用的准备。
很想知道是什么社区进行的“严格测试”，我回到版本库去看最近的变更历史。项目还在修订3，很明显，他们没有发现任何一个值得在发布前修订的bug。考虑到社区测试一定是记录到了其他地方，接着我检查了bug跟踪系统。发现刚好有6个开放的问题，其中四个已经打开了几个月。
当然，这是乞丐的信仰（不可信）。当测试者在一个大型和复杂的软件上认真推敲一段时间，他们一定会发现bug。即使bug的修正不会进入即将到来的版本，人们还是希望有一些版本控制活动会作为测试过程的结果出现，或至少是一些新的问题。很显然，在开源许可证声明和第一次开源发布声明之间没有发生任何事情。
重点不是说这个公司在社区测试问题上说了谎。我不知道他们到底做了没有。但是他们很明显像是在欺骗。因为，无论是版本控制版本库还是问题跟踪系统，都没有任何迹象来说明所谓的严格测试曾经发生过，这个公司要么不要过早的声明，要么提供一些测试结果的明确链接（“我们发现了278个bug；点击此处看详细内容”）。后一种方法可以让任何人迅速掌握社区活动的级别。就像前面说的，我只有了几分钟就确定了这个社区测试的真相，它没有在任何常见的地方留下痕迹。那样不会花费太多力气，我确信我不是唯一保持疑惑的人。
当然，透明性和可验证性也是准确信用的重要部分。关于这些内容可以看的。
不要痛击竞争开源产品
要忍住不要发表关于竞争开源软件的负面意见。可以做的是提供负面的事实—也就是通常在一些好的比较图表上可以轻易确定的断言。但是最好避免不太严格的本性的负面特征，有两个原因。首先，这样会点燃论战而脱离有建设意义的讨论。其次，更重要的，在你的项目的一些志愿开发者会转向为竞争项目工作。开始并不是很明显：项目都在同一个领域（这也是为什么他们会竞争），拥有专业技能的开发者会在任何可以发挥专业才能的地方作出贡献。即使没有直接的开发者重叠，也很可能你的项目的开发者会与关联项目的开发者相识。他们维护建设性的个人关系的能力会被负面营销信息所束缚。
在开源世界中，痛殴闭源产品中的竞争者是可以广泛接受的，特别是如果这些产品是微软制造。个人来讲，我为这种趋势感到悲哀（虽然如此，这种直接基于事实的比较没有任何错误），不仅仅是因为这样很粗鲁，也因为这样很危险，让一个项目开始相信它自己的夸夸其谈，并忽视竞争者实际上可能更加优越的方式。通常情况下，可以仔细观察市场声明的效果，因为这也会发生在你自己的开发社区。人们可能因为市场美元的支持而丧失客观性，无法看清自己软件的真正力量和弱点。一个很可能出现的情形，某个公司的开发者会公开展示自己对于某个市场声明的无辜，甚至是直接在公共论坛。很明显，他们不应当直接跳出来否决市场营销信息（除非它事实上是错误的，尽管人们希望此类事情能够尽早被捕获）。但是他们可能会一次次的取笑这种行为，这也是将开发社区的其余部分带回地球的一个方法。