Es gibt aus technischer Sicht nicht viel darüber zu sagen wie man die Webseite für das Projekt einrichtet: Einen Web-Server aufzubauen und Webseiten zu schreiben sind relativ einfache Aufgaben, und das wichtigste im Bezug auf das Layout und die Anordnung wurde bereits im vorherigen Kapitel abgedeckt. Die Hauptfunktion der Webseite ist es, eine klare und einladende Übersicht des Projekts zu geben und die anderen Werkzeuge einzubinden (die Versionsverwaltung, Bug-Tracker, usw.). Wenn Sie nicht die Kenntnisse haben um selber einen Webserver aufzusetzen, ist es normalerweise kein Umstand jemand zu finden der es kann und bereit ist zu helfen. Trotzdem ziehen es manche vor Hosting Bündel zu benutzen, um sich Zeit und Mühe zu sparen.
Es gibt zwei Hauptvorteile bei der Nutzung von Hosting Bündel. Das Erste ist die Kapazität ihrer Server und ihre Bandbreite: Ihre Server sind schnelle Kisten mit dicken Leitungen. Egal wie erfolgreich Ihr Projekt wird, Ihnen wird niemals der Platz auf der Festplatten oder die Bandbreite ausgehen. Der zweite Vorteil ist seine Einfachheit. Sie haben bereits einen Bug-Tracker, eine Versionsverwaltung, einen E-Mail Verteiler System, ein Archiv System und alles andere was Sie benötigen um eine Seite zu betreiben. Sie haben die Programme konfiguriert, und kümmern sich um die Sicherung aller Daten dieser Programme. Sie müssen nicht viele Entscheidungen treffen. Sie müssen lediglich ein Formular ausfüllen, einen Knopf drücken und plötzlich haben Sie eine Webseite für Ihr Projekt .
Das sind ziemlich schwerwiegende Vorteile. Der Nachteil ist natürlich, dass Sie sich mit deren Auswahl und Konfiguration abfinden müssen, selbst wenn etwas Anderes für Ihr Projekt besser wäre. Meistens lassen sich diese Seiten innerhalb enger Grenzen konfigurieren, aber Sie werden niemals die fein granulierte Kontrolle wie bei einer eigens gebauten Seite mit vollem administrativen Zugriff auf den Server.
Ein perfektes Beispiel hierfür ist die Handhabung generierter Dateien. Bestimmte Webseiten des Projekts können generierte Dateien sein—es gibt z.B. Systeme um die Daten für eine FAQ in ein einfaches Quellformat zu schreiben, von dem aus HTML, PDF und andere Darstellungsformate generiert werden kann. Wie in „Versioniere alles“ früher in diesem Kapitel beschrieben, wollen Sie nicht die generierten Formate in der Versionsverwaltung haben, sondern nur die Quelldatei. Wenn Ihre Webseite aber auf den Server von jemand anderem betrieben wird, kann es unmöglich sein ein eigenes Script einzubinden, um die HTML Version automatisch zu erzeugen, gleich nachdem etwas an der Quelldatei geändert wurde. Die einzige Abhilfe ist die generierten Formate mit in die Versionsverwaltung zu speichern, damit Sie auch auf der Webseite auftauchen.
Es kann auch schwerwiegendere Folgen geben. Sie werden vielleicht nicht so viel Kontrolle über die Präsentation wie Sie es sich wünschen würden. Manche Hosting Seiten erlauben es Ihnen Ihre Webseiten anzupassen, der Vorgegebene Aufbau hinterlässt aber aber meißtens an verschiedenen Stellen erkennbare Spuren. Manche Projekte die sich auf SourceForge haben komplett eigens angepasste Webseiten, weisen Entwickler aber immer noch auf ihre "SourceForge Seite" für weitere Informationen. Die SourceForge Seite ist was die Webseite des Projekts gewesen wäre wenn das Projekt keine angepasste Seite benutzt hätte. Auf der SourceForge Seite sind Verweise auf den Bug-Tracker, zu der CVS Repository, Downloads, usw. Eine SourceForge Seite beinhaltet unglücklicherweise auch eine ganze Menge belangloses Rauschen. Oben ist ein Werbebanner, oftmals eine Animation. Links ist eine vertikale Anordnung verschiedener Verweise die für jemandem der an das Projekt interessiert is von wenig Bedeutung sein dürften. Rechts ist meistens noch mehr Werbung. Lediglich der Mittlere Bereich der Seite ist dem Material des Projekts gewidmet und selbst das ist verwirrend angeordnet, sodass Benutzer unsicher sind, worauf sie als nächstes klicken sollen.
Hinter jedem einzelnen Aspekt, gibt es Zweifelsohne einen guten Grund; gut für SourceForge, wie z.B. die Werbung. Für das einzelne Projekt kann das Ergebnis aber eine nicht ganz optimale Webseite sein. Es ist nicht meine Absicht auf SourceForge rum zu hacken; ähnliche Bedenken lassen sich auf viele andere Seiten anwenden, die Hosting Bündel anbieten. Das wesentliche ist den Kompromiss zu erkennen den man eingeht. Es wird Ihnen die technische Bürde abgenommen, eine eigene Webseite zu betreiben, dafür müssen Sie akzeptieren das jemand anderes bestimmt wie es betrieben wird.
Sie alleine können entscheiden ob ein Hosting Bündel für Ihr Projekt das Beste ist. Wenn Sie eine solche Seite wählen, halten Sie sich die Möglichkeit offen, im nachhinein auf Ihre eigenen Server zu wechseln, indem Sie einen gesonderten Domain-Namen als Adresse verwenden. Sie können diese URL für komplizierte Funktionen auf die Hosting Seite leiten. Ordnen Sie aber unbedingt alles alles so, dass Sie die die Adresse des Projekts nicht ändern müssen, sollten Sie sich später umentscheiden.
Die größte und bekannteste Hosting Seite ist SourceForge. Zwei weitere Seiten die gleiche oder ähnliche Dienste anbieten sind savannah.gnu.org und BerliOS.de. Ein paar Organisationen, wie die Apache Software Foundation und Tigris.org[35], bieten kostenloses Hosting für Open Source Projekte an, die gut zu ihrer Mission und die existierende Projekte der Gemeinschaft passen.
Als Teil der Nachforschungen für seine Diplomarbeit Aufbau eines Modells zur Evaluierung von Freie/Open Source Projekt Hosting (FOSPHost) Seiten hat Haggen So eine gründliche Evaluierung verschiedener Hosting Seiten gemacht. Die Ergebnisse finden Sie bei http://www.ibiblio.org/fosphost/, die Vergleichstabelle bei http://www.ibiblio.org/fosphost/exhost.htm ist besonders anschaulich und lesenswert.
Ein nicht zwangsläufig auf Seiten die Hosting-Bündel benutzen beschränktes Problem, dort aber am häufigsten anzutreffen, ist der Missbrauch der Login Funktion. Die Funktion selbst ist relativ Einfach: Die Seite erlabt jedem Benutzer sich mit Name und Passwort zu registrieren. Von da an speichert es ein Profil für diesen Nutzer und die Administratoren der Projekte können dem Nutzer bestimmte Rechte einräumen, z.B. Schreibzugriff auf die Repository.
Das kann äußerst nützlich sein und es ist tatsächlich eines der wesentlichen Argument für gebündeltes Hosting. Das Problem ist, dass Nutzer sich manchmal für Aufgaben anmelden müssen, die eigentlich auch ohne möglich sein sollten, insbesondere um Tickets im Bug-Tracker zu erstellen. Indem man eine Anmeldung für solche Aufgaben voraussetzt, hebt das Projekt die Grenze für die Teilnahme für Aufgaben an, die möglichst schnell und einfach sein sollten. Natürlich möchte man jemand erreichen können, der Daten in den Bug-Tracker eingetragen hat, dazu reicht aber ein Feld, indem sie ihre E-Mail Adresse eingeben kann (wenn sie es möchte). Wenn ein neuer Nutzer einen Bug findet und ihn melden möchte, wird er durch die Anforderung verärgert sein, ein Konto erstellen zu müssen, nur um einen Eintrag in den Tracker zu machen. Er wird sich vielleicht einfach entscheiden den Bug garnicht zu melden.
Die Vorteile einer Nutzerverwaltung wiegen im Allgemeinen schwerer als die Nachteile. Wenn Sie es sich aussuchen können, welche Aufgaben anonym gemacht werden können, sollten Sie aber nicht nur alle Abläufe die keinen Schreibzugriff erfordern, für nicht angemeldete Besucher erlauben, sonder auch manche Abläufe um Daten einzugeben, insbesondere im Bug-Tracker sowie, falls vorhanden, auf den Seiten der Wiki.