SlideShare una empresa de Scribd logo
1 de 14
Descargar para leer sin conexión
2-T97   2/09/06   16:28     Page 71




             Dynamique de développement
             des communautés
             du logiciel libre
             Conditions d’émergence
             et régulations des tensions

             Didier Demazière, François Horn, Marc Zune*


             L
                     a renommée et l’usage des logiciels libres ne cessent de croître et le
                     nombre de projets déposés sur les sites de développement mutualisés
                     poursuit une croissance exponentielle. Le site de développement com-
             munautaire SourceForge dénombrait, fin 2005 plus de 100 000 projets et plus
             d’un million de développeurs référencés. Ces projets sont marqués par une très
             forte hétérogénéité concernant le nombre de contributeurs et leur organisation.
             Si les développeurs de logiciels libres et certains projets emblématiques ont fait
             l’objet d’études, une question reste cependant, à ce jour, peu analysée : qu’est-
             ce qui explique que parmi tous ces projets certains parviennent à attirer des
             contributeurs permettant d’enclencher une dynamique de développement ?
                   Parmi l’ensemble des modèles de production de logiciels [Horn, 2004],
             le développement des logiciels libres présente l’originalité d’être fondé sur
             un mode d’organisation coopératif qui s’appuie largement sur les commodi-
             tés organisationnelles issues d’Internet. Les développeurs ne sont pas inscrits
             dans la même organisation, sont dispersés, ont des relations médiatisées par
             le réseau Internet, ne sont pas reliés par les fils d’un organigramme quelcon-
             que. Il n’existe pas d’interactions directes, codifiées et prescrites entre les
             producteurs du logiciel. En principe, toute personne peut fournir une contri-
             bution et participer à l’élaboration d’un bien collectif et public.
                   Les échanges entre contributeurs s’effectuent quasi-exclusivement à
             partir de modes de communication électroniques : courrier électronique, lis-
             tes de diffusion, forums, chat, dispositif d’enregistrement et de visualisation
             du code produit, etc. Ce fonctionnement à distance, permet d’attirer des
             contributions nombreuses, favorise un meilleur repérage des erreurs par les
             utilisateurs, et autorise des corrections plus rapides. Cette configuration
             conduit à s’interroger sur les caractéristiques de l’action collective qui per-
             met de passer d’engagements individuels volontaires, et potentiellement
             volatiles et instables, à la réalisation d’une production collective, impliquant
             continuité et pérennité. Le mode de développement du logiciel libre qui
             * Didier Demazière (Printemps, CRS/Université de Versailles - Saint-Quentin-en-Yvelines) ; François Horn
             (CLERSE-IFRESI, Université Lille 3 ; Marc Zune (CSTEF, FNRS/Université Libre de Brxelles).

                                                                                          É té 2006   ] te rminal [   71
2-T97   2/09/06    16:28        Page 72




           repose largement, en apparence, sur le caractère bénévole des contributions,
           se singularise par rapport aux modes de production habituels encadrés par
           des relations de travail salariales ou contractuelles. Mis à part une licence
           d’utilisation spécifique, cette activité n’est en effet régulée par aucun dispo-
           sitif juridique relevant du droit du travail ou commercial, ni par des incitants
           pécuniaires, ni par des rapports de subordination [Gensollen, 2004]. Les
           groupes de production sont d’ailleurs désignés dans les milieux du logiciel
           libre par le terme communauté, et la gestion est référée à un "modèle du
           bazar" [Raymond, 1998], fondé sur une très forte décentralisation auprès de
           contributeurs non sélectionnés, dépourvu de coordination formelle, de cahier
           des charges ou d’injonctions temporelles, laissant libre cours à l’imagination
           et l’implication individuelles [Glass, 2003, Holgrewe et Werle, 2001].
                  Cette modélisation du fonctionnement des communautés de logiciels
           libres a une fonction politique consistant à affirmer le caractère original et
           alternatif de ce mode de production par rapport à l’industrie du logiciel pro-
           priétaire ("modèle de la cathédrale"). Sa valeur descriptive et sociologique
           apparaît en revanche contestable. Car la production d’un bien collectif de
           qualité à partir de contributions individuelles volontaires nécessite des for-
           mes de régulation. Développer un logiciel selon un mode collaboratif sup-
           pose de réaliser une série d’opérations : mobiliser des développeurs autour
           d’un projet, assurer une relative continuité des participations, vérifier la qua-
           lité des contributions, agencer les développements validés en un produit
           cohérent et opératoire, etc.
                  Notre analyse vise à tenter de cerner le fonctionnement des communau-
           tés de logiciels libres dans leurs processus de constitution et de développe-
           ment. Au-delà de l’extrême diversité organisationnelle des différents projets
           de développement de logiciels libres [Demazzière, Horn, Jullien, 2003], il
           s’agit d’éclaircir plusieurs interrogations : comment se constituent et se
           structurent ces collectifs de travail ? Comment sont-ils animés, gérés, fédé-
           rés, soutenus ? Comment maintient-on, dans ces conditions, un produit cohé-
           rent, avec une certaine identité et continuité dans le temps ? Pour cela, nous
           proposons de spécifier une série de moments-clés dans le développement
           d’un projet libre, du stade de l’émergence aux possibilités d’extinction ou de
           scissions. À cet effet, nous nous appuyons sur deux études de cas de logiciels
           libres, les projets Spip et Claroline1.

           Conditions d’émergence d’une communauté

                La brève présentation en encadré des deux projets à la base de notre
           réflexion nous renseigne d’emblée sur une première condition nécessaire au
                                                                                                  Suite page 74
           1. Ceux-ci ont été choisis parce qu’ils sont de taille moyenne, sont en phase de développement et sont
           confrontés à des enjeux de légitimité que les projets les plus connus et les plus établis (Linux, Apache,
           etc.) ne connaissent plus. L’investigation empirique a été menée à la manière d’une enquête ethnographi-
           que en s’appuyant sur 35 entretiens approfondis de recherche auprès de participants présentant des
           contributions et activités différenciées.

           72       ] te rminal [   É té 2006
2-T97   2/09/06   16:28   Page 73




                     SPIP, UN OUTIL D’AUTOPUBLICATION SUR LE WEB
                     Le projet "Spip" se présente comme une figure a priori emblématique d’un
              fonctionnement communautaire fondé sur l’apport central d’individus dispersés et
              non reliés par quelque arrangement institutionnel ou d’emploi particulier. C’est
              afin d’aider les membres d’une association à s’exprimer par eux-mêmes en toute
              autonomie que l’un d’entre eux a l’idée de développer un outil informatique facili-
              tant la fabrication de pages Web et la gestion du site de l’association.
                     La particularité est que l’usage de ce logiciel ne nécessite pas de connais-
              sances techniques particulières et doit pouvoir "tourner" sur des serveurs peu
              véloces, et par conséquent peu onéreux. Après quelques mois d’usage interne, la
              demande se manifeste rapidement pour que cet outil puisse être utilisé par d’au-
              tres associations. Un sympathisant informaticien se propose d’aider le concepteur
              de l’outil, infographiste, et s’implique dans le développement. En même temps, un
              webmestre d’un grand journal mensuel d’opinion manifeste l’intérêt d’utiliser ce
              logiciel à des fins de publication en ligne. Cette équipe de base constituera le
              "noyau" historique du projet, les "auteurs" du logiciel.
                     Ces trois fondateurs partagent une ligne philosophique qu’ils souhaitent
              poursuivre, celle de l’auto-publication et de l’indépendance des utilisateurs face à
              toute contrainte à la liberté d’expression. Ils entendent, face au péril pressenti
              d’une certaine mainmise des industries du contenu, préserver des espaces de
              libre expression pouvant être investis par tout acteur de la vie sociale, quelles que
              soient ses compétences techniques et ses ressources matérielles. Cette orienta-
              tion, traduite en manifeste du Web indépendant, se décline à la fois dans des par-
              tis pris techniques et fonctionnels (liberté de réaction aux contenus publiés, limi-
              tation de la hiérarchie des droits de publication, etc.), mais également dans un
              projet militant de diffusion de la liberté d’expression.
                     Le succès du logiciel est fulgurant. Spip connaît une utilisation fortement
              croissante, au point de devenir une référence incontournable parmi l’offre de logi-
              ciels de gestion de contenu sur Internet. C’est que l’outil développé, certes impar-
              fait dans ses premières moutures, répond à un besoin criant au moment de son
              apparition, face aux solutions "propriétaires" souvent trop onéreuses et anglopho-
              nes. Ce succès s’accompagne du développement d’une communauté importante
              et internationale du fait de la traduction du logiciel et de son support en plus de
              trente langues. Ces contributeurs présentent des profils diversifiés : militants de
              sites associatifs, webmestres ,infographistes, informaticiens pointus, que ce soit
              à titre professionnel ou d’activité hors travail.
                     Après une année de développement, un prestataire informatique sous
              contrat avec une administration publique propose une réécriture partielle du logi-
              ciel en introduisant une méthode de programmation plus complexe et l’ajout de
              fonctionnalités jugées plus adaptées au monde professionnel. L’absence de colla-
              boration avec la communauté provoquera le rejet de la greffe proposée et une
              scission de fait (un fork dans la terminologie indigène), avec le développement en
              parallèle d’une autre version du logiciel intitulée Spip-Agora.



                                                                             É té 2006   ] te rminal [   73
2-T97   2/09/06   16:28        Page 74




                  CLAROLINE, UNE PLATE-FORME DE E-LEARNING

                    Claroline est un logiciel développé par une université belge. L’idée de ce pro-
            jet revient à un jeune docteur en philosophie chargé par son institution de promou-
            voir l’utilisation d’un logiciel commercial de support à l’enseignement en ligne.
            Malgré les efforts, notamment de formation, la mission est un échec, le logiciel
            étant jugé trop lourd et contraignant par les enseignants. Dans le même temps,
            l’initiateur du projet découvre sur Internet des outils logiciels libres simples répon-
            dant aux principales fonctionnalités demandées par les enseignants. Il décide
            alors d’intégrer ces outils et de les doter d’une interface commune créant ainsi un
            nouveau logiciel qu’il diffuse sous licence libre. Claroline connaît un succès rapide
            au sein de l’institution et dans d’autres universités aux besoins identiques. En
            interne, l’équipe de développement s’étoffe progressivement, avec deux autres
            développeurs engagés à temps plein pour répondre aux besoins des utilisateurs
            locaux et améliorer les fonctionnalités demandées. Des utilisateurs avancés, sur-
            tout des gestionnaires de campus numériques d’autres universités (plus d’une
            centaine, essentiellement du sud de l’Europe et du monde hispanique), participent
            aux discussions sur les forums du projet, proposent des traductions, rapportent
            des bogues lors de chaque nouvelle version, font part de leurs souhaits en matière
            de fonctionnalités nouvelles.
                    L’équipe interne défend deux valeurs centrales à la base du projet : la flexi-
            bilité et la simplicité d’utilisation, à l’exact opposé des traits attribués aux logiciels
            commerciaux les plus en vogue. Il s’agit de proposer à l’enseignant un ensemble
            d’outils de support à l’enseignement (forum, dépôt de documents, agenda, etc.)
            sans le contraindre à un usage prescrit. Par conséquent, toute contribution au
            code du logiciel, indépendamment de sa qualité technique, n’est acceptée que
            pour autant qu’elle respecte ces deux traits. Dans les faits, bon nombre de propo-
            sitions de collaboration sur le code sont ainsi rejetées. Les apports techniques
            proposés par les contributeurs "distants" portent davantage sur des petites cor-
            rections, qui, lorsqu’elles sont jugées intéressantes, sont réécrites au moins en
            partie par les développeurs de l’université. L’essentiel des autres contributions
            portent par conséquent sur des activités de traduction ou de rapports de bogues.
                    La grande diffusion du logiciel entraîne, assez rapidement, une multitude de
            demandes de prestations de services visant à adapter le logiciel aux contextes
            spécifiques des utilisateurs. Cette demande amène les fondateurs à solliciter une
            aide publique afin d’améliorer les fonctionnalités du logiciel. Cet argent public per-
            mettra, en 2004, d’étendre l’équipe interne à trois nouvelles personnes. Cependant
            un conflit éclate entre le fondateur du logiciel et l’université qui veut lui retirer le
            leadership du projet. L’initiateur du projet décide alors de créer sa propre société
            de conseil en organisant son propre fork de Claroline, intitulé Dokeos.

           Suite de la page 72
           développement d’une communauté : l’outil proposé comble un manque dans
           l’offre des logiciels commerciaux ou répond à des besoins mal couverts par
           ces derniers étant donné l’impossibilité de les améliorer vu l’absence d’accès

           74      ] te rminal [   É té 2006
2-T97   2/09/06   16:28   Page 75




             au code source. Ainsi les logiciels libres les plus connus et les plus utilisés
             sont nés sur des créneaux où leurs équivalents commerciaux n’existaient pas
             (les outils logiciels nécessaires au fonctionnement d’Internet dans les années
             80) ou dans des domaines où les qualités des logiciels existants étaient jugées
             insuffisantes, notamment en termes de sécurité et de fiabilité (par exemple
             les systèmes d’exploitation). Des manques plus limités des logiciels courants
             peuvent cependant suffire pour créer un espace propice à la naissance d’un
             logiciel libre, comme l’absence d’une version francophone, la nécessité de
             ressources importantes et donc coûteuses ou la simplicité d’utilisation.
                   En effet, les logiciels commerciaux sont souvent des produits très com-
             plexes marqués par une culture informaticienne. Il peut en résulter un déca-
             lage par rapport aux besoins d’une partie des utilisateurs, ce qui explique que
             l’on trouve fréquemment dans les noyaux initiateurs des logiciels libres des
             non-informaticiens professionnels. Les cas de Spip et de Claroline sont à cet
             égard emblématiques de la diversité des origines disciplinaires des initiateurs
             des projets : un pilote de ligne reconverti dans l’infographie, un docteur en
             mathématiques et un ingénieur télécom dans le cas de Spip, deux philosophes
             et un pédagogue dans le cas de Claroline.
                   Outre le fait de combler des manques existants, les choix effectués par
             les initiateurs du projet définissent l’identité originale [Salais, Storper, 1993]
             du logiciel qui sera développé. Les caractéristiques particulières du logiciel
             sont la traduction de cette identité spécifique. Ces caractéristiques qui sont
             dépendantes du processus de production du logiciel et qui influent sur son
             utilisation peuvent apparaître de prime abord comme de simples choix tech-
             niques entre des exigences contradictoires (richesse fonctionnelle versus
             simplicité d’utilisation…). Mais il est fréquent qu’en réalité les options rete-
             nues soient marquées par des conceptions sociales. C’est particulièrement net
             quand le logiciel vise à informatiser une activité existante : dans ce cas, la
             définition des caractéristiques fonctionnelles du logiciel est le reflet direct de
             la vision de l’activité. Ainsi, les caractéristiques de Spip sont fortement
             dépendantes de la représentation des initiateurs de ce qu’est une activité édi-
             toriale et de la manière de la mener. L’interface graphique de la zone d’admi-
             nistration du logiciel mène à une mise en scène du processus de rédaction,
             qui passe notamment par la discussion et la validation de pairs avant publi-
             cation. Placé dans l’espace public, l’article rédigé est associé à un dispositif
             de forum afin de susciter commentaires, réactions voire controverses.
                   Cette stimulation du regard des pairs vise à insuffler et promouvoir une
             culture de débats dans la publication sur Internet. De même, Claroline se
             définit par le caractère simple et incrémental de son utilisation, qui renvoie à
             un modèle de pédagogie active. Ce modèle tend à considérer la technologie
             comme miroir des processus d’apprentissage humains "naturels" qui dépas-
             sent la simple acquisition de connaissances ou de règles. Ceux-ci s’inscrivent
             également dans des contextes, attitudes et comportements culturellement
             situés [Lebrun, 2002]. Le logiciel doit servir les choix du pédagogue, facili-
             ter les processus d’apprentissage à partir d’expériences diverses plutôt que

                                                                         É té 2006   ] te rminal [   75
2-T97   2/09/06   16:28        Page 76




           d’enfermer un transfert de connaissance dans un one best way pédagogique
           universel. L’ensemble des choix effectués à partir des orientations symboli-
           ques et idéologiques des promoteurs du projet va définir l’identité spécifique
           du logiciel proposé et sa différenciation par rapport à d’autres produits voi-
           sins et concurrents. Quand cette identité répond aux attentes d’utilisateurs, et
           même si le logiciel est très imparfait dans ses premières moutures, une com-
           munauté de contributeurs peut émerger. En effet, cette identité spécifique,
           discriminante par rapport aux autres logiciels existants est le vecteur d’un
           sentiment d’appartenance communautaire qui peut motiver une partie des
           utilisateurs à devenir des contributeurs.
                 En outre, c’est sans doute parce qu’on ne peut réduire l’activité de déve-
           loppement à la réalisation d’un simple outil, mais que celui-ci s’inscrit dans
           une perspective temporelle indéterminée d’un projet, qu’une communauté
           peut se constituer et trouver, autour du logiciel créé, des motivations autres
           que strictement techniques à l’implication. C’est notamment ce côté projec-
           tuel qui entraîne le refus, a priori, de plans de développement pré-établis,
           ainsi qu’une division des tâches par trop rigide. Le flou spatiotemporel des
           tâches à réaliser maintient l’incertitude sur le déroulement de l’activité et per-
           met l’appropriation collective. Au-delà de la rationalité technique, ce sont
           des visions du monde et des imaginaires de transformation de la vie sociale
           que transportent avec eux les logiciels.

           Diversité des activités et hiérarchisation des statuts

                 Les relations entretenues entre les membres du groupe initiateur com-
           portent une composante interpersonnelle importante, qui permet de mettre à
           l’épreuve la force de l’accord sur l’identité du logiciel développé.
           Historiquement, les auteurs de Spip se rencontrent fréquemment dans le
           milieu associatif parisien, participent aux mêmes actions militantes, parta-
           gent des opinions similaires sur le développement de l’Internet et la liberté
           d’expression qui le caractérise.
                 De même, l’équipe initiale de développement de Claroline est confron-
           tée concrètement à la problématique de l’usage des TIC à des fins d’ensei-
           gnement, est associée à des activités de recherche sur ce sujet, partage quo-
           tidiennement un même espace de travail et de mêmes origines disciplinaires
           (science de l’éducation, philosophie, communication sociale).
                 Si le centre décisionnel est le garant et le défenseur de cette identité
           autour de laquelle il s’est constitué, il ne peut pour autant assurer la prise en
           charge de l’ensemble des activités liées à la production d’un logiciel. Car, au-
           delà du cœur informatique du logiciel, de multiples activités complémentai-
           res sont nécessaires à sa diffusion : traduction, rapport de bogues, aide aux
           utilisateurs, ajout de fonctionnalités, mise en compatibilité avec des logiciels
           tiers, etc. L’enjeu communautaire consiste à susciter et maintenir un flux de
           contributions extérieures, enjeu d’autant plus incertain que celles-ci ne peu-
           vent être prescrites ou commandées mais reposent uniquement sur le volon-

           76      ] te rminal [   É té 2006
2-T97   2/09/06   16:28   Page 77




             tariat de contributeurs distants. Si les ressorts de l’engagement de ceux-ci
             peuvent s’avérer très divers [Von Hippel, 2002] et inscrits dans des schèmes
             de carrières variées (Demazière, Horn et Jullien, 2004), la sensibilité aux fon-
             dements et à l’identité du projet s’avère généralement centrale dans la pour-
             suite d’une implication soutenue. Mais cette condition n’est pas suffisante :
             pour que se développe une communauté, il est également nécessaire que,
             d’une part, une certaine répartition du travail soit organisée et que, d’autre
             part, se mettent en place des dispositifs de gestion afin de susciter l’intéres-
             sement des acteurs et une implication persistante.
                   Quelques traits saillants émergent des observations de terrain, sans
             conduire cependant à la formation d’un modèle unique. Tout d’abord, une
             division du travail s’instaure systématiquement et se cristallise dans une dis-
             tribution stabilisée des tâches et même dans une différenciation de statuts
             hiérarchisés. Du point de vue des acteurs engagés, tous les participants sont
             membres de la communauté, ce qu’exprime le terme générique de "contribu-
             teur" pour désigner tout individu ayant participé à l’une quelconque de ces
             tâches. Mais l’éventail des tâches prises en charge exige un investissement
             d’inégale importance, pour certains très ponctuel (signaler un bogue), pour
             d’autres plus durable et intense (faire une documentation, maintenir une fonc-
             tionnalité). Les développeurs sont dispersés géographiquement, ont des activi-
             tés professionnelles diverses, mobilisent des compétences différenciées, et ne
             bénéficient pas d’une reconnaissance identique au sein de la communauté
             concernée. C’est ainsi que la mention de l’identité du contributeur à certaines
             tâches, comme la contribution à l’écriture du code, introduit de facto des hié-
             rarchies symboliques. L’usage de dispositifs de développement collectif (SVN,
             CVS, etc.), de gestion de listes de discussions ou de sites internes liés au pro-
             jet nécessitent l’octroi de droits d’accès qui sont contingentés.
                   Émergent ainsi des différenciations entre contributeurs, qui distribuent
             des places, des attributions, des quasi statuts. Ici, la différenciation statutaire
             ne repose pas comme dans les organisations informatiques traditionnelles sur
             des compétences supposées que l’organisation apprécie le plus souvent à par-
             tir de critères indirects (diplôme, années d’expérience sur une technologie,
             etc.), mais elle traduit plutôt l’exhibition par la pratique de compétences mises
             en action et de l’engagement des participants [Tayon et Pitrou, 2005]. Ces sta-
             tuts ne sont d’ailleurs pas inscrits dans des échelons hiérarchiques et n’alimen-
             tent pas des relations de subordination, mais ils stabilisent des positions dans
             des organisations de travail caractérisées souvent par un refus du formalisme.
                   Cette configuration dévoile, au minimum, une distinction entre un cen-
             tre décisionnel et d’animation autour duquel gravitent des contributeurs péri-
             phériques, les communautés les plus développées ayant une structuration
             o rganisationnelle plus riche et plus complexe. Chaque apport des contribu-
             teurs périphériques est le plus souvent limité et s’inscrit dans le cadre fixé
             au projet dont il ne peut modifier profondément l’identité. Cependant, le
             fait que chaque contribution prise isolément est d’ampleur réduite ne doit
             pas conduire à sous-estimer l’impact de l’ensemble de ces contributions qui

                                                                          É té 2006   ] te rminal [   77
2-T97   2/09/06   16:28        Page 78




           p ermettent d’intégrer à moindre frais de multiples améliorations cumulatives
           permettant "d’exploiter au mieux une intelligence distribuée" [Foray,
           Zimmermann, 2001]. Autre caractéristique importante, entre contributeurs
           périphériques, comme avec les membres du centre, les relations sont princi-
           palement virtuelles, médiatisées par le réseau Internet. Les rencontres inter-
           personnelles sont rares et quelques fois non souhaitées : l’anonymat permet
           en effet de limiter son apport sans induire un engagement soutenu ou un
           dévoilement des ressorts de l’investissement personnel.

           Des régulations nécessaires, une complexification croissante

                 À mesure que se développe cette couche de contributeurs distants se
           pose la question du ralliement d’acteurs aux motivations, comportements et
           attentes divers. Cette hétérogénéité croissante s’explique par les qualités ins-
           titutionnelles différentes des acteurs qui s’investissent (simples individus,
           associations, entreprises, pouvoirs publics, etc.), les spécificités des compé-
           tences proposées (traduction, graphisme, documentation, codage, test), ou
           encore des opportunités qui apparaissent du fait de l’implication (lien de plus
           en plus étroit avec l’activité professionnelle, demandes de prestations de ser-
           vices, nécessité d’adaptation du logiciel à des besoins spécifiques).
                 Cette diversité nécessite d’être gérée dans l’optique à la fois d’attirer
           des apports, mais également de les canaliser dans des orientations contri-
           buant au développement du projet et de sa visée normative. Mais il devient
           difficile pour les membres du centre de gérer directement de nombreux contri-
           buteurs. D’où l’apparition d’une multiplication des dispositifs techniques de
           gestion des contributions et des discussions, ainsi que d’un cercle supplémen-
           taire constitué des personnes ayant un statut intermédiaire entre les membres
           du centre et les simples contributeurs périphériques. L’organisation interne des
           projets de logiciels libres peut être schématisée de manière typique en diffé-
           rents cercles délimités avec un degré variable de précision selon les cas et
           emboîtés les uns dans les autres.

                          Cercle stratégique       Liens interpersonnels forts, partage des
                                                   mêmes orientations philosophiques
                                                   et/ou dispositifs juridiques ou institution-
                                                   nels exogènes

                        Cercle intermédiaire       Liens interpersonnels avec certains
                                                   membres du groupe des fondateurs,
                                                   prise de responsabilité dans l'animation
                                                   de la (sous-)communauté

                         Cercle périphérique       Peu de liens interpersonnels : l'anony-
                                                   mat permet la collaboration d'individus
                                                   aux motivations diverses, contributions
                                                   limitées


           78      ] te rminal [   É té 2006
2-T97   2/09/06   16:29   Page 79




                    La création de multiples listes de discussions spécialisées par objet
             témoigne de cette segmentation des communautés. Dans le cas Spip, des
             espaces de travail plus spécialisés se forment : division dans un premier
             temps de la liste principale en deux (Spip-dev et Spip-user), puis développe-
             ment de listes plus spécialisées ; Spip-contrib pour la proposition d’ajouts de
             fonctionnalités optionnelles, Spip-trad pour la gestion des dizaines de traduc-
             tions et le support aux non-francophones, Spip-lab pour la réflexion techni-
             cienne en termes de R&D, Spip-zone pour la stimulation de projets collabo-
             ratifs entre contributeurs, etc.
                    Chaque liste ou site a ainsi pour effet de rassembler des individus aux
             préoccupations communes et ciblées et de tenter de couvrir la diversité de
             centres d’intérêts qui soutiennent l’engagement dans le projet. Le fonction-
             nement de ces sous-espaces du projet est assuré par des participants particu-
             lièrement impliqués auxquels est attribué le statut "d’administrateurs". Ceux-
             ci ont la charge de gérer des dispositifs de communication (listes de
             discussions, sites Internet, serveurs collaboratifs) et d’animer les participants
             afin de susciter les contributions, de motiver l’implication, de s’assurer de
             l’entraide, mais également d’orienter, évaluer, sélectionner les apports. Ces
             couches intermédiaires bénéficient de l’approbation, voire d’un mandat du
             noyau stratégique qui se manifeste par la dispense de conseils, d’informa-
             tions confidentielles, de contacts privilégiés.
                    En déléguant certaines activités et responsabilités, les membres du cen-
             tre peuvent rétribuer par l’octroi d’un statut plus élevé les contributeurs péri-
             phériques les plus impliqués et donc soutenir la participation au projet.
             L’apparition d’un cercle intermédiaire indique également que les organisa-
             tions ne sont pas figées, et signale que des passages d’un cercle à l’autre et
             donc des changements de statut sont possibles. Les promotions viennent
             sanctionner des activités importantes pour le projet. Pour cela, il est néces-
             saire que le contributeur ait fait la preuve de ses compétences techniques
             (appréciées à partir de la qualité de ses contributions) et de l’importance de
             son engagement dans la durée. Il faut aussi que les comportements du postu-
             lant soient en adéquation avec la philosophie du projet et montrent un accord
             profond avec l’identité du logiciel développé, et donc avec le système de
             valeurs qui sous-tend cette identité. Les cas de Claroline et de Spip mettent
             en évidence le caractère non automatique de l’intégration de code produit par
             des contributeurs distants du cœur du logiciel.
                    Ainsi G., développeur de Claroline relate le refus d’une proposition
             d’un étudiant grec : "L’entièreté de son code n’était pas exploitable tel quel,
             et il n’a jamais voulu accepter qu’on avait d’autres contraintes. C’étaient sur-
             tout des objections par rapport aux contradictions avec la philosophie de sim-
             plicité". Accorder les droits d’accès au développement du code source du
             logiciel – ce qui, à ce jour, ne s’est jamais produit – dépendrait fortement
             d’une implication soutenue : "Je crois qu’on est prêt à donner ces droits-là à
             quelqu’un à partir du moment où il y a déjà une certaine confiance qui s’est
             installée, que la personne est bien identifiée, donc de telle institution, que la

                                                                         É té 2006   ] te rminal [   79
2-T97   2/09/06   16:29        Page 80




           collaboration est réelle aussi. Il faut témoigner d’un peu de confiance, il faut
           témoigner du fait qu’ils ont déjà contribué et que ça s’est bien passé et que
           ça aide vraiment". Par conséquent, l’essentiel des contributions portent sur
           des activités de traduction ou de signalement de bugs : "Ce qu’on aime beau-
           coup, c’est "je ne propose pas de code, mais j’ai passé du temps à tester, tes-
           ter". Ça, c’est à chaque fois du temps gagné" (C. Claroline). Les demandes
           de support sont redirigées par les développeurs vers le forum, "comme ça,
           avec un peu de chance, un utilisateur averti répondra avant nous" (H.
           Claroline).
                 Dans le cas de Spip, le contrôle centralisé des orientations du logiciel et
           des accès en écriture sur le cœur du logiciel en développement est souvent
           décrié. Du reste, les auteurs historiques se défendent d’un cloisonnement
           volontaire. L’accès aux droits de commit ne peut être envisagé, selon eux, ni
           comme un retour légitime récompensant une simple présence continue dans
           le projet, ni être restreint à un acte précis et temporaire.
                 Une fois accordés, ces droits ont la force d’un mandat, celui de poursui-
           vre le développement en toute autonomie, et ne s’obtiennent qu’après avoir
           fait la preuve d’une grande qualité et fiabilité techniques : "Ce qu’apparem-
           ment personne ne comprend, c’est que l'on ne va pas ouvrir un accès comme
           étant une sucette ou un bon point, voilà. Ouvrir l’accès, ce sera à quelqu’un
           qui aura produit des patchs ou des trucs fiables, sérieux. On a du mal à véri-
           fier ce que chacun de nous [les auteurs] fait, si en plus il faut corriger sans
           cesse le code par des gens qui sont pas au niveau, c’est pas la peine, c’est un
           travail épuisant. Un jour on en aura marre d’intégrer des patchs d’untel parce
           qu'untel il enverra toujours des patchs qui sont bons à intégrer puis, on en
           aura marre, et on leur dira tiens voilà, fais-le toi-même" (F., Spip).
                 Depuis le lancement du projet, deux contributeurs, au départ périphéri-
           ques, ont ainsi rejoint le cercle des auteurs. Pour vérifier leur proximité idéolo-
           gique au projet, les simples échanges virtuels communautaires sont apparus
           insuffisants ; ils ont été complétés par des interactions sociales directes avec
           des membres du centre (interaction en face à face ou échanges virtuels privés).
                 Cette exigence explique que des contributeurs qui ont pourtant effectué
           des contributions majeures (tant en termes d’importance que de difficulté)
           peuvent rester durablement à la périphérie de la communauté.

           Différenciation, segmentation, et séparation

                 Il existe également des possibilités de régression dans la hiérarchie des
           statuts. Le problème se pose notamment quand un membre (du centre ou du
           cercle intermédiaire) n’effectue plus les tâches qui lui ont été déléguées.
           Faute de substrat contractuel aux relations et aux positions occupées, les pos-
           sibilités de sanction par retrait des attributions correspondantes sont limitées
           et difficiles à mettre en œuvre. Plus fréquemment, la solution consiste à créer
           une nouvelle activité aux fonctionnalités proches de celle qui est mal réali-
           sée, et à laisser ainsi dépérir cette dernière.

           80      ] te rminal [   É té 2006
2-T97   2/09/06   16:29   Page 81




                   C’est le cas de B., initiateur de la liste Spip-contrib qui, lassé de la fai-
             ble implication des personnes qu’il avait repérées et sollicitées à pratiquer
             l’évaluation de propositions de fonctionnalités complémentaires, abandonne
             ses fonctions et choisit de s’impliquer dans le développement d’un nouvel
             espace de travail (Spip-zone). Les modalités de fonctionnement de cette nou-
             velle institution doivent permettre d’améliorer le mode d’animation des contri-
             buteurs et de repenser le processus de sélection des autres administrateurs.
                   D’une certaine façon, cette pratique est assez proche de celle qui est à
             l’œuvre quand la légitimité du centre décisionnel est remise en cause par une
             partie de la communauté du logiciel concerné : plutôt que de tenter de des-
             tituer ces membres, la partie mécontente crée une nouvelle communauté avec
             un nouveau centre décisionnel à partir des développements déjà effectués (un
             fork), ce qui est rendu possible par les licences des logiciels libres (absence
             d’appropriation privée du code développé).
                   Cette probabilité est d’autant plus forte que le logiciel n’a pas encore
             connu un succès suffisant pour que la communauté ait dépassé une taille
             critique rendant peu crédible le développement d’un projet concurrent à
             partir du logiciel existant. Il existe ainsi dans le développement d’une com-
             munauté de production d’un logiciel libre une période délicate où, dans la
             terminologie de Hirschman (1972), le caractère peu coûteux de l’ "exit"
             rend indispensable une gestion fine de la "voice" (notamment pour surmon-
             ter les incompréhensions réciproques) permettant de maintenir la "loyalty"
             et d’éviter les forks.
                   Les deux cas mobilisés ont tous deux fait l’objet de plusieurs stratégies
             de fork, les unes étant considérées plus "hostiles" que d’autres. Ici encore, la
             proximité des finalités poursuivies par des projets devenus concurrents déter-
             mine le caractère amical ou non de l’exercice et les déplacements ou segmen-
             tations des communautés entre elles. Spip fait l’objet depuis de nombreuses
             années de distributions concurrentes, dédiées plus spécifiquement au monde
             de l’éduction (Spipeva) ou intégrant des fonctionnalités supplémentaires
             (BioSpip). Mais en 2004, l’annonce d’une nouvelle version de Spip, dévelop-
             pée par un prestataire informatique pour le compte d’une administration
             publique jette le trouble dans la communauté. Cette nouvelle version du logi-
             ciel (dénommée Spip-Agora) est présentée par le prestataire comme étant de
             meilleure qualité, comprenant des fonctionnalités supplémentaires, pouvant
             s’adapter à des environnements technologiques plus diversifiés.
                   L’intention déclarée du commanditaire est de faire bénéficier ces déve-
             loppements au projet initial afin de l’améliorer, de lui permettre d’élargir son
             marché potentiel aux administrations, et plus généralement, d’accroître sa
             crédibilité professionnelle. Mais le fait de n’avoir pas joué le jeu de la parti-
             cipation communautaire, de ne pas avoir distillé petit à petit les transforma-
             tions réalisées, de ne pas avoir confronté les idées à la communauté et aux
             auteurs historiques en particulier, a provoqué un rejet de la part des auteurs.
                   Ceux-ci craignaient une récupération à des fins commerciales ou politi-
             ques du travail réalisé bénévolement par des dizaines de contributeurs, souvent

                                                                          É té 2006   ] te rminal [   81
2-T97   2/09/06   16:29        Page 82




           à partir de conditions de travail peu aisées, qui pourrait corrompre le carac-
           tère désintéressé de la communauté et provoquer une démotivation générale.
           Entre les deux projets qui coexistent désormais, les différences et les diver-
           gences s’approfondissent progressivement. Dans le cas de Claroline, la situa-
           tion se présente différemment étant donné que c’est l’auteur historique du pro-
           jet qui est dépossédé des rênes du développement par l’institution
           universitaire qui l’emploie. Ayant décroché un substantiel financement
           public pour parfaire le développement, il se voit, pour des raisons statutaires
           et politiques, refuser la direction du projet.
                 Il décide alors d’organiser son propre fork, en l’associant à la création
           d’une société de services. Ce départ brutal se concrétise sous la forme d’un
           e-mail envoyé à l’ensemble de la communauté, précisant notamment :
           "Quelqu’un a déposé la marque Claroline sans me demander mon avis et pro-
           pose de me la revendre au prix fort. Suivant la philosophie de l’Open Source,
           j’ai décidé de ne pas accepter cela et de changer le nom du projet pour
           Dokeos. Veuillez noter qu’à partir de dorénavant, notre projet de logiciel de
           e-Learning Open Source ne s’appelle plus Claroline, mais Dokeos". Cette
           stratégie de communication lui permettra d’attirer avec lui une part impor-
           tante de la communauté liée à Claroline.

           Les communautés distantes

                 Ces deux cas de fork dits "hostiles" indiquent ainsi les facilités poten-
           tielles de transfert de contributeurs "périphériques" lors de situations de forks
           au travers de stratégies de communication. N’entretenant pas de relation spé-
           cifique entre eux en dehors des espaces publics de discussion, ni de relation
           interpersonnelles avec le cercle stratégique, ils ne peuvent décoder facile-
           ment les stratégies d’acteurs et les changements de cap dans l’identité des
           projets. Tout au plus peuvent-ils tenter d’évaluer les enjeux fonctionnels ou
           techniques des schismes, sans nécessairement percevoir par la transformation
           de la raison sociale du projet. Cette situation sera vécue différemment par les
           membres des cercles intermédiaires et stratégique qui, se réunissant ou entre-
           tenant des interactions privées, définiront des stratégies coordonnées de
           résistance et d’offensive afin d’éviter l’hémorragie communautaire.
                 Le fork, dans ce cas, peut exacerber des conflits interpersonnels et pro-
           voquer des inimitiés sociales qui poussent, par ailleurs, à l’accentuation des
           traits spécifiques de l’identité du projet. Les collectifs qui produisent des
           logiciels libres, et qui s’auto-désignent comme des communautés, présentent
           des caractéristiques peu répandues dans le monde du travail : les contribu-
           teurs sont dispersés et sont affranchis de toute contrainte issue d’une autorité
           extérieure au collectif constitué par la mise en réseau [Lerner et Tirole,
           2002]. Comment une production est-elle possible dans ces conditions ?
                 On sait que distance relationnelle et identification à un groupe de projet
           ne sont pas contradictoires, et l’analyse des ressorts de la participation média-
           tisée par le réseau Internet a permis de renseigner ce paradoxe apparent, que

           82      ] te rminal [   É té 2006
2-T97   2/09/06   16:29   Page 83




             nous avons nommé ailleurs par l’expression "communautés distantes"
             [Demazière, Horn, Jullien, 2003]. Un autre aspect a été pris en compte ici,
             qui concerne la distribution des activités, l’organisation de la production et la
             structuration des relations de coopération. Car ces communautés distantes ont
             pour finalité le développement de logiciels informatiques opératoires, utilisa-
             bles, performants. Sous réserve d’une généralisation des résultats, nous
             avons alors pu observer que ces activités à participation libre s’appuient sur
             une répartition distribuée des tâches et sur une hiérarchie informelle. Ces
             modes de structuration apparaissent comme des conditions pour le lance-
             ment, la poursuite et le développement d’activités orientées vers la fabrica-
             tion d’un produit.
                   Au-delà, l’analyse des deux projets Claroline et Spip montre que pour
             être informelle, l’organisation n’en est pas moins visible à travers divers dis-
             positifs : signature des contributions au code, identification des animateurs
             des listes de diffusion, marquage des statuts. Ainsi les relations entre les
             membres de la communauté s’insèrent dans des chemins et réseaux verticaux
             tout autant qu’horizontaux.
                   Ces groupes se caractérisent par un équilibre entre la cohésion et l’adhé-
             sion d’une part, la différenciation et la hiérarchie de l’autre ; entre d’un côté
             une identification, qui est modulée selon la place occupée dans le groupe et
             qui est fortement soutenue par l’identité discriminante du produit, et de l’au-
             tre une division, qui est assouplie par les mobilités internes, et qui est solide-
             ment légitimée par la visibilité des contributions individuelles. Ces collectifs
             sont ainsi constitués d’emboîtements de tâches, de statuts et de cercles, et
             sous cet aspect ils apparaissent comme des communautés non seulement dis-
             tantes mais aussi, second paradoxe, clivées.
                                                                                             




                                                                         É té 2006   ] te rminal [   83
2-T97   2/09/06   16:29         Page 84




           RÉFÉRENCES
           D. DEMAZIÈRE, F. HORN, N. JULLIEN, "Le travail des développeurs de logiciels libres. La mobilisa-
           tion dans des communautés distantes", Communication au colloque du CLERSE, La représen-
           tation économique de l’acteur au travail, Villeneuve d’Ascq, 20-21 novembre 2003, publiée
           dans CLES (Cahiers Lillois d’Economie et de Sociologie) n° 46, 2003.
           D. FORAY, J.-B. ZIMMERMANN, "L’économie du logiciel libre : organisation coopérative et incita-
           tion à l’innovation", Revue Economique 52, pp. 77-93, 2001.
           M. GENSOLLEN, "Biens informationnels et communautés médiatées", Revue d’Economie
           Politique, mars 2004.
           R.L. GLASS, "A socio-political look at open source", Communications of the ACM, 46, pp. 21-23,
           2003.
           ALBERT O. HIRSCHMAN, Face au déclin des entreprises et des institutions, Éditions Ouvrières
           (Collection Economie humaine), 141 p., 1972, traduction de Exit, Voice and loyalty : responses
           to decline in firms, organizations and states, Harvard University Press, 1970.
           HOLTGREWE U., WERLE R., "De-Commodifying Software ? Open Source Software Between
           Business Strategy and Social Movement", Science Studies, 15, pp. 43-65, 2001.
           HORN F., L’économie des logiciels, La Découverte, Paris, 2004.
           LEBRUN M., "Théories et méthodes pédagogiques pour enseigner et apprendre", De Boeck
           Université, Bruxelles, 2002.
           LERNER J., TIROLE J., "Some simple economics of open source", Journal of Industrial
           Economics, 52, pp. 197-234, 2002.
           RAYMOND E.S., "La cathédrale et le bazar, trad. de Blondeel S.", 1998, http://www.lifl.fr/~blon-
           deel/traduc/Cathedral-bazaar/Main_file.html
           SALAIS R., STORPER M., Les mondes de production : enquête sur l’identité économique de la
           France, éditions de l’EHESS, Paris, 1993.
           TAYON J. ET PITROU A., "Libre Academy : statut ou compétence ?", Libroscope.org, 13 juin 2005.
           VON HIPPEL, "Open Souce Software as horizontal innovation networks – by and for users", MIT
           Sloan School of Management W.P. N° 4366-02, 2002.




           84       ] te rminal [   É té 2006

Más contenido relacionado

La actualidad más candente

Étudier les usages du web social
Étudier les usages du web social Étudier les usages du web social
Étudier les usages du web social Alexandre Coutant
 
Comparaison interactions sociales sur les médias socionumériques impec - do...
Comparaison interactions sociales sur les médias socionumériques   impec - do...Comparaison interactions sociales sur les médias socionumériques   impec - do...
Comparaison interactions sociales sur les médias socionumériques impec - do...JCDomenget
 
Que sont devenus les référenceurs pionniers ? Domenget & Michel - acfas
Que sont devenus les référenceurs pionniers ?   Domenget & Michel - acfasQue sont devenus les référenceurs pionniers ?   Domenget & Michel - acfas
Que sont devenus les référenceurs pionniers ? Domenget & Michel - acfasJCDomenget
 
Itfb mai 2015_dossier_collaboration
Itfb mai 2015_dossier_collaborationItfb mai 2015_dossier_collaboration
Itfb mai 2015_dossier_collaborationOne2Team
 
Analyser les commentaires numériques
Analyser les commentaires numériquesAnalyser les commentaires numériques
Analyser les commentaires numériquesJCDomenget
 
Les publics imaginés et réels des professionnels de l'Internet
Les publics imaginés et réels des professionnels de l'InternetLes publics imaginés et réels des professionnels de l'Internet
Les publics imaginés et réels des professionnels de l'InternetAlexandre Coutant
 
La surcharge cognitive interactionnelle
La surcharge cognitive interactionnelleLa surcharge cognitive interactionnelle
La surcharge cognitive interactionnelleThierry Nabeth
 
Conférence Idc entreprise 2.0 DSI lyonnaise des eaux
Conférence Idc entreprise 2.0   DSI lyonnaise des eauxConférence Idc entreprise 2.0   DSI lyonnaise des eaux
Conférence Idc entreprise 2.0 DSI lyonnaise des eauxCHARLES Frédéric
 

La actualidad más candente (14)

Étudier les usages du web social
Étudier les usages du web social Étudier les usages du web social
Étudier les usages du web social
 
Media aces lyonnaise des eaux
Media aces   lyonnaise des eauxMedia aces   lyonnaise des eaux
Media aces lyonnaise des eaux
 
powerpoint
powerpointpowerpoint
powerpoint
 
Comparaison interactions sociales sur les médias socionumériques impec - do...
Comparaison interactions sociales sur les médias socionumériques   impec - do...Comparaison interactions sociales sur les médias socionumériques   impec - do...
Comparaison interactions sociales sur les médias socionumériques impec - do...
 
Que sont devenus les référenceurs pionniers ? Domenget & Michel - acfas
Que sont devenus les référenceurs pionniers ?   Domenget & Michel - acfasQue sont devenus les référenceurs pionniers ?   Domenget & Michel - acfas
Que sont devenus les référenceurs pionniers ? Domenget & Michel - acfas
 
Itfb mai 2015_dossier_collaboration
Itfb mai 2015_dossier_collaborationItfb mai 2015_dossier_collaboration
Itfb mai 2015_dossier_collaboration
 
Presentation_wiki
Presentation_wikiPresentation_wiki
Presentation_wiki
 
Analyser les commentaires numériques
Analyser les commentaires numériquesAnalyser les commentaires numériques
Analyser les commentaires numériques
 
Les publics imaginés et réels des professionnels de l'Internet
Les publics imaginés et réels des professionnels de l'InternetLes publics imaginés et réels des professionnels de l'Internet
Les publics imaginés et réels des professionnels de l'Internet
 
Concepts 2.0 CG62
Concepts 2.0 CG62Concepts 2.0 CG62
Concepts 2.0 CG62
 
Webcom Montréal, piste #openGouv
Webcom Montréal, piste #openGouvWebcom Montréal, piste #openGouv
Webcom Montréal, piste #openGouv
 
La surcharge cognitive interactionnelle
La surcharge cognitive interactionnelleLa surcharge cognitive interactionnelle
La surcharge cognitive interactionnelle
 
Conférence Idc entreprise 2.0 DSI lyonnaise des eaux
Conférence Idc entreprise 2.0   DSI lyonnaise des eauxConférence Idc entreprise 2.0   DSI lyonnaise des eaux
Conférence Idc entreprise 2.0 DSI lyonnaise des eaux
 
Co-construction d'un site web collaboratif à Dakar
Co-construction d'un site web collaboratif à DakarCo-construction d'un site web collaboratif à Dakar
Co-construction d'un site web collaboratif à Dakar
 

Destacado

Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...
Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...
Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...Canadian Patient Safety Institute
 
Instrucciones
InstruccionesInstrucciones
InstruccionesRicardo
 
Un area natural protegida en la cordillera del condor
Un area natural protegida en la cordillera del condorUn area natural protegida en la cordillera del condor
Un area natural protegida en la cordillera del condorcordilleradelcondor
 
Presentacio slideshare pau
Presentacio slideshare pauPresentacio slideshare pau
Presentacio slideshare paupau
 
2 mois pour réactiver une communauté
2 mois pour réactiver une communauté2 mois pour réactiver une communauté
2 mois pour réactiver une communautéVincent Michelot
 
Tic Project
Tic ProjectTic Project
Tic Projectmerchemm
 
2011 04-14 powerpointpng
2011 04-14 powerpointpng2011 04-14 powerpointpng
2011 04-14 powerpointpngRicardo
 
Guide pour la prise de notes collaboratives
Guide pour la prise de notes collaborativesGuide pour la prise de notes collaboratives
Guide pour la prise de notes collaborativesTison Bruno
 
Paris je t’aime 2
Paris je t’aime 2Paris je t’aime 2
Paris je t’aime 2adecraene
 
La estrategia en redes sociales, una clave de internacionalización #enredate...
La estrategia en redes sociales, una clave de internacionalización #enredate...La estrategia en redes sociales, una clave de internacionalización #enredate...
La estrategia en redes sociales, una clave de internacionalización #enredate...Soluciona Facil
 
Proyecto De Transformacion De La Escuela Secundaria
Proyecto De Transformacion De La Escuela SecundariaProyecto De Transformacion De La Escuela Secundaria
Proyecto De Transformacion De La Escuela Secundariaguest02e9f
 
PresentacióN1
PresentacióN1PresentacióN1
PresentacióN1Edu Fraga
 

Destacado (20)

Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...
Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...
Prévention et gestion des chutes : Un nouvel outil pour faciliter l’améliorat...
 
Instrucciones
InstruccionesInstrucciones
Instrucciones
 
Materiales1c
Materiales1cMateriales1c
Materiales1c
 
Un area natural protegida en la cordillera del condor
Un area natural protegida en la cordillera del condorUn area natural protegida en la cordillera del condor
Un area natural protegida en la cordillera del condor
 
Presentacio slideshare pau
Presentacio slideshare pauPresentacio slideshare pau
Presentacio slideshare pau
 
Les gouttes d'eau
Les gouttes d'eauLes gouttes d'eau
Les gouttes d'eau
 
2 mois pour réactiver une communauté
2 mois pour réactiver une communauté2 mois pour réactiver une communauté
2 mois pour réactiver une communauté
 
Tic Project
Tic ProjectTic Project
Tic Project
 
TIC
TICTIC
TIC
 
2011 04-14 powerpointpng
2011 04-14 powerpointpng2011 04-14 powerpointpng
2011 04-14 powerpointpng
 
Guide pour la prise de notes collaboratives
Guide pour la prise de notes collaborativesGuide pour la prise de notes collaboratives
Guide pour la prise de notes collaboratives
 
Paris je t’aime 2
Paris je t’aime 2Paris je t’aime 2
Paris je t’aime 2
 
La mobilité change la donne en Chine
La mobilité change la donne en ChineLa mobilité change la donne en Chine
La mobilité change la donne en Chine
 
Talents@Kerensen
Talents@KerensenTalents@Kerensen
Talents@Kerensen
 
La estrategia en redes sociales, una clave de internacionalización #enredate...
La estrategia en redes sociales, una clave de internacionalización #enredate...La estrategia en redes sociales, una clave de internacionalización #enredate...
La estrategia en redes sociales, una clave de internacionalización #enredate...
 
Reglas
ReglasReglas
Reglas
 
Proyecto De Transformacion De La Escuela Secundaria
Proyecto De Transformacion De La Escuela SecundariaProyecto De Transformacion De La Escuela Secundaria
Proyecto De Transformacion De La Escuela Secundaria
 
Secasan.cl
Secasan.clSecasan.cl
Secasan.cl
 
Competencia Curriculum Iteso
Competencia Curriculum ItesoCompetencia Curriculum Iteso
Competencia Curriculum Iteso
 
PresentacióN1
PresentacióN1PresentacióN1
PresentacióN1
 

Similar a Dev communautes logiciel libre

co-création de valeur.pdf
co-création de valeur.pdfco-création de valeur.pdf
co-création de valeur.pdfAzmour Mohamed
 
Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...
Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...
Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...compuBase Consulting
 
Fab mob numeriques en communs
Fab mob numeriques en communsFab mob numeriques en communs
Fab mob numeriques en communsFabMob
 
Fabmob 2017
Fabmob 2017Fabmob 2017
Fabmob 2017FabMob
 
Conférence sur la Digital Workplace au Salon Intranet & Collaboratif
Conférence sur la Digital Workplace au Salon Intranet & CollaboratifConférence sur la Digital Workplace au Salon Intranet & Collaboratif
Conférence sur la Digital Workplace au Salon Intranet & CollaboratifeXo Platform
 
Pmb Bug 2007 11 06 Eric
Pmb Bug 2007 11 06 EricPmb Bug 2007 11 06 Eric
Pmb Bug 2007 11 06 EricPMB-BUG
 
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...Open Source Politics
 
15 ans de politiques publiques du logiciel libre en France
15 ans de politiques publiques du logiciel libre en France15 ans de politiques publiques du logiciel libre en France
15 ans de politiques publiques du logiciel libre en FranceStefane Fermigier
 
Quenaya intranet collab datasheet client jalios French
Quenaya intranet collab datasheet client jalios FrenchQuenaya intranet collab datasheet client jalios French
Quenaya intranet collab datasheet client jalios FrenchQuenaya France
 
Les enjeux de la société digitale Session 3 L'organisation à l'ère digitale
Les enjeux de la société digitale Session 3 L'organisation à l'ère digitaleLes enjeux de la société digitale Session 3 L'organisation à l'ère digitale
Les enjeux de la société digitale Session 3 L'organisation à l'ère digitaleHenri ISAAC
 
Quelques réflexions autour du community management
Quelques réflexions autour du community managementQuelques réflexions autour du community management
Quelques réflexions autour du community managementAnthony Poncier
 
Fab mob prez#3
Fab mob prez#3Fab mob prez#3
Fab mob prez#3FabMob
 
Fab mob 2019
Fab mob 2019Fab mob 2019
Fab mob 2019FabMob
 
Feuille deroute communsnumeriques
Feuille deroute communsnumeriquesFeuille deroute communsnumeriques
Feuille deroute communsnumeriquesFabMob
 
Présentation concepts travail collaboratif
Présentation concepts travail collaboratifPrésentation concepts travail collaboratif
Présentation concepts travail collaboratifloubnayacoubi
 
TCM - Livre blanc sur les plateformes communautaires Open Source
TCM - Livre blanc sur les plateformes communautaires Open SourceTCM - Livre blanc sur les plateformes communautaires Open Source
TCM - Livre blanc sur les plateformes communautaires Open SourceJEAN-GUILLAUME DUJARDIN
 
Pl news letter_nov10
Pl news letter_nov10Pl news letter_nov10
Pl news letter_nov10robertpluss
 
Nos systèmes : dossier de partenariat
Nos systèmes : dossier de partenariatNos systèmes : dossier de partenariat
Nos systèmes : dossier de partenariatFing
 
Essentiels Web 2.0 vers Entreprise 2.0
Essentiels Web 2.0 vers Entreprise 2.0Essentiels Web 2.0 vers Entreprise 2.0
Essentiels Web 2.0 vers Entreprise 2.0Claude Super
 

Similar a Dev communautes logiciel libre (20)

co-création de valeur.pdf
co-création de valeur.pdfco-création de valeur.pdf
co-création de valeur.pdf
 
Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...
Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...
Matinee compu base_20101109_4_useo_compubase_reseaux_sociaux_rse_par_anthony_...
 
Livre blanc v1.0
Livre blanc v1.0Livre blanc v1.0
Livre blanc v1.0
 
Fab mob numeriques en communs
Fab mob numeriques en communsFab mob numeriques en communs
Fab mob numeriques en communs
 
Fabmob 2017
Fabmob 2017Fabmob 2017
Fabmob 2017
 
Conférence sur la Digital Workplace au Salon Intranet & Collaboratif
Conférence sur la Digital Workplace au Salon Intranet & CollaboratifConférence sur la Digital Workplace au Salon Intranet & Collaboratif
Conférence sur la Digital Workplace au Salon Intranet & Collaboratif
 
Pmb Bug 2007 11 06 Eric
Pmb Bug 2007 11 06 EricPmb Bug 2007 11 06 Eric
Pmb Bug 2007 11 06 Eric
 
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
Webinaire Civic Tech : Pourquoi l'open source devient-il la norme pour les dé...
 
15 ans de politiques publiques du logiciel libre en France
15 ans de politiques publiques du logiciel libre en France15 ans de politiques publiques du logiciel libre en France
15 ans de politiques publiques du logiciel libre en France
 
Quenaya intranet collab datasheet client jalios French
Quenaya intranet collab datasheet client jalios FrenchQuenaya intranet collab datasheet client jalios French
Quenaya intranet collab datasheet client jalios French
 
Les enjeux de la société digitale Session 3 L'organisation à l'ère digitale
Les enjeux de la société digitale Session 3 L'organisation à l'ère digitaleLes enjeux de la société digitale Session 3 L'organisation à l'ère digitale
Les enjeux de la société digitale Session 3 L'organisation à l'ère digitale
 
Quelques réflexions autour du community management
Quelques réflexions autour du community managementQuelques réflexions autour du community management
Quelques réflexions autour du community management
 
Fab mob prez#3
Fab mob prez#3Fab mob prez#3
Fab mob prez#3
 
Fab mob 2019
Fab mob 2019Fab mob 2019
Fab mob 2019
 
Feuille deroute communsnumeriques
Feuille deroute communsnumeriquesFeuille deroute communsnumeriques
Feuille deroute communsnumeriques
 
Présentation concepts travail collaboratif
Présentation concepts travail collaboratifPrésentation concepts travail collaboratif
Présentation concepts travail collaboratif
 
TCM - Livre blanc sur les plateformes communautaires Open Source
TCM - Livre blanc sur les plateformes communautaires Open SourceTCM - Livre blanc sur les plateformes communautaires Open Source
TCM - Livre blanc sur les plateformes communautaires Open Source
 
Pl news letter_nov10
Pl news letter_nov10Pl news letter_nov10
Pl news letter_nov10
 
Nos systèmes : dossier de partenariat
Nos systèmes : dossier de partenariatNos systèmes : dossier de partenariat
Nos systèmes : dossier de partenariat
 
Essentiels Web 2.0 vers Entreprise 2.0
Essentiels Web 2.0 vers Entreprise 2.0Essentiels Web 2.0 vers Entreprise 2.0
Essentiels Web 2.0 vers Entreprise 2.0
 

Más de Rayna Stamboliyska

The NIS directive: Yet another expensive legality or an opportunity to improv...
The NIS directive: Yet another expensive legality or an opportunity to improv...The NIS directive: Yet another expensive legality or an opportunity to improv...
The NIS directive: Yet another expensive legality or an opportunity to improv...Rayna Stamboliyska
 
#CoRIIN2018 : Comment ne pas communiquer en temps de crise
#CoRIIN2018 : Comment ne pas communiquer en temps de crise#CoRIIN2018 : Comment ne pas communiquer en temps de crise
#CoRIIN2018 : Comment ne pas communiquer en temps de criseRayna Stamboliyska
 
Références bibliographiques "La face cachée d'Internet"
Références bibliographiques "La face cachée d'Internet"Références bibliographiques "La face cachée d'Internet"
Références bibliographiques "La face cachée d'Internet"Rayna Stamboliyska
 
La question de mémoire collective post-conflictuelle : une comparaison des di...
La question de mémoire collective post-conflictuelle : une comparaison des di...La question de mémoire collective post-conflictuelle : une comparaison des di...
La question de mémoire collective post-conflictuelle : une comparaison des di...Rayna Stamboliyska
 
The role of data for economic prosperity in the Middle East and North Africa
The role of data for economic prosperity in the Middle East and North AfricaThe role of data for economic prosperity in the Middle East and North Africa
The role of data for economic prosperity in the Middle East and North AfricaRayna Stamboliyska
 
ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)
ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)
ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)Rayna Stamboliyska
 
