Verwalten eines erfolgreichen Inner-Source-Programms

  • 8 Minuten

Hier soll erläutert werden, wie Sie ein Inner-Source-Programm entwerfen können, um die Vorteile des Open-Source-Ansatzes für die Softwareentwicklung in jeder beliebigen Organisation nutzen zu können.

Was ist Inner Source?

Jeder kann Open-Source-Software frei verwenden, ändern und teilen. Mit Open-Source-Software kann jeder Mensch ein Projekt für einen beliebigen Zweck anzeigen, ändern und verteilen. Dahinter steckt der Gedanke, dass die gemeinsame Nutzung von Code zu besserer, zuverlässigerer Software führt.

Inner Source ist ein Ansatz, Open-Source-Prinzipien auf Projekte anzuwenden, allerdings nur für eine begrenztes Zielgruppe. Ein Unternehmen könnte beispielsweise ein Inner-Source-Programm entwickeln, das der Struktur eines typischen Open-Source-Projekts ähnelt, mit der Ausnahme, dass nur Mitarbeiter des entsprechenden Unternehmens Zugriff darauf haben. Im Endeffekt handelt es sich dabei dann also um ein Open-Source-Programm hinter der Firewall Ihres Unternehmens.

Vorteile von Inner-Source

Inner-Source-Programme können im direkten Vergleich mit herkömmlichen geschlossenen Quellmodellen zahlreiche Vorteile bieten.

Zunächst fördern sie die Transparenz. Der Zugriff auf den Quellcode anderer Unternehmensprojekte kann Entwickler dabei unterstützen, produktiver zu sein, wenn sie an ihren eigenen Projekten arbeiten. Sie können dabei sehen, wie andere Teams Probleme lösen, die möglicherweise denen ähneln, mit denen sie gerade konfrontiert sind, und oftmals finden sie Code und weitere Ressourcen, die wiederverwendet werden können. Zugriff auf das gesamte Team betreffende Probleme, Pull Requests und Projektpläne führen insgesamt auch zu besseren Daten für Entwickler, um die aktuelle Geschwindigkeit und Richtung des Projekts nachvollziehen zu können.

Außerdem sorgen Inner-Source-Programme für einen reibungsloseren Ablauf. Angenommen, ein Verbraucherteam ist von einer Fehlerkorrektur oder einem neuen Feature für ein Projekt abhängig, das einem anderen Team gehört. In einem Inner-Source-Programm haben sie einen Kanal, über den sie die benötigten Änderungen vorschlagen können. Wenn diese Änderungen aus verschiedenen Gründen in einer Gesamtlösung nicht realisiert werden können, kann das erste Team immer noch das Projekt forken, um seine Anforderungen dennoch erfüllen zu können.

Schließlich standardisieren Inner-Source-Programme Vorgehensweisen. Eine häufige Herausforderung, der sich Organisationen bei der Entwicklung stellen müssen, ist die Tatsache, dass sich verschiedene Teams oft in ihrer Vorgehensweise unterscheiden. Das Erstellen eines Inner-Source-Programms ist eine ideale Möglichkeit, Standardkonventionen zu übernehmen, die in allen Entwicklungsteams befolgt werden können, selbst wenn sie nicht dieselbe Vorgehensweise wählen. Zwei Teams bevorzugen möglicherweise unterschiedliche Prozesse für die Annahme von Beiträgen. Wenn die Art der Kommunikation der verschiedenen Prozesse standardisiert wird, erleichtert dies beiden Teams, im jeweils anderen Team beizutragen.

Dies sind nur einige Beispiele für Vorteile, die durch Inner-Source-Programme entstehen können. Weitere Informationen erhalten Sie unter Eine Einführung zu Inner Source.

Einrichten eines Inner-Source-Programms auf GitHub

Festlegen von Sichtbarkeit und Berechtigungen für ein Repository

