开源世界中成功的价值很重。随着你的软件的流行，搜寻信息的人也会急剧增加，而能够提供信息的人则增长的慢很多。此外，即使比率能够保持平衡，在大多数开源项目中处理交流也依然存在基础扩展问题。以邮件列表为例。大多数项目有一个一般用户问题的邮件列表—有时，列表的名称是“users”、“discuss”、“help”或其他。无论名称是什么，列表的目的相同：为人们获取问题的答案提供一个场所，同时其他人可以观看并通过观察这种交换（假设的）获取知识。
这种邮件列表可以在数千用户和每天几百文章的情况下工作良好。但之后不久，这个系统就会出现问题，因为每个订阅者看到的文章会超过单个订阅者每天可以处理的数量，这个列表成为了其成员的负担。想象一下，如果微软有一个针对Windows XP的邮件列表。Windows XP有数亿的用户，如果仅有千分之一的用户在24小时内有问题，那么这个假设的列表每天也会有数十万的文章！不可能有这种列表，因为不可能有人会一直订阅它。问题不仅仅限于邮件列表；同样的逻辑也可以应用到IRC频道，在线讨论论坛，以及所有从单个人获取问题的团队。其暗示并不吉利：大规模并行支持的普通开源模型不能扩展到支配全世界的级别。
当论坛达到临界点时并不会发生爆炸。只有一个静悄悄的负面反馈效果：人们会取消列表的订阅，或者离开IRC频道，或者不再去咨询问题，因为他们无法去听所有的噪音。因为有越来越多的人作出了理性的选择，论坛的活动会看起来一直处于可管理的级别。但是，它精确的处于可管理级别是因为理性的（或仅仅是有经验的）人会去寻找其他地方获取信息—而缺乏经验的人会留下来继续发表文章。换句话说，随着项目的成长，如果仍使用未扩展的交流模型，那就会产生询问和回答的平均质量逐渐下降的副作用，感觉就好象新用户比原来更呆了，但实际上并不是如此。只是高人口论坛的收益/花费比变得更低，自然那些有经验的人会开始在其他地方寻找答案。根据项目的成长调整交流机制包含两个相关的策略：
识别出论坛特定部分，甚至整个论坛正在经历有限制的增长，将这部分分割为新的更专业的论坛（也就是说不要让坏的拖累好的）。
确保有许多自动的信息来源，并组织有序、更新及时和易于查找。
策略（1）通常并不难。大多数项目有一个主要论坛开始：一个一般的讨论邮件列表，会包含所有的特性构想、设计问题和编码问题。项目的参与者都会在这个列表上。经过一段时间，整个列表就会很清晰的进化为基于不同主题的子列表。例如，一些线索很明显是关于开发和设计；而另外一些是诸如“如何完成X？”的用户问题；或许还有第三类关于如何处理bug报告和增强请求的主题；等等。对于每一个个体，或许会参与到许多不同的线索类型，但是这些类型之间没有过多的重叠。他们可以划分到不同的列表，而不会造成严重的割据问题，因为这些主题极少会跨越主题的边界。
实际上这种分割是两步骤的过程。你创建新的列表（或者IRC频道，或任何其他的东西），然后你要花必要的时间有礼貌的唠叨和提醒人们使用新的更合适的论坛。后一个步骤会持续几周，但是最终人们会明白。你只需对所有发送到错误目标的人解释这个问题，然后因为大家都看到得到，人们就会被鼓励例行公事一样去帮助解决。当然，提供一个所有列表的指南网页也非常有用；你的回复可以直接引用网页，然后作为奖励，接收者会在发表文章前通过指南学习到一些东西。
策略（2）是一个持续的过程，会伴随项目的一生，需要许多参与者。当然，它部分依赖于是否拥有及时的文档（Chapter 2, 起步的the section called “文档”），并能够指引人们去观看。但不仅仅如此；这个小节的后面会详细讨论这个策略。
通常来说，开源项目中的所有交流（除了一些IRC的对话）都应该归档。归档应该公开且可搜索，并要具备引用的稳定性：也就是一旦信息记录到了特定的地址，就可以永远使用这个地址。
尽可能多的使用那些归档，越显著越好。即使你知道某个问题的答案就在你的脑中，但如果你知道归档中有一个包含此答案的引用，那么请找到并展示出来。每次你使用公开可见的方式完成，有些人就会知道归档，并会在其中寻找答案。另外，通过引用归档而不是重写建议，可以加强对于复制信息的社会标准。为什么同一个答案会出现在不同的地方？当可以找到答案的地方还比较少，人们就更可能会记住地址并再次查找。精心放置的引用也可以帮助改进搜索结果的质量，因为他们可以加强目标资源在互联网搜索引擎中的权重。
当然有时复制信息也有意义。例如，在归档中已经有了一个来自别人的回应说：
看起来你的Scanley索引开始fronbnicated。为了unfrobnicate，可以按照如下步骤： 1. 关闭Scanley服务器。 2. 运行Scanley的'defrobnicate'程序。 3. 启动服务器。
然后，几个月之后，你看到另外一篇文章显示某人的索引变得frobnicated。你搜索归档并发现了上面这个较早的回复，但是你认识到它遗漏了一些步骤（或许是因为误解，也可能是因为软件在那篇文章之后发生了改变）。最经典的方式是发表一篇新文章，更完整的指导，并明确的废弃较早的那篇文章：
看起来你的Scanley索引已经变得frobnicated。我们在7月份看到过这个问 题，而且J. Random在http://blahblahblah/blah发布过一个解决办法。下面 是根据J. Random的指导unfrobnicate你的索引的方法，有一些扩展： 1. 关闭Scanley服务器。 2. 成为通常运行Scanley服务器的用户。 3. 作为该用户，在索引上运行'defrobnicate'程序。 4. 手工运行Scanley，并查看索引是否工作。 5. 重启服务器。
（在理想的世界，可以为原来的文章附加一个注释，说明有较新的信息，并指向新文章。然而，我不知道有什么归档软件支持“废弃”特性，或许因为在不违反归档逐条的归档完整性的情况下实现有一点狡猾。这是设置一个专门的网页回答常见问题的另一个原因。）
归档可能经常被用来查找技术问题的答案，但是他们对于项目的重要性不仅如此。如果说项目的正式指南的法定法律，那么归档就是不成文法：所有决策如何制定和如何得出的记录。对于任何重现的讨论，从归档搜索开始是义不容辞的。这允许你从当前状态、期望的目标、举反证和发现你没有想到立场的摘要开始讨论。另外，其他参与者会期望你已经做了归档搜索。即使之前的讨论没有结果，在你重新提出这个主题时也要指出它们，这样人们就可以自己看到a) 讨论没有结果，并且b) 你做了功课，那么现在说一些没说过的话吧。
之前的所有建议不只是能应用到邮件列表归档。零散的信息都位于稳定，便利和可查询的地址，这必须成为项目所有信息的组织原则。我们以项目FAQ为例进行研究。
人们如何使用FAQ？
他们希望在其中查找特定的单词和短语。
他们希望进行浏览，获取信息，而不是去寻找特定问题的答案。
他们希望诸如Google之类的搜索引擎可以知道FAQ的内容，所以可以搜索到FAQ条目。
他们希望在FAQ中直接为其他人提供特定项目的引用。
他们希望为FAQ提供新的材料，但是注意到添加比查询回答要少许多—FAQ更多的是阅读，而不是编写。
第1点暗示我们FAQ一定要以文本格式存在。第2和第3点暗示FAQ应当以HTML格式存在，第2点也说明HTML必须针对可读性进行设计（即你会希望控制起观感），而且必须有目录。第4点意味着FAQ的每个条目都赋予了一个HTML命名的Anchor，一个用户可以到达页面特定位置的标记。第5点说明FAQ的源文件必须用便利的方法存在（见Chapter 3, 技术基础设施的the section called “版本化所有的东西”），并使用易于编辑的格式。
格式化FAQ只是如何让一个资源可以展示出来的例子。同样的属性—直接的咳嗽索性、主要搜索引擎的存在性、可浏览性、引用稳定性和（合适的地方）可编辑性—可以应用到其他网页、源代码树和bug跟踪系统等等。只是在不久之前大多数邮件列表归档软件才认识到了这些属性的重要性，也是邮件列表倾向于本身具备这些功能的原因，其他格式或许需要维护者花费更多的经历（Chapter 8, 管理志愿者讨论了如何在多个志愿者间分担负担）。
随着项目的日积月累和复杂化，每个新来的参与者必须吸收的数据量大增。那些伴随项目很长时间的人能够根据以前的经历认识到和发明项目的习俗。他们会本能的意识到积累了大量传统，并会为新来者的大量过失而感到惊讶。当然，问题不是新来者的质量降低了；而因为他们面对的是比以前更多的积累负担。
一个项目积累的传统取决于他们交流和保存信息的方法，以及他们的编码标准和其他技术备忘录。我们已经看了两种标准，分别在Chapter 2, 起步的the section called “开发者文档”和Chapter 4, 社会和政治的基础架构的the section called “写下所有的内容”，也都有各自的例子。本小节关注的是如何在项目进化中保持指南的及时性，特别是关于如何管理交流的指南，因为这些指南会随着项目规模和复杂性的成长发生最显著的变化。
首先，关注人们陷入混淆的模式。如果你看到同样的情形屡次发生，特别是发生在新参与者身上时，就是需要记录指南的机会了。其次，不要厌烦反复说同样的话，也不要表现出对说这些话的厌烦。你和其他项目老兵都需要经常的重复自己；这是新手到来时不可避免的副作用。
每个网页、每个邮件列表信息和每个IRC频道必须考虑广告空间—不是商业广告，而是自己项目资源的广告。你所放置的内容取决于会观看它的人口统计数据。一个针对用户问题的IRC频道，其中通常是那些从未与项目交互的人—通常是只安装了软件，需要立刻获得问题答案的人（毕竟，如果他们可以等待，他们可以发送到邮件列表，整体上他将会花费较少的时间，尽管那样会需要更长的时间得到回答）。人们通常不会在IRC频道作出永久投资，他们会露面，询问问题，然后离开。
因而，频道的主题必须针对那些希望立刻寻找软件技术回答的人，而对那些以长期方式参与项目的人，社区交流指南或许更合适。下面是真正忙碌频道的处理方式（Chapter 3, 技术基础设施的the section called “IRC / 实时聊天系统”）：
你现在位于#linuxhelp 关于#linuxhelp的主题请阅读 http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto 询问问题之前 | 频道规则 在http://www.nerdfest.org/lh_rules.html | 升级到内核2.6.x 请看 http://kerneltrap.org/node/view/799 | 内存读可能性: http://tinyurl.com/4s6mc -> 更新到2.6.8.1或2.4.27 | 哈希算法灾难: http://tinyurl.com/6w8rf | reiser4放出
在邮件列表中，“广告空间”是追加在每封邮件后的小注脚。大多数项目会在这里放置订阅/取消订阅的指导，也可能是项目主页或FAQ的链接。你或许会认为所有订阅列表的人都会知道如何做，很可能是—但是会有更多不是订阅者的人会看到邮件列表信息。一个归档的文章会被链接到许多地方；实际上，某些文章最终会变得家喻户晓，有远多于列表订阅者的阅读者。
格式化可以产生明显的区别。例如，在Subversion项目，我们在Chapter 3, 技术基础设施的the section called “Bug跟踪的预过滤”中描述的使用bug过滤技术，取得了有限的成功。经验不足的人会一直发起许多虚假的bug报告，每当发生这种情况，档案管理员必须像他之前的500人那样对此有足够的认识。某天，我们的某个开发者终于忍无可忍，对那些不阅读问题跟踪系统指南的倒霉用户开始发火，另一个开发者则决定这种情况不应该再发生了。他建议重新调整问题跟踪首页的布局，这样最要的部分，也就是在提交之前必须在邮件列表中讨论bug的命令，将会使用较大和粗体红色字体，亮黄色背景，页面居中突出显示处理。我们这样做了（你可以在http://subversion.tigris.org/project_issues.html看到结果），结果是虚假问题的录入率大大降低。我们依然会得到虚假的问题，当然—我们一直会—但是比例显著降低，甚至是在用户数大增的情况下。结果不仅是bug数据库中的垃圾大大减少，而且那些响应问题的人也得到了好情绪，也就更容易在面对罕见的虚假bug时保持友好。这样不仅改善了项目的形象，也改善了志愿者的心理健康。
仅仅是写出指导方针的课程对于我们来说还远远不够。我们也必须让最需要的人看到这些东西，它们的状态要像介绍材料一样格式化处理，这样对项目不熟悉的人们也可以立刻清晰明了。
静态网页不是发布项目习惯唯一的维纳斯。一定数量的的交互政策（友情提示的感觉，而不是冷冰冰的手铐脚镣）也是必需的。所有的同级评审，甚至Chapter 2, 起步的the section called “实践明显的代码评审”描述的提交评审，都应该包括对于人们是否遵守项目规范的检查，特别是与交流习惯相关的。
Subversion项目的另一个例子：我们在版本控制版本库设定了“r12908”表示“修订版本12908”的习惯。小写的“r”前缀很容易输入，又因为它只有数字的一半高度，所以与数字在一起时非常易于识别。当然，设定了习惯并不意味着每个人都会一直以正确的方式使用它。因而，每当有这样包含日志信息的提交邮件时：
------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines Patch from J. Random Contributor <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Fixed some typos from revision 12828. ------------------------------------------------------------------------
...某些提交评审者就会说“顺便说一句，请使用‘r12828’，而不是修订版本（revision）12828引用过去的变更。这不是卖弄学问；重要的是自动解析和人类阅读。
通过遵循一般的原理，包括对常见实体的权威参考方法，以及必须放之四海皆准参考方法，这个项目输出特定的标准。这些标准使得人们可以编写工具用更有价值的方式展现项目交流—例如，一个格式为“r12828”的修订版本可以在版本库浏览工具中被转化为可用的链接。但是如果修订版本写成“revision 12828”，则这项工作将会难许多，一方面因为链接会在换行处分隔，另一方面也因为限制不足（单词“revision”会经常单独出现，一组数字也会单独出现，而他们的组合“r12828”则只意味着修订版本号码）。类似的，同样的关注面也适应于问题号码，FAQ项目（提示：在命名的Anchor和ID属性描述的，使用命名锚点的URL）等等。
即使对于没有简短和权威形式的实体，也要鼓励人们提供一致的关键细节信息。例如，当引用到一个邮件列表信息时，不要只给出发送者和主题；请也给出归档URL和信息的ID头。这样可以让那些虽然自己也有邮件列表拷贝（人们有时会保存离线备份，例如在旅行中使用笔记本时）的人，能够明确无误的定位到正确的信息，甚至无须访问他们自己的归档。发送者和主题并不足够，因为一天里同一个人可能为某一个线索发表过许多文章。
项目愈大，愈是需要这类一致性。一致性意味着人们会在所有的地方，看到被以相同的方式遵循的模式，这样他们知道自己也需要遵循这些模式。作为回报，减少了回答问题的必要。拥有几百万读者的负担并不比仅仅一个更大；扩展性的问题源于一定比例的读者开始提问了。随着项目的成长，必须依靠增加信息的密度和可访问性，才能减少这种比例，这样人们才能更容易的找到答案，而无需提问。