Let's talk about policy! Politiques publiques pour l’ouverture des données sc...
Let's talk about policy! Politiques publiques pour l’ouverture des données sc...Let's talk about policy! Politiques publiques pour l’ouverture des données sc...
Let's talk about policy! Politiques publiques pour l’ouverture des données sc...Rayna Stamboliyska
 
Open Data Barometer, 2nd edition
Open Data Barometer, 2nd editionOpen Data Barometer, 2nd edition
Open Data Barometer, 2nd editionRayna Stamboliyska
 
Egypt: News Websites and Alternative Voices
Egypt: News Websites and Alternative VoicesEgypt: News Websites and Alternative Voices
Egypt: News Websites and Alternative VoicesRayna Stamboliyska
 
Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015
Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015
Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015Rayna Stamboliyska
 
Открытые данные для социально- экономического развития: Роль гражданского общ...
Открытые данные для социально- экономического развития: Роль гражданского общ...Открытые данные для социально- экономического развития: Роль гражданского общ...
Открытые данные для социально- экономического развития: Роль гражданского общ...Rayna Stamboliyska
 
#OpenDataKG: Open Data and the role of civil society
#OpenDataKG: Open Data and the role of civil society#OpenDataKG: Open Data and the role of civil society
#OpenDataKG: Open Data and the role of civil societyRayna Stamboliyska
 