Sie können GitHub-Repositorys mit drei Sichtbarkeitsebenen konfigurieren. Für Benutzer, die die Anforderung an Sichtbarkeit nicht erfüllen, wird eine Seite mit der Benachrichtigung „Nicht gefunden“ angezeigt, wenn sie versuchen, auf das Repository zuzugreifen. Diese Ebenen sind die folgenden:

  • Öffentliche Repositorys sind für jeden sichtbar. Verwenden Sie diese Sichtbarkeitsebene nur für tatsächliche Open-Source-Projekte, auf die Personen sowohl innerhalb als auch außerhalb Ihrer Organisation Zugriff haben dürfen.
  • Interne Repositorys sind nur für Mitglieder der Organisation sichtbar, der diese Repositorys gehören. Verwenden Sie diese Sichtbarkeitsebene für Inner-Source-Projekte.
  • Private Repositorys sind nur für den Besitzer und Teams oder Einzelpersonen, die hinzugefügt werden, sichtbar. Wählen Sie diese Sichtbarkeit für Projekte, auf die nur bestimmte Benutzer und Gruppen zugreifen sollen.

Sobald Sie eine Sichtbarkeitsebene für ein Repository festgelegen, können Sie Berechtigungen auf Einzelperson- oder Teambasis konfigurieren. Es gibt fünf Berechtigungsebenen:

  • Die Leseberechtigungsebene wird für Personen empfohlen, die nichts zum Code beitragen und sich das Projekt nur ansehen oder darüber sprechen möchten.
  • Die Selektierungsebene wird für Mitwirkende empfohlen, die proaktiv Probleme und Pull Requests verwalten müssen, ohne dafür Schreibzugriff zu benötigen.
  • Die Schreibberechtigungsebene wird für Mitwirkende empfohlen, die aktiv Änderungen an das Repository pushen.
  • Die Verwaltungsberechtigungsebene wird für Projektmanager empfohlen, die das Repository verwalten müssen, ohne Zugriff auf vertrauliche oder destruktive Aktionen zu benötigen.
  • Die Administratorenberechtigungsebene wird für Personen empfohlen, die vollständigen Zugriff auf das Projekt benötigen, einschließlich vertraulicher und destruktiver Aktionen wie das Verwalten der Sicherheit oder das Löschen eines Repositorys.

Weitere Informationen erhalten Sie unter Berechtigungsebenen für Repositorys für eine Organisation.

Erstellen auffindbarer Repositorys

Mit zunehmender Größe eines Inner-Source-Programms wird die Anzahl der Repositorys sehr wahrscheinlich hochskaliert. Es ist zwar von Vorteil, dass alle Ressourcen für die Organisation verfügbar sind, es kann jedoch herausfordernd sein, effizient nach Inhalten zu suchen. Es gilt als Best Practice für Teams zu überlegen, was es anderen Personen erleichtern könnte, nach benötigten Repositorys zu suchen und mit ihnen zu arbeiten, um dieses Problem proaktiv zu beheben.

Hier finden Sie einige weitere Best Practices:

  • Verwenden Sie einen beschreibenden Name für das Repository, z. B. warehouse-api oder supply-chain-web.
  • Schließen Sie eine präzise Beschreibung ein. Ein oder zwei Sätze sollten ausreichend dafür sein, dass mögliche Benutzer herausfinden können, ob ein jeweiliges Projekt für ihre Anforderungen geeignet ist.
  • Lizenzieren Sie Ihr Repository, damit Kunden wissen, wie sie die Software verwenden, ändern und verteilen dürfen.
  • Fügen Sie im Repository eine README.md-Datei hinzu. Diese Datei wird von GitHub als Zielseite für Personen verwendet, die das Repository aufrufen.

Hinzufügen einer README-Datei (Infodatei)

