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:
- 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!)
- 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.
- 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.)
- 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.
