Sommet de printemps 2018

Aujourd’hui, nous savons que InnerSource est un excellent moyen de développer efficacement des logiciels en exploitant des communautés qui transcendent les frontières organisationnelles et géographiques aka silos. Nous savons aussi maintenant que InnerSource est une excellente solution pour le véritable développement d’Open Source pour les entreprises qui n’ont pas d’ADN logiciel. De retour lorsque Bosch a commencé avec InnerSource, il n’y avait pas assez d’expérience technique, juridique, de collaboration, sociale et commerciale au sein de Bosch pour démarrer immédiatement open source. Il est difficile d’obtenir une initiative InnerSource dans un tel contexte. Stefan reviendra sur les origines de InnerSource chez Bosch et partagera l’histoire surprenante de la façon dont il a réussi à convaincre les cadres supérieurs de s’engager dans InnerSource en utilisant des moyens peu conventionnels. Il s’agissait de trois éléments clés:

1. commencer par InnerSource d’abord et non par open source tout de suite,
2. commencer avec l’outillage (ici Eclipse IDE pour automobile) et non avec les produits Bosch et
3. Commencer par la capture du drapeau des nations et non par les diapositives Maintenant Stefan est fier que Bosch contribue activement aux projets Eclipse Internet of Things.

Stefan est fier que Bosch contribue activement aux projets Eclipse Internet of Things.

Au fil des ans, nous avons tous vu des méthodes de développement de logiciels venir et venir. Beaucoup d’entre nous sont devenus sceptiques quant aux promesses de nouvelles approches. Danese, Jim et Georg, trois praticiens de longue date de InnerSource, ont vécu de première main comment InnerSource se distingue et a le potentiel de transformer vraiment le monde du développement logiciel d’entreprise. Dans ce discours, ils partageront trois arguments convaincants pour pourquoi InnerSource compte.

« La source intérieure est une excellente idée ! Vous êtes le champion dédié de la source intérieure dans votre entreprise. Que faites-vous maintenant ? Comment affectez-vous de façon réaliste le comportement de dizaines ou de centaines d’équipes au point où l’approvisionnement interne robuste et omniprésent est une partie normale de la façon dont l’ingénierie est faite?

Cette présentation partage des principes, des anecdotes pratiques et des exemples relatables sur cette situation glanée de l’expérience de Nike. Tout en ne revendiquant pas toutes les réponses, elle résume avec perspicacité plus d’une année de travail dans ce domaine.

L’entreprise a décidé de lancer une initiative InnerSource afin de favoriser la collaboration au-delà des frontières organisationnelles partout dans le monde. Nous comprenons que l’adoption du paradigme de développement open source au sein de l’organisation devient très populaire et essentielle pour les affaires de l’entreprise. Pour autant que je sache, de nombreuses entreprises ont expérimenté ce modèle, mais jusqu’à présent il n’est pas toujours clair par où commencer. Je veux donc partager notre expérience de l’affaire Edge Platform InnerSource, avec le cas d’utilisation, DevOps, Outils, Développement de produits, et infrastructure de développement, et ainsi de suite et attendre du public qu’il capte quelques idées. Mais d’autres discussions sont nécessaires pour comprendre les différents modèles de InnerSource que les entreprises adoptent.

En 2006, j’ai introduit la source interne au SAP. Après être devenu professeur, mon groupe a aidé d’autres entreprises à introduire une source intérieure. À l’aide de trois générations de projets, nous rendons compte de nos expériences et de la façon dont nous les transformons en un manuel pratique pour la gouvernance interne des sources.

Wayfair a une importante organisation d’ingénierie (plus de 1200 personnes). Il est composé de nombreuses petites équipes de sprint qui peuvent travailler de façon efficace et efficiente. Toutefois, cette structure rend difficile la coordination des travaux qui s’étendent à de grandes parties du Ministère, comme l’introduction de nouveaux cadres ou la modernisation d’infrastructures partagées. Nous avons introduit un concept appelé groupes de travail, basé sur les principes InnerSource, qui nous permet de mener ce genre de projets avec l’efficacité que nous attendons de toute autre équipe. Au cours de cette séance d’affichage, je vais donner un aperçu des projets que nous avons abordés avec des groupes de travail, leurs avantages et leurs inconvénients, et de la façon dont nous envisageons d’adopter ce modèle.

