fix typo in makefile

[fspm_howto] / FreeSoftwareProjectManagementHOWTO.DE.rst

********************************************
Projektmanagement für freie Software - HOWTO
********************************************

:Author: Benjamin "Mako" Hill, [mako {at} debian.org]

:Author: Übersetzung: Robert F Schmitt, [bobfspm {at} arepo.org]
    
Revisionen
----------

======================== ============== ==============
Revision v0.3.2          15. April 2002 Benutzer: bch
Revision v0.3.1          18. Juni 2001  Benutzer: bch
Revision v0.3            5. Mai 2001    Benutzer: bch
Revision v0.2.1          10. April 2001 Benutzer: bch
Revision v0.2            8. April 2001  Benutzer: bch
Revision v0.01           27. März 2001  Benutzer: bch
(Ursprüngliche Revision)                
======================== ============== ==============


Dieses HOWTO ist konzipiert für Leute mit
Programmiererfahrung und ein paar Fähigkeiten
im
Management eines Software-Projektes, für
die jedoch
die Welt der freien Software neu ist.
Dieses Dokument ist gedacht als ein
Führer zu nichttechnischen Aspekten
des freien Software-Projektmanagements und
wurde 
geschrieben als Crashkurs für die sozialen
Fähigkeiten, die kommerziellen Entwicklern
nicht 
beigebracht werden, die aber über Wohl und
Wehe
eines freien Softwareprojektes entscheiden
können.



Einleitung
----------

Beim Überfliegen von freshmeat.net findet
man Tausende
von Gründen für die Existenz dieses HOWTOS
- das Internet
ist übersät mit ausgezeichnet geschriebenen
und 
nützlichen Programmen,
die ins Universum der vergessenen freien
Software
entschwunden sind. 
Diese düstere Szene führte mich zu der Frage
"warum?"

Dieses HOWTO versucht, eine Menge Sachen
(vermutlich zu viele) zu erledigen, aber
es kann
nicht diese Frage beantworten und wird es
nicht versuchen. Was dieses HOWTO versucht,
ist, deinem freien Software-Projekt
eine Überlebenschance zu verschaffen -
einen Vorsprung. Wenn du ein Stück Schrottcode
schreibst,
das niemanden interessiert, kannst
du dieses HOWTO lesen, bis du es im
Schlaf aufsagen kannst, und dein Projekt
wird 
vermutlich fehlschlagen. Andererseits kannst
du ein 
schönes,
relevantes Stück Software schreiben und jede
Anweisung in diesem HOWTO befolgen 
und deine Software schafft es vielleicht
trotzdem
nicht.
Manchmal ist das Leben so. Jedoch wage ich
micht
ein Stück vor und sage, daß du, wenn du ein
großes relevantes Stücke Software schreibst
und den Rat dieses HOWTOs ignorierst, 
vermutlich häufiger scheitern wirst.

Eine Menge Informationen in diesem HOWTO
sollte man gesunden Menschenverstand nennen.
Selbstverständlich, wie jede mögliche Debatte
über Schnittstellen zeigt, was gesunder 
Menschenverstand für manche Programmierer
ist, erweist
sich als völlig unintuitiv für andere. 
Nachdem ich die Grundlagen dieses HOWTOs
freien 
Softwareentwicklern bei einigen Gelegenheiten
erklärt
habe, stellte ich fest,
daß ich durch das Schreiben dieses HOWTOs
ein nützliches
Hilfsmittel zur Verfügung stellen könnte,
und ein Forum für Programmierer um Ideen
auszutauschen darüber, was für sie funktioniert
hat
und was nicht.

Wie jeder zugeben würde, der je involviert
war in die
dem Anschein nach nie enden wollende Kette
von 
Urheberrechtsstreitigkeiten, erweist sich
ein kleiner
Abschnitt Juristendeutsch als wichtig.



Copyright-Informationen
.......................

Dieses Dokument ist (c) 2002 von Benjamin "Mako" Hill
und wird unter den Bedingungen der Free Documentation
License veröffentlicht.

Es besteht die Erlaubnis, dieses Dokument zu kopieren,
zu verteilen und/oder zu modifizieren, unter den
Bedingungen der GNU Free Documentation License, in 
der Version 1.1 oder jeder späteren von der Free 
Software Foundation publizierten Version, ohne
unveränderliche Abschnitte, Frontseiten- oder
Rückseitentexte. Eine Kopie der Lizenz
kann im Anhang A gefunden werden.



Disclaimer
..........

Es kann keine Verbindlichkeit für den Inhalt dieses 
Dokuments angenommen werden. Die Nutzung der beschriebenen
Konzepte, Beispiele und anderen Inhalte geschieht auf 
eigene Gefahr. Da dies eine neue Veröffentlichung dieses 
Dokumentes ist, können Fehler und Ungenauigkeiten 
zu finden sein, die natürlich deinem Projekt (und 
möglicherweise deinem System) Schaden zufügen
könnten. Laß' Vorsicht walten, denn wenn es auch
sehr unwahrscheinlich ist, kann der Autor keine 
Verantwortung für diese Dinge übernehmen.

Alles Copyrights werden von ihren jeweiligen Inhabern 
gehalten, es sei denn es wird ausdrücklich etwas 
anderes vermerkt. Der Gebrauch irgendeines Begriffes
in diesem Dokument sollte nicht so interpretiert werden,
daß er die Gültigkeit irgendeines eingetragenen 
Warenzeichens oder einer Dienstleistungsmarke
berührt.

Die Nennung bestimmter Produkte oder Marken sollte 
nicht als Werbung gesehen werden.



Neue Versionen
..............

Diese Version ist Teil des dritten pre-release-
Zyklus dieses HOWTO. Es ist geschrieben,
um
Entwicklern zur Verfügung gestellt zu werden,
für Kritik und Brainstorming. Bitte berücksichtige,
daß diese Version des HOWTOs noch
in einem Säuglingsstadium ist und noch weitgehend
verbessert werden wird.

Die neueste Versionsnummer dieses Dokumentes
sollte auf dem Projekthomepage immer verzeichnet
werden, die unter yukidoke.org gehosted wird.

Die neueste Version dieses HOWTO wird immer
von der gleichen Webseite in einer Vielzahl
von Formaten zur Verfügung gestellt:

- HTML.
- HTML (einzelne Seite).
- normaler Text.
- Komprimiertes Postscript.
- Komprimierter SGML-Quellcode. 

(Anm. des Übers.: Die deutsche Version ist
Rest-basiert,
liegt also im Klartext und als HTML-Version
vor.)

Credits
.......

In dieser Version darf ich die Unterstützung
folgender Personen anerkennen:

Debian-Mitentwickler Martin Michlmayr
und Vivek Venugopalan, die mich Informationen
und Verbindungen zu extrem interessanten
Artikeln schickten. Ich habe beide der Bibliographie
hinzugefügt und ich habe Informationen von
beiden dem HOWTO hinzugefügt. Danke an Andrews
Shugg, der einige Störungen im Dokument unterstrich.
Auch grosses Danke an Sung Wook Her (AKA
RedBaron) die die erste Übersetzung des HOWTOs
ins Koreanische macht. Ich bin glücklich
gewesen,
zu sehen, daß Leute sich bisher am HOWTO
erfreut und davon profitiert haben.

Ältere Danksagungen, die ich noch nicht herausnehmen
möchte, schließen ein: Josh Crawford,
Andy King und Jaime Davila, die alle das
Dokument
im Ganzen gelesen haben und mir Feedback
gaben, 
das mir geholfen
hat, Änderungen und Verbesserungen an diesem
Dokument zu machen. Ich kann nicht dir Kerle
genug für deine Hilfe danken. Ein extra Danke
geht 
an Andy King, der dieses mehrmals las und
Patches einreichte,
um das Leben einfacher zu machen für mich.

Karl Fogel, demr Autor von Open Source Development
with CVS (erschienen im Verlag Coriolis Open
Press), 
Große Teile seines
Buches sind im Netz verfügbar. 

(Anm. des Übers.: Das Buch ist inzwischen vollständig
online unter der GPL verfügbar)

225 Seiten des Buches sind unter der GPL verfügbar und
stellen das beste Tutorial über CVS dar,
das ich je gesehen habe. Der Rest
des Buches behandelt "die Herausforderungen
und
die philosophischen Aspekte, die dem Betreiben
eines Open Source-Projektes mit CVS zugrunde
liegen." 
Das Buch macht seine Arbeit gut, was das
Abhandeln
einiger der Themen angeht, die in diesem
HOWTO 
vorgestellt werden, und noch viel mehr. 
Die Webseite des Buches hat Informationen
zur Bestellung des Buches und stellt einige
Übersetzungen der Kapitel über CVS zur Verfügung.

Wenn du ernsthaft daran interessiert bist, ein freies
Software-Projekt zu betreiben, wirst 
du dieses Buch haben wollen. Ich versuchte,
Fogel in den Abschnitten dieses HOWTO zu erwähnen,
wo ich wußte, daß ich direkt seine
Ideen borgte. Wenn ich irgendwelche übersehen
habe,
tut es mir leid. Ich werde versuchen, solche
Stellen in zukünftigen Versionen zu korrigieren.

Karl Fogel kann unter 
<kfogel (at) red-bean (Punkt) com> erreicht
werden.

Wer auch Hilfsmaterial und Inspiration für
dieses
HOWTO zur Verfügung stellt ist Eric
S. Raymond mit seinen fruchtbaren, schlüssigen
und sorgfältig ausgearbeiteten Argumenten
sowie
Lawrence Lessig, der mich erinnert hat
an den Wert freier Software. 
Weiterhin
möchte ich allen Benutzern und Entwicklern
danken, die in am Debian-Projekt beteiligt
sind.
Das Projekt hat mir ein Zuhause,
einen Ort verschafft, um für freie Software 
zu werben, einen Ort, von wo aus man
etwas verändern kann,
einen Ort, um von denen zu lernen, die
an der Bewegung viel länger beteiligt sind
als ich, 
und Beweis eines freien Software-Projektes,
das definitiv, definitiv funktioniert.

Vor allem möchte ich Richard Stallman für
seine Arbeit an der Free Software Foundation
danken und dafür, nie aufzugeben. Stallman
liefert
und artikuliert die philosophische Grundlage,
die mich zur freien Software zieht und
die mich zum Schreiben eines
Dokumentes motiviert, um sicherzustellen,
daß es
funktioniert. 

RMS kann immer per Email erreicht werden
unter <rms (at) gnu (Punkt) org>.



Feedback
........

Feedback ist immer und zweifellos willkommen
zu diesem Dokument. Ohne deine Zusendungen
und Input würde dieses Dokument nicht bestehen.
Glaubst du, daß etwas fehlt? Zögere nicht,
mit mir in Verbindung zu treten, wenn ich
ein Kapitel, einen Abschnitt oder
einen Unterabschnitt schreiben soll oder

