--- /dev/null
+********************************************
+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.
projects / fspm_howto / commitdiff