Was bedeutet Inner Source?
Inner Source bezeichnet die Anwendung der aus Open-Source-Projekten bekannten Entwicklungspraktiken innerhalb eines Unternehmens. Teams teilen Quellcode, Werkzeuge und Bibliotheken über Teamgrenzen hinweg und Personen aus anderen Bereichen können zu Projekten beitragen, die sie ursprünglich nicht verantworten. Die Zusammenarbeit folgt dabei den gleichen Mustern wie in freien Projekten: offene Repositories, transparente Diskussionen, Beiträge per Pull Request und ein klar definiertes Verfahren für deren Review und Aufnahme.
Warum Inner Source?
In gewachsenen Organisationen entstehen häufig Silos zwischen Abteilungen und Produktteams. Teams implementieren Funktionen mehrfach, weil sie Bestehendes nicht kennen oder darauf keinen Zugriff haben. Teams warten aufeinander, wenn nur eine Stelle Änderungen an einer geteilten Komponente vornehmen darf, und das Wissen über interne Werkzeuge bleibt in den Köpfen weniger Personen. Inner Source setzt an dieser Stelle an: Wer eine Erweiterung an einer gemeinsamen Bibliothek braucht, kann sie selbst beitragen, anstatt sie über einen Ticketprozess in eine fremde Roadmap einzureihen. Das beschleunigt die Umsetzung, hebt die Codequalität durch mehr beteiligte Augen und fördert den Wissenstransfer zwischen den Teams.
Rollen und Verantwortlichkeiten
Inner-Source-Projekte definieren ihre Rollen ähnlich wie etablierte Open-Source-Vorhaben. Contributors stammen aus anderen Teams, folgen den Contributing Guidelines und reichen ihre Änderungen als Pull Request ein. Trusted Committers sind die Maintainer eines Projekts, prüfen Beiträge fachlich und führen sie zusammen. Sie pflegen die Dokumentation und helfen neuen Mitwirkenden beim Einstieg. Ein Product Owner definiert die Roadmap, priorisiert eingehende Beiträge und vertritt die Interessen der Stakeholder.
Bewährte Muster
Im Inner-Source-Umfeld haben sich einige Muster eingebürgert, die den Umgang mit fremden Beiträgen regeln. Die sogenannte 30-Day Warranty verpflichtet das beitragende Team, den eingebrachten Code für 30 Tage nach dem Merge zu unterstützen. Ein dedizierter Community Leader kümmert sich in größeren Vorhaben um Onboarding, Sichtbarkeit und Pflege der Diskussionen. Ein übergreifendes Review Committee trifft architektonische Entscheidungen, die mehrere Inner-Source-Projekte gleichzeitig betreffen, und ein Maturity Model beschreibt Reifegrade, an denen sich Teams orientieren können.
Voraussetzungen für die Praxis
Damit Inner Source funktioniert, müssen Projekte auffindbar und zugänglich sein. Dazu gehört eine konsistente Repository-Struktur, in der gemeinsam genutzte Bibliotheken klar von teaminternen Vorhaben getrennt sind. Jedes Projekt sollte mindestens eine README, eine CONTRIBUTING-Datei, eine Übersicht zur Architektur sowie eine kurze Beschreibung der Governance bereitstellen. Erst diese Grundlagen machen es realistisch, dass Personen aus anderen Teams sich orientieren und sinnvoll beitragen können.
Abgrenzung zu Open Source
Inner Source übernimmt die Praktiken offener Projekte, behält aber den Wirkungskreis im Unternehmen. Die Sichtbarkeit bleibt intern, die Governance liegt in der Hand der Organisation, und es gibt keine öffentliche Lizenz. Beitragende sind Mitarbeitende des Unternehmens, deren Motivation aus einer Mischung aus eigenem Bedarf, gemeinsamen Zielen und persönlichem Interesse entsteht. Die Methoden sind dieselben, der Rahmen ist enger gesteckt.
Relevanz für Web-Projekte
Für Agenturen und IT-Abteilungen ist Inner Source ein Hebel, um aus parallelen Projekten eine wiederverwendbare Plattform aufzubauen. Geteilte Bibliotheken für Authentifizierung, UI-Komponenten oder Logging entstehen schneller und Teams testen sie in mehreren Vorhaben gleichzeitig. Voraussetzung bleibt eine Kultur, in der Teams Teilen anerkennen und das Pflegen gemeinsamer Komponenten als Teil der Arbeit sehen – nicht als zusätzliche Last neben dem eigentlichen Projekt.
