Wo kommt eigentlich meine (freie) Software her? Und warum ist SYSTOPIA so “teuer”? (Teil 2)

Beim CiviCRM-Stammtisch am 30.11.2023 hatte ich die Gelegenheit, ein paar schwierige und in der deutschsprachigen CiviCRM-Community weniger gern besprochene Themen vorzustellen und zu diskutieren (vielen Dank an Nina und Ulrich für die Einladung!). Der Vortrag wurde interessiert, angeregt und teils auch nachdenklich aufgenommen. Daher führe ich meine Anliegen hier in einer kleinen Artikelreihe nochmal aus, in der Hoffnung, der Community ein paar Denkanstöße zu geben und die Diskussion anzuregen.

Bisher erschienen:
Teil 1: Neugierig sein lohnt sich, oder: Woher kommen eigentlich meine CiviCRM-Extensions?

Teil 2: Leserfragen

Als Reaktion auf Teil 1 hat Marc Michalsky eine Reihe praktischer Fragen aufgeworfen. Deren Beantwortung hilft vielleicht auch nochmal, bestimmte Zusammenhänge besser zu verstehen, bevor es dann im nächsten Teil mit der Frage „Freie Software - wer bezahlt, wer profitiert?“ weitergeht. Einige Aspekte kann man sicher auch etwas anders sehen - eure Nachfragen, Perspektiven und Diskussionsbeiträge sind natürlich willkommen.

Los geht’s mit Marcs Fragen und meinen Antworten…

Wie melde ich einen Bug in einer Extension?

Freie Software, also der Quellcode, wird in sogenannten „Repositories“ veröffentlicht und verwaltet. Die entsprechenden Plattformen, auf denen diese Repositories liegen, bieten in der Regel auch eine Funktion zum Melden von Fehlern oder neuen Anforderungen (in Form eines sogenannten „Issues“; im Deutschen ist der Begriff „Ticket“ gebräuchlich).

CiviCRM-Core und -Extensions sind in aller Regel entweder auf github.com oder lab.civicrm.org zu finden. Hier findet man z.B. den Quellcode der Extension CiviOffice: GitHub - systopia/de.systopia.civioffice: Use docx files as templates to create personalized documents in various CiviCRM workflows, und hier sind die offenen Tickets zu finden: Issues · systopia/de.systopia.civioffice · GitHub.

Wenn man glaubt, einen Fehler („Bug“) in einer Extension gefunden zu haben, kann man in etwa diese Schritte befolgen:

  1. Erstmal prüfen, ob man eine aktuelle Version verwendet, weil man nicht davon ausgehen kann, dass in einer älteren Version noch Fehler behoben werden. (Übrigens kann es sogar sein, dass die Extension gar nicht mehr weiter gepflegt wird - siehe unten!)
  2. Recherchieren: Wurde dieser oder ein ähnlicher Fehler schonmal gemeldet? Wenn ja, gibt es vielleicht auch schon eine Lösung. Jedenfalls sollte man darauf achten, einen Fehler nicht doppelt zu melden.
  3. Reproduzieren und Informationen sammeln: Kann ich den Fehler wiederholt beobachten? Nur unter bestimmten Bedingungen? Mit welchem Ablauf kann ich den Fehler wiederholt hervorrufen? Dieser Schritt ist sehr wichtig: Ein Fehler, der sich nicht reproduzieren und beobachten lässt, ist für die Entwickler*innen meist sehr schwer zu beheben! (Wenn mein technisches Know-how es zulässt, kann ich natürlich auch versuchen, die Ursache und Lösungsmöglichkeiten zu finden.)
  4. Wenn man bis hierhin gekommen ist, ist es endlich Zeit, das Ticket zu erstellen! Bei der Beschreibung möglichst gründlich und genau darstellen, wie sich der Fehler äußert, unter welchen Bedingungen er beobachtet wird, Anleitung zum Reproduzieren usw. All das kann hilfreich oder sogar notwendig für die Lösung des Problems sein.

Was passiert, wenn ich einen Bug in einer Extension melde?

Kommt drauf an.

