Inhaltsverzeichnis
Der klassische Verlauf vom Anfang 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.
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 Programmiere ein persönliches Interesse daran hat, ein Problem zu lösen; was insofern für freie Software relevant ist, da es sich herausstellte, dass die meisten Open Source Projekte, von Programmierern angefangen 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 etwas weniger als 1997, zu der Zeit als Raymond diese Worte schrieb. Heute haben wir das Phänomen, dass Organisationen —auch profit-orientierte Firmen—große, zentral organisierte Open Source Projekte anfangen. Der einsame Programmierer der ein bisschen Code produziert um ein lokales Problem zu lösen um dann festzustellen, dass das Ergebnis eine breitere Anwendbarkeit hat, ist immer noch die Quelle einer Menge freier Software, es ist aber nicht mehr die Einzige.
Die Argumentation von Raymond ist aber immer noch Aufschlussreich. Diejenigen die Software Produzieren, müssen ein direktes Interesse an seinem 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/), von der Investmentbank Dresdner Kleinwort Wasserstein, dass als Open Source Framework zur Integration unterschiedlicher finanzieller Informationssysteme angefangen wurde, 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, kriegen sie es also mit. Aus diesem Arrangement entsteht gute Software, da Rückmeldungen an den richtigen Stellen ankommen. Die Software muss nicht verkauft werden, also können sie sich auf ihre Probleme konzentrieren. Sie wird geschrieben um ihre eigene Probleme zu lösen, um es dann mit allen zu teilen. Es ist so ähnlich, als wäre das Problem eine Krankheit und die Software die entsprechende Medizin, mit dem Sinn eine Epidemie auszurotten.
In diesem Kapitel geht es um die Frage, wie man ein neues freies Software Projekt der Welt vorstellt. Viele seiner Empfehlungen würden aber einer Medizinischen Organisation, bekannt vorkommen. Die Ziele sind sich sehr ähnlich: Man will klarstellen was die Medizin macht, es in die Hände der richtigen Leute bringen, und sicherstellen, dass diejenigen die es erhalten, wissen damit umzugehen. Bei der 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 einander nicht zwangsläufig gegenüber, aber sie machen die anfänglichen 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 sollt auch immer eine größere Belohnung mit sich bringen. Wenn beide nicht eng miteinander korrelieren, werden die Leser schnell die Hoffnung aufgeben und aufhören ihre Zeit zu investieren.
Daraus folgt, das Erscheinungsbild ist wichtig. Programmierern fällt es besonders schwer, das zu glauben. Ihre Liebe zum Inhalt gegenüber seinem Aussehen, 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 manches erschrocken sind, worauf Programmierer von alleine kommen.
Das ist schade, denn es gibt Situationen, bei 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 erfährt, ist das Aussehen seiner Webseite. Diese Information wird erfasst, bevor irgend ein tatsächlicher Inhalt der Seite verstanden wird—bevor irgendein Text gelesen wurde oder auf irgendein Links geklickt wurde. Egal wie ungerecht es sein mag, Leute können sich nicht anders helfen, als sich sofort einen ersten Eindruck zu verschaffen. Das Erscheinungsbild der Seite deutet darauf hin, 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 dadurch vermittelte Eindruck, übertragt sich auf das übrige Projekt.
Sie sollten deshalb daran denken, auch wenn das Thema in diesem Kapitel sich um Inhaltliches dreht, das Erscheinungsbild ist auch wichtig. Da die Webseite für zwei Arten von Besucher geeignet sein muss—Nutzer 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(falls Überlappende) Zielgruppen ansprechen soll: Besucher sollten eine grobe Vorstellung haben, wo ein Link hinführt, bevor sie darauf klicken. Das Ziel, von einem Link zur Dokumentation für Benutzer, sollte alleine vom Anblick deutlich sein, und keine Missverständnisse aufkommen lassen, ob es nicht etwa zur Dokumentation für Entwickler führt. Beim betrieb eines Projekts, geht es zum Teil darum Informationen bereitzustellen, aber auch darum ein Gefühl der Behaglichkeit anzubieten. Allein schon die Verfügbarkeit bestimmter grundsätzlicher Angebote an den richtigen Stellen, gibt Benutzer und Entwickler eine Sicherheit, bei ihrer Entscheidung, ob sie sich beteiligen wollen oder nicht. Es sagt ihnen, das Projekt hat seine Sachen beisammen, Fragen die gestellt werden erahnt hat und sich die Mühe macht sie so zu beantworten, dass Leute mit Fragen möglichst wenig Einsatz aufbringen müssen. Indem das Projekt eine Aura ausstrahlt, vorbereitet zu sein, sendet es folgende Botschaft nach außen: "Du verschwendest deine Zeit nicht, wenn du dich beteiligst", und das ist genau die Botschaft, die sie hören müssen.
Vor Sie ein Open Source Projekt anfangen, gibt es noch einen 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 zuvor gekommen ist. Wenn das der Fall ist und ihr Code unter einer freien Lizenz gestellt wurde, gibt es keinen Grund das Rad neu zu erfinden. Es gibt natürlich Außnahmen: Falls sie ein Projekt als Lehr-Erfahrung anfangen 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 fehlende Funktionen zu erweitern, als komplett von vorne anzufangen.
Sie haben sich umgeschaut, herausgefunden dass nichts ihre Anforderungen erfüllt und haben sich entschlossen, ein neues Projekt anzufangen.
Was jetzt?
Das schwerste bei der Gründung eines neuen freien Software Projekts ist, die eigene Vision in eine öffentliche zu verwandeln. Sie oder Ihre Organisation mögen sehr wohl wissen was Sie wollen. Dieses Ziel so auszudrücken, dass die Welt es versteht, ist wenn auch eine beträchtliche Menge Arbeit, trotzdem unabdingbar. Sie und die anderen Gründer müssen entscheiden worum es in dem Projekt wirklich geht, bzw. Sie müssen sowohl über seine Grenzen entscheiden—was es nicht machen wird, als auch was es wirklich machen wird—und ein Missionsziel 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 aber nicht unbedingt schlecht sein muss: Es ist besser diese jetzt aus dem Weg zu Räumen als später. Der nächste Schritt, ist das Projekt für den öffentlichen verzehr aufzubereiten, was im Prinzip reine Plackerei ist.
Diese Arbeit ist deshalb so mühselig, weil es hauptsächlich darum geht Sachen zu organisieren und zu dokumentieren, die jeder schon kennt—d.h "jeder" der bisher beteiligt war. Für diejenigen die die Arbeit machen, gibt es deshalb keinen direkten Nutzen. Sie brauchen keine README Datei für einen Überblick über das Projekt, oder ein Dokument über sein Aufbau oder ein Handbuch der Software. Sie brauchen kein sorgsam aufbereiteten Code der mit den, zwar informell, aber weit verbreiteten Normen für die Veröffentlichung von Quellcode, konform ist. Ihnen ist es egal, wie der Quellcode aufgebaut ist, sie sind ja bereits daran gewöhnt, und wenn der Code überhaupt läuft, wissen sie schon wie man ihn benutzt. Es macht ihnen nicht einmal etwas aus, wenn die grundsätzlichen Annahmen über den Aufbau des Projekts nicht dokumentiert werden; das kennen sie ja auch schon.
Für Neulinge sind diese Sachen andererseits sehr wichtig. Glücklicherweise jedoch, nicht alle auf ein mal. Sie müssen nicht jede erdenklich Ressource gleich parat haben, vor Sie ein Projekt an die Öffentlichkeit bringen. In einer perfekten Welt, hätte jedes Projekt von Anfang, ein gründlich durchdachtes Dokument über seine Architektur, eine vollständige Betriebsanleitung (mit besonderen Hinweisen für Funktionen die geplant aber noch nicht implementiert sind), wunderschön aufbereiteten und portablen Code, der auf jedem Rechner läuft, usw. In Wirklichkeit, wäre es unvertretbar Zeitaufwendig all diese Sachen zu erledigen und überhaupt ist es Arbeit von dem man hoffen kann, dass Freiwillige sie aufnehmen werden, sobald das Projekt in gang gebracht wurde.
Was jedoch wirklich notwendig ist, ist dass genug in die Präsentation investiert wird, dass Neulinge an dem ersten Hindernis der Unbekanntheit vorbeikommen können. Sie können es sich als den ersten Schritt beim Hochfahren vorstellen; um das Projekt auf sein minimales Energieniveau zur Aktivierung zu bringen. Diese Grenze wurde auch schon Hacktivierungs-Energie genannt: Die Energie die Neulinge aufbringen müssen bevor sie einen Nutzen ziehen. Je geringer die Hacktivierungs-Energie ist, desto besser. Ihre erste Aufgabe ist es die Hacktivierungs-Energie auf einem Niveau zu senken, welches Leute zur Beteiligen ermutigt.
Jede der folgenden Unterabschnitte, beschreibt einen wichtigen Aspekt der Gründung eines neuen Projekts. Sie werden in der groben Reihenfolge präsentiert, in der ein neuer Besucher sie begegnen würde. Die Reihenfolge in der Sie tatsächlich implementieren werden, kann natürlich davon abweichen. Sie können es als Checkliste betrachten. Am Anfang eines Projekts, gehen Sie der Reihe nach alle Punkte durch und stellen sicher, dass alle erledigt sind oder zumindest, wenn welche weggelassen werden, dass Sie mit den möglichen Folgen umgehen können.
Versetzen Sie sich in die Lage einer Person, die gerade erst von Ihrem Projekt erfahren hat, vielleicht zufällig, bei der Suche nach einer Software, um ein Problem zu lösen. Ihre erste Begegnung ist der Name.
Ein guter Name wird ihr Projekt nicht automatisch erfolgreich machen und ein schlechter bedeutet auch nicht den Untergang; obwohl ein wirklich schlechter Name das wahrscheinlich erreichen könnte, aber wir gehen davon aus, dass keiner hier versucht sein Projekt aktiv zu Sabotieren. Ein schlechter Name kann jedoch die Aufnahme in der Öffentlichkeit verlangsamen, entweder weil Leute es nicht ernst nehmen oder einfach nur, weil Sie Schwierigkeiten haben sich daran zu erinnern.
Ein guter Name:
Gibt eine ungefähre Vorstellung davon, was das Projekt macht oder ist zumindest derart offensichtlich verwandt, dass wenn man den Namen kennt, und weiss was das Projekt macht, es nachher leicht ist, sich an den Name zu erinnern.
Ist einfach zu behalten. Man kommt hier nicht um die Tatsache herum, dass Englisch zur Standard-Sprache im Internet geworden ist: "einfach zu behalten." bedeutet in diesem Fall "Einfach zu behalten, für jemand der Englisch lesen kann". Wortspiele die von einer Einheimischen Aussprache abhängen, werden vielen Menschen deren erste Sprache nicht Englisch ist, unklar sein. Wenn das Wortspiel besonders verlockend und einprägsam ist, kann es das wert sein; denken Sie aber daran, dass viele die den Namen sehen nicht dasselbe heraushören werden wie jemand dessen Muttersprache Englisch ist.
Ist nicht der gleiche wie der eines anderen Projekts und verletzt auch kein Markenrecht. Das ist sowohl höflich als auch rechtlich sinnvoll, denn Sie wollen keine Verwirrung über die Identität entstehen lassen. Es ist schon schwierig genug, alles was im Netz verfügbar ist zu verfolgen, ohne dass auch noch mehrerer Sachen den gleichen Namen tragen.
Die vorher in „Schauen Sie sich Vorher Um“ erwähnten, Quellen können Ihnen dabei helfen, herauszufinden ob ein anderes Projekt bereits den Namen trägt, an den Sie denken. Kostenlose Suchen nach Markenzeichen sind bei http://www.nameprotect.org/ und http://www.uspto.gov/ verfügbar.
Ist möglichst, als Domain-Name in der .com, .net, und .org top-level Domainen verfügbar Sie sollten sich eine aussuchen, wahrscheinlich .org, um sie als offizielle Seite des Projekts zu bewerben; die anderen Beiden sollten darauf verweisen und dienen einfach nur dazu, andere daran zu hindern, Verwirrung um den Namen ihres Projekts zu stiften. Selbst wenn Sie vor haben das Projekt auf eine andere Seite zu betreiben (siehe „Hosting Bündel“), können Sie immer noch die Projekt-spezifischen URL registrieren und sie auf die Seiten des Betreibers weiterleiten lassen. Es hilft dem Nutzer ungemein, wenn er sich eine einfache URL merken kann.
Sobald Besucher ihre Projektseite gefunden haben, werden sie nach einer kurzen Beschreibung suchen, das Ziel des Projekts um (innerhalb von 30 Sekunden) entscheiden zu können, ob sie Interessiert sind mehr zu erfahren. Dieser Satz sollte auf der ersten Seite besonders herausragen, vorzugsweise direkt unterhalb vom Namen des Projekts.
Die Formulierung des Missionsziels sollte anschaulich sein, grenzen setzen und vor allem kurz sein. Hier ist ein gutes Beispiel von http://www.openoffice.org/:
Gemeinschaftlich die führende internationale Office Lösung für alle wichtigen Umgebungen zu erschaffen, die durch offene Schnittstellen und ein XML Dateiformat, den Zugriff auf all seine Funktionen und Daten ermöglicht.
Mit nur wenigen Worten, haben sie alle wichtigen Punkte erwähnt, größtenteils indem sie sich auf das bereits vorhandene Wissen der Leser verlassen. 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 Umgebungen" heißt, für Unix, Macintosh, und Windows. Das Übrige signalisiert, dass offene Schnittstellen und leicht verständliche Dateiformate ein wichtiger Teil ihres Ziels ist. Sie sagen nicht offen, dass sie eine freie Alternative zu Microsoft Office sein wollen, die Meisten können das aber zwischen den Zeilen herauslesen. Auch wenn dieser Satz auf den ersten Blick eine Menge abdeckt, ist es eigentlich ziemlich begrenzt: Die Worte "Office Lösung" bedeuten etwas ganz bestimmtes für diejenigen die mit solcher Software vertraut sind. Das Vorwissen der Leser (in diesem Fall wahrscheinlich mit MS Office) von dem sie ausgehen, wird hier benutzt, um die Formulierung knapp zu halten.
Wie die Missionsziele formuliert sind, hängt teilweise davon ab, wer sie schreibt, nicht nur von der Software die sie beschreiben. Es macht zum Beispiel Sinn für Open Office "Gemeinschaftlich" zu schreiben, denn das Projekt wurde gegründet durch und wird heute noch zum größten Teil entwickelt von Sun Microsystems. Mit diesem Wort weist Sun auf seine Sensibilität gegenüber Sorgen, dass Sie versuchen könnten die Entwicklung zu dominieren. Bei einer solchen Angelegenheit, kann allein schon der Hinweis auf das mögliche Problem sehr hilfreich sein, es ganz und gar zu vermeiden. Andererseits brauchen Projekte die nicht durch eine einzige Firma Unterstützt werden keine solchen Ausdrücke; denn schließlich ist die Entwicklung durch eine Gemeinschaft die Norm, es gibt also für gewöhnlich keinen Grund, es als Teil der Mission aufzulisten.
Wer die Missionziele gelesen hat und noch interessiert ist, wird als nächstes mehr Einzelheiten erfahren wollen, vielleicht eine Dokumentation für Benutzer oder Entwickler und schließlich werden sie etwas herunterladen wollen. Vorher müssen sie sich jedoch sicher sein, dass es Open Source ist.
Die Hauptseite muss unmissverständlich klar machen, dass das Projekt Open Source ist. Das mag offensichtlich klingen, Sie wäre aber überrascht wie viele Projekte es vergessen. Ich habe schon Projekte gesehen, deren Hauptseite es nicht nur versäumten zu sagen, unter welcher Lizenz ihre Software veröffentlicht war, sondern nicht einmal sagte, dass es sich um freie Software handelte. Manchmal verschoben sie die entscheidende Information auf die download Seite, die Entwickler-Seite oder irgend eine andere Seite die ein Klick mehr erforderte. Im Extremfall wurde die Lizenz überhaupt nicht auf der Seite angegeben—die einzige Möglichkeit es herauszufinden war es herunterzuladen und hereinzuschauen.
Machen Sie nicht diesen Fehler. Solch ein Versäumnis kann zum Verlust vieler potentieller Entwickler und Nutzer führen. Sagen Sie gleich vorweg, direkt unterhalb der Missionsziele, dass das Projekt freie Software oder Open Source Software ist, und geben Sie die genaue Lizenz an. Eine kurze Anleitung zur Auswahl einer Lizenz befindet sich im Abschnitt „Die Wahl einer Lizenz“später in diesem Kapitel, und Lizensfragen werden ausführlich im Kapitel Kapitel 9, Lizenzen, Urheberrecht, und Patente behandelt.
Bis hierhin hat unsere hypothetische Besucherin sich entschieden—wahrscheinlich innerhalb der ersten Minute oder schon vorher—ob sie interessiert ist, sagen wir, zumindest weiter fünf Minuten in das Projekt zu investieren. Der nächste Abschnitt beschreibt was sie innerhalb der nächsten fünf Minuten vorfinden sollte.
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 "in Planung" oder "in Arbeit" daneben), und die Hardware Anforderungen, um die Software zu betreiben. Stelle Sie sich die Liste der Funktionen/Anforderungen als das vor, was Sie jemand geben würden, der nach einer kurzen Zusammenfassung der Software fragt. Oft ist sie einfach nur eine logische Erweiterung der Missionsziele. Die Missionsziele könnten zum Beispiel folgendermaßen formuliert sein:
Die Erstellung einer Indizierungs und Suchmaschine für Volltext Dateien, mit einer reichhaltigen Schnittstelle für Programmierer die Suchdienste über große Mengen von Text anbieten wollen.
Die Liste der Funktionen und Anforderungen würde folgende Details angeben, um die Missionsziele klarer zu machen:
Funktionen:
Durchsucht Klartext, HTML, und XML
Suche nach Wörter oder Ausdrücke
(geplant) Unscharfe Suche
(geplant) Inkrementelle Aktualisierung der Indizes
(geplant) Indizierung von Ressourcen im Netzwerk
Anforderungen:
Python 2.2 oder höher
Genug Festplatten Speicher für die Indizierung (ca. 2x Menge der Originaldaten)
Durch diese Informationen, können Leser schnell ein Gefühl dafür entwickeln, ob diese Software irgend eine Aussicht hat, ihnen etwas zu nutzen und sie können sich auch überlegen, ob sie sich als Entwickler beteiligen wollen.
Leute wollen immer wissen wie es einem Projekt geht. Bei neuen Projekten, wollen sie wissen wie weit seine Versprechen und sein derzeitiger Zustand 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 dem die kurzfristigen Ziele und Anfragen des Projekts aufgelistet werden(es könnte z.B. auf der Suche nach Entwickler 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 das Projekt unter "Fortschritt" versteht und wie schnell es nach dieser Vorstellung vorankommt.
Fürchten Sie sich nicht davor, unvorbereitet auszusehen und geben Sie nicht der Versuchung nach, den Entwicklungsfortschritt 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 es hat bekannte Fehler. Sie läuft zwar und funktioniert zumindest manchmal, trotzdem gilt: Nutzung auf eigene Gefahr". Diese Ausdrucksweise wird nicht die Art Entwickler 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. Ein Ruf instabil oder Fehlerträchtig zu sein ist einmal angeeignet, nur schwer wieder loszuwerden. Konservativ zu bleiben zahlt sich auf lange Sicht aus; es ist besser wenn die Software stabiler läuft als erwartet, als weniger und angenehme Überraschungen sorgen für die beste Mundpropaganda.
Man sollte den Quellcode der Software in den üblichen Formaten herunterladen können. Wenn ein Projekt noch am Anfang ist, sind binäre (ausführbare) Dateien noch 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 anzulocken.
Die veröffentlichten Dateien herunterzuladen, sollte möglichst bequem, standardkonform und mühelos sein. Wenn Sie eine Krankheit ausrotten wollen, würden Sie die Medizin nicht derart verteilen, dass man eine unüblich Spritze bräuchte. Ebenso sollte Software die üblichen Build- und Installations-Methoden beachten, denn je mehr die Software von diesen Standards abweicht, desto größer ist das Potential, dass Benutzer und Entwickler aufgeben und verwirrt weggehen.
Das hört sich sehr offensichtlich an, aber viele Projekte machen sich sehr lange nicht diese Mühe und sagen sich, dass sie es jederzeit machen könnten: "Wir erledigen den Kram sobald der Code näher an der Fertigstellung ist.". Was sie dabei nicht erkennen, ist dass indem sie die langweilige Arbeit hinausschieben, wie die Fertigstellung der Build- und Installations-Vorgänge, schieben sie auch die Fertigstellung vom Code hinaus—denn sie entmutigen Entwickler, die ansonsten etwas beigetragen hätten. Das heimtückischste daran ist, dass keiner etwas über diese verloren gegangenen Entwickler überhaupt erfährt, denn der Vorgang ist eine Ansammlung von Nicht-Ereignissen: Jemand geht auf die Webseite, lädt die Software herunter, versucht ein Build zu machen, scheitert, gibt auf und geht weg. Wer wird jemals davon etwas wissen, außer die Person selbst? Keiner im Projekt wird je bemerken, dass das Interesse und Wohlwollen von jemand stumm verschwendet wurde.
Langweilige Arbeit mit einem hohen Nutzen, sollte immer früh erledigt werden. Denn die Einstiegshürden zu einem Projekt zu verringern, zahlt sich um Vielfaches zurück.
Wenn Sie eine neu Version veröffentlichen, ist es wichtig, eine eindeutige Versionsnummer zu vergeben, um alle Versionen von einander unterscheiden zu können und ihre Reihenfolge klar. Eine ausführliche Diskussion über Versionsnummern finden Sie in „Versions Nummerierung“, und Details zur Standardisierung eines der Build- und Installations-Vorgänge werden im Abschnitt „Erstellung der Pakete“, sowie in Kapitel 7, Paket Erstellung, Veröffentlichung, und Tägliche Entwicklung behandelt.
Den Quellcode herunterzuladen reicht für alle aus, die lediglich die Software installieren und benutzen wollen, es reicht jedoch nicht aus für diejenigen, die es weiterentwickeln wollen. Nächtliche Quellcode Snapshots können helfen, reichen aber trotzdem nicht aus für eine gedeihende Entwicklergemeinschaft. Diese Leute brauchen Echtzeit-Zugriff auf den neusten Quellcode und der Weg es ihnen zu geben, ist eine Versionsverwaltung zu benutzen. Anonym Zugriff auf Quellcode, der unter Versionsverwaltung steht, ist ein Zeichen—für Entwickler wie auch für Nutzer—dass das Projekt sich mühe gibt, Leute das nötige zu geben, um sich zu beteiligen. Wenn Sie nicht sofort eine Versionsverwaltung bereitstellen können, sollten Sie zumindest darauf hinweisen, dass Sie es bald vorhaben. Die Infrastruktur der Versionsverwaltung wird ausführlich in „Versionsverwaltung“ im Kapitel Kapitel 3, Technische Infrastruktur behandelt.
Gleiches gilt für den Bug-Tracker. Ein Bug-Tracker ist nicht nur wichtig wegen seinem Nutzen für Entwickler, sondern auch für seine Botschaft an Außenstehende. Für Viele, ist eine offene Bug Datenbank, eines der stärksten Anzeichen, dass ein Projekt ernst genommen 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 Sachen 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 beide 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 gepflegten Bug Datenbank (was so viel heißt wie, dass schnell auf Bugs reagiert wird, Duplikate markiert werden, usw.) macht deshalb einen besseren Eindruck als ein Projekt ohne Bug Datenbank oder einer fast leeren Datenbank.
Am Anfang vom Projekt, wird die Bug Datenbank natürlich nur sehr wenige Meldungen enthalten und es gibt nicht viel, was Sie dagegen machen können. Wenn die Status Seite aber das junge Alter hervorhebt und wenn Leute die auf die Bug Datenbank schauen sehen können, dass die Meisten Einträge vor kurzem gemacht wurden, können sie sich ausrechnen, dass das Projekt immer noch eine gesunde Rate an Einträgen hat und werden dementsprechend nicht übermäßig alarmiert sein, über die niedrige absolute Anzahl an Bug Meldungen.
Man sollte auch beachten, dass Bug-Tracker 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 Bug-Trackers, wird in „Bug-Tracker“ 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 Bug-Tracker zu haben und sicher zu stellen, dass er von der Hauptseite sichtbar ist.
Besucher wollen oft wissen, wie sie die Menschen hinter dem Projekt erreichen können. Adressen der E-Mail Verteiler, Chat Räume, IRC Kanäle und andere Foren auf denen Beteiligte erreicht erreicht werden können, sollten online gestellt werden. Stellen Sie klar, dass Sie und die anderen Autoren des Projekts auf diese Verteiler eingetragen sind, damit Besucher sehen, dass es eine Möglichkeit gibt an die Entwickler Rückmeldungen zu geben. Eine Anmeldung auf den E-Mail Verteilern impliziert keine Verpflichtung, auf alle Fragen zu antworten oder alle Anfragen für neue Funktionen zu implementieren. Auf lange Sicht, werden die Meisten sowieso niemals diesen Foren betreten aber es wird sie Trösten, dass sie es könnten falls es nötig werden sollte.
Am Anfang eines Projekts, hat es keinen Sinn die Foren für Nutzer und Entwickler getrennt zu halten. Es ist viel besser, alle zusammen in einem "Raum" reden zu lassen. Unter den Personen die sich früh an einem Projekt beteiligen, ist die Unterscheidung zwischen Entwickler und Nutzer oft verwaschen. Sofern sie überhaupt gemacht werden kann, ist in den frühen Tagen, gibt es 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 an der Software hacken 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 bekommen.
Da es in diesem Kapitel nur um den Anfang von einem Projekt geht, reicht es zu sagen, dass diese Foren existieren sollten. Später, in „Handhabung von Wachstum“ im Kapitel Kapitel 6, Kommunikation, werden wir untersuchten wo und wie man diese Foren aufbaut, inwiefern Sie möglicherweise Moderation erfordern und wie man Foren für Nutzer und Entwickler, sobald es nötig wird, voneinander trennt, ohne dabei einen unüberwindliches Meer zu erschaffen.
Wenn jemand sich überlegt, etwas zu einem Projekt beizutragen, wird sie sich nach Richtlinien für Entwickler umschauen. Diese sind weniger technischer, als viel mehr sozialer Natur: Sie erklären, wie Entwickler und Benutzern miteinander umgehen und im wesentlichen, den Ablauf der Entwicklung.
Dieses Thema wird ausführlich in „Schriftliche Regeln“ im Kapitel Kapitel 4, Soziale und Politische Infrastruktur behandelt, aber die wesentlichen Elemente dieser Richtlinien sind folgende:
Verweise auf Foren für die Zusammenarbeit mit Entwicklern.
Anleitungen wie man Fehler meldet und Patches einreicht.
Irgend eine Hinweis darauf wie die Entwicklung für gewöhnlich abläuft—ob das Projekt eine gütige Diktatur, eine Demokratie oder etwas anderes ist.
Im übrigen 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 benutzen dieses Schema. Wichtig dabei ist nur, dass das Projekt es von vornherein klar macht. Eine Tyrannei die vorgibt eine Demokratie zu sein, wird Menschen abschrecken; eine Tyrannei die klar sagt was sie ist, wird zurecht kommen sofern der Tyrann kompetent und vertrauenswürdig ist.
Siehe http://svn.collab.net/repos/svn/trunk/www/hacking.html 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.
Etwas anderes, ist eine Einführung für Programmierer bereitzustellen, dass in „Entwickler Dokumentation“ später in diesem Kapitel behandelt wird.
Dokumentation ist unerlässlich. Es muss irgend etwas zum lesen geben, selbst wenn es nur rudimentär und unvollständig ist. Die Doku ist ganz klar ein Teil der vorhin erwähnten "Plackerei" und ist oft das erste was 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, man muss sich normalerweise nicht weiter damit beschäftigen. Die Dokumentation hingegen ist nie wirklich fertig, was vielleicht mit eine Grund dafür ist, dass man es manchmal hinauszögert sie überhaupt anzufangen.
Das heimtückischste daran ist, dass die Autoren der Dokumentation keinen direkten Nutzen daraus ziehen, währen es für neue Nutzer unerlässlich ist. Die wichtigste Dokumentation für neue Benutzer sind die Grundlagen: Wie richte ich schnell die Software ein, eine Übersicht wie sie funktioniert, vielleicht auch Anleitungen für häufige Aufgaben. All das ist den Autoren jedoch nur allzu bekannt—so bekannt, dass es für sie schwierig sein kann sich in die Lage der Leser zu versetzen und mühselig die (für die Autoren) offensichtlichen Einzelschritte zu buchstabieren, die kaum einer Erwähnung wert erscheinen.
Es gibt keine magisch Lösung für dieses Problem. Es muss sich nur jemand die Zeit nehmen, sie zu schreiben und anschließend an neue Nutzer auszuprobieren, um ihre Qualität zu überprüfen. 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 reduziert, sondern auch alle die später zum Projekt hinzukommen ebenfalls ermöglicht, sie schrittweise zu verbessern.
Man bekommt eher eine erste Dokumentation der Grundlagen, wenn man von vornherein seinen Umfang einschränkt. So erscheint es zumindest nicht wie eine endlosen Aufgabe. Als Richtlinie können folgende minimale Bedingungen genommen werden:
Sagen Sie dem Leser klar welche technischen Kenntnisse erwartet werden.
Beschreiben sie klar und deutlich, wie man die Software einrichtet und sagen Sie dem Benutzer irgendwo am Anfang der Dokumentation, ein Merkmal oder Befehl, mit dem man erkennen 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 sie bleiben fortgeschrittene, nicht gut dokumentierte, Funktionen herauszufinden. 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 ein lehrhaftes Beispiel einer häufigen Aufgabe. Offensichtlich wären viele Beispiele für viele Aufgaben noch besser, wenn die Zeit aber knapp ist, suchen Sie sich eins aus und schreiben Sie eine ausführliche Anleitung. Sobald jemand sieht, dass die Software für eine Sache benutzt werden kann, werden sie alleine anfangen herauszufinden, wofür es noch zu gebrauchen ist —und mit etwas Glück, selber anfangen die Dokumentation zu erweitern. Was uns zum nächsten Punkt bringt...
Kennzeichnen Sie Bereiche der Dokumentation die unvollständig sind. Indem Sie dem Leser zeigen, dass Sie sich über die Defizite im klaren sind, stellen Sie sich auf die Sicht der Leser ein. Ihr Einfühlungsvermögen sichert ihnen zu, dass das Projekt nicht erst überzeugt werden muss was wichtig ist. Diese Hinweise entsprechen keiner Verpflichtung, sie bis zu irgend einem bestimmten Datum auszufüllen—sie können auch als offenen Anfragen für Hilfe von Freiwilligen behandelt werden.
Der letzt Punkt ist von größerer Bedeutung und kann auf das ganze Projekt angewandt 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, sobald es dafür Zeit wird (Das kann in der Dokumentation, auf dem Bug-Tracker oder in einer Diskussion auf einem Verteiler 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 explizit 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 das Projekt genau über seinen Zustand Bescheid weiss.
Die Dokumentation sollte an zwei Stellen erreichbar sein: Online (direkt von der Webseite) und in der veröffentlichten Version der Software (siehe „Erstellung der Pakete“ im Kapitel Kapitel 7, Paket Erstellung, Veröffentlichung, und Tägliche Entwicklung ). Man muss sie online durchsuchen können, da Leute die Dokumentation oft lesen wollen bevor sie die Software zum ersten Mal herunterladen, um besser entscheiden zu können, ob sie es überhaupt herunterladen sollen. Prinzipiell, sollte es 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.
Es sollte unbedingt einen Link geben der auf die komplette Dokumentation in einer einzigen HTML Datei verweist (schreiben Sie einen Hinweis wie "monolitisch" oder "eine einzige riesige Datei" daneben, damit 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 durchsuchen wollen. Im allgemeinen wissen sie, schon wonach sie suchen und können sich nur nicht an die richtige Stelle erinnern. In der Situation, gibt es nichts frustrierenderes als eine HTML Seite für die Inhaltsangabe, einer für die Einleitung, eine weitere für die Installationsanleitung, usw. Wenn die Seiten auf diese Art aufgebrochen sind, ist die Suchfunktion im Browser völlig nutzlos. Eine in mehrere Seiten Aufgebrochene Dokumentation ist gut, wenn man weiss 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 ihnen das Leben nur unnötig erschweren.
Die Entwickler Dokumentation wird für Programmierer geschrieben, damit sie den Code verstehen, reparieren und erweitern 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 zusammen in einem Dokument gelegt, aus Gründen der Bequemlichkeit (wie mit dem früher angegebenen http://svn.collab.net/repos/svn/trunk/www/hacking.html Beispiel), müssen es aber nicht.
Obwohl die Entwickler Dokumentation sehr hilfreich sein kann, gibt es keinen Grund eine neue Version wegen ihr zu verzögern. So lange die ursprünglichen Autoren verfügbar (und bereit) sind Fragen zum Code zu beantworten, reicht das für den Anfang. Tatsächlich ist eine häufige Motivation eine Dokumentation zu schreiben, die gleichen Fragen wieder und wieder beantworten zu müssen. Aber selbst bevor es geschrieben wurde, werden entschlossene Freiwillige es schaffen sich im Code zurechtzufinden. Was Leute dazu bringt Zeit damit zu verbringen sich mit dem Quellcode vertraut zu machen, ist sein Nutzen für sie. Wer sich dessen sicher ist, nimmt sich auch die Zeit Probleme zu lösen; ohne dieses Vertrauen, wird keine noch so gute Dokumentation sie anlocken oder behalten können.
Wenn Sie also nur Zeit haben, um eine Dokumentation zu schreiben, schreiben Sie eine für Benutzer. Alle Dokumentation für Benutzer ist effektiv auch für die Entwickler; jeder Programmierer der an einer Software arbeitet, muss auch damit vertraut sein wie man sie benutzt. Später wenn Sie 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 für den Anfang eine Wiki, manchmal sogar für ihre Hauptdokumentation. Nach meiner Erfahrung funktioniert das nur, wenn die Wiki aktiv von einer Handvoll Leuten bearbeitet wird, die sich einig sind, wie die Dokumentation organisiert sein soll und was für einen Ton sie haben soll. Mehr dazu steht in „Wiki“ im Kapitel Kapitel 3, Technische Infrastruktur.
Ein Projekt mit graphischer Benutzeroberfläche, oder graphische sowie andere markante Ausgaben, sollte Beispiele auf der Webseite des Projekts zeigen. 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 sofortiger Genugtuung: Ein einziges Bild kann überzeugender sein als Paragraphen von Beschreibungen und Geschwätz auf dem E-Mail Verteiler, denn ein Bild ist ein unverkennbarer Beweis, 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 wenn man sich nur genug Mühe gibt, man es zum Laufen bringen kann.
Sie können noch vieles mehr auf die Webseite des Projekts setzen, wenn die Zeit dazu reicht, oder wenn es aus irgend ein 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 kann sie für später im Hinterkopf behalten.
Es gibt ein paar Seiten die kostenlos die Infrastruktur für Open Source Projekte bereitstellen: Eine Web Bereich, Versionsverwaltung, ein Bug-Tracker, ein download Bereich, Chat Foren, regelmäßiger Backup, usw. Die Details sind zwar von Seite zu Seite Unterschiedlich, aber das Wesentliche wird bei allen angeboten. Durch die Nutzung dieser Seiten 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 Seite benutzt, und kann das Aussehen der Projektseite und das Gefühl, dass es vermittelt, kontrollieren oder zumindest beeinflussen.
Siehe „Hosting Bündel“ im Kapitel Kapitel 3, Technische Infrastruktur für eine detailliertere Diskussion über die Vor- und Nachteile von Hosting Bündel und eine Liste von Seiten die sie anbieten.