© scyther5 / 123RF.com

Softwareentwickler bedienen sich gern am riesigen Fundus quelloffener Bibliotheken und Werkzeuge. Komplett aus dem Blick geraten dabei allerdings häufig die Communities hinter diesen Komponenten.

Im Januar 2022 zerstörte der Entwickler Marak Squires absichtlich mehrere seiner Javascript-Bibliotheken [1]. Sie fanden sich zwar weiterhin im öffentlichen NPM-Repository, funktionierten aber schlichtweg nicht mehr. Das allein wäre noch kein großes Drama gewesen, hätte es sich nicht um millionenfach genutzte Komponenten gehandelt. Schlimmer noch, viele weitere Bibliotheken setzten auf Squires Arbeit auf. Allein die Testhilfe Faker banden laut NPM-Repository über 2500 Projekte ein (Abbildung 1). Auch sie waren zumindest teilweise nicht mehr zu gebrauchen.

Abbildung 1: Von der Bibliothek Faker selbst blieb in der aktuellen Version nur noch diese Meldung. Das angegebene Github-Repository existiert zudem nicht mehr.

Die Nutzer der Komponenten standen damit plötzlich vor einer großen Herausforderung. Im besten Fall konnten sie zur letzten noch funktionierenden Fassung der Bibliotheken zurückrollen, im schlimmsten Fall streikten Teile ihrer Webanwendung. Solche Situationen können im finanziellen Desaster enden, etwa wenn der Bestellprozess auf einer Website nicht mehr funktioniert. Das Beispiel zeigt eindrucksvoll, wie stark man sich beim Einsatz von freier Software von der jeweiligen Community abhängig macht.

John McBride, Maintainer der im Kubernetes-Umfeld verwendeten Bibliothek Cobra, spricht hier vom Lotteriefaktor (Lottery Factor [2]). Lässt ein Entwickler aufgrund eines großen Lottogewinns alles stehen und liegen, bekommen die Nutzer umgehend ein Problem. Der Grund für das Aufgeben eines Projekts muss allerdings nicht gleich ein Geldkoffer sein. Betreut nur eine einzelne Person ein Projekt, droht oft ganz simpel aus Zeitmangel dessen Einstellung. Dazu genügt bereits ein Wechsel der Arbeitsstelle oder die Geburt eines Kinds.

Klaas Freitag, CTO bei Owncloud, hält Ein-Personen-Projekte ebenfalls für gefährlich. Bevor Sie freie Software einsetzen, sollten Sie stets kurz überlegen, was bei einem Lottogewinn des Entwicklers passieren würde. Lebte das Projekt dann weiter, oder wäre es mit großer Wahrscheinlichkeit Geschichte? Für eine wichtige Komponente sollten Sie außerdem grundsätzlich eine Alternative im Hinterkopf behalten. Eine Bibliothek selbst weiter zu pflegen, lohnt sich wegen des Aufwands nur bei essenziellen Komponenten.

Gemeinsam stark?

Die effektive Sabotage gelang Squires nur, weil er die alleinige Gewalt über seine Repositories besaß. Niemand konnte sie kurzerhand übernehmen und wiederherstellen. Folglich steigt die Überlebenswahrscheinlichkeit eines Projekts, sobald ein Einzelkämpfer (Solo-Maintainer) weitere Personen in den engen Kreis der Entwickler holt. Diese übernehmen dann bei Bedarf die Leitungsfunktion oder greifen zumindest ein. Ein größeres Entwicklerteam verteilt zudem die Arbeit auf mehrere Schultern. Wegen dieser Vorteile empfiehlt es sich, Projekte von Entwicklerteams stets zu bevorzugen – könnte man zumindest meinen.

2015 verließen einige Teammitglieder das Node.js-Projekt. Sie zeigten sich mit der Entwicklung der Javascript-Laufzeitumgebung derart unzufrieden, dass sie ihre eigenen Ideen innerhalb des Forks Io.js umsetzten. Solche Abspaltungen kamen in der Vergangenheit erstaunlich häufig vor. Bei Debian führten Unstimmigkeiten über den Einsatz von Systemd zum Derivat Devuan. Nutzer stellen solche Umbrüche vor Herausforderungen, weil sich zum einen das Projekt selbst verändert und sie sich zum anderen für eines der beiden Systeme entscheiden müssen.

