PTF goes FOSS, Teil 2 – Wir haben einen Plan.

Wie wir im Januar angekündigt haben, wollen wir für die Arbeit im Prototype Fund endlich unserem eigenen Credo – “Open Source für alle” – folgen und dort, wo wir proprietäre Software nutzen, nach freien Alternativen suchen. Nun haben wir dafür einen ersten Plan entwickelt. Hurra!

Vom Großen ins Kleine

Um uns einen Überblick über unsere Tech-Praktiken zu verschaffen, haben wir ganz analog alle digitalen Werkzeuge, die wir nutzen, auf Klebezetteln gesammelt und sortiert. Erstaunlich viele davon waren bereits open source! Zu jeder verbleibenden proprietären Anwendung haben wir gesammelt, welche FOSS-Alternativen uns dazu einfallen. Als letzte Schritte in unserer Kartierungsübung haben wir versucht, mögliche Risiken bei einem Wechsel von einem Tool zum anderen abzuschätzen, und überlegt, welche Wechsel uns am drängendsten erscheinen. Mit dieser Übersicht fühlt sich die Aufgabe, unsere Werkzeuge und teilweise auch unsere Arbeitsprozesse umzustellen, nicht mehr ganz so groß an – jetzt hatten wir bewältigbare Bissen vor uns.

Die wichtigste Erkenntnis aus der Diskussion: Es kommt nicht notwendigerweise auf die Größe an. Es ist verlockend, mit den kleinen Werkzeugen anzufangen, für die es klare offene Alternativen gibt, und so möglichst schnell die ersten Aufgaben abzuarbeiten. Aber wie unser Projekt-Admin zu recht anmerkte: Auch die Administration dieser kleinen Tools ist Arbeit. Deshalb lohnt es sich nicht, mit den kleinen Fischen anzufangen, wenn die kein integraler Bestandteil unserer Arbeit sind. Stattdessen sind andere Faktoren wichtig: Beispielsweise Datenschutz, der von einigen Werkzeugen gut, von anderen eher schlecht gewährleistet wird, oder wie abhängig wir von einzelnen Lösungen bereits sind.

Im Gespräch miteinander ist uns auch klar geworden: Das ganze Team muss mit an Bord sein, damit der Wechsel gut läuft. Dabei mussten wir auch ein paar Kompromisse schließen und einigen Wahrheiten ins Auge blicken:

Pragmatisch bleiben und sich Zeit lassen

Unseren FOSS-Idealismus sollten wir mit einer Prise Pragmatismus würzen. Natürlich wollen wir so schnell wie möglich behaupten können, dass wir frei von proprietären Werkzeugen arbeiten. Zu viele Änderungen in den Arbeitsabläufen auf einmal können uns aber auch in der Projektarbeit lähmen. Das kann zu einer geballten Ladung an Nachfragen, Bugreports und Änderungswünschen führen, was wiederum in viel Arbeit für die Person resultiert, die die Technik administriert, das Team in der Nutzung neuer Anwendungen schult und Issues mit dem Team diskutiert. Denn der Umstellungsprozess ist nicht damit abgeschlossen, dass ein technisches System läuft, sondern er wird erst richtig spannend und manchmal auch herausfordernd, wenn Technik und Team zusammenwirken und ein soziotechnisches System daraus wird. Die Aufgabe, nach Lösungen für Fragen und Probleme zu suchen, liegt deshalb auch nicht nur bei den Admins, sondern ist Teamwork.

Deshalb darf es auch mal etwas länger dauern, und bis wir den nächsten Schritt gehen – nämlich wenn der vorherige Schritt für alle abgeschlossen ist und wir das Gefühl haben, alles läuft wieder wie gewohnt. Und wenn wir ein Werkzeug auf unserer Liste entdecken, für das wir partout keine gute Alternative finden, dann gehen wir damit offen um und sorgen statt eines halbgaren Wechsels lieber dafür, dass bessere Alternativen entstehen können.

Berührungsängste ernst nehmen

Der Wechsel von einem Werkzeug zum anderen wird Zeit kosten – dabei ist es ganz egal, ob das neue Tool freie oder offene Software oder keins von beidem ist. Wir alle haben jede Menge zu tun, deshalb sind Sorgen über den zusätzlichen Aufwand und Berührungsängste vor neuen Werkzeugen berechtigt. Abbauen können wir sie, indem wir Schritt für Schritt vorgehen und allen genug Zeit und Unterstützung geben, um mit ihren Aufgaben trotzdem gut zu Rande zu kommen. Einen Wechsel in einer Stressphase zu forcieren oder zu erwarten, dass alle in der Anfangsphase einfach so weiterarbeiten können wie zuvor, wäre kontraproduktiv. Indem wir Zeit dafür explizit einplanen, neue Werkzeuge auszuprobieren, Feedback- und Auswertungsschleifen zu drehen und eigene Workflows zu entwickeln, und um unsere Erfahrungen im Team (und hier im Blog) zu teilen, wird FOSS nicht mit Stress und Ärger gleichgesetzt, sondern ist eine Chance für alle, etwas neues zu lernen.

Richtig motiviert sein

Zuletzt bleibt die Erkenntnis: Nicht immer ist der Schritt zur Open-Source-Lösung der einzig sinnvolle Weg. Sensitive Daten auf einem eigenen Server mit einer nicht auditierten Anwendung sind nicht unbedingt die beste Idee. Open-Source-Anwendungen sind nicht automatisch sicherer. Deshalb geht es gerade im Spannungsfeld Datenschutz vs. Datensicherheit darum, die Vor- und Nachteile eines jeden Schritts abzuwägen. Manchmal ist ein bestehender Service vielleicht auch die bessere Lösung im Sinne der Betroffenen; Open Source zum Selbstzweck ist keine ausreichende Motivation.

Der Plan

Nach dieser Diskussion haben wir uns auf die nächsten beiden Schritte geeinigt: Zunächst wollen wir unseren Newsletter von Mailchimp auf ein eigenes System umziehen. Die Gründe: Mailchimp nutzen wir regelmäßig für die Kommunikation, gleichzeitig ist unser Verteiler eine der größten Datenbasen, die wir haben. Mailchimp ist zwar DSGVO-konform nutzbar, ist aber in erster Linie ein Marketing-Tool, zu dem wir Menschen nicht länger drängen wollen und das mit schlechtem UX-Design dazu beiträgt, dass Mailadressen nicht gelöscht werden, obwohl sie das sollten. Ersetzen wollen wir es durch phplist.
Im nächsten Schritt nehmen wir uns größeres vor und wollen eine Nextcloud zum Filesharing nutzen statt wie bisher ein Google Drive.

Wie ihr seht, bleibt es spannend! Wir bedanken uns auch bei allen, die uns auf Twitter Mut zugesprochen und Hilfe angeboten haben. Wir haben uns entschlossen, erst einmal die nächsten Schritte zu testen und nicht gleich ein Wiki o. ä. einzurichten, in dem wir unser Wissen teilen und Alternativen auflisten können. Denn um ehrlich zu sein, sehen wir schon genug Tool-Diskussionen am Horizont! ⚒️