Leitfaden für Praktiker: Erste Schritte beim Auslaufen eines Open-Source-Projekts

Primäre Kennzahlen:

Falls Sie das noch nicht gelesen haben Insight Guide: Einführung – Was Sie bei der Interpretation von Metriken beachten solltenBitte halten Sie jetzt inne und lesen Sie diesen Leitfaden.

Viele Open-Source-Projekte, selbst weit verbreitete, werden aus verschiedenen Gründen aufgegeben (z. B. aufgrund veränderter Interessen, familiärer Situationen oder beruflicher Veränderungen). Die Aufgabe kann jedoch verantwortungsvoll erfolgen, indem das Projekt proaktiv eingestellt wird (Miller et al. 2025). Die Einstellung ist ein wichtiger Aspekt in Unternehmensumgebungen, da leicht der Überblick über Projekte verloren gehen kann, die von Mitarbeitern erstellt wurden, die das Projekt später verlassen haben, wenn sie aufgegeben werden. Sie möchten nicht, dass aufgegebene Open-Source-Projekte mit Sicherheitslücken in den Quellcode-Repositories Ihres Unternehmens verbleiben, wo jemand diesem Projekt nur aufgrund des Vertrauens in Ihr Unternehmen vertrauen könnte. Inaktive Projekte zu finden und verantwortungsvoll einzustellen, ist eine gute Geschäftsentscheidung und wird von vielen Open-Source-Teams/Open-Source-Programmbüros (OSPOs) regelmäßig praktiziert.

Es ist wichtig zu bedenken, dass nicht jedes Open-Source-Projekt für immer bestehen kann oder sollte: Technologien entwickeln sich weiter, Unternehmensprioritäten ändern sich und die Interessen der Menschen verändern sich. Ein Teil des Schönen an Open Source ist, dass wir offen arbeiten und gleichzeitig Innovationen entwickeln. Einige dieser innovativen Projekte werden den Test der Zeit bestehen, während andere verantwortungsvoll durch einen Sunset-Prozess veraltet sein sollten. Bei der Einstellung eines Open-Source-Projekts sollten die Bedürfnisse Ihrer Nutzer berücksichtigt und ihnen, wenn möglich, Zeit gegeben werden, auf eine Ersatztechnologie zu migrieren. Zumindest ist es wichtig, darauf hinzuweisen, dass das Projekt nicht mehr gewartet, aktualisiert oder mit Sicherheitspatches ausgestattet wird, damit die Nutzer wissen, dass sie das Projekt nicht mehr verwenden sollten.

Der wichtigste Schritt bei der Beendigung eines Projekts ist Transparenz in jedem Schritt. So können Sie Ihre Absichten offen darlegen und Vertrauen für zukünftige Open-Source-Arbeiten schaffen.

Schritt 1: Trends identifizieren

Es gibt verschiedene Kennzahlen, die Ihnen dabei helfen können, festzustellen, ob für ein Projekt Aktivitäten oder Nutzungen vorliegen, um Entscheidungen über die verantwortungsvolle Beendigung eines Projekts zu treffen. Betrachtet man Änderungsanträge (auch bekannt als Pull Requests / Merge Requests) und Neue Ausgaben kann ein guter Ausgangspunkt sein, um zu prüfen, ob es noch Leute gibt, die ein Projekt nutzen und dazu beitragen. Eine weitere gute Messgröße ist Technische Gabeln, die in der Regel ein Hinweis auf die Nutzung und den potenziellen Beitrag sind.

Änderungsanträge

Die Metrik „Änderungsanfragen“ hilft Ihnen zu erkennen, ob Personen zu Ihrem Projekt beitragen möchten, was wiederum auf Interesse hindeutet. Es ist hilfreich, sowohl geschlossene als auch offene Anfragen zu prüfen. Geschlossene Änderungsanfragen deuten darauf hin, dass ein Projekt möglicherweise noch bearbeitet wird, während offene Änderungsanfragen, die nicht bearbeitet werden, darauf hinweisen können, dass ein Projekt möglicherweise aufgegeben wurde. Wenn keine kürzlich zusammengeführten Änderungsanfragen vorliegen, ist es wahrscheinlich, dass auch keine Sicherheitsupdates veröffentlicht wurden.

Abgebrochenes Projekt – Änderungswünsche

Neue Ausgaben

Viele neue Probleme entstehen, wenn ein Benutzer einen Fehler findet, eine Frage hat oder eine neue Funktion wünscht. Daher können neue Probleme entstehen, weil andere Ihr Projekt nutzen oder sich anderweitig dafür interessieren. Wenn über einen bestimmten Zeitraum hinweg nur wenige oder gar keine Probleme auftreten, kann dies darauf hindeuten, dass das Projekt aufgegeben wurde.

Aufgegebenes Projekt – neue Probleme

Technische Gabeln

