Deine Idee identifizieren und artikulieren

Eric S. Raymond schreibt darüber, wie freie Software-Projekte beginnen in seinem Essay, "die Kathedrale und den Basar," der als Pflichtlektüre für jeden freien Software-Entwickler dient. Er ist online verfügbar.

In "Die Kathedrale und der Basar" erklärt Raymond uns daß „jede gute Softwarelösung beginnt, indem sie eine Stelle kratzt, die den Entwickler juckt." Raymonds jetzt weithin akzeptierte Hypothese ist, daß neue freie Software-Programme in erster Linie geschrieben werden, um ein spezifisches Problem zu lösen, dem der Entwickler gegenübersteht.

Wenn du eine Idee für ein Programm hast, ist die Chance hoch, daß es auf ein spezifisches Problem oder "Jucken" zielt, das du gerne gekratzt sehen würdest. Diese Idee ist das Projekt. Artikuliere sie offen. Formuliere sie aus. Beschreibe das Problem, das du in Angriff nimmst im Detail. Der Erfolg deines Projektes im Anpacken eines bestimmten Problems ist an deine Fähigkeit gekoppelt, dieses Problem früh schon klar zu identifizieren. Finde genau heraus, was dein Projekt nach deinem Willen tun soll.

Monty Manley artikuliert den Wert dieses Ausgangsschrittes in einem Essay, "Managing Projects the Open Source Way." Wie der folgende Abschnitt zeigen wird, gibt es eine Menge Arbeit, die erledigt werden muß, bevor Software überhaupt bereit ist kodiert zu werden. Manley sagt, "Ein OSS-Projekt richtig zu beginnen heißt, daß ein Entwickler in erster Linie vermeiden muß, zu früh Code zu schreiben!"

Deine Idee auswerten

Wenn du deine Idee auswertest, mußt du dir zuerst einige Fragen stellen. Dieses sollte geschehen, bevor du in diesem HOWTO einen Schritt weiter machst. Frage dich: Ist das freie Software-Entwicklung Modell wirklich das richtige für dein Projekt?

Offensichtlich bist du, da das Programm dein Jucken kratzt, definitiv daran interessiert, es in Code implementiert zu sehen. Weil aber ein Hacker, der aleine programmiert, noch nicht als eine Unternehmung freier Software-Entwicklung gilt, mußt du dir eine zweite Frage stellen: Ist sonst jemand interessiert?

Manchmal ist die Antwort ein einfaches "Nein." Wenn du einen Satz Skripte schreiben möchtest, um deine MP3-Sammlung auf deiner Maschine zu sortieren, ist möglicherweise das Modell der freien Software-Entwicklung nicht die beste Wahl.

Wenn du jedoch einen Satz Skripte schreiben möchtest, um jedermanns MP3s zu sortieren, könnte ein freies Software-Projekt eine nützliche Lücke füllen.

Glücklicherweise ist das Internet ein grosser und vielseitiger Ort, daß die Chance besteht, daß dort draußen irgendwo irgendjemand ist, der deine Interessen teilt und der das selbe "Jucken" verspürt. Es ist die Tatsache, daß es also viele Leute mit so vielen ähnliche Bedürfnissen und Wünschen gibt, die die dritte Hauptfrage aufwirft: Hatte jemand bereits deine Idee oder ein recht ähnliche?

Ähnliche Projekte finden

Es gibt Orte im Netz, die du aufsuchen kannst, um zu versuchen, eine Antwort auf die obige Frage zu finden. Wenn du Erfahrung mit der free software community hast, bist du vermutlich bereits mit vielen dieser Seiten vertraut. Alle im folgenden aufgeführten Quellen bieten Suchfunktionen in ihren Datenbanken an:

Sich entscheiden, weiterzumachen

Sobald man erfolgreich das Gelände abgesteckt und eine Vorstellung davon hat, welche Arten ähnlicher freier Software-Projekte existieren, muß jeder Entwickler entscheiden, ob er mit seinem eigenen Projekt fortfährt. Es ist selten, daß ein neues Projekt versucht, ein Ziel zu erreichen, das keinem Ziel eines anderen Projektes ähnlich ist oder zu ihm einen Bezug hat. Jeder, der ein neues Projekt beginnt, muß sich fragen: "Wird das neue Projekt Arbeit duplizieren, die durch ein anderes Projekt erledigt wird? Wird das neue Projekt mit einem vorhandenen Projekt um Entwickler konkurrieren? Können die Ziele des neuen Projektes erreicht werden, indem man einem vorhandenen Projekt Funktionalität hinzufügt?"

Wenn die Antwort auf irgendeine dieser Fragen "ja" ist, dann versuche, mit dem Entwickler des/der entsprechenden existierenden Projekte(s) in Verbindung zu treten und zu eruieren, ob er oder sie bereit sein könnte, mit dir zusammenzuarbeiten.

Für viele Entwickler mag dies der allerschwierigste Aspekt des freien Software-Projektmanagements sein, aber er ist wesentlich. Es ist einfach, durch eine Idee angestachelt und vom Moment und der Aufregung eines neuen Projektes ergriffen zu werden. Es ist häufig extrem schwierig, aber es ist wichtig, daß jeder freie Software-Entwickler sich daran erinnert, daß man die Interessen der freien Software-Community und die Verwirklichung der eigenen Projektziele auf schnellstem Wege häufig dadurch erreicht, daß man keine Neuentwicklung anstrebt.

Wählen einer Lizenz

Jede Diskussion über Lizenzen führt garantiert zumindest zu einem kleinen "Flame War," da die Leute starke emotionale Neigungen zeigen, daß einige freie Software-Lizenzen besser als andere sind. Diese Diskussion bringt auch die Frage nach "Open Source-Software" wieder auf, und die Debatte über die Bezeichnungen "Open Source-Software" und "freie Software." Weil ich dieses HOWTO "Projektmanagement für freie Software" betitelt habe und nicht "Projektmanagement für Open Source-Software," ist meine eigenes Zugehörigkeitsgefühl wohl klar.

Im Versuch, mit Diplomatie einen Kompromiß zu erreichen, ohne meine eigene Philosophie zu opfern, empfehle ich, irgendeine Lizenz auszuwählen, die zu sich an die Debian free software-Richtlinien (engl. Debian Free Software Guidelines, DFSG) hält. Diese Richtlinien, ursprünglich zusammengestellt durch das Debian-Projekt unter Bruce Perens, bilden die erste Version einer Open Source-Definition. In den DFSG angegebene Beispiele freier Lizenzen sind die GPL, die BSD und die Artistic License. Wie ESR (Eric Raymond) in seinem seinem HOWTO [ESRHOWTO] erwähnt, solltest du nicht deine eigene Lizenz schreiben wenn irgend möglich. Die drei erwähnten Lizenzen haben alle eine lange Auslegungstradition. Sie sind auch definitiv freie Software (und können daher als Teil von Debian verteilt werden, und auch an anderen Orten, die den Transfer freier Software ermöglichen).

In Übereinstimmung mit der Definition der freien Software, wie sie von Richard Stallman in "The Free Software Definition" angeboten wird, unterstützt jede dieser Lizenzen "die Freiheit der Benutzer, die Software laufen zu lassen, zu kopieren, zu verteilen, zu erforschen, zu ändern und zu verbessern." Es gibt viele andere Lizenzen, die auch DFSG-konform sind, bei einer besser bekannteren Lizenz zu bleiben bietet jedoch den Vorteil sofortigen Wiedererkennens und sofortigen Verstehens. Viele Leute schreiben drei, oder vier Sätze in einer COPYING-Datei und nehmen an, daß sie damit eine freie Software-Lizenz geschrieben haben -- wie meine lange Erfahrung mit der debian-legal Mailingliste zeigt, ist dieses sehr häufig nicht der Fall.

