Einrichten eines Open-Source-Programms

  • 8 Minuten

Hier werden die wichtigsten Überlegungen zum Einrichten eines Open-Source-Programms erörtert.

Was genau bedeutet „Open-Source-Programm“?

Ein Open-Source-Programm ist mehr als der öffentliche Zugriff auf eine Codebasis. Dabei geht es darum, ein aktives Projekt für andere Benutzer freizugeben, die sich dafür interessieren. Bei der ordnungsgemäßen Ausführung im Rahmen eines entsprechenden Projekts kann ein Open-Source-Programm dazu beitragen, deutliche Verbesserungen hinsichtlich der Qualität des Produkts herbeizuführen.

Einer der Hauptgründe für die Open-Source-Projekte von Unternehmen besteht darin, die Community zu beteiligen. Die Community kann bei beliebten Projekten, die kostenlos verfügbar sind, bedeutende Beiträge leisten.

Die Projekte werden nicht immer aus Uneigennützigkeit veröffentlicht. Personen und Organisationen nutzen Projekte, da sie darin einen Vorteil für sich selbst sehen. Wenn das Projekt die Anforderungen nicht erfüllt oder nicht den Erwartungen entspricht, können möglicherweise dennoch Fehler gemeldet oder Features hinzugefügt werden. Anstatt diese Verbesserungen in privaten Forks zurückzuhalten, sollen diese Änderungen wieder ins Quellrepository eingefügt werden, um Teil der Projektbasis zu werden. Dieser positive Kreislauf von Verbesserungen ist der Grund, warum viele Unternehmen Software mithilfe des Open-Source-Modells entwickeln.

Ziele des Open-Source-Modells

Zusammengefasst gibt es drei Dimensionen für das Mitwirken an Open-Source-Software:

  • Endverbraucher untersuchen oder verwenden die Repositorys von anderen Benutzern.
  • Mitwirkende sind aktiv an der Optimierung von Repositorys anderer Benutzer beteiligt.
  • Entwickler erstellen und verwalten eigene Repositorys, die von anderen genutzt werden können.

Bei der genaueren Ausarbeitung der Ziele für die einzelnen Dimensionen ist es eine bewährte Vorgehensweise, die aktuelle Situation der Organisation zu bewerten. Bei jeder Dimension gibt es fünf Prozessebenen.

Open-source process levels.

  • Bei der Ad-hoc-Ebene sind keine Prozesse vorhanden. Der Erfolg hängt von einzelnen Anstrengungen ab.
  • Bei der Ebene verwaltet sind teilweise dokumentierte Prozesse vorhanden. Der Erfolg hängt von der Disziplin ab.
  • Die Ebene definiert setzt voraus, dass es dokumentierte, standardisierte und integrierte Prozesse gibt. Der Erfolg hängt von der Automatisierung ab.
  • Bei der Ebene gemessen gibt es einen quantitativ geführten Prozess. Der Erfolg hängt von der Messung der Metriken für die Geschäftsziele ab.
  • Die Ebene optimiert setzt voraus, dass ein Prozess sowohl durch inkrementelle als auch innovative Änderungen kontinuierlich und zuverlässig verbessert wird. Der Erfolg hängt davon ab, ob das Risiko durch eine Änderung reduziert werden kann.

Führen Sie die Tests zur Bewertung von Open-Source-Software durch, um besser zu verstehen, auf welcher Ebene sich Ihre Organisation befindet.

Was sollte als Open-Source-Angebot bereitgestellt werden?

Viele Projekte eignen sich nicht für die Bereitstellung als Open-Source-Angebot. Ihre Kriterien können abhängig von den Unternehmenszielen und der Prozessebene variieren. Beachten Sie jedoch die folgenden empfohlenen Kriterien, bevor Sie ein Projekt als Open-Source-Angebot bereitstellen:

  • Enthält Ihr Projekt geistiges Eigentum, das Sie schützen möchten? Wenn dies der Fall ist, würde Ihr Projekt durch die Bereitstellung als Open-Source-Angebot seinen Wert verlieren. Veröffentlichen Sie solche Projekte nur dann als Open Source, wenn Sie das Gefühl haben, dass die Vorteile die Risiken überwiegen.

  • Kann das Projekt einen stabilen Status mit guter Codequalität vorweisen? Das Projekt muss nicht perfekt sein, aber potenzielle Mitwirkende verlieren möglicherweise das Interesse, wenn sich das Projekt gleich zu Beginn in keinem guten Zustand befindet.

  • Ist Ihr Projekt für Personen außerhalb Ihres Unternehmens nützlich? Andernfalls werden wahrscheinlich keine Beiträge geleistet.

  • Können Personen außerhalb Ihres Unternehmens Beiträge leisten? Diese Personen benötigen Zugriff auf alle Projektabhängigkeiten, Buildprozesse und anderen Komponenten, die zum Ausführen des Projekts benötigt werden. Wenn sie es nicht ausführen können, können sie auch keine Beiträge leisten.

  • Verfügt Ihr Team über die Bandbreite, um ein Open-Source-Programm zu unterstützen? Falls nicht, sollten Sie darauf warten, bis dies der Fall ist. Wenn Sie ein Projekt als Open-Source-Angebot bereitstellen und es anschließend nicht unterstützen, verlieren Sie möglicherweise die Gelegenheit, eine vertrauensvolle Community aufzubauen.

