Was ist “Inner Source”-Entwicklung und sollten Sie sie verwenden?

0
211
LuckyStep/Shutterstock.com

Inner Source, oft stilisiert als InnerSource, bezieht sich auf die Einführung von Open-Source-Prozessen und Entwicklungsmethoden innerhalb einer Organisation. Während “Open Source” impliziert die Erstellung öffentlich verfügbarer Tools. Inner Source bedeutet, dass Sie an internen Projekten mit offen abgeleiteten Ansätzen arbeiten.

Open-Source-Workflows ermöglichen eine einfache Zusammenarbeit und schnelle Iteration. Durch öffentlich zugängliche Issues und Merge-Anfragen auf Plattformen wie GitHub kann jeder zu einem Projekt beitragen. Fehler werden schnell, sicher und transparent in einer Umgebung entdeckt und gepatcht, die regelmäßige Diskussionen zwischen Betreuern und Benutzern fördert.

Dieses Modell steht im krassen Gegensatz zur Entwicklung von Software in großen Unternehmen. In diesen Umgebungen werden Tools ad-hoc von einzelnen Teams entwickelt. Die Menschen arbeiten in Silos, tragen zu ihren individuellen Bereichen bei, ohne sich der überlappenden Arbeit bewusst zu sein, die woanders stattfindet.

Introducing Inner Source

Die Inner-Source-Bewegung wendet die Erkenntnisse aus der Open-Source-Entwicklung auf die internen Projekte einer Organisation an. Es plädiert dafür, den gesamten Code für alle sichtbar zu machen und eine offenere Kultur zu schaffen, in der Teams bestehende Projekte finden können, die auch für ihre Arbeit nützlich sein könnten, und dann ihre eigenen Verbesserungen beisteuern.

In vielen Organisationen werden neue Quell-Repositorys auf die Personen beschränkt sein, die an ihnen arbeiten müssen. Die Übernahme eines inneren Quellmodells bedeutet, dass standardmäßig alles sichtbar ist. Dies ermutigt die Teammitglieder, den gesamten Codekorpus der Organisation zu erkunden und Beiträge zu Diskussionen zu leisten, auch wenn das Projekt nicht ausschließlich in ihren Themenbereich fällt.

Werbung

Bei der inneren Quelle geht es auch nicht nur um Code. Es kann erweitert werden, um umfassendere Assets und Dokumentationen aufzunehmen, die für das Geschäft, seinen Betrieb und seine Software relevant sind. Das Ziel besteht darin, Einzelpersonen zu befähigen, Aufgaben selbst auszuwählen und ihre Erfahrung dort einzubringen, wo sie der Meinung sind, dass dies der Organisation zugute kommt, selbst wenn sie in einem bestimmten Schwerpunktbereich eingestellt werden.

Innere Source-Vorteile

Befürworter der “inneren Quelle” Architekturen stellen mehrere bedeutende Vorteile des Ansatzes fest, darunter weniger Verschwendung, beschleunigte Startzeiten, weniger Spannungen zwischen Teams und verbesserte Codequalität. Diese kombinieren, um die Produktivität und die Arbeitsplatzkultur des Unternehmens zu verbessern.

  • Reduzierter Abfall, verbesserte Wiederverwendung– Große Unternehmen können am Ende ähnlichen Code über mehrere Projekte hinweg duplizieren, die verschiedenen Teams gehören. Wenn Teams nicht miteinander sprechen, könnte die Tatsache, dass Sie jetzt drei ähnliche Caching-Bibliotheken haben, unbemerkt bleiben. Die interne Veröffentlichung des gesamten Codes macht andere auf das Vorhandensein üblicher Tools aufmerksam und fördert dann die gemeinsame Iteration auf einer einzigen Codebasis. Das Rad wird nicht mehr neu erfunden, hält alle bei der Arbeit und beschleunigt den Startzeitrahmen.
  • Verbesserte Codequalität– Offen geschriebener Code ist anfälliger, sodass Fehler wahrscheinlich früher im Entwicklungsprozess auftreten. Wenn eine gemeinsame Bibliothek von einem neuen Team übernommen wird, können Probleme auftauchen, die zuvor unbemerkt waren. Die Implementierung von Fixes kommt allen Projekten zugute, die die Bibliothek verwenden.
  • Weniger Spannungen zwischen den Teams– Während der Übergang zu einem offenen Modell zunächst unbequem erscheinen mag, soll die Entwicklung der inneren Quelle Barrieren abbauen und die Zusammenarbeit verbessern. Eine geschlossene Entwicklung kann zu unangenehmen Situationen führen, wenn Sie feststellen, dass ein benachbartes Team eine bessere Version einer Bibliothek erstellt hat, die Sie verwendet haben. In einem offenen Modell wird dies durch gemeinsame Iterationen auf einer gemeinsamen Codebasis gelöst, die die für die gesamte Gruppe benötigten Funktionen enthält.