Wenn ich eine eingehendere Analyse versuche, stimme ich Karl Fogels Beschreibung zu, daß alle Lizenzen in zwei Gruppen fallen: Die, die GPL sind und die, die nicht GPL sind.

Persönlich lizensiere ich all meine Software unter der GPL. Geschaffen und geschützt durch die Free Software Foundation und das GNU-Projekt, ist die GPL die Lizenz für den Linux-Kernel, GNOME, Emacs und die überwiegende Mehrheit an GNU/Linux-Software. Es ist die offensichtliche Wahl, aber ich glaube auch, daß sie eine gute Wahl ist. Jeder BSD-Fanatiker wird dich drängen, daß du dich erinnern sollst, daß die GPL einen "viralen Aspekt" aufweist, der die Mischung von GPL-Code mit nicht-GPL-Code verhindert. Für viele Leute (mich eingeschlossen) ist dies ein Vorteil, aber für einige ist es ein großer Nachteil.

Viele Leute schreiben drei, oder vier Sätze in einer COPYING-Datei und nehmen an, daß sie damit eine freie Software-Lizenz geschrieben haben -- wie meine lange Erfahrung mit der debian-legal Mailingliste zeigt, ist dieses sehr häufig nicht der Fall. Es kann möglicherweise weder dich noch deine Software schützen, und es kann sehr viele Schwierigkeiten verursachen für Leute, die deine Software benutzen möchten, den subtilen rechtlichen Aspekten von Lizenzen aber eine Menge Aufmerksamkeit widmen. Wenn du unbedingt eine handgestrickte Lizenz haben willst, dann zeige sie erstmal entweder den Leuten bei OSI oder denen auf der debial-legal-Mailingliste, um dich zu schützen vor unvorhergesehenen Nebenwirkungen deiner Lizenz.

Die drei wichtigsten Lizenzen können an folgenden Orten gefunden werden:

• Die GNU General Public License http://www.gnu.org/copyleft/gpl.html
• Die BSD License http://www.debian.org/misc/bsd.license
• Die Artistic License http://language.perl.com/misc/Artistic.html

Lies dir auf jeden Fall die Lizenz durch, bevor du eine Software unter ihr veröffentlichst. Als Hauptentwickler kannst du dur keine Überraschungen mit Lizenzen leisten.

Wie die Lizensierung funktioniert

Der Text der GPL bietet eine gute Beschreibung des Prozesses an, mit dem man ein Stück Software einer Lizenz unterwirft. Meine schnelle Checkliste beinhaltet folgende Schritte:

• Deklariere dich oder die FSF als Copyrightträger für das Produkt. In einigen seltenen Fällen magst du vielleicht eher eine fördernde Organisation (wenn sie groß und genug leistungsfähig ist) zum Copyrightträger machen wollen. Dies tust du einfach dadurch, daß du ihren Namen in den freien Raum einsetzt, wenn du die Copyrighterklärung unten änderst. Entgegen der landläufigen Meinung brauchst du das Copyright nicht bei irgendeiner Organisation registrieren lassen. Die Erklärung alleine ist genug, um deine Arbeit urheberrechtlich zu sichern. (Anm. des Übersetzers: Kann sich mal jemand juristisch versiertes dazu äußern, wie da die deutsche Rechstlage ist? Ich kann dazu nichts sagen, außer daß es wohl Gerichtsurteile gibt, die z.B. die GPL anerkennen)

• Wenn irgend möglich, füge eine vollständige Kopie der Lizenz dem Quellcode- und Binärpaket an, als separate Datei.

• Füge am Anfang jeder Quellcodedatei deines Programmes eine Copyrightnotiz an mit Informationen darüber, wo die vollständige Lizenz gefunden werden kann. Die GPL empfiehlt, daß jede Datei so anfängt:

  Eine Zeile, um den Namen des Programms und eine Vorstellung davon, was es tut zu kommunizieren.

  Copyright (C) yyyy name of author

  This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

  This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

  You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Die GPL fährt fort und empfiehlt, Informationen hinzuzufügen, auf welche Weise man dich (den Autor) per Email oder Schneckenpost kontaktiert.

Weiterhin schlägt die GPL vor, daß, wenn dein Programm in einen interaktiv Modus läuft, du das Programm so schreiben solltest, daß es bei jedem Aufruf im interaktiven Modus eine Meldung ausgibt, der einen Hinweis enthält wie den folgenden, der zur vollständigen Lizenz führt:

Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type "show w".

This is free software, and you are welcome to redistribute it under certain conditions; type "show c" for details.

Schließlich könnte es nützlich sein, einen "Copyrightverzicht" von einem Arbeitgeber oder einer Schule einzuschließen, wenn du als Programmierer arbeitest oder wenn es danach aussieht, daß dein Arbeitgeber/ deine Schule später einen Grund für Besitzansprüche finden könnten. Dieser ist nicht oft notwendig, aber es gibt viel freie Softwareentwickler, die Ärger bekommen haben und sich wünschen, sie hätten nach einem gefragt.

Abschließende Warnung zu Lizenzen

Bitte bitte bitte, stell' deine Software

unter irgendeine Lizenz. Es mag möglicherweise nicht wichtig erscheinen, und für dich auch nicht wichtig sein, aber Lizenzen sind wichtig. Um in die Debian GNU/Linux GNU/Linux distribution eingebracht werden zu können, muß ein Stück Software eine Lizenz haben, die zu den "Freie Software"-Richtlinien von Debian paßt.

Wenn deine Software keine Lizenz hat, kann sie nicht verfügbar gemacht werden als Paket in Debian, bis du sie erneut freigibst unter einer freien Lizenz.

Bitte erspare dir und anderen Ärger, indem du gleich die erste Version deiner Software unter einer freien Lizenz publizierst.

Versionsnumerierung des Linux-Kernels

(Anm. des Übers.: Inzwischen sind die Linux-Kernelentwickler von dem unten skizzierten Versionierungssystem abgekommen. Eine gute Einführung in das aktuelle und die vorherigen Systeme findet sich auf Wikipedia [http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering]).

Der Linux-Kernel benutzt ein Versionierungssystem, in dem jede ungerade kleine ("minor") Versionsnummer auf eine Entwickler-/Testversion verweist und jede gerade kleine Versionsnummer auf eine stabile Version. Denke eine Sekunde darüber nach. Unter diesem System waren 2.1 und 2.3 Entwicklungs-/ Test-Kernels, und werden es immer sein, während die Kernels 2.0, 2.2. und 2.4 Produktionsversionen sind, mit einem höheren Grad an Stabilität und Testaufwand.

Ob du planst, ein geteiltes Entwicklungsmodell zu verwenden (wie im Abschnitt "Stabile Zweige und Entwicklungszweige " beschrieben) oder nur eine Version auf einmal freigibst, meine Erfahrung mit einigen freien Software-Projekten und mit das Debian Projekt hat mich gelehrt, daß es das Versionierungssystem von Linux durch wert ist, in Erwägung gezogen zu werden. In Debian sind alle kleinen ("minor") Versionen stabile Versionen (2.0, 2.1, usw.). Jedoch nehmen viele Leute an, daß 2.1 eine instabile- oder Entwicklungsversion ist und nutzen weiterhin eine ältere Version, bis sie der Frust packt über den Mangel an Fortschritt in der Entwicklung, sodaß sie sich beschweren und herausfinden, wie das System funktioniert. Wenn du nie eine ungerade Version, sondern nur gerade herausbringst, schadet das niemandem, aber weniger Leute werden verwirrt. Es ist eine Idee, die man in Erwägung ziehen sollte.

Wine-Versionsnumerierung:

Wegen der ungewöhnlichen Natur der Entwicklung im wine-Projekt, wo der Nicht-Emulator ständig verbessert wird, aber nicht irgendein sofort erreichbares Ziel hin, wird wine alle drei Wochen freigegeben. wine benennt dabei alle seine Versionen nach dem Schema "Jahr Monat Tag" wobei jede Version das Format "wine-XXXXXXXX" hat, sodaß z.B. die Version vom 4. Januar 2000 "wine-20000104" heißt. Für bestimmte Projekte kann so ein "Jahr Monat Tag"- Format sehr sinnvoll sein.

Mozilla-Milestones:

Wenn man Netscape 6 und seine Verkaufsversionen betrachtet, ist die Entwicklungsstruktur des Mozilla-Projekts eines der komplexesten Modelle, das man bei freier Software findet. Die Versionsnumerierung des Projektes reflektiert die einzigartige Situation, in der es entwickelt wird.

Mozillas Versionsnumerierung wurde aus historischen Gründen auf Milestones (Meilensteinen) aufgebaut. Vom Anfang des Mozilla-Projektes an wurden die Ziele des Projektes mit Reihenfolge und zu erreichendem Grad entworfen, in einer Reihe von road maps. Wichtige Punkte und Erfolge entlang dieser road maps wurden als Meilensteine gekennzeichnet. Deshalb wurde, obwohl man von Mozilla jede Nacht einen "nightly build" baute und zur Verfügung stellte, an einem bestimmten Tag, an dem die Ziele eines Meilensteines der road map erreicht waren, dieser Build als "milestone release" gekennzeichnet.

Während ich diese Methode bisher in keinem anderen Projekt in Verwendung gesehen habe, mag ich die Idee und denke, daß sie Wert haben könnte in jedem Test- oder Entwicklungszweig einer großen Anwendung die sich intensiv in Entwicklung befindet.

Man pages

Deine Benutzer werden "man deinprojekt" eintippen wollen und eine schön formatierte man page bekommen, die die elementare Nutzung der Applikation hervorhebt. Stelle sicher, daß du das eingeplant hast, bevor du dein Programm veröffentlicht.

Man pages sind nicht schwer zu schreiben. Es gibt hervorragende Dokumentation über den Erstellungs- prozess für man pages durch das "Linux Man-Page-HOWTO" von Jens Schweikhardt, daß über das Linux Documentation project (LDP) bzw. auf Schweikhardts Webseite verfügbar ist.

Es ist auch möglich, man pages mit DocBook SGML zu schreiben. Weil man pages so einfach sind und die DocBook-Methode relativ neu ist, habe ich ihr noch nicht nachgehen können, würde mich aber freuen über Hilfe von jemandem, der mehr Informationen darüber zur Verfügung stellen kann, wie das genau funktioniert.

Via Kommandozeile verfügbare Dokumentation

Die meisten Benutzer erwarten ein Minimum an über die Kommandozeile verfügbarer Dokumentation. Für wenige Programme sollte diese Art der Dokumentation mehr als eine Bildschirmseite (24 oder 25 Zeilen) sein, aber sie sollte dir prinzipielle Verwendung beinhalten, eine kurze Beschreibung (ein oder zwei Sätze) des Programms, eine Liste der Befehle mit Erklärung, sowie alle wichtigen Optionen (auch mit Erklärungen), mit einem Verweis auf detailiertere Dokumentation für diejenigen, die sie benötigen. Die über Kommandozeile verfügbare Dokumentation für Debians apt-get dient als ausgezeichnetes Beispiel und ein nützliches Modell:

apt 0.3.19 for i386 compiled on May 12 2000 21:17:27

Usage: apt-get [options] command

apt-get [options] install pkg1 [pkg2 ...]

apt-get is a simple command line interface for downloading and installing packages. The most frequently used commands are update and install.

Commands:

update - Retrieve new lists of packages upgrade - Perform an upgrade install - Install new packages (pkg is

libc6 not libc6.deb)

remove - Remove packages source - Download source archives dist-upgrade - Distribution upgrade, see

apt-get(8)

dselect-upgrade - Follow dselect selections clean - Erase downloaded archive files autoclean - Erase old downloaded archive

files

check - Verify that there are no broken dependencies

Options:

-h This help text. -q Loggable output - no progress indicator -qq No output except for errors -d Download only - do NOT install or unpack archives -s No-act. Perform ordering simulation -y Assume Yes to all queries and do not prompt -f Attempt to continue if the integrity check fails -m Attempt to continue if archives are unlocatable -u Show a list of upgraded packages as well -b Build the source package after fetching it -c=? Read this configuration file -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp

See the apt-get(8), sources.list(5) and apt.conf(5) manual pages for more information and options.

Es ist eine GNU-Konvention geworden, diese Art Information über die "-h"- und "--help"-Optionen zugänglich zu machen . Die meisten GNU/Linux-Benutzer erwarten daß sie auf diese Weise grundlegende Dokumentation bekommen, wenn du also beschließt, andere Methoden zu verwenden, solltest du dich auf Flames und radioaktive Gegenschläge vorbereiten, die daraus resultieren können.

Dateien, die Benutzer erwarten

Zusätzlich zu den man pages und der Hilfe über die Kommandozeile gibt es bestimmte Dateien, wo Leute nach Dokumentation suchen, besonders in jedem Softwarepaket, das Quellecode enthält. In einer Distribution mit Quellcode können die meisten diesee Dateien im Wurzelverzeichnis (".") oder einem Unterverzeichnis namens "doc" oder "documentation" gespeichert werden.

Zu den dabei üblichen Dateien gehören:

README oder Readme

Ein Dokument, das alle grundlegende Informationen zu Installation, Kompilierung und sogar eine grundlegende Gebrauchanweisung enthält, die das absolute Minimum an Informationen zur Verfügung stellt, die erforderlich sind, um das Programm zum Laufen zu bringen. Ein README ist keine Gelegenheit, um Romane zu schreiben, sondern sollte kurz und wirkungsvoll sein. Ein ideales README ist mindestens 30 Zeilen lang und nicht mehr als 250.

INSTALL oder Install

Die INSTALL-Datei sollte viel kürzer als das README sein und sollte schnell und präzise beschreiben, wie man das Programm baut und installiert. Normalerweise weist eine INSTALL-Datei den Benutzer einfach an, "./configure; make; make install" auszuführen und tangiert ungewöhnliche Optionen oder Schritte, die notwendig sein könnten. Für die meisten relativ standardkonformen Installations- schritte und für die meisten Programme sollten INSTALL-Dateien so kurz wie möglich sein und selten über 100 Zeilen hinausgehen.

CHANGELOG, Changelog, ChangeLog oder changelog

Ein CHANGELOG ist eine einfache Datei, die jedes gut-gemanagte freie Software-Projekt dabeihaben sollte. Ein CHANGELOG ist einfach die Datei, die, wie ihr Name andeutet, die Änderungen loggt und dokumentiert, die du an deinem Programm machst. Der einfachste Weg, ein CHANGELOG zu pflegen ist, einfach eine Datei beim Quellcode deines Programmes zu haben und mit jeder veröffentlichten Version immer einen Abschnitt an den Anfang des CHANGELOG hinzuzufügen, der beschreibt, was im Programm geändert, korrigiert oder hinzugefügt worden ist. Es ist eine gute Idee, das CHANGELOG auch auf der Webseite verfügbar zu machen, weil es den Leuten helfen kann zu entscheiden, ob sie auf eine neuere Version wechseln wollen oder lieber auf eine weitreichenderer Verbesserung warten.

NEWS

Eine NEWS-Datei und ein ChangeLog sind ähnlich. Anders als ein CHANGELOG wird eine NEWS-Datei gewöhnlich nicht mit neuen Versionen aktualisiert. Wann immer neue Features hinzugefügt werden, wird der verantwortliche Entwicklers eine Anmerkung in NEWS machen. NEWS-Dateien sollten nicht vor einer Freigabe geändert werden (sie sollten die ganze Zeit aktuell gehalten), aber es ist normalerweise eine gute Idee, sie zuerst zu überprüfen, weil Entwickler häufig einfach vergessen, sie so aktuell zu halten, wie sie sollten.