du einen schreiben willst. Ich möchte, daß
dieses 
Dokument ein Produkt des freien Softwareentwicklungs-
Prozesses ist, den es anpreist und ich
glaube, daß sein letztlicher Erfolg in
seiner Fähigkeit, dies zu tun liegt. Bitte
schicke Deine 
Ergänzungen, Anmerkungen und
Kritiken an folgende Emailaddresse: 
<mako (at) debian.org>.



Übersetzungen
.............

Ich weiß, daß nicht jeder Englisch spricht.
Übersetzungen sind nett und ich hätte es
gerne,
daß dieses HOWTO die Art internationaler
Publizität erfährt, die durch übersetzte
Versionen
möglich wird.

Ich bin von einem Leser kontaktiert worden,
der
eine Übersetzung ins Koreanische verspricht.
Jedoch ist dieses HOWTO noch jung, und abgesehen
von dem Versprechen des Koreaners ist Englisch
alles, was zur Zeit verfügbar ist. Wenn du
helfen oder eine Übersetzung machen möchtest,
gewinnst du meinen äußersten Respekt und
Bewunderung und wirst Teil eines
coolen Prozesses sein dürfen. Wenn du überhaupt
interessiert bist, bitte nicht zögern,
mit mir in Verbindung zu treten: <mako (at) debian.org>.



Beginnen eines Projektes
------------------------

Ohne große Zweifel ist der Anfang
die schwierigste Periode im Leben eines Projektes,
um erfolgreiches Projektmanagement für freie
Software
zu leisten. Das Schaffen einer festen Grundlage
entscheidet 
darüber, ob dein Projekt blüht oder eingeht
und stirbt. Es ist auch das Thema, an dem
am meisten direktes Interesse von jedermann
besteht, der dieses Dokument als Tutorial
liest.

Das Beginnen eines Projektes schließt ein
Dilemma mit ein, mit dem du als Entwickler
versuchen mußt klarzukommen: kein möglicher
Benutzer für dein Programm ist an einem Programm
interessiert, das nicht funktioniert, während
der Entwicklungsprozeß, den du etablieren
möchtest,
die Einbeziehung der User als Grundvoraussetzung
betrachtet.

Es ist in diesen gefährlichen Ausgangsmomenten,
daß jedermann, der daran arbeitet, ein freies
Software-Projekt zu beginnen versuchen muß,
eine Balance zwischen diesen Voraussetzungen
zu schaffen.
Eine der wichtigsten Arten, die jemand,
der ein Projekt zu beginnen versucht, in
Richtung dieser Balance bearbeiten kann,
ist, in dem er auf eine festes Framework
für den
Entwicklungsprozeß hinarbeitet durch einige
der 
Vorschläge, die in diesem Abschnitt erwähnt
werden.



Wählen eines Projektes
......................

Wenn du dieses Dokument liest, hast du wahrscheinlich
bereits eine Idee für ein Projekt. Wahrscheinlich
füllt es auch eine als solche wahrgenommene
Lücke, indem es etwas tut, das kein
anderes freies Software-Projekt tut oder
indem es etwas in einer Weise tut, die 
einzigartig genug ist, um ein nagelneues
Stück 
Software zu erfordern.



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ß \84jede 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:

freshmeat.net
#############

freshmeat.net beschreibt sich selbst als, "der
größte Index des WWW für Linux- und Open Source-Software" 
und sein Renommee diesbezüglich ist absolut 
unvergleichlich und unbestritten. 
Wenn du etwas nicht auf freshmeat finden kannst, 
ist es zweifelhaft, 
daß du (oder sonstwer) es überhaupt finden wirst.

Slashdot
########

Slashdot bietet "News for Nerds. Stuff
that matters," wozu gewöhnlich
Diskussionen über freie Software, Open Source, 
Technologie und Nachrichten/Veranstaltungen
für Freaks gehören. Es ist nicht ungewöhnlich,
daß besonders interessante 
Entwicklungsbestrebungen hier verkündet werden, 
also ist die Seite definitiv einen Besuch wert.

SourceForge
###########

SourceForge beherbergt und unterstützt
eine wachsende Anzahl an Open Source-/
Free Software-Projekten. Es wird auch 
schnell zur Basis und Pflichthaltestelle
für Entwickler freier Software. 
SourceForges "software map" und seine "new release"-
Seiten sollten unbedingt aufgesucht werden, bevor man 
mit einem neuen freien Software-Projekt loslegt. 
SourceForge liefert auch eine "Code Snippet"-Bibliothek, 
die nützliche wiederverwendbare Codeteile in einer 
Reihe von Sprachen enthält, was für jedes 
Projekt nützlich werden kann.

Google und Googles Linuxsuche
#############################

Google und Googles Linuxsuche bieten
leistungsfähige Netzsuchen an, die Leute ans
Tageslicht bringen können, die an ähnlichen Projekten
arbeiten. Sie bieten kein Verzeichnis für Software
oder Nachrichten wie freshmeat oder slashdot,
sind aber einen Check wert, um sicherzustellen,
daß du deine Energie nicht in ein redundantes
Projekt steckst.

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.



Deinem Projekt einen Namen geben
................................

Wenn es auch viel Projekte gibt, die mit
beschreibenden Namen fehlschlagen und ohne sie 
Erfolg haben, denke ich doch, daß es sich lohnt,
sich über die Benamung deines Projektes ein paar
Gedanken zu machen. Leslie Orchard geht dieses 
Problem in einem Advogato-Artikel an. Sein Artikel
ist kurz, und ist es definitiv wert, mal überflogen 
zu werden.

Zusammengefaßt empfiehlt Orchard, daß du einen 
Namen wählst, bei dem viele Benutzer 
oder Entwickler sowohl

- wissen, was das Projekt macht, und
- sich am nächsten Tag noch daran erinnern. 

Ironischerweise erreicht Orchards eigenes Projekt namens "Iajitsu"
keines von beiden. Es hat vermutlich nichts damit zu
tun, daß die Entwicklung praktisch stillsteht, seit 
der Artikel geschrieben wurde.

Er bringt damit aber einen wichtiges Argument auf.
Es gibt Firmen deren einziger Job es ist, Namen für 
Software(-teile) zu erfinden. Sie machen damit
wahnsinnig viel Geld und sind es vermutlich wert. 
Wenn du dir auch eine solche Firma vermutlich
nicht leisten kannst, kannst du es dir leisten,
aus ihrer Existenz zu lernen und über den
zukünftigen Namen deines Projektes ein wenig 
nachdenken, weil es sehr wohl von Bedeutung ist.

Wenn es einen Namen gibt, den du unbedingt willst, 
er aber nicht Orchards Kriterien genügt, nur zu.
Ich hielt "gnubile" für einen der besten Namen, die 
ich unter freien Software-Projekten je gehört 
habe und ich sprech immer noch darüber, obwohl
ich das Programm schon lange nicht mehr verwende. 
Wenn du bei diesem Thema flexibel sein kannst, 
hör' auf Orchards Rat. Es könnte hilfreich sein.



Lizensierung deiner Software
............................

Abstrakt (und recht vereinfacht) gesagt, ist der 
Unterschied zwischen einem Baustein freier Software 
und einem Baustein proprietärer Software die Lizenz. 
Eine Lizenz hilft dir als der Entwickler, indem sie 
deine verbrieften Rechte schützt, um deine Software 
zu deinen Bedingungen in Umlauf zu bringen, und 
sie hilft, indem sie denen, die dir helfen möchten 
zeigt, das sie ermutigt sind, mitzumachen.



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.  



Wählen einer Methode der Versionsnumerierung   
............................................

Der wichtigste Aspekt an einem System für
die Versionsnumerierung ist, daß es eins gibt.

Es mag pedantisch scheinen, diesen Punkt
hervorzuheben, aber du wärest überrascht
über der Zahl von Skripten und kleinen Programmen,
die ohne irgendeine Versionsnummer auftauchen.

Der zweitwichtigste Aspekt eines Systems  
der Versionsnumerierung ist, daß die Zahlen immer 
erhöht wird. Automatische Versionierungssysteme 
und  das kosmische Grundverständnis der Menschen
kollabieren, wenn Versionsnummern nicht steigen.  
Es ist nicht wirklich wichtig, ob 2.1 ein 
grosser Schritt und 2.0.005 ein kleiner Schritt in
der Entwicklung ist, aber es ist wichtig, daß 2.1 
aktueller als 2.0.005 ist.    

Folge diesen zwei einfachen Richtlinien und du 
wirst nicht (zu sehr) falsch liegen. Darüber
hinaus scheint die allgemein verbreitetste Technik 
das Versionierungsschema mit "major level" (Hauptversion),
"minor level" (Unterversion) und "patch level" 
(kleinere Korrekturen) zu sein. Unabhängig davon, 
ob du mit den Bezeichnungen vertraut bist oder 
nicht, hast du doch dauernd mit ihnen zu tun. 
Die erste Zahl ist die Hauptzahl und signalisiert 
große Änderungen oder Rewrites.  
Die zweite Zahl ist eine untergeordnete Zahl und
stellt hinzugefügte oder abgewandelte Funktionalität 
dar, unter weitgehender Beibehaltung der 
Programmstruktur. Die dritte Zahl (patch number) 
bezieht sich gewöhnlich nur auf Versionen, die
veröffentlicht wurden, um Bugs zu beseitigen.

Weil dieses Schemas weit verbreitet ist, kenne 
ich die Auswirkung und den relativen Grad an
Unterschied zwischen einer Version 2.4.12
des Linuxkerns und einer Version 2.4.11/2.2.12/
1.2.12, ohne irgendetwas zu wissen über die
Versionen als solche.    

Du kannst dich an diese Richtlinien halten oder 
nicht, andere Leute machen das auch.
Aber Vorsicht, wenn du dich dazu entschließt, 
wird sich jemand darüber ärgern, denken, daß du 
nicht bescheid weißt, und versuchen, dich zu 
erziehen, vermutlich nicht auf eine freundliche Art.
Ich folge dieser Methode immer, und ich 
an beschwöre dich flehentlich, das ebenfalls zu tun.   

Es gibt einige Versionsnumerierungssysteme, die
weithin bekannt und nützlich sind, und die einen
Blick wert sein könnten, bevor du deine erste 
Version freigibst.    



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. 



Dokumentation
.............

Eine große Zahl ansonsten fantastischer freier
Software-Applikationen sind eingegangen und 
gestorben, weil ihr Autor die einzige Person war,
die wußte, wie man sie im Detail nutzt.
Selbst wenn dein Programm primär für eine
technisch versierte Benutzergruppe geschrieben ist,
ist Dokumentation hilfreich und sogar notwendig für
das Überleben deines Projektes.
Du wirst später im Abschnitt 
"Veröffentlichung deines Programms" erfahren, daß
du immer etwas veröffentlichen solltest, das 
benutzbar ist.
Ein Stück Software ohne Dokumentation ist nicht 
benutzbar.