Als problematisch erweist sich daneben eine toxische Atmosphäre innerhalb der Community. Gibt es immer wieder Beleidigungen oder herrscht ein raues Diskussionsklima auf den Mailing-Listen, schreckt das nicht nur Außenstehende von einer Mitarbeit ab; es behindert die Weiterentwicklung des Projekts und strahlt mitunter auf davon abhängige Vorhaben aus. Fassen Sie eine Software ins Auge, sollten Sie daher unbedingt den Aufbau und die Prozesse des Teams prüfen. Was würde passieren, sollte ein Hauptentwickler einen Streit anfangen?

Achten Sie außerdem darauf, wie das Team Richtungsentscheidungen trifft. Bestimmt im Wesentlichen nur eine Person die neu zu implementierenden Funktionen, kann das über kurz oder lang zu mehr oder weniger weitreichendem Zwist führen. Bewährt haben sich hierarchische Führungsstrukturen wie im PHP-Projekt (Abbildung 2). Behalten Sie im Blick, wer zum engeren Kreis (Inner Circle) der Maintainer und Verantwortlichen gehört. Als vertrauenswürdig erweisen sich vermutlich Entwickler, die bereits viel Zeit in aufwendigen Code investiert haben. Sie haben in der Regel eher Bedenken, das Projekt zu kompromittieren.

Abbildung 2: Die PHP-Entwicklung steuert die PHP Group, die zum Redaktionsschluss aus zehn Personen bestand.

Organisationstalente

Anfang 2022 kündigte Nikita Popov an, sich aus der PHP-Entwicklung zurückzuziehen. Bis dahin gehörte er zu den Kernentwicklern der Sprache. Möglich machte seine Arbeit eine Stelle beim IDE-Entwickler Jetbrains. Dieses Unternehmen regte schließlich an, eine PHP-Stiftung zu gründen, die das Fortbestehen und den Erfolg der Sprache PHP sichern soll [3].

Solche Organisationen (Foundations) lenken die Entwicklung in strukturierte Bahnen, kümmern sich um die Finanzierung und sorgen für Zukunftssicherheit. Die Gründung einer Foundation brachte das Io.js-Team nur ein paar Monate später wieder zurück zum Node.js-Projekt [4].

Wie viele andere Organisationen gibt die Linux Foundation nur einen Rahmen vor und überlässt alle technischen Entscheidungen dem jeweiligen Projekt [5]. Zudem leisten die Foundations nur selten Support, die Nutzer eines Projekts müssen sich an die entsprechenden Entwickler halten. Außerdem finden sich gerade bei kleineren Foundations nicht immer genügend engagierte Freiwillige. Im schlimmsten Fall droht ein sogenannter Volunteer Burnout und damit das Ende der Organisation.

Eine Foundation im Hintergrund garantiert also noch lange kein funktionierendes und langlebiges Projekt. Die bekannten großen Organisationen wie die Linux Foundation oder die Apache Foundation haben jedoch in der Vergangenheit bewiesen, dass sie funktionieren und auf die von ihnen betreuten Softwareprojekte Verlass ist.

Unternehmungslustig

2007 begannen die Google-Entwickler Rob Pike, Robert Griesemer und Ken Thompson die Arbeit an einer neuen Programmiersprache. Sie sollte vor allem einige nervige Dinge beheben, über die das Trio bei seiner täglichen Arbeit stolperte. Das Ergebnis war die Programmiersprache Go, die deren Erfinder 2009 unter einer liberalen BSD-Lizenz veröffentlichten [6]. Dennoch bleibt das Team bei Google federführend.

Hinter der Filesharing-Plattform Owncloud steht die gleichnamige Firma. Dort implementiert das Team die Software gerade komplett neu – in Go [7]. Die Owncloud Infinite Scale (OCIS) genannte Plattform stellt das Unternehmen wie seinen Klassiker unter einer Open-Source-Lizenz bereit (Abbildung 3).

Abbildung 3: Go besitzt mittlerweile eine derart große und agile Community, dass sogar Owncloud seine neue Hochleistung-Filesharing-Plattform OCIS darauf aufbaut.