FAQ

Für diejenigen, die es noch nicht wissen, FAQ steht für Frequently Asked Questions (häufig gestellte Fragen) und ein FAQ ist eine Ansammlung von genau diesen. FAQs sind nicht schwierig zu schreiben. Stelle einfach eine Regel auf, daß, wenn dir auf einer Mailingliste eine Frage mindestens zwei Mal gestellt wird, du dann die Frage (samt Antwort) deinem FAQ hinzufügst. FAQs sind optionaler als die oben aufgeführten Dateien, aber sie können dir Zeit sparen, die Benutzbarkeit steigern, und Kopfschmerzen bei allen Beteiligten reduzieren.

Webseite

Es ist nur indirekt ein Problem der Dokumentation, aber eine gute Webseite wird schnell ein wesentlicher Teil eines freien Software-Projektes. Deine Webseite sollte Zugang zu deiner Dokumentation bereitstellen (in HTML, wenn möglich). Es sollte auch einen Abschnitt für Nachrichten und Ereignisse in Bezug auf dein Programm einschließen sowie einen Abschnitt mit Details darüber, wie man sich am Entwicklungs- oder Testprozess beteiligen kann, und man sollte dazu eine freundliche Einladung aussprechen. Es sollte Links zu bestehenden Mailinglisten und ähnlichen Webseiten bereitstellen und einen direkten Verweis auf alle verfügbaren Möglichkeiten, deine Software herunterzuladen.

Weitere Tips zur Dokumentation

• Alle deine Dokumentation sollte in Klartext verfaßt sein, oder, wo sie primär auf deiner Webseite erscheint, in HTML. Jeder kann cat auf eine Datei ausführen, jeder hat einen Pager, (fast) jeder kann HTML darstellen. Du kannst gerne Informationen in PDF, Postscript, RTF oder einer beliebigen Zahl anderer weitläufig genutzter Formate verbreiten, aber dieser Informationen müssen auch im Klartext oder in HTML verfügbar sein, sonst werden sich manche Leute sehr ärgern über dich. Meiner Meinung nach fällt das info-Format auch in diese Kategorie. Es gibt viel großartige GNU- Dokumentation die die Leute einfach nicht lesen, nur weil sie im info-Format ist. Und das verärgert die Leute wirklich. Es ist nicht eine Frage überlegener Formate; es ist eine Frage der Zugänglichkeit, und der Status Quo spielt eine sehr große Rolle darin, diese zu definieren.
• Es schadet nicht, Dokumentation für dein Programm über deine Webseite zu verteilen (FAQ usw.), zusammen mit deinem Programm. Zögere nicht, Dokumentation in den tarball des herunterladbaren Programms zu packen. Wenn die Leute sie nicht benötigen, löschen sie sie wieder. Ich kann es nur immer wieder wiederholen: Zu viel Dokumentation ist keine Sünde.
• Falls deine Software nicht spezifisch für einen nicht-englischen Sprachraum ist (ein japanischer Editor zum Beispiel), verteile sie bitte mit englischer Dokumentation. Wenn du kein Englisch sprichst oder nicht überzeugt bist von deinen Sprachfähigkeiten, bitte einen Freund um Hilfe. Ob du es magst oder nicht, ob du es fair findest oder unfair, Englisch ist die Sprache der freien Software. Dies heißt jedoch nicht, daß du deine Dokumentation auf Englisch allein begrenzen solltest. Wenn du eine andere Sprache sprichst, verteile ruhig Übersetzungen der Dokumentation mit deiner Software, wenn du die Zeit und Energie hast, das zu tun. Sie wird sicherlich mal für jemanden nützlich.
• Als abschließender Rat, bitte prüfe deine Dokumentation auf Rechtschreibung. Rechtschreibfehler in Dokumentation sind Bugs. Ich habe diesen Fehler oft begangen und es ist sehr einfach, ihn zu begehen. Wenn Englisch nicht deine Muttersprache ist, laß' einen Muttersprachler gegenlesen bzw. deine Dokumentation und Webseiten korrigieren. Schlechte Rechtschreibung oder Grammatik hilft nachhaltig, deinen Code unprofessionell erscheinen zu lassen. In den Codekommentaren sind diese Dinge weniger wichtig, aber in den man pages und Webseiten sind diese Fehler nicht akzeptabel.

Dateinamen für Packete

Ich stimme mit ESR überein, wenn er sagt, daß "es hilfreich ist für jeden, wenn deine Archiv- dateien alle GNU-konforme Namen haben -- ein alphanumerisches Präfix in Kleinbuchstaben, gefolgt von einem Bindestrich, einer Versionsnummer, Dateiendung, und sonstigen Suffixen." Es gibt noch mehr Information (einschließlich vieler Beispiele was man nicht tun sollte) in seinem Software Release Practices HOWTO, das der Biographie dieses HOWTOs beigefügt wurde und das über das LDP zu finden ist.

Packetformate

Packetformate können unterschiedlich sein, je nach System, für das du entwickelst. Für Windows-basierte Software sind Zip-archive (.zip) meist das Format der Wahl. Wenn du für GNU/Linux, xBSD, oder sonst ein UNxX entwickelst, solltest du sicherstellen, daß der Quellcode immer im erst ge-"tar"-ten und dann ge-"gzip"-ten format (.tar.gz) verfügbar ist. UNIX compress (.Z) ist außer Mode gekommen und nicht mehr brauchbar, und schnellere Computer haben bzip2 (.bz2) als effektiveres Kompressionsformat ins Rampenlicht gerückt. Ich stelle jetzt alle meine freigegebenen Versionen als tarballs zu Verfügung, sowohl mit gzip als auch mit bzip2 komprimiert.

Binärpakete sollten immer distributionsspezifisch sein. Wenn du Binärpakete für eine aktuelle verbreitete Distribution bauen kannst, wirst du deine Benutzer glücklich machen. Versuche, Beziehungen zu Benutzern und Entwicklern großer Distributionen aufzubauen, um ein System entwickeln zu können, in dem du konsistente Binärpakete erzeugen kannst. Es ist oft eine gute Idee, RedHat RPMs (.rpm), Debian debs (.deb) und source RPMss (SRPMs) zu verfügung zu stellen wenn möglich.

Zur Erinnerung: Binärpakete sind nett, aber es sollte für dich immer Priorität haben, den Quellcode zu verpacken und zu veröffentlichen. Deine Benutzer und Mitentwickler können und werden die Binärversionen für dich machen.

Systeme für Versionsverwaltung

Eine Versionsverwaltung kann viele dieser Probleme mit der Paketerzeugung (sowie viele andere in diesem HOWTO erwähnte Probleme) vereinfachen. Wenn du *NIX verwendest, ist CVS wahrscheinlich deine beste Wahl. Ich empfehle Karl Fogels Buch zum Thema (sowie die HTML-Version online) mit ganzem Herzen.

Ob CVS oder nicht, du solltest wahrscheinlich ein bißchen Zeit in das Erlernen eines Versionsverwaltungssytems investieren, denn es bietet eine Möglichkeit, automatisch viele in diesem HOWTO beschriebenen Probleme zu lösen.

Ich weiß über freie Versionsverwaltungssysteme für Windows oder Mac nicht Bescheid, aber ich weiß, daß CVS clients für beide Platformen existieren. Webseiten wie Sourceforge leisten auch gute Dienste darin, ein nettes, benutzerfreundliches web interface für CVS anzubieten.

(Anm. des Übers.: Sourceforge empfiehlt TortoiseCVS für Windows, es integriert sich sehr gut in den Windows Explorer)

