« Inner source » : différence entre les versions

Contenu supprimé Contenu ajouté

Intégrés

Version du 27 août 2021 à 14:15

L’innersource est l'utilisation des bonnes pratiques de développement logiciels open source et l'établissement d'une culture de type open source au sein des organisations ^[1] pour le développement de ses logiciels non open source et/ou propriétaires. Le terme a été inventé par Tim O'Reilly en 2000 ^[2] dans une de ses publications. ^[3]

Objectif

L'open source est reconnu pour être capable de fournir des logiciels de haute qualité. De plus, la collaboration ouverte en open source permet une collaboration même entre concurrents (par ex. ARM et Intel travaillant sur le noyau Linux avec un modèle décisionnel basé sur le mérite).

Par conséquent, les organisations développant du logiciel veulent bénéficier des résultats des développements (les composants logiciels et les outils), mais aussi des pratiques de développement exercées et établies dans le monde open source. ^[4]

Pratiques open source utilisées

Outre plusieurs pratiques établies dans des fondations telles que la fondation Apache, la fondation Linux et la fondation Eclipse, les projets innersource et opensource nécessitent une collaboration ouverte, une communication ouverte et une assurance qualité appropriée.

Collaboration ouverte

Tous les artefacts de développement requis (par exemple, le code, la documentation, le suivi des problèmes, etc.) doivent être accessibles à tous les employés d'une entreprise tirant parti de l’innersource. Les forges logicielles centralisées sont un outil essentiel pour mettre en œuvre une collaboration ouverte.

Sur la base des principes de collaboration ouverte ( égalitaire, méritocratique et auto-organisé), tout contributeur désireux d'aider un projet innersource est généralement le bienvenu. Les contributions aux projets innersource sont généralement jugées en fonction de la valeur qu'elles apportent au projet, par la méritocratie. La méritocratie peut également être rendue possible par une communication ouverte puisque les décisions sont discutées publiquement. Bien qu'une organisation ne devienne pas nécessairement complètement auto-organisée pour adopter l’innersource, l’innersource permet aux individus, aux unités organisationnelles et aux communautés de projet un degré plus élevé d'auto-organisation.

Communication ouverte