Dies sind die Forks, die Nutzer erstellen, wenn sie Ihr Projekt nutzen oder Beiträge dazu leisten möchten. Es kann jedoch hilfreich sein, über die Anzahl der Forks hinauszublicken und zu sehen, wer Ihr Projekt geforkt hat und ob dieser Fork weiterhin aktualisiert wird. Kürzlich aktualisierte Forks können auf die Nutzung hinweisen. Indem Sie Daten darüber sammeln, wer Ihr Projekt geforkt hat, können Sie möglicherweise auch einige dieser Nutzer kontaktieren und fragen, ob sie es noch nutzen, bevor Sie entscheiden, ob und wie Sie es beenden.

Schritt 2: Diagnose

Wenn Sie Teil einer Organisation sind, die ihre Repositories prüft, um scheinbar aufgegebene Projekte zu finden, sollten Sie zunächst mit den am Projekt beteiligten Personen sprechen, um besser zu verstehen, ob das Projekt wirklich aufgegeben wurde und wenn ja, warum. Dazu müssen Sie sich wahrscheinlich die aktuellsten Änderungsanträge ansehen, um herauszufinden, wer die letzten Änderungen am Projekt vorgenommen hat, damit Sie diese Personen kontaktieren können. In manchen Fällen muss ein Projekt möglicherweise nicht regelmäßig aktualisiert werden und scheint aufgegeben zu sein, obwohl es sich lediglich stabilisiert hat und möglicherweise noch weit verbreitet ist. Beispielsweise muss eine kleine Bibliothek, die eine komplexe mathematische Funktion ausführt, nach ihrer Erstellung möglicherweise nicht mehr aktualisiert werden, da sie keine zu aktualisierenden Abhängigkeiten aufweist. Wenn das Projekt hauptsächlich über Paketmanager verteilt wird, sollten auch die Nutzungsmetriken dieser Quellen berücksichtigt werden.

Wenn das Projekt tatsächlich aufgegeben wurde, kann es hilfreich sein, die Gründe dafür zu verstehen und zu prüfen, ob es noch von anderen genutzt wird, bevor Sie sich für die Einstellung entscheiden. Hier können die technischen Fork-Daten hilfreich sein, um zu sehen, ob andere Ihr Projekt geforkt haben und ihren Fork weiterhin aktualisieren, was auf die Nutzung Ihres Projekts hinweisen könnte. Kritikalitätswert, ein OpenSSF-Projekt, kann ebenfalls Aufschluss über die Nutzung geben, da es auch die Anzahl der Projekte berechnet, die von Ihrem Projekt abhängen. Es gibt eine Python-Skript aufgerufen, das den Kritikalitätswert und die GitHub-API-Fork-Daten verwendet, die zum Sammeln und Analysieren dieser Daten verwendet werden können.

Schritt 3: Sammeln Sie bei Bedarf zusätzliche Daten

CHAOSS verfügt über weitere Messgrößen zum Verständnis der Projektaktivität und -nutzung, die bei der Entscheidung, ob ein Projekt eingestellt werden soll, hilfreich sein können.

Zusätzliche Metriken:

Schritt 4: Nehmen Sie die Änderung vor

Nachdem Sie Ihre Diagnose abgeschlossen und sich für die Beendigung eines Projekts entschieden haben, können Sie verschiedene Maßnahmen ergreifen, um sicherzustellen, dass Sie das Projekt auf verantwortungsvolle Weise beenden.

Kommunikation

Die Kommunikation sollte mit allen bestehenden Mitwirkenden beginnen, um sicherzustellen, dass sie mit dieser Entscheidung einverstanden sind. In manchen Fällen gibt es Mitwirkende, die das Projekt fortsetzen möchten, anstatt es einzustellen.

Wenn Sie sich auf die Beendigung des Projekts geeinigt haben, muss dies allen bestehenden Benutzern, einschließlich anderer interner Teams, die das Projekt möglicherweise nutzen, mitgeteilt werden. Diese Kommunikation sollte transparent erfolgen und die Gründe für die Beendigung klar darlegen. Es gibt zahlreiche Stellen, an denen dies kommuniziert und dokumentiert werden sollte:

  • README: Geben Sie oben in der README-Datei deutlich an, dass das Projekt veraltet ist und nicht mehr aktualisiert wird. Schlagen Sie nach Möglichkeit alternative Projekte mit ähnlicher Funktionalität vor.
  • Kommunikationskanäle des Projekts: Dazu können Slack, Mailinglisten, Foren, soziale Medien und alle anderen Kanäle gehören, die für die Kommunikation innerhalb des Projekts verwendet werden.
  • Dokumentation: Auch die Projektdokumentation sollte aktualisiert werden. Dies kann Wikis, Websites und andere Projektdokumentationen umfassen.
  • Paketmanager/Vertriebskanäle: Da die meisten Projekte über Paketmanager (z. B. npm, PyPI, RubyGems) verteilt werden, sollten diese auch mit einer Veraltungswarnung aktualisiert werden, die klar darauf hinweist, dass das Projekt nicht mehr gewartet oder aktualisiert wird.
  • Zusätzliche Kanäle: Wenn es sich um ein Unternehmensprojekt handelt, sollten auch Marketing- und andere interne Teams benachrichtigt werden.
  • Benutzer: Auch bekannte Benutzer des Projekts sollten benachrichtigt werden.