Innere Quelle verflacht die Organisationsstruktur und gibt allen Entwicklern die gleiche Sicht auf laufenden Arbeiten. Annahme von Beiträgen von außerhalb des Teams, das “besitzt” ein Projekt bietet Zugang zu frischen Augen und einem erweiterten Lösungspool.

Implementierung eines Inner Source Workflows

Im einfachsten Fall wird innere Quelle implementiert, indem Sie zu Ihrer Versionskontrollplattform gehen und die Sichtbarkeit von Projekten von privat auf intern ändern. In der Praxis benötigen Sie einen durchdachteren Plan, wenn Sie das innere Quellmodell erfolgreich in eine vorhandene Teamumgebung einführen möchten.

Bei jedem Übergang gibt es zwei grundlegende Aspekte: Kommunikation und Werkzeuge. Ersteres bezieht sich auf die Aufklärung von Teammitgliedern darüber, was passiert und wie sie zu geöffneten Projekten beitragen können. “Setzen und Vergessen” Zugriffsebenen werden ineffektiv sein, da die Leute ihre neuen Fähigkeiten nicht kennen und nicht wissen, wann sie verwendet werden können.

Der zweite Aspekt, Tools, beinhaltet die Auswahl geeigneter Software-Dienstprogramme, um den offenen Workflow zu verwalten. Ein funktionierendes Softwareteam wird wahrscheinlich bereits eine Form der Versionskontrolle wie GitOps verwenden, um seinen Code zu verwalten. Die genauen Nutzungsmuster können jedoch innerhalb der Organisation erheblich variieren.

Werbung

Inner Source fordert ein einheitliches Entwicklungsmodell, das über alle Projekte hinweg konsistent funktioniert. Dies bedeutet, dass Sie die Fähigkeiten von Git und Ihrer Hosting-Plattform wie GitHub oder GitLab optimal nutzen.

Mitwirkende sollten in der Lage sein, Änderungen in einem Pull-Request einzureichen, den die Betreuer dann überprüfen und zusammenführen. Pull-Requests sollten durch eine bestandene Testsuite ergänzt werden, die in einer CI-Pipeline läuft. Dies gibt dem Wartungsteam die Gewissheit, dass die Änderung wirksam ist, und stellt sicher, dass der gesamte Code denselben Standards entspricht. Die Selbstverifizierung der Codebasis durch automatisierte Tests und Prüfungen trägt dazu bei, Reibungsverluste aus der Erfahrung zu vermeiden.

Sie sollten auch berücksichtigen, wie unterstützende Assets wie Dokumentationen und Problemlisten gespeichert und verfügbar gemacht werden. Erstellen Sie ein offenes Team-Wiki für API-Dokumente und Architekturreferenzen; Stellen Sie sicher, dass alle Fehler und Funktionsanfragen an einem zentralen Ort verfolgt werden. Auf diese Weise können Personen aus dem gesamten Unternehmen die Informationen finden, die sie benötigen. Es befähigt auch Einzelpersonen, in ruhigeren Zeiten beliebige Projekte zu verbessern – Jeder kann Fehlerberichte finden und damit beginnen, sie zu beheben, was zu Verbesserungen in allen nachgelagerten Repositorys führt.

Zu berücksichtigende Nachteile

Innere Quelle ist bereits Realität bei vielen Organisationen. Die potenziellen Vorteile sind in Situationen verlockend, in denen eine höhere Effizienz und ein höherer Durchsatz erwünscht sind. Wie bei jedem Arbeitsansatz ist er jedoch nicht unbedingt für jede Umgebung geeignet.

