如果你的项目有付费的开发者，一定要尽早设置钱可以购买什么东西的指导方针。这并不意味着你需要每天在邮件列表中说明两次来重申你的高尚和不腐的本性。你只需要在恰当的时机放松由钱导致的紧张。你不需要从一开始就假设存在这种紧张；你只需要说明有这种可能性。

一个完美的例子就是Subversion项目。CollabNet在2000年开始了Subversion，从一开始它便是项目主要的投资者，为多个开发者提供薪水（免责声明：包括我）。项目开始后不久，我们雇佣了另一个开发者Mike Pilato，参与开发工作。此时，编码工作已经开始。尽管Subversion还处于早期阶段，但已经有了一个开发者社区和许多基本的规则。

Mike的到来突现了一个有趣的问题。Subversion已经有了开发者如何获得提交权的政策。首先，他需要在开发邮件列表中提交一些补丁。当有了足够的补丁后，其他提交者看到新贡献者知道自己所做的事情，某人就会提议他直接提交（这个提议是私下的，就像the section called “提交者”所描述的）。如果提交者们同意，其中的某人就会邮件通知新的开发者，并为他设置直接提交访问项目版本库的权限。

CollabNet是专门为Subversion项目雇佣了Mike。他们已经对他足够了解，对于他的编码技巧和在此项目所作的准备毫无疑问。此外，志愿者开发者已经与CollabNet雇员有了非常好的关系，看起来如果我们直接在雇用Mike当天就赋予他权限也不会有什么反对意见。但是我们知道我们正在设置一个先例。如果我们按命令给Mike提交权利，我们会说CollabNet有权无视项目的指导方针，只是因为它是主要的投资者。这种行为的害处未必立刻显现出来，它会导致非付费开发者逐渐感到被剥夺了投票权。其他人自己赢得他们的提交权利—而CollabNet只需要花钱买。

所以Mike赞成象其他志愿开发者一样，在没有提交权限的情况下开始了在CollabNet的雇佣工作。他在公共列表中发布补丁，在其中可能会受到，实际上也确实受到了所有人的评审。我们在列表中也说过我们是故意这样做的。经过Mike数周的扎实活动，某人（我不记得是否是CollabNet开发者）提议给他提交权限，而他被接受了，当然，我们知道他会被接受。

那种类型的一致性会让你确信钱不可以买到一切。这种确信是技术讨论中珍贵的流通货币：可以免于以后让某人的动机被怀疑。在辩论最激烈时，人们有时会寻找非技术的方式来赢得战斗。项目的主要投资者，因为涉足较深并且显然会对项目采取的方向十分关注，会展示出比大多数人更广的目标。通过从一开始就一丝不苟的遵守项目方针，投资者就可以获得和所有人一样的影响力。

（Danese Cooper的blog上http://blogs.sun.com/roller/page/DaneseCooper/20040916有关于提交权限的类似故事。Cooper是Sun Microsystem的“开源Diva”—我相信这是她的官方头衔—在她的blog中，她描述了Tomcat开发社区让Sun在控制提交权限时对Sun的人员和非Sun的人员一视同仁。）

创始人对所有人使用相同规则的需要意味着慈善独裁统治模型（见Chapter 4, 社会和政治的基础架构的the section called “慈善独裁者”）在投资面前有一点难于实施，特别是独裁者为主要的投资方工作的情况。因为独裁有一些规则，投资者很难证明遵守了社区标准，即使事实如此。这确实不是不可能；只是需要项目领导者既能够从投资方也能够从外围开发者的视角看待事物，并依此行动。即使那样，也最好能在后口袋有一个非独裁管理的提议，准备好在社区的不满扩散时掏出来。