Programme BIL:OpenGov Tunisie (21 juin 2014)
Programme BIL:OpenGov Tunisie (21 juin 2014)Programme BIL:OpenGov Tunisie (21 juin 2014)
Programme BIL:OpenGov Tunisie (21 juin 2014)Rayna Stamboliyska
 
Cours pour la Licence "Sciences et Ingéniérie" ENSTA
Cours pour la Licence "Sciences et Ingéniérie" ENSTACours pour la Licence "Sciences et Ingéniérie" ENSTA
Cours pour la Licence "Sciences et Ingéniérie" ENSTARayna Stamboliyska
 
Gendered Quantified Self: my talk at FLOSSIE 2013
Gendered Quantified Self: my talk at FLOSSIE 2013Gendered Quantified Self: my talk at FLOSSIE 2013
Gendered Quantified Self: my talk at FLOSSIE 2013Rayna Stamboliyska
 
Big data, bad data -- Closing keynote at the Open World Forum 2013
Big data, bad data -- Closing keynote at the Open World Forum 2013Big data, bad data -- Closing keynote at the Open World Forum 2013
Big data, bad data -- Closing keynote at the Open World Forum 2013Rayna Stamboliyska
 
Open Data in Science & Research -- Open World Forum 2013, Public Policies track
Open Data in Science & Research -- Open World Forum 2013, Public Policies trackOpen Data in Science & Research -- Open World Forum 2013, Public Policies track
Open Data in Science & Research -- Open World Forum 2013, Public Policies trackRayna Stamboliyska
 
