Inner­Source: Projekt Setup Basics

Published On: 15. Februar 2021|Categories: Tech|

Wir haben vor einigen Jahren bei Europace bewusst begonnen, Inner­Source best practices einzu­setzen. Ziel dabei war es, team-übergrei­­fende Zusam­men­arbeit zu verein­fachen, Silos abzubauen und trotz Abhän­gig­keiten zwischen Teams Entwicklung möglichst nicht blockierend zu gestalten.

Vor allem in den vergan­genen Monaten haben wir Erfah­rungen sammeln können mit umfas­sen­derem Einsatz von Lösungen aus dem Inner­Source Bereich für vorhandene Heraus­for­de­rungen. In diesem Blog Post wollen wir uns auf Learnings konzen­trieren, die wir in diesem Prozess gewonnen haben: Wie starte ich ein neues Inner­Source Projekt oder migriere ein altes Projekt zu dieser Arbeits­weise?

Für einen umfas­senden Einstieg in das Thema Inner­Source allgemein, sowie das konkrete Warum und Wie sei das Inner­Source Training empfohlen. In diesem Artikel konzen­trieren wir uns auf konkrete Beobach­tungen.

Trans­parenz

“Offen, auffindbar und trans­parent” — eines der Kernprin­zipien von Inner­Source Projekten: Nur wenn Projekte teamüber­greifend trans­parent geführt werden, ist es für Contri­bu­toren möglich, sich teamüber­greifend einzu­bringen. Dies betrifft:

  • Quellcode und dessen Historie,
  • Kommu­ni­kation und Entschei­dungen zum Projekt,
  • alle Infor­ma­tionen zur Zusam­men­arbeit, die es Contri­bu­toren einfacher machen.

Was bei regulären in-house Projekten nebenbei beim On-Boarding passiert, sollte bei Inner­Source Projekten möglichst nebenbei in passiver Dokumen­tation abgelegt sein — auch weil so existie­rende Dokumen­tation einfach referen­ziert werden kann, wenn sich Fragen an das Projekt wieder­holen. Die Patterns rund um die Struktur von Inner­Source Projekten helfen da mit Vorschlägen rund um sinnvolle Aspekte.

Gover­nance Stufen

Inner­Source kommt nicht als ein einheit­liches “ganz oder gar nicht” Paket. Statt­dessen gibt es konkrete Patterns, die bei team-übergrei­­fender Arbeit helfen können. Das kann aber dazu führen, dass in einem Unter­nehmen Projekte neben­ein­ander existieren, für die unter­schied­liche Stufen der Zusam­men­arbeit sinnvoll sind.

Contri­bu­toren sollten in die Lage versetzt werden, dennoch schnell zu erkennen, wieviel ein Projekt bereit und in der Lage ist, Contri­bu­tions zu unter­stützen. Dafür eignet sich das Gover­nance Levels Pattern: Im einfachsten Falle an sicht­barer Stelle in der README.md des Projektes hinter­legen, auf welcher Stufe sich das Projekt selbst einsor­tiert.

Erwar­tungs­hal­tungen

Team Dory hat sich intern auf einige Standards bei der Zusam­men­arbeit geeinigt: Pull Requests sollen möglichst klein sein, Reviews möglichst in einem halben Tag erfolgen, der Ton in Reviews möglichst knapp bemessen sein. Team Nessie hat sich über die Zeit ebenfalls auf einige Standards bei der Zusam­men­arbeit geeinigt: Pull Requests dürfen gerne in separaten Commits Aufräum­ar­beiten rund um die eigent­lichen Änderungen enthalten, Reviews sollten möglichst innerhalb von zwei Tagen erfolgen. Als Vertreter beider Teams in Inner­Source Projekt Innerdigo zusam­men­ar­beiten, kommt es zu Missver­ständ­nissen.

Auch in diesem Fall hilft es, sich auszu­tau­schen. Im Sinne von “Schriftlich über mündlich” kann dieser Austausch direkt in einem Pull Request statt­finden, der die neuen Best Practices in der README.md des Projektes hinterlegt. Auf diese Weise können oft viele Punkte bereits asynchron geklärt werden. Gegebe­nen­falls offene Punkte können dann in einem separaten Austausch direkt angesprochen werden.

Auf gleiche Art und Weise können später Anpas­sungen an den gemachten Regeln durch­ge­führt werden.

Planung

