Nachfolge Für Eigentümer Einer GitHub-Organisation
Ein Nachfolgeplan hält Code und Verwaltung am Laufen, wenn ein Gründer, leitender Maintainer oder technischer Leiter nicht mehr handeln kann. Er hilft nicht nur im Todesfall, sondern auch bei Krankheit, plötzlichem Austritt, Kontosperre oder einem normalen Führungswechsel.
Das größte Risiko ist die Konzentration. Ein alleiniger Eigentümer kann Mitglieder, Übertragungen, Einstellungen, Integrationen, Sicherheitsrichtlinien und Abrechnung kontrollieren. Andere Entwickler können eventuell weiter Code übertragen, haben aber nicht die nötigen Rechte, um einen Runner wiederherzustellen oder kritische Einstellungen zu ändern.
Mindestens zwei Eigentümer
GitHub warnt, dass Projekte unzugänglich werden können, wenn der einzige Eigentümer nicht erreichbar ist. Deshalb werden mindestens zwei Eigentümer empfohlen.
Wählen Sie aktive, vertrauenswürdige Personen mit dauerhafter Verbindung zum Projekt. Jede nutzt ein eigenes Konto, aktuelle Kontaktdaten, starke Authentifizierung und sichere Wiederherstellungsmethoden. Ein vergessenes Reservekonto ist keine echte Absicherung.
Zu viele Eigentümer erhöhen jedoch die Angriffsfläche. Da Eigentümer vollständige administrative Rechte haben, ist eine kleine verantwortliche Gruppe zusammen mit engeren operativen Rollen sinnvoller.
Alltag und Eigentum trennen
Die meisten Tätigkeiten brauchen keine Eigentümerrechte. GitHub kennt Repository-Rollen von Lesen und Triage über Schreiben und Warten bis Admin. Je nach Tarif lassen sich auch Abrechnung, Sicherheit, CI/CD und App-Verwaltung trennen.
Erstellen Sie eine Verantwortungsmatrix. Für Eigentum, Zahlungen, Sicherheitswarnungen, Repositories, Releases, Pakete, Actions, Runner, Apps, Webhooks, Support und Domains sollten jeweils mindestens zwei geeignete Personen benannt sein.
Externe Abhängigkeiten erfassen
GitHub-Rechte schützen keine Domain, kein DNS-Konto, keine Cloud, kein Paketregister und keine Firmenkarte. Dokumentieren Sie Dienst, Zweck, verantwortliche Person, Vertretung, Verlängerung und sicheren Ablageort der Wiederherstellungsanweisungen. Speichern Sie keine ungeschützten Secrets in dieser Übersicht.
Prüfen Sie besonders die Veröffentlichungskette. Repository-Zugriff bedeutet nicht automatisch Zugriff auf npm, PyPI, App-Stores oder Container-Registries. Erfassen Sie außerdem Actions-Secrets, eigene Runner, Cloud-Verbindungen, GitHub Apps und Webhooks.
Geplante Übergabe
GitHub nennt eine klare Reihenfolge: neuen Eigentümer hinzufügen, Zugriff auf Einstellungen bestätigen, Abrechnungsdaten aktualisieren und erst danach den ausscheidenden Eigentümer entfernen.
Der Nachfolger sollte früh genug beginnen, um Mitglieder, Richtlinien, Integrationen, Zahlungen und Sichtbarkeitsregeln zu prüfen. Eine beaufsichtigte Aufgabe zeigt, ob der Zugriff praktisch funktioniert. Wichtig sind auch die Entscheidungsregeln: Wer genehmigt Mitglieder, welche Projekte bleiben öffentlich und wann wird ein Sicherheitsvorfall eskaliert?
Notfall und Test
Ein Notfallplan nennt Eigentümer, Kontakte, kritische Dienste, Koordinator und Ablageort der Wiederherstellungsdetails. Bei einem Ausfall sollten keine übereilten Übertragungen, Löschungen oder Passwortweitergaben erfolgen. Prüfen Sie zuerst Zahlungen, Warnungen, Automatisierung und bevorstehende Releases.
Testen Sie den Plan zweimal im Jahr und nach Personal- oder Infrastrukturänderungen. Beide Eigentümer müssen die Einstellungen erreichen können. Prüfen Sie Zahlungen, Teams, Apps, Webhooks, Schlüssel und Paketveröffentlichung. Führen Sie praktisch einen Test-Release, eine Secret-Rotation außerhalb der Produktion oder eine Runner-Wiederherstellung durch.
Nachfolge bedeutet nicht, das Passwort eines Gründers zu erben. Sie verteilt rechtmäßige Befugnisse im Voraus. Zwei Eigentümer, begrenzte Rollen, dokumentierte Abhängigkeiten und Übungen schützen Code und Community ohne unnötige Vollmachten.