Wie in diesen Beispielen stecken recht häufig Unternehmen als treibende Kraft hinter einem Projekt. Wer sich auf solche Software stützt, profitiert zwar vom professionellen Ansatz, macht sich aber vom jeweiligen Unternehmen abhängig. Das kann gefährlich sein. So stellte etwa die OTRS AG die quelloffene Fassung ihres gleichnamigen Ticketsystems fast über Nacht ein. In ihrer Not halfen sich einige unabhängige OTRS-Dienstleister selbst, indem sie einen Fork (Abbildung 4) unter neuem Namen erstellten [8]. Durch entsprechende Neuerungen dürfte sich dessen Funktionsumfang jedoch zunehmend vom kommerziellen OTRS-Dienst entfernen.

Abbildung 4: Die OTTER Alliance entwickelt die Community-Edition des Ticketsystems OTRS unter dem Namen Znuny weiter.

Allerdings haben auch Unternehmen ein Interesse an einer starken Community. Owncloud profitiert beispielsweise von den vielen Entwicklern, die Erweiterungen beisteuerten. Der dadurch wachsende Funktionsumfang macht die komplette Plattform für zahlungskräftige Kunden attraktiver. Die Mehreinnahmen finanzieren dann wiederum die Weiterentwicklung von Owncloud.

Reizvoll

Squires ruinierte seine Javascript-Bibliotheken, weil zwar viele Konzerne Profit aus seiner Arbeit schlugen, er selbst aber leer ausging. Geringe Wertschätzung oder das Gefühl, ausgenutzt zu werden, sind ebenfalls häufige Gründe, eine Software einzustellen. Umgekehrt arbeiten Entwickler besonders engagiert an einer Software, sobald es dazu einen Anreiz gibt. Für Angestellte in einem Unternehmen liegt der meist im Gehalt. Motivieren können daneben immaterielle Anreize wie der Ausblick, in der Maintainer-Hierarchie aufzusteigen, verantwortungsvolle Posten zu übernehmen oder einfach Teil der Gemeinschaft zu sein.

Bei den von Ihnen verwendeten Komponenten sollte es für die Entwickler attraktiv sein, weiter an der Software zu arbeiten. Doch damit nicht genug: Als Nutzer einer Software sollten Sie die Anreize aktiv unterstützen. Erfüllen Sie beispielsweise den Entwicklern den Wunsch nach einer Spende. Sofern die Möglichkeit besteht, bieten Sie aktive Hilfe an, und bringen Sie sich in das Projekt ein. Auf diese Weise können Sie nicht nur Einfluss auf das Projekt nehmen, Sie erhöhen zudem seine Überlebenswahrscheinlichkeit.

Bei einer komplexen Software wie OCIS, die aus zahlreichen Komponenten besteht, fällt es allerdings schwer, sämtliche Projekte zu unterstützen (Abbildung 5). Die OCIS-Entwickler stehen darum nur mit einigen wenigen Entwicklern im direkten Austausch. Das OCIS-Team reicht jedoch grundsätzlich Bug-Reports und Patches per Pull Request ein. Abschließend engagiert es sich aktiv im Reva-Projekt, das bei OCIS das Speicher-Backend bildet. Auf diese Weise hilft Owncloud aktiv dabei, die von ihnen genutzten Komponenten zu verbessern und zu pflegen, was letztendlich wieder OCIS zugutekommt.

Abbildung 5: Wie hier bei OCIS hängen in der Praxis Komponenten von Komponenten ab. Dieses Diagramm entstand mit dem auf Go spezialisierten Tool Goda [9].

Selbstverständlich ist das nicht: Laut einer Umfrage des Branchenverbands Bitkom aus dem Jahr 2021 setzt zwar die Mehrheit der Unternehmen Open-Source-Software ein, aber nur etwas mehr als die Hälfte von ihnen beteiligt sich aktiv an der (Weiter-)Entwicklung [10]. Meist greifen die Firmen Projekten lediglich auf finanzieller Ebene unter die Arme, indem sie etwa eine Enterprise-Lizenz und Support kaufen.

Offen für alle

Ändert eine hyperaktive Community immer wieder den Funktionsumfang und die damit verbundenen Schnittstellen, entsteht bei den Nutzern ein hoher Wartungsaufwand. Die Auswirkungen erleben unter anderen PHP-Programmierer nach dem Erscheinen einer größeren PHP-Version. Dann gilt es, die neuen Syntaxelemente und vor allem die nicht abwärtskompatiblen Änderungen zu kontrollieren. In der Praxis tauchen chaotische oder unsinnige Schnittstellenänderungen jedoch glücklicherweise eher selten auf. Den Erfahrungen der OCIS-Entwickler zufolge sind bei den meisten Projekten die Änderungen durchaus sinnvoll. Die Mühen für entsprechende Anpassungen sollte man daher von vorneherein einkalkulieren.

