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.
Motivation 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. 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 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 Code-Hosting-Plattform.
Offene Zusammenarbeit 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 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 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 Neben den Qualitätsattributen, die Open-Source-Software verspricht, werden folgende Vorteile berichtet:
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 Unter anderem berichten die folgenden Unternehmen über den Einsatz von Inner Source: HP Philips Lucent Nokia IBM DTE Robert Bosch Google Microsoft SAP PayPal Capital One Amdocs Skyscanner Siemens
Schlüsselfaktoren für den Einsatz 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.
Produktfaktoren 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 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 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
Kategorie:Vorgehensmodell (Software) Kategorie:FLOSS-Kultur Kategorie:Projektmanagement