Eine der häufigsten Bedenken bezüglich der inneren Quelle sind ihre Auswirkungen auf die Sicherheit und die Offenlegung von Informationen. Die Ähnlichkeiten zwischen Inner Source und dem breiteren Open-Source-Ökosystem reichen nur so weit: Der Code in einer offenen Bibliothek oder einem Framework enthält nichts Sensitives, während Sie bei Ihrer Arbeit möglicherweise mit streng gehüteten proprietären Systemen zu tun haben.

Es ist selbstverständlich, dass einige Projekte immer gesperrt werden müssen und nur für Stakeholder und das direkt verantwortliche Implementierungsteam zugänglich sind. Allerdings sollten einige Projekte mit hohem Einsatz und sensibler Quelle, bei denen es nicht sicher ist, sie in der gesamten Organisation sichtbar zu machen, nicht das Ende einer Initiative der inneren Quelle bedeuten.

Werbung

Es lohnt sich immer noch, Projekte zu öffnen, die sicher aufgedeckt werden können. Sie könnten auch die nicht sensiblen Teile privater Projekte in neue gemeinsam genutzte Bibliotheken abstrahieren, die öffentlich zugänglich sind. Dies bringt die Vorteile von Inner Source näher an Ihre sensiblen Assets heran, ohne sie tatsächlich zu enthüllen.

Eine weitere Herausforderung von Inner Source besteht darin, den Entwicklern Erwartungen zurückzugeben. Entwickler sind möglicherweise vorsichtig, offene Projekte zu erkunden, insbesondere wenn die innere Quelle in eine historisch geschlossene Organisation eingeführt wird. Dies kann auf verschiedene Weise angegangen werden, z. B. indem den Entwicklern Zeit zugewiesen wird, den von anderen Teams geschriebenen Code zu überprüfen.

Es kann auch hilfreich sein, klein zu beginnen und nur Kernbibliotheken bereitzustellen, die für viele verschiedene Teams im gesamten Unternehmen nützlich sind. Eine gute Wahl kann eine bekannte, aber private Komponente sein, die den Ruf hat, unzuverlässig oder veraltet zu sein – Denken Sie noch einmal an “gemeldeter Fehler mit dem ApiClient.” Das Öffnen dieser Komponente ermöglicht es Entwicklern, bei Bedarf ihre eigenen Fixes beizutragen, die Produktivität zu verbessern und das organische Wachstum der inneren Quellenmentalität zu fördern.

Wenn Sie diese Technik ausprobieren, achten Sie darauf, zuerst die ursprünglichen Projektautoren zu warnen – selbst wenn dies insgesamt zu einer höheren Effizienz führt, könnten einige Personen andere behandeln, die zu Code beitragen, der früher “ihrer” als Affront. Teilen Sie mit, warum innere Quelle in die Organisation eingeführt wird, sowie die spezifischen Gründe für die Eröffnung einzelner Projekte.

Schlussfolgerung

Inner Source bezieht sich darauf, Entwicklungsmethoden aus der Open-Source-Community zu übernehmen und auf interne Projekte und Prozesse anzuwenden. Es erleichtert den ungehinderten Zugang zu nützlichem Code und Dokumentation und fördert gleichzeitig die Zusammenarbeit und Kommunikation.

Bei richtiger Implementierung kann Inner Source ein Unterscheidungsmerkmal für ein Unternehmen sein, das Redundanzen reduziert, den Durchsatz erhöht und eine gerechtere Entwicklungskultur fördert. Wenn Sie sich dafür entscheiden, Projekte standardmäßig geöffnet zu lassen, können die ursprünglichen Autoren das menschliche Talent der gesamten Organisation nutzen. So wie führende Open-Source-Frameworks und -Bibliotheken die kollektiven Fähigkeiten der Community nutzen, kann Inner Source interne Tools entwickeln, die über das hinausgehen, was ein einzelnes Team erreichen könnte.

Werbung

Inner Source kann schwierig sein, es richtig zu machen. Dies kann zu Zurückweisungen von Code-Eigentümern und zur Vorsicht seitens der Entwickler führen. Halten Sie bei der Einführung jeglicher Form von Inner Source Development auf dem gleichen Stand, indem Sie Erwartungen und Arbeitsabläufe klar dokumentieren. Jeder muss sich wohl fühlen, einen Beitrag zu leisten, damit die vollen Vorteile der inneren Quelle sichtbar werden.