编程只是开源项目的所有工作的一部分。从项目志愿者的视角，这是最明显和迷人的部分。很不幸，这意味着其他活动，例如文档、正式测试等等，是可以忽略的，至少与私有软件相比，投入了更少的精力。公司组织有时可以弥补这件事，通过投入一些他们内部软件开发时的基础架构到开源项目。
在公司内部过程和公共开发社区之间的转换是成功的关键。不过这种转换也不是轻而易举的：通常二者并不是一场接近的比赛，这种区别只能通过人为干预连接起来。例如，公司会使用与公共项目不同的bug跟踪系统。即使使用相同的跟踪软件，其中存放的数据也会大不相同，因为一个公司需要的bug跟踪与自由软件社区完全不同。位于某一跟踪系统的信息在映射到另一个系统时，必然要删除机密部分，从另一个方向来说，则是要添加。
本小节余下部分关于如何构建和维护这种联系。最后的结果必定是开源软件运行的更加平滑，社区会认可公司对于资源的投资，也不会感到公司掌控事情往自己的目标发展有什么不适合。
在私有软件开发中，一般都有一组人专注于质量保证：寻找bug、性能和扩展性测试、接口和文档检查等等。作为一般的原则，此类活动一般不会被自由软件项目的志愿者社区积极的追求。部分原因是很难为测试之类的不起眼工作找到志愿者，也因为人们总是假定他们有一个大的用户社区，可以给项目好的测试覆盖，以及性能和扩展性测试，也因为志愿者经常无法使用必要的硬件资源。
有很多用户等价于有许多测试者的假设并不成立。诚然，有时候分配测试者在普通环境中进行基本功能测试有一点用处：bug会在用户的日常操作中迅速被发现。但是因为用户只是期望把事情完成，他们不会有意识的开始探索程序未知的最新功能。此外，当他们在一个简单的场景发现了一个bug，他们经常悄悄的实现这个场景，而不会去报告这个bug。大多数没有意识到，你的客户（驱使你进行软件开发的人）对于软件的使用模式会与普通用户的使用模式在统计学上有显著的不同。
专业的测试团队可以迅速发现此类bug，和他们在私有软件时一样容易。真正的挑战是将测试团队的结果以有用的形式反馈给公众。在内部测试部门中，通常有自己报告测试结果的方法，也需要使用公司特定的术语，或与特定客户和他们数据集相关的专业知识。这种报告对于公共bug跟踪并不适合，一方面是因为其格式，另一方面是因为机密性。即使你公司的内部bug跟踪软件与公共项目相同，仍然需要对此问题发生的公司特定的评论和元数据变更进行管理（例如，提升某个问题的内部等级，或者设定其为特定客户进行解决）。通常情况下，这些注释是机密的—有时候他们甚至不会展示给客户。但是即使没有机密，他们对于公共项目也没有意义，因此公众不想因此分散注意力。
核心bug报告本身对于公众非常重要。实际上，来自测试团队的bug报告会比普通用户的报告更有价值，因为测试团队是在为发现问题进行探测，而普通用户不是。因为你不太可能从任何其他来源获取这样的bug报告，你一定希望将其保留并发布给公众。
为此，如果他们愿意，或者可以将内部测试报告的问题转化到公共跟踪系统中，QA部门可以在公共问题跟踪系统中归档问题。转化仅仅意味着使用不涉及用户特定信息（重现的处方会使用用户数据，当然要假定用户对此认可）的方式描述bug。
推荐让QA部门在公共跟踪系统直接填写问题。这样会让公众对你公司的投入更加感激：有用的bug报告和技术贡献一样会增加你的组织的信誉。这样也给了开发者一个与测试团队直接交流的渠道。例如，如果内部QA团队监控着公共问题跟踪系统，一个开发者可以为一个可量测bug（开发者没有资源自己测试）提交修正，并为该问题提交一个说明询问QA团队查看该修正是否起到了预期的效果。也许会遇到一些开发者的抵制；最好情况下，程序员会把QA当作必要的魔鬼。通过发现显著的bug，填写复杂的报告，QA团队可以轻易的达到这个目标；另一方面，如果他们的报告甚至没有来自普通用户社区的报告质量高，那么让他们与开发团队直接交流也没有什么意义。
无论哪一种方法，一旦公共问题已经存在，原来的内部问题就应当在技术内容中引用公共问题。管理层和有薪开发者根据需要，或许可以继续关注包含公司特定注释的内部问题，但是使用公共问题可以让所有人看到对应的信息。
你应当会预期有额外的成本。维护一个bug的两个问题，将会比一个时耗费更多的工作。好处是，将有更多的程序员将会看到这个报告，并且能为这个解决方案作出贡献。
公司，无论是盈利或非赢利，恐怕是唯一在自由软件中将精力投入到法律问题上的实体。单个开发者通常理解多种开源许可证的微妙，但他们没有时间和资源去对版权、商标和版权法进行详细研究。如果你的公司拥有法律部门，可以通过否决代码的版权状态来帮助项目，并可以帮助开发者理解可能的版权和商标问题。如何帮助的具体形式将会在Chapter 9, 许可证，版权和专利讨论。主要是确保法律部门和开发社区的交流，如果发生这种交流，主要是因为完全不同的双方都有相互的渴望。在偶然情况下，这两组人会互相讨论，每一方会假定拥有另一方没有的领域特定知识。一个好的策略是在中间设定一个联络，在任何需要的时候进行转化。
文档和可用性都是开源项目著名的软肋，尽管我认为，在文档方面，自由和私有软件的差距被夸大了。然而根据经验，大多数开源软件缺乏一流的文档和可用性研究。
如果你的组织希望为一个项目弥补这个差距，最好雇佣一些不属于项目常规开发者，但可以与开发者进行有效率交流的人。不雇佣开发者有两个原因：首先，你不会从项目带走开发时间；其次，距离项目过近的人通常不是编写文档或研究可用性的最佳人选，他们很难从外部视角观察软件。
然而，从事该工作的人还是有必要与开发者进行交流。找到的人需要拥有与编码团队交流的技能，但不必对软件过于专业而无法移情于普通用户。
一个中等用户很可能是编写好文档的合适人选。实际上，本书发行第一版后，我收到开源开发者Dirk Reiners的一封电子邮件：
关于金钱::文档和可用性的一些意见：当我们要花一些钱 并决定我们最需要的是编写初学者教程时，我们雇佣了一 个中级用户。他刚刚经历了系统的入门，所以能够记住问题 ，但是因为已经通过问题，所以他知道如何描述问题。这样 他就可以编写一些只需由核心开发者进行少量修正的内容， 同时还是会覆盖开发组会认为‘非常明显的’而遗漏的内容。 他的案例甚至更好，随着他的工作，引入了许多用户（学 生）进入系统，所以他组合了许多人的经验，有时候某些事 看起来只是好运当头，恐怕不是在任何情况下都有效。
对于不使用包装主机的站点（见Chapter 3, 技术基础设施的the section called “包装主机”），提供服务器和网络连接—以及更重要的系统管理帮助—会是重要的辅助。即使这是你的组织为项目所做的唯一工作，也是一种获取公共关系回报的适度有效的方法，尽管，它不会带来任何对于项目方向的影响。
你可能会在项目主页发现一个广告条或致谢，用以感谢提供主机的公司。如果你通过设置主机，让项目网址位于公司域名之下，那么单纯通过URL你就获得了额外的联系。这会导致大多数用户认为软件与你的公司有关，即使没有在开发中作出任何贡献。问题是，开发者也会意识到这种关联的趋势，会对项目位于你的领域感到不适，除非你能贡献出除带宽以外的更多资源。毕竟，现在有很多存放主机的地方。社区会最终感觉到这种隐含信用分化与主机带来的便利并不相配，并将项目带到别的地方。所以，如果你希望提供主机，要这样做—不但要计划投入更多，更要细心的考虑声明投入多少。