© Elena Shchipkova / 123RF.com

Immer mehr Firmen übernehmen die Vorteile des freien Modells der Softwareentwicklung. Auch proprietäre Hersteller wollen von dem profitieren, was sie in den Communities lernen. Sogar Gartner führt den steinalten Begriff Inner Source jetzt in seinen Hype-Cycle-Diagrammen auf.

Es mag überraschen, aber sowohl das Konzept als auch der Begriff Inner Source sind keineswegs neu, sondern bald ein Vierteljahrhundert alt. Großmeister Tim O’Reilly [1] erfand zwar nicht Open Source, trug aber viel dazu bei, dass heute fast jeder IT-Manager schon einmal davon gehört hat. Die Älteren werden sich erinnern: Der in Irland geborene Amerikaner prägte auch das partizipative Web 2.0 mit dem Schwerpunkt auf benutzergenerierte Inhalte.

Als im Jahr 2000 Flame Wars und Streitigkeiten zum Beispiel über OpenGL tobten, diskutierte O’Reilly mit Matt Feinstein über seine Haltung zu Open Source. Obwohl die Originale des Threads verschollen scheinen, gilt diese erste, grundlegende Definition [2] als Ursprung: “Wir haben auch mit Unternehmen an dem gearbeitet, was wir ‘Inner Sourcing’ nennen. Das heißt, wir haben ihnen geholfen, Open-Source-Entwicklungstechniken innerhalb des Unternehmens einzusetzen.”

Besseres Miteinander

Inner Source führt also in Unternehmen eine Form der Zusammenarbeit ein, die Open-Source-Communities miteinander pflegen. Allerdings bleibt die Kooperation und Kommunikation bei Inner Source eher auf die Firma begrenzt und verlässt den Unternehmensraum nicht. Es lässt sich durchaus als ein Ritterschlag für Open Source und Freie Software verstehen, wenn Konzerne zwar einerseits keine Bestrebungen zeigen, ihre Cashcow-Software unter freie Lizenzen zu stellen, auf der anderen Seite aber freimütig zugeben, dass das Entwicklungsmodell so überzeugend ist, dass man sich organisatorisch einiges davon abschauen kann.

Dazu kommen nicht nur agile Softwareentwicklung und deren typische Open-Source-Tools zum Einsatz, sondern auch offene, klare und nachvollziehbare Kommunikation. In Unternehmen, die Inner Source leben, können Entwickler stets den aktuellen Stand von Projekten und Arbeitspaketen ihrer Kollegen abfragen und dazu beitragen – selbstverständlich meist abgestimmt mit Compliance- und anderen Regeln.

Nutzen für Closed Source

Zur offenen Kommunikation kommt die offene Kollaboration hinzu: Verbesserungen und Korrekturen sind ausdrücklich erwünscht, im Idealfall kann jeder zu jedem Code beitragen. Dementsprechend anders gestaltet sich häufig ebenfalls das Qualitätsmanagement und Testing. Die Code-Reviews können viel mehr Kollegen (mit)machen, jeder Contributor darf theoretisch selbst Integrationstests vornehmen.

Firmen versprechen sich von Open-Source-Modellen eine schnellere Entwicklung, geringere Kosten, effizientere, bereichsübergreifende Kommunikation und höhere Codequalität. Das dürfte FOSS-Evangelisten wenig überraschen – und freuen. Wer das in den 1990er-Jahren prophezeite, wurde vielfach verlacht. Wer beispielsweise die Linux-Kernel-Mailing-Liste verfolgt, runzelt ob der vermeintlich besseren und effektiveren Kommunikation die Stirn.

Hinter Mauern

Microsoft, Philips, Mercedes-Benz, Continental, Paypal, Bosch oder Walmart – die Liste der Unternehmen, die Inner Source einsetzen, ist lang. Fast alle Einträge gehören zu Konzernen, deren Produkte sonst eher weniger mit freier Software zu tun haben und die kein Interesse daran haben, Eigenentwicklungen zu veröffentlichen. Andere würden das vielleicht gern, doch bleibt ihnen dieser Schritt etwa aufgrund von Firmengeheimnissen, einem IP-Schutz oder Patentrechten verwehrt.

Außerdem verhindern in vielen Fällen ganz banale Business-Überlegungen und Geschäftsinteressen Open Source, oder schlicht Unkenntnis und Ängste. Wie die 2015 gestartete Inner Source Commons Foundation (ISC [3]) auf ihrer Webseite erklärt, wollen viele Programmierer am liebsten auf der liebgewonnenen Open-Source-Software weiterentwickeln. Sie sind es einfach schon gewohnt, Open-Source-Methoden anzuwenden, und wünschen sich sehr, die Ansätze auch hinter der Firmen-Firewall nutzen zu können. Inner Source hilft dann, Silos aufzubrechen, die Beschäftigten zu motivieren, sie zu inspirieren und neue Mitarbeiter einzuarbeiten (Onboarding).

Hilfe für die Praxis

Offiziell am 19. Februar 2020 von Open-Source-Urgestein Danese Cooper gegründet, verbindet die ISC als Wohltätigkeitsorganisation heute eigenen Angaben zufolge über 3000 Personen aus mehr als 750 Unternehmen, akademischen Einrichtungen und Regierungsbehörden (Abbildung 1). Die ISC bietet auf ihrer Webseite viele Videos und Texte, die sowohl als Einführung dienen als auch bei konkreten Fragestellungen weiterhelfen können (Abbildung 2). Zu den Sponsoren zählen unter anderem IBM, Microsoft, Github, Red Hat, SAP, aber genauso die US-Bank Fannie Mae und der Jobvermittler Indeed.

