Sommet de printemps 2019

Détails paraissant prochainement

Je vais partager l’histoire de InnerSource chez Bosch, qui a commencé il y a une dizaine d’années. Dans mon exposé, je partagerai des détails intéressants sur les débuts et l’évolution de InnerSource chez Bosch ainsi que de nombreuses leçons que nous avons apprises en chemin.

Thales InnerSource Software (TISS) Community est né de l’appel à initiatives Thales Digital Transformation en 2016. Il a été conçu dès le début pour aborder les principaux aspects de la collaboration ouverte : juridique, outils et changements culturels. Aujourd’hui, cette communauté est organisée comme une fondation open source interne et ne cesse de croître au sein de l’entreprise. Thomas Froment, en tant que chef de file de la Communauté, présentera son retour d’expérience, éclairant la manière dont ils tentent de mettre en œuvre InnerSource dans cette multinationale (65 000 employés, dont 25 000 ingénieurs sur 56 pays). Sujets clés abordés : Gouvernance, juridique, outillage, promotion et incitatifs, partage transparent des succès, des échecs, des enjeux ouverts et des défis auxquels ils sont confrontés en 2019 pour l’échelle TISS au niveau du groupe.

Les pratiques de collaboration sont adoptées naturellement par les participants aux projets open source d’aujourd’hui. Beaucoup de gens de la culture informatique ont été « élevés » avec le travail d’équipe et la communication ouverte en tant que partie intégrante de la culture open source. Non pas pour les géants qui font des pas plus grands avec leurs pas, mais en même temps se trouvent réticents à changer. Il n’est pas rare, lors d’une implémentation InnerSource, de voir les motifs industriels habitués derrière leur tête laid. Les humains peuvent être exceptionnellement créatifs de manière positive et négative. Tout comme différentes motivations propulsent l’ingéniosité humaine en avant, ils peuvent également nous retenir. Quelles sont les raisons possibles de la perte de traction de votre InnerSource et ce que nous pouvons faire pour remettre les choses sur la bonne voie?

Red Hat, le premier fournisseur mondial de solutions Open Source Enterprise, dispose d’un outil d’évaluation open source, appelé Open Source Maturity Assessment (OSMA), pour permettre aux organisations de comprendre leur maturité actuelle en ce qui concerne leurs connaissances, leur adoption et leur capacité à utiliser efficacement les technologies Open Source / InnerSource au sein de leur organisation. L’évaluation pose un certain nombre de questions avec des réponses à choix multiples dans les domaines clés suivants : objectifs opérationnels, connaissance générale de l’Open Source, normes et outils de développement, participation communautaire en amont, politiques de gouvernance et juridiques et soutien à la haute direction. Les résultats de l’évaluation sont utilisés comme point de départ pour permettre à une organisation de mieux comprendre ses objectifs opérationnels en ce qui concerne les logiciels et méthodologies Open Source / InnerSource, les domaines d’intervention à aborder (dans les domaines de la consommation, de la contribution, de la création et de la stratégie/de la gouvernance) et les prochaines étapes recommandées. Au cours de cet atelier, nous allons :

• Chaque participant doit passer par l’outil d’évaluation pour déterminer la maturité de son organisation
• Analyser les résultats pour mettre en évidence les domaines sur lesquels une organisation doit se concentrer
• Tenir une discussion ouverte sur la maturité de l’organisation, y compris les problèmes rencontrés et les moyens d’augmenter le niveau de maturité L’évaluation elle-même est Open Source et le code peut être trouvé à https://github.com/boogiespook/osma.

Il s’agit d’une pile LAMP simple, permettant de personnaliser les questions et les réponses pour une organisation. L’outil de maturité a été présenté puis utilisé par un certain nombre d’organisations, grandes et petites, pour les aider à comprendre où ils se trouvent dans leur parcours Open Source.

Cette présentation couvre la phase de découverte InnerSource à Zalando et les meilleures pratiques qui sont actuellement adoptées dans toute l’entreprise.

Lorsque Elbit Systems a lancé son programme InnerSource, il a décidé de stimuler le changement culturel par la gamification. Shelly Nizri offre un aperçu de la Software Guild, une approche de gamification innovante pour accroître l’engagement et encourager la collaboration dans l’organisation. Rejoignez-nous pour apprendre comment l’entreprise a prévalu malgré des ressources modestes et a surmonté tous les défis dans l’esprit de InnerSource

Vous avez donc décidé que InnerSource est la voie à suivre pour votre entreprise. Tant mieux pour toi ! Le reste n’est qu’un morceau de gâteau. Vous n’avez qu’à expliquer à vos employés de quoi il s’agit. Oh oui, et parler aux gens de l’impôt sur les sociétés, ne devrait pas être un problème, vous connaissez un gars là-bas. Alors demandez au service juridique de répondre à quelques questions simples, et vous partez! Ok, l’outillage est aussi un problème. Et la gouvernance… D’accord, donc vous n’avez pas pensé à tous les détails mineurs, mais vous obtenez juste tout le monde de l’attention et de répandre le mot. Du calme ! Pas vrai ?!? Laissez-moi parler un peu de notre voyage à Daimler TSS. Nous n’avons pas encore tout résolu, mais nous sommes sur une bonne voie, et peut-être que notre expérience peut vous aider un peu, aussi.

