Der Einstieg
Den klassischen Verlauf eines freien Software-Projektes
beschreibt Eric Raymond in seinem nunmehr berühmten Text über Open Source,
The Cathedral and the Bazaar:
Jede gute Software entsteht aus einem persönlichen
Bedürfnis eines Programmierers.
(von
)
Raymond sagte wohlgemerkt nicht, dass Open-Source-Projekte nur aus
dem persönlichen Bedürfnis eines Programmierers entsteht, sondern dass
gute Software dann entsteht, wenn der Programmierer
ein persönliches Interesse daran hat, ein Problem zu lösen; was insofern
für freie Software relevant ist, da sich herausstellte, dass die
meisten Open-Source-Projekte von Programmierern begonnen wurden, die
eines ihrer eigenen Probleme lösen wollten.
Die Motivation für die meisten freien Software-Projekte ist auch
heute noch dieselbe, wenn auch in geringerem Maße als um 1997, zu der Zeit als
Raymond diese Worte schrieb. Heute beobachten wir das Phänomen, dass
Organisationen – auch gewinnorientierte Unternehmen – große, zentral
organisierte Open-Source-Projekte anfangen. Der einsame Programmierer
der ein bisschen Code produziert, um ein lokales Problem zu lösen und dann
feststellt, dass das Ergebnis eine breitere Anwendbarkeit besitzt, ist
immer noch die Quelle für vieles an freier Software, jedoch nicht
mehr die einzige.
Raymonds Sicht ist aber immer noch aufschlussreich.
Diejenigen die Software produzieren, müssen ein direktes Interesse an
ihrem Erfolg haben, weil sie auch Benutzer sind. Wenn die Software nicht
macht was es soll, wird die Person oder Organisation die sie produziert,
es bei der täglichen Arbeit merken. Ein gutes Beispiel ist das OpenAdapter
Projekt () der
Investmentbank Dresdner Kleinwort Wasserstein, das als Open-Source-Framework
zur Integration unterschiedlicher finanzieller Informationssysteme
begonnen wurde, es kann wohl kaum als Bedürfnis eines eines einzelnen
Programmierers bezeichnet werden, sondern als institutionelles
Bedürfnis. Dieses Bedürfnis entsteht aber direkt aus den Erfahrungen
der Institution und ihrer Partner, wenn die Software ihre Aufgabe nicht
erfüllt, wird es somit bemerkt. Aus diesem Arrangement entsteht gute
Software, da Rückmeldungen an der richtigen Stelle ankommen. Die
Software muss nicht verkauft werden, also können sie sich auf
ihre Probleme konzentrieren. Sie wird geschrieben
um die eigenen Probleme zu lösen, um diese Lösung dann mit
allen zu teilen. Es ist so ähnlich, als wäre das Problem eine Krankheit
und die Software die entsprechende Medizin um eine Epidemie in den Griff
zu bekommen.
In diesem Kapitel geht es um die Frage, wie man der Welt ein neues
freies Software-Projekt vorstellt. Viele seiner Empfehlungen klingen sehr
nach einer Gesundheitsorganisation, die Medizin verteilen will. Die Ziele
sind sich sehr ähnlich: Man will klarstellen, was die Medizin macht, sie
in die Hände der richtigen Leute bringen und sicherstellen, dass
diejenigen die es erhalten, damit umzugehen wissen. Bei freier
Software will man aber auch ein paar der Empfänger zu einer Beteiligung
an der fortwährenden Forschungsarbeit zur Verbesserung der Medizin
bewegen.
Beim Vertrieb freier Software gibt es zwei Ziele. Die Software
muss sowohl Nutzer als auch Entwickler anziehen. Diese beiden
Anforderungen stehen zueinander nicht zwangsläufig im Widerspruch, aber sie
machen die anfängliche Präsentation des Projekts etwas komplexer.
Manche Informationen sind für beide Gruppen nützlich, manche nur für
die eine oder die andere. Beide Arten der Information sollten das
Prinzip der skalierenden Präsentation verfolgen; d.h. dass die Menge an
Informationen sich jederzeit mit der Zeit und Anstrengung decken sollte,
die vom Leser aufgebracht wird. Eine größere Anstrengung sollte auch
immer eine größere Belohnung mit sich bringen. Wenn beides nicht eng
miteinander korreliert, werden die Leser schnell die Hoffnung aufgeben
und aufhören Zeit zu investieren.
Daraus folgt: das Erscheinungsbild ist
wichtig. Programmierern fällt es besonders schwer, das zu
glauben. Ihre Liebe zum Inhalt gegenüber dem Äußeren gehört fast
schon zum Berufsethos. Es ist kein Zufall, dass so viele Programmierer
gegen Marketing und Public Relations eine Antipathie hegen, oder dass
professionelle Grafiker über so manches erschrocken sind, worauf
Programmierer von sich aus kommen.
Das ist schade, denn es gibt Situationen, in denen das Aussehen
auch wirklich dem Inhalt entspricht. Die
Präsentation eines Projekts ist genau solch ein Fall. Die erste
Information, die ein Besucher über ein Projekt erhält, ist die Gestaltung
seiner Webseite. Diese Information wird erfasst, bevor irgend ein
tatsächlicher Inhalt der Seite verstanden wird – bevor ein
Text gelesen wurde oder auf einen Link geklickt wurde. Egal wie
ungerecht es sein mag, Menschen können sich nicht anders helfen, als sich
sofort einen ersten Eindruck zu verschaffen. Im Erscheinungsbild der
Seite wird deutlich, ob man sich beim Aufbau der Präsentation des
Projekts Mühe gemacht hat. Menschen haben eine extrem sensible Antenne
dafür, wieviel Mühe in etwas investiert wurde. Die meisten können mit
einem Blick erkennen, ob eine Seite eilig zusammengebastelt wurde oder
ob man sich ernsthafte Gedanken gemacht hat. Das ist die erste
Information die Ihr Projekt nach außen gibt, und der hierdurch
vermittelte Eindruck überträgt sich auf das übrige Projekt.
Auch wenn sich dieses Kapitel thematisch um inhaltliche Fragen dreht,
sollten sie daran denken, dass das Erscheinungsbild eine Rolle spielt.
Da die Webseite für zwei Arten von Besuchern geeignet sein muss
– Benutzer und Entwickler – muss besonders auf Klarheit und
Führung geachtet werden. Auch wenn hier nicht die richtige Stelle für
eine allgemeine Abhandlung über Web-Design ist, gibt es ein
erwähnenswertes Prinzip, insbesondere wenn die Seite mehrere
(überlappende) Zielgruppen ansprechen soll: Besucher sollten eine grobe
Vorstellung haben, wo ein Link hinführt, bevor sie darauf klicken. Das
Ziel eines Links zur Benutzer-Dokumentation sollte allein vom
Anblick her deutlich sein, und keine
Missverständnisse aufkommen lassen, ob es sich nicht etwa um die Dokumentation
für Entwickler handelt. Beim Betrieb eines Projekts geht es zu einem Teil
darum, Informationen bereitzustellen, aber auch darum, ein Gefühl der
Bequemlichkeit zu vermitteln. Allein schon die Verfügbarkeit bestimmter
grundsätzlicher Angebote an der richtigen Stelle gibt Benutzern und
Entwicklern eine Sicherheit bei ihrer Entscheidung, ob sie sich
beteiligen wollen oder nicht. Es sagt ihnen, dieses Projekt hat seine
Siebensachen beisammen, Fragen erahnt, die gestellt werden, und sich die
Mühe gemacht diese so zu beantworten, dass Fragesteller möglichst wenig
Einsatz aufbringen müssen. Indem das Projekt eine Aura der Vorbereitetheit
ausstrahlt, sendet es die folgende Botschaft aus:
"Du verschwendest deine Zeit nicht, wenn du dich beteiligst",
und das ist genau die Botschaft, die Menschen hören wollen.
Schauen Sie sich zuerst um
Bevor Sie ein Open-Source-Projekt anfangen, gibt es noch eine
wichtige Warnung:
Schauen Sie sich vorher um, ob nicht schon ein Projekt existiert,
das Ihre Anforderungen erfüllt. Die Wahrscheinlichkeit ist hoch, dass
unabhängig von dem Problem, das Sie lösen wollen, Ihnen jemand zuvorgekommen
ist. Wenn das der Fall ist und der entsprechende Code unter eine freie
Lizenz gestellt wurde, gibt es keinen Grund das Rad neu zu erfinden. Es
gibt natürlich Ausnahmen: Falls Sie ein Projekt um der Lernerfahrung
willen beginnen wollen, wird Ihnen bereits existierender Code nicht
weiterhelfen. Vielleicht wissen Sie bereits von vornherein, dass Ihr
Problem so spezifisch ist, dass es mit Sicherheit noch von keinem
gelöst wurde. Im allgemeinen gibt es aber keinen Grund sich nicht
umzuschauen, und der Lohn kann beträchtlich sein. Sollten die üblichen
Suchmaschinen keine brauchbaren Ergebnisse liefern, sollte Sie es bei
(eine Nachrichtenseite über
Open-Source-Projekte (zu dieser Seite, später mehr), bei
oder beim Verzeichnis
freier Software der Free Software Foundation
versuchen.
Selbst wenn Sie nicht genau das finden, wonach Sie suchen,
könnten Sie etwas derart ähnliches finden, dass es sinnvoller ist,
sich an diesem Projekt zu beteiligen und es um die fehlenden Funktionen
zu erweitern, als komplett von vorne anzufangen.
Mit dem Vorhandenen beginnen
Sie haben sich umgeschaut, herausgefunden dass nichts Ihre
Anforderungen erfüllt und sich entschlossen, ein neues Projekt zu
starten.
Was nun?
Das Schwierigste beim Start eines neuen freien Software-Projekts
ist die Verwandlung einer persönlichen Vision in eine öffentliche. Sie
oder Ihre Organisation mögen sehr wohl wissen was Sie wollen. Dieses
Ziel so auszudrücken, dass die Welt es versteht, ist erfordert ein
beträchtliches Maß an Arbeit. Allerdings ist es von so grundsätzlicher
Bedeutung, dass Sie sich die Zeit dazu nehmen sollten. Sie und die anderen
Gründer müssen entscheiden, worum es in dem Projekt wirklich geht –
so müssen Sie über seine Grenzen entscheiden, was es abdecken wird und was
nicht – und ein Missionsziel
(engl. mission statement) verfassen. Dieser Teil ist für
gewöhnlich nicht allzu schwer, auch wenn es manchmal unerwähnt
gebliebene Annahmen, sogar Meinungsverschiedenheiten über die Natur des
Projekts aufdecken kann, was sogar gut ist:
Es ist besser diese jetzt auszuräumen als später. Der
nächste Schritt ist das Projekt für die öffentliche Wahrnehmung
aufzubereiten, was im Grunde genommen eine Schinderei ist.
Diese Arbeit ist deshalb so mühselig, weil man hauptsächlich
Dinge organisiert und dokumentiert, die jeder bereits kennt –
d.h "jeder" der bislang am Projekt beteiligt ist. Für diejenigen die
die Arbeit machen, gibt es deshalb keinen direkten Nutzen. Sie
brauchen weder die README-Datei für einen Überblick
über das Projekt, noch Entwurfsdokumente oder Benutzerhandbücher.
Sie brauchen keine sorgsam aufbereitete Code-Struktur die mit den
zwar informellen aber verbreiteten Normen zur Veröffentlichung
von Quellen konform ist. Wie auch immer der Quellcode strukturiert ist,
es ist ihnen recht; sie sind ja bereits daran gewöhnt, und solange der
Code läuft, wissen sie wie man ihn benutzt. Es macht ihnen
nicht einmal etwas aus, wenn grundlegende Annahmen über die
Architektur des Projekts undokumentiert bleiben; auch mit ihnen sind
sie ja bereits vertraut.
Neulinge andererseits brauchen all diese Dinge.
Glücklicherweise jedoch nicht alle auf einmal. Sie müssen nicht jede
erdenklich Ressource gleich parat haben, bevor Sie mit einem Projekt an die
Öffentlichkeit gehen. In einer perfekten Welt wäre ein neues
Open-Source-Projekt von Beginn an ausgestattet mit einem ausführlichen
Entwurfsdokument, einem vollständigen Benutzerhandbuch (inklusive der
Hinweise auf Funktionen, die zwar geplant, aber noch nicht implementiert
sind), wunderschönem und portabel gegliedertem Code, der auf jeder
Plattform läuft, usw. In Wirklichkeit wäre es unvertretbar zeitaufwendig,
auf all diese Dinge zu achten; und überhaupt sind das Arbeiten, bei
denen man davon ausgehen kann, dass sich Freiwillige beteiligen,
sobald das Projekt läuft.
Wirklich notwendig ist jedoch, so viel in die
Präsentation zu investieren, dass Neulinge die ersten Hürden des
Unbekannten überwinden können. Stellen Sie sich das wie den ersten
Schritt beim Hochfahren vor, um dem Projekt zu einer Art minimaler
Aktivierungsenergie zu verhelfen. Dieser Grenzbereich wird mitunter
Hacktivierungs-Energie genannt: Die
Energie, die Neulinge investieren müssen, bevor sie etwas zurückbekommen.
Je geringer die Hacktivierungs-Energie ist, desto besser. Ihre erste
Aufgabe ist es, die Hacktivierungs-Energie auf ein Niveau zu senken,
das Leute dazu ermutigt, sich zu beteiligen.
Jeder der folgenden Unterabschnitte, beschreibt einen wichtigen
Aspekt beim Start eines neuen Projekts. Sie werden ungefähr in der
Reihenfolge präsentiert, in der neue Besucher sie wahrnehmen werden,
natürlich kann die tatsächliche Reihenfolge auch abweichen.
Betrachten Sie sie als Checkliste.
Wenn Sie ein Projekt starten, gehen Sie die Liste durch und stellen Sie
sicher, dass alle Punkte erledigt sind oder zumindest dass Sie mit den
möglichen Folgen zurechtkommen, wenn Sie einen Punkt auslassen.
Wählen Sie einen guten Namen
Versetzen Sie sich in die Lage von jemandem, der gerade von Ihrem
Projekt erfahren hat, vielleicht ganz zufällig, bei der Suche nach einer
Software, um ein irgendein Problem zu lösen. Das erste, womit er in
Berührung kommen wird, ist der Name Ihres Projekts.
Ein guter Name wird Ihr Projekt nicht automatisch erfolgreich
machen, und ein schlechter Name wird nicht seinen Untergang besiegeln –
nun ja, ein wirklich schlechter Name könnte das
vielleicht tatsächlich, aber wir gehen davon aus, dass niemand versuchen
wird, sein Projekt aktiv zu sabotieren. Allerdings kann ein schlechter
Name die Aufmerksamkeit für das Projekts schmälern, entweder weil die
Leute ihn nicht ernst nehmen oder schlicht deshalb, weil Sie ihn sich
nicht merken können.
Ein guter Name:
Gibt eine ungefähre Vorstellung davon, was das Projekt
tut oder steht zumindest in einer so offensichtlichen
Beziehung dazu, dass man weiß was das Projekt tut, wenn man
den Namen kennt, und es deshalb später leicht hat, sich an
den Namen zu erinnern.
Ist einfach zu behalten. Man kommt hier nicht um die
Tatsache herum, dass Englisch zur Standardsprache im
Internet geworden ist: "einfach zu behalten" bedeutet in
diesem Fall "Einfach zu behalten für jemanden, der Englisch
lesen kann". Wortspiele, die auf der einheimischen Aussprache
beruhen, werden vielen Menschen, deren Muttersprache nicht
Englisch ist, unverständlich bleiben. Ist das Wortspiel
besonders verlockend und einprägsam, kann es das wert
sein; denken Sie aber daran, dass viele, die den Namen sehen,
nicht dasselbe heraushören werden wie ein englischer
Muttersprachler.
Gleicht nicht dem eines anderen Projekts und verletzt
auch kein Markenrecht. Das ist einerseits höflich und
andererseits auch rechtlich sinnvoll, denn Sie wollen keine
Verwirrung über Identitäten anstiften. Es ist schwierig
genug, im Blick zu behalten, was das Netz zu bieten hat, auch
ohne unterschiedliche Dinge mit demselben Namen.
Die zuvor in erwähnten
Quellen können Ihnen dabei helfen herauszufinden, ob ein
anderes Projekt bereits den Namen trägt, den Sie im Sinn
haben. Die kostenlose Suche nach Markenzeichen ist über
und
verfügbar.
Ist idealerweise als Domain-Name verfügbar in den
Top-Level-Domeins
.com,
.net, und
.org.
Sie sollten eine von ihnen auswählen, vielleicht
.org, um sie als offizielle Seite
des Projekts zu bewerben; die anderen beiden sollten darauf
verweisen und einfach nur dazu dienen, andere zu hindern,
Verwirrung bezüglich Ihres Projektnamens zu stiften.
Selbst wenn Sie vorhaben, das Projekt auf einer anderen Seite
zu betreiben (siehe
), können Sie
immer noch die Projekt-spezifische URL registrieren und
diese auf die Seiten des Betreibers weiterleiten. Es hilft
dem Nutzer ungemein, nur eine einfache URL im Kopf behalten
zu müssen.
Formulieren Sie ein klares Missionsziel
Sobald Besucher ihre Projektseite gefunden haben, werden sie nach
einer kurzen Beschreibung, dem Ziel des Projekts suchen, um (innerhalb
von 30 Sekunden) entscheiden zu können, ob sie interessiert daran sind,
mehr zu erfahren. Das Ziel sollte auf der Frontseite einen auffälligen
Platz einnehmen, vorzugsweise gleich unter dem Projektnamen.
Die Formulierung des Missionsziels sollte anschaulich, klar
umrissen und vor allem kurz sein. Hier ist ein gutes Beispiel von
:
Gemeinschaftlich die führende internationale
Office-Lösung erschaffen, die auf allen wichtigen Plattformen läuft und
den Zugriff auf alle Funktionen und Daten durch offene Schnittstellen
und ein XML-basiertes Dateiformat erlaubt.
In nur wenigen Worten haben sie alle wichtigen Punkte erfasst,
hauptsächlich indem sie sich auf das Vorwissen der Leser stützen.
Mit "Gemeinschaftlich",
signalisieren sie, dass keine einzelne Firma die Entwicklung dominieren
wird; "international" bedeutet, dass die Software
es Menschen erlauben wird, in mehreren Sprachen zu arbeiten;
"alle wichtigen Plattformen" heißt für Unix,
Macintosh und Windows. Das Übrige signalisiert, dass offene
Schnittstellen und leicht verständliche Dateiformate ein wichtiger Teil
ihres Ziels sind. Sie sagen nicht offen, dass sie eine freie Alternative
zu Microsoft Office sein wollen, aber die meisten Menschen können zwischen
den Zeilen lesen. Auch wenn dieser Satz auf den ersten Blick weitgreifend
erscheint, ist es tatsächlich recht begrenzt: Der Begriff
"Office-Lösung" bedeutet etwas ganz bestimmtes für
diejenigen, die mit solcher Software vertraut sind. Die mutmaßlichen
Vorkenntnisse der Leser (in diesem Fall wahrscheinlich mit MS Office)
werden ausgenutzt, um das Missionsziel kompakt zu halten.
Die Gestaltung des Missionsziels hängt teilweise davon ab, wer es
schreibt und nicht von der Software die es beschreibt. So ist es für
Open Office beispielsweise sinnstiftend, das Wort
"gemeinschaftlich" zu verwenden, denn das Projekt
wurde gestartet und noch immer großteils gesponsort von Sun Microsystems.
Mit dieser Wortwahl zeigt man sich sensibel gegenüber Befürchtungen, die
Entwicklung könne einmal seitens Sun dominiert werden. In einer solchen
Angelegenheit kann schon allein der Hinweis auf die
Möglichkeit eines Problems einen wesentlichen
Schritt für seine Ausräumung darstellen.
Andererseits können Projekte, die nicht durch eine einzige Firma
unterstützt werden, auf solche Formulierungen verzichten; schließlich
ist die Entwicklung durch eine Gemeinschaft das Übliche, es gibt also
normalerweise keinen Grund, dies im Missionsziel aufzuführen.
Sagen Sie, dass das Projekt frei ist
Wer die Missionziele gelesen hat und noch interessiert ist, wird
nun weitere Einzelheiten erfahren wollen, vielleicht durch die
Benutzer- oder Entwicklerdokumentation, schließlich wird er
etwas herunterladen wollen. Doch vor alledem will er sicher sein,
dass es sich um Open Source handelt.
Die Hauptseite muss unmissverständlich klar machen,
dass das Projekt Open Source ist. Das mag offensichtlich
klingen, Sie wären aber überrascht darüber, wie viele Projekte es
vergessen. Ich habe schon Projekte gesehen, deren Hauptseite nicht nur
versäumte zu sagen, unter welcher Lizenz ihre Software veröffentlicht
wurde, sondern nicht einmal erwähnte, dass es sich um freie Software
handelt. Manchmal erschien die entscheidende Information erst auf der
Download-Seite, der Entwickler-Seite oder irgend einer andere Stelle die
einen Klick mehr erforderte. Im Extremfall wurde die Lizenz überhaupt
nicht auf der Site angegeben – die einzige Möglichkeit sie
herauszufinden war, die Software herunterzuladen und hineinzuschauen.
Vermeiden Sie diesen Fehler. Durch solch ein Versäumnis können
Ihnen viele potentieller Entwickler und Nutzer verloren gehen. Sagen Sie
gleich vorweg, direkt unterhalb des Missionsziels, dass das Projekt
freie Software oder Open-Source-Software ist, und geben Sie die genaue
Lizenz an. Eine kurze Anleitung zur Wahl einer Lizenz bietet der Abschnitt
später in
diesem Kapitel; Lizenzfragen werden ausführlich im Kapitel
behandelt.
Bis hierhin hat sich unser hypothetischer Besucher entschieden
– wahrscheinlich innerhalb der ersten Minute oder schon vorher
– ob er interessiert ist, sagen wir, zumindest weitere fünf
Minuten in das Projekt zu investieren. Der nächste Abschnitt beschreibt,
was er innerhalb dieser fünf Minuten vorfinden sollte.
Funktionen und Anforderungen
Es sollte eine kurze Liste der Funktionen geben, die von der
Software unterstützt werden (Wenn etwas noch nicht fertig ist, können
Sie es trotzdem auflisten, schreiben Sie aber
"geplant" oder "in Arbeit"
daneben), und der Anforderungen, die die Software an die Hardware stellt.
Stellen Sie sich die Liste der Funktionen/Anforderungen wie etwas vor,
das Sie jemandem geben würden, der eine Kurzzusammenfassung zu dieser
Software wünscht. Oft ist sie einfach nur eine logische Erweiterung der
Missionsziele. Das Missionsziel könnte zum Beispiel folgendes
beinhalten:
Erstellung einer Volltext-Indexierungs- und
-Suchmaschine mit einer umfangreichen Schnittstelle (rich API) für
Programmierer, die Suchdienste über große Mengen von Text anbieten
wollen.
Die Liste der Funktionen und Anforderungen würde Details
bieten, um das Missionsziel zu verdeutlichen:
Funktionen:
Durchsucht Klartext, HTML, und
XML
Suche nach Wörtern oder
Ausdrücke
(geplant) Unscharfe Suche
(geplant) Inkrementelle Aktualisierung
der Indexe
(geplant) Indexierung von Ressourcen im
Netzwerk
Anforderungen:
Python 2.2 oder höher
Genug Festplattenspeicher für die Indexe
(ungefähr. doppelte Menge der
Originaldaten)
Durch diese Informationen gewinnen Leser schnell ein Gefühl dafür,
ob ihnen diese Software etwas nützen könnte, und sie können gleichzeitig
überlegen, ob sie sich als Entwickler beteiligen wollen.
Stand der Entwicklung
Leute wollen immer wissen wie es einem Projekt geht. Bei neuen
Projekten wollen sie wissen wie weit seine Versprechen und sein
derzeitiger Stand auseinanderliegen. Bei einem ausgereiften Projekt
wollen sie wissen, wie aktiv es gepflegt wird, wie oft neue Versionen
veröffentlicht werden, wie schnell es wahrscheinlich auf Bug-Meldungen
reagieren wird usw.
Um diese Fragen zu beantworten, sollten Sie eine Seite zum
Fortschritt der Entwicklung einrichten, auf der die kurzfristigen Ziele
und Anfragen des Projekts aufgelistet werden (es könnte z.B. auf der
Suche nach Entwicklern mit bestimmten Fachkenntnissen sein). Die Seite
kann auch eine Übersicht vergangener Versionen haben, mit einer
Auflistung der jeweiligen Funktionen, damit Besucher sich ein Bild
machen können, was in diesem Projekt unter "Fortschritt" verstanden wird
und wie schnell es nach diesem Verständnis vorankommt.
Fürchten Sie sich nicht davor, einen unfertigen Eindruck zu
vermitteln und widerstehen Sie der Versuchung, den Entwicklungsstand
besser darzustellen als er wirklich ist. Jeder weiß, dass sich Software in
Schritten entwickelt; es ist keine Schande zu sagen "Es ist Alpha-Software
und sie hat bekannte Fehler. Sie läuft zwar und funktioniert
zumindest teilweise, trotzdem gilt: Nutzung auf eigene Gefahr". Diese
Ausdrucksweise wird nicht die Art von Entwicklern verschrecken, die Sie zu
dieser Zeit brauchen. Was die Nutzer angeht: Einer der schlimmsten
Fehler, die ein Projekt machen kann, ist Nutzer anzulocken, für die die
Software noch nicht bereit ist. Der Ruf, instabil oder fehlerträchtig zu
sein, ist schwer wieder loszuwerden, wenn er dem Projekt einmal anhaftet.
Auf lange Sicht zahlt es sich aus, konservativ zu sein; es ist besser
wenn die Software stabiler läuft als erwartet,
und angenehme Überraschungen sorgen für die beste Mundpropaganda.
Alpha und Beta
Der Begriff alpha bedeutet für gewöhnlich
eine erste Version, mit der Benutzer echte Arbeit erledigen können, die
alle geplante Funktionen hat, aber auch bekannte Fehler. Der vorrangige
Sinn von Alpha-Software ist, Rückmeldungen zu erhalten, damit die
Entwickler wissen, woran sie arbeiten sollen. Die nächste Stufe
beta bedeutet, dass in der Software alle groben
Fehler behoben wurden, aber noch nicht genug getestet wurde, um als zur
Herausgabe geeignet zu gelten. Der Sinn von Beta-Software ist entweder
zur offiziellen Version zu werden, wenn keine Fehler gefunden wurden,
oder detailierte Rückmeldungen an die Entwickler zu geben, um die zügige
Fertigstellung der Version zu unterstützen. Der Unterschied zwischen
alpha und beta ist zum größten Teil eine Sache der Einschätzung.
Downloads
Man sollte die Software als Quelltext in den üblichen Formaten
herunterladen können. Wenn ein Projekt noch am Anfang ist, sind
binäre (ausführbare) Dateien nicht nötig, es sei denn der
Build-Vorgang ist derart kompliziert und voller Abhängigkeiten, dass
es für die meisten Leute einen Menge Arbeit wäre, die Software
überhaupt zum Laufen zu bringen. (Wenn das aber der Fall ist, wird
das Projekt sowieso Schwierigkeiten haben, Entwickler
anzuziehen.
Die veröffentlichten Dateien herunterzuladen, sollte so bequem,
standardkonform und mühelos sein wie möglich. Um eine Krankheit
auszurotten, würden Sie die Medizin nicht so verteilen, dass man zur
Anwendung eine unüblich Spritzengröße bräuchte. Ebenso sollte Software
die üblichen Build- und Installationsmethoden beachten, denn je mehr
sie von diesen Standards abweicht, desto mehr potenzielle Benutzer und
Entwickler werden aufgeben und sich verwirrt abwenden.
Das hört sich offensichtlich an, aber viele Projekte machen sich
diese Mühe sehr lange Zeit nicht in der Annahme, dass sie es jederzeit
tun könnten: "Wir erledigen den Kram sobald der Code näher
an der Fertigstellung ist.". Hierbei übersehen sie jedoch,
dass das Hinausschieben der langweiligen Arbeiten an Build- und
Installations-Vorgängen auch die Fertigstellung vom Code hinausschiebt
– denn sie entmutigen Entwickler, die ansonsten etwas
zum Code beigetragen hätten. Das Heimtückische daran ist,
dass nicht einmal jemand davon erfährt, dass
Entwickler verlorengegangenen sind, denn der Vorgang ist eine
Ansammlung von Nicht-Ereignissen: Jemand geht auf die Webseite, lädt
die Software herunter, versucht einen Build zu machen, scheitert, gibt auf
und geht seiner Wege. Wer außer der Person selbst wird jemals davon
erfahren? Keiner im Projekt wird je bemerken, wie Interesse und
Wohlwollen von jemanden lautlos verschwendet wurde.
Langweilige Arbeit mit einem hohen Nutzen sollte immer frühzeitig
erledigt werden, und das Herabsetzen der Einstiegshürden für ein Projekt
durch zahlt sich mit vielfachem Gewinn aus.
Wenn Sie ein Paket zum Herunterladen freigeben ist es wichtig, eine
eindeutige Versionsnummer zu vergeben, damit die Ausgaben unterschieden
werden können und sehen welche die aktuellere ist. Eine
ausführliche Diskussion über Versionsnummern finden Sie in
, und Details zur Standardisierung
von Build- und Installations-Vorgängen werden im Abschnitt
, sowie in
behandelt.
Zugriff auf Versionsverwaltung und Bugtracker
Den Quellcode herunterzuladen, mag für diejenigen ausreichend sein,
die lediglich die Software installieren und benutzen wollen, das genügt
jedoch nicht für diejenigen, die sie weiterentwickeln wollen. Nächtliche
Quelltext-Schnappschüsse können helfen, sind aber nicht ausreichend
fein für eine lebendige Entwicklergemeinschaft. Diese Leute brauchen
Echtzeit-Zugriff auf den neusten Quellcode; ihn bereitzustellen, wird erst
durch die Benutzung einer Versionsverwaltung möglich. Anonymer Zugriff auf
den Quellcode, der unter Versionsverwaltung steht, ist ein Zeichen
– für Entwickler wie auch für Nutzer – dass das Projekt sich
Mühe gibt, den Leuten das für eine Beteiligung Nötige zu geben. Wenn
Sie nicht sofort eine Versionsverwaltung bereitstellen können, sollten
Sie zumindest darauf hinweisen, dass Sie dies demnächst vorhaben. Das
Thema Infrastruktur der Versionsverwaltung wird ausführlich in
im Kapitel
behandelt.
Gleiches gilt für den Bugtracker. Die Bedeutung des Bugtracker liegt
nicht allein in seinem Nutzen für die Entwickler, sondern er ist auch ein
Signal an Außenstehende. Für viele ist eine öffentliche Bug-Datenbank
eines der stärksten Anzeichen dafür, dass ein Projekt ernstgenommen werden
sollte. Desweiteren ist ein Projekt um so besser, je mehr Fehler darin
protokolliert sind. Auch wenn es sich widersprüchlich anhört, sollte man
bedenken, dass die Anzahl der erfassten Fehler von drei Dingen abhängt:
Die absolute Anzahl in der Software enthaltene Fehler, die Anzahl seiner
Benutzer und wie bequem es für diese Benutzer ist, neue Fehler
einzutragen. Von diesen dreien sind die letzten beiden wesentlich. Jede
ausreichen große und komplexe Software, enthält eine im Grunde genommen
beliebige Menge an Fehlern, die nur darauf warten, entdeckt zu werden.
Die eigentliche Frage ist, wie gut kann das Projekt diese Fehler erfassen
und priorisieren? Ein Projekt mit einer großen und gut gepflegten
Fehler-Datenbank (ein Zeichen dafür, dass schnell auf Bugs reagiert wird,
Duplikate markiert werden, usw.) macht deshalb einen besseren Eindruck
als ein Projekt ohne oder mit einer fast leeren Fehler-Datenbank.
Am Anfang des Projekts wird die Fehler-Datenbank natürlich nur sehr
wenige Meldungen enthalten und es gibt nicht viel, das Sie dagegen
tun könnten. Wenn die Statusseite aber das junge Alter hervorhebt
und wenn Leute, die die Bug-Datenbank betrachten, sehen können, dass
die meisten Einträge vor kurzem gemacht wurden, können sie leicht
schlussfolgern, dass das Projekt immer noch eine gesunde
Rate an Einträgen hat und werden dementsprechend
über die niedrige absolute Anzahl an Bug-Meldungen nicht wirklich
beunruhigt sein .
Man sollte auch beachten, dass Bugtracker oft nicht nur zur
Verfolgung von Bugs, sondern auch für Verbesserungen an der Software,
Änderungen an der Dokumentation, ausstehende Aufgaben und mehr benutzt
werden. Weiteres zum Betrieb eines Bugtrackers, wird in
im Kapitel
behandelt, also
werde ich hier nicht näher darauf eingehen. Das Wichtige aus Sicht der
Präsentation ist überhaupt einen Bugtracker zu
haben und sicherzustellen, dass dieser Umstand
bereits auf der Hauptseite deutlich wird.
Kommunikationskanäle
Besucher wollen oft wissen, wie sie am Projekt beteiligte
Menschen erreichen können. Veröffentlichen Sie deshalb Adressen von
Mailinglisten, Chat-Räumen, IRC-Kanälen und anderen Foren, auf denen
Beteiligte erreicht werden können. Stellen Sie klar,
dass Sie und die anderen Autoren des Projekts auf diesen Listen
eingetragen sind, um den Besuchern zu zeigen , dass sie Rückmeldungen
an die Entwickler richten können. Eine Anmeldung auf den
Mailinglisten beinhaltet für Sie nicht die Verpflichtung, alle Fragen
zu beantworten oder alle Wünsche nach neuen Funktionen zu verwirklichen.
Auf lange Sicht betrachtet, nutzt die Mehrheit diese Foren sowieso nie,
aber es wird sie ermutigen zu wissen, dass sie es
könnten, sollte es einmal nötig sein.
Am Anfang eines Projekts hat es keinen Sinn, die Foren für Benutzer
und Entwickler getrennt zu halten. Es ist viel besser, wenn alle
Projektbeteiligten miteinander reden: in einem "Raum". Unter den ersten
Interessenten eines Projekts ist die Unterscheidung zwischen Entwickler
und Nutzer oft verwaschen. Sofern sie überhaupt gemacht werden kann, gibt
es in den frühen Tagen wesentlich mehr Entwickler im Verhältnis zu
Nutzern als es später der Fall ist. Obwohl Sie nicht annehmen können,
dass jeder, der sich früh für das Projekt interessiert, ein Programmierer
ist, der am Quelltext der Software arbeiten will, können Sie annehmen,
dass sie zumindest daran interessiert sind, die Diskussionen um die
Entwicklung mitzuverfolgen und ein Gefühl für die Richtung des Projekts
zu entwickeln.
Da es in diesem Kapitel nur darum geht wie man ein Projekt startet,
belassen wir es dabei zu sagen, dass diese Foren existieren sollten.
Später, in im Kapitel
, werden wir untersuchen, wo
und wie man diese Foren aufbaut, inwiefern Sie möglicherweise
Moderation erfordern und wie man Foren für Nutzer und Foren für
Entwickler voneinander löst wenn es nötig wird, ohne eine
unüberwindliche Kluft aufzureißen.
Richtlinien für Entwickler
Wenn jemand sich überlegt, etwas zu einem Projekt beizutragen,
wird er sich nach Richtlinien für Entwickler umschauen. Diese sind
weniger technischer, als viel mehr sozialer Natur: Sie erklären, wie
Entwickler miteinander und mit Benutzern umgehen, also letzlich
wie die Dinge laufen sollten.
Dieses Thema wird ausführlich in
im Kapitel
behandelt, aber die
wesentlichen Elemente der Richtlinien sind:
Hinweise auf Foren für die Zusammenarbeit mit
anderen Entwicklern.
Anleitungen wie man Fehler meldet und Patches
einreicht.
Einige Hinweise darauf wie
die Entwicklung für gewöhnlich abläuft – ob das Projekt
eine gütige Diktatur, eine Demokratie oder etwas anderes
ist.
Übrigens soll "Diktatur" in keiner Weise herabsetzend wirken. Es ist
völlig in Ordnung eine Tyrannei zu betreiben, bei dem ein bestimmter
Entwickler das letzte Wort über alle Änderungen haben kann: viele
erfolgreiche Projekte arbeiten in dieser Weise. Das Wichtige dabei ist,
dass das Projekt dies von vornherein klarstellt. Eine Tyrannei, die
vorgibt eine Demokratie zu sein, wird sich Menschen abspenstig machen;
eine Tyrannei die klar sagt was sie ist, wird gut zurecht kommen, sofern
der Tyrann kompetent und vertrauenswürdig ist.
Siehe
für ein Beispiel besonders gründlicher Richtlinien für Entwickler oder
für
allgemeinere Richtlinien, die sich mehr auf die Steuerung und Teilnahme
am Projekt, als auf technische Angelegenheiten konzentrieren.
Das etwas andere Thema, die Bereitstellung einer Projekt-Einführung
für Programmierer, wird im Abschnitt
später in diesem Kapitel behandelt.
Dokumentation
Dokumentation ist unerlässlich. Es muss irgend
etwas zum Lesen geben, selbst wenn es nur rudimentär und
unvollständig ist. Die Dokumentation ist ganz klar ein Teil der vorhin
erwähnten "Plackerei" und sie ist oft das erste, das in einem neuen
Open-Source-Projekt zu kurz kommt. Die Missionsziele und eine Liste von
Funktionen zu schreiben, die Wahl einer Lizenz, den Stand der Entwicklung
zusammenzufassen – das sind alles relativ kleine Aufgaben, die mit
einem Schlag erledigt werden können; und wenn sie erledigt sind, muss man
sich normalerweise nicht weiter damit beschäftigen. Die Dokumentation
hingegen ist nie wirklich fertig, was vielleicht ein Grund dafür ist,
dass man es manchmal hinauszögert, sie überhaupt in Angriff zu
nehmen.
Das heimtückischste daran ist, dass die Autoren der Dokumentation
keinen direkten Nutzen aus ihr ziehen, während sie für neue Nutzer
unerlässlich ist. Die wichtigste Dokumentation für neue Benutzer sind die
Grundlagen: Wie richte ich die Software zügig ein, eine Übersicht über
ihre Funktionsweise, vielleicht auch Anleitungen für häufige Aufgaben.
All dies ist den Autoren nur allzu gut
bekannt – so bekannt, dass es für sie schwierig sein kann, sich in
die Lage der Leser zu versetzen, und mühsam die offensichtlichen
Einzelschritte zu buchstabieren, die aus ihrem Blickwinkel kaum der
Erwähnung wert scheinen.
Es gibt keine magische Lösung für dieses Problem. Es muss sich nur
jemand die Zeit nehmen, alles aufzuschreiben und die Brauchbarkeit der
Dokumentation dann an neuen Nutzern zu testen. Benutzen Sie ein
einfaches, leicht zu bearbeitendes Format wie HTML, Klartext oder eine
XML-Variante – etwas geeignetes für kleine und spontane
Verbesserungen. Das reduziert nicht nur den Aufwand für die ersten
Autoren, die Dokumentation schrittweise zu verbessern, sondern auch
allen, die später zum Projekt hinzukommen.
Eine Möglichkeit, eine erste grundlegende Dokumentation abzusichern
ist es, ihren Umfang von vornherein einzuschränken. So erscheint die
Aufgabe zumindest nicht bodenlos. Als Richtlinie könnte gelten, dass
folgende minimale Bedingungen erfüllt werden:
Sagen Sie dem Leser klar, welche technischen
Kenntnisse erwartet werden.
Beschreiben sie klar und deutlich, wie man die
Software einrichtet, und nennen Sie dem Benutzer irgendwo am
Anfang der Dokumentation, ein Merkmal oder einen Befehl, mit
dem man prüfen kann, ob sie richtig eingerichtet wurde. Die
erste Dokumentation ist in mancherlei Hinsicht wichtiger als
eine echte Bedienungsanleitung. Je mehr Mühe jemand in die
Installation und Einrichtung der Software investiert hat,
desto beharrlicher wird er darin sein, fortgeschrittene,
unzureichend dokumentierte Funktionen zu erfassen. Wenn Leute
aufgeben, passiert es meistens gleich am Anfang; deshalb sind
es die frühsten Phasen wie die Installation, bei der man die
meiste Unterstützung braucht.
Geben Sie Tutorial-artige Beispiele für typische
Aufgaben. Natürlich sind viele Beispiele für viele
Aufgaben noch besser, aber wenn die Zeit knapp ist, wählen
Sie einen Punkt aus und schreiben Sie dazu eine ausführliche
Anleitung. Sobald jemand sieht, dass die Software für eine
Sache benutzt werden kann, wird er
beginnen alleine herauszufinden, wofür sie noch zu gebrauchen
ist – und wenn Sie Glück haben, dazu übergehen, die
Dokumentation selbst zu erweitern. Was uns zum nächsten Punkt
bringt...
Kennzeichnen Sie unvollständige Bereiche der
Dokumentation als solche. Indem Sie dem Leser zeigen, dass
Sie sich über die Defizite im Klaren sind, stellen Sie sich
auf seine Sicht ein. Durch Einfühlungsvermögen geben Sie zu
ihm verstehen, dass das Projekt nicht erst überzeugt werden
muss, was wichtig ist. Solche Kennzeichen entsprechen keiner
Verpflichtung, die Lücken bis zu einem bestimmten Datum
auszufüllen – sie können auch als offenen Anfragen um
Hilfe von Freiwilligen betrachtet werden.
Der letzt Punkt hat tatsächlich umfassendere Bedeutung und kann auf
das ganze Projekt angewendet werden, nicht nur auf die Dokumentation. Eine
genaue Buchführung über bekannte Defizite ist in der Open-Source-Welt die
Norm. Sie müssen die Mängel des Projekts nicht hochspielen, sondern
einfach gewissenhaft und leidenschaftslos aufzählen, wo die Veranlassung
gegeben ist (Das kann in der Dokumentation, im Bugtracker oder in einer
Diskussion auf einer Mailingliste geschehen). Keiner wird das als vom
Projekt ausgehende Miesmacherei ansehen, oder als Verpflichtung die
Probleme bis zu einem bestimmten Datum zu lösen, es sei denn, das Projekt
geht ausdrücklich eine solche Verpflichtung ein. Da jeder Nutzer diese
Mängel selbst finden wird, ist es besser, sie psychologisch darauf
vorbereiten – das gibt den Eindruck, dass im Projekt ein
Bewusstsein über seinen Zustand besteht.
Die Pflege einer FAQ-Liste
Eine FAQ ("Frequently Asked
Questions"Häufig gestellte Fragen)
kann eine der besten Investitionen des Projekts hinsichtlich ihres
Informationsgehalts sein. Eine FAQ ist auf
Fragen abgestimmt, die von Benutzern und
Entwickler wirklich gestellt werden – nicht auf Fragen die Sie
vielleicht erwarten würden – und
deshalb neigt eine gut gepflegte FAQ dazu, denjenigen die sie zu Rate
ziehen, genau das zu geben, wonach sie suchen. Die FAQ ist oft die
erste Stelle, die Benutzer durchsuchen, wenn sie auf ein Problem
stoßen, sie ziehen es oft sogar dem offiziellen Handbuch vor und es
ist wahrscheinlich das Dokument in ihrem Projekt, worauf andere
Seiten am ehesten verweisen.
Leider können Sie die FAQ nicht am Anfang eines Projekts
schreiben. Eine gute FAQ schreibt man nicht, man lässt sie wachsen.
Sie sind schon per Definition auf Rückmeldungen angewiesen. FAQs
entwickeln sich erst mit der Zeit, durch die täglichen Nutzung der
Software. Da es unmöglich ist, die Fragen der Benutzer zu erahnen,
ist es unmöglich sich hinzusetzen und von Grund auf eine nützliche
FAQ zu schreiben.
Verschwenden Sie also nicht Ihre Zeit damit, es zu versuchen.
Sie können jedoch eine größtenteils leere FAQ einrichten, als Vorlage
und offensichtlichen Ort, an dem Leute Fragen und Antworten eintragen
können, wenn das Projekt erst einmal läuft. Zunächst ist wichtigste
Eigenschaft einer FAQ aber nicht ihre Vollständigkeit, sondern ihre
Einfachheit: Wenn es einfach ist, neue Einträge zu anzufügen, wird dies
auch getan werden. (Die vernünftige Pflege einer FAQ ist eine nicht
ganz triviale, aber faszinierende Angelegenheit, die in
im Kapitel
weiter behandelt
wird.)
Erreichbarkeit der Dokumentation
Die Dokumentation sollte an zwei Stellen erreichbar sein: Online
(direkt auf der Website) und in der zum Download
verfügbaren Ausgabe der Software (siehe
im Kapitel
). Sie sollte online in
durchsuchbarer Form vorliegen, weil Interessierte die Dokumentation oft
lesen, bevor sie die Software zum ersten Mal
herunterladen, um besser entscheiden zu können, ob sie dies überhaupt
tun sollen. Prinzipiell, sollte die Dokumentation aber auch der Software
beiliegen, denn ein veröffentlichtes Paket sollte alles enthalten
(d.h. lokal verfügbar machen), was man braucht um die Software zu
benutzen.
Im Falle der Online-Dokumentation sollten Sie für einen Link sorgen,
der auf vollständige Dokumentation auf einer einzigen
HTML-Seite verweist (schreiben Sie einen Hinweis wie "monolitisch" oder
"umfangreiche Einzelseite" daneben, damit die Leser nicht überrascht sind
wenn es beim Laden etwas Zeit braucht). Das ist nützlich, da Leute oft die
ganze Dokumentation nach einem bestimmten Wort oder eine Wendung absuchen
wollen. Im Allgemeinen wissen sie schon, wonach sie suchen, können sich
nur nicht an welcher Stelle es stand. In dieser Situation gibt es nichts
frustrierenderes, als je eine HTML-Seite für Inhaltsangabe, eine für die
Einleitung, eine weitere für die Installationsanleitung, usw zu haben.
Wenn die Seiten so aufgeteilt sind, machen sie die Suchfunktion des
Browsers wertlos. Eine in mehrere Seiten aufgebrochene Dokumentation ist
gut, wenn man weiß, welchen Abschnitt man braucht oder die ganze
Dokumentation von vorne nach hinten durchlesen möchte. Das ist aber
nicht die häufigste Art auf die Dokumentation
zuzugreifen. Viel häufiger kennt sich jemand im Grunde genommen mit
der Software aus und kehrt zurück, um nach einem bestimmten Wort oder
Ausdruck zu suchen. Keine monolitische Datei bereitzustellen, würde in
solchen Fällen das Leben unnötig erschweren.
Entwickler-Dokumentation
Die Entwickler-Dokumentation wird geschrieben, damit Programmierer
den Code verstehen, um ihn reparieren und erweitern zu können. Sie
unterscheidet sich ein wenig zu den vorhin erwähnten
Richtlinien für Entwickler, die eher sozialer als
technischer Natur sind. Entwickler-Richtlinien sagen den Programmierern,
wie sie miteinander zurecht kommen; die Entwickler-Dokumentation
hingegen sagt ihnen, wie sie mit dem Code zurechtkommen. Beide werden
oft der Bequemlichkeit halber gemeinsam in einem Dokument angeboten
(wie im oben erwähnten Beispiel
),
müssen dies jedoch nicht.
Obwohl die Entwickler-Dokumentation sehr hilfreich sein kann,
gibt es keinen Grund, um ihretwillen eine Freigabe zu verzögern. So
lange die ursprünglichen Autoren verfügbar (und bereit) sind, Fragen zum
Code zu beantworten, genügt das für den Anfang. Tatsächlich ist eine
häufige Motivation zum Schreiben der Dokumentation, dass man wieder und
wieder die immer gleichen Fragen beantworten muss. Aber selbst bevor sie
geschrieben ist, wird es entschlossene Freiwillige gelingen, sich einen
Weg durch den Code zu bahnen. Was Menschen dazu treibt, ihre Zeit mit
dem Erarbeiten einer Codebasis zu verbringen, ist das der Code aus
ihrer Sicht etwas Nützliches tut. Solange sie sich dessen gewiss sind,
nehmen sich die Zeit, Probleme zu lösen; ohne diese Zuversicht wird sie
keine auch noch so gute Dokumentation anlocken oder halten
können.
Wenn Sie also nur die Zeit zum Schreiben einer Dokumentation haben,
so schreiben Sie eine für Benutzer. Jede Dokumentation für Benutzer ist
auch für die Entwickler effektiv; jeder Programmierer, der an einer
Software arbeitet, muss auch damit vertraut sein, wie man sie benutzt.
Wenn Sie später sehen, wie Programmierer andauernd die gleichen Fragen
stellen, nehmen Sie sich die Zeit, eine paar separate Dokumente eigens
für sie zu schreiben.
Manche Projekte nutzen Wikis für die allererste Dokumentation, oder
sogar für die Hauptdokumentation. Nach meiner Erfahrung funktioniert das
nur dann, wenn das Wiki aktiv von einer Handvoll Leuten bearbeitet wird,
die hinsichtlich der Organisation und des Tonfalls der Dokumentation
einig sind. Mehr dazu steht in
im Kapitel
.
Beispiel-Ausgaben und Screenshots
Ein Projekt mit graphischer Benutzeroberfläche oder graphischen
oder anderen markanten Ausgaben sollte Beispiele auf der Website des
Projekts anbieten. Im Fall einer Benutzeroberfläche wären es Screenshots;
für Ausgaben können es Screenshots oder vielleicht nur Dateien sein.
Beide befriedigen das Bedürfnis des Menschen nach direkter Belohnung:
Ein einziges Bild kann überzeugender sein, als ganze Abstätze von
Beschreibungen oder Geplapper auf Mailinglisten, denn ein Bild
ist ein unverkennbarer Beweis dafür, dass die Software
funktioniert. Sie mag ihre Fehler haben, schwer
zu installieren und unvollständig dokumentiert sein, aber ein Bild ist
immerhin ein Beweis, dass man sie zum Laufen bringen kann,
wenn man sich nur genug Mühe gibt.
Screenshots
Screenshots können einschüchtern, wenn man noch nie welche
gemacht hat, deshalb hier ein kleine Anleitung. Mit "The Gimp"
(), öffnen Sie
Datei->Erstellen->
Bildschirmfoto..., und wählen Sie
Ein einzelnes Fenster aufnehmen
oder
Den ganzen Bildschirm aufnehmen,
klicken Sie dann
auf Aufnehmen. Ziehen Sie nun den
Kreuz-Cursor auf das gewünschte Fenster (dieser Schritt entfällt bei
ganzem Bildschirm) um das Bild in The Gimp aufzunehmen.
Ändern und schneiden Sie anschließend das Bild bei Bedarf
nach den Anweisungen auf .
Sie können der Website des Projekts noch vieles mehr hinzufügen,
wenn die Zeit dazu reicht, oder wenn es aus irgend einem Grund besonders
passend erscheint: Eine Seite mit Neuigkeiten, eine Seite mit der
Historie des Projekts, eine Seite mit verwandten Links, eine
Suchfunktion, ein Link für Spenden, usw. Nichts davon ist am Anfang
notwendig, aber man sollte es für später im Hinterkopf behalten.
Hosting-Pakete
Es gibt ein paar Sites die kostenlos die Infrastruktur für
Open-Source-Projekte bereitstellen: einen Web-Bereich, Versionsverwaltung,
einen Bugtracker, einen Download-Bereich, Foren, regelmäßiges Backup
usw. Die Details unterscheiden sich zwar von Site zu Site, aber das
Wesentliche wird bei allen angeboten. Durch die Nutzung dieser Sites
erhalten Sie vieles umsonst, müssen dafür aber die Kontrolle über die
Benutzerführung teilweise aufgeben. Der Hosting-Dienst entscheidet
darüber, welche Software die Site benutzt, und kann so Look and Feel
der Projektseiten bestimmen oder zumindest beeinflussen.
Siehe
im Kapitel
für eine
detailliertere Diskussion über Vor- und Nachteile von Hosting-Paketen
und eine Liste von Sites die sie anbieten.
Die Wahl einer Lizenz
Dieser Abschnitt soll eine schnelle und sehr grobe Anleitung zur
Wahl einer Lizenz bieten. Lesen Sie um die
rechtlichen Folgen der verschieden Lizenzen im Detail besser zu verstehen
und zu erkennen, inwiefern sich Ihre Lizenz-Entscheidung auf die
Möglichkeit auswirkt, Ihre Software mit anderer freier Software zu
kombinieren.
Sie können aus einer Menge von Lizenzen für freie Software wählen.
Die meisten müssen wir hier nicht beachten, da sie für die speziellen
rechtlichen Bedürfnisse einer bestimmten Firma oder Person geschrieben
wurden und für Ihr Projekt nicht angemessen wären. Wir beschränken uns
auf die üblichsten Lizenzen; in den meisten Fällen werden Sie sich für
eine von ihnen entscheiden wollen.
"Alles ist erlaubt"-Lizenzen
Wenn Sie kein Problem damit haben, dass der Code Ihres Projekts
in proprietären Anwendungen benutzt wird, können Sie eine
MIT/X-artige Lizenz nutzen. Es ist die einfachste
der verschiedenen Minimal-Lizenzen, die wenig mehr leisten als die
Vervielfältigungsrechte abzusichern (ohne dabei wirklich die
Vervielfältigung einzuschränken) und zu erklären, dass keiner für den
Code haftet. Weiteres darüber finden Sie in
.
Die GPL
Wenn Sie nicht wollen, dass Ihr Code in proprietären Anwendungen
verwendet wird, benutzen Sie die GNU General Public
LicenseAllgemeine Öffentliche Lizenz
(). Die GPL ist
heute die wahrscheinlich bekannteste Lizenz für freie Software der
Welt. Das ist an und für sich schon ein großer Vorteil, da viele
potentielle Benutzer und Teilnehmer bereits mit ihr vertraut sein
werden und deshalb keine zusätzliche Zeit aufbringen müssen, um Ihre
Lizenz zu lesen und zu verstehen. Für weiter Details siehe
in .
Wenn die Benutzer auf Ihren Code vorwiegend über ein Netzwerk
zugreifen – d.h. wenn die Software typischerweise Teil eines
Hostingdienstes ist – dann sollten Sie alternativ die Wahl der
GNU Affero GPL in Betracht ziehen. Siehe
in
für weitere Informationen.
Eine Lizenz für Ihre Software
Wenn Sie sich einmal für eine Lizenz entschieden haben, müssen
Sie diese auf Ihre Software anwenden.
Dazu sollten Sie diese zunächst auf Ihrer Website
klar bennennen. Sie müssen dort nicht den vollständigen Text dieser
Lizenz angeben; der Name und ein Verweis auf den vollständigen Text
genügen für's erste. So erklären Sie der Öffentlichkeit, unter welcher
Lizenz Sie beabsichtigen, die Software zu
veröffentlichen, rechtlich gesehen reicht das natürlich nicht. Dafür
muss die Software selbst die Lizenz enthalten.
Der übliche Weg dies zu tun ist, den vollständigen Text der Lizenz
in einer Datei namens COPYING (oder
LICENSE) abzulegen; dann fügen sie jeder
Quellcode-Datei am Beginn eine knappe Notiz hinzu, in der Sie
Copyright-Datum, -Inhaber und Lizenz benennen und angeben, wo der
vollständige Text der Lizenz zu finden ist.
Davon gibt es viele Variationen, also werden wir uns hier nur
ein Beispiel anschauen. Die GNU GPL sagt, dass man einen Hinweis wie
diesen an den Anfang jeder Datei des Quellcodes setzen sollte.
Copyright (C) [Jahr] [Name des Autors]
Dieses Programm ist freie Software. Sie können es unter den
Bedingungen der GNU General Public License, wie von der Free Software
Foundation veröffentlicht, weitergeben und/oder modifizieren, entweder
gemäß Version 2 der Lizenz oder (nach Ihrer Option) jeder späteren
Version.
Die Veröffentlichung dieses Programms erfolgt in der Hoffnung, dass es
Ihnen von Nutzen sein wird, aber OHNE IRGENDEINE GARANTIE, sogar ohne
die implizite Garantie der MARKTREIFE oder der VERWENDBARKEIT FÜR
EINEN BESTIMMTEN ZWECK. Details finden Sie in der GNU General Public
License.
Sie sollten ein Exemplar der GNU General Public License zusammen mit
diesem Programm erhalten haben. Falls nicht, schreiben Sie an die Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110, USA.Diese Übersetzung von Katja Lachmann im
Auftrag der S.u.S.E. GmbH – und
überarbeitet von Peter
Gerwinski, G-N-U GmbH – ,
wird hier zum besseren Verständnis verwendet. In Ihrer
Anwendung sollten Sie jedoch die Englische Originalfassung benutzen, die
Sie hier
finden, da diese Übersetzung nicht offiziell oder im rechtlichen Sinne
anerkannt ist. Die vollständige Übersetzung der GPL finden Sie hier
Damit drücken Sie nicht explizit aus, dass der vollständige Text der
Lizenz in der Datei COPYING steht, es ist aber
meistens der Fall. (Sie können den obigen Hinweis abändern um dies
direkt auszudrücken.) Diese Vorlage enthält auch die Post-Adresse, über
die eine Kopie der Lizenz bezogen werden kann. Noch häufiger wird auf die
eine Webseite verwiesen, die den kompletten Text der Lizenz enthält.
Konsultieren Sie einen Juristen (oder vertrauen Sie Ihrem eigenem
Rechtsverständnis, falls Sie keinen Juristen zur Hand haben), hinsichtlich
der Entscheidung, wo die beständigste Kopie dieser Lizenz gepflegt wird,
vielleicht ist es auch einfach die Webseite Ihres Projekts.
Im Allgemeinen muss der Hinweis am Anfang jeder Datei nicht genau so
aussehen wie der obige, sofern er mit dem Hinweis auf Inhaber des
Copyrights, Datum und Lizenz ausgestattet ist und dem Hinweis, wo der
komplette Lizenztext zu finden ist.
Den Ton angeben
Bis jetzt haben wir Aufgaben behandelt die einmal beim
Aufbau des Projekts zu erledigen sind: Eine Lizenz wählen, die
Website einrichten usw. Die wichtigsten Aspekte beim Start
eines Projekts sind aber dynamisch. Es ist einfach, eine Adresse für
eine Mailingliste zu wählen; aber dafür zu sorgen, dass dort die
Kommunikation beim Thema und produktiv bleibt, ist eine ganz andere
Sache. Wenn das Projekt nach Jahren der geschlossenen Entwicklung
geöffnet wird, verändert sich der Entwicklungsprozess, und Sie werden die
bestehenden Entwickler auf diesen Wandel vorbereiten müssen.
Die ersten Schritte sind die schwersten, da es für zukünftiges
Verhalten noch keine Beispiele oder Erwartungen gibt, nach denen man
sich richten könnte. Beständigkeit in einem Projekt entsteht nicht durch
formale Richtlinien, sondern durch eine von allen geteilte, schwer
greifbare, kollektive Weisheit, die sich mit der Zeit entwickelt. Oft
gibt es auch geschriebene Regeln, die aber im wesentlichen eine
Zusammenfassung der sich fortwährend weiterentwickelnden Vereinbarungen
sind, an denen sich das Projekt wirklich orientiert. Die schriftlichen
Richtlinien legen die Kultur des Projekts nicht fest, sondern beschreiben
sie eher, und selbst das nur näherungsweise.
Dafür gibt es ein paar Gründe. Wachstum und hohe Fluktuation sind
keineswegs so schädlich für die Herausbildung sozialer Normen,
wie man vielleicht denken würde. So lange Veränderungen nicht
zu schnell ablaufen, haben auch Neulinge Zeit,
Abläufe zu lernen, später werden sie diese Regeln selbst anzuwenden und
durchsetzen. Bedenken Sie, wie Kinderlieder Jahrhunderte überdauern. Es
gibt heute Kinder die ungefähr die gleichen Lieder singen wie Kinder
vor hunderten von Jahren, auch wenn keines von ihnen heute noch am
Leben ist. Jüngere Kinder hören die Lieder, wie sie von den älteren
gesungen werden und wenn sie wiederum älter sind, singen sie vor den
anderen jüngeren Kindern. Dabei geben sie die Lieder natürlich nicht
bewusst weiter, aber die Lieder überleben trotzdem, weil sie
regelmäßig und weitergegeben werden. Die Lebenszeit freier
Software-Projekte wird vielleicht nicht in Jahrhunderten gemessen
(zumindest bis noch nicht), aber die Dynamik der Übertragung ist
ziemlich dieselbe. Die Fluktuation ist allerdings viel höher und
muss bei der Weitergabe durch eine aktivere und bewusstere
Anstrengungen ausgeglichen werden.
Diese Anstrengung wird dadurch unterstützt, dass Neuankömmlige
für gewöhnlich soziale Normen erwarten und auch suchen.
Das liegt einfach in der Natur des Menschen. In einer Gruppe,
die durch ein gemeinsames Bestreben vereint ist, sucht man
instinktiv nach Verhaltensmustern, um sich als Mitglied dieser Gruppe
darzustellen. Sie sollten früh Beispiele setzen, um das Verhalten
der Mitglieder so zu beeinflussen, dass es für das Projekt nützlich
ist; einmal etabliert, werden sie überwiegend von selbst
weiterbestehen.
Es folgen ein paar Beispiele, um gute Präzedenzfälle zu setzen.
Es ist keine ausführliche Liste, sondern lediglich eine Veranschaulichung
der Idee, dass es hilfreich ist, die Stimmung für die Zusammenarbeit
im Projekt bereits frühzeitig zu prägen. Rein physikalisch mögen die
einzelnen Entwickler jeder für sich in einem Raum arbeiten,
Sie können jedoch eine Menge dafür tun, ihnen das
Gefühl zu geben, sie würden alle in einem gemeinsamen
Raum arbeiten. Je mehr sie sich so fühlen, desto mehr Zeit werden sie
für das Projekt aufwenden wollen. Ich habe diese Beispiele gewählt, da
sie in dem Subversion-Projekt aufkamen,
(), das ich seit seiner
Gründung tätig und beobachtend begleite. Sie gelten aber nicht
allein für Subversion; diese Situationen werden in den meisten
Open-Source-Projekten aufkommen, und sie sollten als Gelegenheit
betrachtet werden, die Dinge auf dem richtigen Fuß zu erwischen.
Private Diskussionen vermeiden
Selbst nachdem Sie ein Projekt an die Öffentlichkeit gebracht
haben, werden Sie und die anderen Gründungsmitglieder manchmal damit
konfrontiert werden, schwierige Fragen innerhalb eines kleineren
Kreises durch private Kommunikation lösen zu müssen. Das gilt besonders
am Anfang des Projekts, wo viele wichtige Entscheidungen zu treffen
sind und es meist nur wenige Freiwillige gibt, die qualifiziert wären,
sie zu treffen. All die offensichtlichen Nachteile öffentlicher
Diskussionen auf Mailinglisten werden greifbar vor Ihnen liegen:
Die bei E-Mail-Diskussionen unvermeidbare Verzögerung, die für einen
Konsens erforderliche Zeit, die Mühe sich mit naiven Freiwilligen
auseinandersetzen zu müssen die meinen, alles zu verstehen (solche gibt
es in jedem Projekt; manchmal bringen sie im nächsten Jahr die besten
Beiträge, manchmal bleiben sie ewig naiv), die Person die nicht
versteht, warum Sie nur das Problem X lösen wollen, wenn es
offensichtlich eine Untermenge des größeren Problems Y ist, usw. Die
Verlockung, diese Unterhaltungen hinter verschlossenen Türen zu führen
und sie als vollendete Tatsache zu präsentieren oder zumindest als
nachdrückliche Empfehlung einer vereinigten und einflussreichen
Wählergruppe, ist tatsächlich groß.
Tun Sie's nicht.
So langsam und mühselig öffentliche Diskussionen auch sein mögen,
sie sind auf lange Sicht trotzdem vorzuziehen. Wichtige Entscheidungen
privat zu treffen, ist Gift für Freiwillige. Kein Freiwilliger der seine
Sache ernst meint, würde es lange in einer Umgebung aushalten, in dem
alle wichtigen Entscheidungen von einer geheimen Versammlung getroffen
werden. Desweiteren hat die öffentliche Diskussion den Vorteil, dass
ihre positiven Nebenwirkungen viel länger fortbestehen als die
kurzlebige technische Frage um die es geht:
Die Diskussion wird dabei helfen, neue Entwickler auszubilden
und zu unterrichten. Sie können nie wissen, wie viele Augen die
Diskussion beobachten; selbst wenn die Meisten sich nicht
beteiligen, kann es sein, dass viele sie im Stillen mitverfolgen,
um Informationen über das Projekt zu sammeln.
Bei der Diskussion werden Sie die Kunst
erlernen, technische Angelegenheiten für Leute zu erklären die
mit der Software nicht so vertraut sind wie Sie. Das ist eine
Fähigkeit, die Übung erfordert und nicht durch die Unterhaltung
mit Ebenbürtigen erlangt werden kann.
Die Diskussion und ihre Ergebnisse werden auf ewig in den
öffentlichen Archiven verfügbar sein und es zukünftigen
Diskussionen ermöglichen, Wiederholungen zu vermeiden. Siehe
im
Kapitel.
Schließlich besteht die Möglichkeit, dass jemand auf der
Mailingliste einen echten Beitrag zu der Diskussion leisten könnte, indem
er eine Idee aufbringt, an die Sie nie gedacht hätten. Es ist schwer zu
sagen, wie wahrscheinlich das ist; es hängt schlicht von der Komplexität
des Problems und dem erforderlichen Grad der Spezialisierung ab.
Wenn ich aber ein Beispiel anführen darf, wage ich zu behaupten, dass
es viel wahrscheinlicher ist, als man es intuitiv erwarten würde. Im
Subversion-Projekt glaubten wir (die Gründer), mit einer tiefen und
komplexen Problematik konfrontiert zu sein, über die wir uns
seit ein paar Monaten viele Gedanken gemacht hatten; und offen gesagt
zweifelten wir daran, dass irgendjemand auf der kürzlich eingerichteten
Mailingliste etwas Wertvolles zu der Diskussion beizutragen hätte.
Wir nahmen also den einfachen Weg und begannen, unsere technischen
Ideen in privaten E-Mails untereinander auszutauschen, bis ein
Beobachter des ProjektsWir haben zwar noch nicht das
Thema der Namensnennung und Anerkennung angesprochen, aber um auch zu
praktizieren, was ich später predigen werde: Der Name des Beobachters
war Brian Behlendorf; und er war es, der darauf hingedeutet hat, wie
wichtig es ist, alle Diskussionen öffentlich zu halten, es sei denn es
gibt einen bestimmten Grund für Geheimhaltung. davon
Wind bekam und uns bat, die Diskussion auf die öffentliche Mailingliste
zu verlegen. Wir verdrehten zwar ganz schön die Augen, taten es aber
– und waren ganz erstaunt über die Anzahl aufschlussreicher
Kommentare und Vorschläge, die sich recht schnell ergaben. In vielen
Fällen boten Leute Ideen an, die uns nie in den Sinn gekommen wären. Es
stellte sich heraus, dass ein paar sehr kluge Köpfe
auf dieser Liste waren; sie hatten nur auf den richtigen Köder
gewartet. Es ist wahr, dass die resultierenden Diskussionen länger
dauerten, als wenn wir sie privat gehalten hätten, allerdings waren sie
um vieles produktiver, was die zusätzliche Zeit in jedem Fall wert
war.
Ohne in allzu verallgemeinernde Aussagen, wie "Die Gruppe ist
immer schlauer als der Einzelne" abzugleiten (wir kennen alle genügend
Gruppen, die daran zweifeln lassen), muss man doch anerkennen, dass es
bestimmte Aktivitäten gibt, für die Gruppen besonders geeignet sind.
Ausführliche Gutachten sind eine; schnell auf viele Ideen zu kommen
eine weitere. Die Qualität dieser Ideen hängt natürlich davon ab,
wie hochwertig die Gedanken waren, die man hineingesteckt hat. Sie
werden aber nie erfahren, was für geistreiche Denker da draußen sind,
solange Sie ihnen keine echten Herausforderungen bieten.
Es gibt natürlich auch Diskussionen, die man im Privaten führen
muss; im Verlauf des Buches werden wir Beispiele dafür sehen. Das leitende
Prinzip sollte aber sein: Solange es keinen Grund gibt, etwas
privat zu regeln, sollte es öffentlich geschehen.
Dies in Gang zu setzen, erfordert Ihre Einflussnahme. Es
reicht nicht lediglich sicherzustellen, dass Ihre eigenen Nachrichten
an die öffentliche Mailingliste gehen; Sie müssen auch andere dazu
bewegen, ihre unnötig privaten Unterhaltungen öffentlich zu halten. Wenn
jemand versucht, eine private Diskussion anzufangen, und es keinen Grund
gibt, sie privat zu halten, sollten Sie sich verpflichtet fühlen, sofort
eine angemessene übergeordnete Diskussion zu eröffnen. Sie sollten nicht
einmal direkt auf das Thema eingehen, bevor Sie nicht entweder die
Diskussion erfolgreich an einem öffentlichen Ort gelenkt haben oder
deutlich erkannt haben, dass sie tatsächlich besser privat gehalten werden
sollte. Wenn Sie sich konsequent so verhalten, werden die Beteiligten es
ziemlich schnell mitbekommen und gleich die öffentlichen Foren
benutzen.
Unhöflichkeit im Keim ersticken
Sie sollten von Anfang an, gleich nachdem Ihr Projekte an die
Öffentlichen geht, null Toleranz gegenüber unhöflichem oder
beleidigendem Verhalten in seinen Foren zeigen. Null Toleranz heißt
nicht unbedingt, diese technisch durchzusetzen. Sie sollten diese Leute
nicht aus der Liste entfernen, wenn sie einen anderen Teilnehmer
"flamen", oder ihnen wegen abfälligen Bemerkungen den Commit-Zugriff
entziehen. (Theoretisch müssten Sie eventuell auf solche Mittel
zurückgreifen, aber erst nachdem alle anderen erschöpft sind – was
am Anfang eines Projekts per Definition noch nicht der Fall ist.) Null
Toleranz bedeutet, schlechtes Benehmen niemals einfach unbemerkt
geschehen zu lassen. Wenn jemand zum Beispiel eine technische
Bemerkung zusammen mit einem argumentum ad
hominem gegen einem anderen Entwickler koppelt, ist es
zwingend notwendig, dass Ihre Reaktion als erstes
den persönlichen Angriff anspricht, als separate Angelegenheit, und erst
dann auf den technischen Inhalt eingeht.
Leider ist es sehr leicht und allzu üblich, dass konstruktive
Diskussionen in destruktive "flame wars" ausarten. Menschen werden
Dinge sagen, die sie nie von Angesicht zu Angesicht sagen würden. Die
Themen dieser Diskussionen verstärken nur diesen Effekt: Bei
technischen Angelegenheiten glauben Menschen oftmals, dass es nur eine
richtige Antwort zu den meisten Fragen gibt und dass eine
Abweichung von ihrer Antwort nur durch Ignoranz oder
Dummheit des Anderen erklärt werden kann. Den Vorschlag einer Person als
dämlich zu bezeichnen, ist oft nur einen winzigen Schritt davon entfernt,
die Person selbst als dämlich zu bezeichnen. Tatsächlich ist es oft schwer
zu unterscheiden, wo die technische Diskussion aufhört und die persönliche
Beleidigung anfängt, was auch ein Grund ist warum drastische Maßnahmen
oder Bestrafungen nicht angebracht sind. Sie sollten stattdessen, sobald
Ihnen derartiges auffällt, eine Nachricht schreiben, die nachdrücklich
darauf hinweist wie wichtig es ist, die Unterhaltung in einem freundlichen
Ton zu führen, ohne dabei jemanden zu beschuldigen, absichtlich giftig
gewesen zu sein. Leider hören sich diese "Netter-Polizist"-Nachrichten
meist an wie die Predigt einer Vorschullehrerin, die ihre Klasse
über gutes Benehmen belehrt:
Lasst uns bitte zuerst mit den u.U. ad hominem
Bemerkungen aufhören; J's Entwurf der Sicherheitsschicht als "naiv
und dumm gegenüber allen Grundprinzipien der Informationssicherheit"
zu bezeichnen. Ob das so stimmt
oder nicht, es ist in jedem Fall nicht die Art, eine Diskussion zu
führen. J hat seinen Entwurf in guter Absicht vorgeschlagen.
Wenn er Fehler aufweist, weist darauf hin und wir werden sie
beheben oder einen neuen Entwurf suchen. Ich bin mir sicher, dass
M niemanden persönlich beleidigen wollte, aber er hat sich
unglücklich ausgedrückt, und wir wollen versuchen, hier
konstruktiv zu bleiben.
Und jetzt zu dem Entwurf. Ich denke M hatte recht
als er sagte, ...
So gestelzt sich solche Antworten auch anhören, sie haben doch
eine messbare Wirkung. Wenn Sie immer wieder auf solches Verhalten
hindeuten, aber keine Entschuldigung von der angreifenden Partei
fordern, lassen Sie ihr die Möglichkeit, sich abzuregen und ihre
bessere Seite zu zeigen, indem sie sich beim nächsten mal anständiger
benimmt – und das wird sie. Eines der Geheimnisse, erfolgreich
gegen solches Verhalten vorzugehen, ist niemals die untergeordnete
Diskussion zum Hauptthema werden zu lassen. Es sollte immer nur
nebenbei erwähnt werden, ein kurzes Vorwort zu der eigentlichen Antwort.
Weisen Sie im Vorbeigehen darauf hin, dass "wir hier so nicht arbeiten",
aber gehen Sie dann weiter zum echten Inhalt, damit die Beteiligten immer
etwas zum Thema haben, worauf sie antworten können. Wenn protestiert,
dass er unrechtmäßig zurechtgewiesen wurde, sollten Sie sich nicht
in einem Streit verzetteln. Antworten Sie entweder gar nicht (wenn
Sie denken, dass die Person nur Dampf ablassen will und nicht wirklich
eine Antwort erwartet), oder entschuldigen Sie sich für die übertriebene
Reaktion und schreiben Sie, dass es schwer ist, Nuancen aus einer E-Mail
herauszulesen. Gehen Sie danach aber wieder zum eigentlichen Thema
über. Bestehen Sie niemals auf einer Antwort, privat oder öffentlich,
von jemandem, der sich unangemessen verhalten hat. Wenn er sich von
sich aus entschuldigt, ist das großartig, aber es von ihm zu verlangen,
würde nur Verbitterung heraufbeschwören.
Das übergeordnete Ziel ist, dass gute Umgangsformen zu einem
wesentlichen Merkmal in der Kerngruppe werden. Das hilft dem Projekt, da
Entwickler durch "flame wars" vertrieben werden können (sogar von
Projekten die sie mögen und unterstützen). Es kann passieren, dass Sie
ihre Vertreibung nicht einmal mitbekommen; Mancher könnte sich die Liste
anschauen, erkennen dass er ein dickeres Fell bräuchte, um an diesem
Projekt teilzunehmen, und verzichtet daraufhin besser gleich ganz auf die
Teilnahme. Foren freundlich zu halten, ist auf
lange Sicht eine Überlebenstaktik und das ist einfacher,
wenn das Projekt noch klein ist. Ist es erst zu einem Teil der Kultur
geworden, werden Sie nicht mehr der einzige sein, der sich darum bemüht.
Jeder wird daran mitwirken.
Code Review
Eine der besten Möglichkeiten, eine produktive
Entwicklergemeinschaft zu fördern ist es, Leute zu überreden, sich
gegenseitig Ihren Code anzuschauen. Das effektiv zu gewährleisten,
erfordert ein wenig technische Infrastruktur – insbesondere sollten
Commit-E-Mails angeschaltet werden; siehe
für Details hierzu. Commit-E-Mails
sorgen dafür, dass jede Änderung am Quellcode eine E-Mail zur Folge hat
mit dem zugehörigen Kommentar des Autors und den Diffs (siehe
im Kapitel
). Code Review
heißt, diese Commit-E-Mails beim Eintreffen auch durchzulesen und nach
Fehlern und möglichen Verbesserungen zu suchen. So
wird Review zumindest in Open-Source-Projekten praktiziert. Für
zentralisierte Projekte kann "Code Review" auch bedeuten, dass mehrere
Personen gemeinsam den ausgedruckten Code durchgehen und nach
bestimmten Problemen und Mustern suchen.
Code Review dient mehreren Zwecken gleichermaßen. Er ist das
offensichtlichste Beispiel für "Peer Review" in der Open-Source-Welt
und hilft unmittelbar, die Qualität der Software zu erhalten. Jeder
Fehler, der in einer Software ausgeliefert wird, kam durch einen Commit
zustande der übersehen wurde; es werden umso weniger Fehler in einer
veröffentlichten Version sein, je mehr Augen auf jeden Commit
gerichtet sind. Code Review dient aber auch einem indirekten Zweck: Es
bestätigt Menschen, dass ihre Arbeit Bedeutung hat, man würde sich
schließlich nicht die Zeit nehmen über einen Commit zu schauen, wenn es
einen nicht interessieren würde, welche Auswirkungen er hat. Menschen
leisten dann die beste Arbeit wenn sie wissen, dass andere sich
die Zeit nehmen, diese zu prüfen.
Jeder Review sollte öffentlich durchgeführt werden. Selbst wenn
ich im selben Raum mit anderen Entwicklern bin und einer
von uns einen Commit macht, achten wir darauf, den Review nicht verbal
im Raum zu führen, sondern ihn über die Entwickler-Liste zu schicken.
Jeder profitiert davon, wenn der Review sichtbar ist. Leute folgen den
Erläuterungen und finden darin manchmal Mängel und selbst wenn nicht,
erinnert es sie zumindest daran, dass Code Review eine zu erwartende
regelmäßige Aktivität ist, wie Geschirrspülen oder Rasenmähen.
Im Subversion-Projekt hatten wir am Anfang nicht diese
Gewohnheit. Es gab keine Garantie, dass jeder Commit überprüft wurde,
wir schauten zwar manchmal über bestimmte Änderungen, wenn ein
bestimmter Bereich im Quellcode besonders interessant schien. Es
schlichen sich Fehler ein, die man eigentlich hätte sehen sollen und
müssen. Ein Entwickler namens Greg Stein, der aus seiner vorherigen
Arbeit den Wert von Code Review kannte, entschied sich, ein Beispiel zu
setzen, indem er sich jede Zeile von jedem einzelnen
Commit anschaute. Auf jedem Commit, den irgendjemand machte,
folgte bald eine E-Mail von Greg an den Entwickler-Liste, indem er
den Commit sezierte, mögliche Probleme analysierte und ab und zu, für
besonders cleveren Code, ein Lob aussprach. Sofort begann er, Fehler
und problematische Programmierpraktiken zu entdecken, die ansonsten
durchgerutscht wären, ohne je bemerkt zu werden. Er beschwerte sich
wohlgemerkt nie, dass er der einzige sei, der Code Review betrieb, auch
wenn es keinen unwesentlichen Teil seiner Zeit in Anspruch nahm, er
lobte bei jeder Gelegenheit die Vorteile von Code Review. Ziemlich bald
fingen andere an, ich eingeschlossen, regelmäßig Commits zu überprüfen.
Was war unsere Motivation? Greg hatte uns nicht bewusst durch Beschämung
dazu gebracht. Er hatte bewiesen, dass Code Review eine wertvolle
Investition von Zeit ist und dass man durchaus auch zum Projekt
beitragen kann, wenn man die Änderungen anderer durchsieht, anstatt selbst
neuen Code zu schreiben. Nachdem er das demonstriert hatte, wurde
es zum erwarteten Verhalten. Das ging sogar soweit, dass man sich, wenn
auf einen Commit keine Reaktion folgte, als Committer Sorgen machte und
sogar auf der Liste nachfragte, ob denn niemand die Zeit gefunden
hätte, es sich anzuschauen. Später bekam Greg eine Arbeit, die ihm nicht
so viel Zeit für Subversion ließ, und er musste mit dem regelmäßigen
Code Review aufhören. Aber inzwischen war die Angewohnheit unter uns
anderen bereits so weit verbreitet, als sei es nie anders gewesen.
Beginnen Sie mit Code Reviews vom allerersten Commit an. Probleme
die man am einfachsten bei der Durchsicht von Diffs erkennt, sind
Sicherheitslücken, Speicherlecks, ungenügende Kommentare oder
Dokumentation von Schnittstellen, Eins-daneben-Fehler,
Aufrufer-Aufgerufener-Divergenzen
und andere Probleme, deren Entdeckung keinen großen
Kontext erfordern. Selbst Angelegenheiten größeren Umfangs,
wie z.B. häufig auftauchende Muster, nicht an einer gemeinsamen
Stelle zu abstrahieren, werden leichter erkennbar, wenn man Code
Review regelmäßig betreibt, weil man sich an vergangene Diffs
erinnert.
Machen Sie sich keine Sorgen, dass Sie nichts finden, worüber es
etwas zu sagen gäbe, oder dass Sie nicht genug über alle Bereiche im
Code wissen. Es gibt meistens irgendetwas über so ziemlich jeden Commit
zu sagen; selbst wenn Sie nichts Bedenkliches finden, kann es sein, dass
Sie etwas Lobenswertes finden. Wichtig ist, jedem der Committer
klar zu machen, dass ihre Arbeit gesehen und verstanden wird. Natürlich
befreit Code Review die Programmierer nicht von der Verantwortung, ihre
Änderungen vor dem Commit zu überprüfen und zu testen; niemand sollte
sich auf Code Review verlassen, um Fehler zu finden, die er eigentlich
selbst hätte finden sollen.
Der Übergang ehemals geschlossener Projekte zu Open Source
Wenn Sie ein bestehendes Projekt mit aktiven Entwicklern,
die eine Umgebung mit geschlossenem Code gewohnt sind, sorgen Sie dafür,
dass Klarheit über den Umfang der Änderungen besteht, die auf die
Entwickler zukommen – und versuchen Sie sich so gut wie möglich
in ihre Lage zu versetzen.
Versuchen Sie sich die Situation aus ihrer Sicht vorzustellen:
vorher wurden Entscheidungen über Code und Architektur in einer Gruppe
von Programmierern getroffen, die sich alle mehr oder weniger gleich
gut mit der Software auskannten, die alle den gleichen Druck von oben
zu spüren bekamen und die sich alle gegenseitig in ihren Stärken und
Schwächen kannten. Jetzt verlangen Sie von ihnen, ihren Code
freizugeben, nur damit irgendwelche Fremden ihn auseinandernehmen,
untersuchen und sich eine Meinungen über ihn bilden, allein anhand des
Quellcodes den sie sehen, ohne zu wissen, welcher geschäftlicher Druck
Sie zu bestimmten Entscheidungen gezwungen hat. Diese Fremden werden
viele Fragen stellen, Fragen die vorhandene Entwickler aufrütteln
werden, wenn Sie feststellen müssen, dass die Dokumentation, an der sie
so hart gearbeitet haben, immer noch lückenhaft
ist (das ist unvermeidbar). Um dem ganzen noch ein Sahnehäubchen
aufzusetzen: die Neulinge sind unbekannte, gesichtslose Wesen. Wenn einer
Ihrer Entwickler sich seiner Fähigkeiten als Programmierer unsicher
ist, stellen Sie sich vor, wie es ihn erst verbittern wird, wenn die
Neulinge auf Mängel in seinem Code hinweisen, noch dazu vor
seinen Kollegen. Wenn Sie kein Team von perfekten Programmierern
haben, ist sowas unvermeidlich – tatsächlich wird es am Anfang
wahrscheinlich allen passieren. Nicht weil sie schlechte
Programmierer sind; sondern weil jedes Projekt oberhalb einer bestimmten
Größe zwangsläufig Fehler beinhaltet, und die Überprüfung durch eine
Gemeinschaft manche dieser Fehler aufdecken wird (siehe
früher in
diesem Kapitel). Gleichzeitig werden die neuen Freiwilligen
selber nicht so sehr dieser Prüfung unterliegen, da sie selber noch
keinen Code beisteuern können, bis sie mehr mit dem Projekt vertraut
sind. Für Ihre Entwickler kann das erscheinen, als ob die ganze Kritik
immer nur auf sie gerichtet ist und nie nach außen geht. Es besteht
deshalb die Gefahr, dass sich unter den alten Hasen eine
Belagerungsmentalität einstellt.
Am besten kann man das verhindern, indem man alle vorwarnt, was
auf Sie zukommt, es ihnen erklärt, ihnen sagt, dass ein anfängliches
Unbehagen völlig normal ist, und ihnen versichert, dass es mit der Zeit
besser wird. Manche dieser Warnungen sollten privat geschehen, bevor das
Projekt geöffnet wird. Es könnte aber auch hilfreich sein, die Leute
auf der Mailingliste zu erinnern, dass es für das Projekt eine neue
Art der Entwicklung ist und dass die Anpassung eine gewisse Zeit
brauchen wird. Das beste was Sie machen können, ist als gutes Beispiel
voranzugehen. Wenn Sie sehen, dass Ihre Entwickler nicht genügend
Fragen der neuen Freiwilligen beantworten, nützt es nichts, ihnen zu
sagen, dass sie mehr antworten sollten. Es mag sein, dass sie kein gutes
Gefühl dafür haben, wann eine Reaktion gerechtfertigt ist, oder es kann
sein, dass sie nicht wissen, welche Priorität die eigentliche Arbeit am
Code gegenüber der neuen Bürde einnimmt, mit Außenstehende zu
kommunizieren. Man kann sie am ehesten dazu überreden, sich zu beteiligen,
indem man sich selbst beteiligt. Beobachten Sie die öffentliche
Mailingliste und beantworten Sie ein paar Fragen. Wenn Sie nicht genügend
Erfahrung haben, um die Fragen zu beantworten, sollten Sie es für alle
sichtbar an einem anderen Entwickler weitergeben, der die nötige
Erfahrung hat – und achten Sie darauf, dass er eine Antwort oder
zumindest eine Reaktion gibt. Natürlich wird es für die älteren
Entwickler verlockend sein, in private Diskussionen zu verfallen,
schließlich sind sie daran gewohnt. Beobachten Sie deshalb auch die
interne Mailingliste und bitten Sie ggf. darum, bestimmte Diskussionen
besser gleich auf die öffentliche Liste zu verlegen.
Es gibt andere, langfristigere Bedenken beim Öffnen vormals
geschlossener Projekte.
untersucht Techniken um bezahlte und unbezahlte Entwickler erfolgreich
zu mischen und behandelt die nötige rechtliche
Sorgfalt beim Öffnen von privatem Code, mit bestimmten Komponenten,
die einer anderen Partei "gehört", bzw. von ihnen geschrieben
wurde.
Bekanntgabe
Sobald das Projekt in einem vorzeigbarem Zustand ist – nicht
perfekt, lediglich vorzeigbar – ist es bereit, der Welt
bekannt gemacht zu werden. Tatsächlich geht das relativ einfach: Gehen
Sie auf , klicken Sie in der oberen
Navigationsleiste auf Submit und füllen Sie
das Formular aus, um Ihr Projekt bekanntzumachen. Freshmeat ist der Ort,
auf dem alle nach Ankündigungen neuer Projekte Ausschau halten. Sie müssen
dort nur ein paar Augen erwischen und ihre Nachricht wird sich von da
an über Mundpropaganda weiterverbreiten.
Wenn Sie Mailinglisten oder Newsgroups kennen, auf denen eine
Ankündigung Ihres Projekts thematisch passen würde und von Interesse
wäre, sollten Sie dort einen Eintrag machen, achten Sie aber darauf,
genau einen Eintrag pro Forum zu machen, und
verweisen Sie dabei auf Ihre eigenen Foren für weitere anschließende
Diskussionen (indem Sie den Reply-to
Header setzen). Die Einträge sollten kurz und prägnant sein:
An: discuss@lists.example.org
Betreff: [ANN] Das Scanley-Projekt für Volltext-Indizierung
Antwort-An: dev@scanley.org
Diese Nachricht ist die einmalige Bekanntgabe über die Gründung des
Scanly-Projekts, eine Open-Source-Volltextindizierungs- und Suchmaschine,
mit einer reichen API für Programmierer, die Suchfunktionen für große
Mengen an Text implementieren wollen. Der Code von Scanley läuft, wird
aktiv entwickelt, und wir suchen sowohl nach Entwickler als auch Nutzern
die testen wollen.
Webseite: http://www.scanley.org/
Funktionen:
- Durchsucht Klartext, HTML, und XML
- Suche nach Wörter oder Ausdrücken
- (geplant) Unscharfe Suche
- (geplant) Inkrementelle Aktualisierung der Indizes
- (geplant) Indizierung von Webseiten
Voraussetzungen:
- Python 2.2 oder neuer
- Genügend Festplattenplatz für die Indizes (ca. 2x die Größe der
ursprünglichen Daten)
Weiteres finden Sie auf scanley.org.
Vielen Dank,
-H. Mustermann
(Siehe
im Kapitel für Ratschläge
über die Bekanntmachung neuer Versionen und anderer Ereignisse im
Projekt.)
Es gibt eine anhaltende Diskussion in der
Open-Source-Gemeinschaft darüber,
ob ein Projekt schon am Anfang laufenden Code haben muss,
oder ob es einem Projekt hilft, selbst in den frühen Phasen des
Entwurfs offen zu sein. Ich dachte früher, dass es am allerwichtigsten
sei, mit laufendem Code anzufangen, dass man so erfolgreiche Projekte
vom Spielzeug unterscheiden könnte, und ernstzunehmende Entwickler nur
etwas anfassen würden, was auch schon etwas Handfestes machte.
Wie es sich herausstellte, war das nicht der Fall. Beim
Subversion-Projekt, fingen wir mit einem Entwurf an, ein Kern
interessierter und miteinander vertrauter Entwickler, viel Fanfare und
keine einzige Zeile lauffähigen Codes. Zu meiner
völligen Überraschung, schaffte es das Projekt von Anfang an, aktive
Freiwillige anzulocken und bis wir tatsächlich etwas Laufendes hatten,
waren bereits eine ziemliche Menge freiwilliger Entwickler beteiligt.
Subversion ist nicht das einzige Beispiel; das Mozilla-Projekt fing
auch ohne laufenden Code an und bietet heute einen erfolgreichen und
beliebten Web-Browser.
Angesichts solcher Beweise muss ich von meiner ursprünglichen
Behauptung zurücktreten, dass laufender Code absolut notwendig ist, um
ein Projekt anzufangen. Trotzdem ist laufender Code immer noch eines
der besten Grundlagen für Erfolg, und eine gute Grundregel wäre es, mit
der Bekanntgabe zu warten, bis Sie solchen haben. Es mag allerdings
Umstände geben, unter denen eine frühere Bekanntmachung Sinn macht. Ich
denke, dass zumindest ein gut ausgearbeiteter Entwurf oder irgend
ein Grundgerüst für den Code notwendig ist – dieser kann natürlich
wegen öffentlichen Rückmeldungen überarbeitet werden müssen, aber es
muss etwas Handfestes und Greifbares geben, etwas mehr als gute
Absichten, von dem aus Leute ausgehen und weiterarbeiten können.
Wenn Sie die Ankündigung machen, sollten Sie jedoch nicht gleich
darauf ein Schar Freiwilliger erwarten. Für gewöhnlich ist das Resultat
einer Bekanntmachung, dass Sie nebenbei ein paar Anfragen bekommen, es
melden sich ein paar Leute auf der Mailingliste an, abgesehen davon geht
so ziemlich alles weiter wie bisher. Mit der Zeit werden Sie aber eine
stete Zunahme von Beiträgen neuen Mitarbeiter und Benutzer bemerken.
Die Ankündigung ist lediglich das Pflanzen eines Samenkorns.
Es braucht Zeit, bis die Nachricht sich fortpflanzt. Wenn
das Projekt beständig diejenigen honoriert, die sich beteiligen, wird
sich die Nachricht verbreiten, denn Menschen teilen einander mit, wenn
sie etwas Gutes entdecken. Wenn alles gut läuft, wird die Dynamik der
exponenziellen Kommunikationsnetze das Projekt langsam in eine komplexe
Gemeinschaft verwandeln, in der Sie nicht unbedingt jeden Namen
kennen und nicht länger jede Unterhaltung mitverfolgen können. Die
nächsten Kapiteln handeln vom Arbeiten in einer solchen Umgebung.