Archiv

Das Projekt sollte offiziell archiviert werden, ähnlich wie die Archivierungsmethode von GitHub. Es kann auch sinnvoll sein, diese Projekte an einem separaten Ort aufzubewahren, um deutlich zu machen, dass sie das Ende ihrer Lebensdauer erreicht haben. VMware verfügt beispielsweise über eine separate Organisation namens „vmware-archive“, und Apache bietet eine ähnliche Organisation namens „Apache Attic“ an.

Wenn Sie zusätzlich Ihren Code hinzufügen, Heritage-Software Ein Archiv kann dazu beitragen, den Code langfristig zu erhalten. Dies gilt insbesondere, wenn Sie Ihre Quellcode-Repositories selbst hosten. Es kann aber auch dazu beitragen, dass archivierter Code potenzielle Plattformänderungen überdauert und in Zukunft leichter wiedergefunden werden kann.

Bedenken Sie, dass Projekte jederzeit wiederhergestellt werden können, wenn Sie Ihre Meinung später ändern. Wenn Sie diesen Umstand betonen, ist es oft einfacher, die Zustimmung der Beteiligten zum Sunset-Prozess zu gewinnen.

Sonderfall: Auslaufen aktiver Projekte

Leider müssen selbst aktive Projekte manchmal beendet werden, was deutlich schwieriger sein kann. Dies kann passieren, wenn ein Projekt vollständig von einem Unternehmen betreut wird und dieses aufgrund eines Strategiewechsels beschließt, ein weit verbreitetes Projekt nicht mehr mit Personal zu besetzen oder zu betreuen. In diesem Fall sollten vor der Archivierung des Projekts einige zusätzliche Überlegungen angestellt werden:

  • Öffentlichkeitsarbeit (PR): Das Archivieren eines aktiven Projekts kann eine heikle Angelegenheit sein und zu negativer Presse führen, sobald Sie mit Leuten über Ihren Wunsch sprechen, das Projekt einzustellen. Bevor Sie also mit jemandem außerhalb Ihres Unternehmens sprechen, sollten Sie Ihr PR-Team einbeziehen, damit es für alle Anfragen gerüstet ist.
  • Option zur Fortführung unter neuer Eigentümerschaft: Stellen Sie fest, ob es andere Mitwirkende oder andere Organisationen gibt, die bereit und in der Lage wären, die Neuentwicklung und/oder Wartung des Projekts zu übernehmen.
  • Ablaufplan: Es kann hilfreich sein, einen detaillierten Plan zu erstellen, der alle erforderlichen Schritte sowie einen Zeitrahmen für die Beendigung des Projekts umreißt.
  • Zeitliche Planung: Ein verantwortungsvoller Auslaufplan gibt den Benutzern Zeit, auf eine andere Lösung zu migrieren, bevor Sie die Bereitstellung von Sicherheitsupdates und -versionen einstellen. 6 Monate sind ein guter Ausgangspunkt.
  • Kunden, Benutzer und Kommunikation: Es ist eine sorgfältige Kommunikation erforderlich, um diese Entscheidung zusammen mit dem Zeitpunkt allen bestehenden Kunden und Benutzern mitzuteilen.

Vorsichtsmaßnahmen und Überlegungen

  • Es lohnt sich, sich etwas mehr Zeit zu nehmen, um mit den Mitwirkenden zu sprechen und sicherzustellen, dass die Entscheidung, ein Projekt einzustellen, die richtige ist, bevor Sie es tun.
  • Seien Sie so transparent wie möglich, was die Entscheidung zur Einstellung eines Projekts und die Gründe für diese Entscheidung angeht.
  • Das Auslaufen eines Projekts ist kein Anzeichen für ein Scheitern und sollte auch nicht als solches ausgelegt werden. Projekte haben Lebenszyklen; sie bestehen so lange, wie sie benötigt werden, und sollten dann verantwortungsvoll eingestellt werden, wenn sie nicht mehr benötigt werden.
  • Erwägen Sie die Bereitstellung von Übergangsdetails und, wenn möglich, von Tools, die Ihren vorhandenen Benutzern den Übergang zu einer alternativen Lösung erleichtern, sofern eine geeignete Lösung verfügbar ist.
  • Wie alle CHAOSS Practitioner-Leitfäden für den Einstieg sind diese Materialien dazu gedacht, Ihnen beim Auslaufen eines Projekts den Einstieg zu erleichtern. Es handelt sich jedoch nicht um einen umfassenden Leitfaden, der alles enthält, was Sie für jede Situation wissen müssen.

Zusätzliche Lektüre

Mitwirkende

Die folgenden Personen haben zu diesem Leitfaden beigetragen:

  • Morgenröte
  • Ria Schalnat
  • Damián Vicino
  • Matt Germonprez
  • Elisabeth Baron
  • Tara Tarakiyee

Referenzen

CHAOSS Practitioner Guides sind MIT-lizenzierte, lebendige Dokumente und wir freuen uns über Ihr Feedback und Ihren Input. Sie können Änderungen an diesem Dokument vorschlagen unter https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/sunset.md