3. 技术基础设施

# Chapter 3. 技术基础设施 自由软件项目依赖于选择性捕获和信息集成的技术。对这些技术的使用越是熟练，并说服别人去使用这些技术，你的项目就越成功。随着项目的成长，这一点愈发正确。好的信息管理系统应该能够防止开源项目在布鲁克法则的重压下崩塌[[12](#)]，也就是说向一个已经延期的项目增加人力，只能使项目延期更多。佛雷德·布鲁克观察到，项目的复杂性同参与人员数量的*平方*成正比。当项目中只有少数几个人时，大家可以容易的互相交谈，但当有上百人参与时，不可能让每个人都能知道别人正在做什么。如果说优秀的自由软件项目的管理是让每个人都感觉是在同一个屋子里共同工作，很明显问题在于：当在一间拥挤的房间内，在同一时刻每个人都想发出声音，会发生什么？ 这不是一个新问题。在现实中的拥挤房间中，解决方案是*会议程序*：我们需要正式的指导规则：包括如何在一个大型团队中进行即时的讨论，如何保护重要的异议不会在一片“我也是”的回复中淹没，如何形成小组委员会，如何识别出何时作出决定等等。会议程序的一个重要组成部分是指明团队如何同它的信息管理系统互动。有些评论“为了被记录”而存在的，有些则不是。记录本身经常是被直接处理的，不能根据字面意义去理解，而是代表了团队已经确立达成*共识*。记录并非一成不变，为不同的目的会有不同的形式。它可以包括个人会议记录、每次会议的完整记录、摘要、议程及其注解、委员会报告，来自未出席通信者的报告，活动项目列表等等。 因为互联网并不是一个真实的房间，所以我们也无须担心去复印诸如让部分人在别人讲话时保持安静之类的议会程序。但当它和信息管理技术接合时，一个运作良好的开源项目就会是打了兴奋剂的会议程序。由于开源项目中的交流都是通过书写方式完成的，由此发展出了复杂的系统：为了恰当导向和标记数据；为了避免会造成误解的重复；为了储存和检索数据；为了纠正错误和废弃的信息；以及为了在发现不相关信息的新关系时进行关联。开源项目中的活跃参与者已经将掌握了其中的很多技术，并且经常为了确保信息被正确的导向而进行复杂的手工任务。但是所有的努力都是依赖于复杂的软件支持。交流媒体应该尽可能地依靠自身完成发送、标签和记录工作，应该确保人尽可能方便地得到这些信息。当然在实际中，在整个过程中的很多方面还是需要人的干预，并且重要之处在于软件使得这种干预也是方便的。但总得来说，如果人能确保首次进入系统时信息的导向和标签都是正确的，软件应该被配置成可以充分利用这些元数据。 此章中的建议都是非常务实的，都是基于明确的软件和使用模式的经验。但这里不仅仅是教授实用的技术。而是通过许多小范例来演示一种总体态度，这种态度可以最大程度的促进你项目中的好的信息管理。这种态度包含了技术技巧同人力技巧的结合。并且技术技巧是关键，因为当新的需求出现时，信息管理软件总需要配置，以及一定量的持续维护和调整（例如，关于如何处理项目成长的讨论参加本章后面的[the section called “Bug跟踪的预过滤”](# "Bug跟踪的预过滤")）。人力技巧也是不可或缺的，因为人类社区也需要维护：如何利用这些工具的优势有时候不是立刻就很明显，在有些项目案例中甚至有冲突的习惯（例如，参见[the section called “邮件列表”](# "邮件列表")中的关于在外发的邮件列表通告中设置`Reply-to`头的讨论）。应该鼓励项目相关的每一个人在正确的时间、正确的地点尽自己的职责来保持项目信息组织的良好。贡献者参与的程度越深，就越能预期她能学习更复杂和专业的技术。 信息管理没有现成的解决方案。有着众多的不确定因素。你可能好不容易才把所有事情都按照自己的意愿完成配置，并且社区的大多数人参与进来，但随着项目的成长让某些实践不能扩展。或者本来你的项目正在稳步发展，技术基础架构也能使开发者和用户的社区关系融洽，但突然某些人出现，发明了一个全新的信息管理服务，很快新来的会质问为何你的项目不用它—例如很多在维基（参见[http://en.wikipedia.org/wiki/Wiki](http://en.wikipedia.org/wiki/Wiki)）发明之前建立的自由软件项目就正面临这一问题。很多问题需要决断，比如权衡生产信息的方便性还是消费信息的方便性，或者权衡花在配置信息管理软件上的时间与其为项目带来的益处。 小心过度自动化的诱惑，请自动化那些真正需要人们关注的东西。技术基础架构是重要的，但推动一个自由软件项目运转的是参与的人的意愿—用智慧的方式表达的意愿—通过人的参与。技术基础架构只是为人门达到这个目标提供便利。