Knowledge Adventures for Kids: Masterclass presentation during the Social Med...
Knowledge Adventures for Kids: Masterclass presentation during the Social Med...Knowledge Adventures for Kids: Masterclass presentation during the Social Med...
Knowledge Adventures for Kids: Masterclass presentation during the Social Med...Rayna Stamboliyska
 
NASA SpaceApps challenges: Paris Off-the-Grid restitution
NASA SpaceApps challenges: Paris Off-the-Grid restitutionNASA SpaceApps challenges: Paris Off-the-Grid restitution
NASA SpaceApps challenges: Paris Off-the-Grid restitutionRayna Stamboliyska
 

Más de Rayna Stamboliyska (20)

The NIS directive: Yet another expensive legality or an opportunity to improv...
The NIS directive: Yet another expensive legality or an opportunity to improv...The NIS directive: Yet another expensive legality or an opportunity to improv...
The NIS directive: Yet another expensive legality or an opportunity to improv...
 
#CoRIIN2018 : Comment ne pas communiquer en temps de crise
#CoRIIN2018 : Comment ne pas communiquer en temps de crise#CoRIIN2018 : Comment ne pas communiquer en temps de crise
#CoRIIN2018 : Comment ne pas communiquer en temps de crise
 
Références bibliographiques "La face cachée d'Internet"
Références bibliographiques "La face cachée d'Internet"Références bibliographiques "La face cachée d'Internet"
Références bibliographiques "La face cachée d'Internet"
 