GitHub est la plate-forme sur laquelle la plupart des logiciels Open Source sont écrits, générant des quantités massives de valeur en connectant les développeurs à travers le monde pour travailler sur certains des problèmes les plus ambitieux. Bien entendu, les entreprises voulaient rejoindre ce réseau et le reproduire au sein de leurs propres organisations sous le nom de InnerSource. Ces mêmes entreprises se battent maintenant pour trouver des flux de travail qui sont suffisamment flexibles pour évoluer avec leurs sociétés et la façon toujours changeante de développer Open Source. GitHub a pour objectif d’aider les entreprises à mettre en œuvre les pratiques InnerSource en investissant et en s’appuyant sur leurs réseaux tout en maintenant les données client et les pratiques commerciales sécurisées.

Rejoignez Brent Beer alors qu’il partage quelques-uns des récents succès et plans de GitHub pour l’avenir.

L’une des principales questions que toute entreprise prête à essayer InnerSource est de savoir comment cela peut être intégré à sa manière actuelle de se développer. Plus encore, certains d’entre eux ont récemment commencé avec Agile et cela peut être considéré comme «encore une autre approche de développement de logiciels. Agile et InnerSource sont définis dans les deux cas et [par exemple: dans la Wikipedia] comme des pratiques de développement logiciel. Cependant, il semble qu’il ne soit pas encore clair comment chacun d’eux peut compléter l’autre. Ce discours vise à apporter sur la table quelques réflexions sur comment Agile est utilisé par certaines grandes sociétés, et comment InnerSource est appliqué par d’autres. Nous n’avons pas pour but d’exposer les faits, mais d’ouvrir une discussion fructueuse avec l’auditoire dans le but d’apporter davantage de cas d’utilisation et de partager des expériences entre les participants.

Comment apportez-vous un héritage de la planification des ressources d’entreprise (ERP) à « The Cloud », avec la promesse de permettre de nouveaux modèles d’affaires et de réduire les coûts? Comment faire face à une énorme dette technique et organisationnelle accumulée au fil des décennies? Comment initier une transformation radicale et comment mettre les gens en mouvement ? Tels sont les défis que la CTO nouvellement embauchée d’une unité commerciale au sein de Softplan, grande entreprise brésilienne, a accepté il y a quelques années. Dans ce discours, nous expliquons comment nous avons eu l’occasion de travailler avec le CTO et de l’appuyer par une approche axée sur les données. Après avoir introduit la notion d’analyse logicielle, nous expliquons comment nous avons d’abord utilisé les mesures pour diagnostiquer les problèmes, puis pour soutenir un processus d’amélioration continue. Nous passons en revue une série d’expériences spécifiques réalisées dans ce contexte, qui traitent à la fois des succès et des défis. Nous soulignons les aspects humains de la transition et nous expliquons comment les mesures peuvent être puissantes lorsqu’il s’agit de déclencher des conversations et de provoquer des changements de comportement. Nous expliquons comment nos recommandations initiales devaient inciter les équipes à adopter des pratiques qui peuvent être vues « en action » sur GitHub. Lorsque nous avons entrepris ce voyage, nous ne savions pas pour le InnerSource Commons. Néanmoins, certains des problèmes que nous avons rencontrés sont très semblables à ceux qui sont enrôlés dans le catalogue Patterns. Dans l’exposé, nous mappons nos expériences aux problèmes décrits dans le catalogue. Nous comparons nos solutions à celles des modèles.

Lors des dernières sessions InnerSource Commons et Patterns, une série de questions ont été soulevées par la communauté. Ceux-ci sont liés à la découverte, la disponibilité, la sensibilisation, la documentation, et d’autres. Dans ce discours, Kristof Van Tomme et Daniel Izquierdo discuteront de l’utilisation d’un portail de développeurs comme moyen de centraliser et de traiter tous ces modèles connexes. Après l’introduction, nous nous séparons en groupes de discussion pour travailler sur les modèles clés que l’auditoire estime devoir inclure dans la plupart des portails d’internalisation.

Au cours des 10 dernières années, Red Hat Consulting a offert des services autour du processus et de la culture open source, en plus de ses offres technologiques normales. Alors que Red Hat est une entreprise de solutions logicielles Enterprise, il est également le principal promoteur de la façon dont fonctionne l’open source et pourquoi il produit de bons logiciels, en utilisant une approche communautaire. Cet article traite: Si c’est possible, open source devrait être considéré en faveur de source interne comme une approche pour une organisation Si InnerSource est la seule option, ce qui devrait être considéré pendant cette phase du projet

