作为一些个体出现，而不是一个整体

你的开发者必须力求在项目的公共论坛中以一个单独的参与者出现，而不是一个单独的公司。这不是因为作为一个公司出现本身固有的一些负面含义（好的，或许有一些，但那不是本书所讨论的）。而是因为开源项目的结构配备只能处理个人实体。一个单独的贡献者可以讨论、提交补丁、获取信誉、表决等等。而一个公司不能。

此外，因为分布式的行为方式，你避免了对于刺激性中央集权的敌对。让你的开发者在邮件列表中意见并不一致。鼓励他们经常评审他人的代码，尽可能的公开，就象他们是任何其他的人。阻止他们象一个集团一样表决，因为如果你这样做，其他人就会感觉到，根据一般的原理，一定有一个有组织的力量在控制他们。

实际的非中央集权和假装的是有区别的。在特定环境下，让你的开发者协同一致会非常有用，而且如果必要还必须在幕后进行协调。例如，当发出提议时，让许多人尽早跳出来表示认可，得出正在达成共识的印象会有助于提议的进展。其他人会感到提议的动量，如果他们反对，他们需要阻止这个动量。因此，人们只会在有好的原因时才会提出反对。如果能够慎重对待反对意见，这样的精心安排也没有错。私下协议的公众表现不会因为经过预先的协调而变得不够诚实，只要他们没有用这个方法来扼杀反对意见就不会有太多害处。他们的目的仅仅是阻止那些喜欢保持个性的人提出反对意见；更多相关内容可以看Chapter 6, 交流的the section called “主题越软，辩论越长”。