Ich würde CVS hier gerne noch mehr Platz einräumen, weil ich es liebe (ich benutze CVS sogar, um die Versionen dieses HOWTOs zu verwalten!), aber ich denke, daß es den Rahmen dieses Dokuments sprengt, außerdem wird es in eigenen HOWTOs besprochen. Am erwähnenswertesten ist das CVS Best Practices HOWTO [CVSBESTPRACTICES], daß ich der Bibliographie unten hinzugefügt habe.

Nützliche Kleinigkeiten und Präsentationstips

Weitere Tips:

• Stelle sicher, daß dein Programm immer an einer bestimmten Position gefunden werden kann. Häufig bedeutet das, daß du ein einzelnes, über FTP oder das Netz zugängliches Verzeichnis hast, wo die neueste Version schnell gefunden werden kann. Ein wirkungsvolle Technik besteht darin, einen symbolischen Link namens „yourprojectname-latest“ anzubieten, der immer auf die neueste freigegebene bzw. Entwicklungsversion deiner freien Software- Anwendung zeigt. Behalte im Hinterkopf, daß diese Position viele Downloadanfragen bekommen wird, überprüfe also daß dein gewählter Server über eine ausreichende Bandbreite verfügt.
• Stelle sicher, daß es eine gleichbleibende Emailaddresse für Bug-Reports gibt. Es ist normalerweise eine gute Idee, dafür eine Adresse anzulegen, die NICHT deine primäre Emailaddresse ist, etwas wie deinprojektname@host oder deinprojektname-bugs@host. Auf diese Weise brauchst du, wenn du dich je mal entscheidest, die Maintainerhoheit abzugeben, oder wenn sich einfach deine Emailaddresse ändert, einfach die Emailaddresse ändern, an die die Mails weitergeleitet werden. Es ermöglicht auch, daß sich mehr als eine Person mit der Flut an Post beschäftigen kann, die verursacht wird, wenn dein Projekt so riesig wird, wie du es dir erhoffst.

Wie man delegiert

Du magst die Erfahrung machen, daß andere Entwickler sogar noch erfahrener oder sachkundiger zu sein scheinen als du. Dein Job als Maintainer bedeutet nicht, daß du der Beste oder Gescheiteste sein mußt. Es bedeutet, daß du verantwortlich dafür bist, gut zu beurteilen und wartbare Lösungen von unwartbaren unterscheiden kannst. Wie bei anderen Dingen ist es leichter, andere beim Delegieren zu beobachten als es selber zu tun. In einem Satz gesagt: Halte ein Auge offen für andere qualifizierte Entwickler, die Interesse zeigen und anhaltendes Engagement in deinem Projekt, und versuche Verantwortlichkeit an sie abzugeben. Die folgenden Ideen könnten gute Startpunkte sein oder gute Quellen der Inspiration:

Gib einer größeren Gruppe Schreibzugriff auf deinem CVS-Repository und unternimm konkrete Schritte in Richtung Abstimmung durch ein Komitee.

Apache ist ein Beispiel eines Projektes, das von einer kleinen Gruppe an Entwicklern betrieben wird, die über wichtige technische Entscheidungen und die Aufnahme neuer Mitglieder abstimmen, und alle Schreibrechte auf dem zentralen Repository besitzen. Ihr Prozeß wird online genau beschrieben.

Das Debianprojekt ist ein extremes Beispiel von Abstimmung durch ein Komitee. Nach momentaner Zählung tragen mehr als 700 Entwickler volle Verantwortung für Aspekte des Projektes. Alle diese Entwickler können auf den Haupt-FTP-Server hochladen und über wichtige Angelegenheiten abstimmen. Die Richtung des Projektes wird durch den sogenannten "social contract" des Projektes und seine Verfassung festgelegt. Um dieses System zu unterstützen, gibt es spezielle Teams (z.B. das Installationsteam, das Team für japanische Sprache), außerdem gibt es einen technischen Ausschuß und einen Projektleiter. Die Hauptverantwortlichkeit des Leiters besteht darin, "Delegierte zu ernennen oder Entscheidungen an den technischen Ausschuß zu delegieren."

Während diese beiden Projekte sich in einer Dimension bewegen, die dein dein Projekt nicht haben wird (zumindestens nicht zu Beginn), ist ihr Beispiel doch nützlich. Debians Vorstellung eines Projektleiters, der nichts tun kann als zu delegieren dient als Karikatur davon, wie ein Projekt eine sehr große Zahl an Entwicklern einbeziehen und bevollmächtigen und eine enorme Größe erreichen kann.

Ernenne öffentlich jemanden als Releasemanager

Ein Releasemanager oder Freigabemanager ist normalerweise verantwortlich für die Koordination von Tests, dfür das Festlegen eines Code Freeze, für Stabilität und Qualitätskontrolle, sowie für das Zusammenbauen der Software und ihr und Bereitstellen zum Download an den passenden Orten.

Diese Verwendung des Freigabemanagers ist ein guter Weg, sich eine Atempause zu verschaffen und die Verantwortlichkeit für das Annehmen und das Zurückweisen von Patches auf jemand anderen zu verschieben. Es ist eine gute Methode, um ein Stück der Arbeit sehr klar abzugrenzen und einer Person zuzuweisen, und es ist eine tolle Methode, um sich Luft zu schaffen.

Verantwortung für einen ganzen Zweig delegieren

Wenn dein Projekt beschließt, mehrere Entwicklungs- zweige zu führen (wie im Abschnitt "Stabile Zweige und Entwicklungszweige " beschrieben), könnte es eine gute Idee sein, jemanden anderes zu ernennen, um der Leiter eines Zweiges zu sein. Wenn du deine Energie auf Entwicklungsreleases und die Implementierung neuer Features fokussieren möchtest, dann übergib die volle Kontrolle über stabile Releases an einen passenden Entwickler.

Der Autor von Linux, Linus Torvalds, ging hinaus und krönte Alan Cox als "Mann für stabile Kernels." Alle Patches für stabile Kernels gehen zu Alan und wenn Linus aus irgendeinem Grund von der Arbeit an Linux abgehalten werden sollte, wäre Alan Cox mehr als geeignet, um seine Rolle zu übernehmen als akzeptierter Erbe der Linux-Maintainerschaft.

Zu gutem Patchen anregen

Als die Person, die ein Projekt managt oder der Maintainer ist, bist du nicht die Person, die eine Menge an Patches macht. Es ist jedoch nützlich, wenn man den ESRs Abschnitt über gute Patchpraxis aus seinem Software Release Practices HOWTO [ESRHOWTO] kennt. Ich stimme nicht überein mit ESRs Behaupting, daß die allerhäßlichen oder undokumentiertesten Patches es vermutlich wert wären sofort herausgeworfen zu werden -- das ist gerade nicht meine Erfahrung gewesen, besonders wenn im Umgang mit Bugfixes, die oft überhaupt nicht in Form eines Patches kommen. Selbstverständlich bedeutet das nicht, daß ich gerne häßliche "-e"-Patches bekomme. Wenn du häßliche "-e"-Patches oder total undokumentierte Patches bekommst, und vor allem wenn sie irgendetwas anders als Bugfixes sind, könnte es nützlich sein, den Patch nach einigen der Kriterien in ESRs HOWTO zu beurteilen und den Leuten dann den Link zu diesem Dokument zu geben, damit sie "richtig" patchen können.

Fachliche Beurteilung

In Open Source Development with CVS argumentiert Karl Fogel überzeugend, daß beim Annehmen und Ablehnen von Patches die folgenden Dinge in der Berücksichtigung am wichtigsten sind:

• Solides Wissen über den Wirkungsbereich deines Programms (das ist die "Idee" von der ich sprach im Abschnitt "Wählen eines Projektes");
• Die Fähigkeit die "Evolution" deines Programms zu erkennen, zu erleichtern, und zu lenken, sodaß das Programm wachsen, sich ändern und Funktionalität aufnehmen kann, die so ursprünglich nicht vorgesehen war;
• Die Notwendigkeit, Abweichungen zu vermeiden, die den Bereich des Programms zu stark erweitern und das Projekt auf einen frühen Tod unter seinem eigenen Gewicht und seiner Unbeweglichkeit hinsteuern.

Dies sind die Kriterien die du als Projektmaintainer jedesmal in Betracht ziehen solltest, wenn du einen Patch bekommst.

Fogel führt dazu weiter aus und sagt daß "die Fragen, die du dir stellen solltest, wenn du abwägst, ob du eine Änderung implementierst (oder ihr zustimmst) folgende sind:

• Wird sie einem bedeutenden Prozentsatz der Benutzer-Community nützen?
• Paßt sie zum Einsatzgebiet des Programms oder in eine natürliche, intuitive Erweiterung dieses Gebiets?

Die Antworten zu diesen Fragen sind nie trivial und es sehr gut möglich (und sogar wahrscheinlich), daß die Person, die den Patch eingereicht hat, eine andere Antwort auf diese Fragen als richtig empfindet als du. Jedoch wenn du den Eindruck hast, daß die Antwort auf eine dieser Fragen "nein" ist, so ist es deine Verantwortung, die Änderung zurückzuweisen. Wenn du das nicht schaffst, wird das Projekt schwerfällig und unwartbar, und viele scheitern letztlich.

Zurückweisen von Patches

Patches zurückzuweisen ist vermutlich der schwierigste und sensibelste Job, dem sich der Maintainer jedwedes freien Software-Projektes stellen muß. Aber manchmal muß es getan werden. Ich erwähnte bereits (im Abschnitt "Wartung eines Projektes: Wie man mit Entwicklern interagiert" und im Abschnitt "Arbeit delegieren"), daß du versuchen mußt, deine Verantwortung und Macht zu balancieren, um die deiner Meinung nach besten fachlichen Entscheidungen zu treffen angesichts der Tatsache, daß du Unterstützung von anderen Entwicklern verlieren wirst, wenn du auf einem Machttrip bist oder du dich zu herschend oder besitzergreifend zu dem Projekt der Community verhältst. Ich empfehle, daß du dir diese drei Hauptkonzepte merkst, wenn du Patches zurückweist (oder andere Änderungen):

Die Zahl der Branches minimieren

Debian mag vier oder fünf Branches sinnvoll einsetzen können, aber es enthält auch Gigabytes an Software in über 5000 Paketen, kompiliert für 5-6 verschiedene Architekturen. Für dich sind zwei Branches vermutlich das Ende der Fahnenstange. Zu viele Branches verwirren deine Benutzer (ich kann keine Zahl nennen, wieviele Male ich Debians System beschreiben mußte, als es noch nur 2 und manchmal 3 Branches hatte!), mögliche Entwickler und dich selber. Branches können helfen, aber sie haben ihren Preis, also mache sehr sparsam Gebrauch von ihnen.

Stelle sicher, daß all deine verschiedenen Branches erklärt werden

Wie ich im vorhergehenden Punkt erwähnte, verwirren verschiedene Branches deine Benutzer. Tu' alles, was du kannst, um das zu vermeiden, indem du die verschiedenen Branches auf einer hervorstechenden Seite deiner web site und in einem README auf dem FTP-/Webverzeichnus verständlich erklärst.

Ich würde auch gerne eine Empfehlung ausprechen zu einem Fehler den Debin meiner Meinung nach gemacht hat. Die Bezeichnungen "unstable," "testing," und "experimental" sind vage und schwierig einzuordnen in Bezug auf Stabilität (oder Instabilität). Versuche, jemandem zu erklären, daß "stable" wirklich "ultrastabil" bedeutet und "unstable" nicht wirklich irgendwelche instabile Software beinhaltet, sondern stabile Software, die als Distribution zusammen ungestet ist.

Wenn du beabsichtigst, Branches zu verwenden, vor allem von einem frühen Zeitpunkt an, erinnere dich daran, daß die Leute darauf geeicht sind, die Bezeichnungen "stabil" und "development" zu verstehen und du mit dieser einfachen und gebräuchlichen Aufteilung in Branches vermutlich nicht falsch liegen kannst.

Stelle sicher, daß alle deine Branches immer verfügbar sind

Wie vieles in diesem Dokument, sollte das folgende eigentlich nicht gesagt zu werden brauchen, aber die Erfahrung hat mich gelehrt, daß es für viele Leute nicht immer auf der Hand liegt. Es ist eine gute Idee, Branches physikalisch auf unterschiedliche Verzeichnisse oder Verzeichnis- bäume auf deiner ftp-/Webseite aufzuspalten. Linux erreicht das, indem es Kernels in ein v2.2/v2.3- Unterverzeichnis ablegt, wo es sofort auf der Hand liegt (sobald du ihr Numerierungsschema kennst), welches Verzeichnis für die neueste stabile bzw. die aktuelle Entwicklungsversion steht. Debian erreicht das Ziel, indem es allen Distributionen Namen gibt (wie woody, potato, etc), und dann Symlinks namens "stable", "unstable", und "frozen" umleitet, um auf die entsprechende Distribution im entsprechenden Stadium zu verweisen. Beide Methoden funktionieren, und es gibt noch andere. In jedem Fall es ist wichtig, daß die unterschiedlichen Branches immer verfügbar und an gleichbleibenden Orten zugänglich sind, und daß unterschiedliche Branches klar von einander unterscheidbar sind, damit deine Benutzer genau wissen, welche sie wollen und wo sie sie bekommen.

Freezing

Für diejenigen Projekte, die beschließen, ein geteiltes Entwicklungsmodell (der Abschnitt "Stabile Zweige und Entwicklungszweige") zu wählen, ist "freezing" (dt. einfrieren) ein Konzept, mit dem vertraut zu werden nützlich ist.

Freezes kommen in zwei Hauptformen. Ein "feature freeze" ist eine Periode, in der einem Programm keine bedeutende Funktionalität hinzugefügt wird. Es eine Periode, in der etablierte Funktionalität (sogar Gerüste kaum funktionsfähiger Funktionalität) verbessert und vervollkommnet werden können. Es eine Periode, in der Bugs behoben werden. Diese Art des Freeze kommt normalerweise eine gewisse Zeit (ein Monat oder zwei) vor einem Release. Es ist einfach, ein Release zu verschieben, während du auf "ein weiteres Feature" wartest, und ein Freeze hilft, diese Situation zu vermeiden, indem er einen Schlußstrich setzt. Er gibt Entwicklern Raum, den sie brauchen, um ein Programm releasefertig zu bekommen.

Die zweite Art des Freeze ist ein "code freeze," welcher viel eher wie ein freigegebenes Stück Software aussieht. Sobald ein Stück Software einen "code freeze" begeht, wird von allen Änderungen am Code abgeraten, und nur Änderungen, die bekannte Bugs beheben sind gestattet. Diese Art von Freeze olgt normalerweise einem "feature freeze" und kommt kurz vor einem Release.Die meiste freigegebene Software befindet sich in einem Zustand, den man als einen "code freeze" auf höherer Ebene deuten könnte.

Selbst wenn du nie beschließt, einen Releasemanager zu ernennen (der Abschnitt "Ernenne öffentlich jemanden als Releasemanager "), wirst es dir leichter fallen, die Ablehnung oder den Aufschub von Patches zu rechtfertigen (der Abschnitt "Patches annehmen und ablehnen") vor einem Release mit einem öffentlich angekündigten Freeze.

Forks