Innersource a une influence très positive sur le prototypage et le prédéveloppement. Une entreprise avec de nombreux produits dans différents domaines peut déclencher des solutions de domaine croisé en publiant en interne des API et des bibliothèques. Le partage de ces données au sein de l’entreprise a permis la réutilisation dans différentes unités d’affaires menant à des synergies surprenantes entre différentes applications.

Bien qu’il y ait beaucoup de discussions et de blogs sur les API et l’importance d’une API Developer eXperience, la plupart sont des produits d’API publics. Et bien que beaucoup des meilleures pratiques pour les produits API soient également applicables aux API privées, il y a des différences importantes dans les circonstances et les compromis qu’ils doivent faire. La différence la plus importante est probablement dans leurs budgets : en tant que centres de profit potentiels, les produits API peuvent se permettre d’investir beaucoup plus d’argent dans la documentation et les améliorations de portail de développeurs UX. Les API internes ont rarement ce luxe. Dans cette présentation, je vais expliquer les différences entre les API publiques et privées, introduire l’expérience du développeur en amont, et expliquer comment il peut améliorer DX en aval. Introduire la conception d’expérience (a.k.a. gamification) et décrire comment elle pourrait être utilisée sur les portails de développeurs internes. Enfin, je parlerai de l’importance des SDK et des différentes stratégies qu’une organisation peut adopter pour les construire, y compris une stratégie d’intérim qui pourrait contribuer à améliorer le DX des API au cœur de l’initiative de transformation numérique de votre organisation.

FusionX a été la première communauté Bosch Interne Open Source et est active depuis 9 ans. Notre mission est d’habiliter nos collègues ingénieurs Bosch à construire des prototypes, des outils et de nouveaux produits qui se connectent à nos produits beaucoup plus rapidement qu’auparavant. Au fil des ans, nous avons vu tout cela se produire et plus encore. Je partagerai des exemples et des idées sur le fonctionnement de la collectivité, ce que nous avons développé et quels ont été les facteurs de réussite et les défis auxquels nous avons été confrontés en cours de route.

Nous avons fait l’étape 1 : nous avons une plateforme, des dépôts et un groupe d’utilisateurs initiaux. Maintenant, nous cherchons l’étape 2, faire participer les développeurs de grands projets d’infrastructure. Ils craignent de ne pas avoir le temps de participer à InnerSource. Nous avons des équipes — elles ont une bonne softwre et sont disposées à la partager, mais elles ont des préoccupations quant à la qualité du code que d’autres contribueront; et leur capacité à encadrer d’autres personnes en dehors du groupe. C’est notre prochain obstacle. Cette présentation d’affiches est un stand de conseils inversés – rendez-nous visite et partagez vos idées et vos conseils.

        Another topic: we have a one hour meeting with the company president about InnerSource; what should we emphasize and try to get from him (in terms of support for the InnerSource Program).            

Dans cette présentation, nous présentons l’approche de recherche et les résultats préliminaires d’un projet de recherche en cours sur les meilleures pratiques de l’exploitation minière à l’intérieur des sources. Parce que la source interne est l’utilisation des meilleures pratiques de développement de logiciels libres et l’établissement d’une culture de type open source au sein des organisations, nous devons comprendre les meilleures pratiques utilisées et établies dans le monde open source pour en apprendre davantage. Jusqu’à présent, nous avons recueilli de l’information sur les activités de développement auprès de plus de 450 000 projets libres pour quantifier leur rendement et prédire leur succès. Des meilleurs projets, nous prévoyons exploiter le processus et les pratiques utilisés. À l’aide de la recherche d’études de cas, nous appliquerons ces pratiques open source dans la source interne et validerons ce qui peut sauter le chasm de source ouverte à source interne.

Aucune mesure n’est importante, mais celle qui est directement liée aux objectifs stratégiques de votre entreprise. Le succès est essentiellement mesuré lorsque les objectifs sont atteints.
La mesure des choses est « facile » si vous savez où exploiter les données, mais avoir une stratégie nécessite une expertise contextuelle, une méthode détaillée pour formaliser le processus de mesure et une stratégie concernant la sensibilisation, l’amélioration des processus, la transparence et les actions de motivation entre autres domaines clés.

