Freier Informationsfluss: Open Source im Unternehmen mit InnerSource
Wer mit dem Begriff InnerSource nichts anfangen kann, ist nicht alleine. Eine Umfrage des Autors unter Freunden ergab, dass selbst Personen mit jahrzehntelanger Open-Source-Erfahrung, darunter professionelle Softwareentwickler und -Produktmanager, bestenfalls eine grobe Vorstellung davon hatten.
Anzeige
Dr. Rüdiger Berlich beschäftigt sich seit 1992 mit Open Source und hat sich in seinem MBA mit dem Thema zugehöriger Geschäftsmodelle auseinandergesetzt. Er berät Firmen zu Fragen der Open- und InnerSource, zu agilen Praktiken sowie dem Change Management.
Dabei wurde der Begriff bereits vor über zwanzig Jahren geprägt. Tim O’Reilly schrieb im Dezember 2000 zum Verhältnis von OpenGL zu Open Source: “Collabs [CollabNet war eine von O’Reilly mitgegründete Firma] Mission ist es, kollaborative Entwicklung im Stil von Open Source für die Softwareindustrie im Ganzen zu ermöglichen. Typischerweise beinhaltet das, großen Unternehmen beim Übergang zu Open Source behilflich zu sein. Aber wir haben auch mit Unternehmen an ‘Inner Sourcing’, wie wir es nennen, gearbeitet – das heißt, sie beim Nutzen von Open-Source-Techniken innerhalb der Firma zu unterstützen.” Den fehlenden Bekanntheitsgrad kann erklären, dass das Konzept eher bei großen Firmen und in der proprietären Softwareentwicklung eine Rolle spielt.
Die Schreibweise von InnerSource ohne Leerzeichen entsprang dem Versuch, die mangelnde Sichtbarkeit des Konzepts zu verbessern. Im Buch “Adopting InnerSource” von Danese Cooper und Klaas-Jan Stol findet sich die Erklärung: “Um den Begriff einfacher auffindbar zu machen (wenn Sie versuchen, nach ‘inner source’ zu suchen, finden Sie nur Ergebnisse ohne Softwarebezug), haben wir das Leerzeichen in der Mitte entfernt und CamelCase-Schreibeweise eingeführt.” Heute stellt dies kein Problem mehr dar – sowohl Google als auch ChatGPT liefern auch zu “Inner Source” passende Antworten.
Open-Source-Konzepte ins Unternehmen übertragen
InnerSource adressiert ein Grundproblem in vielen Unternehmen, dass Wissen und Ressourcen fragmentiert sind. In gewachsenen Organisationsstrukturen arbeiten Teams oft isoliert, was zu doppelter Arbeit, Wissenssilos und ineffizienter Ressourcennutzung führt. In großen Unternehmen ist es für Entwicklerteams oft einfacher, eine Funktion selbst zu schreiben, als diese bei anderen Teams anzufragen, deren Code dann vielleicht auch nur halb passt. So entstehen Parallelwelten, die sich mit wachsender Komplexität immer schwerer konsolidieren lassen.
Einen Gegenentwurf liefert die InnerSource-Philosophie: Sie wendet das Open-Source-Prinzip “Release early. Release often. And listen to your customers” an, das Eric Raymond 1997 in seinem Essay “The Cathedral and the Bazaar” beschrieben hat. Übertragen auf Unternehmen bedeutet es, Code schon beim Entstehen unternehmensintern verfügbar zu machen und zu bewerben. Kontributoren sollten nicht nur aus den Kreisen der eigenen Peer Group hinzukommen, sondern idealerweise über Abteilungsgrenzen hinweg – jedoch beschränkt auf die eigene Organisation. Das hilft, die Zahl neu entstehender Silos frühzeitig einzudämmen und kann – mit höherem Aufwand – auch in etablierten Projekten zum Einsatz kommen.
Ist dieses interne Community-Building erfolgreich, vermeidet es nicht nur Insellösungen, sondern das Unternehmen profitiert gleichzeitig von einem zweiten von Eric Raymond formulierten Prinzip: “Given enough eyeballs, all bugs are shallow”, auch bekannt als Linus’s Law. Die Qualität steigt und zugleich orientiert sich die Entwicklung an den realen Bedürfnissen der Nutzerinnen und Nutzer, was zu einer weiteren Effizienzsteigerung führt.
Das FOSS Manifesto der Mercedes-Benz AG beschreibt einige Prinzipien, darunter
- Entwickler sollen zunächst nach passenden Open- oder InnerSource-Alternativen suchen, bevor sie Code selbst entwickeln oder kaufen.
- Entwickler sollen sich in der InnerSource-Community engagieren und zu Projekten beitragen.
Nicht nur bei Mercedes ist InnerSource en vogue. Das Beratungsunternehmen Gartner führte das Thema 2023 auf Platz 7 seines Software Engineering Hype Cycles.
InnerSource Commons als zentrale Anlaufstelle
Die Open-Source-Pionierin Danese Cooper hat 2015 die firmenübergreifende und gut organisierte Initiative InnerSource Commons ins Leben gerufen, mit dem Ziel, Wissen über InnerSource zu sammeln und zu verbreiten. Die Initiative bildet einen zentralen Hub, veröffentlicht auf der Plattform umfangreiche Informationen und stellt die InnerSource Patterns vor. Sie liefern Know-how zum Aufsetzen und weiteren Betreiben von InnerSource-Communities. Interessenten finden auf der Plattform auch kostenlose Bücher, Fallstudien und einen Vergleich zu Open Source. Außerdem veranstaltet die Initiative Events, wie zuletzt online den InnerSource Summit vom 20. bis 21. November 2024. Die über YouTube frei zugänglichen Streams der Vorträge bilden ebenfalls eine gute Informationsquelle.
Der von der Initiative veröffentlichte State of InnerSource Report 2024 gibt einen quantitativen Überblick zu Motiven und Umsetzung von InnerSource-Initiativen.
Viele Informationen finden sich auch in Publikationen der Firma SAP, die das Thema aktiv aufgegriffen hat. Das Projektportal von SAP auf GitHub diente als Vorlage für eines der erwähnten Patterns der Commons. Im Abstract zu seinem Vortrag “SAP’s Repository Linter” auf dem Summit 2024 beschreibt Benjamin Ihrig, Cloud Native Developer von SAP, das Engagement seines Arbeitgebers so: “Ein essenzieller Teil unseres Software-Entwicklungsprozesses ist: Zusammenarbeit, Innovation und effiziente Code-Wiederverwendung zu fördern.”
