******************************************** 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.