Es gibt viele verschiedene Leute, für die du 
dein Projekt dokumentieren solltest.
Die Bedeutung von Dokumentation im Source Code
um die Entwicklung durch eine große Community
zu erleichtern ist essentiell, aber sie 
überschreitet den Rahmen dieses HOWTOs.
Aus diesem Grund beschäftigt sich dieser Abschnitt
mit einer sinnvollen Taktik für benutzerorientierte
Dokumentation.

Eine Kombination aus Tradition und Notwendigkeit
führte zu einem quasi-regulären Dokumentationssystem
in den meisten freien Software-Projekten, das
es wert ist, angewandt zu werden.
Sowohl Benutzer als auch Entwickler erwarten, daß
sie in der Lage sind, Dokumentation auf verschiedene
Arten zu bekommen, und es ist essentiell, daß du
die von ihnen gesuchte Information in einer Form
zur Verfügung stellst, die sie lesen können, wenn 
dein Projekt jemals abheben soll. 
Die Leute erwarten inzwischen die folgenden 
Dokumente:



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. 



Weitere Aspekte der Darstellung
...............................

Viele der verbleibenden Aspekte rund um die
Erzeugung eines neuen freien Softwareprogramms
gehören zu den Aspekten, die die meisten Leute
zum gesunden Menschenverstand zählen.
Man sagt oft, daß software engineering zu 90 Prozent
von gesundem Menschenverstand und zu 10 Prozent von
Spezialwissen bestimmt wird. Trotzdem sind diese
90 Prozent ein paar Worte wert, in der Hoffnung, daß
sie einen Entwickler an etwas erinnern könnten,
was er vergessen haben könnte.

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 \84yourprojectname-latest\93
  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.     

Wartung eines Projektes: Wie man mit Entwicklern interagiert
------------------------------------------------------------
    
Sobald dein Projekt den Start geschafft hat, hast die 
schwierigsten Hürden überwunden im Entwicklungsprozeß 
deines Programms.  Eine feste Grundlage zu legen 
ist essentiell, aber der Entwicklungsprozeß selbst 
ist gleichermaßen wichtig und bietet genauso viele 
Gelegenheiten zum Versagen. In den folgenden 
zwei Abschnitten werde ich beschreiben, wie
man ein Projekt handhabt, indem ich diskutiere, wie 
man mit Entwicklern und Benutzern interagiert.    

Durch die Veröffentlichung deines Programmes wird 
es freie Software. Dieser Übergang bedeutet mehr als
nur eine größere Benutzerbasis. Durch das 
Freigeben deines Programms als freie Software 
wird deine Software die Software der Community
um freie Software. Die Richtung der Entwicklung 
deiner Software wird völlig umgestaltet, 
in eine andere Richtung geführt und vollkommen
durch deine Benutzer bestimmt, sowie, in einem 
größeren Umfang, durch andere Entwickler in der 
Community.    

Der Hauptunterschied zwischen freier Software-  
Entwicklung und Proprietärer Software-Entwicklung  
ist die Entwicklerbasis. Als der Leiter eines 
freien Softwareprojektes mußt du Entwickler auf eine
besondere Art und Weise anziehen und unterhalten, 
was für Leiter kommerzieller Software-Projekte 
schlicht kein Thema ist. Als die Person, die die
Entwicklung eines freien Software-Projektes leitet, 
mußt du die Arbeit deiner Mitentwickler in die
richtige Richtung lenken, indem du verantwortliche 
Entscheidungen triffst, bzw. dich auf verantwortliche Weise dazu entschließt, 
Entscheidungen nicht zu treffen. Du mußt
Entwickler anleiten, ohne anmaßend oder rechthaberisch
zu sein. Du mußt dich bemühen, dir Respekt zu 
erwerben und nie vergessen, ihn anderen zu erweisen.  

Arbeit delegieren
.................

Jetzt bist du mir hypothetisch gefolgt  
durch die frühe Programmierungphase einer 
kleinen Software, der Schaffung einer
Webseite und eines Systems zur Dokumentation,
und wir haben weitergemacht und (wie 
im Abschnitt "Freigeben deines Programms" besprochen 
werden wird) 
es freigegeben für den Rest der Welt. 
Etwas Zeit vergeht, und wenn die Dinge gut
laufen, wird es Leute geben, die Interesse zeigen 
und helfen möchten. Die Patches fangen an,
einzutreffen.    

Wie die Eltern eines Kindes, das erwachsen wird,
ist es jetzt Zeit kurz zu erschrecken, dann zu
lächeln und das zu tun, was Eltern in ihrem Leben 
am schwersten fällt: Es ist Zeit, loszulassen.    

Delegation ist die politische Art, diesen Prozeß 
des "Loslassens" zu beschreiben. Es ist der Prozeß  
der teilweisen Übergabe von Verantwortlichkeit 
und Macht über dein Projekt an andere  
verantwortliche und beteiligte Entwickler. 
Es ist schwierig  für jeden, der eine große Menge 
Zeit und Energie investiert hat in ein Projekt, 
aber es ist entscheidend für das Wachstum 
jedes freien Softwareprojektes. Eine Person 
alleine stößt irgendwann an ihre Grenzen.  
Ein freies Software-Projekt ist nichts 
ohne die Miteinbeziehung einer Gruppe von 
Entwicklern.  Eine Gruppe von Entwicklern kann 
nur aufrechterhalten werden durch respektvolle 
und verantwortliche Führung und durch Delegation.    

Sowie dein Projekt fortschreitet, wirst du  
Leute bemerken, die eine bedeutende Menge an
Zeit und Mühe in dein Projekt stecken. Diese 
Leute werden diejenigen sein, welche am meisten 
Patches einreichen, am meisten auf den Mailinglisten
posten, und sich an langen Emaildiskussionen 
beteiligen. Es gehört zu deiner Verantwortung, 
mit diesen Leuten in Verbindung treten und zu
versuchen, etwas Projekthoheit und Verantwortung, 
die du in deiner Position als Maintainer des 
Projektes hast, an sie abzugeben (wenn sie es 
wollen). Es gibt mehrere einfache Wege dies zu tun:    

Um es ein wenig wie eine Verzichtserklärung zu
formulieren: Delegation muß nicht Entscheidung
durch ein Kommitee bedeuten. In vielen 
Fällen läuft es so und dies hat sich nachweislich 
als funktionierende Variante gezeigt. In anderen 
Fällen hat diese Variante Probleme verursacht.  
"Managing Projects the Open Source Way" argumentiert
daß "Open Source-Projekte am besten laufen, wenn 
eine Person der klare Anführer des Teams ist und 
alle wichtigen Entscheidungen (Designänderungen, 
Freigabedaten,  und so weiter) trifft." Ich denke, 
daß das häufig zutrifft, würde aber darauf drängen, 
daß Entwickler die Idee berücksichtigen, daß
der Projektleiter nicht der Projektgründer sein
muß und der Release-Manager eine andere Person sein
kann als ein Hauptentwickler. Diese Situationen 
sind politisch schwierig, sei also vorsichtig und 
stelle sicher, daß es notwendig ist, bevor du 
anfängst, Leute zu bevollmächtigen. 

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.  

Patches annehmen und ablehnen
.............................

Dieses HOWTO hat bereits das Thema berührt, daß
als Maintainer eines freien Softwareprojektes
eine deiner primären und wichtigsten 
Aufgaben darin besteht, durch andere Entwickler
eingereichte Patches anzunehmen oder abzuweisen.

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):  

Zeige ihn der Community
#######################

Einer der besten Wege, um die Entscheidung, 
einen Patch abzulehnen, zu rechtfertigen, der
auch darauf hinzielt, daß du nicht den Eindruck
erweckst, dein Projekt mit eiserner Hand zu führen,
besteht darin, die Entscheidung überhaupt nicht 
allein zu treffen.  Es könnte sinnvoll sein, 
größere vorgeschlagene Änderungen oder schwierigere 
Entscheidungen an eine Entwicklungs-Mailingliste
zu delegieren, wo sie diskutiert und debattiert
werden können. Es wird einige Patches geben 
(Bugfixes etc.), die definitiv angenommen werden,
und einige, von denen du glaubst, daß sie so abwegig
sind, daß sie nicht mal eine weitere Diskussion
verdienen. Es sind diejenigen, die in die Grauezone
zwischen diesen zwei Gruppen fallen, die es vielleicht
verdienen, schnell mal andie Mailingliste weitergeleitet
zu werden.

Ich empfehle diesen Prozeß von ganzem Herzen.  
Als Projektmaintainer sorgst du dich darum, wie
die beste Entscheidung für das Projekt gefällt wird, 
für die Benutzer und die Entwickler des Projektes, 
und für dich selbst als verantwortlichen 
Projektleiter. Das Weiterleiten an eine Mailingliste
demonstriert dein eigenes Verantwortlichkeitsgefühl 
und deinen entgegenkommenden Führungsstil, weil es
die Interessen der Community deiner Software prüft
und ihnen dient.  

Fachliche Einwände sind nicht immer eine gute Rechtfertigung    
############################################################

Besonders zum Anfang des Lebens deines Projektes
wirst du auf viele Änderungen stoßen, 
die schwer zu implementieren sind, Bugs hervorrufen,
oder sonstige technische Schwierigkeiten verursachen.
Versuche, über diese hinwegzusehen. Besonders bei 
neuer Funktionalität kommen gute Ideen nicht immer 
von guten Programmierern. 
Wenn er fachlich nicht angebracht ist, ist das 
ein berechtigter Grund, um die Integration eines
Patches hinauszuschieben, aber es ist nicht immer 
ein triftiger Grund, eine Änderung völlig 
zurückzuweisen.  Selbst kleine Änderungen 
sind es wert, mit dem den Patch einreichenden
Enwickler zusammenzuarbeiten, um Bugs auszubügeln
und die Änderung zu integrieren, wenn du der
Meinung bist, daß sie eine gute Ergänzung für dein
Projekt darstellt. Dein Aufwand wird dabei helfen,
das Projekt zu einem Communityprojekt zu machen
und einen neuen oder weniger erfahrenen Entwickler 
in dein Projekt integrieren, und ihm sogar etwas
beibringen, daß ihm helfen könnte, wenn er seinen
nächsten Patch erstellt.  

Allgemeine Höflichkeit    
######################