Ich war mir nicht sicher, wie ich mit dem Forking (dt Aufgabeln, Aufspalten) in diesem Dokument umgehen soll (oder ob ich es überhaupt behandele). Ein Fork liegt vor, wenn eine Gruppe von Entwicklern den Code einer freien Software nimmt und tatsächlich ein völlig neues freies Software-Projekt mit ihm beginnt. Das berühmteste Beispiel eines Forks war zwischen Emacs und XEmacs. Beide Emacse basieren auf einer identischen Codebasis, aber aus technischen, politischen und philosophischen Gründen wurde die Entwicklung in zwei Projekte aufgespalten, die jetzt miteinander konkurrieren.

Die Kurzversion dieses Abschnitts über Forks ist: Mach' keinen. Forks zwingen Entwickler, sich für ein Projekt zu entscheiden, an dem sie arbeiten möchten, schaffen unangenehme politische Lager und Redundanz in der Arbeit. Glücklicherweise ist normalerweise die Drohung eines Forks genug, um den oder die Maintainer eines Projektes so abzuschrecken, daß sie ihren Projektführungsstil ändern.

In seinem Kapitel über den "Open Source Process" beschreibt Karl Fogel, wie man einen Fork durchführt, wenn du unbedingt mußt. Wenn du festgestellt hast, das es zwingend notwendig ist und die Differenzen zwischen dir und den Leuten, die mit einem Fork drohen absolut unauflöslich sind, empfehle ich Fogels Buch als gute Einführung.

Grenzwertfälle

Maximale Pufferlängen, Datenumwandlungen, ober/untere Grenzen, und so weiter.

Nicht angebrachtes Verhalten

Es ist eine gute Idee herauszufinden, was ein Programm tun wird, wenn ein Benutzer ihm einen Wert übergibt, den es nicht erwartet, eine falsche Taste drückt, etc. Frage dich eine Vielzahl von "was passiert, wenn ..."-Fragen und denke an all das, was schieflaufen oder falsch laufen könnte, und finde heraus, was dein Programm in diesen Fällen tun würde.

Würdevolles Versagen

Die Antwort zu einer Vielzahl von "was passiert, wenn ..."-Fragen oben ist vermutlich "Versagen," was häufig die einzige Antwort ist. Jetzt stelle sicher, ob das auf eine schöne Art geschieht. Stelle sicher, daß, wenn dein Programm abstürzt, es irgendwelche Hinweise gibt darüber, warum es abgestürzt ist oder versagt hat, sodaß der Benutzer oder Entwickler versteht, was los ist.

Standardkonformität

Wenn möglich stelle sicher, daß deine Programme sicher an Standards halten. Wenn es interaktiv ist, sei nicht zu kreativ mit Schnittstellen. Wenn es nicht interaktiv ist, dann stelle sicher, daß es über passende und etablierte Schnittstellen mit anderen Programmen und mit dem Rest des System kommuniziert.

Automatisiertes Testen

Für viele Programme können viele häufige Fehler durch automatisierte Methoden erkannt werden. Automatisierte Tests erweisen sich als nützlich beim Erkennen von Fehlern, in die du schon mehrmals vorher gelaufen bist, oder von den Dingen, die du einfach vergißt. Sie sind nicht sehr gut im Auffinden von Fehlern, auch sehr schweren Fehlern, die völlig unvorhergesehen sind.