Zunächst einmal wird wie gesagt nicht jedes Repository auch aktiv gewartet, siehe oben. Freie Software wird ohne Garantie zur allgemeinen Verfügung gestellt, und es ist den Entwickler*innen überlassen, ob, wie und wie lange sie den Code warten. Das Repository gibt häufig Auskunft darüber:

  • Wird der Wartungsstatus explizit benannt?
  • Ist im Repository Aktivität zu erkennen?
  • Sind Ansprechpartner*innen zu erkennen, mit denen ich Kontakt aufnehmen kann?

Bei CiviCRM-Extensions kann man ggf. auch auf die Nutzungszahlen im Extension-Verzeichnis schauen.

Wenn ein Repository „verwaist“ ist, wird die Fehlermeldung wahrscheinlich zu nichts führen. Es besteht aber theoretisch immer noch die Möglichkeit, dass andere Entwickler*innen die Entwicklung wieder aufnehmen (siehe dazu unten das Thema „Forks“). Das passiert aber nicht zufällig - wenn einem die Sache wichtig ist, sollte man also selbst aktiv werden.

Gehen wir nun davon aus, dass die Extension noch aktiv gewartet wird. Dann wird der Bug Report zwar früher oder später gelesen - jedoch hat man nicht automatisch Anspruch darauf, dass der Bug auch gefixt wird. Die Entwickler*innen können dies auf freiwilliger Basis tun, sind aber aufgrund der Lizenzbedingungen keineswegs dazu verpflichtet. Häufig werden sie gegen Bezahlung dazu bereit sein, zumal wenn sie die Software als professioneller Dienstleister entwickeln.

Bei SYSTOPIA unterscheiden wir folgendermaßen: Von den weit über 100 Repositories, die wir veröffentlicht haben, versuchen wir die wichtigsten Projekte verlässlich weiter zu betreuen. So führen wir über 60 unserer Extensions und Drupal-Module als „proaktiv gewartet“. Das bedeutet, dass wir schwere Fehler und Kompatibilitätsprobleme proaktiv beheben, um einen stabilen Betrieb bei den Anwender*innen zu ermöglichen. Weniger schwere Probleme werden meist nur nach Auftrag bearbeitet, ebenso Arbeiten an nicht proaktiv gewarteten Extensions.

Muss ich dafür bezahlen, dass der Bug gefixt wird?

Ja, sofern die Entwickler*innen dies nicht freiwillig von sich aus tun oder jemand anders es bezahlt. Wenn ich nicht bereit oder in der Lage bin, einen Bugfix zu finanzieren, kann ich nur freundlich darum bitten oder abwarten, bis andere sich um das Problem kümmern.

Man sollte sich aber vor Augen halten, dass man mit freier Software bereits sehr viel umsonst bekommt, und dass das Prinzip der freien Software nur funktionieren kann, wenn genügend Anwender auch etwas dazu beitragen.

Bei den Extensions von SYSTOPIA machen wir die Erfahrung, praktisch ausschließlich feste SYSTOPIA-Kunden Bugfixes und Weiterentwicklung finanzieren (oder wir selbst in Form von unbezahlter Arbeit). Gelegentlich gibt es meist kleinere Beiträge in Form von Code oder Dokumentation, die auch wertvoll sind, aber das Finanzierungsproblem nicht lösen. (Dies ist ein zentraler Grund, weshalb SYSTOPIA als „teuer“ gilt - es ist natürlich billiger, die Software nur zu verwenden, ohne etwas dazu beizutragen.)

Kann ich den Bug selber fixen?

Ja, aber nur mit relativ viel technischem Know-how. Für „normale“ Anwender*innen ist das keine realistische Perspektive. (Selber Coden ist erlernbar, aber der Weg ist weit.)

Eine von einer externen Entwicklerin vorgeschlagene Lösung muss dann von den Hauptentwickler*innen (auch: „Maintainer“) akzeptiert werden. Auch das kann aufwändig sein, insbesondere wenn man sicherstellen möchte, dass der eingereichte Code keine neuen Probleme verursacht, was immer möglich ist. Hier verfolgen Maintainer unterschiedliche Strategien - von „erstmal alles annehmen“ bis „möglichst sicher und stabil muss es sein“.

