为了让志愿开发者社区一直站在你一边，非常重要的一点是不要说任何不能确定正确的事情。作出任何声明前要仔细审核，并要为公众提供独立检查该声明的方法。独立事实检查是开源项目的主要组成部分，它不仅仅适用于代码。

很自然，没有人会建议公司作出未验证的声明。但是在开源活动中，通常会有不可思议的大量拥有专业技能的人去验证声明—这些人也都有高速的宽带接入和足够的社会联系，可以用一种危险方法发布他们的发现，他们一定会这么干。当Global Megacorp化工的工厂污染了河流，只有经过训练的科学家可以验证，他们也会受到Global Megacorp科学家的反驳，让公众抓耳挠腮而不知如何考虑。而另一方面，你在开源世界中的行为不仅是可见的和可记录的；也很容易被许多人独立的检查，得出他们自己的结论，并口头传播这些结论。这种交流网络一直都在；那是开源操作的本质，他们可以用来传播任何信息。如果不是不可能，反驳通常很困难，特别是当某人所说的是正确的。

例如，如果你们确实这么做了，可以称你的组织“资助了项目X”。但是，如果大多数代码是外人写的，不要称自己为“X的制造者”。相反地，如果任何人都可以看到版本库只有少量代码变更来自于组织之外，不要声明已经有了一个深入参与的开发者社区。

不久之前，我看到一个知名计算机公司的一次声明，说明他们以开源许可证发布了一个重要的软件包。当最初的声明发出之后，我看了一下他们的公共版本控制版本库，发现其中只有三次修订。换句话说，他们只是做了一次代码的初始化导入，之后没做什么事情。此事本身没有什么好担心的—毕竟，他们只是做了声明。没有理由期待会立刻发生大量开发活动。

不久之后，他们作出另一次声明。下面是将名称和数字替换后声明：

很想知道是什么社区进行的“严格测试”，我回到版本库去看最近的变更历史。项目还在修订3，很明显，他们没有发现任何一个值得在发布前修订的bug。考虑到社区测试一定是记录到了其他地方，接着我检查了bug跟踪系统。发现刚好有6个开放的问题，其中四个已经打开了几个月。

当然，这是乞丐的信仰（不可信）。当测试者在一个大型和复杂的软件上认真推敲一段时间，他们一定会发现bug。即使bug的修正不会进入即将到来的版本，人们还是希望有一些版本控制活动会作为测试过程的结果出现，或至少是一些新的问题。很显然，在开源许可证声明和第一次开源发布声明之间没有发生任何事情。

重点不是说这个公司在社区测试问题上说了谎。我不知道他们到底做了没有。但是他们很明显像是在欺骗。因为，无论是版本控制版本库还是问题跟踪系统，都没有任何迹象来说明所谓的严格测试曾经发生过，这个公司要么不要过早的声明，要么提供一些测试结果的明确链接（“我们发现了278个bug；点击此处看详细内容”）。后一种方法可以让任何人迅速掌握社区活动的级别。就像前面说的，我只有了几分钟就确定了这个社区测试的真相，它没有在任何常见的地方留下痕迹。那样不会花费太多力气，我确信我不是唯一保持疑惑的人。

当然，透明性和可验证性也是准确信用的重要部分。关于这些内容可以看Chapter 8, 管理志愿者的the section called “荣誉”。

要忍住不要发表关于竞争开源软件的负面意见。可以做的是提供负面的事实—也就是通常在一些好的比较图表上可以轻易确定的断言。但是最好避免不太严格的本性的负面特征，有两个原因。首先，这样会点燃论战而脱离有建设意义的讨论。其次，更重要的，在你的项目的一些志愿开发者会转向为竞争项目工作。开始并不是很明显：项目都在同一个领域（这也是为什么他们会竞争），拥有专业技能的开发者会在任何可以发挥专业才能的地方作出贡献。即使没有直接的开发者重叠，也很可能你的项目的开发者会与关联项目的开发者相识。他们维护建设性的个人关系的能力会被负面营销信息所束缚。

在开源世界中，痛殴闭源产品中的竞争者是可以广泛接受的，特别是如果这些产品是微软制造。个人来讲，我为这种趋势感到悲哀（虽然如此，这种直接基于事实的比较没有任何错误），不仅仅是因为这样很粗鲁，也因为这样很危险，让一个项目开始相信它自己的夸夸其谈，并忽视竞争者实际上可能更加优越的方式。通常情况下，可以仔细观察市场声明的效果，因为这也会发生在你自己的开发社区。人们可能因为市场美元的支持而丧失客观性，无法看清自己软件的真正力量和弱点。一个很可能出现的情形，某个公司的开发者会公开展示自己对于某个市场声明的无辜，甚至是直接在公共论坛。很明显，他们不应当直接跳出来否决市场营销信息（除非它事实上是错误的，尽管人们希望此类事情能够尽早被捕获）。但是他们可能会一次次的取笑这种行为，这也是将开发社区的其余部分带回地球的一个方法。