CVS kommt mit einem Bourne-Shell-Skript namens sanity.sh, das eine Betrachtung wert ist. Debian verwendet ein Programm namens lintian, das Debianpakete auf die gängigsten Fehler prüft. Während der Gebrauch dieser Skripte nicht nützlich sein mag, gibt es doch eine Armee anderer Fehlerprüfsoftware im Netz, die vielleicht anwendbar ist (schick' mir ruhig Empfehlungen per Email). Keine von diesen wird zu einem bug-freien Release führen, aber sie vermeiden zumindest, daß du etwas wichtiges übersiehst. Schließlich wirst du feststellen, wenn deine Programme sich als längerfristige Projekte erweisen, daß du bestimmte Fehler immer wieder machst. Fange eine Skriptensammlung an, die auf diese Fehler hin prüfen, damit sie dir helfen, zukünftige Releases von diesen Fehler freizuhalten.

Testen durch Tester

In jedem Programm, das auf Interaktion mit dem Benutzer angewiesen ist, werden viele Bugs nur durch testende Benutzer gefunden, die wirklich die Tasten und Maustasten drücken. Dafür brauchst du Tester, und zwar so viele wie möglich.

Der schwierigste Teil am Testen ist das Finden von Testern. Es ist normalerweise eine gute Strategie, eine Nachricht an eine relevante Mailingliste oder Newsgroup zu schicken, die ein vorgeschlagenes Releasedatum ankündigt und die Funktionalität deines Programms skizziert. Wenn du ein bißchen Zeit in deine Ankündigung investierst, wirst du sicher einige Antworten erhalten.

Der zweitschwierigste Teil des Testens besteht darin, deine Tester zu binden und sie aktiv in den Test- prozeß miteinzubeziehen. Glücklicherweise gibt es einige bewährte Strategien, die man zu diesem Zweck anwenden kann:

Die Dinge einfach machen für deine Tester

Deine Tester tun dir einen Gefallen, also mach' es ihnen so einfach wie möglich. Das bedeutet, daß du achtgeben solltest, deine Software so zu verpacken, daß sie leicht zu finden, zu entpacken, zu installieren und zu deinstallieren ist. Das heißt auch, daß du jedem Tester erklären solltest, wonach du suchst, und zum Melden von Bugs einfache und bewährte Strukturen bereitstellst. Der Schlüssel liegt darin, so viel Struktur wie möglich zur Verfügung zu stellen, um deinen Testern ihren Job leicht zu machen, und so viel Flexibilität wie möglich zu behalten für diejenigen, die ein bißchen anders arbeiten wollen.

Sei entgegenkommend deinen Testern gegenüber

Wenn deine Tester Bugs einreichen, reagiere darauf, und reagiere schnell. Selbst wenn du nur so reagierst, daß du ihnen erklärst, daß der Bug bereits behoben ist, geben schnelle und konsistente Antworten ihnen das Gefühl, daß ihre Arbeit bemerkt wird, und daß sie wichtig und geschätzt ist.

Danke deinen Testern

Danke ihnen jedes Mal persönlich, wenn sie dir Patches schicken. Danke ihnen öffentlich in der Dokumentation und im About-Teil deines Programms. Du schätzt deine Tester und dein dein Programm wäre ohne ihre Hilfe nicht möglich. Stelle sicher, daß sie es mitkriegen. Klopfe ihnen öffentlich auf den Rücken, um sicherstellen, daß der Rest der Welt es auch mitkriegt. Das wird mehr geschätzt als du erwarten würdest.

Dokumentation

Es sollte keine Überraschung sein, daß das wichtigste Element jedweder Supportinfrastruktur gute Dokumentation ist. Dieses Thema wurde schon ausführlich im Abschnitt Dokumentation behandelt und wird hier nicht wiederholt.

Mailinglisten

Neben Dokumentation werden Mailinglisten dein wichtigstes Werkzeug beim Benutzersupport sein. Eine Mailingliste gut zu führen ist schwieriger als die bloße Installation einer entsprechenden Mailinglisten-Software.

Listen trennen

Es ist eine gute Idee, deine Benutzer- und Enwickler-Mailinglisten zu trennen (beispielsweise in project-user@host und project-devel@host) und diese Unterteilung zu forcieren. Wenn jemand eine entwicklungsrelevante Frage an die User-Liste schickt, bitte sie höflich, sie an die -devel-Liste zu schicken und umgekehrt. Schreibe dich bei beiden Listen ein und ermutige alle Hauptentwickler, dasselbe zu tun.

Dieses System stellt sicher daß der Support nicht bei einer einzelnen Person hängen bleibt, und erlaubt, daß alle Benutzer mehr über das Programm erfahren, sodaß sie neuen Benutzern bei ihren Fragen helfen können.

Mailinglisten-Software gut auswählen

Triff deine Auswahl für eine Mailinglisten-Software bitte nicht spontan. Berücksichtige bitte die einfache Zugänglichkeit durch Benutzer ohne viel technische Erfahrung, mache es ihnen also so einfach wie möglich. Zugänglichkeit zu einem Web-Archiv der Liste ist auch wichtig.

Die zwei größten freien Mailinglisten-Programme sind Majordomo und GNU Mailman. Wenn ich auch lange ein Fürsprecher für Majordomo war, würde ich jetzt jedem Projekt empfehlen, GNU Mailman zu nehmen. Es erfüllt die oben genannten Kriterien und macht die Dinge einfacher. Es bietet ein gutes Mailinglistenprogramm für einen Maintainer eines freien Software-Projektes, nicht nur für einen Administrator von Mailinglisten.

Es gibt noch andere Sachen, die du berücksichtigen solltest beim Einrichten deiner Liste. Wenn es möglich ist, deine Mailinglisten ins Usenet weiter- zuleiten und in einem digest-Format (gesammelt) sowie im Netz zur Verfügung zu stellen, wirst das einigen Benutzern gefallen und deine Supportinfrastruktur etwas zugänglicher machen.

Andere Supportideen

Eine Mailingliste und zugängliche Dokumentation sind noch lange nicht alles, was du tun kannst, um eine gute Benutzersupportinfrastruktur aufzubauen. Sei kreativ. Wenn du über etwas stolperst, das gut funktioniert, emaile es mir, dann werde ich es hier hinzufügen.

Wann man freigibt

Die Entscheidung, wann du deine Software zum ersten Mal releast, ist eine unglaublich wichtige und unglaublich stressvolle Entscheidung. Aber sie muß getroffen werden. Mein Rat ist, zu versuchen, etwas zu schaffen, das fertig genug ist, um verwendbar zu sein und unvollständig genug, um Flexibilität und Raum für die Phantasie deiner zukünftigen Entwickler zu lassen. Es ist keine einfache Entscheidung. Frag' nach Hilfe auf einer lokalen Linuxnutzer-Mailingliste oder frag' eine Gruppe von Freunden, die selber Entwickler sind.

Eine Taktik besteht darin, zuerst ein "Alpha"- oder "Beta"-Release zu machen, wie im Abschnitt "Alpha-, Beta- und Entwicklungsfreigaben" beschrieben. Jedoch gelten die meisten der oben genannten Regeln nach wie vor.

Wenn du ein Bauchgefühl hast, daß es Zeit ist und du meinst, die Situation oft genug abgewogen zu haben, dann kreuze die Finger und wage den Sprung ins Nasse.

Nachdem du das ersten Mal ein Release gemacht hast, wird die Entscheidung, wann das nächste erfolgt weniger stressvoll sein, dabei aber genauso schwierig abzuschätzen sein. Ich mag die Kriterien die Robert Krawitz in seinem Artikel "Free Software Project Management" bereithält, um einen guten Releasezyklus beizubehalten. Er empfiehlt, daß du dich fragst, "hat dieses Release..."

• Genügende neue Funktionalität oder Bugfixes, daß es die Mühe wert ist.
• Genug zeitlichen Abstand zum letzten, sodaß der Benutzer die Möglichkeit hat, mit dem neuesten Release zu arbeiten.
• Funktioniert es gut genug, daß der Benutzer damit arbeiten kann.

Wenn die Antwort auf alle diese Fragen ja ist, ist es vermutlich Zeit für ein Release. Wenn du Zweifel hast, erinnere dich daß um Rat zu fragen nichts kostet.

Wie man freigibt

Wenn du den beschriebenen Richtlinien in diesem HOWTO bis diesen Punkt gefolgt bist, wird die praktische Umsetzung für dich der einfache Teil am Release sein. Wenn du einheitliche Distributionsorte bereitgestellt hast sowie die übrige Infrastruktur wie in den vorhergehenden Abschnitten beschrieben, wird der Releaseprozess einfach nur darin bestehen, ein Packet zu bauen, es noch einmal zu prüfen, es dann an den richtigen Ort hochzuladen und deine Webseite entsprechend zu aktualisieren.

Alpha-, Beta- und Entwicklungsfreigaben

Wenn man ein Release erwägt, ist die Tatsache erwägenswert, daß nicht jedes Release ein separat numeriertes Release sein muß. Softwarenutzer sind an Prereleases gewöhnt, aber du mußt vorsichtig sein und diese Releases akkurat benennen, sonst schaffen sie mehr Probleme als Nutzen.

Oft sieht man, daß viele Entwicker freier Software vom Releasezyklus verwirrt zu sein scheinen. "Managing Projects the Open Source Way" schlägt vor, daß du den Satz "Alpha ist nicht Beta, Beta ist nicht Release" auswendig lernst und ich stimme zu, daß das vermutlich eine gute Idee ist.

Mailinglisten und USENET

Kündige deine Software auf comp.os.linux.announce im USENET an. Wenn du deineSoftware nur an zwei Stellen ankündigen willst, nimm' c.o.l.a und freshmeat.

Email ist allerdings immer noch der Weg, auf dem die meisten Leute im Internet an Informationen gelangen. Es ist eine gute Idee, ein dein Programm ankündigende Nachricht an jede relevante Mailingliste zu schicken, von der du weißt, sowie an andere relevante USENET- Diskussionsgruppen.

Karl Fogel empfiehlt, daß du eine einfache Betreffzeile benutzt, die erkennbar macht, daß die Nachricht eine Ankündigung ist, die den Namen deines Programms, Version sowie eine halbe Zeile enthält, die seine Funktionalität beschreibt. Auf diese Weise wird jeder interessierte Benutzer oder Entwickler sofort auf deine Ankündigung aufmerksam. Fogels Beispiel sieht so aus (Anm. des Übers.: ANN steht für announcement=Ankündigung):

Subject: ANN: aub 1.0, a program to assemble Usenet binaries

Der Rest der Email sollte die Programmfunktionalität kurz und präzise in maximal zwei Absätzen beschreiben und Links zur Webseite des Projekts sowie direkte Links zu den Downloads anbieten, für die, die sie sofort ausprobieren wollen. Dieses Format wird sowohl im USENET als auch bei Posts in Mailinglisten funktionieren.

Du solltest die Ankündigungen an den gleichen Stellen konsistent wiederholen, wann immer es ein neues Release gibt.

freshmeat.net

Ich habe es schon vorher erwähnt im Abschnitt "Ähnliche Projekte finden," in der freien Software-Community heutzutage sind Ankündigungen deines Projektes auf freshmeat fast noch wichtiger als Ankündigungen auf Mailinglisten.

Besuche die freshmeat.net-Webseite oder ihre "submit project page," um dein Projekt auf ihrer Webseite und in ihrer Datenbank einzutragen. Neben einer großen Webseite bietet freshmeat einen täglichen Newsletter an, der die täglichen Releases hervorhebt und ein sehr großes Publikum erreicht (ich persönlich überfliege es jeden Abend nach interessanten neuen Releases).

Projekt-Mailingliste

Wenn du soweit gegangen bist, eine Mailingliste für dein Projekt zu erstellen, dann solltest du neue Versionen auf diesen Listen immer ankündigen. Meiner Erfahrung nach verlangen die Benutzer bei vielen Projekten eine Mailingliste nur für Announcements mit sehr geringem Durchsatz, um über neue Releases zu erfahren. freshmeat.net erlaubt Benutzern jetzt, sich für ein Projekt einzutragen, um jedesmal eine Mail zu bekommen, wenn eine neue Version durch ihr System angekündigt wird. Es ist frei und es kann eine entsprechende Mailingliste ersetzen. Meiner Meinung nach kann es nicht schaden.