Muss ich dafür bezahlen, wenn mein Bugfix übernommen werden soll?

Eigentlich wünscht man sich ja Beiträge externer Entwickler*innen, insofern fiele es schwer, diese Frage mit „Ja“ zu beantworten. Der damit verbundene (unbezahlte) Aufwand führt bei SYSTOPIA leider manchmal dazu, dass es lange dauert, bis ein Bugfix angenommen wird. Andere gehen anders damit um und akzeptieren externe Beiträge teils unbesehen. Das geht sehr viel schneller, es leidet aber auch die Stabilität, weil man sich leicht neue Probleme einhandelt.

Generell wäre es natürlich schön, wenn man für diese Wartungsarbeiten eine Art Grundfinanzierung hätte. In der Realität müssen wir sie querfinanzieren oder unbezahlt leisten.

Kann ich eine fremde Extension selbst weiterentwickeln?

Ja, das ist bei Freier Software explizit erlaubt (evtl. sind Namensrechte zu berücksichtigen). Wenn ich meinen Code nicht bei dem Extension-Projekt einreiche, sondern es separat weiterführe, spricht man von einem „Fork“, weil die Entwicklung vom bisherigen Verlauf abzweigt.

Wann sollte meine Weiterentwicklung mit der Original-Extension zusammengeführt werden und wer kommt für den Arbeitsaufwand auf?

Wenn es tatsächlich eine gezielte Abspaltung gibt, ist eine Reintegration des Forks nicht vorgesehen und irgendwann auch gar nicht mehr realistisch möglich. So wurde z.B. LibreOffice als eigenständiges Projekt auf der Basis von OpenOffice gestartet. Freie Software ermöglicht es so z.B., brachliegende Projekte wieder aufzugreifen und fortzuführen.

Wenn das nicht gewollt ist, ist es hingegen sinnvoll und nachhaltig, wenn die Community auf die Dauer nur einen Entwicklungsstamm einer Software pflegt. Dann kann ein Fork immer noch genutzt werden, um trotz vorübergehenden Stillstands bei den Hauptentwickler*innen an einer Extension weiterarbeiten zu können. In diesem Szenario haben letztere das Projekt nicht aufgegeben, sondern können z.B. wegen Überlastung externe Weiterentwicklungen nicht so schnell integrieren, wie sie entstehen.

So hat z.B. Greenpeace die SYSTOPIA-Extension SQL-Tasks in einem Fork erheblich weiterentwickelt, was dann in Zusammenarbeit mit SYSTOPIA zur wieder konsolidierten Version 2.0 der Extension führte. Anders ist es z.B. bei der Theme-Extension „Shoreditch“, die nicht mehr weiterentwickelt und dann als „The Island“ geforkt wurde (soweit ich das mitbekommen habe).

Die Reintegration eines Forks kann u.U. sehr aufwändig sein. Bei SQL-Tasks wurden diese Arbeiten von SYSTOPIA und Greenpeace unbezahlt im Rahmen eines Sprints gemacht. Bei der Twingle-Extension suchen wir aktuell noch Mitstreiter*innen für die Integration der Weiterentwicklungen von Marc. Je mehr Interessierte sich beteiligen, desto eher klappt es, den Fork wieder in die Hauptversion zu integrieren. Einen Anspruch auf unbezahlte Arbeit der Entwickler*innen gibt es auch hier natürlich wiederum nicht.

Soweit fürs Erste zu Marcs Fragen - ich freue mich über weitere Reaktionen.

3 „Gefällt mir“

Hallo Martin, danke für die Beantwortung meiner Fragen! Ich kann mich Deinen Ausführungen hier wieder nur anschließen.

1 „Gefällt mir“

Hallo Martin, hallo Marc, vielen Dank für eure Beiträge und den erhellenden Blick hinter die Kulissen.

Ich würde jetzt gerne mal die Rolle des CiviCRM-Nutzers einnehmen. Es wundert mich nicht, dass das Funding von Arbeiten von Systopia nur bei ihren aktiven Kunden funktioniert. Diese haben oder hatte zumindest ein Projekt und können darüber Mittel zur Verfügung stellen.

