InnerSource ist eine Lüge - Eine Antwort auf häufige Missverständnisse
Wenn Sie auf YouTube nach “InnerSource” suchen, werden Sie wahrscheinlich als eines der ersten Ergebnisse ein Video finden, das behauptet, dass “InnerSource eine Lüge ist.”
(Link: https://youtube.com/shorts/53jEP3mPP3E)
Diese Sichtweise repräsentiert eine typische Falle, in die viele Menschen tappen, wenn sie zum ersten Mal von InnerSource erfahren.
Ich möchte dieses Video als Fallstudie verwenden, um zu erklären, welche Art von irreführenden Schlussfolgerungen es fördert. Das ist ein Fehler, den ich in der Vergangenheit auch gemacht habe, und es ist eine Falle, in die viele Menschen, die dieses Gebiet nicht tiefgreifend erforscht haben, leicht tappen können. Deshalb möchte ich dies mit Selbstreflexion untersuchen und anderen helfen, den richtigen Weg zu finden, indem ich diese Fallstricke entwirre.
Das erste Missverständnis: “Verwende React, damit andere beitragen können” #
Lassen Sie mich zunächst das Argument in diesem Fall entschlüsseln. Das Video schlägt vor, React für interne Anwendungen zu verwenden “Verwende React, weil andere Leute dazu beitragen können.” Diese Art von Argumentation wird selten in tatsächlichen InnerSource-Diskussionen gehört.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Dieses Argument kann in drei Hauptprobleme zerlegt werden:
- Grundlegendes Missverständnis dessen, was InnerSource tatsächlich bedeutet
- Wahl der falschen Domäne für die InnerSource-Anwendung
- Verwechslung von individueller versus Team-Perspektive
Was InnerSource tatsächlich bedeutet #
InnerSource bedeutet, Open-Source-Prinzipien innerhalb eines Unternehmens zu praktizieren. Es geht nicht nur um “Beiträge” oder “Beiträge erhalten.”
Die meisten Menschen, die mit Open Source interagieren, sind einfach “Nutzer.” Einige sind nur Konsumenten, andere reichen Fehlerberichte ein, und nur ein kleiner Bruchteil reicht tatsächlich Pull Requests ein. InnerSource wendet Open-Source-Erkenntnisse intern an, um Organisationen zu schaffen, die offen und breit zugänglich sind, mit transparenter Entscheidungsfindung und Teambeziehungen, die auf Vertrauen durch Eigenverantwortung und Mentoring aufgebaut sind. Dies schafft eine Kultur der Transparenz und Zusammenarbeit.
Das bedeutet “Open Source intern praktizieren” - es geht nicht nur darum, “Pull Requests zu erhalten.” Pull Requests sind lediglich ein Ergebnis dieser Kultur, nicht das primäre Ziel.
Eine weniger optimale Domäne für die InnerSource-Anwendung #
Das zweite Problem ist, dass sich dieses Argument in einer Domäne entfaltet, in der InnerSource und Open Source vor besonderen Herausforderungen stehen.
Wenn Sie “Pull Requests erhalten” oder “viele Menschen Ihren Code verwenden lassen möchten, um die Qualität zu verbessern”, könnte das durch die Natur Ihres Produkts begrenzt sein. Es ist klar, dass das Teilen von “Komponenten mit hohen Abhängigkeiten” oder Tools auf Plattformebene mehr Wert schaffen würde als Endbenutzeranwendungen. Während stream-ausgerichtete Teams dennoch Open-Source-Praktiken übernehmen sollten, wenn sie vorteilhaft sind, unterscheiden sich die Kollaborationsdynamiken erheblich.
In meiner Erfahrung mit Unternehmenskunden stellt die Verwendung von InnerSource für Projekte auf Projektebene, bei denen die Endnutzer “Nicht-Ingenieure” sind, einzigartige Herausforderungen dar. Warum? Weil diese Produkte letztendlich den Bedürfnissen von “Endnutzern” oder “Geschäftsnutzern” dienen müssen, denen möglicherweise Entwicklungsfähigkeiten und direkte Kommunikationskanäle mit Entwicklungsteams fehlen. Dies schafft komplexe, individualisierte Anforderungen und längere Kommunikationsvorlaufzeiten.
InnerSource-Implementierungen funktionieren tendenziell relativ gut, wenn sie auf gemeinsame Bibliotheken, Plattformkomponenten, Entwicklungstools und Infrastrukturcode angewendet werden - Bereiche, in denen die “Nutzer” hauptsächlich andere Entwickler sind, die sinnvoll zu kollaborativen Entwicklungspraktiken beitragen und davon profitieren können.
Während die Anwendung von InnerSource-Praktiken auf benutzerorientierte Anwendungen wertvolle Vorteile wie Transparenz und verbesserte Problemverfolgung bringen kann (was allein schon lohnenswert ist).
Individuelle vs. Team-Perspektive #
Das dritte Problem betrifft, ob sich “Sie” auf eine Einzelperson oder ein Team bezieht.
Es ist wichtig zu beachten, dass InnerSource nicht unbedingt darauf wartet, dass jemand zu “Ihrem persönlichen Projekt” innerhalb eines Unternehmens beiträgt. Wenn InnerSource angewendet wird, könnte es Fälle geben, in denen Menschen zu Projekten beitragen, die während 20% Zeit entwickelt wurden, wie bei großen Tech-Unternehmen, aber das ist nicht unbedingt der Mainstream-Ansatz.
InnerSource wird hauptsächlich eingeführt und aufrechterhalten, weil es ROI durch Kostensenkung, Vermeidung der Neuerfindung des Rades, Schaffung von Synergien, Qualitätssicherung und Beseitigung von Kommunikationsoverhead aus hierarchischer Entscheidungsfindung generiert. Dies betrifft typischerweise gemeinsame interne Bibliotheken, proprietäre Wettbewerbsvorteilskomponenten oder Dinge mit hohen Abhängigkeiten, die innerhalb des Unternehmens nischenhaft sind. Und diese “Geschäftsvorteile” fließen typischerweise zurück zu “Teamoperationen” in den meisten Fällen. Letztendlich geht es alles um ROI für Teams und Organisationen. Wenn wir nicht an Teams denken, wird jemand Sie daran hindern, zu Projekten beizutragen. Sie müssen Ihren ROI rechtfertigen, ob kurz- oder langfristig.
Was einzigartig an InnerSource ist, ist dass es grundsätzlich um Team-zu-Team-Kollaboration geht. Hier landen die meisten Implementierungen letztendlich. Es geht nicht unbedingt darum, dass Einzelpersonen zufällig zu bequemen persönlichen Projekten beitragen. Es wird typischerweise durch Host-Team- und Gast-Team-Beziehungen implementiert, bei denen Gast-Teams mit Teilen mitfahren, die von Host-Teams gepflegt werden. Die meisten Unternehmen haben Mitarbeiter mit definierten Rollen und Verantwortlichkeiten, und Kollaboration findet tendenziell innerhalb dieser Strukturen statt.
Daher ist InnerSource besonders effektiv, wenn Beziehungen zwischen Plattform-Teams und stream-ausgerichteten Teams (Gast-Teams und Host-Teams) etabliert sind. Aktive Co-Kreation zwischen stream-ausgerichteten Teams oder Einzelpersonen ist ungewisser, natürlich erfolgreich zu sein.
Die gesamte InnerSource basierend auf Szenarien zu kritisieren, die unwahrscheinlich funktionieren, macht keinen logischen Sinn.
Das zweite Missverständnis: “Es passiert nie in echten Unternehmen” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
Tatsächlich passiert das. Fallstudien beweisen es. Punkt.
Das dritte Missverständnis: “99,69% der InnerSource-Projekte werden scheitern” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Das könnte korrekt sein, je nachdem, wie Sie “InnerSource” definieren. Wie bereits erwähnt, geht es bei InnerSource nicht darum, “PR-Beiträge zu erhalten.”
Es gibt jedoch drei wichtige Punkte zu beachten:
- InnerSource gilt besonders für strategische Komponenten - es ist nicht für alle Komponenten erforderlich
- Vorteile erstrecken sich über aktive Beiträge hinaus
- Open Source hat das gleiche “Ausfallraten”-Problem
InnerSource ist eine Unternehmensstrategie #
Wenn Menschen an InnerSource denken, stellen sie sich manchmal radikale Ideen vor wie “allen Code innerhalb des Unternehmens teilen” oder “jeder trägt zu allem bei.” Sie könnten sich Hunderte von geteilten Repositories innerhalb eines Unternehmens vorstellen, bei denen jeder aktiv Beiträge austauscht. Wie Open Source eine Strategie für Unternehmen ist, ist InnerSource auch eine Unternehmensstrategie mit Prioritäten. Unternehmen teilen zuerst “was es wert ist, geteilt zu werden.”
Daher ist die tatsächliche Anzahl von Codebasen, bei denen Code aktiv zwischen Teams fließt und lebendige teamübergreifende Kollaboration stattfindet, relativ klein. Das könnten tatsächlich einstellige Prozentsätze sein. Jedoch können auch ohne aktive teamübergreifende Kollaboration viele Projekte davon profitieren, offen und transparent zu sein. In diesem Sinne von InnerSource können Unternehmen oft Wert über viel mehr Fälle hinweg teilen.
Während InnerSource individuelle Beiträge einschließt, konzentriert es sich hauptsächlich auf Team-zu-Team-Kollaboration. Daher tendiert das, was durch InnerSource geteilt wird, dazu, relativ nischenhaft innerhalb von Unternehmen zu sein, oder zweckspezifische Artikel wie geforkelte Linux-Distributionen für bestimmte Bedürfnisse. Oder es könnte einfach Open-Source-ähnliche Entwicklungskultur sein, wie wenn GitHub Ruby on Rails-Code über alle Mitarbeiter hinweg teilt.
Wenn wir diese Prozentsatzdiskussion auf InnerSource konditionieren, das aktiv kollaboriert und als gemeinsame Anforderungen gepflegt wird, könnte der Prozentsatz tatsächlich relativ niedrig sein. Jedoch passieren kleine Kollaborationen wie Dokumentations-Pull-Requests oder kleinere Konfigurationsänderungen (kleine Patches senden) zwischen Gast-Teams und Plattform-/Host-Teams relativ häufig. Wenn Sie diese Mikro-Kollaborationen und Transparenzvorteile einbeziehen, die doppelte Anstrengungen verhindern, steigen diese Zahlen erheblich.
Open Source hat das gleiche “Problem” #
Andererseits, wenn wir es so definieren, wäre Open Source auch eine “Lüge.” Weil “99,69% der Open-Source-Projekte scheitern werden.” Der meiste Code, der als Open Source veröffentlicht wird, erhält keine Beiträge. Aber niemand sagt “Open Source ist eine Lüge” deswegen. Menschen verfolgen Open Source, weil es Vorteile jenseits des Erhaltens von Beiträgen gibt.
Wieder ist “beigetragen zu werden” nicht der einzige Wert von InnerSource. Und dasselbe gilt auch für den Open-Source-Wert.
Die wahren Vorteile der Transparenz #
Internen Code offen statt versteckt zu halten - bei GitHub könnten Architekten oder Solution Engineers im Revenue-Team in der Lage sein, Quellcode zu untersuchen, um relevante Informationen zu finden, möglicherweise Details sehr nah an Kundenanfragen zu finden, reibungslosere Support-Gespräche zu ermöglichen und genauere Informationen aus Issues zu extrahieren. Ich lebe in Tokio, und manchmal ist es schneller, einfach Ruby-Code anzuschauen, um die Implementierung zu überprüfen, oder zu Issues zu gehen, um den Hintergrund der Änderungen zu überprüfen, anstatt darauf zu warten, dass das SF-basierte Produktteam aufwacht, um Implementierungsfragen über die Änderungen und ihren Hintergrund zu stellen.
Mit dem git blame-Befehl können Sie die “echten” Stakeholder des Codes identifizieren und Fragen über den Hintergrund von Entscheidungen stellen.
Unnötig zu sagen, dasselbe gilt für andere Entwicklungsteams. Informationen über Komponenten, die möglicherweise Abhängigkeiten schaffen, leicht verfügbar zu haben, reduziert eindeutig den Kommunikationsoverhead.
InnerSource bedeutet, Open-Source-Prinzipien intern zu praktizieren. InnerSource geht nicht nur darum, Pull Requests hin und her zu senden - es geht darum, Transparenz zu gewährleisten und Vorteile durch Open-Source-ähnliche Kollaboration zu gewinnen. Diese Vorteile erstrecken sich weit über die wenigen Prozent aktiv gepflegter Repositories hinaus auf breitere kulturelle Implementierungsvorteile.
Das vierte Missverständnis: “Sie werden zurückgerufen, wenn Sie gehen” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Ressourcen bleiben manchmal ungepflegt, aber das ist keine angemessene Kritik an InnerSource selbst - es ist Kritik daran, InnerSource nicht ordnungsgemäß zu implementieren. Das ist keine Kritik an InnerSource, sondern Kritik an mangelnder Wartungskultur, bei der niemand den Code wartet. Das resultiert daraus, InnerSource nicht ordnungsgemäß zu implementieren oder es überhaupt nicht zu berücksichtigen - das Ergebnis mangelnder Eigenverantwortung.
Die DevOps-Analogie #
Das ist Kritik daran, InnerSource nicht zu machen, nicht Kritik an InnerSource selbst. Manchmal verwirrt das die Logik. Um das in DevOps-Begriffen auszudrücken: es ist wie zu sagen “Unternehmen übernehmen am Ende langsame Review-Zyklen von mehreren Monaten oder Audits, oder fügen Prozesse für Release-Entscheidungen hinzu, sodass Releases vierteljährlich oder nur zweimal im Jahr werden. Daher ist DevOps, das behauptet, schnelle Releases zu ermöglichen, nicht gut.” Das liegt nicht daran, dass die DevOps-Methodologie schlecht ist, sondern einfach daran, dass “es Fälle gab, in denen DevOps nicht implementiert werden konnte.”
Geschäftsprozesse zu durchbrechen ist extrem schwierig, und viele Unternehmen sagten, DevOps sei unmöglich. Aber selbst als Menschen dachten, es sei unmöglich, gab es mutige Pioniere, die hart daran arbeiteten, die Kultur zu ändern und DevOps erreichten. Dasselbe kann mit InnerSource passieren.
Das fünfte Missverständnis: “Sie müssen alles zu 100% besitzen” #
you own it 100% (was impliziert: InnerSource, bei dem Sie nicht 100% besitzen, ist unmöglich)
“InnerSource bedeutet, Code-Eigenverantwortung aufzugeben” ist falsch. InnerSource erfordert tatsächlich, dass Teams Code besitzen. Das ist ein häufiger Fehler. Das ist wie Menschen, die Wartungsverantwortung aufgeben wollen und sagen “lassen Sie es uns Open Source machen.” Das funktioniert nicht.
Individuelle vs. Team-Eigenverantwortung - Ist InnerSource starke Code-Eigenverantwortung? #
Erstens, ist dieses “Sie” singular oder plural? Obwohl Einzelpersonen möglicherweise als CODEOWNERS-Datei in Organisationen aufgelistet sind, halten Teams letztendlich die Verantwortung für Code. Kontextuell spricht es wahrscheinlich über Strong Code Ownership. Aber das ist nicht gut, wenn man organisatorische Wartung betrachtet. Weil Mitarbeiter kündigen könnten.
InnerSource ist nicht Strong Code Ownership. Mindestens müssen mehrere Menschen die Verantwortung teilen. Dennoch erkenne ich an, dass Strong Code Ownership kurzfristig entstehen kann, und in den frühen Phasen eines Projekts könnte starker individueller Wille natürlich zu solchen Arrangements führen, aber wenn Sie langfristigen Erfolg erreichen wollen, ist es notwendig, Autorität zu delegieren, damit die Organisation die Wartung kollektiv handhaben kann.
Arten der Team-Eigenverantwortung - Ist InnerSource kollektive Code-Eigenverantwortung? #
Diese Art von Argument könnte sich manchmal auf Collective Ownership beziehen. In diesem Fall scheint das Argument auch zu suggerieren, dass InnerSource kollektive Eigenverantwortung bedeutet, aber das ist tatsächlich anders. InnerSource ist nicht Collective Code Ownership InnerSource beinhaltet Host-Teams, die letztendlich die Wartung handhaben. InnerSource ist Weak Code Ownership. Also während Wartungsverantwortung zu 100% korrekt ist, zu sagen “Sie müssen 100% besitzen und InnerSource ist anders” ist völlig unlogisch. Das ist tatsächlich eine falsche Meinung.
Wie Martin Fowler berühmt über Code-Eigenverantwortung argumentierte, schafft es manchmal Situationen, in denen niemand Verantwortung übernimmt, wenn jeder Code zu 100% besitzt (kollektive Eigenverantwortung). Das ist sehr problematisch - Verantwortung wird unklar und Projekte scheitern letztendlich.
Weak Code Ownership Modell #
In Weak Code Ownership existieren Maintainer, Host-Teams warten Projekte, und spezifische Teile könnten vertrauenswürdige Committer/Maintainer von anderen Teams einbringen. Jemand könnte beitragen, jemand könnte warten, aber nicht 100% von “Ihnen” oder “Ihrem Team” - es könnte ganz anders sein. Zum Beispiel könnten 98% des Codes von Ihrem Team besessen werden, während 2% von anderen Teams besessen werden könnten.
In diesem Fall denken Sie daran, dass auch wenn Einzelpersonen als Code-Besitzer in Organisationen zugewiesen sind, Teams letztendlich die Verantwortung für Code halten. Teams sollten es besitzen, und vergessen Sie diesen wichtigen Punkt nicht.
Das sechste Missverständnis: “Jemand wird Ihnen 7000 Zeilen vor die Füße werfen” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Dass plötzlich 7000-Zeilen-Pull-Requests auftauchen, ist selbst ein Versagen bei der Einführung der InnerSource-Kultur - es ist nicht etwas, das durch InnerSource passiert. Dieser Fall könnte befürchten, dass die Einführung von InnerSource solche Kollaboration geschehen lässt, aber das ist völlig falsch.
Das wahre Problem #
Dieses Argument repräsentiert das Versagen, InnerSource-Kultur und kollaborative Praktiken zu implementieren, nicht InnerSource selbst. 7000-Zeilen-Implementierungen sind sehr begrenzte Fälle. Das repräsentiert das Versagen der Kollaborationskultur, bei der 7000 Zeilen plötzlich als Pull Requests ohne jede Benachrichtigung eingereicht werden - die Organisation sollte dieses grundlegende Kulturproblem beheben, das vor-InnerSource ist.
Wenn Sie das verhindern wollen, gibt es eine Lösung. Fördern Sie InnerSource-Kultur innerhalb Ihrer Organisation:)
Die Realität: Was InnerSource tatsächlich ist #
InnerSource ist kulturelle Implementierung - die Verwendung von Open-Source-Kollaborationspraktiken, um verschiedene Vorteile zu genießen, die Open Source durch Kollaboration erhält. InnerSources ultimativer Zweck ist nicht nur das Erhalten von Beiträgen (Pull Requests), sondern schließt Feature-Requests durch Issues, Support-Koordination und verschiedene andere Vorteile ein, plus Transparenz in der Entscheidungsfindung und praktische kulturelle Förderung.
Daher lehne ich definitiv die Behauptung ab, dass “die Implementierung von InnerSource-Best-Practices, um Pull Requests zu bekommen, eine Lüge ist.”
Beitragsrealität verstehen #
“Nobody ever is going to contribute”
In der Open-Source-Kollaboration sind Beitragende tatsächlich ein winziger Bruchteil. Von 1000 Nutzern sind vielleicht die große Mehrheit nur Nutzer, 20 könnten Issues oder Feature-Requests einreichen, 5 könnten Pull Requests senden, und vielleicht nur einer wird ein Maintainer.
Wieder werden InnerSource-Best-Practices nicht alle 1000 Menschen zum Beitragen bringen. InnerSource hilft dabei, solche Kollaboration zu induzieren, aber zielt letztendlich darauf ab, Unternehmenssilos aufzubrechen, Kollaboration zu verbessern, die durch traditionelle organisatorische Beschränkungen behindert wird, Vorlaufzeiten von Informationssilos zu reduzieren und organisatorische Ressourcenallokation unter Verwendung von Open-Source-Praktiken zu optimieren.
Fazit #
Während die Argumente in diesem Fall einige reale Herausforderungen berühren, basieren sie auf häufigen Missverständnissen, denen viele Menschen begegnen, wenn sie zum ersten Mal von InnerSource erfahren. Das sind bekannte Fallstricke in der Community, und es ist verständlich, wie jemand zu diesen Schlussfolgerungen kommen könnte, ohne tiefere Erforschung des Gebiets.
Die Schlüsselerkenntnis ist, dass InnerSource nicht darum geht, Open-Source-Praktiken in einen starren Rahmen zu zwingen. Stattdessen geht es darum, zur grundlegenden Frage zurückzukehren: was können wir von Open Source lernen? Indem wir Open Source durch eine breitere Linse betrachten, können wir diese Prinzipien besser intern anpassen.
Sie können sich an dieser Unterhaltung beteiligen und frische Perspektiven einbringen. Ob Sie auf dieser Diskussion aufbauen, spezifischere Implementierungsdetails erforschen oder sogar diese Argumente völlig herausfordern wollen - alle Ansätze sind willkommen. Was am wichtigsten ist, ist die Aufrechterhaltung dieser breiten Perspektive auf Open-Source-Erkenntnisse und wie sie sich in interne organisatorische Kontexte übersetzen.
Für umfassende Informationen über InnerSource empfehle ich, die InnerSource Commons Foundation zu besuchen. Sie begrüßen diverse Standpunkte und fortlaufenden Dialog darüber, wie Open-Source-Prinzipien Wert innerhalb von Organisationen schaffen können.
