Wie funktioniert InnerSource?

Nehmen wir folgendes Szenario an: Team A verwendet Software, die von Team B produziert wird. Team A übermittelt Anforderungen an Team B, aber Team B ist stark ausgelastet und kann diese nicht rechtzeitig implementieren. InnerSource ermögicht Team A, anstatt einer Anforderung, einen PullRequest mit der eigenen Implementierung an Team B zu schicken. Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. Team B überprüft dann den übermittelten Code, überarbeitet ihn gegebenenfalls in enger Partnerschaft mit Team A und integriert die Änderungen sobald sie den Anforderungen entsprechen.

In diesem Beispiel nennen wir Team A das Guest-Team und Team B das Host-Team. Die Begriffe Guest und Host legen eine Situation nahe, die dem Empfang eines Besuchers im Haus entspricht. In dieser Situation wollen die meisten Menschen ein guter Gastgeber sein. Haben sich Gäste angekündigt, sorgen Gastgeber für eine einladende Atmosphäre. Die Besucher werden an der Tür begrüßt und herein gebeten. Sie können die Einrichtungen und Räume nutzen, die sich in den öffentlichen Bereichen des Zuhauses befinden. Es kann ein paar Regeln geben, um deren Befolgung Gäste gebeten werden. Auf der anderen Seite wollen Gäste meist respektvoll und sorgsam mit dem Zuhause des Gastgeber umgehen. Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. Werden die Grenzen von Etikette und höflichen Umgangsformen überschritten, sollten diese Gäste sich nicht wundern, wenn sie keine erneute Einladung erhalten. Diese Konzepte rund um einen Besuch sind eine Metapher für Einstellung und Verhalten von Teams in den Rollen Gastgeber (Host) und Gast (Contributor).

Werfen wir einen genaueren Blick darauf, wie der InnerSource-Prozess funktioniert. Bevor wir in das Thema tiefer einsteigen, schauen wir uns einige wichtige Rollen in den Gast- und Gastgeberteams an. Zunächst legt der Product Owner fest, welche Funktionen das Hostteam als Beitrag zu akzeptieren bereit ist. Der Contributor ist die Person im Gastteam, die den Codebeitrag einreicht, welcher dann durch das Hostteam geprüft und ggf. akzeptiert wird. Der Trusted Committer steht dem Hostteam als zusätzliche Unterstützung für Review- und Mentoringaufgaben bei, um letztendlich den Contributor mit seinem Pullrequest zu unterstützen. Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person sowohl die Rolle des Product Owners als auch die des Trusted Committer aus.

Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren.

Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. InnerSource geht davon aus, dass Teams bereits über vorhandene Organisationsmethoden verfügen, und bietet einen Rahmen für die Zusammenarbeit, wenn ein Gastteam Code zu einem Project beitragen möchte.

Dieser Weg der Zusammenarbeit birgt Vorteile für das Gastteam. Es erhält die Funktionalität, die es benötigt zum rechten Zeitpunkt und ohne die Verpflichtung, die langfristige Wartung der Lösung zu übernehmen. Dieser Weg funktioniert für das Gastgeberteam, weil es in der Lage ist, besser zu skalieren und seine Kunden besser zu bedienen. Dies funktioniert für das Unternehmen in der Gesamtheit, weil Lösungen für gemeinsame Probleme an einem gemeinsamen, zentral gepflegten Ort jedem zur Verfügung gestellt werden. In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehmensprobleme löst, anstatt in Verhandlungen über Features oder in Eskalationsprozesse.