Der Einstieg

Der Einstieg Das Starten eines freien Softwareprojekts ist eine zweifältige Aufgabe. Die Software muss Benutzer akquirieren und Entwickler akquirieren. Diese zwei Bedürfnisse stehen nicht notwendigerweise in Konflikt, aber die Interaktion zwischen diesen erhöht die Komplexität der ersten Präsentation eines Projekts. Ein paar Informationen sind für beide Zielgruppen nützlich, manche nur für die Eine oder die Andere. Beide Arten von Informationen sollten das Prinzip der skalierten Darstellung berücksichtigen: Der präsentierte Detaillierungsgrad jeder Stufe sollte der Zeit und dem Aufwand entsprechen, den der Leser zu diesem Zeitpunkt einzubringen bereit ist. Mehr Aufwand sollte immer mehr Belohnung bewirken. Wenn Anstrengung und Belohnung nicht zuverlässig korrelieren, werden die meisten Menschen das Vertrauen verlieren und aufhören, Mühe zu investieren. Daraus folgt: Das Erscheinungsbild ist wichtig. Programmierern fällt es besonders schwer, das zu glauben. Ihre Liebe des Inhalt über der zur Form 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 Design erschrocken sind, auf dass 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 von dessen 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 Webseite 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: "Sie verschwenden ihre Zeit nicht, wenn Sie sich beteiligen". Das ist genau die Botschaft, die Menschen hören wollen. Was wir unter Nutzern und Entwicklern verstehen Die Begriffe Nutzer und Entwickler bezieht sich hier auf die Beziehung, die jemand mit einem betreffenden Software Projekt hat, nicht auf ihre Identität in der Welt in Gänze. Wenn beispielsweise das Open-Source Projekt eine für die Benutzung in der Webentwicklung vorgesehene Javascript Bibiliothek ist und jemand benutzt die Bibleothek als Teil ihrer Arbeit zum Bau von Webseiten, dann ist sie eine "Nutzerin" dieser Bibleothek (obwohl ihr professioneller Titel "Software-Entwickler" sein mag). Aber wenn sie anfängt, Bugfixes und Verbesserungen wieder stromaufwärts beizutragen - das heißt wieder in das Projekt - dann, soweit sie in die Wartung des Projekts involviert ist, ist sie auch "Entwicklerin" des Projekts. Für Entwickler ist es üblich, in einem Open Source-Projekt auch Benutzer zu sein, aber es ist nicht immer der Fall. Besonders bei großen Projekten, die von Organisationen begonnen wurden, um unternehmensweite Softwareanforderungen zu erfüllen, müssen die Entwickler nicht immer direkte Benutzer der Software sein, obwohl sie normalerweise immer noch Teil des Teams sind, welches diese Software innerhalb ihrer Organisation verwendet. Bei Projekten, die in erster Linie für Programmierer gedacht sind, ist die Grenze zwischen Benutzer und Entwickler sehr durchlässig: Jeder Benutzer ist ein potenzieller Entwickler. Aber auch in Projekten, die für Nicht-technische Personen gedacht sind, sind einige Prozent der Benutzer potenziell Entwickler. Open Source-Projekte sollten so ausgeführt werden, dass dieser Übergang für alle Interessierten einladent wird. Wenn Sie ein "Hosting-Paket"Anm. d. Übersetzers: Wir verwenden den Begriff "Hosting-Packet", weil der engl. Begriff "canned hosting" im deutschen Sprachraum nicht geläufig ist. Ein anderer, auch im deutschen Sprachraum geläufiger Begriff, ist "Shared Hosting". "Hosting-Paket" schien uns beim Übersetzen am geeignetsten zu sein. verwenden (sieh in ), ist ein Vorteil dieser Variante, dass deren Seiten ein Standardlayout haben, welches von Projekt zu Projekt ähnlich und sehr gut geeignet ist, um ein Projekt der Welt zu präsentieren. Dieses Layout kann auf bestimmte Weise angepasst werden, in gewissen Grenzen, aber das Standarddesign fordert Sie auf, die Informationen einzupflegen, welche Besucher am ehesten suchen. 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 es kann sich beträchtlich lohnen. Sollten die üblichen Suchmaschinen keine brauchbaren Ergebnisse liefern, sollte Sie es direkt bei https://github.com/, https://freshcode.club/, https://openhub.net/ und beim Verzeichnis freier Software der Free Software Foundation https://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 selbst komplett von Vorne anzufangen. Sieh in zu einer Diskussion, auf welche Weise ein existierendes Open-Source Projekt schnell zu evaluieren ist. 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 ein Entwurfsdokument. 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 andere 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 normalerweise "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 speziell für die USA über verfügbar. Ist idealerweise als Domain-Name verfügbar in den Top-Level-Domains .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.Die Wichtigkeit von Top-Level Domainnamen nimmt scheinbar ab. Zahlreiche Projekte haben gerade ihren Namen in der .io TLD, beispielsweise, und scheren sich nicht um .com, .net oder .org. Ich kann nicht vorhersagen, wie die Marken-Psychologie von Domainnamen in Zukunft sein wird, daher nutzen Sie ihr Urteilsvermögen und wenn Sie unter all den wichtigen TLDs den Namen bekommen können, tun Sie es. Möglicherweise ist er als Nutzername auf https://twitter.com/ und anderen Mikroblogseiten verfügbar. Siehe zu Details dazu und dessen Beziehung zu Domainnamen. Besitze den Namen in wichtigen Namensräumen Für große Projekte ist es eine gute Idee, den Projektnamen in sovielen relevanten Namensräume des Internet zu besitzen wie möglich. Mit Namensräume meine ich nicht nur das Domain Name System, sondern auch online Dienste, bei denen Kontonamen (Benutzernamen) die öffentlich sichtbaren Anlaufstellen sind, durch welche Personen auf das Projekt verweisen. Wenn sie den gleichen Namen überall dort haben, wo Menschen nach ihnen suchen würden, ist es für die Menschen leichter, ein laues Interesse am Projekt zu wahren, bis sie zu mehr Engagement bereit sind. Beispielsweise hat das freie Desktop-Projekt Gnome den https://gnome.org/ Domainnamen Sie schafften es nicht, gnome.com oder gnome.net zu bekommen, aber das ist okay — wenn sie nur einen haben und es der .org ist, ist das ausgezeichnet. Das ist normalerweise der Erste, nach dem Leute suchen, wenn sie nach einem Open-Source Projekt diesen Namens Ausschau halten. Wenn Sie "gnome.org" selber nicht bekommen können, kann eine übliche Lösung darin bestehen, stattdessen "gnomeproject.org" zu nehmen und viele Projekte lösen das Problem auf diese Weise., die https://twitter.com/gnome Twitter Anlaufstelle, den https://identi.ca/gnome Nutzernamen bei Identi.cahttps://identi.ca/ ist eine Open-Source Mikrobolog / Sozial Networking Platform, die zahlreiche freie Software Entwickler nutzen., den https://github.com/gnome Nutzernamen bei GitHub.comWährend die Hauptkopie des Gnome Sourcecodes bei https://git.gnome.org/ liegt, pflegen sie eine gespiegelte Kopie bei GitHub, seit so viele Entwickler sich bereits mit GitHub auskennen und beim Freenote IRC Netzwerk (siehe ) haben sie den Kanal #gnome, obwohl sie auch ihren eigenen IRC Server warten (wo sie den Kanal Namensraum sowieso kontrollieren). All dies macht das Gnome Projekt blendent einfach auffindbar: Es ist im Allgemeinen genau da, wo ein potentieller Unterstützer erwarten würde es anzutreffen. Sicher, Gnome ist ein großes und komplexes Projekt mit tausenden Unterstützern und vielen Unterteilungen; Der Nutzen für Gnome, einfach Auffindbarkeit zu sein, ist größer als er bei einem neueren Projekt wäre, bis jetzt gibt es so viele Wege, an Gnome teilzunehmen. Aber es wird sicher niemals ihrem Projekt schaden, seinen Namen in soviel wie möglich relevanten Namensräumen zu besitzen und das kann manchmal hilfreich sein. Wenn sie also ein Projekt starten, denken sie darüber nach, was der Online Anlaufpunkt sein sollte, und registrieren sie diesen bei den Online-Diensten um die sie sich sorgen. Die weiter oben Erwähnten sind möglicherweise eine gute Anfangsliste, aber sie mögen andere kennen, die für den konkreten Bereich ihres Projektes relevant sind. Formulieren Sie ein klares Missionsziel Sobald Besucher ihre Projektseite gefunden haben, werden sie nach einer kurzen Beschreibung oder dem Leitbild 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 Beschreibung sollte konkret, klar umrissen und vor allem kurz sein. Hier ist ein gutes Beispiel von https://hadoop.apache.org/:

