Inner Source

Inner Source (englisch inner source, auch firmeninterner Open Source) ist die Verwendung von etablierten Open-Source-Praktiken in der Softwareentwicklung sowie die Einführung einer Open-Source-artigen Kultur innerhalb eines Unternehmens. Der Begriff stammt von Tim O’Reilly aus dem Jahr 2000.^[1]

Motivation Bearbeiten

Unternehmen sind motiviert an Open-Source-Software zu arbeiten, da dies Innovation fördert und Open-Source-Software aufgrund des Mehraugenprinzips eine höhere Qualität und Zuverlässigkeit hat. Der ideologische Anspruch für freie Software ist hingegen bei Unternehmen weniger wichtig.^[2] Außerdem erweist sich die offene Zusammenarbeit in Open-Source-Projekten besonders geeignet, um Zusammenarbeit sogar zwischen direkten Konkurrenten (z. B. ARM und Intel am Linux-Kernel) funktional und meritokratisch zu gestalten. Softwarefirmen wollen diesen Erfolg nutzen: Einerseits durch die Nutzung von Open-Source-Tools oder -Software-Komponenten in ihren proprietären Software-Produkten, andererseits durch die Praktiken, die sich in der Open-Source-Welt etabliert haben.

Übernommene Open-Source-Praktiken Bearbeiten

Neben vielen Praktiken, die sich auch in Foundations wie der Apache Software Foundation, Linux Foundation oder Eclipse Foundation etabliert haben, ist für Open- wie Inner-Source-Projekte eine offene Zusammenarbeit und offene Kommunikation sowie eine funktionierende Qualitätssicherung notwendig. Ein wesentliches Werkzeug zur Realisierung dieser Transparenz ist die Verwendung einer zentralen Software-Forge.

Offene Zusammenarbeit Bearbeiten

Um sinnvoll und effektiv in Open-Source-Projekten zusammenarbeiten zu können, müssen alle nötigen Entwicklungsartefakte (z. B. Code, Dokumentation, Issue Tracker) allen zugänglich gemacht werden.

Offene Kommunikation Bearbeiten

Offene Kommunikation in Open-Source zeichnet sich dadurch aus, dass sie allgemein einsehbar, vollständig, archivierbar, asynchron und in schriftlicher Form stattfindet, um allen potentiellen Mitarbeitern die Möglichkeit der Interaktion zu geben. Dies wird oft durch Foren, Mailinglists oder ähnliche Tools umgesetzt.

Qualitätssicherung durch Trennung von Code-Beitrag und -Integration Bearbeiten

Mit Hilfe von dedizierten Reviews sowie der Unterscheidung zwischen Contributor (Code-Beitragender) und Committer (Integrator, Entwickler mit Schreibrechten) wird die Qualität in Open-Source-Projekten sichergestellt.

Nutzen Bearbeiten

Neben den Qualitätsattributen, die Open-Source-Software verspricht, werden folgende Vorteile berichtet:^[3]

Effizientere und effektivere Entwicklung

Kürzere Time-to-Market
Geringere Entwicklungskosten

Überwindung von Organisationsgrenzen

Aufteilung von Kosten und Risiken über Organisationseinheiten hinweg
Zusammenarbeit über Organisationsgrenzen hinweg
Programmweiter Informationsaustausch

Erfolgreichere Wiederverwendung

Nutzung von Kompetenz außerhalb von Organisationseinheiten
Entkopplung von Software-Komponentenanbietern und -wiederverwendern
Entlastung von Software-Komponentenanbietern

Bessere Software

Höhere Codequalität
Mehr Innovation

Höhere Flexibilität beim Einsatz von Entwicklern

Vereinfachter Einstieg in die Entwicklung für neue Entwickler
Vereinfachte Entwicklung von geographisch verteilten Entwicklern

Verbessertes Wissensmanagement

Gemeinschaftliches Lernen
Offenheit und Verfügbarkeit von Wissen

Höhere Mitarbeitermotivation

Verbreitung Bearbeiten

Unter anderem berichten die folgenden Unternehmen über den Einsatz von Inner Source:^[3]

Schlüsselfaktoren für den Einsatz Bearbeiten

Inner Source kann für große Unternehmen, die Software entwickeln, ein vielversprechender Ansatz sein. Es ist jedoch möglicherweise nicht in allen Facetten geeignet. Die folgenden neun Faktoren, eingeteilt die in drei Kategorien, können herangezogen werden, um zu beurteilen, inwieweit Inner Source geeignet sein könnte.^[6]