La question de mémoire collective post-conflictuelle : une comparaison des di...
La question de mémoire collective post-conflictuelle : une comparaison des di...La question de mémoire collective post-conflictuelle : une comparaison des di...
La question de mémoire collective post-conflictuelle : une comparaison des di...
 
The role of data for economic prosperity in the Middle East and North Africa
The role of data for economic prosperity in the Middle East and North AfricaThe role of data for economic prosperity in the Middle East and North Africa
The role of data for economic prosperity in the Middle East and North Africa
 
ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)
ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)
ОТВОРЕНИ ДАННИ ЗА ДОБРО УПРАВЛЕНИЕ (Open Data for Good Governance)
 
Let's talk about policy! Politiques publiques pour l’ouverture des données sc...
Let's talk about policy! Politiques publiques pour l’ouverture des données sc...Let's talk about policy! Politiques publiques pour l’ouverture des données sc...
Let's talk about policy! Politiques publiques pour l’ouverture des données sc...
 
Open Data Barometer, 2nd edition
Open Data Barometer, 2nd editionOpen Data Barometer, 2nd edition
Open Data Barometer, 2nd edition
 
Egypt: News Websites and Alternative Voices
Egypt: News Websites and Alternative VoicesEgypt: News Websites and Alternative Voices
Egypt: News Websites and Alternative Voices
 
Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015
Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015
Contes et légendes du RuNet : séminaire EHESS du 16 mars 2015
 
Corruption risk management
Corruption risk managementCorruption risk management
Corruption risk management
 
Открытые данные для социально- экономического развития: Роль гражданского общ...
Открытые данные для социально- экономического развития: Роль гражданского общ...Открытые данные для социально- экономического развития: Роль гражданского общ...
Открытые данные для социально- экономического развития: Роль гражданского общ...
 
#OpenDataKG: Open Data and the role of civil society
#OpenDataKG: Open Data and the role of civil society#OpenDataKG: Open Data and the role of civil society
#OpenDataKG: Open Data and the role of civil society
 
Programme BIL:OpenGov Tunisie (21 juin 2014)
Programme BIL:OpenGov Tunisie (21 juin 2014)Programme BIL:OpenGov Tunisie (21 juin 2014)
Programme BIL:OpenGov Tunisie (21 juin 2014)
 
Cours pour la Licence "Sciences et Ingéniérie" ENSTA
Cours pour la Licence "Sciences et Ingéniérie" ENSTACours pour la Licence "Sciences et Ingéniérie" ENSTA
Cours pour la Licence "Sciences et Ingéniérie" ENSTA
 
Gendered Quantified Self: my talk at FLOSSIE 2013
Gendered Quantified Self: my talk at FLOSSIE 2013Gendered Quantified Self: my talk at FLOSSIE 2013
Gendered Quantified Self: my talk at FLOSSIE 2013
 
Big data, bad data -- Closing keynote at the Open World Forum 2013
Big data, bad data -- Closing keynote at the Open World Forum 2013Big data, bad data -- Closing keynote at the Open World Forum 2013
Big data, bad data -- Closing keynote at the Open World Forum 2013
 
Open Data in Science & Research -- Open World Forum 2013, Public Policies track
Open Data in Science & Research -- Open World Forum 2013, Public Policies trackOpen Data in Science & Research -- Open World Forum 2013, Public Policies track
Open Data in Science & Research -- Open World Forum 2013, Public Policies track
 