Das Apache™ Hadoop® Projekt entwickelt Open-Source Software für zuverlässiges, skalierbares, verteiltes Rechnen. Die Apache Hadoop Software Bibliothek ist ein Rahmenwerk, dass es erlaubt, für verteilte Abarbeitung von großen Datensätzen über Computer-Cluster hinweg, ein einfaches Programmiermodell zu nutzen. Es wurde designed, um von einem einzelnen Server bis hin zu tausenden Maschienen zu skalieren, von denen jede lokale Rechen- und Speicherkapazität anbietet. Es verlässt sich weniger auf Hardware, um Höchverfügbarkeit zu liefern, sondern die Bibleothek selbst wurde designed, um Fehler im Applikationslayer zu ermitteln und zu behandeln, so dass Hochverfügbarkeit auf Ebene eines Cluster aus Computern geliefert wird, von denen jeder fehleranfällig sein kann.

In nur vier Sätzen haben sie alle Highlights getroffen, weitestgehend durch das Vorwissen des Lesers. Das ist ein wichtiger Punkt: Es ist okay, von einem in Mindestmaß informierten Leser auszugehen, der grundsätzlich vorbereitet ist. Ein Leser, der nicht weiß, was "Cluster" und "Hochverfügbarkeit" in diesem Zusammenhang bedeutet, kann vermutlich nicht viel Nutzen aus Hadoop überhaupt ziehen, so dass es keine Veranlassung gibt, für einen Leser zu schreiben, der weniger als dieses weiß. Die Phrase "designed, um Fehler im Applikationslayer zu ermitteln und zu behandeln" hat Ingenieure im Auge, die Übung mit großformatigen Rechenclustern haben — wenn diese solche Worte sehen, werden sie wissen, dass die hinter Hadoop stehenden Leute diese Welt verstehen und der erstmalige Besucher wird Hadoop gerne weiterhin in Erwägung ziehen. Wer die Missionziele gelesen hat und weiterhin 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. Sagen Sie, dass das Projekt frei ist 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 nicht sagte, 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 darin nach einer Lizenzdatei zu schauen. Bitte machen Sie diesen Fehler nicht. 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 weiter unten 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, welche 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 kurze Zusammenfassung 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 3.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 Besucher wollen normalerweise wissen, wie es einem Projekt geht. Bei neuen Projekten wollen sie wissen, wie weit dessen Versprechen und dessen 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. Es gibt eine Reiche verschiedener Wege, um Antworten auf diese Fragen anzubieten. Einer ist, eine Seite zum Status der Entwicklung einzurichten, 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. Manche Projekte strukturieren ihre Entwicklungsstatus-Seite als Roadmap, welche die Zukunft beinhaltet: Vergangene Ereignisse werden an Zeitenpunkten gezeigt, die gerade erst vorbei sind, zukünftige an ungefähren Zeitpunkten, von denen das Projekt hofft, dass sie an diesen dann passieren. Der andere Weg — der sich mit dem Ersten nicht gegenseitig ausschließt und tatsächlich am besten mit diesem in Kombination gemacht wird — ist, verschiedene automatisch-pflegende Zähler und Indikatoren in die Startseite und/oder der Entwicklerseite des Projektes einzubetten, welche verschiedene Informationshäppchen zeigen, die zusammenfassend gesehen, einen Eindruck vom Entwicklungsstatus und Fortschritt des Projektes geben. Zum Beispiel ein Ankündigungs- oder Nachrichtenfenster, aktuelle Nachrichten zeigend, einen Twitter- oder ein anderer Microblog-Stream, der Benachrichtigungen anzeigt, die mit den angegebenen Hashtags des Projekts übereinstimmen, eine Zeitleiste von kürzlich veröffentlichten Versionen, ein Panel mit den letzten Aktivitäten im Bug-Tracker (Bugs eingereicht, Bugs geantwortet), eine andere Mailingliste oder Diskussionsforum-Aktivität usw. Jeder dieser Indikatoren sollte ein Zugangspunkt für weitere Informationen sein. Wenn Sie beispielsweise auf das Fenster "Letzte Fehler" klicken, sollten Sie den vollständigen Bug-Tracker oder zumindest eine erweiterte Ansicht der Bug-Tracker-Aktivität aufrufen. Tatsächlich gibt es zwei leicht unterschiedliche Bedeutungen für "Entwicklungsstatus", die hier miteinander verschmolzen werden. Eine ist das formale Gefühl: Wo steht das Projekt in Relation zu seinen erklärten Zielen und wie schnell kommt es voran? Die andere ist weniger formell, aber genauso nützlich: Wie aktiv ist dieses Projekt? Läuft das Zeug? Gibt es hier Leute, die Dinge erledigen? Oft ist diese letztere Darstellung das, was ein Besucher am meisten interessiert. Ob ein Projekt seinen letzten Meilenstein erreicht hat oder nicht, ist manchmal nicht so interessant wie die grundlegendere Frage, ob es eine aktive Gemeinschaft von Entwicklern gibt. Die zwei Begriffe des Entwicklungsstandes sind natürlich miteinander verbunden und ein gut dargestelltes Projekt zeigt beide Arten. Die Informationen können zwischen der Titelseite des Projekts (dort hinreichend dargestellt, um einen Überblick über beide Arten des Entwicklungsstatus zu geben) und einer eher auf Entwickler ausgerichteten Seite aufgeteilt werden. Beispiel: Launchpad Status Indikatoren Launchpad.net ist eine Site, die ziemlich gute Ergebnisse bei der Anzeige von entwicklerorientierten Statusindikatoren leistet. Launchpad.net ist insofern etwas ungewöhnlich, als dass es für einige Projekte sowohl eine primäre Hosting-Plattform, als auch für andere eine sekundäre, auf das Packen ausgerichtete Website ist (bzw. für die Anderen ist es der primäre Standort für das "Projekt", um das speziell zusamengestellte Programmpaket für das Ubuntu GNU / Linux-Betriebssystem, für das Launchpad entsprechend seiner Spezifikation entwickelt wurde, zu erhalten). In beiden Fällen werden auf der Startseite eines Projekts in Launchpad verschiedene automatisch gewartete Statusanzeigen angezeigt, die schnell Aufschluss über den Stand des Projekts geben. Während das einfache Nachahmen einer Launchpad-Seite wahrscheinlich keine gute Idee ist — Ihr eigenes Projekt sollte sorgfältig darüber nachdenken, was die besten Entwicklungsstatusindikatoren sind — bieten Launchpad-Projektseiten einige gute Beispiele für die Möglichkeiten. Beginnen Sie bei den folgenden ganz oben auf einer Projektseite und scrollen Sie nach unten: https://launchpad.net/drizzle oder https://launchpad.net/inkscape, um nur zwei zufällig heraus zu picken. Der Entwicklungsstatus sollte immer die Realität widerspiegeln 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; 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" ist keine Schande. 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 welche 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 geplanten 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. Alpha Releases können sich generell nach freien Stücken bei APIs und Funktionalität ändern. Die nächste Stufe, beta, bedeutet, dass die Software APIs abgeschlossen sind und alle groben bekannten Fehler behoben wurden, aber noch nicht genug getestet wurde, um als Produktions-Release zertifiziert zu sein. Der Sinn von Beta-Software ist, entweder zur offiziellen Version zu werden, angenommen, dass keine Fehler gefunden wurden, oder detaillierte Rückmeldungen an die Entwickler, so dass diese zügig die offizielle Version erreichen können. In einer Serie von Beta-Releases sollten sich APIs und Funktionalität nicht ändern, außer es ist absolut notwendig. 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 kümmert es nicht, das sie ihre Installationsprozeduren erst sehr spät standardisieren, in der Annahme, dass sie es jederzeit machen könnten: "Wir erledigen den Kram, sobald der Code näher an der Fertigstellung ist.". Hierbei übersehen diese jedoch, dass sie mit dem Hinausschieben der langweiligen Arbeiten zur Fertigstellung der Build- und Installations-Vorgänge den Zeitraum, um den Code startklar zu bekommen, tatsächlich verlängern — denn sie entmutigen Entwickler, welche ansonsten etwas zum Code beigetragen hätten, wenn nur sie selbst ihn bauen und testen können. Das Heimtückische daran ist, dass das Projekt nicht einmal davon erfährt, dass es all diese Entwickler verliert, 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 verprasst 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 Packetieren zahlt sich mit vervielfachtem Gewinn aus. Wenn Sie ein herunterladbares Paket freigeben, vergeben Sie diesem eine eindeutige Versionsnummer, damit die Leute zwei beliebige unterschiedliche Pakete auch unterscheiden können und wissen, welches das Aktuellere ist. Auf diesem Weg können von jenen Fehler in Bezug auf eine bestimmtes Paket gemeldet werden (was Auskunftgebende zu ermitteln hilft, ob der Fehler bereits behoben wurde oder nicht). Eine ausführliche Diskussion über Versionsnummerierung finden Sie in und Details zur Standardisierung von Build- und Installations-Vorgängen werden im , beides in behandelt. Zugriff auf Versionsverwaltung und Bugtracker Die Quellcodepakete herunterzuladen mag für diejenigen ausreichend sein, welche lediglich die Software installieren und benutzen wollen, aber das genügt nicht denjenigen, welche Fehler bereinigen oder neue Funktionen hinzufügen wollen. Nächtliche Quelltext-Schnappschüsse können helfen, sind aber nicht ausreichend granular für eine lebendige Entwicklergemeinschaft. Diese Leute brauchen Echtzeit-Zugriff auf den neuesten Quellcode und einen Weg, Änderungen basierend auf diese Quellen zu übermitteln. Die Lösung ist die Nutzung eines Versionskontroll-Systems — speziell ein online, öffentlich aufrufbares versionskontrolliertes Repository, aus dem jeder das Projektmaterial auschecken und nachfolgende Updates erhalten kann. Ein Versionskontroll-Repository ist ein Zeichen — für beide, Anwender und Entwickler, — das dieses Projekt sich darum bemüht, Leuten das für die Teilnahme notwendige zu geben. Seit dem dies hier geschrieben steht nutzen viele Open-Source Projekte https://github.com/, welches ein unbegrenztes freies öffentliches Versionskontrollsystem für Open-Source Projekte anbietet. Während GitHub nicht die einzige Wahl ist, ist es für die meisten Projekte eine vernünftige Wahl Obwohl GitHub auf Git basiert, einem weit verbreiteten Open-Source-Versionskontrollsystem, ist der Code, mit dem die Webservices von GitHub ausgeführt werden, nicht selbst Open Source. Ob dies für Ihr Projekt wichtig ist, ist eine komplexe Frage und wird ausführlicher in in behandelt.. Versionskontroll-Infrastruktur wird detailliert besprochen in in . Gleiches gilt für den Bugtracker. Die Bedeutung des Bugtracker liegt nicht allein in seinem täglichen 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 — und ein Projekt ist um so besser, je mehr Fehler darin protokolliert sind. Das mag sich widersprüchlich anhört, aber bedenken sie, dass die Anzahl der erfassten Fehlerberichte von drei Dingen abhängt: Die absolute Anzahl Softwarefehler, die im Code enthalten sind, die Anzahl seiner Benutzer und der Komfort mit dem diese Benutzer neue Fehler melden können. Von diesen dreien sind die letzten beiden wesentlicher als der Erste. 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 geringe Alter hervorhebt und wenn Leute, welche 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.Hinsichlich eines vollständigeren Arguments dafür, dass Fehlerberichte als "Good News" behandelt werden sollten, siehe http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/, in dem es hauptsächlich darum geht, dass die Anhäufung von Fehlerberichten eben nicht technische Schulden (engl. technical debt) repräsentieren (im Sinn von https://en.wikipedia.org/wiki/Technical_debt) sondern eher Nutzerengagement. 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 wird voraussichtlich nur ein Teil der Nutzer diese Foren sowieso nur nutzen, aber die anderen wird es 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 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 und wie Entscheidungen gefällt werden — 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 in darüber, warum Diktatur in Open-Source Projekten nicht dieselben Implikationen hat wie Diktatur in anderen Lebensbereichen.) http://subversion.apache.org/docs/community-guide/ ist ein Beispiel für besonders gründliche Entwicklerrichtlinien; die LibreOffice Richtlinien bei https://wiki.documentfoundation.org/Development sind ebenfall ein gutes Beispiel. If the project has a written Code of Conduct (see ), then the developer guidelines should link to it. Wenn das Projekt niedergeschriebene Verhaltensregeln hat (siehe ), dann sollten die Entwicklerrichtlinien darauf verweisen. 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 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 normalerweise nicht wieder angefasst werden müssen, wenn einmalig erledigt. 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 hinsetzten und die Sachen aufschreiben und dann, was am wichtigsten ist, die Anmerkungen der Leser einbinden. Benutzen Sie ein einfaches, leicht zu bearbeitendes Format wie HTML, Klartext, Markdown, ReStructuredText oder eine XML-Variante – etwas geeignetes für kleine und spontane VerbesserungenMachen Sie sich für den Anfang nicht zuviele Gedanken über das richtige Format. Wenn Sie ihre Meinung später ändern, können Sie immer noch eine autmatische Konvertierung mittes http://johnmacfarlane.net/pandoc/ durchführen.. 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 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. 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 Entwicklern 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 definitionsgemäß reaktive Dokumente, die sich im Laufe der Zeit als Antwort auf die Fragen entwickeln, welche die Benutzer nach der Software stellen. 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 als Vorlage einrichten, damit es eine offensichtlichen Ort gibt, 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 anzufügen, werden Leute dies auch tun. (Die vernünftige Pflege einer FAQ ist eine nicht ganz triviale, aber faszinierende Angelegenheit: siehe in , in und in .) 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 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 notwendigerweise die häufigste Art des Dokumentationszugriffs. 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, und keine monolitische Datei bereitzustellen, würde in solchen Fällen deren Leben unnötig erschweren. Entwickler-Dokumentation Developer documentation is written by programmers to help other programmers understand the code, so they can repair and extend it. This is somewhat different from the developer guidelines discussed earlier, which are more social than technical. Developer guidelines tell programmers how to get along with each other; developer documentation tells them how to get along with the code itself. The two are often packaged together in one document for convenience (as with the http://subversion.apache.org/docs/community-guide/ example given earlier), but they don't have to be. --> Die Entwickler-Dokumentation wird von Programmierer geschrieben, um anderen Programmierern zu helfen, den Code verstehen, so dass sie ihn 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 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 sich hinsichtlich der Organisation und des Tonfalls der Dokumentation einig sind. Mehr dazu steht in im Kapitel . If the infrastructure aspects of documentation workflow seem daunting, consider using https://readthedocs.org/. Many projects now depend on it to automate the process of presenting their documentation online. The site takes care of format conversion, integration with the project's version control repository (so that documentation rebuilds happen automatically), and various other mundane tasks, so that you and your contributors can focus on content. Wenn die Infrastrukturaspekte des Dokumentationsworkflows entmutigend werden, erwäge die Verwendung von https://readthedocs.org/. Viele Projekte vertrauen diesem beim automatisieren des Prozesses der Online-Präsentation ihrer Dokumentation. Die Seite kümmert sich um die Formatkonvertierung, Integration mit dem Versionkontroll-Repository des Projektes (so dass die Neuerstellung der Dokumentationen automatisch erfolgt) und verschiedene andere weltliche Aufgaben, so dass Sie und Ihre Mitarbeiter sich auf den Inhalt konzentrieren können. Demos, Screenshots, Videos und Beispielausgabe Ein Projekt mit graphischer Benutzeroberfläche oder mit graphischen oder anderen markanten Ausgaben, sollte Beispiele auf der Website des Projekts anbieten. Im Fall einer Benutzeroberfläche bedeutet dies Screenshots oder besser noch ein kurzes Video (4 Minuten oder weniger) mit Untertiteln und einem Sprecher. Für Ausgaben mögen es Screenshots oder eben Beispieldateien zum Download sein. Für web-basierte Software ist der goldenen Weg einen Demo-Seite, davon ausgehend, dass sie dem zugänglich ist. The main thing is to cater to people's desire for instant gratification in the way they are most likely to expect. A single screenshot or video can be more convincing than paragraphs of descriptive text and mailing list chatter, because it is proof that the software works. The code may still be buggy, it may be hard to install, it may be incompletely documented, but image-based evidence shows people that if one puts in enough effort, one can get it to run. Es geht hauptsächlich darum, das Bedürfnis des Menschen nach direkter Belohnung auf der Weise zu befriedigen, auf der sie es am ehesten erwarten. Ein einziges Bild oder Video kann überzeugender sein, als ganze Absä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. Halte die Videos kurz und <emphasis>Sage</emphasis> dass sie kurz sind Wenn sie eine Video-Demonstration ihres Projektes haben, halten sie das Video unter 4 Minuten und stellen sie sicher, dass die Leute die Dauer erkennen können, bevor diese darauf klicken. Dies, damit es dem zuvor bereits erwähntem "Prinzip der skalierten Präsentation" gehorcht: Sie möchten, dass die Entscheidung zur Sichtung des Videos leicht fällt, indem sie alle Risiken entfernen. Besucher klicken lieber auf einen Link der "Sieh dir unser 3 Minuten Video an" anstatt "Sieh dir unser Video an" heißt, weil sie im ersten Fall wissen, bevor sie klicken — worauf sie sich einlassen und sie sehen es sich eher an, weil sie mental auf die notwendige Zeit vorbereitet sind, und werden nicht auf der halben Strecke ermüden. Woher diese 4-Minuten Grenze kommt? Es ist eine wissenschaftliche Tatsache, welche durch viele Versuche derselben experimentellen Fragestellung (durch wen sein hier nicht genannt) zum Ansehen von Videos ermittelt wurde. Die Grenze bezieht sich nicht auf Tutorials oder anderes Anleitungsmaterial, ja; es bezieht sich nur auf Einführungsvideos. Für den Fall, dass sie nicht schon eine bevorzugte Software zur Bildschirmaufzeichnung haben: Wenn sie den GNOME 3 Desktop Manager nutzen, könenn sie den dort eingebauten Recorder nutzen ( siehe https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html.en#screencast — zusammenfassend, drücke Ctl+Alt+Shift+R um die Aufzeichnung zu starten, und drücke dann Ctl+Alt+Shift+R erneut, um sie anzuhalten). 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 Wo im Internet sollten sie ihr Projektmaterial platzieren? Auf einer Webseite, sicherlich — aber die umfassende Antwort darauf ist ein wenig komplizierter als das. Viele Projekte unterscheiden zwischen ihrer primär öffentlichen anwenderbezogenen Webseite — die mit den schönen Bildern und der "Über" Seite und den zaghaften Einführungen und Videos und Führungen und all dem Zeug — und ihrer Entwickler-Seite, wo alles schmuddelig und voller eng beieinander liegender Texte in Monospace-Schriften und undurchdringlichen Abkürzungen ist. Nun, ich übertreibe. Ein bisschen. In jedem Fall ist es in der frühen Phase Ihres Projekts nicht so wichtig, zwischen diesen beiden Zielgruppen zu unterscheiden. Die meisten interessierten Besucher werden Entwickler oder zumindest Leute sein, die gerne neuen Code ausprobieren. Im Laufe der Zeit kann es sinnvoll sein, eine benutzerbezogene Seite (wenn Ihr Projekt eine Codebibliothek ist, können diese "Benutzer" andere Programmierer sein) und einen etwas separaten Bereich für die Collaboration diejenigen zu haben, welche an der Teilnahme an der Entwicklung interessiert sind. Die Collaborations-Seite würde das Code-Repository, den Bug-Tracker, das Entwicklungs-Wiki, Links zu Entwicklungs-Mailinglisten usw. enthalten. Die beiden Websites sollten miteinander verknüpft sein. Insbesondere ist wichtig, dass auf der benutzerbezogenen Website klargestellt wird, dass es sich bei dem Projekt um Open Source handelt und wo sich die Open Source-Entwicklungsaktivität befindet. In der Vergangenheit, viele Projekte erstellten ihre Entwickler-Seite und Infrastruktur selbstständig. Seit der letzten Dekade oder so, wie auch immer, nutzen die meisten Open-Source-Projekte — und i.d.R. alle neuen — eine der gehosteten Seiten die entstanden sind, um diese Dienste kostenlos für Open-Source-Projekte anzubieten. Bis jetzt ist die popolärste Seite, zu Beginn von 2018, GitHub (https://github.com/) und wenn Sie keine starke Präferenz für ein bestimmtes Hosting haben, sollten sie wirklich GitHub wählen; viele Entwickler kennen es bereits gut und haben persönliche Accounts dort. Siehe in hinsichtlich einer detaillierteren Diskussion der Fragen, die bei der Auswahl einer vorgefertigten Hosting-eite zu berücksichtigen sind und für einen Überblick über die beliebtesten. Die Wahl einer Lizenz und ihre Anwendung 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 Software zu kombinieren. Synonyme: "free software license", "FSF-approved", "open source license" und "OSI-approved" Die Begriffe "free software license" und "open source license" sind inhaltich Synonyme und ich behandele sie als solche das ganze Buch hindurch. Technisch gesehen bezieht sich der erstgenannte Begriff auf Lizenzen, die von der Free Software Foundation als mit den "vier Freiheiten" versehen bestätigt wurden, die für freie Software erforderlich sind (siehe https://www.gnu.org/philosophy/free-sw.html), wohingegen der letztere Begriff sich auf Lizenzen bezieht, welche die Open Source Definition der Open Source Initiative erfüllen (https://opensource.org/osd). Wie auch immer, wenn sie die FSF Definition von freier Software und die OSI Definition von Open-Source-Software lesen, wird es offensichtlich, dass die beiden Definitionen die gleichen Freiheiten umreißen — nicht überraschend, wie in erklärt. Das unvermeidliche und in gewissem Sinne absichtliche Ergebnis ist, dass die beiden Organisationen denselben Lizenzsatz genehmigt haben.Aktuell gibt es ein paar kleine Unterschiede zwischen den jeweiligen Listen der geprüfter Lizenzen, aber diese sind für unsere Zwecke nicht signifikant — oder tatsächlich für die meisten praktischen Belange. In einigen Fällen ist die eine oder andere Organisation einfach nicht dazu gekommen, eine bestimmte Lizenz in Betracht zu ziehen, normalerweise eine Lizenz, die ohnehin nicht weit verbreitet ist. Und anscheinend (so wurde mir gesagt) gab es historisch gesehen eine Lizenz, der mindestens eine der Organisationen und möglicherweise beide zustimmten, dass sie einer Definition entsprachen, der anderen jedoch nicht. Immer wenn ich versuche, die Details dazu zu erfahren, bekomme ich eine andere Antwort darauf, was diese Lizenz war, außer dass die genannte Lizenz immer eine ist, die sowieso nicht von vielen Personen verwendet wurde. Daher können die Begriffe "OSI-genehmigt" und "FSF-genehmigt" für jede Lizenz, die Sie wahrscheinlich verwenden, so behandelt werden, als würden sie sich gegenseitig implizieren. 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 am häufigsten verwendeten 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-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 License, version 3 (https://www.gnu.org/licenses/gpl.html). 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. Siehe in for details. Wenn Anwender auf ihren Code hauptsächlich über eine Netzwerkverbindung zugreifen — meist dann, wenn die Software gewöhnlicherweise eher Bestandteil eines gehosteten Service ist anstatt verteilt zu werden, um auf einem Client zu laufen — dann erwäge, stattdessen die GNU Affero GPL zu nutzen. Die AGPL ist gerade die GPL mit einer zusätzlichen Klausel, welche die Netzwerkzugänglichkeit als eine Form der Verteilung in der Lizenz festschreibt. Siehe in for more. 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 benennen. 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, Version 3 der Lizenz oder (nach Ihrer Wahl) jeder neueren veröffentlichten Version, weiterverbreiten und/oder modifizieren. Dieses Programm wird in der Hoffnung, dass es nützlich sein wird, aber OHNE JEDE GEWÄHRLEISTUNG, bereitgestellt; sogar ohne die implizite Gewährleistung der MARKTFÄHIGKEIT oder EIGNUNG FÜR EINEN BESTIMMTEN ZWECK. Siehe die GNU General Public License für weitere Details. Sie sollten eine Kopie der GNU General Public License zusammen mit diesem Programm erhalten haben. Wenn nicht, siehe <http://www.gnu.org/licenses/>.