Ich würde mal behaupten, dass alle anderen CiviCRM-Nutzer kein Budget für solche Aufgaben vorgesehen haben und dann natürlich auch kein Geld operativ einsetzen können. Wie viel denkt ihr denn, müsste das sein? Auf der anderen Seite müssten wir auch Zahlen haben, was dann z.B. die Erweiterung der Twingle-Extension kostet und zu welchem Preis man sich dort ein Ticket ziehen kann und wie viele Tickets verkauft werden müssen, dass es losgeht und wann es denn fertig ist.

Kommt mir so vor, dass wir einen besseren Marktplatz für Angebote und Nachfragen brauchen …

1 „Gefällt mir“

Lieber Ulrich,

ich antworte mal mit einem Rechenbeispiel, weil ich keine exakten Zahlen dafür parat habe. Von der Größenordnung her ist es aber realistisch bzw. eher konservativ gerechnet.

Wir warten aktuell ca. 65 Software-Pakete aktiv, in den allermeisten Fällen natürlich CiviCRM-Extensions. Nehmen wir mal 50 an, da wir auch teilweise mit anderen Entwickler*innen zusammen arbeiten, z.B. mit Marc oder CiviCoop. Oder auch nur 40, weil manche Tools noch nicht so in der Öffentlichkeit angekommen sind.

Nehmen wir jetzt nur mal diese beiden Themen:

  • Seit letztem Jahr widmen wir uns der leider notwendigen Aufgabe, all diese Extensions mit PHP 8 kompatibel zu machen.
  • Zudem gab es in CiviCRM-Core Änderungen, die Anpassungen an vielen Extensions notwendig gemacht haben.

Folgendes ist dann zu tun:

  • Recherchen
  • Lösungswege entwickeln
  • bei allen Extensions implementieren
  • testen
  • auftretende Probleme lösen
  • Releases und Dokumentation
  • Koordination und Management

Diesen Aufwand schätze ich mal vorsichtig auf 10 Stunden pro Extension, macht also rund 400 Stunden Aufwand für Kompatibilität der Extensions mit PHP 8+ und CiviCRM 5.60+. In Projektarbeit wären das für uns rund 50.000 Euro Umsatz gewesen. Den kleineren Teil davon (wieviel ist noch nicht ganz klar) sammeln wir direkt von unseren festen Kunden ein.

Wer sich daran beteiligten möchte, ist jederzeit herzlich willkommen. Wir sind dankbar für jeden Beitrag und stellen euch gern eine Rechnung. Eine weitergehende Verpflichtung mit uns müsst ihr selbstverständlich nicht eingehen.

(Das ist im Übrigen nur ein Teil des anfallenden Aufwands für die Wartung dieser Tools…)

P.S. Ulrich

Kommt mir so vor, dass wir einen besseren Marktplatz für Angebote und Nachfragen brauchen …

Das klingt erstmal sinnvoll - aber meine Befürchtung ist, dass kaum die Bereitschaft vorhanden ist, etwas beizutragen, wenn man es nicht unbedingt muss. Wenn das zutrifft, dann fehlt uns auch kein Marktplatz, sondern vielleicht erstmal etwas mehr Einsicht, wie eigentlich eine FOSS-Community nachhaltig funktionieren kann. (Ich lasse mich aber gern vom Gegenteil überzeugen.)

P.P.S. Community:
Ein paar Beispiele, worüber wir hier reden, damit es nicht so abstrakt bleibt:

Mir ist bekannt, dass ohne eure Extensions man praktisch kein Civi-Projekt in DACH machen kann.
Aber ehe ich hier weiter in eine Diskussion einsteige, würde ich gern mal den Rest der Community fragen:

  • Zuerst einmal Software für Engagierte, die ja extra für diesen Zweck Geld einsammelt. Wie wird das dort gesehen? Was ist passiert und was wird passieren?
  • Und dann natürlich insbesondere die langjährigen und größeren Organisationen: wie könnt ihr euch eure Beteiligung kurz- oder langfristig vorstellen?