Kapitel 2. Der Einstieg

Inhaltsverzeichnis

Mit dem Vorhandenen beginnen
Wählen Sie einen guten Namen
Formulieren Sie ein klares Missionsziel
Sagen Sie, dass das Projekt frei ist
Funktionen und Anforderungen
Stand der Entwicklung
Downloads
Zugriff auf Versionsverwaltung und Bugtracker
Kommunikationskanäle
Richtlinien für Entwickler
Dokumentation
Erreichbarkeit der Dokumentation
Entwickler-Dokumentation
Beispiel-Ausgaben und Screenshots
Hosting-Pakete
Die Wahl einer Lizenz
"Alles ist erlaubt"-Lizenzen
Die GPL
Eine Lizenz für Ihre Software
Den Ton angeben
Private Diskussionen vermeiden
Unhöflichkeit im Keim ersticken
Code Review
Der Übergang ehemals geschlossener Projekte zu Open Source
Bekanntgabe

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 http://www.catb.org/~esr/writings/cathedral-bazaar/ )

Raymond sagte wohlgemerkt nicht, dass Open-Source-Projekte nur aus dem persönlichen Bedürfnis eines Programmierers entstehen, 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 (http://www.openadapter.org/) 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 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, 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 irgendein 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 – Benutzer und Entwickler – geeignet sein muss, 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, dass dieses Projekt seine Siebensachen beisammen hat, Fragen erahnt, die gestellt werden, und sich die Mühe gemacht hat diese so zu beantworten, dass Fragesteller möglichst wenig Einsatz aufbringen müssen. Indem das Projekt eine Aura des Vorbereitetseins ausstrahlt, sendet es die folgende Botschaft aus: "Du verschwendest deine Zeit nicht, wenn du dich beteiligst". 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 http://freshmeat.net/ (eine Nachrichtenseite über Open-Source-Projekte (zu dieser Seite, später mehr), bei http://www.sourceforge.net/ oder beim Verzeichnis freier Software der Free Software Foundation http://directory.fsf.org/ 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, 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, und so weiter. In Wirklichkeit wäre es unvertretbar zeitaufwendig, auf all diese Dinge zu achten; und überhaupt sind dies 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 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 „Schauen Sie sich zuerst um“ 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 http://www.nameprotect.org/ und http://www.uspto.gov/ 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 „Hosting-Pakete“), 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 http://www.openoffice.org/:

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 „Die Wahl einer Lizenz“später in diesem Kapitel; Lizenzfragen werden ausführlich im Kapitel Kapitel 9, Lizenzen, Urheberrecht und Patente 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 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ücken

  • (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 die 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.

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übliche 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 sauberes Packen 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 zu sehen welche die aktuellere ist. Eine ausführliche Diskussion über Versionsnummern finden Sie in „Versionszählung“, und Details zur Standardisierung von Build- und Installations-Vorgängen werden im Abschnitt „Erstellung der Pakete“, sowie in Kapitel 7, Paket-Erstellung, Veröffentlichung, und tägliche Entwicklung 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 neuesten 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 „Versionsverwaltung“ im Kapitel Kapitel 3, Technische Infrastruktur 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 ausreichend 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 das Projekt diese Fehler erfassen und priorisieren kann. 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 „Bugtracker“ im Kapitel Kapitel 3, Technische Infrastruktur 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 „Handhabung von Wachstum“ im Kapitel Kapitel 6, Kommunikation, 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 „Schriftliche Regeln“ im Kapitel Kapitel 4, Soziale und politische Infrastruktur 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 http://subversion.apache.org/docs/community-guide/ für ein Beispiel besonders gründlicher Richtlinien für Entwickler oder http://www.openoffice.org/dev_docs/guidelines.html 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 „Entwickler-Dokumentation“ später in diesem Kapitel behandelt.

Dokumentation

Dokumentation ist unerlässlich. Es muss irgendetwas 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ühesten 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 ihm zu 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 letzte 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 vorzubereiten – das gibt den Eindruck, dass im Projekt ein Bewusstsein über seinen Zustand besteht.

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 „Erstellung der Pakete“ im Kapitel Kapitel 7, Paket-Erstellung, Veröffentlichung, und tägliche Entwicklung ). 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 eine 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 einer Wendung absuchen wollen. Im Allgemeinen wissen sie schon, wonach sie suchen, können sich nur nicht erinnern 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 http://subversion.apache.org/docs/community-guide/), 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 entschlossenen Freiwilligen gelingen, sich einen Weg durch den Code zu bahnen. Was Menschen dazu treibt, ihre Zeit mit dem Erarbeiten einer Codebasis zu verbringen, ist, dass 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 „Wikis“ im Kapitel Kapitel 3, Technische Infrastruktur.

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.

Sie können der Website des Projekts noch vieles mehr hinzufügen, wenn die Zeit dazu reicht, oder wenn es aus irgendeinem 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 „Hosting-Pakete“ im Kapitel Kapitel 3, Technische Infrastruktur für eine detailliertere Diskussion über Vor- und Nachteile von Hosting-Paketen und eine Liste von Sites die sie anbieten.



[13] Häufig gestellte Fragen