Was es bedeutet, InnerSource zu definieren
Die Frage #
Menschen fragen mich häufig, was die Definition von InnerSource ist. Was ist also InnerSource? Ich möchte einige Gedanken über InnerSource und was es für mich bedeutet teilen.
Lassen Sie mich von Anfang an klarstellen: Das sind meine persönlichen Meinungen, nicht eine offizielle Position. Obwohl ich derzeit als Präsident der InnerSource Commons Foundation fungiere, wurde InnerSource von vielen Pionieren geprägt, die ich zutiefst respektiere. Ihre Beiträge haben das aufgebaut, was InnerSource heute ist.
Das Fundament von InnerSource entsteht durch die Verflechtung von Unternehmenspraktiken, akademischer Forschung und natürlich der Evolution von Open Source selbst. Angesichts dieses reichen Geflechts wäre es anmaßend von mir zu behaupten, InnerSource persönlich zu definieren. Nur weil ich derzeit als Präsident fungiere, bedeutet das nicht, dass ich die Autorität oder Weisheit habe, diese Definition allein zu erstellen.
Anstatt eine einzige definitive Antwort zu geben, möchte ich verschiedene Perspektiven zu dieser Frage teilen und Standpunkte anbieten, die Ihnen helfen könnten, Ihre eigene Definition und Ihr Verständnis davon zu entdecken, was InnerSource für Ihren Kontext bedeutet.
Die zwei Wege zu InnerSource #
Wir befinden uns an einem interessanten Wendepunkt. Lassen Sie mich expliziter erklären, was ich meine. Es gibt im Wesentlichen zwei Arten von Menschen, die heute zu InnerSource kommen:
Die erste Gruppe besteht aus denen, die Open Source praktiziert haben, dessen kollaborative Methoden als kraftvoll empfanden und diese Prinzipien natürlich intern anwendeten. Für sie war InnerSource einfach ein Name, der etwas bezeichnete, was sie bereits taten—die Exzellenz der Open-Source-Zusammenarbeit in ihre Organisationen zu bringen.
Die zweite Gruppe entdeckte InnerSource als benannte Methodologie. Sie haben möglicherweise keinen umfangreichen Open-Source-Hintergrund, aber sie erkennen, dass InnerSource als organisatorische Methodologie enormen Wert für die Transformation bietet. Sie übernehmen InnerSource nicht, weil sie Open-Source-Praktiker waren, sondern weil InnerSource selbst organisatorische Vorteile verspricht.
Diese Dualität schafft faszinierende Möglichkeiten in unserer Gemeinschaft. Die erste Gruppe versteht intuitiv, was es bedeutet, InnerSource innerhalb einer Organisation zu implementieren, sowie den Wert und die Kultur von InnerSource und Open Source. Daher mögen sie darüber nachdenken, wie InnerSource definiert werden sollte und denken darüber im Rahmen von Open Source nach. Andererseits hat die zweite Gruppe nicht unbedingt eine Beteiligung an Open Source, daher neigen sie dazu, klarere Vorstellungen darüber zu suchen, was es tatsächlich ist.
Von DevOps lernen: Die Macht der Benennung #
Um InnerSources Definitionsherausforderung zu verstehen, schauen wir uns DevOps an. So verstehe ich seine Evolution: Praktiker bei Unternehmen wie Flickr taten etwas Innovatives—sie brachen Silos zwischen Entwicklung und Betrieb auf. Als sie ihre Erfahrungen teilten und jemand dem einen Namen gab—“DevOps”—geschah etwas Magisches. Plötzlich erkannten Unternehmen überall, dass sie ähnliche Dinge taten, und sie alle begannen, ihre Geschichten zu teilen.
Die Schlüsselerkenntnis ist diese: Die Praxis existierte vor dem Namen, aber die Benennung schuf Gemeinschaft. Mit dieser Gemeinschaft kamen Werkzeuge, geteilte Konzepte, Konferenzen und explosives Wachstum. DevOps wurde nicht erfunden; es wurde entdeckt und benannt. Die Benennung katalysierte alles andere.
InnerSource folgt einem bemerkenswert ähnlichen Muster. Tim O’Reilly erwähnte es in einem Blog-Post im Jahr 2000. 2015 formalisierten Danese Cooper und Kollegen, damals bei PayPal, die InnerSource Commons und gründeten später eine Stiftung. Aber sie erfanden die Praxis nicht—sie benannten etwas, was Menschen bereits taten.
Diese Benennung war magisch. Plötzlich erkannten isolierte Praktiker, dass sie nicht allein waren. “Oh, das Ding, das wir mit unseren internen Bibliotheken machen? Das ist InnerSource!” Die Gemeinschaft explodierte mit Musteraustausch, was zu Ressourcen wie InnerSource Patterns führte, die kollektive Weisheit erfassen.
Was ist DevOps heute? Eine Perspektive unter vielen #
Menschen definieren DevOps auf unzählige Weise, und ich kann unmöglich alle abdecken. Hier ist ein Beispiel, wie es verstanden werden könnte:
- Eine Kultur der Zusammenarbeit zwischen traditionell getrennten Teams
- Ein Set von Praktiken und Automatisierungswerkzeugen
- Eine Philosophie, die sich der traditionellen Wasserfallentwicklung widersetzt
- Eine Sammlung von Methodologien und Frameworks
- Erweiterungen in spezialisierte Bereiche: BizDevOps, DevSecOps und darüber hinaus
Das ist nur eine Interpretation. Fragen Sie zehn Praktiker, und Sie erhalten zehn verschiedene Schwerpunkte. Diese Vielfalt ist keine Schwäche—sie ist evolutionäre Stärke.
Die vielfältigen Bedeutungen von “Internal Open Source” #
Der Ausdruck “internal open source” scheint paradox, und dieses Paradox zeigt, warum InnerSource für verschiedene Organisationen verschiedene Dinge bedeutet. Lassen Sie mich einige repräsentative Beispiele teilen, die aus unseren Gemeinschaftsdiskussionen entstanden sind:
InnerSource als Weg zur Open-Source-Reife #
Für einige öffnet InnerSource einen organischen Weg zur Open-Source-Teilnahme und digitalen Transformation. Es geht nicht nur darum, sich auf eventuelle Open-Source-Beiträge vorzubereiten—es geht darum, ein Umfeld zu schaffen, in dem die Organisation zu einem echten Softwareunternehmen heranwachsen kann. Unternehmen wie Microsoft und Google veranschaulichen diese Reise, wo interne Praktiken natürlich evolvieren, um externe zu spiegeln, und nahtlose Zusammenarbeit sowohl innerhalb als auch außerhalb des Unternehmens schaffen.
Aber was ist mit Fertigungsunternehmen, Einzelhändlern oder Finanzinstitutionen? Während sie möglicherweise massive Mengen an Open Source verwenden, ist ihre Reise anders. Für sie könnte InnerSource der erste Schritt in einer längeren Transformation sein—Softwarefähigkeiten aufbauen, Innovationskultur fördern und vielleicht schließlich ihren eigenen einzigartigen Weg finden, sich mit Open Source zu beschäftigen, der mit ihrem Geschäftsmodell übereinstimmt.
InnerSource als organisatorische Transparenz #
Viele werden von InnerSource für kulturelle Transformation angezogen. Es geht nicht nur darum, Pull Requests zu senden—obwohl das Teil davon ist. Es geht darum, organische Transparenz zu schaffen, wo Sie:
- Feature-Requests an andere Teams senden können
- Sehen können, was benachbarte Teams bauen
- Die breitere organisatorische Technologielandschaft verstehen
- Silos aufbrechen, die Zusammenarbeit verhindern
- Eine offenere, atmungsaktivere Organisationskultur schaffen, wo Informationen natürlich fließen
Diese Transparenz transformiert Organisationen von starren Hierarchien in lebende Netzwerke der Zusammenarbeit.
Letztendlich tragen diese zum Glück und Wohlbefinden von Ingenieuren, Produktteams und allen Beteiligten innerhalb der Organisation bei. Sich in einer unterstützenden Arbeitsumgebung vertrauenswürdig zu fühlen—standardmäßig vertraut zu werden—ist unglaublich wichtig. Das bezieht sich auf die Entwicklererfahrung und führt folglich zu verbesserter Talentbindung und liefert gleichzeitig positive Ergebnisse für die Rekrutierung.
InnerSource als Ressourcenoptimierung #
Traditionelles hierarchisches Projektmanagement fügt auf jeder Ebene Margen hinzu. Anforderungen fließen nach unten, jede Schicht fügt Pufferzeit für Unsicherheit hinzu. Bis die Arbeit die Implementierung erreicht, sind Zeitpläne aufgebläht und Ingenieure unter Druck.
InnerSource kehrt das um. Die Menschen, die Problemen am nächsten sind, verstehen sie am besten. Sie können Probleme priorisieren, diskutieren und lösen, ohne kaskadierende Meetings und Genehmigungen. Das ist nicht immer richtig—Feldteams kennen nur ihr Feld—aber wenn es mit strategischer Aufsicht ausbalanciert wird, ist es kraftvoll.
Aber Ressourcenoptimierung geht über menschliche und Team-Ressourcen hinaus. Es geht auch darum, die Code-Assets, das geistige Eigentum und die Wettbewerbsvorteile der Organisation zu nutzen. Wenn Teams die Werkzeuge, Bibliotheken und das Wissen der anderen teilen und darauf aufbauen können, schaffen sie Synergien, die in isolierten Strukturen nicht existieren würden. Diese interne Machine-Learning-Bibliothek, die Ihr Team gebaut hat? Ein anderes Team könnte sie auf Weise erweitern, die Sie sich nie vorgestellt haben. Das Test-Framework, das Ihnen Wettbewerbsvorteile gab? Es intern zu teilen multipliziert seinen Wert über die Organisation hinweg. InnerSource hilft Organisationen zu erkennen, dass ihre Code- und Wissens-Assets Ressourcen sind, die wertvoller werden, wenn sie geteilt und nicht gehortet werden.
Das Definitionsdilemma: Kontext ist alles #
Diese Herausforderung vielfältiger Bedeutungen ist nicht einzigartig für InnerSource. Betrachten Sie, wie Open Source Program Office (OSPO) Befürworter Open Source intern fördern. Sie verwenden absolut unterschiedliche Botschaften für verschiedene Zielgruppen, weil jede Aktivität Buy-in von verschiedenen Stakeholdern benötigt, und jede Ebene der Organisation hat verschiedene Interessen und Bedenken.
Für InnerSource-Befürwortung könnte die Botschaft etwa so aussehen:
An Ingenieure: “Arbeiten Sie mit brillanten Kollegen zusammen, lernen Sie vom besten Code, tragen Sie zu aufregenden Projekten jenseits Ihres unmittelbaren Teams bei”
An mittleres Management: “Reduzieren Sie Duplikation, erhöhen Sie Effizienz, beschleunigen Sie Lieferung durch Wiederverwendung und Zusammenarbeit”
An Führungskräfte: “Reduzieren Sie Kosten, erhöhen Sie Innovationsgeschwindigkeit und behalten Sie Top-Talente”
Die gleiche InnerSource-Initiative dient all diesen Zielen gleichzeitig, aber Sie betonen verschiedene Aspekte für verschiedene Zielgruppen. Das ist keine Täuschung—es ist die Anerkennung, dass InnerSource, wie jede transformative Methodologie, Wert auf mehreren Ebenen liefert.
Ihre InnerSource-Definition ist nicht nur zielgruppenabhängig—sie ist phasenabhängig. Und das ist völlig in Ordnung.
Ihre InnerSource-Reise: Eine sich entwickelnde Definition #
Was ist also InnerSource? Es ist das, was Sie es definieren.
Vielleicht wird die InnerSource Commons Foundation in der Zukunft eine klarere, kommunizierbarere Definition entwickeln, die sofort offensichtlich macht, was InnerSource ist. Persönlich freue ich mich auf diesen Tag, obwohl ich anerkenne, dass die Erstellung einer solchen Definition inmitten solcher Vielfalt eine unglaublich schwierige Aufgabe ist.
Darüber hinaus kann und sollte sich Ihre Definition entwickeln. Das InnerSource, das Ihnen hilft, Ihre Reise zu beginnen, könnte sich von dem InnerSource unterscheiden, das Sie drei Jahre später praktizieren. Ihre Definition könnte sich verschieben, wenn Ihre Organisation reift, wenn sich Ihre Herausforderungen ändern, wenn sich Ihr Verständnis vertieft.
Sie können Ihre Definition in die Gemeinschaft bringen, Ihre Perspektive teilen und uns allen helfen, diese Fragen gemeinsam zu durchdenken. Diese kollektive Erkundung ist, wie wir schließlich zu geteiltem Verständnis gelangen werden—nicht durch Top-down-Dekret, sondern durch kollaborative Entdeckung.
Ein Aufruf zum Handeln #
Anstatt die perfekte Definition zu suchen, ermutige ich Sie, InnerSource zu erleben:
- Reichen Sie ein Issue ein, das ein Problem beschreibt, das Sie sehen
- Senden Sie einen Pull Request, der Dokumentation repariert
- Fordern Sie ein Feature von einem anderen Team an
- Teilen Sie Ihren Code mit Kollegen
- Erkunden Sie, was andere Teams bauen
- Arbeiten Sie über Organisationsgrenzen hinweg zusammen
Durch die Praxis werden Sie entdecken, was InnerSource für Ihre Organisation bedeutet. Sie könnten sogar neue Muster erfinden, von denen der Rest von uns lernen kann.
Treten Sie der Unterhaltung bei #
2025, während KI transformiert, wie wir Code schreiben und daran zusammenarbeiten, werden InnerSource-Prinzipien noch relevanter. Wie erhalten wir Qualität aufrecht, wenn KI sofort Tausende von Zeilen generieren kann? Wie bewahren wir Wissensaustausch, wenn Code-Erstellung automatisiert ist? Wie stellen wir sicher, dass menschliches Urteilsvermögen zentral für Softwareentwicklung bleibt?
Für dieses Thema verweisen Sie bitte auf den Artikel, der Kollaborationsmethodologie im KI-Zeitalter behandelt.
Nun, diese Fragen haben noch keine Antworten, aber ich glaube, dass InnerSource—mit seiner Betonung auf Offenheit, Transparenz, priorisiertem Mentoring und freiwilligen Code-Beiträgen—einzigartig positioniert ist, sie zu erkunden.
InnerSource hat viele Geschmacksrichtungen. Sie können Ihre eigene hinzufügen. Sie können Muster benennen, die existieren, aber noch nicht artikuliert wurden. Deshalb ist InnerSource aufregend: Es ist ein Banner, unter dem eine Gemeinschaft wächst, sich entwickelt und Innovation verbreitet.
Die InnerSource Commons Foundation begrüßt diese Diskussionen. Unsere Gemeinschaftsmitglieder erkunden diese Fragen täglich, teilen Erfahrungen und bauen die Zukunft interner Zusammenarbeit.
Also frage ich Sie: Was ist Ihr InnerSource? Wie werden Sie es für Ihre Organisation definieren? Welche Muster werden Sie entdecken und teilen?
Lassen Sie uns diese Fragen gemeinsam erkunden. Die Reise beginnt gerade erst. Ich freue mich darauf, Sie in der Unterhaltung bei innersourcecommons.org willkommen zu heißen.