Es sollte eigentlich nicht gesagt werden müssen, 
aber bitte, sei einfach immer höflich. Wenn
jemand eine Idee hat und sie für wichtig genug
erachtet, daß er dazu Code schreibt und einen Patch
einreicht, dann bedeutet es ihm etwas, er ist
motiviert, und bereits am Projekt beteiligt. Dein 
Ziel als Maintainer besteht darin sicherstellen, 
daß er weiter Patches einreicht.
Manchmal mag er dir einen Blindgänger geliefert
haben, aber das nächste Mail ist es vielleicht
die Idee oder das Feature, das dein Projekt
revolutioniert.    

Es liegt in deiner Verantwortung, zuerst 
deine Entscheidung, seine Änderung nicht 
zu integrieren, kurz und klar zu rechtfertigen. 
Weiterhin solltest du ihm danken. Lasse ihn wissen,
daß du seine Hilfe schätzt, und dich schlecht 
fühlst, weil du seine Änderungen nicht integrieren
kannst. Informiere ihn, daß du dich darauf freust,
daß sie sich weiterhin beteiligen, und daß du 
hoffst, daß der nächste Patch oder die nächste 
Idee besser in dein Projekt paßt, weil du 
seine Arbeit schätzt und sie in deine Anwendung 
einfließen sehen möchtest. Wenn dir je einer deiner
Patches zurückgewiesen wurde, in den du eine Menge 
Zeit, Gedanken und Energie gesteckt hast, wirst du 
dich erinnern, wie es sich anfühlt, und es fühlt
sich schlecht an. Erinnere dich daran, wenn du mal
jemanden entäuschen mußt. Es ist nie einfach, aber 
du mußt alles tun was du kannst, um es so wenig
unangenehm wie möglich zu gestalten.

Stabile Zweige und Entwicklungszweige ("branches")
..................................................

Die Idee der stabile Zweige und Entwicklungszweige
ist bereits kurz im Abschnitt "Wählen einer Methode der Versionsnumerierung" 
beschrieben worden,
sowie im Abschnitt "Verantwortung für einen ganzen Zweig delegieren." 
Diese Anrisse bezeugen bis
zu einem gewissen Grad, daß mehrere Zweige (branches)
deine Software beeinflussen.
Branches ermöglichen dir (bis zu einem gewissen Grad)
einige der Probleme mit dem Zurückweisen von 
Patches (wie im Abschnitt "Patches annehmen und ablehnen"
beschrieben) zu
vermeiden, indem sie dir erlauben, die Stabilität 
deines Projektes vorübergehend zu kompromittieren,
ohne diejenigen Benutzer zu beeinträchtigen, die 
diese Stabilität benötigen.

Die gängigste Art, dein Projekt in Branches aufzuteilen
besteht darin, einen stabilen Branch zu haben und
einen für die Entwicklung. Das ist das Modell, dem
der Linux-Kernel folgt, es wird beschrieben im 
Abschnitt "Wählen einer Methode der Versionsnumerierung." 
In diesem Modell gibt es immer
einen Branch, der stabil ist, und einen, der sich
in der Entwicklungsphase befindet. Vor jedem neuen
Release geht der Entwicklungszweig in einen 
"feature freeze" genannten Zustand über, wie im
Abschnitt "Freezing" beschrieben, wo große Änderungen
und neue Features zurückgewiesen werden, oder 
zurückgehalten werden, bis der Entwicklungskernel
freigegeben worden ist als neuer stabiler Branch
und die Hauptentwicklung auf dem Entwicklungszweig
weitergeht. Bugfixes und kleine Änderungen, die 
wahrscheinlich keine großen negativen Rückwirkungen
haben werden, werden in den stabilen und den
Entwicklungszweig integriert.
   
Das Modell von Linux liefert ein extremes Beispiel.
In vielen Projekten besteht keine Notwendigkeit,
zwei Versionen ständig verfügbar zu halten. Es kann
sinnvoll sein, zwei Versionen nur kurz vor einem
Release zu haben. Das Debian-Projekt hat in seiner
Geschichte immer eine stabile und eine instabile 
Distribution bereitgestellt, hat aber erweitert,
um die folgenden Distributionen einzubeziehen: 
Stabil, instabil, testing, experimentell, und 
(um die Releasezeit herum) eine eingefrorene 
Distribution, die nur Bugfixes integriert während 
des Übergangs von instabil zu stabil. Es gibt 
wenige Projekte, deren Größe ein System wie das 
von Debian erfordern würde, aber diese Verwendung
von Branches hilft dabei, zu zeigen, wie sie 
verwendet werden können, um eine Ausgleich zu 
schaffen zwischen konsistenter und effektiver 
Entwicklung und dem Bedürfnis, regelmäßige und 
brauchbare Releases zu erzeugen.

Beim Versuch einen Entwicklungsbaum für 
dich selbst aufzusetzen, gibt es einige nützliche 
Dinge, die du im Kopf behalten solltest:

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.

Andere Aspekte des Projektmanagements
.....................................

Es gibt noch mehr Aspekte rund um die Interaktion
mit Entwicklern in einem freien Software-Projekt,
die ich nicht in großem Detail schildern kann in
einem HOWTO dieser Größe und dieser Sichtweise. 
Bitte zögere nicht, mit mir in Verbindung zu
treten, wenn du irgendwelche entscheidenden 
Auslassungen siehst.

Andere kleinere erwähnenswerte Aspekte sind:  

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. 

Maintainen eines Projektes: Mit Benutzern interagieren    
------------------------------------------------------

Wenn du dich bis hier her vorgearbeitet hast, 
herzlichen Glückwunsch, du näherst dich dem Ende 
dieses Dokumentes.  Dieser abschließende
Abschnitt beschreibt einige der Situationen, in
denen du, in deiner Funktion als Projektmaintainer 
mit Benutzern interagieren wirst. Es bietet einige 
Vorschläge, wie diese Situationen effektiv 
gehandhabt werden könnten.    

Das Interagieren mit Benutzern ist schwierig. In 
unserer Diskussion über die Interaktion mit 
Entwicklern ist die zugrundeliegende
Annahme, daß ein Projektmaintainer in einem freiem 
Softwareprojekt sich ständig bemühen muß,
Entwickler anzuziehen und zu halten, die
leicht jederzeit gehen können.    

Benutzer in der freien Software-Community sind
anders als Entwickler und als Benutzer in der Welt 
der kommerziellen Software, und sie sollten auch
anders behandelt werden als die beiden erstgenannten
Gruppen. Einige Merkmale, wie sich die Gruppen  
erheblich unterscheiden folgen:

- Die Grenze zwischen Benutzern und Entwicklern 
  ist unscharf, in einer Art, wie es einem proprietären
  Entwicklungsmodell völlig fremd ist. Deine
  Benutzer sind häufig deine Entwickler und umgekehrt.
- In der freien Software-Welt bist du häufig die
  einzige Wahl deiner Benutzer. Weil dort ein so
  starkes Gewicht darauf liegt, daß man nicht die
  Arbeit von anderen dupliziert, und weil das 
  Element des Wettbewerbs wie beim proprietären 
  Softwaremodell abwesend ist (oder zumindest eine 
  ganz andere Form annimmt), wirst du vermutlich 
  das einzige Projekt sein, daß das tut was du tust
  (oder zumindest das einzige, das es auf diese
  Art und Weise macht). Das heißt, daß schnelles
  Reagieren deinerseits für deine Benutzer sogar 
  noch wichtiger ist als in der kommerziellen
  Softwarewelt.      

- Es scheint eine fast paradoxe Situation zu sein, 
  aber für freie Software-Projekte hat es erst mal
  weniger direkte und schwerwiegende Konsequenzen, 
  wenn sie ihre Benutzer vollkommen ignorieren. 
  Das zu tun ist auch häufig einfacher. Weil du 
  normalerweise nicht mit einem anderen Produkt 
  zu konkurrieren brauchst, stehen die Chancen gut,
  daß du nicht auf Teufel-komm'raus versuchen wirst,
  neue Features vom neuesten Programm deines
  Konkurrenten zu übernehmen. Dies bedeutet, daß 
  dein Entwicklungsprozeß sich entweder aus sich 
  selbst heraus leitet muß, oder aus einer 
  Verpflichtung gegenüber deinen Benutzern, oder 
  aus beidem.

Der Versuch, diese einzigartige Situation anzugehen
kann nur indirekt erfolgen. Entwickler und 
Maintainer müssen den Benutzern zuhören und 
versuchen, so entgegenkommend wie möglich zu sein. 
Ein solide Wissen über die oben dargestellte 
Situation ist das beste Werkzeug jedes freien 
Softwareentwicklers um seinen Entwicklungs- oder
Führungsstil so zu adaptieren, daß er zum 
einzigartigen Prozeß des freien Software-
Projektmanagements paßt.
Diese Kapitel werden versuchen, einige der 
schwierigeren oder wichtigeren Punkte einzuführen
in Interaktionen mit Benutzern eines Projekts, und 
geben dabei einige Tips, wie man diese anpackt.  

Testen und Tester
.................

Deine Benutzern sind nicht nur deine Entwickler, 
sondern auch (und möglicherweise sogar öfter) 
deine Tester. Bevor ich jetzt geflamed werde,
sollte ich  meinen Satz umformulieren: Einige 
deiner Benutzer (diejenigen, die sich ausdrücklich 
anbieten) sind deine Tester. 

Es ist wichtig, daß diese Unterscheidung von einem
frühen Zeitpunkt an gemacht wird, weil nicht alle 
deine Benutzer Tester sein wollen. Viele Benutzer 
möchten stabile Software verwenden, und es kümmert
sie nicht, wenn sie nicht die neueste, tollste 
Software mit den neueste, tollsten Features haben.
Diese Benutzer akzeptieren ein stabiles, getestetes
Stück Software ohne große/offensichtliche Bugs und 
werden sich ärgern, wenn sie sich als Tester 
erkennen. Dies ist ein weiterer Moment, wo ein
aufgeteiltes Entwicklungsmodell (wie im Abschnitt 
"Stabile Zweige und Entwicklungszweige" erwähnt) 
sich als nützlich erweist.

"Managing Projects the Open Source Way" beschreibt, 
wonach ein guter Test suchen sollte:    

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.
 
Aufbauen einer Supportinfrastruktur
...................................

Wenn Testen auch wichtig ist, fällt der Hauptteil  
deiner Interaktionen und Verantwortlichkeiten 
gebenüber deinen Benutzern unter die Kategorie 
Support. Die beste Art, um sicherzustellen, daß
deine Benutzer ausreichend Unterstützung bekommen
im Umgang mit deinem Programm besteht darin,
eine gute Infrastruktur zu diesem Zweck aufzubauen,
damit deine Entwickler und Benutzer einander helfen
und eine geringere Last bei dir landet. Auf diese 
Weise werden die Leute auch schnellere und bessere 
Antworten auf ihre Fragen bekommen. Diese 
Infrastruktur kommt in verschiedenen primären
Erscheinungsformen:  

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.  

