Aller au contenu

Inner source

Un article de Wikipédia, l'encyclopédie libre.

L’inner source, ou innersource en un seul mot[1], est l'adoption des pratiques de développement logiciels open source et l'établissement d'une culture de type open source au sein même d'une organisation[2]. Le concept d’inner sourcing a été inventé et exposé par Tim O'Reilly en 2000[3],[4]. D'autres désignations existent : corporate open source, internal open source, progressive open source[5].

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[6],[7].

Pratiques open source utilisées

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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

Au-delà des attributs de qualité logicielle source, les retours d’expérience ont montré certains avantages suivants[8] : développement plus efficace et plus efficient, briser l’effet silo des organisations, une meilleure réutilisation, utilisation des compétences manquantes chez les fournisseurs de composants, meilleure indépendance entre les réutilisateurs et les fournisseurs, pression moindre pour les fournisseurs de composants, meilleur produit logiciel, amélioration de la qualité du code, des développements plus innovants, une utilisation plus flexible des développeurs, meilleure gestion des connaissances, plus grande motivation des employés[9],[8].

Prévalence

[modifier | modifier le code]

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

Facteurs clés pour l’adoption de l’inner source

[modifier | modifier le code]

L’inner source 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[16].

Notes et références

[modifier | modifier le code]
  1. (en) Understanding the InnerSource Checklist by Silona Bonewald : « The term we are using was coined by Tim O’Reilly more than 15 years ago. Originally, it was “Inner Source,” but we removed the space between the words so that the term is findable in a search. »
  2. (en) Capraro et Riehle, « Inner Source Definition, Benefits, and Challenges », ACM Computing Surveys, vol. 49, no 4,‎ , 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. »

  3. Ven van 't ende, « InnerSource: An Open Source Approach to Community Culture »,  : « 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.” »
  4. O'Reilly, « Open Source and OpenGL » [archive du ], oreilly.com, O'Reilly and Associates, (consulté le ) : « [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. ».
  5. (en) Martin Höst et al, Inner Source Project Management, chap. 14 de Software Project Management in a Changing World, Springer, 21 may 2014, pp. 343-369.
  6. Stol, Klaas-Jan; Fitzgerald, Brian, « Inner source—adopting open source development practices within organizations: a tutorial », IEEE Software,‎ (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. »

  7. a et b « Innersource | Opensource.com », sur opensource.com (consulté le )
  8. a et b Stol et Fitzgerald, « Inner Source - Adopting Open Source Development Practices within Organizations: A tutorial », IEEE Software, vol. 32, no 4,‎ , p. 60–67 (ISSN 0740-7459, DOI 10.1109/MS.2014.77, lire en ligne)
  9. a et b Capraro et Riehle, « Inner Source Definition, Benefits, and Challenges », ACM Comput. Surv., vol. 49, no 4,‎ , p. 67:1–67:36 (ISSN 0360-0300, DOI 10.1145/2856821, lire en ligne)
  10. Microsoft Internal Solorigate Investigation Update (lire en ligne)
  11. Andy Oram, Getting Started with InnerSource, O’Reilly Media, Inc., (ISBN 978-1-491-93758-7, lire en ligne)
  12. Jared Smith, Using open source methods for internal software projects, O’Reilly Media, Inc., (lire en ligne)
  13. « Commit San Francisco 2020 : Shucking Corporate Oysters-Kickstarting an Innersource Culture @ T-Mobile » (consulté le )
  14. (en-US) « Watch: Creating an Inner Source Hub at Siemens », JFrog, (consulté le )
  15. (en-US) Senior Writer, « How Wal-Mart enables ‘innersource’ with Github », sur CIO (consulté le )
  16. Stol, Avgeriou, Babar et Lucas, « Key factors for adopting inner source », ACM Transactions on Software Engineering and Methodology, vol. 23, no 2,‎ , p. 1 (DOI 10.1145/2533685).