056.3 Lektion 1

Synchrone Kommunikation ist ebenso effektiv wie anspruchsvoll und findet zu einem bestimmten Zeitpunkt im gleichen physischen oder virtuellen Raum statt.

Ein direktes Treffen ist ideal, um Fragen interaktiv zu klären, anstatt lange E-Mail-Nachrichten auszutauschen, die das Risiko von Missverständnissen mit sich bringen. Stellen Sie sich vor, Sie wollen mehr über ein Open-Source-Projekt erfahren und die Mitglieder der Community kennenlernen; E-Mail-Nachrichten und Websites können bei der Einführung helfen und haben niedrigere Einstiegshürden, aber ein nachhaltiger erster Eindruck entsteht, wenn Sie mit jemandem persönlich sprechen. Es sind nicht zuletzt diese direkten Interaktionen, die an einem Open-Source-Projekt faszinieren und dazu motivieren, selbst etwas beizutragen.

Neben dem gegenseitigen Kennenlernen eignen sich synchrone Treffen insbesondere auch bei Konflikten oder Problemen — oder wenn man negative Nachrichten überbringen muss.

Aber natürlich sind internationale Projekte mit einer Herausforderung konfrontiert, die keine Technologie überwinden kann: Zeitzonen. Bei Mitwirkenden auf verschiedenen Kontinenten ist es schwierig, Zeitfenster für Besprechungen zu finden, die allen passen. In Australien wacht vielleicht gerade jemand auf, wenn jemand in Europa kurz davor ist, Feierabend zu machen. Eine weitere Herausforderung besteht darin, dass manche Beiträger nur nachts oder am Wochenende Zeit finden, während andere die Bürozeiten an Werktagen bevorzugen.

Hinzu kommt, dass nicht jeder fließend Englisch spricht — und noch gibt es keine allgemein zugänglichen und verlässlichen Werkzeuge zum Simultandolmetschen.

Dennoch sind Videokonferenzen eines der häufigsten Kommunikationsmittel in Open-Source-Projekten. Das LibreOffice-Projekt führt regelmäßig Online Meetings für seine Community durch, beispielsweise für Entwickliung, Marketing, Infrastruktur, Qualitätssicherung, Benutzererfahrung und Design.

Über asynchrone Kommunikation beteiligt man sich an einer Diskussion zu einem Zeitpunkt und in einer Geschwindigkeit, die einem selbst angemessen scheint. Bekanntestes Beispiel ist wahrscheinlich E-Mail: Sie antworten auf eine Nachricht, wann immer Sie es für angemessen halten — sei es in der nächsten Minute oder am nächsten Tag.

Asynchrone Kommunikation erfolgt meist schriftlich, was auch eine maschinelle Übersetzung erlaubt. So können Sie Nachrichten in einer Fremdsprache lesen und verstehen und sogar Ihre Antwort rückübersetzen.

Niedergeschriebene Inhalte sind auch leichter zu behalten oder in Dokumentation zu überführen. Einem Benutzer am Telefon die Funktion einer Software zu erklären ist deutlich schwieriger, als die Erklärungen in einem Support-Dokument aufzubereiten.

