AccueilđŸ‡«đŸ‡·Chercher

Inner source

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].

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

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) assurent la qualité d'un projet open source, et donc aussi des projets inner source.

Avantages

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

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

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
  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. « Innersource | Opensource.com », sur opensource.com (consulté le )
  8. 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. 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).
Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.