Knowledge Adventures for Kids: Masterclass presentation during the Social Med...
Knowledge Adventures for Kids: Masterclass presentation during the Social Med...Knowledge Adventures for Kids: Masterclass presentation during the Social Med...
Knowledge Adventures for Kids: Masterclass presentation during the Social Med...
 
NASA SpaceApps challenges: Paris Off-the-Grid restitution
NASA SpaceApps challenges: Paris Off-the-Grid restitutionNASA SpaceApps challenges: Paris Off-the-Grid restitution
NASA SpaceApps challenges: Paris Off-the-Grid restitution
 

Dev communautes logiciel libre

  • 1. 2-T97 2/09/06 16:28 Page 71 Dynamique de développement des communautés du logiciel libre Conditions d’émergence et régulations des tensions Didier Demazière, François Horn, Marc Zune* L a renommée et l’usage des logiciels libres ne cessent de croître et le nombre de projets déposés sur les sites de développement mutualisés poursuit une croissance exponentielle. Le site de développement com- munautaire SourceForge dénombrait, fin 2005 plus de 100 000 projets et plus d’un million de développeurs référencés. Ces projets sont marqués par une très forte hétérogénéité concernant le nombre de contributeurs et leur organisation. Si les développeurs de logiciels libres et certains projets emblématiques ont fait l’objet d’études, une question reste cependant, à ce jour, peu analysée : qu’est- ce qui explique que parmi tous ces projets certains parviennent à attirer des contributeurs permettant d’enclencher une dynamique de développement ? Parmi l’ensemble des modèles de production de logiciels [Horn, 2004], le développement des logiciels libres présente l’originalité d’être fondé sur un mode d’organisation coopératif qui s’appuie largement sur les commodi- tés organisationnelles issues d’Internet. Les développeurs ne sont pas inscrits dans la même organisation, sont dispersés, ont des relations médiatisées par le réseau Internet, ne sont pas reliés par les fils d’un organigramme quelcon- que. Il n’existe pas d’interactions directes, codifiées et prescrites entre les producteurs du logiciel. En principe, toute personne peut fournir une contri- bution et participer à l’élaboration d’un bien collectif et public. Les échanges entre contributeurs s’effectuent quasi-exclusivement à partir de modes de communication électroniques : courrier électronique, lis- tes de diffusion, forums, chat, dispositif d’enregistrement et de visualisation du code produit, etc. Ce fonctionnement à distance, permet d’attirer des contributions nombreuses, favorise un meilleur repérage des erreurs par les utilisateurs, et autorise des corrections plus rapides. Cette configuration conduit à s’interroger sur les caractéristiques de l’action collective qui per- met de passer d’engagements individuels volontaires, et potentiellement volatiles et instables, à la réalisation d’une production collective, impliquant continuité et pérennité. Le mode de développement du logiciel libre qui * Didier Demazière (Printemps, CRS/Université de Versailles - Saint-Quentin-en-Yvelines) ; François Horn (CLERSE-IFRESI, Université Lille 3 ; Marc Zune (CSTEF, FNRS/Université Libre de Brxelles). É té 2006 ] te rminal [ 71
  • 2. 2-T97 2/09/06 16:28 Page 72 repose largement, en apparence, sur le caractère bénévole des contributions, se singularise par rapport aux modes de production habituels encadrés par des relations de travail salariales ou contractuelles. Mis à part une licence d’utilisation spécifique, cette activité n’est en effet régulée par aucun dispo- sitif juridique relevant du droit du travail ou commercial, ni par des incitants pécuniaires, ni par des rapports de subordination [Gensollen, 2004]. Les groupes de production sont d’ailleurs désignés dans les milieux du logiciel libre par le terme communauté, et la gestion est référée à un "modèle du bazar" [Raymond, 1998], fondé sur une très forte décentralisation auprès de contributeurs non sélectionnés, dépourvu de coordination formelle, de cahier des charges ou d’injonctions temporelles, laissant libre cours à l’imagination et l’implication individuelles [Glass, 2003, Holgrewe et Werle, 2001]. Cette modélisation du fonctionnement des communautés de logiciels libres a une fonction politique consistant à affirmer le caractère original et alternatif de ce mode de production par rapport à l’industrie du logiciel pro- priétaire ("modèle de la cathédrale"). Sa valeur descriptive et sociologique apparaît en revanche contestable. Car la production d’un bien collectif de qualité à partir de contributions individuelles volontaires nécessite des for- mes de régulation. Développer un logiciel selon un mode collaboratif sup- pose de réaliser une série d’opérations : mobiliser des développeurs autour d’un projet, assurer une relative continuité des participations, vérifier la qua- lité des contributions, agencer les développements validés en un produit cohérent et opératoire, etc. Notre analyse vise à tenter de cerner le fonctionnement des communau- tés de logiciels libres dans leurs processus de constitution et de développe- ment. Au-delà de l’extrême diversité organisationnelle des différents projets de développement de logiciels libres [Demazzière, Horn, Jullien, 2003], il s’agit d’éclaircir plusieurs interrogations : comment se constituent et se structurent ces collectifs de travail ? Comment sont-ils animés, gérés, fédé- rés, soutenus ? Comment maintient-on, dans ces conditions, un produit cohé- rent, avec une certaine identité et continuité dans le temps ? Pour cela, nous proposons de spécifier une série de moments-clés dans le développement d’un projet libre, du stade de l’émergence aux possibilités d’extinction ou de scissions. À cet effet, nous nous appuyons sur deux études de cas de logiciels libres, les projets Spip et Claroline1. Conditions d’émergence d’une communauté La brève présentation en encadré des deux projets à la base de notre réflexion nous renseigne d’emblée sur une première condition nécessaire au Suite page 74 1. Ceux-ci ont été choisis parce qu’ils sont de taille moyenne, sont en phase de développement et sont confrontés à des enjeux de légitimité que les projets les plus connus et les plus établis (Linux, Apache, etc.) ne connaissent plus. L’investigation empirique a été menée à la manière d’une enquête ethnographi- que en s’appuyant sur 35 entretiens approfondis de recherche auprès de participants présentant des contributions et activités différenciées. 72 ] te rminal [ É té 2006
  • 3. 2-T97 2/09/06 16:28 Page 73 SPIP, UN OUTIL D’AUTOPUBLICATION SUR LE WEB Le projet "Spip" se présente comme une figure a priori emblématique d’un fonctionnement communautaire fondé sur l’apport central d’individus dispersés et non reliés par quelque arrangement institutionnel ou d’emploi particulier. C’est afin d’aider les membres d’une association à s’exprimer par eux-mêmes en toute autonomie que l’un d’entre eux a l’idée de développer un outil informatique facili- tant la fabrication de pages Web et la gestion du site de l’association. La particularité est que l’usage de ce logiciel ne nécessite pas de connais- sances techniques particulières et doit pouvoir "tourner" sur des serveurs peu véloces, et par conséquent peu onéreux. Après quelques mois d’usage interne, la demande se manifeste rapidement pour que cet outil puisse être utilisé par d’au- tres associations. Un sympathisant informaticien se propose d’aider le concepteur de l’outil, infographiste, et s’implique dans le développement. En même temps, un webmestre d’un grand journal mensuel d’opinion manifeste l’intérêt d’utiliser ce logiciel à des fins de publication en ligne. Cette équipe de base constituera le "noyau" historique du projet, les "auteurs" du logiciel. Ces trois fondateurs partagent une ligne philosophique qu’ils souhaitent poursuivre, celle de l’auto-publication et de l’indépendance des utilisateurs face à toute contrainte à la liberté d’expression. Ils entendent, face au péril pressenti d’une certaine mainmise des industries du contenu, préserver des espaces de libre expression pouvant être investis par tout acteur de la vie sociale, quelles que soient ses compétences techniques et ses ressources matérielles. Cette orienta- tion, traduite en manifeste du Web indépendant, se décline à la fois dans des par- tis pris techniques et fonctionnels (liberté de réaction aux contenus publiés, limi- tation de la hiérarchie des droits de publication, etc.), mais également dans un projet militant de diffusion de la liberté d’expression. Le succès du logiciel est fulgurant. Spip connaît une utilisation fortement croissante, au point de devenir une référence incontournable parmi l’offre de logi- ciels de gestion de contenu sur Internet. C’est que l’outil développé, certes impar- fait dans ses premières moutures, répond à un besoin criant au moment de son apparition, face aux solutions "propriétaires" souvent trop onéreuses et anglopho- nes. Ce succès s’accompagne du développement d’une communauté importante et internationale du fait de la traduction du logiciel et de son support en plus de trente langues. Ces contributeurs présentent des profils diversifiés : militants de sites associatifs, webmestres ,infographistes, informaticiens pointus, que ce soit à titre professionnel ou d’activité hors travail. Après une année de développement, un prestataire informatique sous contrat avec une administration publique propose une réécriture partielle du logi- ciel en introduisant une méthode de programmation plus complexe et l’ajout de fonctionnalités jugées plus adaptées au monde professionnel. L’absence de colla- boration avec la communauté provoquera le rejet de la greffe proposée et une scission de fait (un fork dans la terminologie indigène), avec le développement en parallèle d’une autre version du logiciel intitulée Spip-Agora. É té 2006 ] te rminal [ 73
  • 4. 2-T97 2/09/06 16:28 Page 74 CLAROLINE, UNE PLATE-FORME DE E-LEARNING Claroline est un logiciel développé par une université belge. L’idée de ce pro- jet revient à un jeune docteur en philosophie chargé par son institution de promou- voir l’utilisation d’un logiciel commercial de support à l’enseignement en ligne. Malgré les efforts, notamment de formation, la mission est un échec, le logiciel étant jugé trop lourd et contraignant par les enseignants. Dans le même temps, l’initiateur du projet découvre sur Internet des outils logiciels libres simples répon- dant aux principales fonctionnalités demandées par les enseignants. Il décide alors d’intégrer ces outils et de les doter d’une interface commune créant ainsi un nouveau logiciel qu’il diffuse sous licence libre. Claroline connaît un succès rapide au sein de l’institution et dans d’autres universités aux besoins identiques. En interne, l’équipe de développement s’étoffe progressivement, avec deux autres développeurs engagés à temps plein pour répondre aux besoins des utilisateurs locaux et améliorer les fonctionnalités demandées. Des utilisateurs avancés, sur- tout des gestionnaires de campus numériques d’autres universités (plus d’une centaine, essentiellement du sud de l’Europe et du monde hispanique), participent aux discussions sur les forums du projet, proposent des traductions, rapportent des bogues lors de chaque nouvelle version, font part de leurs souhaits en matière de fonctionnalités nouvelles. L’équipe interne défend deux valeurs centrales à la base du projet : la flexi- bilité et la simplicité d’utilisation, à l’exact opposé des traits attribués aux logiciels commerciaux les plus en vogue. Il s’agit de proposer à l’enseignant un ensemble d’outils de support à l’enseignement (forum, dépôt de documents, agenda, etc.) sans le contraindre à un usage prescrit. Par conséquent, toute contribution au code du logiciel, indépendamment de sa qualité technique, n’est acceptée que pour autant qu’elle respecte ces deux traits. Dans les faits, bon nombre de propo- sitions de collaboration sur le code sont ainsi rejetées. Les apports techniques proposés par les contributeurs "distants" portent davantage sur des petites cor- rections, qui, lorsqu’elles sont jugées intéressantes, sont réécrites au moins en partie par les développeurs de l’université. L’essentiel des autres contributions portent par conséquent sur des activités de traduction ou de rapports de bogues. La grande diffusion du logiciel entraîne, assez rapidement, une multitude de demandes de prestations de services visant à adapter le logiciel aux contextes spécifiques des utilisateurs. Cette demande amène les fondateurs à solliciter une aide publique afin d’améliorer les fonctionnalités du logiciel. Cet argent public per- mettra, en 2004, d’étendre l’équipe interne à trois nouvelles personnes. Cependant un conflit éclate entre le fondateur du logiciel et l’université qui veut lui retirer le leadership du projet. L’initiateur du projet décide alors de créer sa propre société de conseil en organisant son propre fork de Claroline, intitulé Dokeos. Suite de la page 72 développement d’une communauté : l’outil proposé comble un manque dans l’offre des logiciels commerciaux ou répond à des besoins mal couverts par ces derniers étant donné l’impossibilité de les améliorer vu l’absence d’accès 74 ] te rminal [ É té 2006
  • 5. 2-T97 2/09/06 16:28 Page 75 au code source. Ainsi les logiciels libres les plus connus et les plus utilisés sont nés sur des créneaux où leurs équivalents commerciaux n’existaient pas (les outils logiciels nécessaires au fonctionnement d’Internet dans les années 80) ou dans des domaines où les qualités des logiciels existants étaient jugées insuffisantes, notamment en termes de sécurité et de fiabilité (par exemple les systèmes d’exploitation). Des manques plus limités des logiciels courants peuvent cependant suffire pour créer un espace propice à la naissance d’un logiciel libre, comme l’absence d’une version francophone, la nécessité de ressources importantes et donc coûteuses ou la simplicité d’utilisation. En effet, les logiciels commerciaux sont souvent des produits très com- plexes marqués par une culture informaticienne. Il peut en résulter un déca- lage par rapport aux besoins d’une partie des utilisateurs, ce qui explique que l’on trouve fréquemment dans les noyaux initiateurs des logiciels libres des non-informaticiens professionnels. Les cas de Spip et de Claroline sont à cet égard emblématiques de la diversité des origines disciplinaires des initiateurs des projets : un pilote de ligne reconverti dans l’infographie, un docteur en mathématiques et un ingénieur télécom dans le cas de Spip, deux philosophes et un pédagogue dans le cas de Claroline. Outre le fait de combler des manques existants, les choix effectués par les initiateurs du projet définissent l’identité originale [Salais, Storper, 1993] du logiciel qui sera développé. Les caractéristiques particulières du logiciel sont la traduction de cette identité spécifique. Ces caractéristiques qui sont dépendantes du processus de production du logiciel et qui influent sur son utilisation peuvent apparaître de prime abord comme de simples choix tech- niques entre des exigences contradictoires (richesse fonctionnelle versus simplicité d’utilisation…). Mais il est fréquent qu’en réalité les options rete- nues soient marquées par des conceptions sociales. C’est particulièrement net quand le logiciel vise à informatiser une activité existante : dans ce cas, la définition des caractéristiques fonctionnelles du logiciel est le reflet direct de la vision de l’activité. Ainsi, les caractéristiques de Spip sont fortement dépendantes de la représentation des initiateurs de ce qu’est une activité édi- toriale et de la manière de la mener. L’interface graphique de la zone d’admi- nistration du logiciel mène à une mise en scène du processus de rédaction, qui passe notamment par la discussion et la validation de pairs avant publi- cation. Placé dans l’espace public, l’article rédigé est associé à un dispositif de forum afin de susciter commentaires, réactions voire controverses. Cette stimulation du regard des pairs vise à insuffler et promouvoir une culture de débats dans la publication sur Internet. De même, Claroline se définit par le caractère simple et incrémental de son utilisation, qui renvoie à un modèle de pédagogie active. Ce modèle tend à considérer la technologie comme miroir des processus d’apprentissage humains "naturels" qui dépas- sent la simple acquisition de connaissances ou de règles. Ceux-ci s’inscrivent également dans des contextes, attitudes et comportements culturellement situés [Lebrun, 2002]. Le logiciel doit servir les choix du pédagogue, facili- ter les processus d’apprentissage à partir d’expériences diverses plutôt que É té 2006 ] te rminal [ 75
  • 6. 2-T97 2/09/06 16:28 Page 76 d’enfermer un transfert de connaissance dans un one best way pédagogique universel. L’ensemble des choix effectués à partir des orientations symboli- ques et idéologiques des promoteurs du projet va définir l’identité spécifique du logiciel proposé et sa différenciation par rapport à d’autres produits voi- sins et concurrents. Quand cette identité répond aux attentes d’utilisateurs, et même si le logiciel est très imparfait dans ses premières moutures, une com- munauté de contributeurs peut émerger. En effet, cette identité spécifique, discriminante par rapport aux autres logiciels existants est le vecteur d’un sentiment d’appartenance communautaire qui peut motiver une partie des utilisateurs à devenir des contributeurs. En outre, c’est sans doute parce qu’on ne peut réduire l’activité de déve- loppement à la réalisation d’un simple outil, mais que celui-ci s’inscrit dans une perspective temporelle indéterminée d’un projet, qu’une communauté peut se constituer et trouver, autour du logiciel créé, des motivations autres que strictement techniques à l’implication. C’est notamment ce côté projec- tuel qui entraîne le refus, a priori, de plans de développement pré-établis, ainsi qu’une division des tâches par trop rigide. Le flou spatiotemporel des tâches à réaliser maintient l’incertitude sur le déroulement de l’activité et per- met l’appropriation collective. Au-delà de la rationalité technique, ce sont des visions du monde et des imaginaires de transformation de la vie sociale que transportent avec eux les logiciels. Diversité des activités et hiérarchisation des statuts Les relations entretenues entre les membres du groupe initiateur com- portent une composante interpersonnelle importante, qui permet de mettre à l’épreuve la force de l’accord sur l’identité du logiciel développé. Historiquement, les auteurs de Spip se rencontrent fréquemment dans le milieu associatif parisien, participent aux mêmes actions militantes, parta- gent des opinions similaires sur le développement de l’Internet et la liberté d’expression qui le caractérise. De même, l’équipe initiale de développement de Claroline est confron- tée concrètement à la problématique de l’usage des TIC à des fins d’ensei- gnement, est associée à des activités de recherche sur ce sujet, partage quo- tidiennement un même espace de travail et de mêmes origines disciplinaires (science de l’éducation, philosophie, communication sociale). Si le centre décisionnel est le garant et le défenseur de cette identité autour de laquelle il s’est constitué, il ne peut pour autant assurer la prise en charge de l’ensemble des activités liées à la production d’un logiciel. Car, au- delà du cœur informatique du logiciel, de multiples activités complémentai- res sont nécessaires à sa diffusion : traduction, rapport de bogues, aide aux utilisateurs, ajout de fonctionnalités, mise en compatibilité avec des logiciels tiers, etc. L’enjeu communautaire consiste à susciter et maintenir un flux de contributions extérieures, enjeu d’autant plus incertain que celles-ci ne peu- vent être prescrites ou commandées mais reposent uniquement sur le volon- 76 ] te rminal [ É té 2006
  • 7. 2-T97 2/09/06 16:28 Page 77 tariat de contributeurs distants. Si les ressorts de l’engagement de ceux-ci peuvent s’avérer très divers [Von Hippel, 2002] et inscrits dans des schèmes de carrières variées (Demazière, Horn et Jullien, 2004), la sensibilité aux fon- dements et à l’identité du projet s’avère généralement centrale dans la pour- suite d’une implication soutenue. Mais cette condition n’est pas suffisante : pour que se développe une communauté, il est également nécessaire que, d’une part, une certaine répartition du travail soit organisée et que, d’autre part, se mettent en place des dispositifs de gestion afin de susciter l’intéres- sement des acteurs et une implication persistante. Quelques traits saillants émergent des observations de terrain, sans conduire cependant à la formation d’un modèle unique. Tout d’abord, une division du travail s’instaure systématiquement et se cristallise dans une dis- tribution stabilisée des tâches et même dans une différenciation de statuts hiérarchisés. Du point de vue des acteurs engagés, tous les participants sont membres de la communauté, ce qu’exprime le terme générique de "contribu- teur" pour désigner tout individu ayant participé à l’une quelconque de ces tâches. Mais l’éventail des tâches prises en charge exige un investissement d’inégale importance, pour certains très ponctuel (signaler un bogue), pour d’autres plus durable et intense (faire une documentation, maintenir une fonc- tionnalité). Les développeurs sont dispersés géographiquement, ont des activi- tés professionnelles diverses, mobilisent des compétences différenciées, et ne bénéficient pas d’une reconnaissance identique au sein de la communauté concernée. C’est ainsi que la mention de l’identité du contributeur à certaines tâches, comme la contribution à l’écriture du code, introduit de facto des hié- rarchies symboliques. L’usage de dispositifs de développement collectif (SVN, CVS, etc.), de gestion de listes de discussions ou de sites internes liés au pro- jet nécessitent l’octroi de droits d’accès qui sont contingentés. Émergent ainsi des différenciations entre contributeurs, qui distribuent des places, des attributions, des quasi statuts. Ici, la différenciation statutaire ne repose pas comme dans les organisations informatiques traditionnelles sur des compétences supposées que l’organisation apprécie le plus souvent à par- tir de critères indirects (diplôme, années d’expérience sur une technologie, etc.), mais elle traduit plutôt l’exhibition par la pratique de compétences mises en action et de l’engagement des participants [Tayon et Pitrou, 2005]. Ces sta- tuts ne sont d’ailleurs pas inscrits dans des échelons hiérarchiques et n’alimen- tent pas des relations de subordination, mais ils stabilisent des positions dans des organisations de travail caractérisées souvent par un refus du formalisme. Cette configuration dévoile, au minimum, une distinction entre un cen- tre décisionnel et d’animation autour duquel gravitent des contributeurs péri- phériques, les communautés les plus développées ayant une structuration o rganisationnelle plus riche et plus complexe. Chaque apport des contribu- teurs périphériques est le plus souvent limité et s’inscrit dans le cadre fixé au projet dont il ne peut modifier profondément l’identité. Cependant, le fait que chaque contribution prise isolément est d’ampleur réduite ne doit pas conduire à sous-estimer l’impact de l’ensemble de ces contributions qui É té 2006 ] te rminal [ 77
  • 8. 2-T97 2/09/06 16:28 Page 78 p ermettent d’intégrer à moindre frais de multiples améliorations cumulatives permettant "d’exploiter au mieux une intelligence distribuée" [Foray, Zimmermann, 2001]. Autre caractéristique importante, entre contributeurs périphériques, comme avec les membres du centre, les relations sont princi- palement virtuelles, médiatisées par le réseau Internet. Les rencontres inter- personnelles sont rares et quelques fois non souhaitées : l’anonymat permet en effet de limiter son apport sans induire un engagement soutenu ou un dévoilement des ressorts de l’investissement personnel. Des régulations nécessaires, une complexification croissante À mesure que se développe cette couche de contributeurs distants se pose la question du ralliement d’acteurs aux motivations, comportements et attentes divers. Cette hétérogénéité croissante s’explique par les qualités ins- titutionnelles différentes des acteurs qui s’investissent (simples individus, associations, entreprises, pouvoirs publics, etc.), les spécificités des compé- tences proposées (traduction, graphisme, documentation, codage, test), ou encore des opportunités qui apparaissent du fait de l’implication (lien de plus en plus étroit avec l’activité professionnelle, demandes de prestations de ser- vices, nécessité d’adaptation du logiciel à des besoins spécifiques). Cette diversité nécessite d’être gérée dans l’optique à la fois d’attirer des apports, mais également de les canaliser dans des orientations contri- buant au développement du projet et de sa visée normative. Mais il devient difficile pour les membres du centre de gérer directement de nombreux contri- buteurs. D’où l’apparition d’une multiplication des dispositifs techniques de gestion des contributions et des discussions, ainsi que d’un cercle supplémen- taire constitué des personnes ayant un statut intermédiaire entre les membres du centre et les simples contributeurs périphériques. L’organisation interne des projets de logiciels libres peut être schématisée de manière typique en diffé- rents cercles délimités avec un degré variable de précision selon les cas et emboîtés les uns dans les autres. Cercle stratégique Liens interpersonnels forts, partage des mêmes orientations philosophiques et/ou dispositifs juridiques ou institution- nels exogènes Cercle intermédiaire Liens interpersonnels avec certains membres du groupe des fondateurs, prise de responsabilité dans l'animation de la (sous-)communauté Cercle périphérique Peu de liens interpersonnels : l'anony- mat permet la collaboration d'individus aux motivations diverses, contributions limitées 78 ] te rminal [ É té 2006
  • 9. 2-T97 2/09/06 16:29 Page 79 La création de multiples listes de discussions spécialisées par objet témoigne de cette segmentation des communautés. Dans le cas Spip, des espaces de travail plus spécialisés se forment : division dans un premier temps de la liste principale en deux (Spip-dev et Spip-user), puis développe- ment de listes plus spécialisées ; Spip-contrib pour la proposition d’ajouts de fonctionnalités optionnelles, Spip-trad pour la gestion des dizaines de traduc- tions et le support aux non-francophones, Spip-lab pour la réflexion techni- cienne en termes de R&D, Spip-zone pour la stimulation de projets collabo- ratifs entre contributeurs, etc. Chaque liste ou site a ainsi pour effet de rassembler des individus aux préoccupations communes et ciblées et de tenter de couvrir la diversité de centres d’intérêts qui soutiennent l’engagement dans le projet. Le fonction- nement de ces sous-espaces du projet est assuré par des participants particu- lièrement impliqués auxquels est attribué le statut "d’administrateurs". Ceux- ci ont la charge de gérer des dispositifs de communication (listes de discussions, sites Internet, serveurs collaboratifs) et d’animer les participants afin de susciter les contributions, de motiver l’implication, de s’assurer de l’entraide, mais également d’orienter, évaluer, sélectionner les apports. Ces couches intermédiaires bénéficient de l’approbation, voire d’un mandat du noyau stratégique qui se manifeste par la dispense de conseils, d’informa- tions confidentielles, de contacts privilégiés. En déléguant certaines activités et responsabilités, les membres du cen- tre peuvent rétribuer par l’octroi d’un statut plus élevé les contributeurs péri- phériques les plus impliqués et donc soutenir la participation au projet. L’apparition d’un cercle intermédiaire indique également que les organisa- tions ne sont pas figées, et signale que des passages d’un cercle à l’autre et donc des changements de statut sont possibles. Les promotions viennent sanctionner des activités importantes pour le projet. Pour cela, il est néces- saire que le contributeur ait fait la preuve de ses compétences techniques (appréciées à partir de la qualité de ses contributions) et de l’importance de son engagement dans la durée. Il faut aussi que les comportements du postu- lant soient en adéquation avec la philosophie du projet et montrent un accord profond avec l’identité du logiciel développé, et donc avec le système de valeurs qui sous-tend cette identité. Les cas de Claroline et de Spip mettent en évidence le caractère non automatique de l’intégration de code produit par des contributeurs distants du cœur du logiciel. Ainsi G., développeur de Claroline relate le refus d’une proposition d’un étudiant grec : "L’entièreté de son code n’était pas exploitable tel quel, et il n’a jamais voulu accepter qu’on avait d’autres contraintes. C’étaient sur- tout des objections par rapport aux contradictions avec la philosophie de sim- plicité". Accorder les droits d’accès au développement du code source du logiciel – ce qui, à ce jour, ne s’est jamais produit – dépendrait fortement d’une implication soutenue : "Je crois qu’on est prêt à donner ces droits-là à quelqu’un à partir du moment où il y a déjà une certaine confiance qui s’est installée, que la personne est bien identifiée, donc de telle institution, que la É té 2006 ] te rminal [ 79
  • 10. 2-T97 2/09/06 16:29 Page 80 collaboration est réelle aussi. Il faut témoigner d’un peu de confiance, il faut témoigner du fait qu’ils ont déjà contribué et que ça s’est bien passé et que ça aide vraiment". Par conséquent, l’essentiel des contributions portent sur des activités de traduction ou de signalement de bugs : "Ce qu’on aime beau- coup, c’est "je ne propose pas de code, mais j’ai passé du temps à tester, tes- ter". Ça, c’est à chaque fois du temps gagné" (C. Claroline). Les demandes de support sont redirigées par les développeurs vers le forum, "comme ça, avec un peu de chance, un utilisateur averti répondra avant nous" (H. Claroline). Dans le cas de Spip, le contrôle centralisé des orientations du logiciel et des accès en écriture sur le cœur du logiciel en développement est souvent décrié. Du reste, les auteurs historiques se défendent d’un cloisonnement volontaire. L’accès aux droits de commit ne peut être envisagé, selon eux, ni comme un retour légitime récompensant une simple présence continue dans le projet, ni être restreint à un acte précis et temporaire. Une fois accordés, ces droits ont la force d’un mandat, celui de poursui- vre le développement en toute autonomie, et ne s’obtiennent qu’après avoir fait la preuve d’une grande qualité et fiabilité techniques : "Ce qu’apparem- ment personne ne comprend, c’est que l'on ne va pas ouvrir un accès comme étant une sucette ou un bon point, voilà. Ouvrir l’accès, ce sera à quelqu’un qui aura produit des patchs ou des trucs fiables, sérieux. On a du mal à véri- fier ce que chacun de nous [les auteurs] fait, si en plus il faut corriger sans cesse le code par des gens qui sont pas au niveau, c’est pas la peine, c’est un travail épuisant. Un jour on en aura marre d’intégrer des patchs d’untel parce qu'untel il enverra toujours des patchs qui sont bons à intégrer puis, on en aura marre, et on leur dira tiens voilà, fais-le toi-même" (F., Spip). Depuis le lancement du projet, deux contributeurs, au départ périphéri- ques, ont ainsi rejoint le cercle des auteurs. Pour vérifier leur proximité idéolo- gique au projet, les simples échanges virtuels communautaires sont apparus insuffisants ; ils ont été complétés par des interactions sociales directes avec des membres du centre (interaction en face à face ou échanges virtuels privés). Cette exigence explique que des contributeurs qui ont pourtant effectué des contributions majeures (tant en termes d’importance que de difficulté) peuvent rester durablement à la périphérie de la communauté. Différenciation, segmentation, et séparation Il existe également des possibilités de régression dans la hiérarchie des statuts. Le problème se pose notamment quand un membre (du centre ou du cercle intermédiaire) n’effectue plus les tâches qui lui ont été déléguées. Faute de substrat contractuel aux relations et aux positions occupées, les pos- sibilités de sanction par retrait des attributions correspondantes sont limitées et difficiles à mettre en œuvre. Plus fréquemment, la solution consiste à créer une nouvelle activité aux fonctionnalités proches de celle qui est mal réali- sée, et à laisser ainsi dépérir cette dernière. 80 ] te rminal [ É té 2006
  • 11. 2-T97 2/09/06 16:29 Page 81 C’est le cas de B., initiateur de la liste Spip-contrib qui, lassé de la fai- ble implication des personnes qu’il avait repérées et sollicitées à pratiquer l’évaluation de propositions de fonctionnalités complémentaires, abandonne ses fonctions et choisit de s’impliquer dans le développement d’un nouvel espace de travail (Spip-zone). Les modalités de fonctionnement de cette nou- velle institution doivent permettre d’améliorer le mode d’animation des contri- buteurs et de repenser le processus de sélection des autres administrateurs. D’une certaine façon, cette pratique est assez proche de celle qui est à l’œuvre quand la légitimité du centre décisionnel est remise en cause par une partie de la communauté du logiciel concerné : plutôt que de tenter de des- tituer ces membres, la partie mécontente crée une nouvelle communauté avec un nouveau centre décisionnel à partir des développements déjà effectués (un fork), ce qui est rendu possible par les licences des logiciels libres (absence d’appropriation privée du code développé). Cette probabilité est d’autant plus forte que le logiciel n’a pas encore connu un succès suffisant pour que la communauté ait dépassé une taille critique rendant peu crédible le développement d’un projet concurrent à partir du logiciel existant. Il existe ainsi dans le développement d’une com- munauté de production d’un logiciel libre une période délicate où, dans la terminologie de Hirschman (1972), le caractère peu coûteux de l’ "exit" rend indispensable une gestion fine de la "voice" (notamment pour surmon- ter les incompréhensions réciproques) permettant de maintenir la "loyalty" et d’éviter les forks. Les deux cas mobilisés ont tous deux fait l’objet de plusieurs stratégies de fork, les unes étant considérées plus "hostiles" que d’autres. Ici encore, la proximité des finalités poursuivies par des projets devenus concurrents déter- mine le caractère amical ou non de l’exercice et les déplacements ou segmen- tations des communautés entre elles. Spip fait l’objet depuis de nombreuses années de distributions concurrentes, dédiées plus spécifiquement au monde de l’éduction (Spipeva) ou intégrant des fonctionnalités supplémentaires (BioSpip). Mais en 2004, l’annonce d’une nouvelle version de Spip, dévelop- pée par un prestataire informatique pour le compte d’une administration publique jette le trouble dans la communauté. Cette nouvelle version du logi- ciel (dénommée Spip-Agora) est présentée par le prestataire comme étant de meilleure qualité, comprenant des fonctionnalités supplémentaires, pouvant s’adapter à des environnements technologiques plus diversifiés. L’intention déclarée du commanditaire est de faire bénéficier ces déve- loppements au projet initial afin de l’améliorer, de lui permettre d’élargir son marché potentiel aux administrations, et plus généralement, d’accroître sa crédibilité professionnelle. Mais le fait de n’avoir pas joué le jeu de la parti- cipation communautaire, de ne pas avoir distillé petit à petit les transforma- tions réalisées, de ne pas avoir confronté les idées à la communauté et aux auteurs historiques en particulier, a provoqué un rejet de la part des auteurs. Ceux-ci craignaient une récupération à des fins commerciales ou politi- ques du travail réalisé bénévolement par des dizaines de contributeurs, souvent É té 2006 ] te rminal [ 81
  • 12. 2-T97 2/09/06 16:29 Page 82 à partir de conditions de travail peu aisées, qui pourrait corrompre le carac- tère désintéressé de la communauté et provoquer une démotivation générale. Entre les deux projets qui coexistent désormais, les différences et les diver- gences s’approfondissent progressivement. Dans le cas de Claroline, la situa- tion se présente différemment étant donné que c’est l’auteur historique du pro- jet qui est dépossédé des rênes du développement par l’institution universitaire qui l’emploie. Ayant décroché un substantiel financement public pour parfaire le développement, il se voit, pour des raisons statutaires et politiques, refuser la direction du projet. Il décide alors d’organiser son propre fork, en l’associant à la création d’une société de services. Ce départ brutal se concrétise sous la forme d’un e-mail envoyé à l’ensemble de la communauté, précisant notamment : "Quelqu’un a déposé la marque Claroline sans me demander mon avis et pro- pose de me la revendre au prix fort. Suivant la philosophie de l’Open Source, j’ai décidé de ne pas accepter cela et de changer le nom du projet pour Dokeos. Veuillez noter qu’à partir de dorénavant, notre projet de logiciel de e-Learning Open Source ne s’appelle plus Claroline, mais Dokeos". Cette stratégie de communication lui permettra d’attirer avec lui une part impor- tante de la communauté liée à Claroline. Les communautés distantes Ces deux cas de fork dits "hostiles" indiquent ainsi les facilités poten- tielles de transfert de contributeurs "périphériques" lors de situations de forks au travers de stratégies de communication. N’entretenant pas de relation spé- cifique entre eux en dehors des espaces publics de discussion, ni de relation interpersonnelles avec le cercle stratégique, ils ne peuvent décoder facile- ment les stratégies d’acteurs et les changements de cap dans l’identité des projets. Tout au plus peuvent-ils tenter d’évaluer les enjeux fonctionnels ou techniques des schismes, sans nécessairement percevoir par la transformation de la raison sociale du projet. Cette situation sera vécue différemment par les membres des cercles intermédiaires et stratégique qui, se réunissant ou entre- tenant des interactions privées, définiront des stratégies coordonnées de résistance et d’offensive afin d’éviter l’hémorragie communautaire. Le fork, dans ce cas, peut exacerber des conflits interpersonnels et pro- voquer des inimitiés sociales qui poussent, par ailleurs, à l’accentuation des traits spécifiques de l’identité du projet. Les collectifs qui produisent des logiciels libres, et qui s’auto-désignent comme des communautés, présentent des caractéristiques peu répandues dans le monde du travail : les contribu- teurs sont dispersés et sont affranchis de toute contrainte issue d’une autorité extérieure au collectif constitué par la mise en réseau [Lerner et Tirole, 2002]. Comment une production est-elle possible dans ces conditions ? On sait que distance relationnelle et identification à un groupe de projet ne sont pas contradictoires, et l’analyse des ressorts de la participation média- tisée par le réseau Internet a permis de renseigner ce paradoxe apparent, que 82 ] te rminal [ É té 2006
  • 13. 2-T97 2/09/06 16:29 Page 83 nous avons nommé ailleurs par l’expression "communautés distantes" [Demazière, Horn, Jullien, 2003]. Un autre aspect a été pris en compte ici, qui concerne la distribution des activités, l’organisation de la production et la structuration des relations de coopération. Car ces communautés distantes ont pour finalité le développement de logiciels informatiques opératoires, utilisa- bles, performants. Sous réserve d’une généralisation des résultats, nous avons alors pu observer que ces activités à participation libre s’appuient sur une répartition distribuée des tâches et sur une hiérarchie informelle. Ces modes de structuration apparaissent comme des conditions pour le lance- ment, la poursuite et le développement d’activités orientées vers la fabrica- tion d’un produit. Au-delà, l’analyse des deux projets Claroline et Spip montre que pour être informelle, l’organisation n’en est pas moins visible à travers divers dis- positifs : signature des contributions au code, identification des animateurs des listes de diffusion, marquage des statuts. Ainsi les relations entre les membres de la communauté s’insèrent dans des chemins et réseaux verticaux tout autant qu’horizontaux. Ces groupes se caractérisent par un équilibre entre la cohésion et l’adhé- sion d’une part, la différenciation et la hiérarchie de l’autre ; entre d’un côté une identification, qui est modulée selon la place occupée dans le groupe et qui est fortement soutenue par l’identité discriminante du produit, et de l’au- tre une division, qui est assouplie par les mobilités internes, et qui est solide- ment légitimée par la visibilité des contributions individuelles. Ces collectifs sont ainsi constitués d’emboîtements de tâches, de statuts et de cercles, et sous cet aspect ils apparaissent comme des communautés non seulement dis- tantes mais aussi, second paradoxe, clivées.  É té 2006 ] te rminal [ 83
  • 14. 2-T97 2/09/06 16:29 Page 84 RÉFÉRENCES D. DEMAZIÈRE, F. HORN, N. JULLIEN, "Le travail des développeurs de logiciels libres. La mobilisa- tion dans des communautés distantes", Communication au colloque du CLERSE, La représen- tation économique de l’acteur au travail, Villeneuve d’Ascq, 20-21 novembre 2003, publiée dans CLES (Cahiers Lillois d’Economie et de Sociologie) n° 46, 2003. D. FORAY, J.-B. ZIMMERMANN, "L’économie du logiciel libre : organisation coopérative et incita- tion à l’innovation", Revue Economique 52, pp. 77-93, 2001. M. GENSOLLEN, "Biens informationnels et communautés médiatées", Revue d’Economie Politique, mars 2004. R.L. GLASS, "A socio-political look at open source", Communications of the ACM, 46, pp. 21-23, 2003. ALBERT O. HIRSCHMAN, Face au déclin des entreprises et des institutions, Éditions Ouvrières (Collection Economie humaine), 141 p., 1972, traduction de Exit, Voice and loyalty : responses to decline in firms, organizations and states, Harvard University Press, 1970. HOLTGREWE U., WERLE R., "De-Commodifying Software ? Open Source Software Between Business Strategy and Social Movement", Science Studies, 15, pp. 43-65, 2001. HORN F., L’économie des logiciels, La Découverte, Paris, 2004. LEBRUN M., "Théories et méthodes pédagogiques pour enseigner et apprendre", De Boeck Université, Bruxelles, 2002. LERNER J., TIROLE J., "Some simple economics of open source", Journal of Industrial Economics, 52, pp. 197-234, 2002. RAYMOND E.S., "La cathédrale et le bazar, trad. de Blondeel S.", 1998, http://www.lifl.fr/~blon- deel/traduc/Cathedral-bazaar/Main_file.html SALAIS R., STORPER M., Les mondes de production : enquête sur l’identité économique de la France, éditions de l’EHESS, Paris, 1993. TAYON J. ET PITROU A., "Libre Academy : statut ou compétence ?", Libroscope.org, 13 juin 2005. VON HIPPEL, "Open Souce Software as horizontal innovation networks – by and for users", MIT Sloan School of Management W.P. N° 4366-02, 2002. 84 ] te rminal [ É té 2006