Les mesures ne sont pas la panacée, mais aident à comprendre la structure et la méthodologie actuelles suivies par une équipe de développement de logiciels. Et c’est loin d’autres organisations similaires.

Les sujets abordés sont les suivants :

• Objectifs utilisant des paramètres
• Domaines d’analyse
• Une approche formelle telle que l’objectif-question-mesure
• Stratégie d’utilisation des paramètres
• Quelques exemples

Breaking silos et favoriser la collaboration entre les différentes unités commerciales est l’un des principaux objectifs de toute initiative InnerSource. Cependant, comment pouvons-nous savoir si cela se produit réellement? Cet exposé portera également sur les sources de données habituelles disponibles lors de la construction de l’infrastructure nécessaire à ce type d’initiatives et sur les traces laissées par les membres de la nouvelle communauté. Ces traces sont celles analysées, stockées et curées afin de produire des mesures précieuses pour l’organisation. J’examinerai les sources de données habituelles comme GitHub, Jira ou Slack comme quelques exemples de la façon de comprendre et de mesurer la collaboration dans l’ensemble de l’organisation.

La source interne (IS) permet et exige que les développeurs collaborent davantage que les méthodes traditionnelles de développement durable, comme le développement axé sur le plan ou agile. Pour mieux comprendre les SI, les chercheurs et les praticiens doivent mesurer leur collaboration. Toutefois, il n’existe pas encore de méthode établie pour le faire. Dans cette présentation, nous présentons une méthode de mesure de la collaboration IS en mesurant le flux patch au sein d’une organisation. Le flux-patch est le flux des contributions de code au-delà des limites organisationnelles telles que les limites de projet, d’unité organisationnelle ou de centre de profit. Nous démontrons la capacité de la méthode de mesure du flux patch en l’appliquant à une entreprise de développement de logiciels. Dans cette entreprise, nous avons constaté qu’environ la moitié (47,9%) de toutes les contributions de code aux projets IS constituent un flux de patchs entre les unités organisationnelles, presque toutes (42,2 %) étant entre les unités organisationnelles travaillant sur différents produits. Un débit de patch aussi important indique une grande pertinence du phénomène de débit de patch. Notre méthode de mesure du débit patch est la première du genre à mesurer et quantifier la collaboration IS. Elle peut servir de base à d’autres analyses quantitatives de la collaboration en matière de SI.

Les désaccords et les malentendus sont courants même dans les organisations les plus performantes. Heureusement, une solution potentielle nous offre une voie de l’imprécision et de la confusion : la conception intentionnelle des relations. Tiré de la profession thérapeutique, IRD nous permet d’établir rapidement la clarté de nos relations de travail afin d’éviter les conflits. Dans ce discours, je vais montrer comment vous pouvez l’utiliser pour établir des attentes, fixer des limites et découvrir des préférences de communication pour construire la confiance et l’harmonie, surtout lorsque vos équipes visent InnerSource.

En appliquant InnerSource avec nos équipes, nous avons découvert comment c’est le moyen le plus puissant de développer, d’apprendre rapidement, de briser les silos et d’augmenter l’organisation. InnerSource permet d’établir les meilleures pratiques de développement de logiciels libres et la culture open source pour chaque développement interne. Vous pouvez encore développer un logiciel propriétaire, mais en interne ouvrir son développement. Au cours de cette session, je partage nos expériences sur la façon dont nous avons élargi notre organisation en utilisant InnerSource avec les rôles, les paramètres de mon organisation précédente Intuit, et la culture et les pratiques internes open source chez Microsoft.

Développer une plateforme technologique Cloud Native, qui apporte des capacités non fonctionnelles à l’entreprise a toujours été un défi pour nous, en tant qu’équipe de plateforme de fondations. En adoptant un état d’esprit Open Source, nous avons examiné comment augmenter l’agilité et commencer un changement culturel dans notre propre organisation, pour conduire un changement culturel dans les unités commerciales adoptant notre plateforme. Nous avons changé notre organisation pour penser comme une organisation open source (structure, pratiques d’ingénierie et collaboration) et sommes rapidement devenus une organisation InnerSource à l’entreprise, menant plus que InnerSource – menant un changement culturel. Je vais décrire la transition que nous avons faite et comment nous avons fait les premiers pas comme InnerSource dans l’entreprise