Une présentation informelle, mais peut-être instructive, sur les défis de la mise en œuvre de InnerSource dans une entreprise non technique de taille moyenne. Harvard Business Publishing a pour mission d’améliorer la pratique de la gestion dans un monde en mutation, et nos domaines d’intérêt sont l’édition et l’apprentissage des pédagogies. Nous reconnaissons de manière réfléchie que, bien que nous ne soyons pas une entreprise de technologie, nous traitons le génie logiciel comme une compétence de base qui peut faire ou briser notre stratégie. L’adoption de InnerSource a été considérée comme un élément clé de nos plans à long terme, mais a été bien en deçà de nos attentes. Nous aimerions partager notre expérience non pas en tant qu’acte d’accusation inhérent à InnerSource mais en tant que mise en garde de l’intention et de l’aspiration par rapport à chaque jour et des contraintes peu excitantes, mais très réelles.

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. Beaucoup d’ingénieurs manquent d’expérience en open source et les idées et la mécanique du développement de code ouvert. Même ceux qui ont ce contexte font face à un nouvel ensemble de contraintes et de motivations lorsqu’ils essaient de travailler ouvertement au sein de l’entreprise. Le chemin d’apprentissage InnerSource donne une introduction simple et facile à comprendre à la source intérieure. Il introduit des termes, des concepts et des principes clés pour un approvisionnement interne efficace ainsi que des explications et des exemples réels. Il vise à accélérer les nouveaux arrivants et à fournir à ceux qui ont l’expérience d’un vocabulaire commun à utiliser pour discuter de concepts plus avancés. Le chemin d’apprentissage InnerSource sera hébergé gratuitement par O’Reilly Media à https://www.safaribooksonline.com/learning-paths pour votre utilisation et partage. Dans cette session, nous examinerons le contenu du parcours d’apprentissage et comment vous pouvez l’utiliser et le partager.

Le crowdsourcing devient une autre stratégie d’externalisation qui suscite une attention croissante dans la communauté du génie logiciel. Cependant, le développement de logiciels de crowdsourcing implique des tâches complexes qui diffèrent considérablement des microtâches que l’on peut trouver sur les plateformes de crowdsourcing comme Amazon Mechanical Turk – ces dernières sont beaucoup plus courtes en durée, et généralement très simples et n’impliquent aucune interdépendance des tâches. Pour obtenir les avantages potentiels du crowdsourcing dans le contexte du développement de logiciels, les entreprises doivent comprendre comment cette stratégie fonctionne, quels défis se posent et quels facteurs peuvent influer sur la participation de la foule. Jusqu’à présent, la recherche sur le développement de logiciels de crowdsourcing a eu tendance à se concentrer sur la plateforme technique, avec peu de recherche du point de vue du client qui cherche à tirer parti du modèle de développement de crowdsourcing. Les résultats d’une étude de cas approfondie du développement de logiciels de crowdsourcing dans une entreprise de Fortune 500 sont complétés par une analyse de plus de 13 000 concours de crowdsourcing sur une période de dix ans sur la plateforme de crowdsourcing Topcoder, l’une des plateformes les plus populaires pour le développement de logiciels, sont utilisés pour évaluer l’efficacité du crowdsourcing dans un contexte de développement de logiciels.

Les métriques sont une partie importante du voyage InnerSource. Le InnerSource Commons a été un excellent endroit pour discuter du sujet. Plus précisément, la communauté InnerSource Patterns a livré un modèle axé sur les premières étapes avec des mesures [1] où aucune mesure spécifique n’est détaillée, mais qui donne un point de départ pour discuter quand, comment et quoi mesurer. Cette conférence vise à détailler ces ensembles de mesures et d’ICP pour une discussion plus approfondie dans la communauté. Ceci est basé sur les travaux en cours dans la communauté GrimoireLab/CHAOSS, un projet de Fondation Linux. L’ensemble de mesures proposé est divisé en trois grands domaines : activité, communauté et processus. [1] https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/introducing-metrics-in-innersource.md

Détails paraissant prochainement

La culture est difficile à décrire, et encore plus à imiter. Alors comment commencer à établir une culture open source ? Quels sont les principes sous-jacents sur lesquels ces cultures sont construites? Depuis 13 ans, j’ai lu et réfléchi à ces questions, essayant de comprendre ce qui fait que certains projets open source réussissent et font échouer d’autres. Dans ce discours, je veux présenter 7 modèles mentaux et des idées surprenantes que j’ai adoptées en cours de route qui ont transformé la façon dont je pense aux affaires. Je présenterai les idées ainsi que les références aux livres dont elles sont issues et expliquerai pourquoi je crois qu’elles peuvent aider une organisation à construire une culture de type open source.