InnerSource est un mensonge - Une réponse aux idées fausses courantes
Quand vous recherchez « InnerSource » sur YouTube, l’un des premiers résultats que vous rencontrerez probablement est une vidéo prétendant qu’« InnerSource est un mensonge ».
(lien : https://youtube.com/shorts/53jEP3mPP3E)
Ce point de vue représente un piège typique dans lequel beaucoup de personnes tombent quand elles découvrent InnerSource pour la première fois.
Je veux utiliser cette vidéo comme étude de cas pour expliquer quel type de conclusions trompeuses elle promeut. C’est une erreur que j’ai faite par le passé également, et c’est un piège dans lequel beaucoup de personnes qui n’ont pas exploré ce domaine en profondeur peuvent facilement tomber. C’est pourquoi je veux examiner cela avec auto-réflexion et aider les autres à trouver le bon chemin en démêlant ces pièges.
La première idée fausse : « Utilisez React pour que d’autres puissent contribuer » #
Permettez-moi d’abord de décortiquer l’argument dans ce cas. La vidéo suggère d’utiliser React pour les applications internes « Utilisez React parce que d’autres personnes peuvent y contribuer ». Ce type de raisonnement est rarement entendu dans les discussions réelles sur InnerSource.
devriez-vous utiliser react HTMX ou solid ou quelque chose pour l’application interne de votre entreprise maintenant beaucoup de gens ce que vous allez entendre c’est utilisez react pour que d’autres personnes puissent contribuer à cela
Cet argument peut être décomposé en trois problèmes clés :
- Malentendu fondamental de ce qu’InnerSource signifie réellement
- Choisir le mauvais domaine pour l’application d’InnerSource
- Confondre les perspectives individuelles et d’équipe
Ce qu’InnerSource signifie réellement #
InnerSource consiste à pratiquer les principes de l’open source au sein d’une entreprise. Ce n’est pas seulement une question de « contribuer » ou de « recevoir des contributions ».
La plupart des personnes qui interagissent avec l’open source sont simplement des « utilisateurs ». Certains ne sont que des consommateurs, d’autres soumettent des rapports de bugs, et seule une petite fraction soumet réellement des pull requests. InnerSource applique les apprentissages de l’open source en interne pour créer des organisations qui sont ouvertes, largement accessibles, avec une prise de décision transparente, et des relations d’équipe construites sur la confiance à travers la propriété et le mentorat. Cela crée une culture de transparence et de collaboration.
C’est ce que signifie « pratiquer l’open source en interne » - ce n’est pas seulement « recevoir des pull requests ». Les pull requests ne sont qu’un résultat de cette culture, pas l’objectif principal.
Un domaine moins optimal pour l’application d’InnerSource #
Le deuxième problème est que cet argument se déroule dans un domaine où InnerSource et l’open source font face à des défis particuliers.
Si vous voulez « recevoir des pull requests » ou « avoir beaucoup de personnes utilisant votre code pour améliorer la qualité », cela pourrait être limité par la nature de votre produit. Il est clair que partager des « composants à haute dépendance » ou des outils au niveau de la plateforme créerait plus de valeur que les applications destinées aux utilisateurs finaux. Bien que les équipes alignées sur les flux doivent encore adopter les pratiques open source quand c’est bénéfique, les dynamiques de collaboration diffèrent significativement.
Dans mon expérience de travail avec des entreprises, utiliser InnerSource pour des initiatives au niveau projet où les utilisateurs finaux sont des « non-ingénieurs » présente des défis uniques. Pourquoi ? Parce qu’ultimement, ces produits doivent servir les besoins des « utilisateurs finaux » ou « utilisateurs métier » qui peuvent manquer de compétences de développement et de canaux de communication directs avec les équipes de développement. Cela crée des exigences complexes et individualisées et des délais de communication plus longs.
Les implémentations d’InnerSource tendent à fonctionner relativement bien quand elles sont appliquées aux bibliothèques partagées, composants de plateforme, outils de développement, et code d’infrastructure—des domaines où les « utilisateurs » sont principalement d’autres développeurs qui peuvent contribuer de manière significative et bénéficier des pratiques de développement collaboratif.
Bien qu’appliquer les pratiques InnerSource aux applications destinées aux utilisateurs peut apporter des bénéfices précieux comme la transparence et un meilleur suivi des problèmes (ce qui seul rend cela valable).
Perspective individuelle vs. d’équipe #
Le troisième problème concerne si « vous » fait référence à un individu ou à une équipe.
Il est important de noter qu’InnerSource ne consiste pas nécessairement à attendre que quelqu’un contribue à « votre projet personnel » au sein d’une entreprise. Quand InnerSource est appliqué, il pourrait y avoir des cas où les gens contribuent à des projets développés pendant les 20% de temps, comme les grandes entreprises technologiques, mais ce n’est pas nécessairement l’approche principale.
InnerSource est principalement introduit et maintenu parce qu’il génère du ROI à travers la réduction des coûts, évitant de réinventer la roue, créant des synergies, l’assurance qualité, et supprimant les frais généraux de communication de la prise de décision hiérarchique. Cela implique typiquement des bibliothèques internes partagées, des composants d’avantage concurrentiel propriétaires, ou des choses avec de hautes dépendances qui sont de niche au sein de l’entreprise. Et ces « bénéfices métier » retournent typiquement aux « opérations d’équipe » dans la plupart des cas. Ultimement, tout est question de ROI pour les équipes et organisations. Si nous ne pensons pas aux équipes, quelqu’un vous empêchera de contribuer aux projets. Vous devez justifier votre ROI que ce soit à court terme ou à long terme.
Ce qui est unique à propos d’InnerSource est qu’il s’agit fondamentalement de collaboration équipe-à-équipe. C’est là que la plupart des implémentations finissent ultimement. Ce n’est pas nécessairement des individus contribuant au hasard à des projets personnels pratiques. C’est typiquement implémenté à travers des relations d’équipe hôte et d’équipe invitée, où les équipes invitées accompagnent des parties maintenues par les équipes hôtes. La plupart des entreprises ont des employés avec des rôles et responsabilités définis, et la collaboration tend à se produire au sein de ces structures.
Par conséquent, InnerSource est particulièrement efficace quand les relations entre les équipes de plateforme et les équipes alignées sur les flux (équipes invitées et équipes hôtes) sont établies. La co-création active entre les équipes alignées sur les flux ou les individus est plus incertaine de réussir naturellement.
Critiquer tout InnerSource basé sur des scénarios qui ont peu de chances de fonctionner n’a aucun sens logique.
La deuxième idée fausse : « Cela n’arrive jamais dans les vraies entreprises » #
parce que nous voulons que les gens fassent cela la réalité est que ce n’est pas ce qui va se passer jamais dans aucune entreprise jamais inner source
En fait, cela arrive. Les études de cas le prouvent. Point final.
La troisième idée fausse : « 99,69% des projets InnerSource échoueront » #
99,69% un mensonge vous allez construire tout le projet par vous-même quand il tombe en panne les gens vont se tourner vers vous
Cela pourrait être correct selon comment vous définissez « InnerSource ». Comme mentionné précédemment, InnerSource ne consiste pas à « recevoir des contributions PR ».
Cependant, il y a trois points importants à considérer :
- InnerSource s’applique surtout aux composants stratégiques - ce n’est pas requis pour tous les composants
- Les bénéfices s’étendent au-delà des contributions actives
- L’open source a le même problème de « taux d’échec »
InnerSource est une stratégie d’entreprise #
Quand les gens pensent à InnerSource, ils imaginent parfois des idées radicales comme « partager tout le code au sein de l’entreprise » ou « tout le monde contribuant à tout ». Ils pourraient envisager des centaines de dépôts partagés au sein d’une entreprise avec tout le monde échangeant activement des contributions. Comme l’open source étant une stratégie pour les entreprises, InnerSource est aussi une stratégie d’entreprise avec des priorités. Les entreprises partagent « ce qui vaut la peine d’être partagé » en premier.
Par conséquent, le nombre réel de bases de code où le code circule activement entre les équipes et où une collaboration inter-équipes vibrante se produit est relativement petit. Cela pourrait effectivement être des pourcentages à un chiffre. Cependant, même sans collaboration inter-équipes active, beaucoup de projets peuvent bénéficier d’être ouverts et transparents. Dans ce sens d’InnerSource, les entreprises peuvent souvent partager de la valeur à travers beaucoup plus de cas.
Bien qu’InnerSource inclue les contributions individuelles, il est principalement axé sur la collaboration équipe-à-équipe. Par conséquent, ce qui est partagé à travers InnerSource tend à être relativement de niche au sein des entreprises, ou des éléments spécifiques à un but comme des distributions Linux forkées pour des besoins particuliers. Ou cela pourrait simplement être une culture de développement similaire à l’open source, comme quand GitHub partage le code Ruby on Rails à travers tous les employés.
Quand nous conditionnons cette discussion de pourcentage sur InnerSource qui collabore activement et est maintenu comme des exigences communes, le pourcentage peut effectivement être relativement bas. Cependant, de petites collaborations comme des pull requests de documentation ou des changements de configuration mineurs (envoyant de petits patches) entre les équipes invitées et les équipes de plateforme/hôtes se produisent relativement fréquemment. Quand vous incluez ces micro-collaborations et les bénéfices de transparence qui préviennent les efforts dupliqués, ces nombres augmentent significativement.
L’open source a le même « problème » #
D’autre part, si nous le définissons de cette façon, l’open source serait aussi un « mensonge ». Parce que « 99,69% des projets open source échoueront ». La plupart du code publié comme open source ne reçoit pas de contributions. Mais personne ne dit « l’open source est un mensonge » à cause de cela. Les gens poursuivent l’open source parce qu’il y a des bénéfices au-delà de recevoir des contributions.
Encore une fois, « recevoir des contributions » n’est pas la seule valeur d’InnerSource. Et la même chose est vraie pour la valeur de l’open source également
Les vrais bénéfices de la transparence #
Garder le code interne ouvert plutôt que caché - chez GitHub, les architectes ou ingénieurs solutions de l’équipe revenus pourraient être capables d’examiner le code source pour trouver des informations pertinentes, potentiellement trouvant des détails très proches des demandes clients, facilitant des conversations de support plus fluides, et extrayant des informations plus précises des problèmes. Je vis à Tokyo, et parfois c’est plus rapide de juste regarder le code Ruby pour vérifier l’implémentation, ou aller aux problèmes pour vérifier le contexte des changements, plutôt que d’attendre que l’équipe produit basée à SF se réveille pour poser des questions d’implémentation sur les changements et leur contexte.
En utilisant la commande git blame, vous pouvez identifier les « vrais » parties prenantes du code et poser des questions sur le contexte des décisions.
Il va sans dire que la même chose s’applique aux autres équipes de développement. Avoir des informations facilement disponibles sur les composants qui pourraient créer des dépendances réduit clairement les frais généraux de communication.
InnerSource consiste à pratiquer les principes de l’open source en interne. InnerSource ne consiste pas seulement à envoyer des pull requests dans les deux sens - il s’agit d’assurer la transparence et de gagner des bénéfices à travers la collaboration de style open source. Ces bénéfices s’étendent bien au-delà des quelques pour cent de dépôts activement maintenus aux bénéfices d’implémentation culturelle plus larges.
La quatrième idée fausse : « Vous serez rappelé quand vous partirez » #
« quand vous quittez l’entreprise ils vont vous envoyer un message 6 mois plus tard vous posant des questions ou voyant si vous aimeriez contracter avec eux pour mettre à niveau votre application il n’y a pas de chose telle que l’innersourcing »
Les ressources deviennent parfois non maintenues, mais ce n’est pas une critique appropriée d’InnerSource lui-même - c’est une critique d’échec à implémenter InnerSource correctement. Ce n’est pas une critique d’InnerSource, mais une critique du manque de culture de maintenance où personne ne maintient le code. Cela résulte d’échec à implémenter InnerSource correctement ou de ne pas le considérer du tout - le résultat du manque de propriété.
L’analogie DevOps #
C’est une critique d’échec à faire InnerSource, pas une critique d’InnerSource lui-même. Parfois cela confond la logique. Pour mettre cela en termes DevOps : c’est comme dire « les entreprises finissent par adopter des cycles de révision lents de plusieurs mois ou des audits, ou ajoutant des processus pour les décisions de release, donc les releases deviennent trimestrielles ou seulement deux fois par an. Par conséquent DevOps, qui prétend permettre des releases rapides, n’est pas bon. » Ce n’est pas parce que la méthodologie DevOps est mauvaise, mais simplement parce qu’« il y avait des cas où DevOps ne pouvait pas être implémenté. »
Casser les processus métier est extrêmement difficile, et beaucoup d’entreprises ont dit que DevOps était impossible. Mais même quand les gens pensaient que c’était impossible, il y avait des pionniers courageux qui ont travaillé dur pour changer la culture et ont réalisé DevOps. La même chose peut arriver avec InnerSource.
La cinquième idée fausse : « Vous devez posséder tout à 100% » #
vous le possédez à 100% (ce qui implique : InnerSource où vous ne possédez pas 100% est impossible)
« InnerSource signifie abandonner la propriété du code » est faux. InnerSource exige réellement que les équipes possèdent le code. C’est une erreur commune. C’est comme les gens qui veulent abandonner la responsabilité de maintenance et disent « rendons cela open source ». Cela ne fonctionne pas.
Propriété individuelle vs. d’équipe - InnerSource est-il une propriété de code forte ? #
D’abord, ce « Vous » est-il individuel ou pluriel ? Bien que les individus puissent être listés comme fichier CODEOWNERS dans les organisations, les équipes détiennent ultimement la responsabilité du code. Contextuellement, cela parle probablement de Propriété de Code Forte. Mais ce n’est pas bon quand on considère la maintenance organisationnelle. Parce que les employés pourraient démissionner.
InnerSource n’est pas une Propriété de Code Forte. Au minimum, plusieurs personnes doivent partager la responsabilité. Cela dit, je reconnais qu’une Propriété de Code Forte peut émerger à court terme, et dans les premières étapes d’un projet, une forte volonté individuelle pourrait naturellement mener à de tels arrangements, mais si vous voulez atteindre le succès à long terme, il est nécessaire de déléguer l’autorité pour que l’organisation puisse gérer la maintenance collectivement.
Types de propriété d’équipe - InnerSource est-il une propriété de code collective ? #
Ce type d’argument pourrait parfois faire référence à la Propriété Collective. Dans ce cas, l’argument semble aussi suggérer qu’InnerSource signifie propriété collective, mais c’est en fait différent. InnerSource n’est pas une Propriété de Code Collective InnerSource implique que les équipes hôtes gèrent ultimement la maintenance. InnerSource est une Propriété de Code Faible. Donc bien que la responsabilité de maintenance soit 100% correcte, dire « vous devez posséder 100% et InnerSource est différent » est complètement illogique. C’est en fait une opinion incorrecte.
Comme Martin Fowler l’a famousement argumenté à propos de la propriété du code, avoir tout le monde possédant le code à 100% (propriété collective) crée parfois des situations où personne ne prend la responsabilité. C’est très problématique - la responsabilité devient peu claire et les projets échouent ultimement.
Modèle de propriété de code faible #
Dans la Propriété de Code Faible, les mainteneurs existent, les équipes hôtes maintiennent les projets, et des parties spécifiques pourraient faire venir des committers/mainteneurs de confiance d’autres équipes. Quelqu’un pourrait contribuer, quelqu’un pourrait maintenir, mais pas 100% par « vous » ou « votre équipe » - cela pourrait être assez différent. Par exemple, 98% du code pourrait être possédé par votre équipe, tandis que 2% pourrait être possédé par d’autres équipes.
Dans ce cas, rappelez-vous que même si les individus sont assignés comme propriétaires de code dans les organisations, les équipes détiennent ultimement la responsabilité du code. Les équipes devraient le posséder, et n’oubliez pas ce point important.
La sixième idée fausse : « Quelqu’un va vous lâcher 7000 lignes dessus » #
De temps en temps il y aura un collègue suffisamment motivé qui est vraiment génial et fait comme une mise à jour de 7 000 lignes sans explication mais ne tombez jamais dans cette idée que choisir quoi que ce soit pour une app interne sur laquelle vous allez travailler
Avoir des pull requests de 7000 lignes apparaître soudainement est lui-même un échec à introduire la culture InnerSource - ce n’est pas quelque chose qui arrive en faisant InnerSource. Ce cas pourrait s’inquiéter qu’introduire InnerSource fait que de telles collaborations arrivent, mais c’est complètement faux.
Le vrai problème #
Cet argument représente l’échec à implémenter la culture InnerSource et les pratiques collaboratives, pas InnerSource lui-même. Les implémentations de 7000 lignes sont des cas très limités. Cela représente l’échec de la culture de collaboration où 7000 lignes sont soumises comme pull requests soudainement sans aucune notification - l’organisation devrait corriger ce problème de culture fondamental, qui est pré-InnerSource.
Si vous voulez prévenir cela, il y a une solution. Favorisez la culture InnerSource au sein de votre organisation :)
La réalité : Ce qu’InnerSource est réellement #
InnerSource est une implémentation culturelle - utilisant les pratiques de collaboration open source pour profiter de divers bénéfices que l’open source reçoit à travers la collaboration. Le but ultime d’InnerSource n’est pas seulement de recevoir des contributions (pull requests), mais inclut les demandes de fonctionnalités à travers les problèmes, la coordination du support, et divers autres bénéfices, plus la transparence dans la prise de décision et la promotion culturelle pratique.
Par conséquent, je rejette définitivement l’affirmation que « implémenter les meilleures pratiques InnerSource pour obtenir des pull requests est un mensonge ».
Comprendre la réalité des contributions #
« Personne ne va jamais contribuer »
Dans la collaboration open source, les contributeurs sont effectivement une fraction minuscule. Sur 1000 utilisateurs, peut-être la grande majorité ne sont que des utilisateurs, 20 pourraient soumettre des problèmes ou des demandes de fonctionnalités, 5 pourraient envoyer des pull requests, et peut-être seulement un devient un mainteneur.
Encore une fois, les meilleures pratiques InnerSource ne feront pas que les 1000 personnes contribuent. InnerSource aide à induire une telle collaboration, mais vise ultimement à briser les silos d’entreprise, améliorer la collaboration qui est entravée par les contraintes organisationnelles traditionnelles, réduire les délais d’exécution des silos d’information, et optimiser l’allocation des ressources organisationnelles en utilisant les pratiques open source.
Conclusion #
Bien que les arguments dans ce cas touchent à certains défis réels, ils sont basés sur des malentendus communs que beaucoup de personnes rencontrent quand elles découvrent InnerSource pour la première fois. Ce sont des pièges bien connus dans la communauté, et il est compréhensible comment quelqu’un pourrait arriver à ces conclusions sans exploration plus profonde du domaine.
L’insight clé est qu’InnerSource ne consiste pas à forcer les pratiques open source dans un cadre rigide. Au lieu de cela, il s’agit de revenir à la question fondamentale : que pouvons-nous apprendre de l’open source ? En examinant l’open source à travers une lentille plus large, nous pouvons mieux adapter ces principes en interne.
Vous pouvez rejoindre cette conversation et apporter des perspectives fraîches. Que vous vouliez construire sur cette discussion, explorer des détails d’implémentation plus spécifiques, ou même défier ces arguments entièrement - toutes les approches sont les bienvenues. Ce qui importe le plus est de maintenir cette perspective large sur les apprentissages open source et comment ils se traduisent aux contextes organisationnels internes.
Pour des informations complètes sur InnerSource, je recommande de vérifier la Fondation InnerSource Commons. Ils accueillent des points de vue divers et un dialogue continu sur comment les principes open source peuvent créer de la valeur au sein des organisations.
