PARTIE III. DU MODELE RACINE A LA VARIETE DES
1. Les fondements théoriques et pratiques des régimes de l’open source
1.1.
Les limites de la notion de « community ».
Dans nos recherches empiriques, nous avons été frappés par la richesse des formes organisationnelles existantes dans l’open source. Or, la littérature utilisait toujours le terme communauté pour désigner ces formes organisationnelles. Par exemple, O’Mahony souligne qu’un « projet géré par une communauté est un projet open source ou free software initié et
géré par un groupe distribué de personnes qui ne partagent pas un même employeur. »
(O’Mahony 2003: 1179). Dans un autre article, O’Mahony soutient que de « plus précises
distinctions sont nécessaires pour communiquer les frontières entre firme, organisations à but non lucratif et communauté » (O’Mahony 2007: 144).
Ce problème de pluralité fut également mis évidence par Henkel. Henkel propose de distinguer les « projets » open source en fonction de leurs participants. Il distingue trois types de projets : (1) ceux uniquement constitués d’acteurs individuels, (2) ceux disposant d’une firme centrale et (3) ceux composés uniquement par des entreprises. Les travaux de Henkel ont donc prouvé qu’il était possible d’avoir une communauté d’entreprises (Henkel 2003a: 3). Plus spécifiquement, Henkel identifia une première dimension permettant de distinguer les organisations de l’open source : le type de participants. Les notions de projet71 et de
communauté étant bien trop vagues pour distinguer les différentes formes d’organisations
dans l’open source.
Depuis ses débuts, l’open source a connu de profondes mutations du point de vue de la nature des organisations comme le souligne un expert de l’open source, « il y a eu des
individuels bénévoles tout seuls dans leur coin. Il y a eu des organisations d’individuels et maintenant ce sont des organisations d’organisations. C’est l’open source de troisième génération72. »
71
Il convient de noter que la notion de « projet » dans la littérature sur l’open source n’a pas grand-chose à voir avec la littérature sur la gestion de projet (Garel, Giard, et Midler 2001; Garel 2003b, 2003a; Giard 1991; Giard et Midler 1993; Jolivet 1998; Royer 2005). Par exemple, le triptyque coût, qualité et délai ne se retrouve pas dans les « projets open source ».
72
0. Chapitre 1. De la variété des organisations ou l’émergence des régimes de l’open source.
1.2.
La technique de l’échantillonnage théorique.
La technique de l’étude de cas consiste à choisir délibérément des cas suffisamment hétérogènes pour rendre compte de la variété d’un phénomène (Eisenhardt 1989). Sur la base de cette technique, nous avons sélectionné nos cas grâce auxquels nous avons bâti notre typologie des régimes de l’open source. Nous nous focaliserons particulièrement sur les formes existantes entre d’un côté la communauté d’utilisateurs-développeurs (non rémunération des producteurs et objet produit libre d’utilisation) et la firme (rémunération des producteurs et objet produit valorisé directement ou indirectement).
D’après Christensen, les théories basées sur un grand échantillon n’ont pas une validité externe plus grande que les théories basées sur l’étude d’un nombre limité de cas (Christensen 2006: 53). C’est pourquoi les analyses découlant de nos cas seront suffisamment générales pour expliquer une large partie du phénomène étudié.
Nous ajoutons que le rôle des firmes dans l’open source ne se limite plus au simple financement de communautés ou à la libération de logiciels, les firmes financent elles-mêmes les communautés qu’elles ont créées entre-elles comme les travaux de Boiteux (2002) et Henkel (2003b, 2003a, 2004, 2006) le montrent ou encore Demazière et al. en faisant référence à des organisations constituées « d’institutions diverses (entreprises, centres de
recherche,…) » (Demazière, Horn, et Zune Forthcoming: 7) sans toutefois proposer une
analyse de ces organisations. Les cas OW2 consortium et OpenOffice.org (décrits de manière détaillée ci-après) sont particulièrement significatifs de ce phénomène. Cette variété d’organisations est donc à la fois rencontrée sur le terrain et mentionnée par différents auteurs. En revanche, il n’existe pas de modèle général permettant de distinguer les organisations de l’open source à partir de critères empiriques et encore moins de suivre les transformations organisationnelles d’une forme à une autre.
Il faut tout de même garder à l’esprit que lorsque la notion de communautés d’utilisateurs- développeurs est citée, on pense le plus souvent à des communautés constituées de plusieurs centaines de personnes. Or, la grande majorité des communautés sont d’une taille réduite d’après les résultats de l’étude de Krishnamurthy (2002: 4) dans laquelle il s’est intéressé à 100 logiciels libres du site SourceForge.net. Il trouve une moyenne de 6,61 développeurs par logiciel, une médiane à 4 et un mode73 de 1.
73
0. Chapitre 1. De la variété des organisations ou l’émergence des régimes de l’open source.
D’après Rannou et Ronai, « la majorité des projets est élaborée par 1 développeur (28,4%
des projets), 2 développeurs (24,3% des projets) ou 3 développeurs (24,3% des projets) »
(Rannou et Ronai 2003a: 127), ces données furent obtenues à partir de l’étude de 16 905 logiciels libres. Par conséquent, il est difficile d’accepter que les logiciels libres soient développés par de grandes communautés comme le prétendent certains auteurs (Bonaccorsi et al. 2006: 1086).
Le but de notre travail était de bâtir une typologie des formes organisationnelles existantes dans l’open source. D’après Eisenhardt et Graebner, le choix d’une approche qualitative basée sur de multiples cas vise à la construction de théories. De ce fait, nous ne pouvions pas avoir une approche quantitative puisque ces approches visent à tester des hypothèses. Nous avons choisi d’étudier les organisations de l’open source en nous basant sur de multiples études de cas en utilisant la technique de l’échantillonnage théorique ou « theoretical sampling ». Dans cette méthode, la sélection des cas peut être basée notamment sur la réplication, l'extension ou l'inversement d'un phénomène (Eisenhardt et Graebner 2007: 27).
1.3.
Les critères de sélection des cas.
Pour réaliser notre sélection, nous avons défini des critères à la fois appuyés sur la variété des formes rencontrées sur le terrain, les notions de solidarité et de distribution [Partie II] et la littérature existante sur les organisations de l’open source.
Le premier critère est le type d’acteurs puisque la littérature fait état de plusieurs catégories d’acteurs dans les organisations de l’open source (Henkel 2003a: 3; O’Mahony 2003: 1180; 2007: 144). Nous avons résumé les types d’acteurs, les liens de solidarité et les cas étudiés correspondants dans le tableau ci-dessous.
0. Chapitre 1. De la variété des organisations ou l’émergence des régimes de l’open source.
Tableau 13 : Types d'acteurs dans les organisations de l'open source.
Types d’acteurs74 Sources Liens de solidarité Cas (mineurs et
majeurs) Utilisateurs (U) (Demazière et al. 2007: 40;
Hertel et al. 2003: 1165) Usage (utilisateurs) [Partie II].
Claroline/Dokeos, Kexi, Freeworks.
Développeurs (D) (Demazière et al. 2007: 40; Hertel et al. 2003: 1165)
Conception et apprentissage (développeurs) [Partie II]. Mandriva, Mozilla, OpenOffice.org, OW2 Consortium, Apache. Utilisateurs- Développeurs (UD) (Baldwin et Clark 2005: 33; Gaudeul 2007: 242; Hicks et Pachamanova 2007: 316; Lerner et Tirole 2000: 18; West et O’Mahony 2005: 1)
Usage, conception et apprentissage [Partie II].
Kexi, Freeworks, Mandriva, Mozilla,
Adonthell, TDR, Claroline/Dokeos, NeoOffice, Apache.
Entreprises (E) (Boiteux 2002: partie 5; Henkel 2003b, 2003a)
Economique (mutualisation de coûts et/ou lutte contre monopole), technologique (maintien
d’une base de code générique commune : composant ou commodité).
Thales, QualiPSo, OW2 Consortium, OpenOffice.org.
Le second critère correspond au mode de financement de l’organisation. Les différents modes de financements peuvent être résumés dans le tableau ci-dessous.
Tableau 14 : Modes de financement dans les organisations de l'open source. Types de
financement Principe Sources Cas (mineurs et majeurs)
Propres Ressources (PR)
Utilisation de ressources privées pour
construire un bien collectif. (von Hippel et von Krogh 2003: 213)
Kexi, Freeworks, Mandriva, Mozilla, Adonthell, TDR, Claroline/Dokeos, NeoOffice,
Apache. Partage de Coûts
(PC)
Mutualisation des coûts de développement sur composants génériques communs ou commodités.
(Boiteux, 2002: partie 5;(Deek et McHugh 2007: 9)
OpenOffice.org, OW2 Consortium.
Sponsors (S)
Recours à des sponsors pour le financement de matériel ou d’événements. (Dahlander et McKelvey 2005: 634; O’Mahony 2003: 1180), Kexi, OpenOffice.org, Apache. Prestation de Services75 (PS)
Adaptation du modèle économique
aux logiciels libres. (Bonaccorsi et Rossi 2003a: 1249)
Thales, Mekensleep, Wallix, Mozilla.
Dons (D)
Réalisation de campagnes de dons auprès des membres et des
utilisateurs.
(Fitzgerald 2007: 591; Klincewicz 2005: 15).
Kexi, Apache, Mozilla, Freeworks.
74 La littérature fait aussi état de contributeurs sponsorisés (O’Mahony, 2003 ; West et O’Mahony, 2005 ; 2007) mais il ne s’agit pas d’une catégorie d’acteur particulier puisqu’il ne s’agit de représentants d’une entreprise dans une communauté existante. L’entreprise n’existe que par ses représentants puisque par définition ce n’est qu’une fiction juridique.
75 Nous avons volontairement laissé une appellation générale pour incorporer la plus grande partie des modèles économiques liés aux logiciels libres.
0. Chapitre 1. De la variété des organisations ou l’émergence des régimes de l’open source.
Le troisième critère concerne le système de rémunération puisqu’il existe plusieurs cas de figure résumés dans le tableau ci-dessous.
Tableau 15 : Modes de rémunération dans les organisations de l’open source. Mode de
rémunération Principe Sources Cas (mineurs et majeurs)
Bénévolat (B)
Absence de rémunération que se soit de manière directe ou
indirecte.
(Bitzer et Schröder 2005: 390; Kogut et Metiu 2001a: 249)
Kexi, Freeworks, Mandriva, Mozilla, Adonthell, TDR, Claroline/Dokeos, NeoOffice,
Apache.
Rémunération Directe (RD)
Les développeurs sont rémunérés pour leur travail.
(Crémer et Gaudeul 2004: 115; Dahlander et Magnusson 2005: 483; Ghosh et al. 2002: 63)
Kexi, Mozilla, OpenOffice.org, OW2 Consortium, Apache, Thales,
Wallix, Mekensleep.
Rémunération Indirecte (RI)
Les développeurs perçoivent une rémunération indirecte par
le biais de services liés au logiciel libre.
(Benkler 2002: 438)
Freeworks, Mandriva, OpenOffice.org, OW2
Consortium.
Le quatrième critère porte sur l’existence d’une structure juridique ou pas : la littérature fait état de structures Informelles (I) (communautés) et Formelles (F) (les firmes (Bonaccorsi et Rossi 2003b: 12) et les fondations (O’Mahony 2002: 21)).
Il est largement reconnu qu’il existe une grande variété de formes organisationnelles développant des logiciels open source (Shah 2006: 1001). Les notions de « Bazaar » et de
« community » renseignent peu sur la manière dont ces collectifs fonctionnent réellement
(Demazière et al. 2007: 35). La question qu’il faut se poser est qu’est-ce qu’une communauté ? Est-ce qu’un groupe de bénévoles développant un jeu vidéo sur leur temps libre et un consortium rassemblant plus de 60 entreprises et instituts de recherche autour des problématiques du Middleware peuvent-ils être tous deux nommés communautés ? Bien au contraire, nous pensons qu’il est nécessaire de réaliser une typologie permettant de faire la distinction entre les différentes organisations de l’open source.