Einleitung:
Wer etwas bauen möchte, braucht dafür Ressourcen. In der Mainstream-IT ist die teuerste Ressource die Zeit von fähigen Entwicklern. Diese Zeit ist nicht beliebig beschaffbar, skaliert also nicht. Und sie kostet eine Menge Geld.
OpenSource und Community-Projekte haben meistens kein Geld, leben also von Zeitspenden der Entwickler. Die Motivationen hierfür sind unterschiedlich: Langeweile, interessante Themen, Interesse an einer neuen Technologie oder schlicht das Bedürfnis nach sozialem Engagement um etwas „zurückzugeben“.
Das Problem ist:
Dieses Engagement wird vermutlich nicht bezahlt und nur „ideell entlohnt“. Stecke ich also mehr Zeit und Antrieb in diese soziale Arbeit, als sie ich mir leisten kann, dann schade ich mir finanziell, körperlich etc … selbst (oder meiner Familie). Am Ende steht der typische Burn-Out, den vermutlich viele Ex-Mitglieder der Piratenpartei oder anderer gescheiterter Community-Projekte erleben mussten.
Neben der reinen Überlastung können auch alle möglichen zwischenmenschlichen Probleme auftreten. Visionen oder Sichtweisen können sich ändern, es kann zu Zerwürfnissen oder Streit kommen, der u.U. das ganze Projekt scheitern lässt (siehe „Hacklace“-Projekt des RaumZeitLabors Mannheim).
Meiner Meinung nach muss man hier schon zu Beginn klare Obergrenzen des Engagements aufstellen und immer auch einen Rückzug planen (von anderne und von sich selbst). Natürlich ist es schwer, sein „Baby“ irgendwann loszulassen, aber es gelingt dann am besten, wenn man es in sicheren Händen weiss: Also in Händen von verantwortungsvollen, vertrauenswürdigen, fähigen Menschen, die ebenso klare Grenzen ziehen und somit die Nachhaltigkeit des Projektes über „Freiwilligen-Generationen“ sicherstellen können.
Konkret:
Nehmen wir also an, das soziale Projekt lautet „Code for Germany„, eine deutsche Adaption des „CodeForAmerica„-Projekts, bei dem Freiwillige OpenSource-Software entwickeln um Probleme der Allgemeinheit zu lösen oder zu lindern.
Solche Probleme sind meistens keine „Eintagsfliegen“ sondern bedürfen einer dauerhaften Betreuung: Nehmen wir hier als Beispiel die Anwendung „Adopt a Hydrant„, bei der Bürger aufgefordert werden, eine Patenschaft für ihren Wasserhydranten zu übernehmen. Im Notfall soll so gewährleistet sein, dass auch ohne intensive und teure kommunale Überwachung die Funktionstüchtigkeit gewährleistet ist.
Das wird sie nur, wenn die Bürger und die Anwendung langfristig engagiert bleiben und funktionieren. Das ist eben keine typische Wegwerfanwendung, die nur einen Sommer lang laufen muss.
In der Euphorie des Anfangs und ggf. durch den Erfolg des ersten Releases steigt die Erwartungshaltung, steigt die Anzahl an Bugs und die Anzahl an Wünschen und Anpassungen. Das Projekt ist erfolgreich, bedarf aber unmittelbar weiteren helfenden Händen. Über die Zeit verlassen Entwickler das Projekt (oder müssen ihren Zeiteinsatz reduzieren), andere kommen hinzu und möchten mitarbeiten.
Das alles kann ich nur gewährleisten, wenn der Zustand einer Anwendung kontinuierlich getestet wird. Zumindest in einem groben Rahmen. Nur so kann ich Abhängigkeiten seitens Dritter verwalten oder es mir erlauben für einige Zeit meinen Code „liegen zu lassen“.
Interessenten können anhand der Tests den aktuellen Zustand und die Funktionen des Codes einsehen, erlernen und erweitern. Stimmt die Code-Coverage der Tests und laufen diese nach einer Änderung noch durch, so braucht der Teamlead weniger Zeit um eine Kontribution zu reviewen und zu mergen.
Die „alles oder nichts“-Kennen-Situation wird entschärft, die Abhängigkeit von einzelnen Personen und Technologien auch. Nur so kann ein Projekt, das nicht direkt durch die Vergütung der Mitarbeiter (=Sicherung des Lebensunterhalts der Beteiligten) deren Mitwirkung sichern kann, dauerhaft erfolgreich sein.
Die angesprochene „Adopt a Hydrant“-Anwendung hat fast keine Tests und hängt quasi an einem Entwickler (Freiwilligen). Ein Single-point-of-failure.
Bei einer anderen Anwendung, bei welcher einige Tests vorhanden sind, schaut es anders aus.
Das sind zwei einzelne Beispiele, die eine Verallgemeinerung natürlich noch nicht zulassen. Aber oben genannte Probleme im Umgang mit Freiwilligen-Tätigkeiten kann man in jedem Verein oder Partei etc. erleben, ob mit oder ohne IT-Bezug. Gemeinsam ist man am stärksten, wenn man zusammen arbeiten und seine Freiwilligen nicht verbrennt/verbrennen lässt.
Tests sind eine Absicherung des (zeitlichen) Investments für alle Entwickler und Nutzer.
Software ist ein Prozess, kein Produkt.