Nicht zuletzt hängt Kommunikation auch davon ab, ob es sich um interne oder externe Empfänger handelt. Sie werden eine interne Notiz an die Systemadministratoren anders verfassen als eine Pressemitteilung für Hunderte Journalisten. Bedenken Sie jedoch, dass aufgrund der Natur eines Open-Source-Projekts Kommunikation, die ursprünglich vielleicht nicht explizit für die Öffentlichkeit bestimmt war, öffentlich werden kann, beispielsweise in den Archiven von Mailinglisten (im Fall von LibreOffice ist es https://listarchives.documentfoundation.org/).

Eines der ersten Tools, das Sie in der Kommunikation mit einem Open-Source-Projekt nutzen werden, ist die “klassische” E-Mail. Viele Projekte betreiben Mailinglisten, die im Wesentlichen Verteilerlisten für E-Mails sind: Mit einer E-Mail-Nachricht erreichen Sie hunderte oder sogar tausende von Abonnenten, die an bestimmten Themen interessiert sind.

Mailinglisten gehören zu den ältesten Tools von Open-Source-Projekten und dienen sowohl der projektinternen Koordination als auch der Interaktion mit den Benutzern. Wenn Sie eine Frage zur Software haben oder einen Fehler im Programm melden wollen, ist die Wahrscheinlichkeit groß, dass es dafür eine Mailingliste gibt. Die LibreOffice-Community beispielsweise bietet eine Vielzahl internationaler und lokaler Mailinglisten für verschiedene Themen an (https://www.libreoffice.org/get-help/mailing-lists/), von der Benutzerunterstützung über Diskussionen mit den Entwicklern bis hin zur Koordination der Infrastruktur (LibreOffice Webseite für Mailinglisten).

Jede gesendete Nachricht wird in der Regel auch in einem öffentlichen Mailinglisten-Archiv gespeichert. Einmal versendet, kann eine Nachricht nicht mehr ohne weiteres gelöscht werden — gemäß der gängigen Redewendung: “Das Internet vergisst nichts.” Man sollte mit seinen Nachrichten darum durchaus vorsichtig sein. Vermeiden Sie beispielsweise die Angabe Ihrer privaten Adresse oder Telefonnummer in der Signatur oder den Versand vertraulicher Dokumente im Anhang.

Ein Nachteil von Mailinglisten ist, dass die Verwaltung in einem Mailprogramm nicht immer einfach ist. Sogenannte Filter, die auf bestimmten Elementen der Nachricht basieren (etwa einem Präfix in der Betreffzeile) helfen dabei. Die Feinheiten im Umgang mit einer großen Menge von E-Mails können für unerfahrene Benutzer schwierig sein. Daher gehen immer mehr Projekte zu Diskussionsforen über — davon später mehr.

Eine besondere Form der Mailingliste ist der Newsletter. Wenn Sie über die neuesten Projektentwicklungen auf dem Laufenden bleiben und über neue Softwareversionen informiert werden möchten, abonnieren Sie den Newsletter und erhalten eine E-Mail-Nachricht, wenn etwas Wichtiges passiert.

Abgesehen von dem Aufwand, den die Verwaltung von Mailinglisten in einem E-Mail-Programm erfordert, setzen vor allem jüngere Menschen immer weniger auf E-Mail als Kommunikationsmittel. Auch darum verlagern immer mehr Open-Source-Projekte ihre Kommunikation in Diskussionsforen. Die Grundidee ist mit E-Mail durchaus vergleichbar: Jedes Forum hat verschiedene Kategorien/Themen, in denen man sich austauscht, sogenannte Threads. Ähnlich wie bei E-Mail kann man in einem Forum mit dem Open-Source-Projekt in Kontakt treten und Aktivitäten koordinieren, Vorschläge für die Richtung des Projekts machen und als Benutzer Fehler melden.

Alles, was in einem Forum gepostet wird, ist in der Regel öffentlich sichtbar, genau wie in einer Mailingliste; aber anders als dort lassen sich Inhalte je nach Konfiguration des Forums auch nachträglich bearbeiten oder löschen. Die Benutzerfreundlichkeit von Foren ist, besonders für Einteiger, oft höher als die von Mailinglisten. Das LibreOffice-Projekt hat damit begonnen, einige seiner Mailinglisten in Foren umzuwandeln (https://community.documentfoundation.org/) und konnte seitdem eine steigende Beteiligung an den Diskussionen verzeichnen.

Ein weiterer Weg, mit einer Open Source Community in Kontakt zu treten, sind Instant Messages (Sofortnachrichten) und Chat-Plattformen. Mit dem Aufkommen von Tools wie WhatsApp, Telegram, Signal oder Matrix hat fast jeder bereits eine dieser populären Anwendungen auf seinen Geräten installiert, was die Einstiegshürde deutlich niedriger macht. Sofortnachrichten sind auch bei jüngeren Leuten sehr viel beliebter als E-Mail oder Foren. Es überrascht daher nicht, dass viele Open-Source-Projekte diese heutzutage einsetzen.

Chat-Teilnehmer geben Nachrichten ein, die ähnlich wie E-Mails an alle anderen Teilnehmer gesendet werden. Je nach Chat-Plattform lässt sich eine Nachricht formatieren und mit Grafiken und Anhängen ergänzen.

Nachrichten-Apps sind ähnlich organisiert wie Foren oder E-Mail. Es stehen mehrere Gruppen oder Channel (Kanäle) zur Verfügung, an denen man sich je nach Interesse beteiligt. Nachrichten lassen sich in der Regel bearbeiten oder löschen; oft gibt es auch reine Ankündigungskanäle, deren Funktion der eines E-Mail-Newsletters entspricht.

Nachteil von Instant-Messenger-Apps ist, dass sie meist auf dem Mobiltelefon installiert sind, das auf jede neue Nachricht hinweist. Dies führt schnell zu einer Informationsflut bzw. “Alarmmüdigkeit”. Mit der richtigen Konfiguration sind diese Benachrichtigungen jedoch zu handhaben.

Ein weiterer Nachteil besteht darin, dass viele Messenger-Apps proprietär und in den Händen eines einzigen Anbieters sind, was die langfristige Bewahrung von Wissen erschwert, wenn die Daten nicht frei zugänglich sind.

Open-Source-Projekte arbeiten offen, auf der Grundlage offener Standards und offener Werkzeuge. Daher ist es wichtig zu verstehen, wie diese Werkzeuge im Hinblick auf Interoperabilität konzipiert sind. Drei Kategorien sind dabei zu unterscheiden.

Eine stand-alone Plattform läuft isoliert für eine Community. Beispiele sind Foren oder Wikis, die in der Regel nicht mit Instanzen anderer Projekte verbunden sind.

Dezentrale oder föderale Systeme laufen separat für jede Community, können aber miteinander verbunden werden. Ein Beispiel ist E-Mail: ein lokaler E-Mail-Server kann E-Mails an jeden anderen E-Mail-Server in der Welt senden. Andere Beispiele sind Nextcloud und ownCloud, die Dateifreigaben mit anderen Servern “föderieren”, oder der Messenger-Dienst Element, über den man mit Benutzern anderer Server kommunizieren kann. Die gleichen Prinzipien gelten für das soziale Netzwerk Mastodon.

Sowohl stand-alone als auch verteilte Plattformen haben einen großen Vorteil: Das Open-Source-Projekt behält die volle Kontrolle über alle Inhalte und Funktionen. Das gesamte in einem solchen System gespeicherte Wissen bleibt in den Händen der Open Source Community und unterliegt nicht der Kontrolle durch Dritte.

Ein zentralisiertes System hingegen wird von einem Anbieter betrieben und interagiert nicht mit Dritten. Klassische Beispiele sind soziale Netzwerke wie Facebook oder Instagram oder Messenger-Apps wie WhatsApp oder Telegram. Alle Inhalte werden auf den Servern des externen Anbieters gespeichert und unterliegen dessen Geschäftsbedingungen.

Wenn Sie in einer Open Source Community aktiv sind, nutzen Sie wahrscheinlich alle drei Optionen. Zentralisierte Systeme eignen sich hervorragend, um viele Menschen zu erreichen, da sie oft beliebt sind und eine breite Benutzerbasis haben. Für die eigentliche Arbeit im Projekt ist jedoch ein föderales oder stand-alone System unter der Kontrolle der Community am besten geeignet.

Eines der ältesten und beliebtesten Werkzeuge der Zusammenarbeit ist das Wiki. Berühmt geworden vor allem durch Wikipedia, ermöglicht ein Wiki den Benutzern die gemeinsame Arbeit an einer Website, die aus mehreren Dokumenten oder “Artikeln” besteht. Sie können in verschiedenen Kategorien gruppiert und nach Sprache gefiltert werden und enthalten Formatierungen, Tabellen und Bilder.

Wikis dienen oft als Wissensdatenbank, zu der jeder beitragen kann. Wenn Sie Content für ein Open-Source-Projekt liefern möchten, ist die Teilnahme an dessen Wiki ein guter Einstieg. Sie können bestehende Inhalte übersetzen, Artikel bearbeiten und aktualisieren oder neue Inhalte erstellen. Im Wiki des LibreOffice-Projekts (https://wiki.documentfoundation.org) finden Sie Marketingmaterial, Protokolle von Vorstandssitzungen, Installationsanleitungen und Konferenzplanung, und das alles in zahlreichen Sprachen (LibreOffice Wiki).

Viele Open-Source-Projekte stellen ihre Dokumentation und das integrierte Hilfesystem ihres Programms auch in einem Wiki zur Verfügung. Zudem werden alte Versionen einer Seite (Revisionen) für künftige Referenzen archiviert.

Obwohl Wikis auch Projektdateien speichern können, gibt es bessere Werkzeuge für diesen Zweck, wie wir noch sehen werden.

Ein häufig genutztes Werkzeug in einem Open-Source-Projekt sind Bug Tracker, auch Issue Tracker genannt. Um ein Problem in der Software zu melden oder eine neue Funktion vorzuschlagen, könnten Sie eine E-Mail an das Projekt schicken — über einen Bug Tracker lassen sich jedoch alle erforderlichen Informationen und Schritte zur Reproduktion des Problems in strukturierter Form übermitteln, was es den Entwicklern deutlich einfacher macht. Ein solch strukturierter Bericht wird als Bug Report bezeichnet.

Außerdem gehen die Informationen nicht verloren, und das Projekt vergisst das Problem nicht; es kann es der richtigen Person zuordnen und sehen, wie viele Fehler bearbeitet oder behoben werden.

Das LibreOffice-Projekt bietet einen Bug Tracker, zu dem jeder beitragen kann (https://bugs.documentfoundation.org).

Ein ähnliches Werkzeug ist ein Helpdesk oder Ticket-System, das weniger der Meldung von Softwareproblemen als der Unterstützung von Benutzern bei allen Arten von Problemen und Anfragen dient, beispielsweise zur Website des Projekts.

Der klassische Helpdesk ist eine Art Benutzer-Hotline: Der Benutzer meldet ein Problem, das in ein Ticket umgewandelt wird. Der Arbeitsablauf in einem Helpdesk-System dreht sich in der Regel um Prioritäten, Eskalationsstufen und Reaktionszeiten.

Nicht alle Open Source Communities bieten ein solches System an, aber viele kommerzielle Unternehmen haben eines. Für das LibreOffice-Projekt gibt es ein Ticket-System für die Infrastruktur, um Probleme mit Servern und Webdiensten zu melden.

Ein weiteres wichtiges Tool für die Zusammenarbeit ist ein Content Management System (CMS). Wie der Name schon sagt, hilft es bei der Verwaltung von Inhalten, vor allem bei Websites. Wenn Sie zum Inhalt oder zur Gestaltung der Website eines Projekts beitragen wollen, sollten Sie sich mit dem CMS vertraut machen.

CMS helfen, ähnlich wie Wikis, Inhalte nach Kategorien und Sprachen zu strukturieren. Sie bieten oft einen WYSIWYG-Editor (“what you see is what you get”) und betten alles in ein passendes Template ein: Titel, Überschriften, Seitenlayout und Menüeinträge werden automatisch erstellt, so dass Sie sich ganz auf den Inhalt konzentrieren können. Außerdem verschwinden bei einer Umgestaltung der Seite die Inhalte nicht, sondern werden an das neue Template angepasst.

Ein Document Management System (DMS) ist nicht zu verwechseln mit einem Content Management System: Während ein CMS dazu dient, Inhalte in einer definierten Vorlage darzustellen, etwa für die Präsentation einer Website, dient ein DMS der Verwaltung von Dokumenten wie Verträge, Rechnungen, Quittungen, E-Mails und allen anderen Arten von Korrespondenz.

Ein weiterer Unterschied besteht darin, dass ein CMS häufig für die öffentliche Präsentation verwendet wird, während ein DMS interne Dokumente verwaltet, die nicht für die Öffentlichkeit bestimmt sind.

Als Beiträger zu einem Open-Source-Projekt werden Sie wahrscheinlich seltener mit einem DMS in Berührung kommen, da es oft für bestimmte Rollen wie die Buchhaltung oder die Rechtsabteilung reserviert ist.

Allgemein bekannt ist in der Regel die Dokumentation für Benutzer, die erklärt, wie die Software zu verwenden ist. Wenn Sie eine Eigenschaft oder Funktion des Programms nicht kennen, ist die Dokumentation — die von einzelnen Hilfeseiten bis zum Buch reichen kann — die erste Anlaufstelle.

Die Dokumentationswebsite, auf der die Handhabung der Software erklärt wird, ist neben der Produktwebsite, die einen Überblick über die Software und ihre Community bietet, oft eine der meistbesuchten Websites eines Projekts.

Für den Einsatz in größeren Umgebungen, etwa in einem Unternehmen, enthält die Dokumentation für Administratoren alle relevanten Informationen, beispielsweise für die Verbindung mit Benutzerdatenbanken und Dateispeichern, die zentrale Konfigurationsverwaltung und die Handhabung von Updates.

Eine weitere Kategorie von Dokumentation richtet sich an Entwickler und Softwarearchitekten. Wenn Sie einen Beitrag zum Code eines Projekts leisten möchten, informiert Sie diese Dokumentation über die Softwarearchitektur, die Kodierungsstandards sowie Werkzeuge und Arbeitsabläufe, die bei der Arbeit an der Software zum Einsatz kommen.

Das LibreOffice-Projekt hat in seinem Wiki einen Leitfaden für Entwickler veröffentlicht, der Interessierten hilft, der Community beizutreten (https://wiki.documentfoundation.org/Documentation/DevGuide).