如果您已经读到这里，恭喜您，您即将读完本文档。最后这一节描述了您作为项目维护者，在哪些情况下会与用户互动。并就如何有效处理这些情况提出一些建议。
与用户互动是困难的。在我们讨论与开发者的互动时，其潜在的假设是，在一个自由软件项目中，项目维护者必须不断努力吸引和留住可以随时离开的开发者。
自由软件社区中的用户与开发者不同，也与专有软件世界中的用户不同，他们应该被区别对待。以下是一些群体之间显著差异的方面：
尝试解决这种独特的情况只能间接地进行。开发者和维护者需要倾听用户的意见，并尽可能做出响应。对上述情况的充分了解是任何自由软件开发者调整其开发或领导风格以适应自由软件项目管理的独特过程的最佳工具。本章将尝试介绍任何项目与用户互动中更困难或更重要的点，并就如何处理这些点给出一些提示。
除了您的用户是您的开发者之外，他们也是（也许更常见的是）您的测试者。在我被批评之前，我应该重新措辞我的句子：您的一些用户（那些明确自愿的用户）是您的测试者。
尽早做出这种区分非常重要，因为并非所有用户都想成为测试者。许多用户希望使用稳定的软件，并且不在乎他们是否拥有最新、最棒的软件以及最新的、最棒的功能。这些用户期望获得一个稳定、经过测试且没有重大或明显错误的软件，如果他们发现自己在测试，他们会很生气。这是拆分开发模型（如第 3.3 节中提到的）可能派上用场的另一种方式。
“以开源方式管理项目” 描述了一个好的测试应该寻找什么
最大缓冲区长度、数据转换、上限/下限等。
最好找出程序在用户向其传递预期之外的值、按下错误的按钮等情况下会做什么。问自己一堆 “如果...会怎样” 的问题，并思考任何可能失败或可能出错的事情，并找出您的程序在这些情况下会做什么。
上面许多 “如果...会怎样” 问题的答案很可能是 “失败”，这通常是唯一的答案。现在确保它发生得很顺利。确保当它崩溃时，有一些关于它为什么崩溃或失败的指示，以便用户或开发者理解发生了什么。
如果可能，请确保您的程序符合标准。如果是交互式的，不要在界面上过于创新。如果是非交互式的，请确保它通过适当且已建立的通道与其他程序和系统的其余部分进行通信。
对于许多程序，许多常见错误可以通过自动化方式捕获。自动化测试往往非常擅长捕获您之前多次遇到的错误或您只是忘记的事情。它们不太擅长发现错误，即使是重大的错误，也是完全无法预料的错误。
对于任何依赖用户交互的程序，许多错误只能通过用户实际点击按键和按下鼠标按钮的测试来发现。为此，您需要测试者，而且越多越好。
测试最困难的部分是找到测试者。通常，一个好的策略是在相关的邮件列表或新闻组中发布消息，宣布一个特定的拟议发布日期，并概述程序的功能。如果您在公告上花一些时间，您肯定会收到一些回复。
测试的第二大难点是留住您的测试者，并让他们积极参与测试过程。幸运的是，有一些久经考验的策略可以应用于此目的
任何支持基础设施的关键要素是良好的文档，这应该不足为奇。这个主题在 第 2.5 节中已进行了大量介绍，此处不再赘述。
除了文档之外，有效的邮件列表将是您提供用户支持的最大工具。良好地运行邮件列表比在机器上安装邮件列表软件更复杂。
请不要冲动地选择邮件列表软件。请考虑没有太多技术经验的用户易于访问，因此您希望尽可能容易。Web 访问列表存档也很重要。
两个最大的自由软件邮件列表程序是 majordomo 和 GNU Mailman。作为 majordomo 的长期倡导者，我现在会建议任何项目选择 GNU Mailman。它满足了上面列出的标准，并使其更容易。它为自由软件项目维护者提供了一个好的邮件列表程序，而不是为邮件列表管理员提供了一个好的邮件列表应用程序。
在设置列表时，您还需要考虑其他事项。如果可以将您的邮件列表连接到 Usenet 并以摘要形式提供，并在 Web 上访问它们，您将取悦一些用户，并努力使支持基础设施更易于访问。
邮件列表和可访问的文档远非您可以为建立良好的用户支持基础设施所做的一切。发挥创意。如果您偶然发现一些效果良好的东西，请给我发电子邮件，我会将其包含在此处。
您可以列出太多联系您的方法。如果您在 IRC 频道中闲逛，请毫不犹豫地将其列在您的项目文档中。列出电子邮件和邮寄地址，以及通过 ICQ、AIM 或 Jabber 联系您的方式（如果适用）。
对于许多大型软件项目，使用 Bug 管理软件对于跟踪哪些 Bug 已修复、哪些 Bug 尚未修复以及哪些 Bug 正在由哪些人修复至关重要。Debian 使用 Debian Bug 跟踪系统 (BTS)，尽管它可能不是每个项目的最佳选择（它目前似乎在其自身重量下摇摇欲坠）。除了一个非常好的 Web 浏览器之外，Mozilla 项目还衍生出一个子项目，产生了一个名为 bugzilla 的 Bug 跟踪系统，该系统已变得非常流行，我非常喜欢它。
这些系统（以及其他类似的系统）可能很笨重，因此开发者应注意不要在 Bug 跟踪系统上花费比在 Bug 或项目本身上更多的时间。如果一个项目继续增长，使用 Bug 跟踪系统可以为用户和测试者提供一个简单的标准途径来报告 Bug，并为开发者和维护者提供一个有序的方式来修复和跟踪它们。
一种策略是首先进行 “alpha” 或 “beta” 版本发布，如下面 第 4.3.3 节中所述。但是，上面描述的大多数准则仍然适用。
当您从直觉上感觉是时候了，并且您觉得您已经多次权衡了情况，请祈祷并大胆尝试。
在您第一次发布之后，知道何时发布变得不那么有压力，但同样难以衡量。我喜欢 Robert Krawitz 在他的文章 “自由软件项目管理” 中为保持良好的发布周期提供的标准。他建议您问自己，“此版本是否...”
包含足够的新功能或 Bug 修复，值得付出努力。
间隔足够长，以便用户有时间使用最新版本。
功能足够强大，以便用户可以完成工作（质量）。
如果对所有这些问题的答案都是肯定的，那么可能就是发布的时候了。如果心存疑虑，请记住寻求建议不会有坏处。
在考虑发布时，值得考虑的事实是，并非每个版本都需要是完整的编号版本。软件用户习惯了预发布版本，但您必须小心准确地标记这些版本，否则它们会引起比它们本身价值更多的问题。
人们经常观察到，许多自由软件开发者似乎对发布周期感到困惑。“以开源方式管理项目” 建议您记住这句话，“Alpha 不是 Beta。Beta 不是正式版”，我同意这可能是一个好主意。
Alpha 软件在功能上是完整的，但有时只有部分功能可用。
Alpha 版本预计是不稳定的，可能有点不安全，但绝对可用。它们可以有已知的 Bug 和尚未解决的缺陷。在发布 alpha 版本之前，请务必记住，alpha 版本仍然是版本，人们不会期望从 CVS 源代码获得每夜构建版本。Alpha 版本应该可以工作，并且已经完成了最少的测试和 Bug 修复。
Beta 软件在功能上是完整的且可用的，但处于测试周期中，并且仍有一些 Bug 需要解决。
Beta 版本通常预计是可用的且略微不稳定的，但绝对不是不安全的。 Beta 版本通常在正式版本发布前不到一个月发布。它们可能包含小的已知 Bug，但没有重大的 Bug。所有主要功能都应完全实现，尽管确切的机制仍有待完善。Beta 版本是激发潜在用户胃口的好工具，它们可以让潜在用户非常真实地了解您的项目在不久的将来会发展到什么程度，并且可以通过给人们一些东西来帮助保持兴趣。
“开发版本” 是一个比 “alpha” 或 “beta” 更模糊的术语。我通常选择保留该术语用于讨论开发分支，尽管还有其他使用该术语的方式。事实上，有很多种用法，以至于我觉得这个术语已经被廉价化了。流行的窗口管理器 Enlightenment 只发布开发版本。最常见的是，该术语用于描述甚至不是 alpha 或 beta 的版本，如果我要发布一个 pre-alpha 版本的软件以保持人们对我的项目的兴趣，这可能就是我必须标记它的方式。
在 Usenet 的 comp.os.linux.announce 上宣布您的软件。如果您只在两个地方宣布您的软件，那就选择 c.o.l.a 和 freshmeat。
但是，电子邮件仍然是互联网上大多数人获取信息的方式。将宣布您的程序的消息发送到您知道的任何相关邮件列表和任何其他相关的 Usenet 讨论组是一个好主意。
Karl Fogel 建议您使用简单的标题来描述该消息是公告、程序名称、版本以及半行长的功能描述。这样，任何感兴趣的用户或开发者都会立即被您的公告所吸引。Fogel 的示例看起来像
Subject: ANN: aub 1.0, a program to assemble Usenet binaries |
电子邮件的其余部分应在不超过两段的篇幅内快速简洁地描述程序的功能，并应提供指向项目网页的链接以及直接指向下载的链接，供那些想要立即尝试的人使用。这种形式适用于 Usenet 和邮件列表帖子。
您应该在每个后续版本中在相同的位置一致地重复此公告过程。
如 第 2.1.2.1 节前面提到的，在今天的自由软件社区中，在 freshmeat 上宣布您的项目几乎比在邮件列表上宣布更重要。
访问 freshmeat.net 网站 或他们的 提交项目页面，将您的项目发布到他们的网站和数据库中。除了一个大型网站之外，freshmeat 还提供每日新闻通讯，重点介绍当天所有版本，并覆盖庞大的受众（我个人每天晚上都会浏览它，看看是否有任何有趣的新版本）。