Nous allons discuter de quelques moyens sûrs d’incendie pour vous assurer que vous définissez votre InnerSource Journey en cas d’échec. Après ces conseils, vous pouvez garantir que InnerSource ne réussira jamais

Ceux d’entre nous qui établissent des programmes InnerSource rencontrent des problèmes similaires. Développer des modèles est une façon de saisir des solutions éprouvées à ces problèmes. Laissez-nous travailler ensemble et fournir des solutions pour la plus grande communauté! Cet atelier présentera brièvement les modèles InnerSource et les composantes standard des modèles. Ensuite, nous allons nous détacher en groupes pour rédiger des modèles pour les problèmes omniprésents. Participants : Si vous avez un problème que vous souhaitez que nous couvrions dans l’atelier, faites-le nous savoir à l’avance ! Courriel: erin.bank@ca.com

Les langages modèles montrent comment les modèles s’harmonisent pour résoudre des classes de problèmes autour d’un sujet. Nous créons des modèles InnerSource dans l’ISC depuis 2016 ; ce travail a peut-être été, par nécessité, quelque peu fragmenté. Nous avons découvert, par exemple, qu’il existe différentes saveurs de InnerSource et de multiples dimensions dans lesquelles les programmes InnerSource pourraient être décrits. Cette présentation partage quelques idées sur les langages de modèle InnerSource, à quoi ils pourraient ressembler, comment ils pourraient être utilisés et comment ils pourraient être créés.

Au cours des derniers mois, une série d’entreprises espagnoles ont travaillé sur un modèle de maturité pour donner un cadre général pour le niveau C et d’autres domaines de travail dans InnerSource.
Cet exposé présentera une discussion interne sur le thème du modèle de maturité et une mise en œuvre potentielle basée sur les principaux principes InnerSource tels que la collaboration ou la transparence. En plus de cela, il est prévu d’ouvrir une discussion sur le sujet de ce type de modèles qui sont habituellement initiés comme un ensemble de bonnes pratiques, mais à la fin ils sont considérés comme pure bureaocracy au sein des organisations.

La plate-forme Siemens InnerSource a commencé comme un moyen pour une division de maintenir une pile standard dans toute sa gamme de produits. À partir de ces débuts, il est rapidement devenu quelque chose de beaucoup plus grand : Un environnement de développement à la pointe de la technologie, un outil pour construire des plateformes au sein de l’entreprise. Il est également devenu un exemple très visible pour une manière collaborative et agile de travailler au sein de Siemens. Dans cette introduction, nous examinerons l’histoire de la plateforme et les principales raisons de son succès jusqu’à présent, ainsi que les défis passés et présents.

InnerSource – ce que nous appelons Bosch Internal Open Source (BIOS) en interne – est un excellent outil pour une variété de cas d’utilisation dans une configuration d’entreprise. L’un d’eux étant l’outillage interne, nous pensons que InnerSource est un ajustement naturel. Grâce à nos efforts constants pour faire avancer le BIOS au cours des neuf dernières années, nous sommes enfin en mesure de convaincre le secteur des entreprises IT chez Bosch de commencer l’adoption de InnerSource. Le premier outil interne qui deviendra un projet BIOS est l’Open Source Desktop (OSD), un alténatif OS basé sur Linux pour les associés Bosch. En plus de fournir des détails sur les premières mesures que nous avons prises, nous donnerons également quelques indications sur les conditions préalables qui sont essentielles pour un projet InnerSource réussi et donnerons un bref aperçu des domaines où l’OSD est utilisé au sein de Bosch.

Ceux d’entre nous qui établissent des programmes InnerSource rencontrent des problèmes similaires. Développer des modèles est une façon de saisir des solutions éprouvées à ces problèmes. Laissez-nous travailler ensemble et fournir des solutions pour la plus grande communauté! Cet atelier présentera brièvement les modèles InnerSource et les composantes standard des modèles. Ensuite, nous allons nous détacher en groupes pour rédiger des modèles pour les problèmes omniprésents. Participants : Si vous avez un problème que vous souhaitez que nous couvrions dans l’atelier, faites-le nous savoir à l’avance ! Courriel: erin.bank@ca.com

