Publiziert:

InnerSource

Code wird über Teamgrenzen hinweg besser

InnerSource ist die Anwendung von bewährten Open-Source-Methoden (wie Pull Requests, asynchrone Code Reviews und offene Dokumentation) auf die interne Softwareentwicklung. Es ermöglicht Teams, Code anderer Teams zu verbessern, ohne auf langsame Feature-Requests warten zu müssen.

In vielen Firmen sind Code-Basen "Besitz" einzelner Teams. Wenn Team A eine Änderung in einer Bibliothek von Team B braucht, entsteht ein Flaschenhals. InnerSource löst diesen Knoten.

Anti-Patterns: Die Kosten von Code-Silos

  • Wartezeiten: Teams stehen still, weil sie auf die Implementierung einer kleinen Änderung in einer anderen Komponente warten.
  • Code-Duplikation: Da der Zugriff oder das Verständnis für existierenden Code fehlt, bauen Teams Funktionalitäten einfach selbst neu.
  • Wissensinseln: Verlässt ein Entwickler das Team, geht das Wissen über diesen Code-Teil oft unwiederbringlich verloren.

Die Säulen von InnerSource

  1. Offene Sichtbarkeit: Jeder im Unternehmen kann (fast) jeden Code lesen und verstehen.
  2. Kollaboration via PRs: Wenn Team A eine Änderung braucht, schreibt es den Code selbst und stellt einen Pull Request (PR) an Team B.
  3. Trusted Committers: Erfahrene Entwicklerinnen und Entwickler in Team B fungieren als Qualitätshüter und Mentoren, führen Code Reviews durch und stellen die Qualität sicher.
  4. Asynchrone Dokumentation: Wissen wird nicht in Köpfen, sondern im Code und in begleitenden Readmes festgehalten.
  5. Passive Beteiligung: Auch das Mitlesen von Diskussionen und das Lernen aus bestehendem Code ist ein Wert an sich.

Kulturelle Voraussetzung

InnerSource benötigt Zeit für Code Reviews und eine Kultur, in der Hilfeleistungen für andere Teams als wertvolle Arbeit anerkannt werden (statt nur "eigene" Tickets zu zählen).

FAQ

Verlieren Entwickler nicht Zeit, wenn sie Code für andere Teams reviewen?

Kurzfristig ja, langfristig sparen sie Zeit: weniger Support-Anfragen, bessere Gesamtqualität des Codes.

Muss ich jetzt meinen unfertigen Code allen zeigen?

Ja. Transparenz ist ein Vorteil. "Perfect is the enemy of the good." Frühe Sichtbarkeit ermöglicht frühes Feedback.

Referenzen