Wie chaotisch eine Community vorgeht, hängt maßgeblich von ihren internen Strukturen und Regeln ab. Beim PHP-Projekt kann jeder einen neuen Änderungsvorschlag einreichen, das dazu notwendige Vorgehen ist penibel geregelt (Abbildung 6). Nachdem die Projektmitglieder das Vorhaben auf der Mailing-Liste diskutiert haben, stimmen sie darüber ab. Erst bei einem positiven Ergebnis geht es an die Umsetzung.

Abbildung 6: Beim PHP-Projekt durchlaufen Änderungsvorschläge (Request For Comment, RFC) ein präzise geregeltes Prozedere.

Wie bei PHP sollte ein Projekt möglichst alle potenziellen Helfer einbinden und sogar zum Mitarbeiten einladen. Liegen dafür die Hürden zu hoch, kann das Unterstützer abschrecken. Hilfreich ist außerdem eine klare Vision des Projekts: Fokussiert sich eine Bibliothek auf eine konkrete Aufgabe, oder kleben die Entwickler einfach immer weiter neue Funktionen an? Im ersten Fall lässt sich die Komponente deutlich einfacher und zukunftssicherer in eigene Software einbinden.

Abschreckend

Canonical entwickelt fleißig quelloffene Software. Wer bei einigen Projekten aktiv mitarbeiten möchte, muss zuvor allerdings einer speziellen Lizenzvereinbarung [11] zustimmen (Abbildung 7). Mit ihr gestattet man dem Unternehmen das Nutzen des Codes. Solche Lizenzbedingungen schrecken viele Entwickler ab. In der Folge schrumpft die Unterstützung von außen, wodurch Canonical die meiste Arbeit selbst stemmen muss. Für sein Contributor Agreement schlägt Canonical immer noch viel Kritik entgegen. Interessanterweise gilt das nicht für andere Unternehmen. So scheint es die Go-Community weniger zu stören, dass auch dort Google die Unterzeichnung eines Contributor License Agreement (CLA) verlangt (Abbildung 8).

Abbildung 7: Bei sehr vielen Projekten aus dem Hause Canonical müssen Entwickler vor der Zusammenarbeit ein Contributor Agreement unterzeichnen.

Abbildung 8: Wer bei Go mitarbeiten möchte, muss ebenfalls einem Contributor License Agreement (CLA) zustimmen.

Nicht nur der eingangs erwähnte Marak Squires, auch das Entwicklerteam der Datenbank MongoDB war zunehmend verärgert: Während viele Cloud-Anbieter die Software an ihre Kunden vermieteten, ging das MongoDB-Team leer aus. Das Projekt änderte daher kurzerhand die Lizenz auf die restriktivere Server Side Public License (SSPL). Diesem Modell folgten einige andere, darunter der Hersteller Elastic mit seiner quelloffenen Suchmaschine Elasticsearch. Solche durchaus abrupten Lizenzänderungen sorgen für verunsicherte User und sich abwendende Helfer. Im Fall von Elasticsearch starteten schließlich Amazon und Red Hat einen Fork unter dem Namen OpenSearch [12].

Solche Abspaltungen sind vor allem bei beliebten Softwarekomponenten wahrscheinlich. Nach Lizenzänderungen in kleinen Projekten steht man jedoch häufig ohne Alternative da. Darüber hinaus driften die Forks typischerweise auseinander, was zunehmend einen Wechsel erschwert. Auch deshalb ist es wichtig, die Diskussionen in der Community zu verfolgen und im Idealfall mit ihr in Kontakt zu bleiben.

Owncloud-CTO Freitag sieht nicht nur im Lizenzwechsel eine Gefahr für die Nutzer. Die fortlaufende Pflege einer Komponente könnte für ein Unternehmen ebenfalls irgendwann unattraktiv werden. Ein Paradebeispiel lieferte in der Vergangenheit Canonical: Dessen Desktop-Umgebung Unity samt Wayland-Konkurrent Mir fand keinen Anklang und fuhr Verluste ein (Abbildung 9). Canonical zog schließlich die Reißleine und gab die Software auf. Bislang fanden sich nur wenige Enthusiasten, die Unity weiterentwickeln – im Wesentlichen flossen lediglich Fehlerkorrekturen ein.