Eine README-Datei informiert über die Erwartungen an Ihr Projekt und hilft Ihnen beim Verwalten der Beiträge. README-Dateien bieten folgende Möglichkeiten:

  • Formulieren Sie den Zweck und die Vision des Projekts, damit mögliche Benutzer herausfinden können, ob es ihren Anforderungen entspricht.
  • Bieten Sie visuelle Hilfsmittel wie Screenshots oder Codebeispiele, um das Projekt in Aktion zu zeigen.
  • Sie können zu Überprüfungszwecken Links zu einer Produktions- oder Demoversion der App enthalten.
  • Legen Sie Erwartungen für Voraussetzungen und Bereitstellungsprozeduren fest.
  • Sie können Verweise auf die Projekte enthalten, zu denen Abhängigkeiten bestehen. Diese Verweise sind eine gute Möglichkeit, die Arbeit anderer Menschen zu bewerben.
  • Verwenden Sie Markdown, um die Inhalte ordnungsgemäß zu formatieren, sodass die Leser*innen die gewünschten Informationen finden.

Wenn Sie Ihre README-Datei in die verborgenen Verzeichnisse .github oder docs oder in das Stammverzeichnis einfügen, erkennt GitHub die Datei und stellt sie automatisch für Repositorybesucher bereit. Enthält ein Repository mehrere README-Dateien, wird die angezeigte Datei aus Speicherorten in der folgenden Reihenfolge ausgewählt: das .github-Verzeichnis, dann das Stammverzeichnis des Repositorys und schließlich das docs-Verzeichnis.

Hier finden Sie geeignete Beispiele für Infodateien.

Sobald das Projekt veröffentlicht wird, verwenden Sie E-Mail- und andere Netzwerkkanäle, um die Veröffentlichung zu kommunizieren. Wenn eine geeignetes Publikum angesprochen werden kann, kann dies die Teilnahme an einem Projekt erheblich steigern.

Verwalten von Projekten auf GitHub

Wenn Projekte an Fahrt gewinnen, kann der Input durch Benutzer und von Beiträgen erheblichen einen hohen Verwaltungsaufwand verursachen. Je nach Projekt kann es sich möglicherweise als sehr arbeitsintensiv herausstellen, einfach nur die Erwartungen der einzelnen Projektteilnehmer zu verwalten.

GitHub sucht nach einer CONTRIBUTING.md-Datei im Stammverzeichnis (oder /docs oder /.github) eines Repositorys, um dieses Problem proaktiv anzugehen. Verwenden Sie diese Datei, um die Richtlinien für Beiträge zum Projekt zu erläutern. Die genauen Details können variieren, aber es ist ratsam, potenzielle Mitwirkende darüber zu informieren, welchen Konventionen das Projekt folgt. Beispielsweise, wo das Team nach Pull-Anforderungen sucht, welche Details für Fehlerberichte angefordert werden usw.

Wenn eine CONTRIBUTING.md-Datei vorhanden ist, wird auf GitHub ein Link dazu angezeigt, wenn Benutzer Issues oder Pull Requests erstellen, damit diese darauf klicken.

Link mit einem Leitfaden für Beiträge.

Sehen Sie sich hier geeignete CONTRIBUTING.md-Beispiele an.

Darüber hinaus sollten Sie dem Repository eine CODEOWNERS-Datei hinzufügen, um Einzelpersonen oder Teams zu definieren, die für die Überprüfung von Codeänderungen verantwortlich sind.

Erstellen von Issue- und Pull Request-Vorlagen

Auf GitHub werden grundlegende Vorlagen für die Erstellung neuer Issues und Pull Requests unterstützt. Verwenden Sie diese Vorlagen, um zu Beginn einen Beschreibungstext für ein neu erstelltes Ticket oder eine Pull-Anforderung bereitzustellen.

Wenn Ihr Projekt beispielsweise über eine .github/ISSUE_TEMPLATE.md-Datei verfügt, wird dieser Inhalt jedes Mal angezeigt, wenn ein Benutzer damit beginnt, ein Issue zu erstellen. Diese Personen oder Teams müssen nicht ständig in einer CONTRIBUTING.md-Datei auf die erforderlichen Details verweisen, sondern können das Issue einfach mithilfe des Vorlagentexts ausfüllen – wie ein Formular.