Mach' dich erreichbar
#####################

Du kannst nicht zu wenige Varianten angeben, wie
man dich erreichen kann. Wenn du in einem IRC-
Channel herumhängst, zögere nicht, ihn in deiner
Projektdokumentation aufzuführen. Gib Email- und 
"snail mail"-Adressen an, und Möglichkeiten, dich
über ICQ, AIM oder Jabber zu erreichen, falls
es sie gibt.

Software für Bug-Management
###########################

Für viele große Software-Projekte ist der Gebrauch   
von Bugmanagementsoftware essentiell, um 
festzuhalten, welche Bugs behoben wurden, welche
nicht behoben wurden, und welche Bugs von wem gerade
behoben werden. Debian nutzt das Debian Bug Tracking System 
(BTS), wobei es wohl nicht für für jedes Projekt 
die beste Wahl sein mag (es scheint im Moment unter 
seinem eigenen Gewicht zu leiden). Das 
Mozillaprojekt hat neben einem verdammt guten 
Webbrowser ein Unterprojekt aufgemacht, aus dem
ein Bugtracker namens Bugzilla wurde, der
extrem brauchbar geworden ist und den ich sehr mag.

Diese Systeme (und andere wie sie) können so
schwerfällig sein, daß Entwickler aufpassen sollten,
daß sie nicht mehr Zeit mit Bugtracking verbringen 
als mit den Bugs und den Projekten selbst. 
Wenn ein Projekt weiter wächst, dann kann die
Nutzung eines Bugtracking-Systems einen einfachen 
standardisierten Zugang schaffen für Benutzer
und Tester, um Bugs zu melden, und für Entwickler 
und Maintainer, um sie zu beheben und auf saubere
Art und Weise über sie Buch zu führen.  

Freigeben deines Programms
..........................

Wie schon vorher im HOWTO erwähnt, ist die erste 
Regel für eine Freigabe (Release), daß du etwas
nützliches freigeben sollst. Nicht funktionierende
oder nicht nützliche Software wird deinem Projekt 
keine Anziehungskraft verleihen. Die Leute werden 
von deinem Projekt abgeschreckt und werden 
wahrscheinlich, wenn das nächste Mal eine neue 
Version verkündet wird, das nur halbherzig 
überfliegen. Halbwegs funktionierende Software, 
so sie denn nützlich ist, wird die Leute beeindrucken,  
ihren Appetit wecken für künftige Versionen, und 
sie anregen, sich dem Entwicklungsprozeß 
anzuschließen.  

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.    

Alpha-Releases
##############

Alpha-Software hat alle Features, funktioniert
aber manchmal nur teilweise.    

Von Alpha-Releases erwartet man, daß sie instabil
sind, möglicherweise ein wenig unsicher, aber 
definitiv verwendbar.  Sie können bekannte Bugs 
und Macken enthalten, die noch überarbeitet werden
müssen. Bevor du eine Alphaversion freigibst, 
erinnere dich, daß Alpha-Releases nichtsdestotrotz
Releases sind, und die Leute werden nicht erwarten,
daß sie bloß einen "nightly build" aus dem CVS
bekommen. Ein Alpha sollte funktionieren und 
ein Minimum an Tests und Bugfixing bereits absolviert
haben.

Beta-Releases        
#############

Beta-Software hat alle Features, und sie funktionieren
auch, befindet sich aber im Teststadium und hat noch
einige zu korrigierende Bugs.

Von Beta-Releases erwartet man, daß sie grundsätzlich
verwendbar und leicht instabil sind, aber 
definitiv nicht unsicher. Beta-Releases
gehen normalerweise einem vollen Release um nicht
mehr als einen Monat voraus. Sie können kleine 
bekannte Bugs enthalten aber keine schwerwiegenden.
Das wichtigste an Funktionalität sollte vollständig
implementiert sein, wenn auch die Feinheiten noch
ausgearbeitet werden. Beta-Releases sind ein
großartiges Mittel, um potentielle Benutzer auf
den Geschmack zu bringen, indem sie ihnen einen 
realistische Ausblick darauf geben, wo dein Projekt
in naher Zukunft stehen wird, und können dabei
helfen, das Interesse wach zu halten, indem sie
den Leute etwas in die Hand geben.

Entwicklungsreleases ("development releases") 
#############################################

"Entwicklungsrelease" ist eine viel schwammigere
Bezeichnung als "Alpha" oder "Beta." Ich entscheide
mich normalerweise, mir diese Bezeichnung für die
Diskussion eines Entwicklungszweigs (development 
branch) aufzuheben, wenn es auch andere Varianten
gibt, sie zu benutzen - so viele sogar, daß ich
den Eindruck habe, daß dieser Begriff verwässert
worden ist. Der populäre  Window-Manager
Enlightenment hat nichts als Entwicklungsreleases
freigegeben.  Meistens wird der Begriff verwendet, 
um Freigaben zu beschreiben, die noch nicht mal
Alpha oder Beta sind, und wenn ich eine Vor-Alpha-
Version einer Software freigeben wollte, um 
das Interesse an ihr wachzuhalten, würde ich sie
vermutlich so benennen müssen.

Dein Projekt ankündigen
.......................

Ok, du hast es getan. Du hast dein freies 
Software-Projekt (zumindest aus Sicht dieses HOWTOs) 
entworfen, gebaut und freigegeben. Alles, was 
zu tun bleibt ist, daß du die Welt da draußen 
informierst, damit sie davon wissen und kommen, 
um es auszuprobieren und hoffentlich an Bord 
des Entwicklerschiffs springen. Wenn alles in
Ordnung ist, wie oben beschrieben, wird das ein
schneller und schmerzloser Prozeß. Eine schnelle 
Ankündigung ist alles, was du brauchst, um dich
auf den Radarschirm der freie Software-Community
zu bringen.  

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.

------------

Bibliography
------------

(Anm. des Übers.: Die Bibliographie habe ich nicht
übersetzt, da sie sich ausschließlich auf englische
Quellen bezieht, sodaß man davon ausgehen kann,
das derjenige, der sich für sie interessiert auch 
gut genug Englisch kann, um die Bibliographie zu
verstehen).

Printed Books
.............

Karl Fogel, Open Source Development with
CVS, Coriolois Open Press, 1999, 1-57610-490-7.

Fogel's "guide to using CVS in the free software
world" is much more than its subtitle. In
the publisher's own words: "Open Source Development
with CVS is one of the first books available
that teaches you development and implementation
of Open Source software." It also includes
the best reference and tutorial to CVS I
have ever seen. It is the book that was so
good that it prompted me to write this HOWTO
because I thought the role it tried to serve
was so important and useful. Please check
it or buy it if you can and are seriously
interested in running a free software project.

Lawrence Lessig, Code and Other Laws of Cyberspace,
Basic Books, 2000, 0-465-03913-8.

While it only briefly talks about free software
(and does it by tiptoeing around the free
software/open source issue with the spineless
use of the term "open code" that only a lawyer
could coin), Lessig's book is brilliant.
Written by a lawyer, it talks about how regulation
on the Internet is not done with law, but
with the code itself and how the nature of
the code will determine the nature of future
freedoms. In addition to being a quick and
enjoyable read, it gives some cool history
and describes how we need free software in
a way more powerfully than anything I've
read outside of RMS's "Right to Read."

Eric Raymond, The Cathedral and the Bazaar:
Musings on Linux and Open Source by an Accidental
Revolutionary, O'Reilly, 1999, 1-56592-724-9.

Although I have to honestly say that I am
not the ESR fan that I used to be, this book
proved invaluable in getting me where I am
today. The essay that gives the book its
title does a good job of sketching the free
software process and does an an amazing job
of making an argument for free software/open
source development as a road to better software.
The rest of the book has other of ESR's articles,
which for the most part are posted on his
website. Still, it's nice thing to own in
hard copy and something that every free software/open
source hacker should read.
Web-Accessible Resources

George N Dafermos, Management and Virtual
Decentralized Networks: The Linux Project.

Since the paper includes its own abstract,
I thought I would include it here verbatim:

    This paper examines the latest of paradigms - the Virtual Network(ed) Organisation -
        and whether geographically dispersed knowledge
        workers can virtually collaborate for a project
        under no central planning. Co-ordination,
        management and the role of knowledge arise
        as the central areas of focus. The Linux
        Project and its development model are selected
        as a case of analysis and the critical success
        factors of this organisational design are
        identified. The study proceeds to the formulation
        of a framework that can be applied to all
        kinds of virtual decentralised work and concludes
        that value creation is maximized when there
        is intense interaction and uninhibited sharing
        of information between the organisation and
        the surrounding community. Therefore, the
        potential success or failure of this organisational
        paradigm depends on the degree of dedication
        and involvement by the surrounding community.

This paper was referred to me in my capacity
as author of this HOWTO and I was very impressed.
It's written by a graduate student in management
and I think it succeeds at evaluating the
Linux project as an example of a new paradigm
in management--one that you will be be placing
yourself at the center of in your capacity
as maintainer of a free software project.

As a developer trying to control an application
and guide it to success in the free software
world, I'm not sure how useful Dafermos's
argument is. It does however, provide a theoretical
justification for my HOWTO--free software
project management is a different creature
than proprietary software project management.
If you are interested in the conceptual and
theoretical ways that free software project
management differs from other types of management,
this is a great paper to read. If this paper
answers questions of "how?", Dafermos answers
the (more difficult to defend) questions
of "why?" and does a very good job.

Richard Gabriel, The Rise of "Worse is Better".

A well written article although I think the
title may have confused as many people as
the rest of the essay helped. It offers a
good description of how to design programs
that will succeed and stay maintainable as
they grow.

Montey Manley, Managing Projects the Open
Source Way, Linux Programming, Oct 31, 2000.

In one of the better articles on the subject
that I've read, Monty sums up some of the
major points I touch on including: starting
a project, testing, documentation, organizing
a team and leadership, and several other
topics. While more opinionated that I try
to be, I think its an important article that
I found very helpful in writing this HOWTO.
I've tried to cite him in the places where
I borrowed from him most.

I have problems much of this piece and I
recommend you read [KRAWITZ] at the same
time you read Monty's article for a good
critique.

Eric Steven Raymond, Software Release Practice
HOWTO.

At first glance, ESR's release practice HOWTO
seems to share a lot of terrain with this
document. Upon closer examination, the differences
become apparent but they are closely related.
His document, read in conjunction with mine,
will give a reader a good picture of how
to go about managing a project. ESR's HOWTO
goes into a bit more detail on how to write
and what languages to write in. He tends
to give more specific instructions and checklists
("name this file this, not this") while this
HOWTO speaks more conceptually. There are
several sections that are extremely similar.
It's also much shorter.