Projekt Innerdigo wird als Inner­Source Projekt von einem Team aus Trusted Committern entwi­ckelt und betreut. Das kundennahe Team Contri­biella nutzt dieses Projekt in seinen Abhän­gig­keiten. Im Zuge der Analyse einer User Story wird deutlich, dass eine Änderung an Innerdigo Team Contri­biella helfen würde. Team Contri­biella verbringt viel Zeit nicht nur mit der Analyse, sondern auch mit einer ersten Imple­men­tierung der Änderung. Als die Änderung letztlich bei Innerdigo einge­reicht wird, stößt die Änderung aber nicht auf offene Arme: Es kommen viele Fragen, warum diese Änderung überhaupt gebraucht wird. Warum genau diese Imple­men­tierung gewählt wurde, statt eine Variante, die sich besser in die Roadmap von Innerdigo einpasst. Warum Coding Standards von Innerdigo nicht einge­halten wurden. Letztlich dauert die Anpassung der Änderung so lange, dass eine komplette Umgehung der notwen­digen Änderung vermutlich schneller imple­men­tiert wäre.

Was ist passiert?

Auf beiden Seiten fehlten wichtige Infor­ma­tionen: Mangels einer trans­pa­renten Roadmap Planung konnte Contri­biella nicht abschätzen, welche Änderungen tatsächlich sinnvoll sind. Mangels einer zügigen Trans­parenz hinsichtlich der Kunden­an­for­de­rungen und den dafür poten­ziell notwen­digen Änderungen konnte das Team hinter Innerdigo wenig bei der Imple­men­tierung unter­stützen.

An dieser Stelle hilft wiederum sehr viel mehr Trans­parenz: Einer­seits auf Seiten von Innerdigo wenn es darum geht, die eigene Roadmap zu entwi­ckeln und zu publi­zieren. Aber auch Seiten von Contri­biella wenn es darum geht, die Absicht einer Änderung möglichst schnell in Innerdigo trans­parent zu machen — nur so kann Innerdigo bei der Umsetzung unter­stützen und effizi­entere Wege anregen.

Klare Verant­wortung

In allen voran­ge­gan­genen Posts sind wir bei Inner­Source Projekten davon ausge­gangen, dass es ein Team aus Trusted Committern gibt. Was aber, wenn diese Verant­wortung ungeklärt ist?

Auch hier hat es sich bewährt, die Diskussion möglichst trans­parent zu führen. Auf diese Weise können ihr auch Personen folgen und sich einbringen, die vielleicht nicht offen­sichtlich von Anfang an integriert wurden:

Ein Issue, das den Mangel an Trusted Committern sichtbar macht, ist hier oft der erste Schritt. Die Personen, die als Trusted Committer in Frage kommen, können dann per Pull Request z.B. an der README.md ergänzt werden.

Kann man vermeiden in einen Mangel an Trusted Committern zu laufen? Die beste Strategie dafür liegt darin, konti­nu­ierlich Personen in das Projekt zu ziehen, die sich aktiv betei­ligen (und jene zu unter­stützen, die sich noch nicht aktiv betei­ligen). Üblicher­weise sollte unter den existie­renden Trusted Committern vor der Einladung eines neuen Mitglieds eine Abstimmung über die Einladung erfolgen. Auch dazu gibt es einen Vorschlag zum Ablauf.

Regel­mä­ßiger Austausch

In allen voran­ge­gan­genen Posts sind wir bei Inner­Source Projekten davon ausge­gangen, dass es ein Team aus Trusted Committern gibt. Was aber, wenn diese Verant­wortung ungeklärt ist?

Auch hier hat es sich bewährt, die Diskussion möglichst trans­parent zu führen. Auf diese Weise können ihr auch Personen folgen und sich einbringen, die vielleicht nicht offen­sichtlich von Anfang an integriert wurden:

Ein Issue, das den Mangel an Trusted Committern sichtbar macht, ist hier oft der erste Schritt. Die Personen, die als Trusted Committer in Frage kommen, können dann per Pull Request z.B. an der README.md ergänzt werden.

Kann man vermeiden in einen Mangel an Trusted Committern zu laufen? Die beste Strategie dafür liegt darin, konti­nu­ierlich Personen in das Projekt zu ziehen, die sich aktiv betei­ligen (und jene zu unter­stützen, die sich noch nicht aktiv betei­ligen). Üblicher­weise sollte unter den existie­renden Trusted Committern vor der Einladung eines neuen Mitglieds eine Abstimmung über die Einladung erfolgen. Auch dazu gibt es einen Vorschlag zum Ablauf.

Written by Isabel Drost-Fromm Open Source Strategist @ Europace