Diese Fragen sind nur einige der gängigsten Überlegungen. In Ihrer Organisation sind möglicherweise andere wirtschaftliche Aspekte oder Konformitätsfragen zu berücksichtigen.

Entwerfen eines Open Source-Programms

Das Ausführen eines Open Source-Programms ähnelt dem Ausführen eines Inner-Source-Programms, allerdings für eine öffentliche Zielgruppe. Daher gibt es einige weitere Überlegungen.

Festlegen der Erwartungen der Community

Dateien wie README.md und CONTRIBUTING.md sind noch wichtiger, da sie für Personen verfügbar gemacht werden, die nicht auf Ihren Organisationskontext zurückgreifen können. Sie müssen aus der Perspektive einer Person außerhalb des Unternehmens bewertet werden, um Übersichtlichkeit zu gewährleisten.

Außerdem sind Ihre Verhaltensregeln eine wichtige Richtlinie, die bereitgestellt werden sollte. In der Regel wird eine CODE_OF_CONDUCT.md-Datei zum Stammverzeichnis Ihres Repositorys hinzugefügt, die zum Erläutern des erwarteten Verhaltens der Community genutzt wird. Dieses Dokument sollte von mehreren Gruppen in Ihrer Organisation einschließlich der Rechtsabteilung geprüft werden. Glücklicherweise gibt es viele Standardverhaltensregeln, mit denen Sie beginnen können. Bei vielen Projekten werden diese Codes ohne Änderungen verwendet. Weitere Informationen finden Sie unter Ihr Verhaltenskodex.

Vorbereiten von Mitarbeitern auf die Verwaltung eines Repositorys

Mitarbeiter haben möglicherweise keine Erfahrung mit der Open-Source-Community. Als Vorbereitung wird empfohlen, dass das Unternehmen mehrere Richtlinien mit den wichtigsten Regeln bereitstellt, die noch vor dem Einstieg berücksichtigt werden sollten. Diese Richtlinien sollten in einem internen Repository oder Portal veröffentlicht werden, das nur für die Mitarbeiter des Unternehmens zugänglich ist und regelmäßig aktualisiert wird. Die folgenden Leitfäden sind einige der wichtigsten.

  • Ein Leitfaden zum Thema „Sollten wir dieses Projekt als Open-Source-Angebot bereitstellen?“ dient als Rahmen für die Entscheidung, ob ein infrage kommendes Projekt als Open-Source-Angebot bereitgestellt werden sollte oder nicht. Der Leitfaden kann als Flussdiagramm, Liste mit Fragen oder Liste mit Überlegungen strukturiert werden.

  • Eine Setupcheckliste enthält alle Arbeitselemente, die ein Team vor und nach dem Start eines Open-Source-Projekts benötigt. Diese Liste sollte beispielsweise die folgenden Punkte enthalten: Einholen der Genehmigung zur Bereitstellung des Projekts als Open-Source-Angebot, Code Reviews (um sicherzustellen, dass vertrauliche Daten vor der Freigabe des Projekts entfernt wurden), Markenkennzeichnungen oder eine Open-Source-Projektsuche (um sicherzustellen, dass kein Namenskonflikt besteht) usw.

  • Ebenfalls wichtig ist eine Kontaktliste mit Mitarbeitern mit Schlüsselfunktionen in Ihrer Organisation, die möglicherweise kontaktiert werden müssen, wenn direkter Support von den Maintainern erforderlich ist. Diese Liste sollte Mitarbeiter der verschiedenen Abteilungen für Softwaresicherheit, Standortsicherheit, Recht, Öffentlichkeitsarbeit usw. enthalten.

  • Stellen Sie einen Link zu einem Startrepository bereit, das als Startpunkt geklont werden kann. Es sollte Infodateien und Dateien in Bezug auf Lizenzen, Verhaltensregeln, Leitfäden für Mitwirkende und andere unterstützenden Dateien enthalten, die für jedes Open-Source-Projekt Ihres Unternehmens erforderlich sind. Darin werden alle Elemente gespeichert, die nicht versehentlich veröffentlicht werden sollten.

  • In Maintaineranleitungen werden die Zuständigkeiten eines Maintainers erläutert, um Fehler im Zusammenhang mit dem Repository zu vermeiden. Zu diesen Zuständigkeiten gehört es, die Dokumentation des Repositorys auf dem neuesten Stand zu halten, dafür zu sorgen, dass Probleme und Pull Requests rechtzeitig die Aufmerksamkeit der richtigen Personen erhalten usw.

  • Ein Leitfaden für die Kommunikation bietet Repositorymaintainern Informationen zu bestimmten Themen, da beispielsweise README.md, CONTRIBUTING.md oder CODE_OF_CONDUCT.md nicht in öffentlichen Dateien enthalten sein sollten. Diese Aspekte können vertrauliche geschäftliche Themen wie die Vorgabe sein, dass nicht über Mitbewerber diskutiert werden soll. Ein Beispiel für allgemeinere Themen ist das Erkennen der wichtigsten Mitwirkenden.

  • Eine interne FAQ-Seite bietet bestätigte Antworten auf häufige Fragen. Diese Liste ist besonders nützlich, wenn es rechtliche Feinheiten in Bezug auf die Themen zu klären gibt, die Ihr Unternehmen im Rahmen der Verwaltung eines Open-Source-Programms erläutert.

  • In einer Lizenzrichtlinie wird aufgeführt, welche Lizenzen von der Rechtsabteilung für Open-Source-Angebote genehmigt oder abgelehnt wurden.