Les projets et programmes innersource reposent sur une communication ouverte pour rendre toute communication directement accessible à tous les employés. La communication ouverte est une communication publique (au sein de l'entreprise), écrite, archivée et complète. En conséquence, la communication se fait de manière asynchrone. L'objectif est de permettre à toute personne ou partie qui a un intérêt dans un projet innersource de participer à la communication. Au fur et à mesure que les discussions de communication ouvertes sont archivées, elles constituent une documentation détaillée et centralisée du logiciel, ce qui permet de revoir les discussions et les décisions historiques en examinant les communications passées.

Assurance qualité par la séparation entre contribution et intégration

Une revue de code dédiée, et la distinction entre contributeurs et committers (intégrateurs, développeurs avec accès en écriture) assure la qualité d'un projet open source, et donc aussi des projets innersource.

Avantages

Au-delà des attributs de qualité logicielle source, les retours d’expérience ont montré les avantages suivants : ^[5] ^[6]

Un développement plus efficace et plus efficient

Une plus grande rapidité de mise sur le marché
Des coûts de développement réduits

Briser l’effet silo des organisations

Un meilleur partage des coûts et des risques entre les unités organisationnelles
Une collaboration au-delà des limites des unités organisationnelles
Des échanges d'information à l'échelle du logiciel

Une meilleure réutilisation

L’utilisation des compétences manquantes chez les fournisseurs de composants
Une meilleure indépendance entre les réutilisateurs et les fournisseurs
Une pression moindre pour les fournisseurs de composants

Un meilleur produit logiciel

amélioration de la qualité du code
Des développements plus innovants

Une utilisation plus flexible des développeurs

Un déploiement simplifié des développeurs
La collaboration entre développeurs d’équipes différentes

Une meilleure gestion des connaissances

L’apprentissage par la communauté
L’ouverture et la disponibilité des connaissances

Une plus grande motivation des employés

Prévalence

Entre autres, les sociétés suivantes sont connues pour avoir adopté l’innersource : ^[5]

Facteurs clés pour l’adoption de l’innersource

L’innersource peut être une approche prometteuse pour les grandes organisations qui développent du logiciel. Cependant, il peut ne pas être approprié dans tous les contextes. Les neuf facteurs suivants, regroupés en trois catégories, peuvent être mise en exergue pour évaluer dans quelle mesure l’innersource peut être approprié. ^[12]

Les facteurs liés au produit

Créer un produit initial pour attirer une communauté
Avoir des intervenants multiples pour des contributions variées
Fournir de la modularité pour attirer les contributeurs et les utilisateurs

Facteurs liés aux processus et outils

Favoriser les pratiques qui encouragent le développement « à la manière du bazar »
Favoriser les pratiques qui encouragent l'assurance qualité « à la manière du bazar »
Travailler à la standardisation des outils pour faciliter la collaboration

Facteurs organisationnels et communautaires

Organiser la coordination et le leadership pour accompagner l’émergence d’une méritocratie interne
Prôner la transparence pour ouvrir l'organisation
Fournir l’appui et la motivation du management pour impliquer les personnes

Les références

↑ (en) Capraro et Riehle, « Inner Source Definition, Benefits, and Challenges », ACM Computing Surveys, vol. 49, n^o 4,‎ 6 février 2017, p. 1–36 (ISSN 0360-0300, DOI 10.1145/2856821, lire en ligne) :
« Inner source (IS) is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development. »
↑ Ven van 't ende, « InnerSource: An Open Source Approach to Community Culture », 9 mai 2016 : « Tim O’Reilly, the founder of O’Reilly Media, coined the term “inner-sourcing” in 2000, describing it as: “the use of open source development techniques within the corporation.” »
↑ O'Reilly, « Open Source and OpenGL » [archive du 15 février 2015], oreilly.com, O'Reilly and Associates, 1^er décembre 2000 (consulté le 22 février 2017) : « [W]e've also worked with companies on what we call “inner sourcing” — that is, helping them to use open source development techniques within the corporation. »
↑ Stol, Klaas-Jan; Fitzgerald, Brian, « Inner source—adopting open source development practices within organizations: a tutorial », IEEE Software,‎ 2014 (DOI 10.1109/MS.2014.77, lire en ligne) :
« [...] a number of organizations have adopted open source practices to develop their software. [...] Unlike traditional approaches, developers of an inner source project do not belong to a single team or department. Instead, anybody within the confines of the organization can become a contributing member of this internal community, either as a user or contributor. »
↑ ^{a et b} Capraro et Riehle, « Inner Source Definition, Benefits, and Challenges », ACM Comput. Surv., vol. 49, n^o 4,‎ 1^er décembre 2016, p. 67:1–67:36 (ISSN 0360-0300, DOI 10.1145/2856821, lire en ligne) Erreur de référence : Balise <ref> incorrecte : le nom « :0 » est défini plusieurs fois avec des contenus différents.
↑ Stol et Fitzgerald, « Inner Source - Adopting Open Source Development Practices within Organizations: A tutorial », IEEE Software, vol. 32, n^o 4,‎ 1^er juillet 2015, p. 60–67 (ISSN 0740-7459, DOI 10.1109/MS.2014.77, lire en ligne)
↑ Microsoft Internal Solorigate Investigation Update (lire en ligne)
↑ Andy Oram, Getting Started with InnerSource, O’Reilly Media, Inc., 2015 (ISBN 978-1-491-93758-7, lire en ligne)
↑ Jared Smith, Using open source methods for internal software projects, O’Reilly Media, Inc., 2016 (lire en ligne)
↑ https://www.youtube.com/watch?v=pTssFh1qLwk
↑ (en-US) « Watch: Creating an Inner Source Hub at Siemens », JFrog, 28 juillet 2020 (consulté le 9 décembre 2020)
↑ Stol, Avgeriou, Babar et Lucas, « Key factors for adopting inner source », ACM Transactions on Software Engineering and Methodology, vol. 23, n^o 2,‎ 2014, p. 1 (DOI 10.1145/2533685)

[1] (en) Capraro et Riehle, « Inner Source Definition, Benefits, and Challenges », ACM Computing Surveys, vol. 49, n^o 4,‎ 6 février 2017, p. 1–36 (ISSN 0360-0300, DOI 10.1145/2856821, lire en ligne) :
« Inner source (IS) is the use of open source software development practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software but internally opens up its development. »

[2] Ven van 't ende, « InnerSource: An Open Source Approach to Community Culture », 9 mai 2016 : « Tim O’Reilly, the founder of O’Reilly Media, coined the term “inner-sourcing” in 2000, describing it as: “the use of open source development techniques within the corporation.” »

[3] O'Reilly, « Open Source and OpenGL » [archive du 15 février 2015], oreilly.com, O'Reilly and Associates, 1^er décembre 2000 (consulté le 22 février 2017) : « [W]e've also worked with companies on what we call “inner sourcing” — that is, helping them to use open source development techniques within the corporation. »

[4] Stol, Klaas-Jan; Fitzgerald, Brian, « Inner source—adopting open source development practices within organizations: a tutorial », IEEE Software,‎ 2014 (DOI 10.1109/MS.2014.77, lire en ligne) :
« [...] a number of organizations have adopted open source practices to develop their software. [...] Unlike traditional approaches, developers of an inner source project do not belong to a single team or department. Instead, anybody within the confines of the organization can become a contributing member of this internal community, either as a user or contributor. »

[:0-5] {a et b} Capraro et Riehle, « Inner Source Definition, Benefits, and Challenges », ACM Comput. Surv., vol. 49, n^o 4,‎ 1^er décembre 2016, p. 67:1–67:36 (ISSN 0360-0300, DOI 10.1145/2856821, lire en ligne) Erreur de référence : Balise <ref> incorrecte : le nom « :0 » est défini plusieurs fois avec des contenus différents.

[:10-6] Stol et Fitzgerald, « Inner Source - Adopting Open Source Development Practices within Organizations: A tutorial », IEEE Software, vol. 32, n^o 4,‎ 1^er juillet 2015, p. 60–67 (ISSN 0740-7459, DOI 10.1109/MS.2014.77, lire en ligne)

[7] Microsoft Internal Solorigate Investigation Update (lire en ligne)

[8] Andy Oram, Getting Started with InnerSource, O’Reilly Media, Inc., 2015 (ISBN 978-1-491-93758-7, lire en ligne)

[9] Jared Smith, Using open source methods for internal software projects, O’Reilly Media, Inc., 2016 (lire en ligne)

[10] ttps://www.youtube.com/watch?v=pTssFh1qLwk

[11] (en-US) « Watch: Creating an Inner Source Hub at Siemens », JFrog, 28 juillet 2020 (consulté le 9 décembre 2020)

[KeyFactors2014-12] Stol, Avgeriou, Babar et Lucas, « Key factors for adopting inner source », ACM Transactions on Software Engineering and Methodology, vol. 23, n^o 2,‎ 2014, p. 1 (DOI 10.1145/2533685)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]