In solchen Fällen lässt sich die Software zumindest noch eine Weile weiter nutzen und ein Umstieg planen. Darüber hinaus sollten Sie darüber nachdenken, mit dem federführenden Unternehmen einen Support-Vertrag abzuschließen. Das schützt zumindest vor einer plötzlichen Einstellung eines Projekts wie beim Ticketsystem OTRS.

Abbildung 9: Nur noch eine kleine Community pflegt die Desktop-Umgebung Unity, ohne die Unterstützung von Canonical.

Eine Frage der Sicherheit

Mitte Dezember 2021 zeigten sich schlagartig Schweißperlen auf der Stirn zahlreicher Softwareentwickler: Im beliebten Logging-Framework Log4j klaffte eine schwerwiegende Sicherheitslücke, über die Angreifer das komplette System übernehmen konnten [13]. Das als Log4Shell bekannte Loch stopfte die zuständige Apache Foundation äußerst zügig. Als größere Foundation leistet sie sich sogar ein eigenes Apache Logging Security Team [14].

Hinter vielen Softwarekomponenten steht jedoch nur ein kleines Team, das sämtliche Arbeiten in seiner Freizeit erledigt. Hier passiert es häufiger, dass Fehler erst mit Verzögerung oder auch gar nicht behoben werden. Da verwundert es wenig, dass die OCIS-Entwickler die von ihnen genutzten Module vor allem nach der Qualität der Wartung auswählen. Wie die bisherigen Beispiele zeigen, kann die sich jedoch recht schnell ändern. Je weniger etabliert eine Komponente ist, desto mehr Vorsicht müssen Sie bei ihrem Einsatz walten lassen, rät Owncloud-CTO Freitag. Treten Sicherheitslücken auf, arbeitete das OCIS-Team zum Teil mit den Entwicklern der Komponenten zusammen, um die Schwachstellen so schnell wie möglich zu schließen.

Um herauszufinden, wie gut die Wartung funktioniert, lohnt sich unter anderem ein Blick auf den Bug Tracker des Projekts. Herrscht dort ein rauer Umgangston oder bleiben die eingestellten Probleme unangetastet, sollten Sie das Projekt lieber meiden. Eingereichten Code sollten die Entwickler zudem einem Review unterziehen und nicht einfach durchwinken. Fehler und Sicherheitslücken könnten sich sonst allzu leicht einschleichen, und Sie haben als Nutzer das Nachsehen.

Fahrpläne

Die Entwickler des Content-Management-Systems Joomla waren berühmt-berüchtigt dafür, ihre selbst gesteckten Zeitpläne zu kontinuierlich zu missachten. Darüber hinaus wechselte das Team das Versionsnummernschema wie andere ihre Socken. Auf die Version 1.7 zum Beispiel folgte direkt das Release 2.5. All das verwirrte Nutzer und Entwickler, die ihre Websites auf Joomla aufbauen wollten.

Mittlerweile implementiert das Joomla-Team nur noch wenige neue Funktionen, was gleichzeitig häufigere Releases ermöglicht. Anders geht WordPress vor, dessen Team zuverlässig zweimal im Jahr eine neue Version mit kleineren Neuerungen veröffentlicht. Owncloud nutzt als Versionsnummernschema Semantic Versioning, das sich bei immer mehr Projekten durchsetzt, unter anderem im Umfeld der Programmiersprache Go.

Vorhandene Roadmaps und realistische Milestones, die das Entwicklerteam stemmen kann, geben Nutzern Planungssicherheit und zeugen von einer funktionierenden Zusammenarbeit. Die OCIS-Entwickler stellen ihre Roadmaps sogar auf Konferenzen vor. Wer besonders langlebige und stabile Fassungen benötigt, sollte auf Komponenten mit Long Term Support achten. Apropos Stabilität: Den Erfahrungen des OCIS-Teams zufolge fällt mangelnde Stabilität bereits recht zuverlässig bei der Auswahl einer Komponente auf.

Handbücher

