Kapitel 2. Der Einstieg

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:

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/:

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.

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 „Die Wahl einer Lizenz und ihre Anwendung“; Lizenzfragen werden ausführlich im Kapitel Kapitel 9, Lizenzen, Urheberrecht und Patente behandelt.

Bis hierhin hat sich unser hypothetischer Besucher entschieden  — wahrscheinlich innerhalb der ersten Minute oder schon vorher  — ob er interessiert ist, sagen wir, zumindest weitere fünf Minuten in das Projekt zu investieren. Der nächste Abschnitt beschreibt, was er innerhalb dieser fünf Minuten vorfinden sollte.

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:

Die Liste der Funktionen und Anforderungen würde Details bieten, um das Missionsziel zu verdeutlichen:

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.

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.

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 „Versionszählung“ und Details zur Standardisierung von Build- und Installations-Vorgängen werden im „Erstellung der Pakete“ behandelt.

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^[21]. Versionskontroll-Infrastruktur wird detailliert besprochen in „Versionsverwaltung“.

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.^[22]

Man sollte auch beachten, dass Bugtracker oft nicht nur zur Verfolgung von Bugs, sondern auch für Verbesserungen an der Software, Änderungen an der Dokumentation, ausstehende Aufgaben und mehr benutzt werden. Weiteres zum Betrieb eines Bugtrackers, wird in „Bugtracker“ 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.

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 (Kapitel 3, Technische Infrastruktur), 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 „Handhabung von Wachstum“, 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.

Wenn jemand sich überlegt, etwas zu einem Projekt beizutragen, wird er sich nach Richtlinien für Entwickler umschauen. Diese sind weniger technischer, als viel mehr sozialer Natur: Sie erklären, wie Entwickler miteinander und mit Benutzern umgehen, also letzlich wie die Dinge laufen sollten.

Dieses Thema wird ausführlich in „Schriftliche Regeln“ behandelt, aber die wesentlichen Elemente der Richtlinien sind:

Ü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 „Aufspaltbarkeit“ 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 „Verhaltensregeln“), then the developer guidelines should link to it.

Wenn das Projekt niedergeschriebene Verhaltensregeln hat (siehe „Verhaltensregeln“), dann sollten die Entwicklerrichtlinien darauf verweisen.

Das etwas andere Thema, die Bereitstellung einer Projekt-Einführung für Programmierer, wird im Abschnitt „Entwickler-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 Verbesserungen^[23]. 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:

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.

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.

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 „Hosting-Pakete“ 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.