My favorite quote from his HOWTO is: ""Managing
a project well when all the participants
are volunteers presents some unique challenges.
This is too large a topic to cover in a HOWTO."
Oh really? Perhaps I just do a poor job.

Vivek Venugopalan, CVS Best Practices.

Venugopalan provides one of the best essays
on effective use of CVS that I've come across.
It is written for people who already have
a good knowledge of CVS. In the chapter on
branching, he describes when and how to branch
but gives no information on what CVS commands
you should use to do this. This is fine (technical
CVS HOWTO have been written) but CVS newbies
will want to spend some time with Fogel's
reference before they will find this one
very useful.

Venugopalan creates checklists of things
to do before, after, and around releases.
It's definitely worth a read through as most
of his ideas will save tons of developer
head aches over any longer period of time.
Advogato Articles

Stephen Hindle, 'Best Practices' for Open
Source?, Advogato, March 21, 2001.

Touching mostly on programming practice (as
most articles on the subject usually do),
the article talks a little about project
management ("Use it!") and a bit about communication
within a free software project.

Bram Cohen, http://www.advogato.org/article/258.htmlHow
to Write Maintainable Code, Advogato, March
15, 2001.

This article touches upon the "writing maintainable
code" discussion that I try hard to avoid
in my HOWTO. It's one of the better (and
most diplomatic) articles on the subject
that I've found.

Robert Krawitz, Free Source Project Management,
Advogato, November 4, 2000.

This article made me happy because it challenged
many of the problems that I had with Monty's
article on LinuxProgramming. The author argues
that Monty calls simply for the application
of old (proprietary software) project management
techniques in free software projects instead
of working to come up with something new.
I found his article to be extremely well
thought out and I think it's an essential
read for any free software project manager.

Lalo Martins, Ask the Advogatos: why do Free
Software projects fail?, Advogato, July 20,
2000.

While the article is little more than a question,
reading the answers to this question offered
by Advogato's readers can help. In a lot
of ways, this HOWTO acts as my answer to
the questions posed in this article but there
are others, many of which might take issue
with whats is in this HOWTO. It's worth checking
out.

David Burley, In-Roads to Free Software Development,
Advogato, June 14, 2000.

This document was written as a response to
another Advogato article. Although not about
running a project, this describes some of
the ways that you can get started with free
software development without starting a project.
I think this is an important article. If
you are interested in becoming involved with
free software, this article showcases some
of the ways that you can do this without
actually starting a project (something that
I hope this HOWTO has demonstrated is not
to be taken lightly).

Jacob Moorman, Importance of Non-Developer
Supporters in Free Software, , Advogato,
April 16, 2000.

Moorman's is a short article but it brings
up some good points. The comment reminding
developers to thank their testers and end-users
is invaluable and oft-forgotten.

Leslie Orchard, On Naming an Open Source
Project, Advogato, April 12, 2000.

