Wir haben vor einigen Jahren bei Europace bewusst begonnen, InnerSource best practices einzusetzen. Ziel dabei war es, team-übergreifende Zusammenarbeit zu vereinfachen, Silos abzubauen und trotz Abhängigkeiten zwischen Teams Entwicklung möglichst nicht blockierend zu gestalten.

Vor allem in den vergangenen Monaten haben wir Erfahrungen sammeln können mit umfassenderem Einsatz von Lösungen aus dem InnerSource Bereich für vorhandene Herausforderungen. In diesem Blog Post wollen wir uns auf Learnings konzentrieren, die wir in diesem Prozess gewonnen haben: Wie starte ich ein neues InnerSource Projekt oder migriere ein altes Projekt zu dieser Arbeitsweise?

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

Transparenz

“Offen, auffindbar und transparent” - eines der Kernprinzipien von InnerSource Projekten: Nur wenn Projekte teamübergreifend transparent geführt werden, ist es für Contributoren möglich, sich teamübergreifend einzubringen. Dies betrifft:

• Quellcode und dessen Historie,
• Kommunikation und Entscheidungen zum Projekt,
• alle Informationen zur Zusammenarbeit, die es Contributoren einfacher machen.

Was bei regulären in-house 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. Die Patterns rund um die Struktur von InnerSource Projekten helfen da mit Vorschlägen rund um sinnvolle Aspekte.

Governance Stufen

InnerSource kommt nicht als ein einheitliches “ganz oder gar nicht” Paket. Stattdessen gibt es konkrete Patterns, die bei team-übergreifender Arbeit helfen können. Das kann aber dazu führen, dass in einem Unternehmen Projekte nebeneinander existieren, für die unterschiedliche Stufen der Zusammenarbeit sinnvoll sind.

Contributoren 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 aber nicht auf offene Arme: 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 ist 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.

Klare Verantwortung

In allen vorangegangenen Posts sind wir bei InnerSource Projekten davon ausgegangen, dass es ein Team aus Trusted Committern gibt. Was aber, wenn diese Verantwortung ungeklärt ist?

Auch hier hat es sich bewährt, die Diskussion möglichst transparent zu führen. Auf diese Weise können ihr auch Personen folgen und sich einbringen, die vielleicht nicht offensichtlich 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, kontinuierlich Personen in das Projekt zu ziehen, die sich aktiv beteiligen (und jene zu unterstützen, die sich noch nicht aktiv beteiligen). Üblicherweise sollte unter den existierenden Trusted Committern vor der Einladung eines neuen Mitglieds eine Abstimmung über die Einladung erfolgen. Auch dazu gibt es einen Vorschlag zum Ablauf.

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 Team zu Team weitergegeben werden. Auch Probleme können so 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. Diese trifft sich monatlich. Themen können aber auch zwischendurch asynchron besprochen werden, da für die Organisation der Community die gleichen Best Practices zum Einsatz kommen, wie für InnerSource Projekte.