From: Benjamin Mako Hill Date: Tue, 22 Dec 2009 23:48:33 +0000 (-0500) Subject: moved the makefile and added german translation X-Git-Url: https://projects.mako.cc/source/fspm_howto/commitdiff_plain/6780791d4498fe936a123ef4f0e65f0092733ede moved the makefile and added german translation --- diff --git a/FreeSoftwareProjectManagementHOWTO.DE.rst b/FreeSoftwareProjectManagementHOWTO.DE.rst new file mode 100644 index 0000000..7df54fd --- /dev/null +++ b/FreeSoftwareProjectManagementHOWTO.DE.rst @@ -0,0 +1,3701 @@ +******************************************** +Projektmanagement für freie Software - HOWTO +******************************************** + +:Author: Benjamin "Mako" Hill, [mako {at} debian.org] + +:Author: Übersetzung: Robert F Schmitt, [bobfspm {at} arepo.org] + +Revisionen +---------- + +======================== ============== ============== +Revision v0.3.2 15. April 2002 Benutzer: bch +Revision v0.3.1 18. Juni 2001 Benutzer: bch +Revision v0.3 5. Mai 2001 Benutzer: bch +Revision v0.2.1 10. April 2001 Benutzer: bch +Revision v0.2 8. April 2001 Benutzer: bch +Revision v0.01 27. März 2001 Benutzer: bch +(Ursprüngliche Revision) +======================== ============== ============== + + +Dieses HOWTO ist konzipiert für Leute mit +Programmiererfahrung und ein paar Fähigkeiten +im +Management eines Software-Projektes, für +die jedoch +die Welt der freien Software neu ist. +Dieses Dokument ist gedacht als ein +Führer zu nichttechnischen Aspekten +des freien Software-Projektmanagements und +wurde +geschrieben als Crashkurs für die sozialen +Fähigkeiten, die kommerziellen Entwicklern +nicht +beigebracht werden, die aber über Wohl und +Wehe +eines freien Softwareprojektes entscheiden +können. + + + +Einleitung +---------- + +Beim Überfliegen von freshmeat.net findet +man Tausende +von Gründen für die Existenz dieses HOWTOS +- das Internet +ist übersät mit ausgezeichnet geschriebenen +und +nützlichen Programmen, +die ins Universum der vergessenen freien +Software +entschwunden sind. +Diese düstere Szene führte mich zu der Frage +"warum?" + +Dieses HOWTO versucht, eine Menge Sachen +(vermutlich zu viele) zu erledigen, aber +es kann +nicht diese Frage beantworten und wird es +nicht versuchen. Was dieses HOWTO versucht, +ist, deinem freien Software-Projekt +eine Überlebenschance zu verschaffen - +einen Vorsprung. Wenn du ein Stück Schrottcode +schreibst, +das niemanden interessiert, kannst +du dieses HOWTO lesen, bis du es im +Schlaf aufsagen kannst, und dein Projekt +wird +vermutlich fehlschlagen. Andererseits kannst +du ein +schönes, +relevantes Stück Software schreiben und jede +Anweisung in diesem HOWTO befolgen +und deine Software schafft es vielleicht +trotzdem +nicht. +Manchmal ist das Leben so. Jedoch wage ich +micht +ein Stück vor und sage, daß du, wenn du ein +großes relevantes Stücke Software schreibst +und den Rat dieses HOWTOs ignorierst, +vermutlich häufiger scheitern wirst. + +Eine Menge Informationen in diesem HOWTO +sollte man gesunden Menschenverstand nennen. +Selbstverständlich, wie jede mögliche Debatte +über Schnittstellen zeigt, was gesunder +Menschenverstand für manche Programmierer +ist, erweist +sich als völlig unintuitiv für andere. +Nachdem ich die Grundlagen dieses HOWTOs +freien +Softwareentwicklern bei einigen Gelegenheiten +erklärt +habe, stellte ich fest, +daß ich durch das Schreiben dieses HOWTOs +ein nützliches +Hilfsmittel zur Verfügung stellen könnte, +und ein Forum für Programmierer um Ideen +auszutauschen darüber, was für sie funktioniert +hat +und was nicht. + +Wie jeder zugeben würde, der je involviert +war in die +dem Anschein nach nie enden wollende Kette +von +Urheberrechtsstreitigkeiten, erweist sich +ein kleiner +Abschnitt Juristendeutsch als wichtig. + + + +Copyright-Informationen +....................... + +Dieses Dokument ist (c) 2002 von Benjamin "Mako" Hill +und wird unter den Bedingungen der Free Documentation +License veröffentlicht. + +Es besteht die Erlaubnis, dieses Dokument zu kopieren, +zu verteilen und/oder zu modifizieren, unter den +Bedingungen der GNU Free Documentation License, in +der Version 1.1 oder jeder späteren von der Free +Software Foundation publizierten Version, ohne +unveränderliche Abschnitte, Frontseiten- oder +Rückseitentexte. Eine Kopie der Lizenz +kann im Anhang A gefunden werden. + + + +Disclaimer +.......... + +Es kann keine Verbindlichkeit für den Inhalt dieses +Dokuments angenommen werden. Die Nutzung der beschriebenen +Konzepte, Beispiele und anderen Inhalte geschieht auf +eigene Gefahr. Da dies eine neue Veröffentlichung dieses +Dokumentes ist, können Fehler und Ungenauigkeiten +zu finden sein, die natürlich deinem Projekt (und +möglicherweise deinem System) Schaden zufügen +könnten. Laß' Vorsicht walten, denn wenn es auch +sehr unwahrscheinlich ist, kann der Autor keine +Verantwortung für diese Dinge übernehmen. + +Alles Copyrights werden von ihren jeweiligen Inhabern +gehalten, es sei denn es wird ausdrücklich etwas +anderes vermerkt. Der Gebrauch irgendeines Begriffes +in diesem Dokument sollte nicht so interpretiert werden, +daß er die Gültigkeit irgendeines eingetragenen +Warenzeichens oder einer Dienstleistungsmarke +berührt. + +Die Nennung bestimmter Produkte oder Marken sollte +nicht als Werbung gesehen werden. + + + +Neue Versionen +.............. + +Diese Version ist Teil des dritten pre-release- +Zyklus dieses HOWTO. Es ist geschrieben, +um +Entwicklern zur Verfügung gestellt zu werden, +für Kritik und Brainstorming. Bitte berücksichtige, +daß diese Version des HOWTOs noch +in einem Säuglingsstadium ist und noch weitgehend +verbessert werden wird. + +Die neueste Versionsnummer dieses Dokumentes +sollte auf dem Projekthomepage immer verzeichnet +werden, die unter yukidoke.org gehosted wird. + +Die neueste Version dieses HOWTO wird immer +von der gleichen Webseite in einer Vielzahl +von Formaten zur Verfügung gestellt: + +- HTML. +- HTML (einzelne Seite). +- normaler Text. +- Komprimiertes Postscript. +- Komprimierter SGML-Quellcode. + +(Anm. des Übers.: Die deutsche Version ist +Rest-basiert, +liegt also im Klartext und als HTML-Version +vor.) + +Credits +....... + +In dieser Version darf ich die Unterstützung +folgender Personen anerkennen: + +Debian-Mitentwickler Martin Michlmayr +und Vivek Venugopalan, die mich Informationen +und Verbindungen zu extrem interessanten +Artikeln schickten. Ich habe beide der Bibliographie +hinzugefügt und ich habe Informationen von +beiden dem HOWTO hinzugefügt. Danke an Andrews +Shugg, der einige Störungen im Dokument unterstrich. +Auch grosses Danke an Sung Wook Her (AKA +RedBaron) die die erste Übersetzung des HOWTOs +ins Koreanische macht. Ich bin glücklich +gewesen, +zu sehen, daß Leute sich bisher am HOWTO +erfreut und davon profitiert haben. + +Ältere Danksagungen, die ich noch nicht herausnehmen +möchte, schließen ein: Josh Crawford, +Andy King und Jaime Davila, die alle das +Dokument +im Ganzen gelesen haben und mir Feedback +gaben, +das mir geholfen +hat, Änderungen und Verbesserungen an diesem +Dokument zu machen. Ich kann nicht dir Kerle +genug für deine Hilfe danken. Ein extra Danke +geht +an Andy King, der dieses mehrmals las und +Patches einreichte, +um das Leben einfacher zu machen für mich. + +Karl Fogel, demr Autor von Open Source Development +with CVS (erschienen im Verlag Coriolis Open +Press), +Große Teile seines +Buches sind im Netz verfügbar. + +(Anm. des Übers.: Das Buch ist inzwischen vollständig +online unter der GPL verfügbar) + +225 Seiten des Buches sind unter der GPL verfügbar und +stellen das beste Tutorial über CVS dar, +das ich je gesehen habe. Der Rest +des Buches behandelt "die Herausforderungen +und +die philosophischen Aspekte, die dem Betreiben +eines Open Source-Projektes mit CVS zugrunde +liegen." +Das Buch macht seine Arbeit gut, was das +Abhandeln +einiger der Themen angeht, die in diesem +HOWTO +vorgestellt werden, und noch viel mehr. +Die Webseite des Buches hat Informationen +zur Bestellung des Buches und stellt einige +Übersetzungen der Kapitel über CVS zur Verfügung. + +Wenn du ernsthaft daran interessiert bist, ein freies +Software-Projekt zu betreiben, wirst +du dieses Buch haben wollen. Ich versuchte, +Fogel in den Abschnitten dieses HOWTO zu erwähnen, +wo ich wußte, daß ich direkt seine +Ideen borgte. Wenn ich irgendwelche übersehen +habe, +tut es mir leid. Ich werde versuchen, solche +Stellen in zukünftigen Versionen zu korrigieren. + +Karl Fogel kann unter + 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 . + + + +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: +. + + + +Ü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: . + + + +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ß „jede gute Softwarelösung +beginnt, indem sie eine Stelle kratzt, die +den +Entwickler juckt." Raymonds jetzt weithin +akzeptierte +Hypothese ist, daß neue freie Software-Programme +in +erster Linie geschrieben werden, um ein +spezifisches Problem zu lösen, dem der Entwickler +gegenübersteht. + +Wenn du eine Idee für ein Programm hast, +ist die Chance hoch, daß es +auf ein spezifisches Problem oder "Jucken" +zielt, +das du gerne gekratzt sehen würdest. Diese +Idee +ist das Projekt. Artikuliere sie offen. +Formuliere sie aus. Beschreibe das Problem, +das du in Angriff nimmst im Detail. Der Erfolg +deines Projektes im Anpacken eines bestimmten +Problems ist an deine Fähigkeit gekoppelt, +dieses Problem früh schon klar zu identifizieren. +Finde genau heraus, was dein Projekt nach +deinem +Willen tun soll. + +Monty Manley artikuliert den Wert dieses +Ausgangsschrittes in einem Essay, "Managing +Projects the Open Source Way." Wie der +folgende Abschnitt zeigen wird, gibt es eine +Menge Arbeit, die erledigt werden muß, bevor +Software überhaupt bereit ist kodiert zu +werden. +Manley sagt, "Ein OSS-Projekt richtig zu +beginnen heißt, +daß ein Entwickler in erster Linie vermeiden +muß, +zu früh Code zu schreiben!" + + + + +Deine Idee auswerten +++++++++++++++++++++ + +Wenn du deine Idee auswertest, mußt du dir +zuerst einige +Fragen stellen. Dieses sollte +geschehen, bevor du in diesem HOWTO einen +Schritt weiter machst. +Frage dich: Ist das +freie Software-Entwicklung Modell wirklich +das richtige für dein Projekt? + +Offensichtlich bist du, da das Programm dein +Jucken kratzt, +definitiv daran interessiert, es in Code +implementiert zu sehen. +Weil aber ein Hacker, der aleine programmiert, +noch nicht +als eine Unternehmung freier Software-Entwicklung +gilt, +mußt du dir eine zweite Frage stellen: Ist +sonst +jemand interessiert? + +Manchmal ist die Antwort ein einfaches "Nein." +Wenn du einen Satz Skripte schreiben möchtest, +um deine MP3-Sammlung auf deiner Maschine +zu sortieren, ist möglicherweise das Modell +der freien +Software-Entwicklung nicht die beste Wahl. + +Wenn du jedoch einen Satz +Skripte schreiben möchtest, um jedermanns +MP3s zu +sortieren, könnte ein freies Software-Projekt +eine nützliche Lücke füllen. + +Glücklicherweise ist das Internet ein grosser +und vielseitiger Ort, daß die Chance besteht, +daß dort draußen irgendwo irgendjemand ist, +der deine +Interessen teilt und der das selbe "Jucken" +verspürt. +Es ist die Tatsache, daß es also +viele Leute mit so vielen ähnliche Bedürfnissen +und Wünschen gibt, die die dritte Hauptfrage +aufwirft: Hatte jemand bereits deine Idee +oder ein recht ähnliche? + + + +Ähnliche Projekte finden +++++++++++++++++++++++++ + +Es gibt Orte im Netz, die du aufsuchen +kannst, um zu versuchen, eine Antwort auf die obige Frage +zu finden. Wenn du Erfahrung mit der +free software community hast, bist du +vermutlich bereits mit vielen dieser Seiten +vertraut. Alle im folgenden aufgeführten Quellen +bieten Suchfunktionen in ihren Datenbanken an: + +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 „yourprojectname-latest“ + anzubieten, der immer auf die neueste freigegebene + bzw. Entwicklungsversion deiner freien Software- + Anwendung zeigt. Behalte im Hinterkopf, + daß diese Position viele Downloadanfragen bekommen + wird, überprüfe also daß dein gewählter Server + über eine ausreichende Bandbreite verfügt. +- Stelle sicher, daß es eine gleichbleibende + Emailaddresse für Bug-Reports gibt. Es + ist normalerweise eine gute Idee, dafür eine + Adresse anzulegen, die NICHT deine primäre + Emailaddresse ist, etwas wie deinprojektname@host + oder deinprojektname-bugs@host. Auf diese Weise + brauchst du, wenn du dich je mal entscheidest, + die Maintainerhoheit abzugeben, oder wenn + sich einfach deine Emailaddresse ändert, einfach + die Emailaddresse ändern, an die die Mails + weitergeleitet werden. Es ermöglicht auch, daß + sich mehr als eine Person mit der Flut + an Post beschäftigen kann, die verursacht wird, + wenn dein Projekt so riesig wird, wie du es dir + erhoffst. + +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. diff --git a/render_sgml b/Makefile old mode 100755 new mode 100644 similarity index 80% rename from render_sgml rename to Makefile index ca55b21..f5e67a7 --- a/render_sgml +++ b/Makefile @@ -6,6 +6,7 @@ build: sgmltools -v --backend=ps FreeSoftwareProjectManagementHOWTO.sgml ps2pdf FreeSoftwareProjectManagementHOWTO.ps sgmltools -v --backend=rtf FreeSoftwareProjectManagementHOWTO.sgml + rst2html FreeSoftwareProjectManagementHOWTO.DE.rst FreeSoftwareProjectManagementHOWTO.DE.html move: mkdir -p ./tmp @@ -22,6 +23,7 @@ move: install: build move clean: - rm -rf FreeSoftwareProjectManagementHOwTO - rm -f FreeSoftwareProjectManagementHOWTO.html FreeSoftwareProjectManagement-HOWTO.txt FreeSoftwareProjectManagement-HOWTO.ps FreeSoftwareProjectManagement-HOWTO.pdf FreeSoftwareProjectManagement-HOWTO.rtf - rm -rf ./tmp \ No newline at end of file + rm -rf FreeSoftwareProjectManagementHOWTO + rm -f FreeSoftwareProjectManagementHOWTO.html FreeSoftwareProjectManagementHOWTO.txt FreeSoftwareProjectManagementHOWTO.ps FreeSoftwareProjectManagementHOWTO.pdf FreeSoftwareProjectManagementHOWTO.rtf + rm -rf ./tmp + rm FreeSoftwareProjectManagementHOWTO.DE.html