La gouvernance et la division du travail dans les communautés open source

L’un des premiers écrits informant sur la manière dont le développement de logiciels libres s’organisait est le texte de Raymond intitulé « The Cathedral and the Bazaar ». Raymond oppose deux styles de développement : d’un côté, le style de la cathédrale caractérisé par un développement où des génies isolés en petits groupes travaillent dans une formidable isolation, sans qu’une version beta ne soit lancée avant que son heure ne soit venue ; d’un autre côté, le style de Linus Torvald ressemblant à un grand « bazaar » polyglotte associant différentes approches et manières de développer (Raymond 2000: 2-3).

(I) Motivations internes (II) Motivations externes

(1) Motivation intrinsèque (2) Altruisme (3) Identification à la communauté (1) Récompenses futures (2) Besoins personnels

(1a) Vendre des produits liés

(1b) Développer ses compétences

(1c) Publicité personnelle

Partie I. Chapitre 3. Les débats de la littérature sur les formes d’organisations de l’open source.

Dans un premier temps, la littérature considéra que les communautés de l’open source n’étaient régulées par aucune règle et étaient largement auto-organisées à la manière du

« bazaar ». Le point de départ de cette idée est le travail de Raymond selon qui le processus

de développement des logiciels libres est comme une place de marché (« bazaar ») où tout le monde peut participer et contribuer dans une atmosphère créative et démocratique (Hertel et al. 2003: 1161).

Rapidement, un grand nombre d’auteurs reprirent cette métaphore et défendirent l’idée que les communautés fonctionnaient sans hiérarchie. Raymond eut une influence très importante sur la littérature puisque son texte figure dans la bibliographie d’un grand nombre d’articles académiques traitant de l’open source (Baldwin et Clark 2006: 1127; Bonaccorsi, Giannangeli, et Rossi 2006: 1098; Cusumano 2004: 27; Dahlander et Magnusson 2005: 493), il est largement considéré comme un classique incontournable dans ce champ de recherche.

Demil et Lecoq ont défendu la thèse que les processus de développement des logiciels libres étaient ni réalisés hiérarchiquement, ni grâce à un mode de coordination marchand, ni en réseau mais à la manière du bazar de Raymond (Demil et Lecocq 2005: 3). Pareillement, d’autres auteurs ont soutenu l’idée que le développement de logiciels libres était réalisé sans coordination hiérarchique entre les acteurs (Elliott et Scacchi 2003: 7) avec toutefois quelques cas particuliers (Garzarelli 2003: 7) comme lorsque le développement est réalisé par une seule entreprise (Henkel 2003b: 7).

D’un autre côté, Bezroukov a contredit Raymond en affirmant que le développement de logiciels libres était comparable à la manière dont la communauté scientifique s’organisait (Hertel et al. 2003: 1161). Kogut et Metiu ont également très tôt souligné qu’une hiérarchie émergeait parmi les développeurs et que celle-ci avait pour mission d’encadrer le développement des logiciels libres (Kogut et Metiu 2000: 2). D’autres universitaires ont par la suite appuyé cette thèse comme Shaikh et Cornford (2003: 128) ou Gauguier (2005: 8).

Il y a un évident paradoxe dans la littérature : certains suggèrent que les logiciels libres sont développés sans hiérarchie et d’autres soutiennent qu’au contraire, il y a bel et bien une hiérarchie. Face à ce débat, nous pensons qu’il est nécessaire de revenir sur ce que les uns et les autres considèrent comme être une hiérarchie. Dans sa thèse, Grassineau a réalisé une analyse critique approfondie de la notion de hiérarchie. Selon lui, la notion de hiérarchie renvoie à au moins trois sens. (1) La hiérarchie peut servir à désigner une forme d'organisation particulière « caractérisée par un mode d'organisation relativement rigide et

des statuts hiérarchisés ». Nous pouvons raisonnablement considérer cette première définition

Partie I. Chapitre 3. Les débats de la littérature sur les formes d’organisations de l’open source.

désigne le recours à la subordination dans une structure organisationnelle plutôt que le recours au mécanisme de prix (marché). (2) La hiérarchie peut être interprétée comme « une dotation

inégale des pouvoirs entre les acteurs ». Il s'agit plutôt d'une définition sociologique vue à

travers le prisme de la notion de pouvoir (Crozier et Friedberg 1977). (3) Pour finir, la notion de hiérarchie peut être considérée sous l'angle « de l'interaction sociale entre les acteurs d'un

même groupe ou de groupes distincts » (Grassineau 2009: 41-42). Cette définition propose la

vision managériale du mot hiérarchie se focalisant sur le rapport de subordination en tant que tel entre un responsable et son subordonné.

Pour répondre à ce paradoxe, les membres des communautés d’utilisateurs-développeurs n’ont ni recours à la hiérarchie (au sens économique44) ni au marché pour réaliser leur production (Benkler 2002: 381; Demil et Lecocq 2005: 3). Toutefois bon nombre de communautés fonctionnent de manière hiérarchique45 (au sens managérial). En effet, nous avons réalisé notre propre étude dans le cadre d’un mémoire de Master Recherche, nous avons constaté empiriquement qu’il y avait bel et bien une hiérarchie entre les membres et que celle- ci était basée sur la contribution (Benkeltoum 2006). De récents travaux ont montré comment se structurait le leadership au sein de la communauté Debian46 (O’Mahony et Ferraro 2007). O’Mahony et Ferraro ont proposé d’étudier la manière dont un système bureaucratique est intégré dans une communauté. Ils proposent en somme un couplage des formes bureaucratiques et démocratiques.