Damit drücken Sie nicht explizit aus, dass der vollständige Text der Lizenz in der Datei COPYING oder LICENSE steht, es ist aber meistens der Fall. (Sie können den obigen Hinweis abändern um dies direkt auszudrücken, was aber nicht wirklich notwendig ist.) Generell muss die Notiz, die sie in jede Sourcecode-Datei einfügen, nicht exakt wie die weiter oben aussehen, solange sie mit dem selben Hinweis auf den Inhaber des Urheberrechts und dem DatumDas Datum sollte die Datümer auflisten, an denen die Datei verändert wurde, aus Urheberechtsgründen. Mit anderen Worten würden sie für eine Datei, die 2008, 2009 und 2013 geändert wurde "2008, 2009, 2013" — nicht "2008-2013" schreiben, weil die Datei nicht in jedem Jahr des Zeitbereichs geändert wurde. beginnt, den Namen der Lizenz nennt und klarstellt, wo der vollständige Text der Lizenz einzusehen ist. Es ist natürlich immer am besten, einen Anwalt zu konsultieren, wenn Sie sich einen leisten können. Den Ton angeben Bis jetzt haben wir Aufgaben behandelt, welche einmalig 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 anwenden 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 wiederholt weitergegeben werden. Die Lebenszeit freier Software-Projekte wird vielleicht nicht in Jahrhunderten gemessen (zumindest bis jetzt 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 Anstrengung 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, (http://subversion.apache.org/), in dem ich tätig war und das ich seit seiner Gründung beobachte. 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 Neulingen 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, mögen viele im Stillen lauern, um Informationen über das Projekt zu sammeln. Bei der Diskussion werden Sie die Kunst erlernen, technische Angelegenheiten für Leute zu erklären, welche 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 sie es intuitiv erwarten würden. 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 mit ihnen 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 Projekt an die Öffentlichkeit geht, null Toleranz gegenüber unhöflichem oder beleidigendem Verhalten in ihren 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 einen anderen Entwickler koppelt, ist es zwingend notwendig, dass Ihre Reaktion 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; zum Beispiel, 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 jemand protestiert, dass er unrechtmäßig zurechtgewiesen wurde, sollten Sie sich nicht in einen 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 ein Eingeständnis, 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, welche 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. Verhaltensregeln In der Dekade seit der ersten Ausgabe dieses Buches von 2006 ist es gewissermaßen üblicher für Open-Source-Projekte geworden, gerade auch für die Größeren, explizite Verhaltensregeln zu verabschieden. Ich denke dies ist ein guter Trend. Da Open-Source-Projekte nach langer Zeit endlich auch vielfältiger werden, kann das Vorhandensein eines Verhaltenskodex die Teilnehmer daran erinnern, zweimal darüber nachzudenken, ob ein Witz für manche Menschen verletzlich sein könnte oder ob es — um ein zufälliges Beispiel zu nehmen — zu einer willkommenden und einbindenden Atmosphäre beiträgt wenn eine Dokumentation einer Open-Source Bildbearbeitungsbibliothek abermals ein weiters Bild einer hübschen jungen Frau verwendet um das Verhalten eines bestimmten Algorithmus zu illustrieren. Verhaltensregeln erinnern Teilnehmende daran, dass die Pflege einer respektvollen und willkommenden Umgebung eines jeden Verantwortung ist. Eine Internetsuche wird leicht viele Beispiele von Verhaltensregeln für Open-Source-Projekte finden. Die Populärste ist möglicherweise die bei https://contributor-covenant.org/, so ist dort natürlicherweise eine positive Rückkoppelungsdynamik wenn Sie diese wählen: Mehrere Entwickler werden diese bereits kennen, zusätzlich bekommen sie ihre Übersetzung in andere Sprachen kostenlos usw. Ein Verhaltenskodex wird nicht alle zwischenmenschlichen Probleme in ihrem Projekt lösen. Weiter gilt, wenn er missbraucht wird, dass er das Potential hat, neue Probleme zu erzeugen — es ist immer möglich, Menschen zu finden, die sich darauf spezialisiert haben, soziale Normen und Regeln zu manipulieren, um einer Gemeinschaft Schaden zuzufügen, anstatt ihr zu helfen (siehe in ), und wenn sie selbst zum Teil unglücklich sind, mögen einige dieser Menschen ihren Weg in ihr Projekt finden. Es liegt immer an der Führung des Projektes, wobei ich diejenigen meine, denen die meisten anderen des Projektes am meisten bereitwillig zuhören, einen Verhaltenskodex durchzusetzen und darauf zu achten, dass er weise benutzt wird (Siehe auch in ). Einige Teilnehmer werden tatsächlich nicht mit der Notwendigkeit, überhaupt einen Verhaltenskodex einzuführen, übereinstimmen und argumentieren gegen ihn mit der Begründung, dass er mehr Schaden als Gutes anrichten könnte. Auch wenn sie den Eindruck hast, dass diese falsch liegen, ist es zwingend, dass sie sicherzustellen helfen, dass diese ihre Meinung äußern können ohne dafür angegriffen zu werden. Nach allem nicht mit der Notwendigkeit eines Verhaltenskodex übereinzustimmen ist nicht das Selbe wie — es ist faktisch komplett unabhängig davon — sich in einem Verhalten zu engagieren, welches eine Verletzung des angestrebten Verhaltenskodex darstellt. Manchmal bringen Menschen diese Dinge durcheinander und müssen an diesen Unterschied erinnert werden.Es gibt einen exzellenten Post mit Titel https://subfictional.com/2016/01/25/the-complex-reality-of-adopting-a-meaningful-code-of-conduct/ von Christie Koehler, der das viel tiefergehender bespricht. 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 jeden Commit, den irgendjemand machte, folgte bald eine E-Mail von Greg an die 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, mich 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, öffnen, 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 Meinungen über ihn allein anhand des Quellcodes bilden, ohne zu wissen, welcher geschäftliche 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ßenstehenden 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 gewöhnt. 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 Scanley-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örtern 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 öffentlicher 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 Kapitel handeln vom Arbeiten in einer solchen Umgebung.