网站

# 网站 从技术角度上看，对于设置项目网站没有可以多说的：设置网站服务器并编写网页都是相当简单的任务，大多数需要说的重要事情如布局和安排已经在前面的章节提过。网站的主要功能是为项目提供一个清新和友好的概况，并组合其他工具（版本控制系统、bug跟踪系统等等）。如果你没有设置网站的技能，通常不难能找到有能力的人乐意帮助你。虽然如此，为了节省时间和工作量，人们通常会选择一个包装主机站点。 ### 包装主机 使用包装站点有两个主要的好处。首先是服务器容量和带宽：他们的服务器通常位于非常宽的管道上。无论你的项目多么成功，你都不会用完你的磁盘并消耗完网络带宽。第二个好处是简单。他们已经选择了bug跟踪、版本控制系统、邮件列表管理器、归档程序以及其他运行一个站点所需的所有东西。他们已经配置好了工具，并且会小心的备份其保管的所有数据。你不需要作出任何选择。你所需要的只是填写表单，点击按钮，你就立刻得到了一个项目网站。 这些是很明显的益处。坏处当然也有，你必须接受*他们的*选择和配置，即使有时候不同的方式更适合你的项目。通常情况下，包装主站可以通过特定较少的参数进行调整，但是你永远无法得到细致的控制，就像你自己搭建站点并对服务器有完全管理权限时的那样。 这里的一个完美例子是对生成文件的处理。特定项目网页可以是生成的文件—例如，有系统可以保持FAQ数据为易于编辑的原格式，而不是HTML、PDF、和其他可以生成的展示格式。本章后的[the section called “版本化所有的东西”](# "版本化所有的东西")会有解释，你不会希望版本化这些生成格式，而只要保存原文件。但是当你的网站存放在其他人的服务器上，就不能设置一个自定义的钩子，当原格式文件变更时，来生成在线的HTML版本的FAQ。唯一的解决办法是也版本化生成的格式，这样，它们才可以在网站上展示。 也可能有更大的后果。你可能无法控制你所展示的内容。一些包装主站允许你自定义网页，但是站点的缺省布局通常是通过许多蹩脚的方法完成。例如，一些SourceForge上的项目拥有完全的自定义主页，但仍然将开发者指向他们的“SourceForge页面”来获得进一步信息。SourceForge页面是项目的主页，使得项目不能使用自定义主页。SourceForge页面包含到bug跟踪、CVS版本库、下载等链接。不幸的是，SourceForge页面也包含了太多外来的噪音。顶上有一个广告条，通常是一个图像动画。左面垂直布局的是项目中的某人感兴趣的一些相关链接。右侧可能是另一个广告。只有中央才是项目特定的材料，甚至让访问者无法确定下一步应该点击什么。 SourceForge设计的每个方面后面，无疑有一个好的原因—从SourceForge的视点是好的，例如广告。但是从每个项目的视点，结果可能不是一个理想的网页。我不是要招惹SourceForge；类似的关注会在许多包装主站出现。关键是代价。你省去了运行项目站点的负担，但是要接受其他人运行它的方式。 你唯一可以决定的是哪个包装主站适合你的项目。如果你选择了一个包装站点，可以保留将站点转移到你自己服务器的选项，通过使用自定义域名作为项目的“主地址”。你可以将URL转向到包装主站，或者你在公共URL上有完全自定义的主页，只在复杂功能时才将用户转移到包装主站。只要确保这样安排，如果之后你希望使用不同的主机方案，项目地址不需要改变。 ### 选择一个包装站点 最大最著名的主机站点是[SourceForge](http://www.sourceforge.net/)。[savannah.gnu.org](http://savannah.gnu.org/)和[BerliOS.de](http://www.berlios.de/)这两个站点提供了相同或类似的服务。一些组织，例如[Apache Software基金会](http://www.apache.org/)和[Tigris.org](http://www.tigris.org/)。[[21](#)]也会为开源项目提供免费主机，但要符合他们的目标和他们社区已有的项目。 Haggen So对于各式包装站点有一个完全的评估，作为他的博士论文研究的一部分，*Construction of an Evaluation Model for Free/Open SourceProject Hosting (FOSPHost) sites*。结果在[http://www.ibiblio.org/fosphost/](http://www.ibiblio.org/fosphost/)，还可以看非常易读的比较图[http://www.ibiblio.org/fosphost/exhost.htm](http://www.ibiblio.org/fosphost/exhost.htm)。 ### 匿名和参与 一个不仅是包装主战，而且许多其他地方也能看到的问题是对于用户登录功能的滥用。这个功能本身很简单：站点允许每个访问者自己通过用户名和密码注册。此后他就保存了一份用户信息，项目管理员可以为用户赋予特定的权限，例如，提交版本库的权利。 这非常有用，实际上这也是包装主站的一个好处。问题是有时候有一些附加给注册用户的任务本应该由未注册访问者执行，特别是如在bug跟踪系统发起问题和对已有问题进行回复。如果对此类活动要求输入登陆用户名，项目就为这类快速方便的任务设置了障碍。当然，人们希望可以联系到输入数据的人，但只要保留一个输入邮件地址（如果她愿意）的字段就够了。如果一个新的用户发现一个bug，并希望报告它，她会被在输入bug之前被要求填写帐户信息惹恼。她可能会放弃发起这个bug。 用户管理的好处被过高估计了。但是如果你可以选择哪些动作可以匿名完成，请确保不仅只有*所有的*只读动作对于未登陆用户是允许的，也包括一些数据条目动作，特别是在bug跟踪系统，可能的话还有你的wiki页。 [[21](#)] 免责生命：我由[CollabNet](http://www.collab.net/)雇佣，它是Tigris.org的赞助商，我经常会用Tigris。