Les travaux de ces auteurs montrent que le leadership n’est pas seulement basé sur la contribution technique mais aussi sur au moins deux autres éléments. (1) D’une part, l’impact des contributions en termes d’adoption (mesuré par la popularité du paquetage47 maintenu par le développeur) a un impact significatif sur la propension d’un individu à devenir leader. Plus précisément, le mainteneur a 2,3 fois plus de chances de devenir leader. (2) D’autre part, le fait de rencontrer physiquement les autres développeurs a aussi un impact significatif sur le leadership (O’Mahony et Ferraro 2007: 1098).

O’Mahony, spécialiste des questions de gouvernance dans l’open source grâce à la réalisation d’une thèse sur la manière dont les projets open source sont gérés (O’Mahony 2002), défend l’idée que les notions d’autogestion et d’autogouvernement ne décrivent pas de

44 _{Pour ce qui est de la définition de hiérarchie basée sur les pouvoirs, elle est plus difficile à interpréter étant} donné que nous n’avons pas analysé les communautés sous l’angle des rapports de pouvoirs.

45

Nous traiterons plus loin la question de la structuration sociale des régimes de l’open source du point de vue empirique.

46 _{Pour de plus amples informations sur l’organisation de la communauté Debian, lire les travaux de N. Auray} (2003, 2004, 2006).

47

Partie I. Chapitre 3. Les débats de la littérature sur les formes d’organisations de l’open source.

manière satisfaisante les modèles de gouvernance dans les projets open source (O’Mahony 2007: 140). O’Mahony suggère de découpler la notion de gouvernance communautaire de la notion d’open source. L’auteur identifie cinq principes de gouvernance communautaire : (1) l’indépendance des structures de direction, (2) le pluralisme des méthodes et techniques, (3) la représentation des membres de la communauté dans les organes de direction, (4) la décentralisation des prises de décisions et (5) la participation autonome des contributeurs (O’Mahony 2007: 148-49).

Sharma et al. soutiennent l’idée que les communautés open source utilisent quatre mécanismes de gouvernance : (1) la gestion des participants (cooptation), (2) des règles et des normes (système de vote), (3) de la surveillance et des sanctions et (4) des effets de réputation (Sharma, Sugumaran, et Rajagopalan 2002: 11).

L'étude du projet Spip montre l'existence de trois types de régulation de l’action collective : (1) un premier centré sur le logiciel, (2) un second autonome reflétant des engagements différenciés et (3) un troisième distribué portant sur la création et la modification de normes partagées (Demazière, Horn, et Zune 2007: 34). Les auteurs ajoutent que « les projets de

grande échelle à la place développent des formes de régulations plus codifiées, stabilisées et prescriptives » (Demazière et al. 2007: 37). Il est évident que les problématiques de

gouvernance ne sont pas les mêmes en fonction de la taille de l’organisation mais cela n’est pas nouveau en théorie des organisations (Beziat 1992: 105). Il semble toutefois qu’une hiérarchie émerge très classiquement lorsque le projet grandit (Maggioni 2002: 14).

2.

Les firmes et l’open source.

Au départ, la littérature sur les logiciels libres s’est focalisée sur les communautés d’utilisateurs-développeurs. Néanmoins, la littérature a rapidement mentionné le fait que les firmes avaient un rôle grandissant dans l’open source. Certains universitaires ont particulièrement signalé la nécessité d’étudier l’activité des firmes dans l’open source (Dahlander 2004: 18; Gauguier 2005: 25; Grand, Von Krogh, Leonard, et Swap 2004: 593; West et O’Mahony 2005: 9).

En premier lieu, les recherches se sont focalisées sur l’étude des modèles économiques associés aux logiciels libres (Dahlander 2004; Hecker 2000; 2004b, 2004a, 2005, 2006; Onetti et Capobianco 2005; Pal et Madanmohan 2002; Spiller et Wichmann 2002; Välimäki 2003),

Partie I. Chapitre 3. Les débats de la littérature sur les formes d’organisations de l’open source.

nous présenterons ces travaux dans le chapitre dédié à la valorisation économique du logiciel libre.

Parallèlement à ces études, d’autres auteurs se sont tournés vers les éléments justifiant la participation des firmes dans le développement de logiciels libres. Bonaccorsi et Rossi ont justifié la participation des firmes par trois types de motivations : économiques, technologiques et sociales. Ils mettent en évidence que les motivations économiques sont les plus importantes viennent ensuite les motivations technologiques puis sociales (Bonaccorsi et Rossi 2003b: 23).

De même, Rannou et Ronai suggèrent que les firmes sont impliquées dans le développement de logiciels libres pour deux raisons. (1) D’un côté, les firmes sont intéressées par l’amélioration de la compatibilité de leurs propres logiciels fermés avec d’autres logiciels libres. (2) D’un autre côté, les firmes recherchent à promouvoir des standards pour améliorer l’interopérabilité entre systèmes, réduire les risques d’investissement et donner un meilleur futur à l’innovation (Rannou et Ronai 2003a: 124).

D’autres auteurs se sont intéressés à l’activité des firmes à proprement parler. Grand et al. modélisent les quatre niveaux d’allocation de ressources qu’une entreprise peut avoir dans le but d’exploiter les opportunités offertes par les logiciels libres. (1) Au premier niveau, la firme utilise des logiciels libres, elle n’intervient pas dans le développement des logiciels utilisés. (2) Au second niveau, la firme propose des logiciels libres avec d’autres produits comme atout complémentaire. A ce niveau, les entreprises investissent davantage dans l’open source. (3) Au troisième niveau, la firme sélectionne l’open source comme méthode de production dans le but de profiter du travail des développeurs individuels. (4) Au quatrième niveau, la firme choisit l’open source comme mode de développement. Elle se dote d’un modèle économique compatible avec l’open source (Grand et al. 2004: 594-600).