]> projects.mako.cc - fspm_howto/commitdiff
moved the makefile and added german translation
authorBenjamin Mako Hill <mako@atdot.cc>
Tue, 22 Dec 2009 23:48:33 +0000 (18:48 -0500)
committerBenjamin Mako Hill <mako@atdot.cc>
Wed, 23 Dec 2009 00:20:29 +0000 (19:20 -0500)
FreeSoftwareProjectManagementHOWTO.DE.rst [new file with mode: 0644]
Makefile [moved from render_sgml with 80% similarity, mode: 0644]

diff --git a/FreeSoftwareProjectManagementHOWTO.DE.rst b/FreeSoftwareProjectManagementHOWTO.DE.rst
new file mode 100644 (file)
index 0000000..7df54fd
--- /dev/null
@@ -0,0 +1,3701 @@
+********************************************
+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.
old mode 100755 (executable)
new mode 100644 (file)
similarity index 80%
rename from render_sgml
rename to Makefile
index ca55b21..f5e67a7
+++ b/Makefile
@@ -6,6 +6,7 @@ build:
        sgmltools -v --backend=ps FreeSoftwareProjectManagementHOWTO.sgml
        ps2pdf FreeSoftwareProjectManagementHOWTO.ps
        sgmltools -v --backend=rtf FreeSoftwareProjectManagementHOWTO.sgml
        sgmltools -v --backend=ps FreeSoftwareProjectManagementHOWTO.sgml
        ps2pdf FreeSoftwareProjectManagementHOWTO.ps
        sgmltools -v --backend=rtf FreeSoftwareProjectManagementHOWTO.sgml
+       rst2html FreeSoftwareProjectManagementHOWTO.DE.rst FreeSoftwareProjectManagementHOWTO.DE.html
 
 move:
        mkdir -p ./tmp
 
 move:
        mkdir -p ./tmp
@@ -22,6 +23,7 @@ move:
 install: build move
 
 clean:
 install: build move
 
 clean:
-       rm -rf FreeSoftwareProjectManagementHOwTO
-       rm -f FreeSoftwareProjectManagementHOWTO.html FreeSoftwareProjectManagement-HOWTO.txt FreeSoftwareProjectManagement-HOWTO.ps FreeSoftwareProjectManagement-HOWTO.pdf FreeSoftwareProjectManagement-HOWTO.rtf
-       rm -rf ./tmp
\ No newline at end of file
+       rm -rf FreeSoftwareProjectManagementHOWTO
+       rm -f FreeSoftwareProjectManagementHOWTO.html FreeSoftwareProjectManagementHOWTO.txt FreeSoftwareProjectManagementHOWTO.ps FreeSoftwareProjectManagementHOWTO.pdf FreeSoftwareProjectManagementHOWTO.rtf
+       rm -rf ./tmp
+       rm FreeSoftwareProjectManagementHOWTO.DE.html

Benjamin Mako Hill || Want to submit a patch?