Es gibt aus technischer Sicht nicht viel darüber zu sagen, wie man die Webseite für das Projekt einrichtet: Einen Webserver 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 über das Projekts zu geben und die anderen Werkzeuge einzubinden (die Versionsverwaltung, Bugtracker, usw.). Wenn Ihnen die Kenntnisse dazu fehlen, selbst 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-Pakete zu nutzen, um sich Zeit und Mühe zu sparen.
Es gibt zwei Hauptvorteile bei der Nutzung von Hosting-Paketen. Der 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 Plattenplatz oder die Bandbreite ausgehen. Der zweite Vorteil ist seine Einfachheit. Sie haben bereits einen Bugtracker, eine Versionsverwaltung, eine Malinglisten-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 feingranulare Kontrolle haben wie bei einer selbstgebauten 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 es die generierten Formate zusätzlich in der Versionsverwaltung abzulegen, damit sie auch auf der Webseite auftauchen.
Es kann auch schwerwiegendere Folgen geben. Sie werden vielleicht nicht so viel Kontrolle über die Präsentation haben, wie Sie es sich wünschen würden. Manche Hosting-Seiten erlauben es Ihnen, Ihre Webseiten anzupassen, der vorgegebene Aufbau hinterlässt aber aber meistens an verschiedenen Stellen erkennbare Spuren. Manche auf SourceForge gehostete Projekte haben ausgefeilte eigene Webseiten, verweisen 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 Bugtracker, zum 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 am Projekt interessiert ist, kaum von 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, so dass 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 herum zu hacken; ähnliche Bedenken lassen sich auf viele andere Seiten übertragen, die Hosting-Pakete anbieten. Das Wesentliche ist hierbei, 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 anders bestimmt, wie sie betrieben wird.
Sie alleine können entscheiden, ob ein Hosting-Paket 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 so, dass Sie die die Adresse des Projekts nicht ändern müssen, sollten Sie sich später umentscheiden.
Die größte und bekannteste Hosting-Site ist SourceForge. Zwei weitere Sites, die gleiche oder ähnliche Dienste anbieten, sind savannah.gnu.org und BerliOS.de. Ein paar Organisationen, wie die Apache Software Foundation und Tigris.org[34], bieten kostenloses Hosting für Open-Source-Projekte an, die gut zu ihrer Mission und den existierenden Projekten 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 Problem, das nicht zwangsläufig auf Seiten beschränkt ist, die Hosting-Pakete benutzen, dort aber am häufigsten anzutreffen sind, ist der Missbrauch der Login-Funktion. Die Funktion selbst ist relativ einfach: Die Seite erlaubt jedem Benutzer sich mit Namen und Passwort zu registrieren. Von da an speichert sie ein Profil für diesen Nutzer und die Administratoren der Projekte können dem Nutzer bestimmte Rechte einräumen, z.B. Schreibzugriff auf das Projektarchiv.
Das kann äußerst nützlich sein und es ist tatsächlich eines der wesentlichen Argument für fertige Hosting-Pakete. Das Problem ist, dass Nutzer sich manchmal für Aufgaben anmelden müssen, die eigentlich auch ohne Anmeldung möglich sein sollten, z.B. um Tickets im Bugtracker zu erstellen. Indem man eine Anmeldung für solche Aufgaben voraussetzt, hebt das Projekt die Hürde zur Mitwirkung an Dingen an, die möglichst schnell und einfach sein sollten. Natürlich möchte man jemanden erreichen können, der Daten in den Bugtracker eingetragen hat, dazu reicht aber ein Feld, in dem er seine ihre E-Mail-Adresse eingeben kann (falls er möchte). Wenn ein neuer Benutzer 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 könnte sich leicht entscheiden den Bug gar nicht 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 ohne Schreibzugriff für unangemeldete Besucher erlauben, sondern auch bestimmte Aktivitäten um Daten einzugeben, insbesondere im Bugtracker sowie, falls vorhanden, auf den Seiten des Wikis.