Abbildung 1: Die ISC hat viele Unterstützer gewonnen und bietet neben tatkräftiger Unterstützung und Konferenzen umfangreiches Informationsmaterial.

Abbildung 2: Unter den Informationen findet sich ein vom ISC-Mitglied Paypal gesponsertes O’Reilly-E-Book “Adopting Inner Source” (Stand 2018) zum kostenlosen Download.

Auch nach der Definition der ISC bedeutet Inner Source vor allem offene Zusammenarbeit. Die Foundation legt den Schwerpunkt aber ein wenig mehr auf Effizienzsteigerungen: Teams können unabhängig von Abteilungsgrenzen Code und Ressourcen offen teilen. Offene Code Reviews und gemeinsames Lernen versetzen Entwickler in die Lage, sich gegenseitig zu unterstützen, Code zu überprüfen und voneinander zu lernen. Dementsprechend können Unternehmen Entwicklungsprojekte schneller vorantreiben, da sich Talente und Ressourcen besser nutzen lassen. Der reibungslose Austausch von Ideen und Technologien innerhalb der Organisationen fördert obendrein die Innovationskraft in der Firma.

Strukturen aufbrechen

Dazu müssen Unternehmen allerdings zunächst einige Hürden überspringen. Nicht alle Teams sind automatisch bereit, offen zu teilen oder zu kollaborieren. Bei manchen Projekten kann es sich als schwierig erweisen, die Zusammenarbeit zu organisieren und klare Verantwortlichkeiten festzulegen.

In solchen Fällen hilft eine gute (Prozess-)Dokumentation weiter: Sie stellt sicher, dass alle Beteiligten den Überblick behalten. Als Klassiker in Inner-Source-Firmen gelten Git, Containerlösungen, Continuous Integration und Deployment sowie Tools aus dem Test-, Qualitäts- und Release-Management. Da überrascht es dann doch, dass es kaum auf die Bedürfnisse der Inner-Source-Anwender zugeschnittene Software gibt, ganz zu schweigen von Open-Source-Tools. In Unternehmen finden sich häufig selbst entwickelte, relativ listenbasierte Webportale.

Im Gespräch mit Georg Grütter, ISC-Board-Mitglied und Chief Expert Inner Source bei Bosch, wird schnell klar, dass Inner Source oft als Wunsch der Belegschaft von unten nach oben durchsickert, dann aber schnell durch Erfolge zu überzeugen weiß. “Vor allem das Training ist da wichtig, auf allen Ebenen. […] Und dann merkt man, dass Autonomy, Motivation, Purpose (AMP) als Antrieb so viel besser funktioniert als klassische Modelle und Incentives.” Grütter, Cooper und die CEO der ISC, Clare Dillon, geben ihr Wissen in zahlreichen Videos weiter, sowohl auf der Webseite der Organisation als auch bei Youtube und den jährlichen Inner Source Summits [4].

Dort präsentieren auch die Konzerne ihre Erfahrungen, beispielsweise Github. Besonders spannend ist dabei, wie Github die Stakeholder aufteilt. Laut den Github-Experten Jamie Strusz und Gus Stewart existieren drei unterschiedliche Gruppen, die man spezifisch ansprechen muss: Leadership, Management und Contributors. Zwischen den ersten beiden zu unterscheiden, scheint bereits eine Erfahrung aus der Anwendung des Open-Source-Gedankens zu sein. Die Folie aus Abbildung 3 gibt einen guten Einblick, wie die verschiedenen Ebenen von Inner Source profitieren können [5]. Mehr Details dazu liefert Github auf seinen Inner-Source-Seiten [6].

Abbildung 3: Github betreibt seit vielen Jahren Inner Source und teilt seine Erfahrungen. Leadership Team, Management und Contributors könnten gleichermaßen profitieren.

Im deutschen Bereich hat sich vorrangig Prof. Dr. Dirk Riehle von der Friedrich-Alexander-Universität Nürnberg/Erlangen als Experte hervorgetan. Seit vielen Jahren versorgt der Open-Source-Professor sein Publikum in Vorträgen, Vorlesungen und Videos mit Wissen zum Thema [7]. Im Jahr 2016 hat er mit Maximilian Capraro zusammen den Technical Report “Definition, Benefits und Herausforderungen” [8] zu Inner Source in Unternehmen verfasst.

Fazit: Steil aufwärts

Das Marktforschungs- und Beratungsunternehmen Gartner hat Inner Source inzwischen ebenfalls entdeckt und schreibt dem Thema neuerdings großes Potenzial zu. Im Gartner Hype Cycle für das Software-Engineering von November 2023 [9] findet sich sogar ein eigener Eintrag dafür auf der linken, steil ansteigenden Seite der Hype-Kurve (Abbildung 4). 2023 rangierte es vor AI Engineering und DesignOps und knapp hinter Cloud- und Observability-Plattformen.

Abbildung 4: Links auf dem steil ansteigenden Ast der Hype-Kurve platzierte Gartner das Thema Inner Source (gelb hinterlegt) im Jahr 2023. Quelle: Gartner

Gartner bekommt zwar seine Daten nur aus tieferen Recherchen im Internet und Gesprächen mit Kunden, aber auch bei Google und Youtube finden sich erstaunlich viele gehaltvolle Beiträge aus den letzten Monaten zu Inner Source. Man darf also durchaus gespannt sein, wo das Thema 2024 landen wird. Avanciert es womöglich sogar zum Hype? (tsc/csi)