I didn't even have a section on project naming
in this HOWTO (See the Section called Naming
your project in "Free Software Project Management
HOWTO") until Leslie Orchard's article reminded
me of it. Thanks to Leslie for writing this
article!

David Allen, Version Numbering Madness, Advogato,
February 28, 2000.

In this article, David Allen challenges the
whole "Major.Minor.Patch" version numbering
scheme. Its good to read this as you read
the Section called Choosing a Method of Version
Numbering in "Free Software Project Management
HOWTO". I liked the article and it describes
some of the projects that I bring up in my
discussion of version numbering.

------------

A. GNU Free Documentation License
---------------------------------

(Anm. des Übers.: Hier habe ich die Übersetzung
von Hugo Giese
angefügt, zu finden unter http://www.giese-online.de/gnufdl-de.html)

This is an unofficial translation of the
GNU Free Documentation License into German.
It was not published by the Free Software
Foundation, and does not legally state the
distribution terms for documentation that
uses the GNU FDL--only the original English
text of the GNU FDL does that. However, we
hope that this translation will help German
speakers understand the GNU FDL better.

Dies ist eine inoffzielle deutsche Übersetzung
der GNU Free Documentation License. Sie ist
nicht von der Free Software Foundation herausgegeben
und erläutert nicht die Bedingungen der GNU
FDL -- Dies tut nur der original englische
Text der GNU FDL. Dennoch hoffen wir, dass
diese Übersetzung mit dazu beiträgt deutschsprachigen
Personen das Verstehen der GNU FDL zu erleichtern.
Präambel
Der Zweck dieser Lizenz ist es, ein Handbuch,
Lehrbuch oder ein anderes zweckdienliches
und nützliches Dokument frei, im Sinne von
Freiheit, zu machen; jedermann die Freiheit
zu sichern, es zu kopieren und mit oder ohne
Änderungen daran, sowohl kommerziell als
auch nicht kommerziell weiter zu verbreiten.
Weiterhin sichert diese Lizenz einem Autor
oder Verleger die Möglichkeit, Anerkennung
für seine Arbeit zu erhalten ohne für Änderungen
durch Andere verantwortlich gemacht zu werden.

Diese Lizenz ist eine Art des "copyleft",
was bedeutet, daß von diesem Dokument abgeleitete
Werke ihrerseits in derselben Weise frei
sein müssen.
Dies vervollständigt die GNU General Public
License, die eine "copyleft"-Lizenz ist,
und für freie Software entworfen wurde.

Diese Lizenz wurde für Handbücher für freie
Software entworfen, denn freie Software braucht
freie Dokumentation: Ein freies Programm
sollte von Handbüchern begleitet sein, die
dieselben Freiheiten bieten, die auch die
Software selbst bietet.
Diese Lizenz ist aber nicht auf Softwarehandbücher
beschränkt; vielmehr kann sie für jede Art
von textuellen Werken verwendet werden, unabhängig
davon, was das Thema ist, oder ob es als
gedrucktes Buch veröffentlicht wurde. Wir
empfehlen diese Lizenz prinzipiell für Werke,
die als Anleitungen oder Referenzen dienen
sollen.

1. Anwendbarkeit und Definitionen
.................................

Diese Lizenz findet Anwendung auf jedes Handbuch
oder andere Werk, unabhängig von dem Medium,
auf dem es erscheint, das einen vom Rechteinhaber
eingefügten Hinweis enthält, der besagt,
daß das Werk unter den Bedingungen dieser
Lizenz verbreitet werden darf.
Ein solcher Hinweis gewährt eine weltweit
gültige, tantiemenfreie und zeitlich unbefristete
Lizenz, die es gestattet das Werk, unter
den hier festgelegten Bedingungen, zu nutzen.
Der Begriff Dokument wird im Folgenden für
alle solche Handbücher und Werke verwendet.
Jede Person kann Lizenznehmer sein und wird
im Folgenden mit Sie angesprochen.
Sie akzeptieren diese Lizenz, wenn Sie ein
Dokument derart kopieren, verändern oder
verteilen, daß Sie gemäß den Gesetzen zum
Copyright die Erlaubnis benötigen.

Eine modifizierte Version des Dokumentes
steht für jedes Werk, das das Dokument als
Ganzes oder in Teilen enthält, sowohl auf
Datenträger kopiert, als auch mit Änderungen
und/oder in andere Sprachen übersetzt.

Ein zweitrangiger Abschnitt ist ein benannter
Anhang oder eine Enleitung des Dokumentes,
der sich ausschließlich mit dem Verhältnis
des Autors oder Verlegers des Dokumentes
zu dem eigentlichen Thema des Dokumentes
(oder damit zusammenhängender Dinge) beschäftigt,
und der nichts enthält, das direkt zu dem
eigentlichen Thema gehört. (Wenn das Dokument
beispielweise ein Buch über Mathematik ist,
dann darf ein zweitrangiger Abschnitt nichts
über Mathematik enthalten).
Dies kann eine historische Beziehung zu dem
Thema, oder damit zusammenhängender Dinge,
oder von gesetzlicher, gesellschaftlicher,
philosophischer, ethischer oder politischer
Art sein, die das Thema betreffen.

Die unveränderlichen Abschnitte sind benannte
zweitrangige Abschnitte, deren Titel als
unveränderlicher Abschnitt in dem Lizenhinweis,
der das Dokument unter diese Lizenz stellt,
aufgeführt sind.
Wenn ein Abschnitt nicht in die oben stehende
Definition eines zweitrangigen Abschnittes
passt, dann ist es nicht erlaubt diesen Bereich
als unveränderlichen Bereich zu kennzeichnen.

Umschlagtexte sind bestimmte, kurze Textstücke,
die als vorderer Umschlagtext oder als hinterer
Umschlagtext in der Notiz benannt werden,
die besagt, dass das Dokument unter dieser
Lizenz freigegeben ist.
Ein vorderer Umschlagtext kann bis zu 5 Worte
enthalten, ein hinterer Umschlagtext bis
zu 25 Worte.

Eine transparente Kopie des Dokumentes bezeichnet
eine maschinenlesbare Kopie, dargestellt
in einem Format, dessen Spezifikationen allgemein
verfügbar sind, und das geeignet ist das
Dokument auf einfache Weise mit einem allgemeinen
Texteditor oder (für Bilder, die aus Pixeln
bestehen) mit einem allgemeinen Bildberabeitungsprogramm
oder (für Zeichnungen) mit einem häufig verfügbaren
Zeichenprogramm zu überarbeiten, und das
geeignet ist es als Eingabe für Textformatierer
zu verwenden, oder als Eingabe für automatische
Konvertierungsprogramme, die eine Reihe von
unterschiedlichen Formaten erzeugen, die
ihrerseits als Eingabe für Textformatierer
verwendet werden können. Eine Kopie in ein
anderes transparentes Dateiformat dessen
Auszeichnung oder das fehlen der Auszeichnungen
derart beschaffen sind, nachfolgende Modifikationen
durch die Leser zu verhindern oder zu erschweren
ist nicht transparent.
Ein Bildformat ist nicht transparent, wenn
es für eine wesentliche Menge von Text verwendet
wird.
Eine Kopie, die nicht transparent ist, wird
als opak bezeichnet.

Beispiele verwendbarer Formate für transparente
Kopien schliessen einfachen ASCII-Text ohne
Auszeichnungen, TeX-info Eingabe, LaTeX-Eingabeformat,
SGML oder XML, sofern die verwendete DTD
öffentlich verfügbar ist, sowie standardkonformes,
einfaches HTML, Postscript oder PDF, die
für Veränderungen durch Menschen entworfen
sind, ein.

Beispiele für transparente Bildformate sind
u.a. PNG, XCF und JPG.
Opake Formate sind unter anderen solche proprietären
Formate, die nur von proprietären Textverarbeitungsprogramm
gelesen und bearbeitet werden können, SGML
oder XML deren DTD und/oder Verarbeitungswerkzeuge
nicht allgemein verfügbar sind, und maschinengeneriertes
HTML, PostScript oder PDF, das von manchen
Textverarbeitungsprogrammen nur zu Ausgabezwecken
erzeugt wird.

Mit Titelseite wird in einem gedruckten Buch
die eigentliche Titelseite sowie die direkt
darauf folgenden Seiten bezeichnet, die all
das in lesbarer Form enthalten, was in dieser
Lizenz gefordert ist, dass es auf der Titelseite
erscheinen muss.
Für Werke, die in Formaten vorliegen, die
keine Titelseiten haben, gilt als Titelseite
der Text, der der auffälligsten Darstellung
des Titels des Werkes direkt folgt, aber
noch vor dem Inhalt des Werkes steht.

Ein Abschnitt mit dem Titel xyz bezeichnet
einen benannten Unterbereich des Dokumentes,
dessen Titel entweder genau xyz ist, oder
der xyz in Anführungszeichen enthält, der
einem Text folgt, der xyz in eine andere
Sprache übersetzt. (Hier steht xyz für einen
speziellen Abschnittsnamen, der im Folgenden
erwähnt wird wie"Danksagung"(Acknowledgements),
"Widmung"(Dedications), "Anmerkung"(Endorsement)
oder "Historie"(History).).
Den Titel erhalten eines Abschnittes bedeutet,
daß beim Modifizieren des Dokumentes dieser
Abschnitt mit dem Titel xyz bleibt, wie es
in dieser Definition festgelegt ist.

Das Dokument kann direkt hinter der Notiz,
die besagt, dass das Dokument unter dieser
Lizenz freigegeben ist, Garantieausschlüsse
enthalten. Diese Garantieausschlüsse werden
so behandelt, als seien sie als Referenzen
in diese Lizenz eingeschlossen, allerdings
nur um Garantien auszuschliessen: Jede andere
Implizierung, die dieser Ausschluss hat ist
ungültig und keine Wirkung im Sinne dieser
Lizenz.

2. Datenträgerkopien
....................

Sie dürfen das Dokument auf jedem Medium
sowohl kommerziell als auch nicht kommerziell
kopieren und verbreiten, vorausgesetzt, daß
diese Lizenz, die Copyright-Hinweise sowie
der Lizenzhinweis, der besagt, daß diese
Lizenz auf das Dokument anzuwenden ist, in
allen Kopien reproduziert wird, und daß keine
weiteren Bedingungen jeglicher Art zu denen
dieser Lizenz hinzugefügt werden.
Sie dürfen in den Kopien, die Sie erstellen
oder verbreiten, keinerlei technische Maßnahmen
treffen um das Lesen oder das weitere Kopieren
zu erschweren oder zu kontrollieren. Dennoch
dürfen Sie Gegenleistungen für Kopien akzeptieren.
Wenn Sie eine ausreichend große Menge von
Kopien verteilen, müssen Sie zusätzlich die
bestimmungen von Ziffer 3 beachten.
Sie können ausserdem unter denselben Bedingungen,
die oben angeführt sind, Kopien verleihen
und sie können Kopien auch öffentlich bewerben.

3. Kopien in Stückzahlen
........................

Wenn Sie gedruckte Kopien des Dokumentes
(oder Kopien auf Medien, die üblicherweise
gedruckte Umschläge haben), in einer Stückzahl
von mehr als 100 veröffentlichen, und der
Lizenzhinweis des Dokumentes Umschlagtexte
verlangt, müssen die Kopien in Hüllen verpackt
sein, die alle diese Umschlagtexte klar und
lesbar enthalten. Die vorderen Umschlagtexte
auf dem vorderen Umschlag, die hinteren Umschlagtexte
auf dem hinteren Umschlag.
Beide Umschläge müssen Sie ausserdem klar
und lesbar als den Herausgeber dieser Kopien
benennen.
Der vordere Umschlag muss den gesamten Titel
darstellen, mit allen Worten gleich auffällig
und sichtbar. Sie können weiteres Material
den Umschlägen hinzufügen.
Das Kopieren mit Änderungen, die auf Umschläge
begrenzt sind, können, so lange der Titel
des Dokuments erhalten bleibt, ansonsten
als Datenträgerkopien behandelt werden.

Wenn der vorgeschriebene Text für einen der
Umschläge zu umfangreich ist um lesbar zu
bleiben, sollten Sie den ersten der aufgelisteten
Texte auf den aktuellen Umschlag nehmen (so
viel wie vernünftigerweise möglich ist) und
den Rest auf direkt angrenzenden Seiten.

Wenn Sie mehr als 100 opake Kopien veröffentlichen
oder verbreiten, müssen Sie entweder eine
maschinenlesbare, transparente Kopie jeder
opaken Kopie beilegen, oder mit bzw. in jeder
opaken Kopie eine Computer-Netzwerk Adresse
angeben, von wo die allgemeine, netzwerk
benutzende Öffentlichkeit, Zugriff zum Download
einer kompletten transparenten Kopie über
öffentliche Standardnetzwerkprotokolle hat.

Wenn Sie sich für die letztere Möglichkeit
entscheiden, müssen Sie mit Beginn der Verbreitung
der opaken Kopien in Stückzahlen, zumutbare
und vernünftige Schritte unternehmen, um
sicher zu stellen, daß die transparenten
Kopien mindestens ein Jahr nach der Auslieferung
der letzten opaken Kopie (direkt oder über
einen Agenten oder Händler) dieser Ausgabe
an die Öffentlichkeit, an der genannten Adresse
verfügbar bleiben.

Es ist erbeten, aber nicht gefordert, daß
Sie ausreichend lange vor der Auslieferung
einer grösseren Menge von Kopien, Kontakt
mit den Autoren des Dokumentes aufnehmen,
um jenen die Möglichkeit zu geben, Ihnen
eine aktualisierte Version des Dokumentes
zuzuleiten.

4. Modifikationen
.................

Unter den obigen Bedingungen unter Ziffer
2 und 3 können Sie modifizierte Versionen
kopieren und verbreiten, vorausgesetzt, daß
Sie die modifizierte Version unter exakt
dieser Lizenz herausgeben, wobei die modifizierte
Version die Rolle des Dokumentes einnimmt,
und dadurch die weitere Modifikation und
Verbreitung an jeden Lizensieren, der eine
Kopie davon besitzt.
Zusätzlich müssen Sie die folgenden Dinge
in der modifizierten Version beachten:

1. Benutzen Sie auf der Titelseite (und
   auf Umschlägen, sofern vorhanden) einen Titel,
   der sich von dem Titel des Dokumentes und
   von früheren Versionen unterscheidet. (Die
   früheren Versionen sollten, wenn es welche
   gibt, in dem Abschnitt Historie aufgelistet
   werden.)
   
   Sie können denselben Titel wie den
   einer Vorgängerversion verwenden, wenn der
   ursprüngliche Herausgeber damit einverstanden
   ist.
2. Geben Sie auf der Titelseite eine oder
   mehrere Personen oder Einheiten, die als
   Autoren auftreten können, als für die Modifikationen
   verantwortliche Autoren der modifizierten
   Version, zusammen mit mindestens fünf der
   ursprünglichen Autoren der Ursprungsversion
   an (alle vorherige Autoren, wenn es weniger
   als fünf sind), es sei denn diese befreien
   Sie von dieser Notwendigkeit.
3. Geben Sie auf der Titelseite den Namen
   des Herausgebers als Herausgeber an.
4. Erhalten Sie alle Copyright-Vermerke des Dokumentes.
5. Setzen Sie einen passenden Copyright-Vermerk
   für Ihre Modifikationen direkt hinter die
   anderen Copyright-Vermerke.
6. Schliessen Sie direkt hinter den Copyright-Vermerken
   einen Lizenzhinweis ein, der die öffentliche
   Erlaubnis erteilt, die modifizierte Version
   unter den Bedingungen dieser Lizenz zu benutzen,
   wie es im Anhang weiter unten beschrieben
   ist.
7. Erhalten Sie im Copyright-Vermerk die
   komplette Liste der unveränderlichen Abschnitte
   und obligatorischen Umschlagtexte, die in
   dem Lizenzvermerk des Dokumentes aufgeführt
   sind.
8. Schliessen Sie eine unveränderte Kopie
   dieser Lizenz mit ein.
9. Erhalten Sie den Abschnitt "Historie".
   Erhalten Sie den Titel und fügen Sie einen
   Punkt hinzu der mindestens den Titel, das
   Jahr, die neuen Autoren und Herausgeber,
   wie sie auf der Titelseite aufgeführt sind,
   enthält. Sollte es keinen Abschnitt Historie
   geben, dann erstellen Sie einen, der Titel,
   Jahr, Autor und Herausgeber des Dokumentes,
   wie auf der Titelseite angegeben, enthält
   und fügen Sie einen Punkt hinzu, der die
   modifizierte Version wie oben dargestellt
   beschreibt.
10. Erhalten Sie die Netzwerkadresse, die
    angegeben wurde, um Zugang zu einer transparenten
    Kopie zu gewähren, sowie entsprechend angegebene
    Adressen früherer Versionen, auf denen das
    Dokument aufbaute. Diese Angaben können in
    den Abschnitt Historie verschoben werden.
    Sie können die Netzwerkadresse weglassen,
    wenn sie sich auf ein Werk bezieht, das mindestens
    4 Jahre vor dem Dokument selbst veröffentlicht
    wurde, oder wenn der ursprüngliche Herausgeber
    der Version, auf die sich die Adresse bezieht,
    seine Erlaubnis erteilt.
11. Erhalten Sie für alle Abschnitt, die
    als Danksagungen(Acknowledgements) oder Widmungen(Dedications)
    überschrieben sind, den Titel sowie die Substanz
    und den Ton aller vom Geber gemachten Danksagungen
    und/oder Widmungen in diesem Abschnitt.
12. Erhalten Sie alle unveränderlichen
    Abschnitte unverändert, sowohl im Titel als
    auch im Text. Abschnittsnummern oder dergleichen
    gelten hierbei nicht als Teil des Titels.
13. Löschen Sie alle Abschnitte, die als
    Anmerkungen(Endorsements) überschrieben sind.
    Ein solchen Abschnitt sollte nicht in der
    modifizierten Version enthalten sein.
14. Benennen Sie keinen Abschnitt in Anmerkungen
    um, oder in einen Namen, der in Konflikt
    mit einem unveränderlichen Abschnitt gerät.
15. Erhalten Sie alle Garantieausschlüsse.

Wenn die modifizierte Version neue Vorspannabschnitte
oder Anhänge enthält, die zweitrangige Abschnitte
sein können, und die kein vom Dokument kopiertes
Material enthalten, können Sie, nach Ihrem
Belieben, einige oder alle diese Abschnitte
als unveränderliche Abschnitte in die Lizenzanmerkung
der modifizierten Version aufnehmen. Diese
Titel müssen sich von allen anderen Titeln
unterscheiden.

Sie können einen Abschnitt Anmerkungen anfügen,
sofern dieser nichts als Bemerkungen, verschiedener
Stellen, zu der modifizierten Version enthält.
Beispielsweise Publikumsreaktionen oder eine
Mitteilung, daß der Text von einer Organisation
als maßgebliche Definition eines Standards
geprüft wurde.

Sie können einen Teil mit bis zu fünf Worten
als vorderen Umschlagtext und einen mit bis
zu 25 Worten als hinteren Umschlagtext an
das Ende der Liste mit den Umschlagtexten
der modifizierten Version hinzufügen.
Nur je ein Teil für den vorderen Umschlagtext
und den hinteren Umschlagtext können von
jeder Einheit hinzugefügt (oder durch entsprechende
Anordnung erstellt) werden.

Wenn das Dokument bereits einen Umschlagtext
für denselben Umschlag enthält, das von Ihnen
oder der Einheit, in deren Namen Sie tätig
sind, bereits früher eingefügt wurde, dürfen
Sie keine neue hinzufügen. Sie können aber
den alten ersetzen, wenn sie die ausdrückliche
Genehmigung des Herausgebers haben, der den
früheren Text eingefügt hat.

Der/die Autor(en) und Herausgeber des Dokumentes
geben duch diese Lizenz weder implizit noch
explizit die Erlaubnis ihren Namen für Werbung
in den Anmerkungen der modifizierten Version
zu benutzen.

5. Dokumente Kombinieren
........................

Sie können mehrere Dokumente, die unter dieser
Lizenz freigegeben sind, unter den Bedingungen
unter Ziffer 4 für modifizierte Versionen
miteinander kombinieren, vorausgesetzt, daß
in der Kombination alle unveränderlichen
Abschnitte aller Originaldokumente, enthalten
sind, und daß Sie diese alle in der Liste
der unveränderlichen Abschnitte der Lizenzanmerkung
des kombinierten Dokumentes aufführen, sowie
alle Garantieausschlüsse erhalten.

Das kombinierte Werk braucht nur eine Kopie
dieser Lizenz zu enthalten, und mehrere identische
unveränderliche Abschnitte können durch eine
einzelne Kopie ersetzt werden.
Wenn es mehrere unveränderliche Abschnitte
mit unterschiedlichem Inhalt aber gleichem
Namen gibt, machen Sie den Namen eindeutig,
indem Sie am Ende des Titels, in Anführungszeichen,
den Namen des original Autors oder Herausgebers,
falls bekannt, oder andernfalls eine eindeutige
Nummer anhängen.
Machen Sie dasselbe mit den Titeln der Abschnitte
in der Liste der unveränderlichen Abschnitte
im Lizenzhinweis des kombinierten Werkes.

In der Kombination müssen Sie alle Abschnitte
mit dem Titel Historie in den unterschiedlichen
Dokumenten zu einem einzelnen Abschnit Historie
zusammenführen; entsprechend verfahren Sie
mit den Abschnitten Danksagungen und Widmungen.
Sie müssen alle Abschnitte mit dem Titel
Anmerkungen löschen.

6. Sammlungen von Dokumenten
............................

Sie können eine Sammlung von Dokumenten erstellen,
bestehend aus diesem Dokument und weiteren,
unter dieser Lizenz stehenden Dokumenten,
wobei Sie die einzelnen Kopien dieser Lizenz
in den verschiedenen Dokumenten durch eine
einzelne Kopie, die in der Sammlung enthalten
ist, ersetzen, vorausgesetzt, Sie befolgen
in allen andern Punkten, für jedes der Dokumente,
die Regeln für Datenträgerkopien.

Sie können ein einzelnes Dokument aus einer
solchen Sammlung herausziehen und einzeln
unter dieser Lizenz verbreiten, vorausgesetzt,
Sie fügen eine Kopie dieser Lizenz in das
extrahierte Dokument ein, und befolgen ansonsten
die Bedingungen dieser Lizenz für Datenträgerkopien.

7. Aggregation mit unabhängigen Werken
......................................

Eine Zusammenstellung des Werkes, oder von
Ableitungen davon, mit anderen, separaten
und unabhängigen Dokumenten oder Werken,
in oder auf demselben Band eines Speicher-
oder Verbreitungsmediums, wird dann eine
Aggregation genannt, wenn die Copyrights
der Zusammenstellung nicht dazu verwendet
werden die Rechte der Benutzer, die für die
einzelnen Werke gewährt werden, stärker zu
beschränken als dies durch die Lizenzen der
einzelnen Werke geschieht.
Wenn das Werk in einer Aggregation vorhanden
ist, so gilt diese Lizenz nicht für die anderen
Werke dieser Aggregation, die keine Ableitung
des Dokumentes sind.

Wenn die Bestimmungen für die Umschlagtexte
aus Ziffer 3 Anwendung finden, und wenn das
Dokument weniger als die Hälfte der gesammten
Aggregation ausmacht, dann können die Umschlagtexte
auf Seiten gesetzt werden, die das Dokument
innerhalb der Aggregation umschliessen, oder
auf das elektronische Äquivalent eines Umschlages,
wenn das Dokument in elektronischer Form
vorliegt.
Andernfalls müssen sie auf gedruckten Umschlägen
erscheinen, die das gesamte Werk umschliessen.

8. Übersetzung
..............

Übersetzungen werden als eine Art von Modifikationen
betrachtet. Damit können Sie eine Übersetzung
des Dokumentes unter den Bestimmungen von
Ziffer 4 verbreiten.
Um die unveränderlichen Abschnitte durch
eine Übersetzung zu ersetzen, benötigen Sie
die spezielle Erlaubnis des Copyright-Inhabers.
Sie können allerdings Übersetzungen von einigen
oder allen unveränderlichen Abschnitten zu
den original Versionen der unveränderlichen
Abschnitte hinzufügen.
Sie können eine Übersetzung dieser Lizenz
und allen Lizenzhinweisen im Dokument sowie
allen Garantieausschlüssen hinzufügen, vorausgesetzt,
daß Sie ebenso die originale englische Version
dieser Lizenz und aller Hinweise und Ausschlüsse
beifügen.
Sollten die Übersetzung und die Originalversion
dieser Lizenz oder eines Hinweises oder Ausschlusses
voneinander abweichen, so hat die Originalversion
vorrang.

Wenn ein Abschnitt des Dokumentes als Danksagung,
Widmungen oder Historie überschrieben ist,
so erfordert die Forderung (Ziffer 4) den
Titel dieses Abschnittes zuerhalten, die
Änderung des aktuellen Titels.

9. Abschlussbestimmungen
........................

Sie dürfen dieses Dokument nicht kopieren,
verändern, unterlizensieren oder verteilen
mit der Ausnahme, daß Sie es ausdrücklich
unter dieser Lizenz tun.
Jedweder andere Versuch zu kopieren, zu modifizieren,
unter zu lizensieren oder zu verbreiten ist
unzulässig und führt automatisch zum Entzug
der durch diese Lizenz gewährten Rechte.
Dennoch verlieren jene Parteien, die von
ihnen Kopien oder Rechte unter dieser Lizen
erhalten haben, nicht Ihre Rechte, so lange
sie sich in völliger Übereinstimmung mit
der Lizenz befinden.

10. Spätere Überarbeitungen dieser Lizenz
.........................................

Die Free Software Foundation kann von Zeit
zu Zeit neue, überarbeitete Versionen der
GNU Free Dokumentation License veröffentlichen.
Diese neuen Versionen werden im Geiste gleich
bleiben, können sich aber in Details unterscheiden
um neuen Problemen oder Besorgnissen gerecht
zu werden.

Siehe: http://www.gnu.org/copyleft/

Jede Version dieser Lizenz erhält eine eigene
Versionsnummer.
Wenn das Dokument bestimmt, daß eine bestimmt
numerierte Version oder jede spätere Version
dafür gilt, haben Sie die Wahl den Bestimmungen
dieser speziell benannten Version zu folgen,
oder jeder Version, die später von der Free
Software Foundation, nicht als Entwurf, veröffentlicht
wurde.
Anhang:
Wie Sie diese Lizenz für Ihre Dokumente verwenden
können
Um diese Lizenz in einem Dokument zu verwenden,
das sie selbst geschrieben haben, schliessen
Sie eine Kopie dieser Lizenz (eine englische
Kopie des Originals anm. des Übersetzers)
in Ihr Dokument mit ein, und setzen Sie den
folgenden Copyright- und Lizenzhinweis gleich
hinter die Titelseite:

Copyright (c) YEAR YOUR NAME
Permission is granted to copy, distribute
and/or modify this document under the terms
of the GNU Free Documentation License, Version
1.2 or any later version published by the
Free Software Foundation;
with no Invariant Sections, no Front-Cover
Texts, and no Back-Cover Texts.
A copy of the license is included in the
section entitled "GNU Free Documentation
License".

Es folgt eine Übersetzung des oben stehenden
Hinweises, der nur zur Klarheit hier angegeben
ist ! (anm.: des Übersetzers)
Copyright Jahr Ihr Name
Kopieren, Verbreiten und/oder Modifizieren
ist unter den Bedingungen der
GNU Free Documentation License, Version 1.2
oder einer späteren Version, veröffentlicht
von der Free Software Foundation, erlaubt.
Es gibt keine unveränderlichen Abschnitte,
keinen vorderen Umschlagtext und keinen hinteren
Umschlagtext
Eine Kopie des Lizenztextes ist unter dem
Titel
GNU Free Documentation License enthalten.
(Ende der Übersetzung des Lizenzhinweistextes)

Wenn Sie unveränderlichen Abschnitte, vordere
und hintere Umschlagtexte haben, ersetzen
Sie die Zeile: "Es gibt keine...... Umschlagtext"
durch die Folgende:
Mit den unveränderlichen Abschnitten:
Liste dem den Titeln der unveränderlichen
Abschnitte
mit dem vorderen Umschlagtext:
vorderer Umschlagtext
und dem hinteren Umschlagtext:
hinterer Umschlagtext

Wenn Sie unveränderliche Abschnitte, aber
keine Umschlagtexte oder irgend eine andere
Kombination der drei Bereiche haben, mischen
Sie die verschiedenen Alternativen, daß sie
zu Ihren Anforderungen passen.

Wenn Ihr Dokument nicht-triviale Codebeispiele
enthält empfehlen wir diese Beispiele parallel
unter einer freien Softwarelizenz Ihrer Wahl,
beispielsweise der GNU General Public License
zu lizensieren, 
um ihren Gebrauch in freier Software zu erlauben.