L’approvisionnement intérieur au cœur des réseaux NOKIA et les gens semblaient être un match fait au paradis. Pour la haute direction, il s’agit d’un programme d’efficacité de la R-D. Pour les développeurs, c’est l’occasion de s’exprimer. Le voyage a eu sa part de succès et d’échecs qui nous ont fait faire plusieurs corrections de cap sur le chemin. Bientôt, le fantasme de l’approvisionnement et de la réutilisation internes et les attentes concernant la réalisation des objectifs de l’entreprise ont eu leurs propres façons de se réunir. La lune de miel était bientôt terminée et nous avons eu la lourde tâche de faire ce cocktail capricieux, juste le bon mélange entre l’Open Source oser et le flair de l’entreprise. Nous sommes toujours à la recherche de ce mélange insaisissable… Ce discours explorera les choses qui ont fonctionné, les choses qui n’ont pas fonctionné, les aspirations des gens, les frustrations

En open source, les projets diffèrent souvent sensiblement les uns des autres. Par conséquent, il n’est pas surprenant que les projets sources internes et même les programmes puissent avoir une variété de formes différentes. Lorsqu’on adopte la source intérieure en créant un nouveau programme source interne, ou même en gérant l’évolution d’une initiative existante, il est crucial de comprendre quelles sont les différentes formes (classes) de projets et de programmes source interne. Dans cette présentation, nous présentons un cadre de classification décrivant différentes classes de projets et de programmes de sources internes. Nous appliquons le cadre à onze entreprises qui font des SI et discutons des différences de leurs programmes de sources internes. Le cadre de classification présenté est le premier de ce genre à classer et à structurer l’espace du programme de sources internes existant. Après avoir entendu ce discours, vous pourrez appliquer le cadre à votre propre entreprise.

Les data savants ne sont pas des développeurs. Et pourtant, ils écrivent constamment du code source. Le logiciel d’écriture est complexe, encore plus dans le domaine de la science des données. Le génie logiciel est la réification de décennies d’échecs et de réussites dans la livraison de produits logiciels. Peut-être que l’open source est l’un des cas les plus paradigmes: avec des pratiques innovantes, nous avons vu comment les équipes distribuées à l’échelle mondiale, les mélanges de développeurs rémunérés et bénévoles, la réutilisation de dizaines de morceaux de code, ont constamment livré des logiciels de haute qualité. Qu’est-ce que la science des données peut apprendre de Software Engineering et Open Source ? Dans cette présentation, nous montrerons comment les équipes de data science peuvent apprendre de Software Engineering et Open Source, adopter une approche InnerSource, réutiliser le code et les résultats et fournir des résultats de haute qualité, qui sont plus faciles à promouvoir à la production.

Tout le monde peut installer une forge de logiciel, prescrire que « nous faisons maintenant source intérieure » et l’appeler un succès par définition. Beaucoup vont plus loin et commencent même à mesurer leur efficacité. Les métriques sont cependant difficiles, souvent juste les développeurs frustrés, sont faciles à jouer et très rarement liés à tout ce que l’entreprise comprend – complexité cyclomatique et KLOC quelqu’un? Ce discours proposera quelques mesures utilisées par un fonds de capital-risque qui gère des entreprises comme Docker, Twitter, Blabla Car et Hello Fresh pour mesurer le succès de leurs investissements. Nous montrerons l’impact économique de ces mesures sur des exemples concrets de leur application dans de grandes entreprises comme Allianz, Continental et Zalando. Comme beaucoup de ces paramètres ont à voir avec l’application de la source intérieure (source ouverte dans les limites des entreprises), nous démystifierons également la plus grande perception de la source intérieure qui empêche particulièrement la direction intermédiaire de l’adopter – la peur que chaque développeur fasse désormais tout ce qu’il veut.

La source interne est l’application de méthodes libres à des logiciels développés en interne. Bien que simple à définir, source intérieure peut être difficile à expliquer et à mettre en œuvre avec succès. Cette présentation présente les termes, concepts et principes clés pour un approvisionnement interne efficace, ainsi que des explications et des exemples réels. Ce contenu est accessible aux nouveaux arrivants tout en rafraîchissant ceux qui ont de l’expérience. Les mêmes informations dans cette présentation sont également livrées sous la forme d’un O-Reilly Oriole, disponible gratuitement chez https://www.safaribooksonline.com/oriole/. Nous allons examiner l’Oriole, comment l’utiliser, et d’autres Orioles liés à la source intérieure qui sont en route.