Problèmes de santé des écosystèmes logiciels ouverts :
Une étude exploratoire auprès d'experts de la pratique
Mémoire
Georgia Leïda Mopenza
Maîtrise en sciences de l'administration – systèmes d'information
organisationnels – avec mémoire
Problèmes de santé des écosystèmes logiciels ouverts :
Une étude exploratoire auprès d’experts de la pratique
Mémoire
Georgia Leïda MOPENZA
Sous la direction de :
Josianne Marsan, directrice de recherche
Mathieu Templier, codirecteur de recherche
RÉSUMÉ
Aujourd’hui, les logiciels libres ou open source sont de plus en plus utilisés et peuvent servir dans certains cas de base de développement de logiciels « non libres » ou propriétaires. Le noyau Linux est utilisé par exemple pour aider dans le développement de plusieurs plateformes et logiciels comme Windows et iOS.
Le succès des logiciels open source émane du fait que, contrairement aux logiciels propriétaires, les logiciels open source sont développés dans des projets qui s’appuient sur des communautés. Les projets et leurs communautés sont compris dans des environnements plus larges appelés écosystème logiciel ouvert (ECLOO). Toutefois, ces ECLOOs font face à de nombreuses difficultés pouvant nuire à leur santé ou leur bonne marche. Le projet
SECOHealth a été initié dans le but de comprendre la santé des écosystèmes logiciels afin de
proposer des catalogues de lignes directrices et des outils de recommandation pour pouvoir mesurer et contrôler cette santé.
La recherche décrite dans ce document est une partie du projet SECOHealth. Cette recherche a pour objectif de mieux appréhender la santé des ECLOOs pour pouvoir mesurer et contrôler cette santé. Pour ce faire, nous répondrons aux trois questions de recherche suivantes :
1. Quels sont les principaux problèmes auxquels font face les ECLOOs? 2. Quelles sont les principales causes de ces problèmes?
3. Quels sont les principaux impacts de ces problèmes?
ABSTRACT
Nowadays, open source software are increasingly used and can become in some cases the basis to develop commercial or proprietary software. For example, the Linux kernel is used in developing several platforms and software like Windows and iOS.
The success of open source software stems from the fact that, unlike proprietary software, open source software are developed in projects that rely on communities. Projects and their communities are included in broader environments called open source software ecosystems (OSSECOs). However, these OSSECOs face many difficulties that can affect their health or their proper functioning. The SECOHealth project was initiated with the aim of understanding the health of software ecosystems in order to propose catalogs of guidelines and recommendation tools for measuring and controlling this health.
The research described in this document is part of the SECOHealth project. This research aims to better understand the health of open software ecosystems in order to be able to measure and control it. To do this, we will answer the following three research questions:
1. What are the main problems facing OSSECOs? 2. What are the main causes of these problems? 3. What are the main impacts of these problems?
To answer these questions, we conducted one-on-one interviews with ten experts in OSSECOs. Analysis of the data collected allowed us to construct the causal analysis
TABLE DES MATIÈRES
RÉSUMÉ ... iii
ABSTRACT ... iv
TABLE DES MATIÈRES ... v
LISTE DES TABLEAUX ... vii
LISTE DES SCHÉMAS ... viii
LEXIQUE ... x
REMERCIEMENTS ... xii
INTRODUCTION ... 1
CHAPITRE 1 : BASES CONCEPTUELLES ... 6
1.1. ÉCOSYSTÈMESLOGICIELSETLEURSCOMPOSANTS ... 6
1.1.1. Écosystèmes logiciels ... 6
1.1.2. Projets open source ... 8
1.1.3. Communautés open source ... 9
1.2. SANTÉETINDICATEURSDESANTÉ ... 12
1.3. LESPROBLÈMESDESANTÉ,LEURSCAUSESETCONSÉQUENCES ... 15
CHAPITRE 2 : MÉTHODOLOGIE ... 18
2.1. COLLECTEDEDONNÉES ... 18
2.2. ANALYSEDESDONNÉESRECUEILLIES ... 21
2.2.1. Codification des données ... 22
2.2.2. Consolidation des données codifiées : la construction d’une réponse de groupe ... 23
2.2.2.1. Défis rencontrés au cours de l’analyse des données ... 24
3.2.2.2. Cause de niveau 3 : Mauvaise direction technique du projet ... 35
3.2.3. Cause de niveau 2 : Manque de stabilité du projet ... 36
3.2.3.1. Cause de niveau 3 : Manque de stabilité du code ... 37
3.2.3.2. Cause de niveau 3 : Temps élevé de mise en œuvre de fonctionnalités38 3.2.3.3. Cause de niveau 3 : Mises à jour occasionnelles du projet ... 39
3.2.3.4. Cause de niveau 3 : Bifurcation (« fork » en anglais) des projets ... 40
3.3. CAUSECOMMUNEAUXDEUXPROBLÈMES :FAIBLENOMBREDE LIGNESDECODE(CAUSEDENIVEAU3) ... 41
3.3.1. Cause de niveau 4 : Non-intégration par les mainteneurs de patchs soumis par les contributeurs ... 42
3.3.1.1. Cause de niveau 5 : Divergence d’opinions entre mainteneurs de haut niveau ………...43
3.3.1.2. Cause de niveau 5 : Conjonction de l’incapacité des mainteneurs faisant parti du tronc à revoir les contributions et l’absence de relève ... 45
3.3.2. Cause de niveau 4 : Manque de contribution ... 46
3.3.2.1. Cause de niveau 5 : Faible nombre de patchs soumis ... 48
3.3.2.2. Cause de niveau 5 : Faible nombre de contributeurs ... 49
3.4. PROPOSITIONSBASÉESSURLESRÉSULTATS ... 50
CHAPITRE 4 : DISCUSSION ... 52
4.1. DISCUSSIONDESRÉSULTATS ... 52
4.2. RECOMMANDATIONSPOURLESPRATICIENS ... 56
4.3. RECOMMANDATIONSPOURLESFUTURESRECHERCHES ... 58
CONCLUSION ... 60
RÉFÉRENCES BIBLIOGRAPHIQUES ... 64
ANNEXES ... 74
ANNEXE A : ANALYSES CAUSALES DES DIFFÉRENTES ENTREVUES ... 75
ANNEXE B : PROCESSUS DE CONSOLIDATION DES RESULTATS DES ANALYSES CAUSALES ... 99
ANNEXE C : TABLEAU DE SYNTHÈSE DES RÉSULTAT ... 119
ANNEXE D : TABLEAU DE REGROUPEMENT DES RÉSULTATS ... 157
ANNEXE E : CHAÎNES CAUSALES DES PRINCIPAUX PROBLÈMES RETENUS ... 183
LISTE DES TABLEAUX
Tableau 1 : Types de contributeurs présents dans le modèle de l’oignon et leurs rôles ... 10
Tableau 2 : Profils des participants interviewés ... 20
Tableau 3 : Signification des catégories de codes utilisées ... 22
Tableau 4 : Exemples des extraits codés ... 28
Tableau 5 : Exemple du tableau de synthèse des résultats ... 104
Tableau 6 : Exemple du tableau de regroupement des résultats ... 105 Tableau 7 : Listes de problèmes sans causes et des problèmes avec causes de l'exemple . 108
LISTE DES SCHÉMAS
Figure 1 : Modèle général de l’oignon des communautés open source (adaptée de nakakoji et
al., 2002) ... 11
Figure 2 : Interactions dans une communauté (adaptée de carillo et al., 2017) ... 12 Figure 3 : Représentation des problèmes, leurs causes et conséquences dans un écosystème logiciel (adaptée de marois et al., 2018) ... 17 Figure 4 : Exemple de diagramme cause-effet en arborescence pour le problème d’épuisement des étudiants ... 24 Figure 5: Lien entre la mort du projet et la mort de la communauté ... 29 Figure 6 : Lien entre l'affaiblissement du projet et la mort du projet ... 29 Figure 7 : Lien entre le faible taux d'utilisation du produit développé et l'affaiblissement du projet ... 30 Figure 8 : Lien entre la faible évolution du projet et le faible nombre de releases ... 30 Figure 9 : Lien entre le manque de consensus entre contributeurs et la faible évolution du projet ... 31 Figure 10 : Lien entre la mauvaise communication entre contributeurs et le manque de consensus entre contributeurs ... 32 Figure 11 : Lien entre la présence de perspectives différentes quant aux spécialités techniques du projet et le manque de consensus entre contributeurs ... 33 Figure 12 : Lien entre la présence d'erreurs techniques dans le projet et la faible évolution du projet ... 34 Figure 13 : Lien entre la faible qualité des patchs resoumis par les contributeurs et la présence d'erreurs techniques dans le projet ... 34 Figure 14 : Lien entre la mauvaise direction technique du projet et la présence d'erreurs techniques dans le projet ... 35 Figure 15 : Lien entre le manque de stabilité du projet et la faible évolution du projet ... 36 Figure 16 : Lien entre le manque de stabilité du code et le manque de stabilité du projet .. 37 Figure 17 : Lien entre le temps élevé de mise en œuvre de fonctionnalité et le manque de stabilité du projet ... 38 Figure 18 : Lien entre les mises à jour occasionnelles et le manque de stabilité du projet .. 39 Figure 19 : Lien entre la bifurcation (« fork » en anglais) du projet et le manque de stabilité du projet ... 40 Figure 20 : Liens entre le faible nombre de lignes de code et le manque de stabilité du projet, ainsi que l'affaiblissement du projet ... 41 Figure 21 : Lien entre la non-intégration par les mainteneurs des patchs soumis par les
Figure 30 : Listes des problèmes sans causes et des problèmes avec causes ... 107
Figure 31 : Processus de création d'une chaîne causale d'un regroupement ... 109
Figure 32 : Chaîne causale de l’élément problème « épuisement des étudiants » ... 111
Figure 33 : Chaîne causale de l’élément impact « fatigue des étudiants » ... 112
Figure 34 : Chaînes causale des éléments problème et cause « conciliation vie familiale /études par certains étudiants » ... 113
Figure 35 : Chaîne causale fusionnée du regroupement de type problème « épuisement des étudiants » ... 114
Figure 36 : Chaîne causale fusionnée du regroupement de type cause « conciliation vie familiale / études par certains étudiants » ... 115
Figure 37 : Agrégation des causes de la chaîne causale fusionnée du regroupement de type problème : « épuisement des étudiants ... 116
LEXIQUE
- API – Application Programming Interface - DevOps – Development and operations - ECLO – Écosystème logiciel
- ECLOO – Écosystème logiciel open source - HTTP – HyperText Transfert Protocol
- iOS – Anciennement iPhone OS, est le système d'exploitation mobile développé par
Apple pour plusieurs de ses appareils
- IRC – Internet Relay Chat
- MySQL – My Structured Query Language
- SAP – Systems, Applications and Products for data processing - SECO – Software Ecosystem
À mes parents Suzanne et Cyprien MOPENZA.
Puisse ce travail être le triomphe de leur appui, leurs vœux, leurs prières, leur amour, leur considération et leur attention à mon égard.
REMERCIEMENTS
Ce travail est l’aboutissement d’un projet personnel qui n’aurait pu être réalisé sans l’appui et l’aide précieuse de nombreuses personnes. Au terme de ce travail, je tiens à exprimer ma profonde gratitude et mes sincères remerciements à tous mes proches, ceux qui me sont chers et qui sont toujours là pour moi particulièrement à mes parents Suzanne et Cyprien MOPENZA pour le soutien apporté. Vous n’avez en aucun cas failli à votre devoir et m’avez prouvé encore une fois que vous êtes les meilleurs grâce à tout l’amour que vous m’apportez jour après jour. Mes profonds remerciements vont également à mes frères Gilcyan, Varlet-de-Jancy, Luc-Aurore et Rayhan MOPENZA, mes compagnons de toujours qui ont su me remonter le moral face à chaque difficulté que j’ai pu rencontrer au cours de ces travaux de recherche.
Mes remerciements vont également à l’endroit du corps professoral et administratif de l’Université Laval pour la qualité de l’enseignement reçu au cours de ces trois dernières années. Merci à ma directrice Josianne Marsan et mon codirecteur Mathieu Templier pour leurs directives. Je tiens particulièrement à remercier Balla Diop pour ses encouragements, son temps et ses éclaircissements apportés lors de la rédaction de ce document.
Je tiens à remercier les experts qui ont participé à cette étude ainsi que la Linux Foundation qui nous a permis de recruter les participants à cette recherche. Je voudrais également remercier Patrick Marois qui a participé à l’exercice d’inter-codage des entrevues. Aussi, je tiens à remercier le Projet SECOHealth financé par le Programme bilatéral de recherche collaborative Québec – Communauté française de Belgique des Fonds de recherche du Québec (FRQ) et Fonds de la Recherche Scientifique (F.R.S.-FNRS).
INTRODUCTION
Jadis, les entreprises ont dû développer d’elles-mêmes des avantages concurrentiels sur le long terme pour faire face aux autres entreprises concurrentes et assurer leur survie (Porter, 1982). Cette donne a peu à peu changé vers la fin du 20e siècle (Hamel et al., 1989), où les
entreprises ont de plus en plus été amenées à coopérer avec d’autres entreprises pour faire face à la complexité accrue de l’environnement dans lequel elles évoluent et à l’interdépendance des différents marchés et technologies (Bengtsson et Kock, 1999; Tidd et Bessant, 2013). Une forme de coopération se trouve lors du développement des logiciels (Dahlander et Magnusson, 2005). Cependant, le développement logiciel n’est pas à l’abri de la complexité qui se traduit par l’existence d’une interdépendance entre les logiciels (Dahlander et Magnusson, 2005). En effet, lorsqu’il s’agit de concevoir un logiciel, on a besoin d’autres logiciels tels que les compilateurs et les interpréteurs pour faire la traduction d’un langage de programmation en langage compréhensible par les ordinateurs. On a également besoin d’une base de données, d’un système de gestion de bases de données pour gérer ces dernières, et d’un système d’exploitation. Afin de développer des logiciels, les entreprises collaborent pour obtenir une variété de compétences et de connaissances dans la programmation et ainsi créer des logiciels performants, défiant toute concurrence (Colombo
et al., 2012). C’est dans cette optique que le mouvement open source est apparu, soit dans
l’intention de concurrencer les logiciels propriétaires et d’éviter que les entreprises s’approprient l’effort conjoint des développeurs lors du développement des logiciels open
terme) ; 4) la liberté d’améliorer le programme et de diffuser les améliorations au public afin d’en faire bénéficier l’ensemble de la communauté (Rohaut, 2008). Les logiciels libres offrent plusieurs avantages parmi lesquels figurent entre autres les faibles coûts d’acquisition de licence et la possibilité de personnaliser et de faire évoluer le code source (Coris, 2000 ; Jullien, 2000 ; Jullien et Zimmermann, 2002). Allant des simples suites bureautiques aux systèmes d’exploitation en passant par les navigateurs Web et les applications d’entreprises, les logiciels libres s’invitent de plus en plus dans la vie quotidienne des entreprises(Marsan
et al., 2012).
Plusieurs logiciels open source sont développés par des contributeurs dans des projets soutenus par des communautés open source (Daniel et al., 2013). Les contributeurs au sein des projets open source et leurs communautés peuvent avoir différents rôles, allant du contributeur de code au responsable de projet, voire de communauté (Nakakoji et al., 2002). Le succès des logiciels open source nécessite que les communautés y étant rattachées soient actives et impliquées pour la conception, la réussite et la pérennité de ces logiciels (Loilier et Tellier, 2004). Ces communautés ainsi que les différents projets de développement logiciels qu’elles maintiennent sont interdépendants (Jensen et Scacchi, 2005). Par exemple, le serveur
HTTP Apache (développé par la communauté Apache) gère les transactions des artefacts Web
utilisé par le navigateur Mozilla (développé par la communauté Mozilla (Jensen et Scacchi, 2005). Avec l’arrivée des logiciels open source, on a vu apparaître plusieurs communautés et écosystèmes de logiciels. Des fondations telles que la Linux Foundation ont vu leur mission évoluer de la gestion des relations entre les communautés open source et les partenaires externes (de Laat, 2007) vers le support à l’émergence et au maintien d’écosystèmes logiciels open source afin d’accélérer le développement technologique et l’adoption des logiciels open source (Linux Foundation, 2017).
(Jansen et al., 2009). Ainsi, les écosystèmes logiciels ouverts (ECLOOs) évoluent dans un environnement qui comprend non seulement des fournisseurs de services (p. ex., formation des utilisateurs, intégration dans les systèmes déjà en place) entourant les logiciels open
source, mais également des entreprises de logiciels propriétaires ou « non libres » (Marsan et al., 2012; Marsan et Paré, 2013; Carillo et Marsan 2016). Les projets et leurs communautés
sont principalement les composants des écosystèmes logiciels (Lungu et al., 2008; Jensen et Scacchi, 2005). Une grande partie des logiciels présents dans notre vie quotidienne sont issus des projets faisant partie des ECLOOs et couvrent plusieurs domaines (p. ex., éducation, finance, divertissement) (Hess et al., 2015). Parmi ces logiciels figurent entre autres Android,
Eclipse, Linux et iOS. Ces ECLOOs et leurs composants font souvent face à différentes
problématiques telles que la bifurcation, le départ des contributeurs et les conflits entre contributeurs qui peuvent nuire à leur santé (Carillo et Marsan, 2016 ; Manikas et Hansen, 2013a; Lundell et al., 2009; Lungu et al., 2010; D’Arcy et al., 2008; Xu et al., 2015; Xu et
al., 2012).
Dans ce travail, la santé d’un ECLOO est perçue comme un état de fonctionnement normal et continu de chacun des projets et des communautés constituant l’ECLOO ainsi qu’une bonne interaction entre ces constituants (Manikas et Hansen, 2013a; Jansen, 2014). En open
source, d’un côté, on remarque que le projet et la communauté qui l’entoure sont inséparables
et fortement entrelacés (Mens, 2016). De l’autre côté, on peut observer que l’ECLOO regroupe plusieurs communautés incluant non seulement des projets interdépendants techniquement, mais également des échanges sociaux au sein des communautés et entre elles (Manikas et Hansen, 2013a). On peut donc déduire qu’il existe une interdépendance entre la santé des ECLOOs et le succès des projets open source, puisque ces derniers nécessitent que
importants qui pourraient avoir un impact sur le succès des projets ou des communautés open
source, peu sont ceux qui tiennent compte de l’environnement sociotechnique plus large
(écosystème) dans lequel travaillent et évoluent les contributeurs de ces projets (Singh et al., 2011). De plus, les responsables des composants (projets, communautés) d’un ECLOO, ne disposant que d’une vue partielle de l’impact que peuvent avoir certains événements sur l’ECLOO, ne peuvent pas toujours être en mesure de mesurer de manière globale la santé de leur ECLOO ni d’apporter des actions correctives à cet égard (Kazman et Chen, 2010; Marois
et al., 2018). Ainsi, l’objectif général de cette recherche est de mieux comprendre les dynamiques ou les mécanismes qui influencent la santé des ECLOOs pour permettre aux contributeurs et responsables des ECLOOs de mieux contrôler cette santé. Pour y arriver, nous répondrons aux questions suivantes :
1. Quels sont les principaux problèmes de santé des écosystèmes logiciels ouverts ? 2. Quelles sont les principales causes de ces problèmes de santé des
écosystèmes logiciels ouverts ?
3. Quelles sont les principales conséquences de ces problèmes de santé des écosystèmes logiciels ouverts ?
Pour répondre à ces questions, nous avons mené une enquête qualitative auprès de dix experts des ECLOOs. À partir de l’analyse du contenu des propos recueillis, nous avons produit les diagrammes d’analyse causale des entrevues et construit les chaînes causales des principaux problèmes de santé vécus par les ECLOOs.
La suite du présent document est organisée comme suit : le premier chapitre présente les bases conceptuelles de notre recherche. Ensuite, le deuxième chapitre est dédié à la méthodologie utilisée pour la collecte et l’analyse des données qui ont servi à répondre à nos questions de recherche. Enfin, les troisième et quatrième chapitres sont respectivement
de Mons), de la France (Université de Toulouse) ainsi que de l’Italie (Politecnico di Milano). Le projet SECOHealth a pour objectif de comprendre la santé des écosystèmes logiciels afin de proposer des catalogues de lignes directrices et des outils de recommandation pour pouvoir mesurer et contrôler cette santé.
CHAPITRE 1 : BASES CONCEPTUELLES
Ce chapitre est consacré à l’étude des bases conceptuelles utiles à notre recherche grâce aux recherches menées précédemment. Ces bases conceptuelles, qui sont la pierre angulaire de notre étude, nous ont permis de mener à bien notre projet. À cet effet, nous commencerons tout d’abord par définir l’écosystème logiciel ainsi que ses différents composants. Ensuite, nous présenterons le concept de santé d’un écosystème logiciel en examinant les indicateurs de santé présents dans la littérature. Enfin, nous aborderons les problèmes de santé dont on fait part dans les travaux antérieurs, leurs causes et leurs conséquences.
1.1. ÉCOSYSTÈMESLOGICIELSETLEURSCOMPOSANTS
Un écosystème logiciel (ECLO) est un ensemble de projets logiciels interdépendants partageant une plateforme technologique et maintenu par des communautés interagissant en ligne et formées de contributeurs dans ces projets (Manikas et Hansen, 2013a). Un écosystème logiciel ouvert (ECLOO) est composé des projets open source et des communautés open source qui les maintiennent (Lungu et al., 2008; Jensen et Scacchi, 2005). La sous-section suivante présentera les écosystèmes logiciels en général. Les deux autres sous-sections présenteront les composants (projets et communautés) des écosystèmes logiciels.
de plusieurs entreprises (Lungu et al., 2008). Jansen et al. (2009) de leur côté conçoivent un écosystème logiciel comme un ensemble d’entreprises qui développent des logiciels. Ces logiciels œuvrent comme un bloc et interagissent entre eux et avec d’autres logiciels présents sur le marché (Jansen et al., 2009). Ces interactions comprennent l’échange d’informations, de ressources, d’artefacts et sont souvent administrées par une plateforme ou un marché technologique commun (Jansen et al., 2009). Ces ECLOs peuvent être fermés ou propriétaires (propres à une organisation qui conçoit des logiciels propriétaires, par exemple
iOS), ouverts ou open source (lorsque plusieurs entreprises, associations ou particuliers
apportent des contributions permettant de créer des logiciels open source, par exemple
Cassandra) et/ou compris dans d’autres ECLOs (par exemple Android qui est un ECLOO
compris dans Google, un autre ECLOO plus vaste) (Jansen et al., 2009).
Manikas et Hansen (2013b) ont effectué une étude intéressante pour la compréhension du concept d’écosystème logiciel. Dans le but de montrer les domaines qui ont influencé la santé des ECLOOs, ces derniers distinguent plusieurs catégories d’écosystèmes dont les écosystèmes logiciels, les écosystèmes d’affaires ou commerciaux, les écosystèmes open
source et les écosystèmes naturels (Manikas et Hansen, 2013a). Manikas et Hansen (2013a)
ont ainsi proposé une définition de ce qu’est un écosystème logiciel grâce à une analyse des définitions présentes dans la littérature et ont pu identifier trois principaux éléments qui font d’un ensemble de logiciels un écosystème logiciel : un logiciel ou une plateforme technologique commune, une entreprise ou des intérêts communs et les relations de connexion ou interactions entre les logiciels (Manikas et Hansen, 2013a). Cependant, un bon nombre d’universitaires ne partagent pas cet avis. Pour certains chercheurs, il existe plusieurs types d’écosystèmes logiciels qui n’ont pas nécessairement une plateforme logicielle
(Manikas et Hansen, 2013a; Mens, 2016). Dans ce mémoire, nous définissons un écosystème logiciel comme une unité composée de communautés qui maintiennent des projets de développement logiciel, disposant d’un élément (plateforme, logiciel, etc.) commun et évoluant dans un environnement comprenant d’autres écosystèmes (Manikas et Hansen, 2013a). Les ECLOOs sont principalement composés de projets open source et des communautés qui les maintiennent (Lungu et al., 2008; Jensen et Scacchi, 2005).
1.1.2. Projets open source
Au cours des dernières années, le nombre de logiciels open source développés s’est avéré important. (Wen et al., 2013). Une caractéristique qui distingue un projet de développement
open source des autres projets de développement logiciel est que, plutôt que de se voir
assigner des tâches par d’autres, les contributeurs du projet open source assument de leur propre gré certains rôles en fonction de leur intérêt pour le projet (Nakakoji et al., 2002; Raymond, 1999). Généralement, l’initiateur d’un projet open source est un développeur qui, jouant le rôle de leader ou de chef de projet, cherche à résoudre un problème particulier et crée une solution (Nakakoji et al., 2002; Raymond, 1999). Cette solution est mise gratuitement à la disposition des autres personnes intéressées qui ont un intérêt à résoudre ce problème (Nakakoji et al., 2002; Raymond, 1999). Ces autres personnes, qui sont soit des développeurs, soit des utilisateurs, auront accès au code source et, avec l’initiateur, feront évoluer le projet (Nakakoji et al., 2002; Raymond, 1999). En raison de l’accès gratuit au code source, plusieurs autres contributeurs au fil du temps se joindront au projet pour l’améliorer (Nakakoji et al., 2002). Les projets open source comprennent plusieurs équipes virtuelles de contributeurs venant d’horizons et de domaines différents et évoluant dans une communauté
de la bifurcation1 des projets, du manque de contributions, du manque de sponsors ou du
manque de ressources financières (Markus et al., 2000; Fang et Neufeld, 2009). Ces échecs peuvent également être le résultat de certains événements mal gérés tels que la présence de bogues, le départ des contributeurs ou des comportements opportunistes qu’affichent certains membres au sein des communautés qui maintiennent ces projets (Markus et al., 2000; Fang et Neufeld, 2009).
1.1.3. Communautés open source
Bon nombre de logiciels et d’applications open source sont développés dans des communautés (Roberts et al., 2006). Les communautés open source sont souvent composées de plusieurs projets qui comprennent plusieurs contributeurs (Xu et al., 2006). Les contributeurs peuvent participer à différents projets au sein d’une communauté (Xu et al., 2006). Une communauté peut développer ou gérer plusieurs projets. Par exemple, la communauté Openstack gère des projets tels que Nova, Neutron et Swift. Aujourd’hui, développer un logiciel open source devient plus rentable et plus avantageux en termes de qualité qu’offre ce mode de développement qui repose sur la communauté (Mockus et al., 2000). En effet, en open source, une communauté de développement de logiciels s’appuie sur les contributions des volontaires, des particuliers et des entreprises qui affichent un intérêt pour l’open source (Roberts et al., 2006; Ye et Kishida, 2003; Lakhani et Von Hippel, 2004). Une grande partie des contributeurs présents dans les communautés open source consacrent leur temps, leurs efforts et leurs habiletés à collaborer les uns avec les autres sur des sites en ligne tels que GitHub et SourceForge (Hu et al., 2012). La participation (de façon totalement
Dans une communauté open source, les contributeurs sont généralement un groupe de développeurs soutenu par un ensemble actif d’utilisateurs (Manikas et Hansen, 2013a). Nakakoji et al. (2002) appréhendent une communauté open source sous la vue d’un oignon dans lequel on trouve plusieurs couches correspondantes aux types de contributeurs. Ils distinguent ainsi huit types de contributeurs au sein des communautés open source : les leaders, les membres principaux, les développeurs actifs, les développeurs périphériques, les correcteurs de bogues, les reporteurs de bogues, les lecteurs et les utilisateurs passifs dont les rôles respectifs sont définis dans le Tableau 1.
Tableau 1 : Types de contributeurs présents dans le modèle de l’oignon et leurs rôles Types de
contributeurs Rôles
Leaders Ils sont généralement les initiateurs des projets et donnent une vision globale à l’orientation du projet.
Membres principaux Également appelés mainteneurs dans certaines communautés, ils sont chargés de gérer le développement des projets open source. Développeurs actifs Ils apportent régulièrement de nouvelles fonctionnalités et
corrigent les bogues. Développeurs
périphériques
Ils apportent de manière occasionnelle de nouvelles fonctionnalités aux systèmes existants.
Correcteurs de bogues
Ils corrigent les bogues qu’ils ont découverts ou qui ont été découverts par les reporteurs de bogues.
Reporteurs de bogues
Ils signalent les bogues qu’ils découvrent sans pour autant lire le code source et les corriger.
Figure 1 : Modèle général de l’oignon des communautés open source (adaptée de Nakakoji et al., 2002)
gestion, de production et humain (Carillo et Marsan, 2016; Carillo et al., 2017). Dans le même courant, Carillo et al. (2017) mettent en avant la dépendance des projets open source et leurs communautés les uns envers les autres dans l’écosystème.À l’extérieur du projet et sa communauté, se trouve un environnement appelé environnement externe avec lequel il y a des échanges sous la forme d’inputs et d’outputs (Carillo et al., 2017). Il peut également y avoir des échanges (flots) à travers différents sous-systèmes dans la communauté (Carillo et
al., 2017) comme le montre la Figure 2. Les projets et/ou leurs communautés disposant d’un même environnement externe interagissent, mais peuvent également être en compétition les uns avec les autres (Carillo et al., 2017). Les communautés sont plus que de simples réseaux d’individus rendus possibles par les plateformes numériques, elles sont des entités sociales complexes et dynamiques dont le fonctionnement dépend de l’interaction entre leurs composants internes et l’environnement externe (Carillo et al., 2017).
Figure 2 : Interactions dans une communauté (adaptée de Carillo et al., 2017)
d’indicateurs de santé ayant chacun une signification et une performance différentes (Audibert, 1981; Ware, 1987; Hunt et al., 1980). La santé d’un organisme se définit comme un état de fonctionnement normal et continu de ses systèmes vitaux (Wang et Lantzy, 2011). Nous définissons ainsi dans ce travail la santé d’un ECLOO comme un état de fonctionnement normal et continu de chacun des projets et des communautés constituant l’ECLOO ainsi qu’une bonne interaction entre ces constituants (Jansen, 2014).
Plusieurs études se sont intéressées à des éléments précis de santé des composants des ECLOOs (par exemple, le succès des projets) (Jansen, 2014). En revanche, peu de recherches portent sur la santé globale de l’ECLO (Jansen, 2014). Bien souvent, dans la littérature, la santé d’un écosystème et la santé du projet sont utilisées de manière interchangeable. Tel est le cas par exemple de la recherche menée par Lundell et al. (2009) dans laquelle ils conçoivent les écosystèmes open source comme étant équivalents aux projets open source. Dans ce travail, nous considérons que la santé d’un écosystème est différente de la santé d’un projet. Aussi, on trouve différentes visions sur la manière de mesurer la santé d’un ECLO. Par exemple, pour Manikas et Hansen (2013a), la santé de l’ECLO est composée de la santé de chaque acteur individuel, du réseau d’acteurs, de chaque composant logiciel individuel, de la plateforme, de l’ensemble des logiciels, et de l’orchestrateur3. Jansen (2014) estime
qu’un indicateur d’un écosystème en santé peut être la santé des projets qui le composent. Une évaluation de la santé d’un projet comprend un regard sur le nombre de validations des modifications des versions récentes, les correctifs, le nombre de téléchargements, le temps de réponse dans les forums et les traqueurs de bogues, l’activité sur les listes de courrier électronique et les contributions des non-développeurs (p. ex. les tests effectués par les utilisateurs sur les nouvelles fonctionnalités ou l’aide qu’apportent certains utilisateurs à la
Dans le domaine de la gestion de projets, il a été démontré que la bonne marche, le succès et donc la santé d’un projet résident dans le fait que plusieurs parties prenantes venant de domaines différents apportent une pierre à l’édifice (Marchewka, 2015). Dans le domaine de l’open source, la santé des communautés et des écosystèmes va bien au-delà du développement et de la renommée des applications ou des logiciels (Singh et al., 2011; Giuri
et al., 2010; Midha et Palvia, 2012; Singh et al., 2011; Giuri et al., 2010; Méndez-Durón et
García, 2009; Subramaniam et al., 2009) ; elle touche également les aspects techniques (p. ex., le type de licence, l’architecture du code, le langage de programmation, l’activité des développeurs), voire les rapports humains tels que la motivation, le leadership, la communication et la coordination entre les membres de ces communautés et écosystèmes (Peng, Wan et Woodlock, 2013; Lakhani et Wolf, 2003; Fleming et Waguespack, 2007; Colazo et Fang, 2009; Stewart et al., 2006; Singh et Tan, 2011; Bonaccorsi et Rossi, 2003). En open source, la littérature existante s’est beaucoup plus concentrée sur la participation des développeurs et sur l’activité du projet pour évaluer la santé d’un projet et de sa communauté (Crowston et al., 2006). Des éléments tels que la taille (c’est-à-dire le nombre de contributeurs actifs) de l’équipe de développement ou de la communauté et le temps nécessaire pour corriger les bogues logiciels ont été identifiés comme certaines des mesures clés du succès (Crowston et al., 2006). De leur côté, Stewart et al. (2006) ont identifié la variation du nombre d’utilisateurs ainsi que la variation des activités de développement telle que le nombre de fonctionnalités développées au fil du temps comme mesures de succès des projets et des communautés open source. Wahyudin et al. (2007) ont examiné la notion de santé dans les projets open source. Ils ont défini la santé d’un projet open source comme étant la capacité du projet à survivre dans le temps. Un projet open source survit et se porte bien lorsque le logiciel développé dans le cadre de ce projet est utilisé par un grand nombre
1.3. LESPROBLÈMESDESANTÉ,LEURSCAUSESETCONSÉQUENCES Un problème est défini comme un écart entre une situation escomptée et une situation présente (Rivard, 2013). Pour identifier un problème, il faudrait d’abord déterminer les attentes et ensuite mesurer les écarts entre la situation actuelle et les attentes espérées (Rivard, 2013). Étant composés d’individus qui peuvent venir d’horizons différents et avoir des besoins et des comportements différents, les ECLOOs peuvent faire face à plusieurs problématiques mentionnées par plusieurs auteurs qui peuvent être autant néfastes ou faire évoluer les écosystèmes si elles sont bien gérées grâce à l’apport des mesures correctives adéquates (Manikas et Hansen, 2013a; Lundell et al., 2009; Lungu et al., 2010; Manikas et Hansen, 2013b). Parmi ces problématiques figurent entre autres l’effritement à long terme des projets et de leurs communautés ou même l’apparition des conflits interpersonnels qui peuvent pousser les contributeurs à quitter les communautés (D’Arcy et al., 2008; Xu et al., 2015; Xu et al., 2012).
Généralement, les causes des problèmes sont mixtes et relèvent de plusieurs domaines tels que le management, la gestion des ressources humaines et l’informatique (Rivard, 2013). Une cause est définie comme un fait suivi d’un autre, et ce dernier ne peut exister que si le premier fait apparaît (Hume, 1975; Marois et al., 2018). Une conséquence en revanche est la perte engendrée lorsqu’une menace (un problème dans ce contexte) surgit (Alberts et Dorofee, 2009). Évaluer les conséquences ou les impacts d’un problème permet de déterminer la gravité du problème pour lui accorder une attention spécifique (Rivard, 2013). C’est pour cette raison qu’il faut quantifier les impacts des problèmes (Rivard, 2013). Un exemple d’un problème dans une communauté open source serait une faible attirance des
al., 2009; Li, 2006; Raskauskas et Stoltz, 2007; Xu et al., 2015; Wu et al., 2007). Ils peuvent
avoir comme cause la présence d’individus « toxiques » ou « venimeux » (Carillo et Marsan, 2016). Un autre problème qu’on rencontre est la difficulté de communication dans les projets
open source en raison du manque d’interactions directes et de l’absence de structures de
gestion formelles (Herbsleb et Mockus, 2003; Herbsleb et al., 2006; Kuk, 2006; Olson et Olson, 2000; Singh et Tan, 2005). Ces problèmes peuvent engendrer comme impacts le départ de certains contributeurs des communautés open source (Filippova et Cho, 2016; Huang et al., 2016), ou la disparition des projets dans lesquels ces problèmes surviennent (Williams, 2016; Chengalur-Smith et Sidorova, 2003) ou peuvent même porter préjudice sur la viabilité à long terme des communautés (Arazy et al., 2013; Filippova et Cho, 2015). Wahyudin et al. (2007) ont identifié trois éléments qui peuvent affecter la santé d’un projet
open source : l’empressement de la communauté des développeurs, qui est un facteur
déterminant au maintien de leur motivation et à l’attractivité de nouveaux contributeurs; l’engouement des utilisateurs pour faire évoluer le projet en rapportant les bogues ou en demandant de nouvelles fonctionnalités, et enfin la qualité du produit qui fait en sorte que ce dernier défie toute concurrence, attire de nouveaux utilisateurs, augmente l’activité dans le projet, améliorant ainsi la capacité de survie du projet. Dans le contexte des communautés et projets open source vus en tant qu’organismes vivants, Carillo et Marsan (2016) estiment qu’il peut y avoir des substances toxiques susceptibles de pénétrer dans un des sous-systèmes de l’organisme, créant des problèmes qui peuvent causer plus ou moins de dommages ou n’ayant aucun effet. Ces problèmes sont causés par n’importe quel comportement, action ou interaction qui se produit dans un projet ou communauté open source. Il peut s’agir par exemple d’un message posté sur la liste de diffusion du projet, d’un commentaire suite à un rapport de bogue donné, d’un changement de code soumis dans le référentiel de code ou
Figure 3 : Représentation des problèmes, leurs causes et conséquences dans un écosystème logiciel (Adaptée de Marois et al., 2018)
Comme mentionné plus haut, le but de cette recherche est de mieux comprendre les mécanismes qui influencent la santé des ECLOOs pour permettre aux contributeurs et responsables des ECLOOs de mieux contrôler cette santé. Pour atteindre ce but, répondrons à trois questions spécifiques :
1. Quels sont les principaux problèmes de santé des écosystèmes logiciels ouverts ? 2. Quelles sont les principales causes de ces problèmes de santé des
CHAPITRE 2 : MÉTHODOLOGIE
Ce chapitre vise à présenter la méthodologie de notre recherche.Pour ce faire, nous présenterons d’abord la démarche utilisée pour la collecte des données. Nous présenterons ensuite comment nous avons procédé à l’analyse de ces données pour en arriver à construire une réponse de groupe.
2.1. COLLECTEDEDONNÉES
À la manière de Marsan et Paré (2013), nous avons effectué dans le cadre de cette recherche un « sondage qualitatif auprès d’experts » pour mieux comprendre les dynamiques ou les mécanismes qui influencent la santé des ECLOOs. Le choix du « sondage qualitatif auprès d’experts » comme méthodologie de recherche réside notamment dans le fait qu’elle est communément utilisée pour enquêter, interpréter et mieux comprendre des nouvelles thématiques ou sujets de recherche (Marsan et Paré, 2013). À cet effet, nous avons établi des critères de sélection d’experts. Établir les critères de sélection est un processus primordial dans la collecte de données (Fortin, 2010). Ce processus permet de définir les règles afin de mieux sélectionner l’échantillon utile à la compréhension d’un phénomène (Fortin, 2010). Pour délimiter la portée de notre recherche, chaque participant a été sélectionné lorsqu’il satisfaisait au minimum à un des critères de sélection suivants :
1. Être un contributeur (p. ex., gestionnaire de communauté, programmeur, testeur, producteur de documentation) actuellement actif dans un ou plusieurs ECLOOs;
ex., l’outil GrimoireLab de Bitergia, l’outil SonarQube de SonarSource, l’outil
DependencyCI);
6. Avoir été, dans les cinq dernières années, conférencier invité dans des événements d’envergure portant sur les ECLOOs tels que l’Open Source Summit et avoir eu des contacts avec des ECLOOs dans les cinq dernières années.
Les données qui ont servi à cette étude ont été recueillies lors de l’Open Source Summit tenu en octobre 2017 à Prague en République tchèque. Une série d’entrevues semi-dirigées (Miles et Huberman, 1994) auprès de dix (10) experts des ECLOOs a été effectuée conformément à un guide d’entrevue (Meyer et Booker, 2001) élaboré en collaboration avec l’équipe du projet
SECOHealth. Ce guide d’entrevue a été réalisé dans le but de répondre entre autres aux
questions de recherche du présent mémoire. Le guide d’entrevue a été validé par un chercheur du projet SECOHealth via un prétest auprès de deux (2) experts répondant aux critères d’inclusion. Le choix d’utiliser un guide d’entrevue a permis aux intervieweurs de ne pas sortir du contexte de la recherche grâce aux questions préparées d’avance et de leur rappeler les questions devant être abordées (Patton, 1990). Des questions ouvertes ont été élaborées, laissant ainsi aux participants une flexibilité dans leurs réponses (Burgess, 1982). Dans le cadre de ce mémoire, nous avons posé aux experts des questions sur la nature et la durée de leurs contributions dans des ECLOOs. Nous les avons également questionnés sur les problèmes de santé les plus importants des ECLOOs, ainsi que sur les causes et les conséquences de ces problèmes. Chaque entrevue a duré entre 40 et 120 minutes.
Notre objectif était de cibler plusieurs profils d’experts tels que les gestionnaires de projets, de communautés ou de fondations, les programmeurs, les testeurs, les producteurs de documentation. Ceci nous a permis d’avoir un échantillon constitué d’une diversité de domaines d’expertises concernant les concepts qui nous intéressent (Meyer et Booker, 2001). Le profil des participants aux entrevues est varié; certains d’entre eux sont des leaders,
Tableau 2 : Profils des participants interviewés
Numéro Langue de l’entrevue résidence Pays de d’inclusion Critère de l’expert
Type de
contribution Domaine d’expertise contribution Durée de E1 Français France 1, 2, 5, 6 Bénévole et Professionnel
— Données massives — DevOps
— Intelligence artificielle 4 ans
E2 Français États-Unis 1, 2, 5 Professionnel — Pilotes (sous-système de vidéo) 4 ans
E3 Français Finlande 1, 2, 5, 6 Bénévole et Professionnel — Multimédia (caméras, codeurs encodeurs de vidéos et affichage) 17 ans
E4 Anglais Autriche 1, 2, 5 Bénévole et Professionnel — Conseil et support en logiciels open source 6 ans
E5 Anglais Suède 1, 2 Professionnel — Recherche sur les communautés open source 6 ans
E6 Anglais États-Unis 1, 2, 5 Bénévole et Professionnel — Conseil en open source 5 ans
E7 Anglais États-Unis 1, 2, 5, 6 Bénévole et Professionnel — Recherche sur les communautés open source
Un enregistrement audio de chacune des entrevues a été fait afin de minimiser la perte de données causée par la prise de notes. Sept des dix enregistrements (dont cinq en français et deux en anglais) ont ensuite été transcrits par l’auteure de ce travail à l’aide du logiciel de traitement de texte Word et les trois autres en anglais ont été transcrits par un membre du projet SECOHealth ULaval. Ces premières transcriptions des dix entrevues ont généré 105 pages de texte. Une vérification de ces transcriptions a été ensuite effectuée par un autre membre pour chaque entrevue (dont trois par l’auteure du mémoire) pour s’assurer de la cohérence des propos et compléter les parties manquantes des premières transcriptions. Au cas où il y aurait toujours des parties manquantes après la vérification, un ou deux autres membres de l’équipe (la directrice et le codirecteur de ce mémoire) ont réécouté les sections d’enregistrements associées aux parties manquantes pour les compléter.
2.2. ANALYSEDESDONNÉESRECUEILLIES
Dans le processus d’analyse des résultats, nous avons suivi les recommandations de Miles et Huberman (1994). À cet effet, nous avons procédé à l’élaboration de codes et de tableaux. Nous avons également réalisé l’analyse causale des données recueillies. L’analyse causale est une approche qui permet de poser un diagnostic, c’est-à-dire déterminer les mauvais fonctionnements d’un système en se basant sur les problèmes rencontrés (Rivard, 2013). Cette technique a pour objectifs d’évaluer les impacts et de chercher les causes probables de chaque problème identifié et se termine quand la recherche des causes probables n’apporte plus d’informations pertinentes (Rivard, 2013). D’après Rivard (2013), l’analyse causale se
2.2.1. Codification des données
Les transcriptions d’entrevues ont été codées (Patton, 2015) par l’auteure de ce mémoire à l’aide de la version 11 du logiciel NVivo. L’analyse des donnéesa été réalisée grâce au codage de l’ensemble des entrevues et à une approche d’analyse de contenu semblable à celle que Miles
et Huberman (1994) proposent. Pour couvrir la totalité de nos questions de recherche, nous
avons élaboré un schème de codification composé de cinq (5) catégories de codes. Grâce à ces
cinq (5) catégories de codes, nous avons pu catégoriser et analyser les propos recueillis. Les cinq (5) catégories de codes qui ont été utilisées sont : problème, cause, conséquence, lien de causalité et lien de conséquence. Le Tableau 3 donne la signification de chacune des catégories de codes que nous avons élaborées sur la base des concepts mobilisés dans la technique de l’analyse causale pour codifier les propos des experts interviewés.
Tableau 3 : Signification des catégories de codes utilisées
Catégorie de code Définition
Problème Désigne un élément négatif ou une difficulté plaçant dans
une situation pénible.
Cause Désigne la raison ou la source d’un problème.
Conséquence Désigne les impacts ou effets d’un problème.
Lien de causalité
Désigne la relation entre une cause et un problème. Il est composé de deux sous-catégories de codes et peut faire référence au lien cause-problème ou au lien cause-cause (relation entre les causes de niveau n et les causes de niveau n+1).
2.2.2. Consolidation des données codifiées : la construction d’une réponse de groupe
L’analyse des extraits codés pour chacune de nos dix (10) entrevues a permis de construire un diagramme d’analyse causale par entrevue (voir annexe A), basé sur la codification des réponses individuelles des différents experts (Meyer et Booker, 2001; Rivard, 2013). Pour des fins de validation, le diagramme d’analyse causale d’une entrevue a été fait par l’auteure de ce travail puis présenté et discuté dans un atelier auquel ont participé trois autres membres de l’équipe SECOHealth ULaval. Les diagrammes d’analyse causale de quatre (4) autres entrevues ont ensuite été faits par l’auteure du mémoire et présentés et discutés avec la directrice de ce mémoire. Finalement, l’auteure de ce mémoire a fait seule les diagrammes d’analyse causale des cinq (5) dernières entrevues.
L’analyse causale permet ultimement de construire un diagramme cause-effet qui peut prendre la forme d’un diagramme en arborescence (Rivard, 2013). Rivard (2013) explique comment, en partant des conséquences, on peut construire un diagramme en arborescence et déterminer les éléments des niveaux suivants à partir des précédents, jusqu’au dernier niveau :
1. Au niveau 0 du diagramme en arborescence, figurent les conséquences.
2. Les causes de niveau 1 correspondent aux problèmes. Ils sont déterminés à partir des conséquences. Chaque problème sera ainsi lié à sa (ses) conséquence(s). Le passage des conséquences aux causes de niveau 1 est déterminé grâce à la réponse à la question suivante : « Quelles est la/les raison(s) qui a/ont engendré cette conséquence ? ». Cet exercice est répété pour chacune des conséquences présentes. 3. Les causes de niveau 2 inscrites dans le diagramme seront liées aux causes de
niveau 1 (ou problèmes). Ces causes sont déterminées à partir des causes de niveau 1 et ainsi de suite. Le passage d’un niveau n à un niveau n+1 est formé grâce à la réponse à la question suivante : « Quelles est la/les raison(s) qui a/ont engendré cette
déclenche. Dans les différents diagrammes que nous avons construits, cette combinaison est représentée par le signe plus (+) entouré d’un cercle.
Une représentation à l’aide d’un diagramme cause-effet en arborescence du problème d’épuisement observé auprès d’étudiants, par exemple, est présentée à la Figure 4.
Figure 4 : Exemple de diagramme cause-effet en arborescence pour le problème d’épuisement des étudiants
concernant les différents diagrammes d’analyse causale nous ont guidé dans la construction de cette réponse de groupe.
Premièrement, certains problèmes répertoriés dans les diagrammes d’analyse causale n’ont pas de causes. Cela s’explique par le fait que nous n’avons pas construit les diagrammes d’analyse causale avec les experts pendant les entrevues; ils ont été construits a posteriori sur la base des transcriptions des entrevues. De plus, les experts se sont concentrés à identifier les causes des problèmes qu’ils jugeaient les plus importants à discuter dans le temps alloué à l’entrevue.
Deuxièmement, on remarque une certaine similitude entre certains problèmes mentionnés par différents participants. Par exemple, le « départ des contributeurs » est mentionné par un expert comme étant un problème, un deuxième expert précise ses propos et mentionne « départ des contributeurs du projet » et « départ des contributeurs dans des grands projets » comme des problèmes alors que pour un troisième expert, le « départ des entreprises des
projets » est un problème. On perçoit aussi par exemple qu’un participant mentionne la
présence de « communications conflictuelles entre contributeurs » comme un problème, un deuxième invoque comme problème « l’absence de saine collaboration entre les
programmeurs », et un troisième admet que les « frictions entre mainteneurs et programmeurs » est un problème.
Troisièmement, on remarque que certains éléments sont considérés comme des problèmes par certains participants alors que pour d’autres, les mêmes éléments sont considérés comme des impacts de problèmes ou des causes de problèmes. Par exemple, la bifurcation du projet
participants quant à eux envisagent le départ des contributeurs (mainteneurs seniors ou ceux qui sont arrivés récemment dans la communauté) comme un impact de plusieurs problèmes comme l’exténuation des mainteneurs à répéter les mêmes choses ou le sentiment des nouveaux contributeurs d’être rejetés par les anciens. Le départ des contributeurs est aussi perçu par certains participants comme la cause de nombreux problèmes tels que le contrôle de la communauté par certaines entreprises et un faible nombre de contributions dans le projet.
Au regard de ces trois constats, nous avons opté pour la démarche illustrée à l’annexe B. Essentiellement, cette démarche consiste en la consolidation des diagrammes d’analyse causale par le regroupement des éléments similaires identifiés par les différents experts. Dans l’annexe B, nous décrivons le processus de consolidation en détails pour le lecteur éventuellement intéressé à le reproduire.
Dans ce chapitre, nous avons présenté notre méthodologie de recherche. Le chapitre suivant sera entièrement consacré à la présentation des résultats de notre recherche.
CHAPITRE 3 : RÉSULTATS
Ce chapitre vise à présenter les résultats obtenus au cours de cette recherche. À cet effet, sera présenté dans la première section de ce chapitre le premier problème de santé des ECLOOs observé, son principal impact ainsi que ses causes les plus immédiates. La deuxième section du chapitre sera consacrée à la présentation du second problème de santé des ECLOOs observé, son principal impact ainsi que ses causes les plus immédiates. Étant donné qu’il est nécessaire de comprendre les premiers niveaux de causes pour analyser plus en profondeur l’ensemble de la chaîne causale, le présent mémoire, en tant que premier essai de compréhension des causes des problèmes de santé des ECLOOs, se limite à présenter en détails les causes les plus « immédiates » (les causes de niveaux 2 et de niveaux 3) des problèmes. Les autres causes sont mentionnées dans les diagrammes en Annexe, mais ne seront pas présentées en détails. Dans cette recherche, nous avons trouvé une seule cause de niveau 3 qui est commune aux deux problèmes. Ainsi, nous avons jugé pertinent de présenter dans une section à part cette cause de niveau 3 commune qu’est le faible nombre de lignes de code ainsi que ses principales causes immédiates, i.e. de niveaux quatre (4) et cinq (5). Aussi, à la fin de ce chapitre, seront présentées les propositions basées sur les résultats. Comme mentionné plus haut, le présent document a pour principal objectif de comprendre la santé des ECLOOs à travers la détermination des principaux problèmes de santé, leurs principales causes et leurs principaux impacts. Le Tableau 4 donne un exemple de codification de propos recueillis (extraits d’entrevues) pour chacune des catégories de codes que nous avons présentées précédemment au Tableau 3.
Tableau 4 : Exemples des extraits codés
Catégories de codes Exemples de propos recueillis
Problème
« … c’est compliqué… effectivement la gestion de
l’Application Programming Interface (API) ou en français interface de programmation applicative au travers de ses cycles de releases4. C’est un choix qui est très complexe… »
Cause « … l’API est juste surcompliqué, il n’y a pas eu de refactoring5. On n’ose jamais […] faire [… de refactoring
du] code source… »
Impact « Ça laisse finalement une place béante pour des nouveaux projets qui font quasiment la même chose » Lien de causalité
« Peut-être le degré d’engagement qu’on a […] quand on va appliquer une action. On ne se rend pas compte que… des fois des actions très simples… peuvent prendre beaucoup, beaucoup de temps. »
Lien de conséquence « Problèmes de communication entre quelques individus, incapacité à les résoudre et [le projet] est mort […] de sa p’tite mort quoi. »
Le processus de consolidation nous a permis de construire deux chaînes causales (voir annexe E) des problèmes retenus. Ces deux problèmes sont : la mort du projet et la faible évolution du projet. Chaque chaîne causale synthétise un des problèmes retenus, ses principales causes et ses principaux impacts. Les prochaines sections de ce chapitre seront consacrées à la présentation de ces problèmes, leurs principaux impacts ainsi que leurs causes les plus immédiates.
3.1. MORTDUPROJET(PROBLÈME1)
D’après Nakakoji et al. (2002), une communauté open
source comprend huit types de contributeurs : les leaders,
les membres principaux, les développeurs actifs, les développeurs périphériques, les correcteurs de bogues, les reporteurs de bogues, les lecteurs et les utilisateurs passifs. Ainsi, la mort d’une communauté peut faire allusion à sa disparition, son arrêt complet ou encore à la cession définitive des activités de ces types de contributeurs. La mort d’un projet sous-entend son échec (English et Schweik, 2007). Dans nos résultats, nous avons trouvé que la mort du projet est un des problèmes auxquels font face
les ECLOOs. La mort du projet peut entrainer la disparition de la communauté dans laquelle se trouve ce projet. Ce problème a été mentionné par 8 des 10 experts interviewés. Pour illustrer ce constat, voici un extrait des propos recueillis auprès d’un expert : « Par exemple
le projet [nom du projet] a disparu et sa communauté avec […]. J’ai vu plusieurs communautés mourir […] juste parce que […] le projet peut mourir très vite. » (Expert 9).
3.1.1. Cause de niveau 2 : Affaiblissement du projet
L’affaiblissement d’un projet désigne la perte de force ou de vigueur d’un projet au point où il ne parvient plus à réaliser ses
Figure 5: Lien entre la mort du projet et la mort de la communauté
Figure 6 : Lien entre l'affaiblissement du projet et la mort du projet
3.1.1.1. Cause de niveau 3 : Faible taux d’utilisation du produit développé
Le faible taux d’utilisation du produit développé dans un projet fait allusion à un faible nombre d’utilisateurs du logiciel développé dans le cadre de ce projet (Lee et al., 2009). Les résultats de cette recherche montrent qu’un faible taux d’utilisation des produits développés dans le cadre des projets
open source est à l’origine de l’affaiblissement de ces projets. En
ce sens, un des experts interviewés affirme : « … lorsque j'essaie
de décider, en tant qu’un consommateur d'un produit [logiciel open source], de l'utiliser ou non, je regarde tous les autres projets [open source] qui l'utilisent [ce produit]. En ce moment, je constate qu'il est largement utilisé et que ce n'est pas un projet susceptible d'être affaiblit … » (Expert 7) (Traduction libre)
3.2. FAIBLEÉVOLUTIONDUPROJET(PROBLÈME2) L'évolution d’un projet consiste en l’ajout des
fonctionnalités supplémentaires à un système logiciel existant (Buchta et al., 2006). Contrairement à cela, la faible évolution d’un projet représente une croissance ou une progression non significative ou encore un avancement non considérable du projet (Tu, 2000 ; Capiluppi et al., 2003).
Figure 7 : Lien entre le faible taux d'utilisation du produit développé et l'affaiblissement du projet
Figure 8 : Lien entre la faible évolution du projet et le faible nombre de releases
releases désigne un faible nombre de nouvelles versions du logiciel offert. En ce sens, un
des experts interviewés estime que : « [L]e projet devient complexe à maintenir et à faire
évoluer […] et donc on assiste à […] un faible nombre de releases dans ces projets-là. »
(Expert 1)
3.2.1. Cause de niveau 2 : Manque de consensus entre contributeurs
Le manque de consensus entre contributeurs fait allusion à l’absence de consentement ou de commun accord entre les contributeurs à propos des décisions à prendre dans un projet (Tawileh et al., 2006). Dans nos résultats, nous avons trouvé qu’un manque de consensus entre contributeurs provoque une faible évolution du projet. À ce propos, un expert affirme que : « [C]e sont des gens, […] en arrivant à des
consensus, qui finissent par évoluer puis avoir, à mon avis, la capacité de grossir, puis de grossir en santé. » (Expert 4)
(Traduction libre).
Figure 9 : Lien entre le manque de consensus entre contributeurs et la faible évolution du projet
3.2.1.1. Cause de niveau 3 : Mauvaise communication entre contributeurs
Une mauvaise communication entre contributeurs représente des échanges ou des conversations inopportunes entre les contributeurs (Bird et al., 2008; Kemper et al., 2017). La mauvaise communication entre contributeurs fait également allusion à l’absence d’échanges ou de conversations entre les contributeurs (Kemper et al., 2017). L’analyse des données recueillies montre qu’une mauvaise communication entre contributeurs engendre un manque de consensus entre eux. Dans ce contexte, un expert note que : « […]
après un certain point, si vous n'êtes pas d'accord avec les autres, c’est ce que vous n’avez pas pris la peine de bien communiquer. » (Expert 8) (Traduction libre).
Figure 10 : Lien entre la
mauvaise communication
entre contributeurs et le manque de consensus entre contributeurs
3.2.1.2. Cause de niveau 3 : Présence de perspectives différentes quant aux spécialités techniques du projet
La présence de perspectives différentes désigne l’existence de points de vue, d’opinions ou de visions contradictoires (Wilkinson et Links, 2002) entre contributeurs sur les spécialités techniques (ou fonctionnalités) à mettre en place dans un projet. Nous avons trouvé que lorsque les contributeurs ont plusieurs visions différentes sur ces spécialités, on assiste à un manque de consensus entre les contributeurs. En ce sens, un expert déclare que : « les contributeurs se séparent simplement parce
qu’ils n’aiment pas le fait que dans le projet il n’y ait pas de consentement nécessaire sur les différentes opinions concernant les spécialités ou quoi que ce soit du côté technique. » (Expert 4)
(Traduction libre)
Figure 11 : Lien entre la présence de perspectives différentes quant aux spécialités techniques du projet et le manque de consensus entre contributeurs
3.2.2. Cause de niveau 2 : Présence d’erreurs techniques dans le projet
Les erreurs techniques représentent les actes ou les opinions involontaires commis par les contributeurs pouvant réduire la qualité et l’efficacité d’un projet et du logiciel développé dans le cadre de ce projet (Ripoche et Gasser, 2003). L’analyse du contenu révèle que la présence d’erreurs techniques dans le projet est l’une des principales causes pouvant conduire à la faible évolution des projets. Dans ce contexte, un expert estime que « lorsque les
erreurs dans le code soumis par les contributeurs ne sont pas corrigées et intégrées telles quelles dans le code source, on peut assister à un ralentissement du projet »
(Expert 2).
3.2.2.1. Cause de niveau 3 : Faible qualité des patchs resoumis par les contributeurs
Hertel et al. (2003) considèrent qu’un
patch est l’ensemble de plusieurs lignes
de code constituant une contribution et soumis sous la forme d'un fichier
Figure 12 : Lien entre la présence d'erreurs techniques dans le projet et la faible évolution du projet
Figure 13 : Lien entre la faible qualité des patchs resoumis par les contributeurs et la présence d'erreurs techniques dans le projet
Un code de mauvaise qualité peut contenir plusieurs erreurs. On note dans nos résultats que lorsque la qualité des patchs soumis initialement par les contributeurs est faible et que le niveau d’expertise technique des vérificateurs de patchs (mainteneurs) est élevé, ces vérificateurs demandent aux contributeurs ayant soumis ces patchs d’y apporter des corrections. Ces demandes de correction, associées au refus d’apprentissage des contributeurs ayant soumis ces patchs de mauvaise qualité, les emmènent à resoumettre des
patchs de mauvaise qualité qui se retrouvent parfois, intégrés malencontreusement dans le
code source et cela cause des erreurs techniques dans le projet. À ce titre, comme le note un expert : « beaucoup de patchs contiennent des fautes … si ces erreurs ne sont pas corrigées,
des erreurs techniques peuvent subvenir dans le projet. » (Expert 8) (Traduction libre)
3.2.2.2. Cause de niveau 3 : Mauvaise direction technique du projet
Une mauvaise direction technique désigne une orientation inadéquate d’un point de vue technique (Fogel, 2005). L’analyse des données recueillies montre qu’une mauvaise prise de direction technique dans le projet cause des erreurs techniques dans le projet. Selon un expert : « […]
on ne prend pas la bonne direction d’un point de vue technique […] et au
Figure 14 : Lien entre la mauvaise direction technique du projet et la présence d'erreurs techniques dans le projet
3.2.3. Cause de niveau 2 : Manque de stabilité du projet
Le manque de stabilité d’un projet réfère au caractère fragile du projet. Un projet instable est un projet vulnérable au moindre changement ou modification apporté (Huang et
al., 2005). Nous avons trouvé
que le manque de stabilité du projet peut être une cause directe de la faible évolution des projets. Dans ce contexte, un expert affirme : « Eh bien, le
projet est assez stable depuis
quelques temps […] Il est flexible et évolue en santé. » (Expert 7) (Traduction libre)
Figure 15 : Lien entre le manque de stabilité du projet et la faible évolution du projet
