| Author: | Benjamin Mako Hill, [mako {at} atdot.cc] |
|---|---|
| Author: | Übersetzung: Robert F Schmitt, [bobfspm {at} arepo.org] |
| Revision v0.3.2 |
|
Benutzer: bch |
| Revision v0.3.1 |
|
Benutzer: bch |
| Revision v0.3 |
|
Benutzer: bch |
| Revision v0.2.1 |
|
Benutzer: bch |
| Revision v0.2 |
|
Benutzer: bch |
| Revision v0.01 |
|
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.
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.
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.
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.
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:
(Anm. des Übers.: Die deutsche Version ist Rest-basiert, liegt also im Klartext und als HTML-Version vor.)
In dieser Version darf ich die Unterstützung folgender Personen anerkennen:
Debian-Mitentwickler Martin Michlmayr und Vivek Venugopalan, die mich Informationen und Verbindungen zu extrem interessanten Artikeln schickten. Ich habe beide der Bibliographie hinzugefügt und ich habe Informationen von beiden dem HOWTO hinzugefügt. Danke an Andrews Shugg, der einige Störungen im Dokument unterstrich. Auch grosses Danke an Sung Wook Her (AKA RedBaron) die die erste Übersetzung des HOWTOs ins Koreanische macht. Ich bin glücklich gewesen, zu sehen, daß Leute sich bisher am HOWTO erfreut und davon profitiert haben.
Ältere Danksagungen, die ich noch nicht herausnehmen möchte, schließen ein: Josh Crawford, Andy King und Jaime Davila, die alle das Dokument im Ganzen gelesen haben und mir Feedback gaben, das mir geholfen hat, Änderungen und Verbesserungen an diesem Dokument zu machen. Ich kann nicht dir Kerle genug für deine Hilfe danken. Ein extra Danke geht an Andy King, der dieses mehrmals las und Patches einreichte, um das Leben einfacher zu machen für mich.
Karl Fogel, demr Autor von Open Source Development with CVS (erschienen im Verlag Coriolis Open Press), Große Teile seines Buches sind im Netz verfügbar.
(Anm. des Übers.: Das Buch ist inzwischen vollständig online unter der GPL verfügbar)
225 Seiten des Buches sind unter der GPL verfügbar und stellen das beste Tutorial über CVS dar, das ich je gesehen habe. Der Rest des Buches behandelt "die Herausforderungen und die philosophischen Aspekte, die dem Betreiben eines Open Source-Projektes mit CVS zugrunde liegen." Das Buch macht seine Arbeit gut, was das Abhandeln einiger der Themen angeht, die in diesem HOWTO vorgestellt werden, und noch viel mehr. Die Webseite des Buches hat Informationen zur Bestellung des Buches und stellt einige Übersetzungen der Kapitel über CVS zur Verfügung.
Wenn du ernsthaft daran interessiert bist, ein freies Software-Projekt zu betreiben, wirst du dieses Buch haben wollen. Ich versuchte, Fogel in den Abschnitten dieses HOWTO zu erwähnen, wo ich wußte, daß ich direkt seine Ideen borgte. Wenn ich irgendwelche übersehen habe, tut es mir leid. Ich werde versuchen, solche Stellen in zukünftigen Versionen zu korrigieren.
Karl Fogel kann unter <kfogel (at) red-bean (Punkt) com> erreicht werden.
Wer auch Hilfsmaterial und Inspiration für dieses HOWTO zur Verfügung stellt ist Eric S. Raymond mit seinen fruchtbaren, schlüssigen und sorgfältig ausgearbeiteten Argumenten sowie Lawrence Lessig, der mich erinnert hat an den Wert freier Software. Weiterhin möchte ich allen Benutzern und Entwicklern danken, die in am Debian-Projekt beteiligt sind. Das Projekt hat mir ein Zuhause, einen Ort verschafft, um für freie Software zu werben, einen Ort, von wo aus man etwas verändern kann, einen Ort, um von denen zu lernen, die an der Bewegung viel länger beteiligt sind als ich, und Beweis eines freien Software-Projektes, das definitiv, definitiv funktioniert.
Vor allem möchte ich Richard Stallman für seine Arbeit an der Free Software Foundation danken und dafür, nie aufzugeben. Stallman liefert und artikuliert die philosophische Grundlage, die mich zur freien Software zieht und die mich zum Schreiben eines Dokumentes motiviert, um sicherzustellen, daß es funktioniert.
RMS kann immer per Email erreicht werden unter <rms (at) gnu (Punkt) org>.
Feedback ist immer und zweifellos willkommen zu diesem Dokument. Ohne deine Zusendungen und Input würde dieses Dokument nicht bestehen. Glaubst du, daß etwas fehlt? Zögere nicht, mit mir in Verbindung zu treten, wenn ich ein Kapitel, einen Abschnitt oder einen Unterabschnitt schreiben soll oder
du einen schreiben willst. Ich möchte, daß dieses Dokument ein Produkt des freien Softwareentwicklungs- Prozesses ist, den es anpreist und ich glaube, daß sein letztlicher Erfolg in seiner Fähigkeit, dies zu tun liegt. Bitte schicke Deine Ergänzungen, Anmerkungen und Kritiken an folgende Emailaddresse: <mako (at) atodt.cc>.
Ich weiß, daß nicht jeder Englisch spricht. Übersetzungen sind nett und ich hätte es gerne, daß dieses HOWTO die Art internationaler Publizität erfährt, die durch übersetzte Versionen möglich wird.
Ich bin von einem Leser kontaktiert worden, der eine Übersetzung ins Koreanische verspricht. Jedoch ist dieses HOWTO noch jung, und abgesehen von dem Versprechen des Koreaners ist Englisch alles, was zur Zeit verfügbar ist. Wenn du helfen oder eine Übersetzung machen möchtest, gewinnst du meinen äußersten Respekt und Bewunderung und wirst Teil eines coolen Prozesses sein dürfen. Wenn du überhaupt interessiert bist, bitte nicht zögern, mit mir in Verbindung zu treten: <mako (at) atdot.cc>.
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.
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.
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!"
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?
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 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 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 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 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.
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.
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
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.
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.
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:
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.
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.
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.
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.
(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.
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.
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.
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:
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.
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.
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.
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.
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 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.
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.
Weitere Tips:
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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):
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
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:
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.
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:
Maximale Pufferlängen, Datenumwandlungen, ober/untere Grenzen, und so weiter.
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.
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.
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.
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.
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:
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.
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 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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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..."
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.
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.
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-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-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.
"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.
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.
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.
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).
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.
(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).
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.
(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 F