Eine allzu häufig unterschätzte Rolle spielt die Dokumentation. Insbesondere bei komplexeren Systemen erleichtern Tutorials den Einstieg, Referenzen helfen später beim Nachschlagen. Da die kontinuierliche Pflege der Dokumentation viel Aufwand verursacht, behandeln viele Projekte sie stiefmütterlich. Hinzu kommt, dass die meisten Teammitglieder Entwickler sind und darum andere Prioritäten setzen. Aus diesem Grund muss eine rudimentäre Dokumentation noch nicht auf ein wankendes Projekt hinweisen.

Bestes Beispiel dafür ist der Linux-Kernel, der immer wieder für seine mangelnde Dokumentation in der Kritik steht. Auch bei OCIS fällt die Dokumentation noch nicht so umfangreich aus wie bei Owncloud. Zum etablierten Owncloud haben zudem viele Freiwillige in Blogs und andernorts ergänzendes Informationsmaterial geschaffen.

Die Webseiten eines Projekts sollten alle internen Prozesse und Kommunikationsregeln offen dokumentieren. Bei PHP kümmert sich darum beispielsweise ein eigener Abschnitt in der offiziellen Dokumentation [15]. Die OCIS-Entwickler haben ihre Prozesse ebenfalls notiert (Abbildung 10). Nur so wissen angehende Helfer und Nutzer einer Komponente, an wen sie sich wenden können. Zudem sollte klar festgehalten sein, wer im Team welche Verantwortlichkeiten übernimmt und was passiert, sollte der Maintainer plötzlich sein Amt aufgeben.

Abbildung 10: Wie hier bei OCIS sollten angehende Helfer in der Dokumentation alle notwendigen Informationen finden.

Sprachrohr

Zu guter Letzt spielt die Kommunikation mit einem Projekt eine wichtige Rolle. Kein gutes Zeichen ist es beispielsweise, wenn sich die unbearbeiteten Meldungen im Bug Tracker stapeln und die Fragen im Forum unbeantwortet bleiben. Sie sollten immer nachvollziehen können, wie das Team untereinander und nach außen kommuniziert. Die OCIS-Entwickler bieten unter anderem einen Chat und ein Forum an, darüber hinaus gibt es ein umfangreiches Community-Programm [16].

Sich mit der Community zu beschäftigen und einen Blick auf die Mailing-Listen zu werfen, kostet immens viel Zeit. Ärgerlicherweise lässt sich diese Arbeit nicht automatisieren: Es gibt keine Stelle, die vertrauenswürdige Komponenten auflistet und empfiehlt. Immerhin existieren Tools, mit denen Sie die Abhängigkeiten einer Komponente verfolgen und inventarisieren können.

Go-Entwicklern liefert beispielsweise der Befehl »go mod graph« sämtliche Abhängigkeiten (Abbildung 11). Sie erfahren so zumindest, welche Komponenten Sie sich als Abhängigkeiten in die eigene Software holen. Minimieren Sie außerdem die Abhängigkeiten – nicht jede externe Bibliothek ist in der Praxis tatsächlich notwendig. Die OCIS-Entwickler gehen regelmäßig die Abhängigkeiten der Software durch und sortieren überflüssige Komponenten aus.

Abbildung 11: Das Go-Tool Deptree zeigt die Abhängigkeiten von »go mod graph« in einer Baumstruktur an (hier der Übersicht zuliebe auf drei Ebenen begrenzt).

Fazit

Komponenten von Einzelkämpfern droht stets die Einstellung, weshalb sie ein unkalkulierbares Risiko für das eigene Projekt darstellen können. Mehr Sicherheit bieten tendenziell Teams, die ein Unternehmen im Rücken wissen oder in einer Foundation organisiert sind. Bei der Softwareauswahl sollten Sie folglich immer einen Blick auf die dahinterstehenden Communities werfen.

Gute und verlässliche Projekte fördern die Mitarbeit von Freiwilligen, haben etablierte interne Strukturen, halten sich weitgehend an ihre Roadmap und weisen kurze Reaktionszeiten auf. Den größten Mehrwert erhalten Sie, indem Sie sich aktiv in die genutzten Projekte einbringen. Laut Klaas Freitag sollten Sie jedoch stets darauf gefasst sein, ein Modul beziehungsweise eine Komponente wieder entfernen zu müssen. (csi)