Produktfaktoren Bearbeiten

Produkt-Platzierung, um eine Community anzuziehen
Mehrere Stakeholder für eine Vielzahl von Kontributoren
Modularität zur Gewinnung von Mitwirkenden und Nutzern

Prozess- und Tool-Faktoren Bearbeiten

Praktiken, die die Entwicklung nach dem "Bazaar-style" unterstützen
Praktiken, die die Qualitätssicherung des "Bazaar-style" unterstützen
Standardisierung von Tools zur Erleichterung der Zusammenarbeit

Organizations- und Community-Faktoren Bearbeiten

Koordination und Führung zur Unterstützung der Entstehung einer internen Leistungsgesellschaft
Transparenz, um die Organisation zu öffnen
Managementunterstützung und Motivation, Menschen einzubeziehen

Einzelnachweise Bearbeiten

↑ Tim O'Reilly: Open Source and OpenGL - O'Reilly Media. In: archive.oreilly.com. Archiviert vom Original (nicht mehr online verfügbar) am 4. Januar 2017; abgerufen am 4. Januar 2017 (englisch).
↑ Kevin Crowston, Kangning Wei, James Howison, Andrea Wiggins: Free/Libre open-source software development: What we know and what we do not know. Hrsg.: ACM. Band 44, Nr. 2. ACM Computing Surveys, ISSN 0360-0300, doi:10.1145/2089125.2089127: „For example, Bonaccorsi and Rossi [2006] found that firms are motivated to be involved with FLOSS because it allows smaller firms to innovate, because “many eyes” assist them in software development, and because of the quality and reliability of FLOSS, with the ideological fight for free software at the bottom of the list.“
↑ ^a ^b Maximilian Capraro, Dirk Riehle: Inner Source Definition, Benefits, and Challenges. In: ACM (Hrsg.): ACM Computing Surveys. Band 49, Nr. 4. ACM, ISSN 0360-0300, doi:10.1145/2856821.
↑ Andy Oram: Getting Started with InnerSource. 1. Auflage. O’Reilly Media, Inc., ISBN 978-1-4919-3758-7.
↑ Watch: Creating an Inner Source Hub at Siemens. In: JFrog. 28. Juli 2020, abgerufen am 9. Dezember 2020 (amerikanisches Englisch).
↑ Klaas-Jan Stol, Paris Avgeriou, M. A. Babar, Yan Lucas, Brian Fitzgerald: Key factors for adopting inner source. 23. Auflage. ACM, 2014, S. 1, doi:10.1145/2533685.

[1] Tim O'Reilly: Open Source and OpenGL - O'Reilly Media. In: archive.oreilly.com. Archiviert vom Original (nicht mehr online verfügbar) am 4. Januar 2017; abgerufen am 4. Januar 2017 (englisch).

[2] Kevin Crowston, Kangning Wei, James Howison, Andrea Wiggins: Free/Libre open-source software development: What we know and what we do not know. Hrsg.: ACM. Band 44, Nr. 2. ACM Computing Surveys, ISSN 0360-0300, doi:10.1145/2089125.2089127: „For example, Bonaccorsi and Rossi [2006] found that firms are motivated to be involved with FLOSS because it allows smaller firms to innovate, because “many eyes” assist them in software development, and because of the quality and reliability of FLOSS, with the ideological fight for free software at the bottom of the list.“

[:0-3] Maximilian Capraro, Dirk Riehle: Inner Source Definition, Benefits, and Challenges. In: ACM (Hrsg.): ACM Computing Surveys. Band 49, Nr. 4. ACM, ISSN 0360-0300, doi:10.1145/2856821.

[4] Andy Oram: Getting Started with InnerSource. 1. Auflage. O’Reilly Media, Inc., ISBN 978-1-4919-3758-7.

[5] Watch: Creating an Inner Source Hub at Siemens. In: JFrog. 28. Juli 2020, abgerufen am 9. Dezember 2020 (amerikanisches Englisch).

[KeyFactors2014-6] Klaas-Jan Stol, Paris Avgeriou, M. A. Babar, Yan Lucas, Brian Fitzgerald: Key factors for adopting inner source. 23. Auflage. ACM, 2014, S. 1, doi:10.1145/2533685.

[1]

[2]

[3]

[4]

[5]

[6]