EP-Tech-Reihe – Teil 2: How-to Innersource

Vor einigen Jahren haben wir bei Europace bewusst begonnen, InnerSource Best Practices einzusetzen. Hier möchten wir unsere Learnings teilen, die wir in diesem Prozess gewonnen haben. Allen voran: Wie starte ich ein neues InnerSource Projekt oder migriere ein altes Projekt zu dieser Arbeitsweise? 

Für einen sicheren Einstieg in das Thema InnerSource allgemein, sowie das konkrete Warum und Wie sei das InnerSource Training empfohlen. In diesem Artikel konzentrieren wir uns auf unsere konkrete Beobachtungen:

Was bei regulären Inhouse-Projekten nebenbei beim On-Boarding passiert, sollte bei InnerSource-Projekten möglichst nebenbei in passiver Dokumentation abgelegt sein – auch weil so existierende Dokumentation einfach referenziert werden kann, wenn sich Fragen an das Projekt wiederholen. Patterns rund um die Struktur von InnerSource Projekten helfen uns mit Vorschlägen.

Governance-Stufen

InnerSource kommt nicht als ein einheitliches „ganz oder gar nicht“-Paket. Stattdessen gibt es konkrete Muster, die bei teamübergreifender Arbeit helfen können. Das kann aber dazu führen, dass in einem Unternehmen Projekte nebeneinander existieren, für die unterschiedlichen Stufen der Zusammenarbeit sinnvoll sind. Mitwirkende sollten in die Lage versetzt werden, dennoch schnell zu erkennen, wieviel ein Projekt bereit und in der Lage ist, Contributions zu unterstützen. Dafür eignet sich das Governance Levels Pattern: Im einfachsten Falle an sichtbarer Stelle in der README.md des Projektes hinterlegen, auf welcher Stufe sich das Projekt selbst einsortiert.

Erwartungshaltungen

Team Dory hat sich intern auf einige Standards bei der Zusammenarbeit 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 Zusammenarbeit geeinigt: Pull Requests dürfen gerne in separaten Commits Aufräumarbeiten rund um die eigentlichen Änderungen enthalten, Reviews sollten möglichst innerhalb von zwei Tagen erfolgen. Als Vertreter beider Teams in InnerSource Projekt Innerdigo zusammenarbeiten, kommt es zu Missverständnissen.

Auch in diesem Fall hilft es, sich auszutauschen. Im Sinne von “schriftlich über mündlich” kann dieser Austausch direkt in einem Pull Request stattfinden, 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. Gegebenenfalls offene Punkte können dann in einem separaten Austausch direkt angesprochen werden.

Auf gleiche Art und Weise können später Anpassungen an den gemachten Regeln durchgeführt werden.

Planung

Projekt Innerdigo wird als InnerSource Projekt von einem Team aus Trusted Committern entwickelt und betreut. Das kundennahe Team Contribiella nutzt dieses Projekt in seinen Abhängigkeiten. Im Zuge der Analyse einer User Story wird deutlich, dass eine Änderung an Innerdigo Team Contribiella helfen würde. Team Contribiella verbringt viel Zeit nicht nur mit der Analyse, sondern auch mit einer ersten Implementierung der Änderung. Als die Änderung letztlich bei Innerdigo eingereicht wird, stößt die Änderung auf Kritik: Es kommen viele Fragen, warum diese Änderung überhaupt gebraucht wird, warum genau diese Implementierung gewählt wurde, statt eine Variante, die sich besser in die Roadmap von Innerdigo einpasst, warum Coding Standards von Innerdigo nicht eingehalten wurden. Letztlich dauert die Anpassung der Änderung so lange, dass eine komplette Umgehung der notwendigen Änderung vermutlich schneller implementiert wäre.

Was war passiert?

Auf beiden Seiten fehlten wichtige Informationen: Mangels einer transparenten Roadmap Planung konnte Contribiella nicht abschätzen, welche Änderungen tatsächlich sinnvoll sind. Mangels einer zügigen Transparenz hinsichtlich der Kundenanforderungen und den dafür potenziell notwendigen Änderungen konnte das Team hinter Innerdigo wenig bei der Implementierung unterstützen.

An dieser Stelle hilft wiederum sehr viel mehr Transparenz: Einerseits auf Seiten von Innerdigo wenn es darum geht, die eigene Roadmap zu entwickeln und zu publizieren. Aber auch Seiten von Contribiella wenn es darum geht, die Absicht einer Änderung möglichst schnell in Innerdigo transparent zu machen – nur so kann Innerdigo bei der Umsetzung unterstützen und effizientere Wege anregen.

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.

Wie kann man einen Mangel an Trusted Committern vermeiden? Die beste Strategie dafür liegt darin, kontinuierlich Personen in das Projekt zu ziehen, die sich aktiv beteiligen und jene zu unterstützen, die dies noch nicht tun. Üblicherweise sollte unter den agierenden Trusted Committern vor der Einladung eines neuen Mitglieds eine Abstimmung über die Einladung erfolgen. Auch dazu sollte ein Prozess etabliert werden.

Regelmäßiger Austausch

Ein wichtiger Aspekt bei teamübergreifender Zusammenarbeit besteht darin, regelmäßig in Kontakt zu bleiben. Auf diese Weise können Best Practices schnell von anderen Teams übernommen werden. Probleme können schnell in einem Team-neutralen Umfeld angesprochen und so meist einfacher gelöst werden.

Auch bei uns nutzen wir dafür eine Community of Practice. Sie trifft sich monatlich, aber natürlich können Themen zwischendurch auch asynchron besprochen werden, da für die Organisation der Community die gleichen Best Practices zum Einsatz kommen, wie für InnerSource-Projekte.