Erstellen eines neuen Issues mithilfe einer Vorlage.

Dasselbe gilt für Pull Requests, wenn der Pfad nicht .github/PULL_REQUEST_TEMPLATE.md lautet.

Sehen Sie sich hier einige geeignete Vorlagen für Issues und Pull Requests auf GitHub an.

Definieren von Workflows

Bei Projekten, bei denen externe Beiträge erwünscht sind, sollten Sie angeben, welchem Workflow das Projekt folgt. Der Workflow sollte Details dazu enthalten, wo und wie Verzweigungen für Fehler und Features verwendet werden sollen. Es sollte auch enthalten sein, wie Pull-Anforderungen geöffnet werden sollen, und alle anderen Details, die Personen außerhalb des Repositoryteams wissen sollten, bevor sie Code pushen. Wenn Sie selbst keinen speziellen Workflow geplant haben, empfiehlt sich der GitHub-Workflow.

Sie sollten eine Strategie für die Verwaltung von Releases und Bereitstellungen kommunizieren. Diese Teile des Workflows wirken sich auf alltägliches Verzweigen und Zusammenführen aus. Es ist also wichtig, diese Teile an Mitwirkende zu kommunizieren. Weitere Informationen hierzu finden Sie unter Übernehmen einer Git-Verzweigungsstrategie.

Messen des Programmerfolgs

Teams, die mit einem Inner-Source-Ansatz arbeiten, sollten sich Metriken überlegen, über deren Nachverfolgung sie den Erfolg eines jeweiligen Programms messen können. Herkömmliche Metriken wie „Time-to-Market“ oder „Anzahl gemeldeter Fehler“ eignen sich hier zwar auch, sie zeigen aber nicht zwangsweise die Vorteile auf, die über den Inner-Source-Ansatz erzielt werden können.

Ziehen Sie stattdessen in Erwägung, Metriken hinzuzufügen, die aufzeigen, wie eine externe Mitwirkung am Projekt die Projektqualität steigern konnte. Erhält das Repository Pull Requests von externen Quellen, über die Fehler behoben und Features hinzugefügt werden können? Nehmen Personen aktiv an Diskussionen zum Projekt und dem weiteren Vorgehen teil? Inspiriert das Programm eine ausgeweitete Verwendung des Inner-Source-Ansatzes, über die sich auch in anderen Teilen der Organisation Vorteile erzielen lassen?

Kurz gesagt, ist es schwierig, hier geeignete Metriken zu erstellen, insbesondere wenn es darum geht, Nutzen und Einfluss der Beiträge von Einzelpersonen und des Teams zu messen. Werden die Metriken falsch angewendet, schaden Sie der Unternehmenskultur und vorhandenen Prozessen und können die allgemeine Stimmung gegenüber der Organisation und der Führungsebene negativ beeinflussen. Wenn Sie sich Gedanken über das Messen des Erfolgs der Übernahme eines Inner-Source-Ansatzes machen, sollten Sie folgende Anleitungen zu Metriken bedenken:

  • Messen Sie den Prozess, nicht die Ergebnisse
    • Für Code Reviews benötige Zeit
    • Umfang von Pull Requests
    • Laufende Arbeit
    • Zeit bis zur Verfügbarkeit
  • Messen Sie Zielwerte, keine absoluten Werte
  • Messen Sie Teams, keine Einzelpersonen
    • Anzahl einzelner Mitwirkender am Projekt
    • Anzahl der Projekte, für die Code wiederverwendet werden kann
    • Anzahl teamübergreifender gegenseitiger Erwähnungen (@mentions)

Wenn Sie an Erfolgsgeschichten anderer Organisationen interessiert sind, finden Sie in den Inner-Source-Fallstudien weitere Informationen.