Abstracts
Résumé
Activité collective fondée sur l’engagement volontaire et bénévole, la production de logiciels libres ne résulte pas de l’ajustement spontané de participations dispersées. Elle offre un terrain fertile pour l’analyse des relations distantes médiatisées par le réseau Internet. En effet, cette activité est soumise à une double contrainte : attirer des participants nombreux, sans sélection préalable, et canaliser les contributions afin de mettre au point un produit consistant et cohérent. Partant de l’ethnographie approfondie d’un collectif de développement de logiciel libre, cet article analyse la manière dont les hétérogénéités individuelles sont agencées, c’est-à-dire mobilisées et contrôlées. Il identifie des processus de socialisation qui articulent une tolérance maximale à l’égard des engagements subjectifs individuels et une reconnaissance différentielle des contributions à l’oeuvre commune et de leurs auteurs. Cette socialisation est spécifique, dans le sens où elle régule moins les identités personnelles des participants que l’identité collective du projet, incluant le produit et le groupe de production.
Abstract
A collective activity based on voluntary, benevolent commitment, the production of free software does not result from the spontaneous adjustment of dispersed participation. It offers fertile terrain for the analysis of non-local relationships mediated by the internet. Indeed, this activity is subject to a double constraint: that of attracting numerous participants without any previous selection as well as that of channeling contributions to put together a consistent and coherent product. Based on the detailed ethnography of a group involved in the development of free software, this article analyses how individual differences are organized, that is, mobilised and controlled. It identifies processes of socialisation that deploy a maximum tolerance towards individual subjective commitment and a differential recognition of contribution to the common work and of the authors. This is a specific kind of socialisation in that it regulates less the personal identity of participants than the collective identity of hte project, including both the product and the production group.
Resumen
Actividad colectiva basada en el compromiso voluntario y benévolo, la producción de programas informáticos libres no resulta del ajuste espontáneo de participaciones dispersas. Ella ofrece un terreno fértil para el análisis de las relaciones distantes mediatizadas por la red Internet. En efecto, esta actividad está sometida a una doble dificultad : atraer numerosos participantes, sin selección previa, y canalizar las contribuciones con el fin de poner a punto un producto consistente y coherente. A partir de la etnografía profunda de un colectivo de desarrollo de programa informático libre, este artículo analiza la manera en que las heterogeneidades individuales se arreglan, es decir, se movilizan y controlan. El programa define procesos de socialización que articulan una tolerancia máxima respecto a los compromisos subjetivos individuales y un reconocimiento diferencial de las contribuciones a la obra común y de sus autores. Esta socialización es específica, en el sentido que ella controla menos las identidades personales de los participantes que la identidad colectiva del proyecto, incluyendo el producto y al grupo de producción.
Article body
Le développement de logiciels libres est une activité éminemment collective. Elle est soutenue, en principe, par la coopération de participants volontaires et bénévoles qui contribuent à l’élaboration d’un logiciel : écriture, mise à jour, diffusion, documentation, traduction, etc. Le principe au fondement des logiciels libres — c’est-à-dire la mise à disposition du code source (texte du programme écrit dans un langage de programmation compréhensible par l’être humain), avec autorisation de le modifier et de le distribuer librement — se traduit par la collaboration de développeurs participant ainsi à la conception d’une oeuvre commune. Habituellement, ceux-ci coopèrent à distance : non seulement ils nouent des relations à travers le réseau Internet, mais ils sont dispersés géographiquement et, surtout, ne partagent pas d’inscription spatiale ou organisationnelle commune (Von Hippel et Von Krogh, 2003 : 211 ; Kollock, 1998 : 194-195). Ils forment ainsi des collectivités humaines aux traits spécifiques : les relations entre les individus et le groupe ne sont réglées ni par des identifications héritées comme dans les communautés traditionnelles, ni par des appartenances de proximité comme dans les collectifs localisés, ni par des contrats juridiques comme dans les organisations de travail. En ce sens, de tels groupes offrent un terrain fertile pour interroger les formes de coordination permettant de fabriquer un collectif d’action (Weber, 1971 [1921-1922] : 78-79), les modalités de socialisation permettant de produire des identités sociales (Dubar, 1991 : 112-114), les équilibres « Nous-Je » permettant de faire société (Elias, 1987 : 240-241).
Notre hypothèse est que les collectifs de développement de logiciels libres se caractérisent par des processus et des modes de socialisation singuliers. Certes, ces groupes ne sont pas soudés par de fréquents contacts de type face-à-face, à l’image des sociétés de petite taille ou des équipes de travail partageant les mêmes espaces, mais ils se caractérisent pourtant par des échanges proprement sociaux, et socialisateurs, dans la mesure où la relation n’est pas réductible au mode de communication qui la porte (Proulx et Latzko-Toth, 2001 : 110-114). On peut aussi avancer que les engagements individuels et volontaires doivent faire l’objet d’un encadrement spécifique, permettant de contrecarrer les risques de défection qui condamnent nombre de projets après la période initiale d’effervescence[1] (Healy et Schussman, 2003 : 18-19). De plus, les règles d’appartenance sont peu codifiées par le poids du « modèle du bazar » (Raymond, 1998 : 10-11) dans les référents identitaires et idéologiques qui soudent le monde de la production de logiciels libres. Autrement dit, la socialisation n’est pas absente ou empêchée par le caractère « virtuel » de ces groupes ; bien au contraire, elle est nécessaire à leur maintien dans le temps, tout en prenant des formes particulières qui doivent être explorées dans la durée. Pour le montrer, nous nous appuierons sur une étude de cas consacrée au collectif qui développe le logiciel Spip, un outil de publication dynamique sur Internet. Mais avant de présenter les résultats de l’enquête, il faut spécifier quelques caractéristiques saillantes des collectifs de développeurs, et ce faisant, préciser comment la socialisation peut y être observée.
1. De la communauté à la socialisation
Selon le vocabulaire indigène, chaque logiciel fédère une « communauté » travaillant à son développement, qui s’autodésigne par le nom du logiciel correspondant (communautés Linux, OpenOffice, Debian, Zope, etc.). Ce terme de « communauté » s’est largement imposé dans l’analyse du fonctionnement des collectifs de production de logiciels libres. Pourtant, il « fait partie de ces mots “fourre-tout” qui permettent d’évacuer (provisoirement) certains questionnements » (Proulx et Latzko-Toth, 2001 : 110). Sans valeur descriptive, ce terme incite à explorer les relations que nouent les participants et les modes d’appartenance à ces groupes. La littérature fournit quelques éléments de réponse, mais cette interrogation nécessite de procéder à des investigations empiriques ajustées.
1.1. Une socialisation nécessaire
L’utilisation du terme de « communauté », largement répandue pour désigner ces groupes, signifie a minima qu’ils se différencient des formes plus classiques d’organisation productive, conceptualisées en termes de marché ou de hiérarchie (Demil et Lecocq, 2006 : 1451-1454 ; Adler, 2001 : 216 ; Powell, 1990 : 300-301). Mais renseigne-t-il sur les fonctionnements, sur les mécanismes de socialisation ou sur les processus d’intégration qui les caractérisent ? Autrement dit, ceux-ci s’apparentent-ils à la Vergemeinschaftung conceptualisée par Weber (1921-1922 : 41-42), pour lequel la communauté désigne un idéal-type de société, une manière d’être ensemble ? C’est une force socialisatrice qui se caractérise par un ensemble de rapports nécessaires et donnés entre des individus dépendant les uns des autres, dont les relations primitives (filiation, alliance, consanguinité) sont l’archétype. Par rapport à ce modèle, les collectifs de développement de logiciels libres présentent des traits sensiblement différents, sinon opposés : ce sont des groupes contingents, réunissant des individus aux ancrages sociaux variés, coalisant des intérêts ou des préférences à agir dans un but partagé (Himanen et al., 2001). Ils constituent ce que l’on appellerait, dans le vocabulaire contemporain, des groupes de projet (Boltanski et Chiapello, 1999 : 157), dans lesquels chaque participant se trouve dans un état de tension à l’égard des autres, et qui ne reposent pas sur un principe d’appartenance préalable, sinon celui résultant de l’action collective elle-même. En ce sens, ils se rapprocheraient plutôt de la forme sociétaire (Vergesellschaftung).
Mais le problème est moins de déterminer si ces groupes sont de « vraies » communautés ou des « simulacres de communautés » (Fernback et Thompson, 1995 : 4-7) que de découvrir quels modes de fonctionnement assurent leur cohésion et permettent leur survie (Harrison, 1960 : 232 ; Rothschild et Russell, 1986 : 321). Mieux vaut donc considérer que le terme « communauté » a une valeur métaphorique, voire normative : il affirme que ces collectifs sont soudés et solides — ou du moins doivent l’être —, mais il ne nous informe pas sur les processus permettant que le groupe fonctionne, tienne, perdure. Souligner l’absence de dispositif d’organisation structuré (cahier des charges, injonctions temporelles, hiérarchie formelle) et la prégnance de principes d’action communément partagés (méritocratie basée sur la mise en acte des seules compétences, leadership participatif, liberté d’engagement) ne saurait suffire à caractériser ces processus, empiriquement ou théoriquement (Moon et Sproull, 2002 : 390-392 ; Hertel et al., 2003 : 1174-1175).
Si le fonctionnement de ces collectifs ne résulte pas d’appartenances données et héritées, il ne provient pas plus de l’ajustement automatique et pérenne d’intérêts à participer. Il repose sur des mécanismes de coordination permettant d’intégrer les intérêts individuels et d’ajuster les participations au cours du temps. Plus encore, il repose sur des processus de socialisation permettant de consolider les affiliations et de maintenir une cohésion nécessaire à la poursuite de l’activité. D’ailleurs, dans le cas des groupes de développement de logiciels libres, la nécessité d’une socialisation des participants est beaucoup plus forte que dans nombre d’autres groupes où la communication face à face est remplacée par une communication médiatisée par le réseau Internet. Ainsi, dans le cas de collectifs orientés vers l’échange non marchand de biens de consommation (fichiers audio ou vidéo par exemple), les défections et les stratégies de cavalier seul compromettent peu l’activité si celle-ci repose sur un groupe assez large (Beuscart, 2002 : 470-471). Dans le cas de collectifs pratiquant l’échange de connaissances spécialisées ou d’expériences pratiques, la maîtrise d’un même métier et l’identification à une profession constituent une base solide à la participation et à la réciprocité (Wenger, 1998). Dans le cas de groupes produisant un bien collectif subdivisé en une multitude de composants indépendants (Wikipédia, par exemple), le caractère ponctuel et partiel des contributions est parfaitement compatible avec la réussite du projet d’ensemble (Erpicum, 2005 : 16). Et quand les collectifs sont orientés vers la production de savoirs nouveaux et organisés en un produit cohérent dans lequel les apports individuels sont intégrés, interdépendants et fondus, comme de façon typique dans un logiciel libre, les interdépendances entre participants sont particulièrement déterminantes pour la réalisation des objectifs (Gensollen, 2004 : 30). Cette caractéristique a des implications directes sur l’organisation du collectif et sur les relations entre participants (Von Krogh et al., 2003 : 1234 ; O’Mahony, 2003 : 1179-1180). Les exigences de socialisation sont alors plus grandes.
Les relations entre participants sont modelées par deux séries de contraintes, fortes et contradictoires. La première résulte des finalités du collectif et des caractéristiques du bien produit : le logiciel est un texte numérique actif, un texte qui agit dans la mesure où il se compose d’un ensemble d’instructions exécutées automatiquement par une machine, ce qui nécessite une cohérence extrêmement forte des différentes parties du texte (Horn, 2004 : 8). Il en résulte que les activités individuelles doivent être étroitement interdépendantes, que les relations doivent être finalisées autour d’objectifs de complémentarité et que les contributions doivent être ajustées les unes aux autres. Mais ces exigences de cohérence sont contrecarrées par un second ensemble de contraintes, qui découle du caractère volontaire et bénévole des participations : le risque d’instabilité des engagements est élevé, ce qui modifie continûment la composition du collectif, menace sa pérennité et complique la nécessaire coordination de ses membres. Pour faire face à ce risque, le groupe doit à la fois maintenir l’engagement de ses contributeurs — notamment les plus actifs — et en accueillir de nouveaux, dont l’arrivée accroît les capacités de production, même si parallèlement elle augmente l’hétérogénéité interne. À ce cumul d’exigences, de mise au point d’un produit et de cohérence interne d’une part, de mobilisation des participants et d’ouverture du groupe d’autre part, répondent des processus et des modalités spécifiques de socialisation.
1.2. Une méthode ethnographique
L’interrogation des mécanismes de socialisation caractéristiques des collectifs de développement de logiciels libres a des implications méthodologiques directes. Elle suppose en effet de mobiliser des méthodes ethnographiques, permettant de saisir tant les interactions entre participants que les formes proprement collectives de leurs activités, ou encore les mécanismes codifiés ou informels de régulation de leurs conduites. La méthode biographique, orientée vers la collecte de récits de pratiques, ne saurait suffire, même si elle renseigne sur les significations subjectives données à ces pratiques, mesure l’éventail de leur diversité, et partant, décrit la socialisation à travers ses effets (Demazière et Dubar, 2004 : 326-327). De plus, la socialisation est aussi un processus temporel qui, à ce titre, appelle des enquêtes empiriques prolongées, permettant de repérer la variété des canaux et instruments qui la supportent, de comprendre la structuration du groupe dans lequel elle opère, de caractériser les ajustements qu’elle induit.
La méthode ethnographique prolongée, basée sur la répétition des observations, sur l’insertion progressive au sein du groupe et sur l’interrogation de nombreux membres, est rarement utilisée pour l’analyse des collectifs de développement de logiciels libres (Wellman et Gulia, 1999 : 170). Plus généralement, les enquêtes empiriques approfondies sont assez rares et portent souvent sur les motivations des développeurs, considérés comme des individus indépendants les uns des autres. Ainsi, ces motivations s’enracineraient dans des orientations idéologiques et normatives d’informaticiens férus de technique et engagés dans un combat pour la liberté de l’information et de la connaissance (des hackers) (Glass, 2003 : 21-23 ; Holtgrewe et Werle, 2001 : 57), relèveraient d’un utilitarisme direct (l’usage du logiciel pour ses besoins personnels justifie le souhait de voir ses propres modifications intégrées, la confrontation à la communauté permet d’apprendre et d’accroître ses compétences), d’un utilitarisme indirect (l’exhibition des compétences agit comme un signalement vis-à-vis du marché du travail « réel »), ou encore d’une diversité de facteurs sociaux (le partage, l’amusement) (Ghosh et al., 2002 : 43-45 ; Lerner et Tirole, 2002 : 213 ; Elliot et Scacchi, 2004 : 153-154 ; Lakhani et Wolf, 2005 : 4-6).
Dans de tels travaux, le collectif apparaît, de manière indirecte, comme le résultat agrégé de motivations, d’intérêts ou de préférences d’ordre individuel. Dès lors, la production de la cohésion des collectifs reste dans l’ombre. Quant aux analyses, plus rares, portant sur des collectifs de développement — et non sur des développeurs pris isolément —, elles ne pénètrent guère au sein des groupes pour disséquer leur fonctionnement. Car en mettant l’accent sur des mécanismes de régulation à l’entrée, comme la sélection en amont des contributeurs, qui ne sont pas systématiquement admis ou intégrés, elles considèrent que la cohésion du groupe et la cohérence du logiciel sont assurées par ces barrières (Auray, 2004 : 89 ; Conein, 2004 : 143 ; Weber, 2005). Pourtant, ces mécanismes d’ouverture et de fermeture n’existent que pour les projets d’envergure — rares — dont la grande réputation séduit pléthore de contributeurs attirés par la reconnaissance que procure le fait d’y être admis (Demazière et al., 2005 : 180). En complément de ces approches, nous proposons de centrer l’analyse sur les processus de production de ces collectifs. Quelles relations se nouent entre participants dispersés ? Comment s’agencent des hétérogénéités individuelles pour former un groupe, efficace dans son activité productive ? Quels sont les vecteurs de socialisation des membres ? Comment les participants sont-ils reliés et comment échangent-ils ? Quels ressorts et valeurs soutiennent leurs engagements ? Comment la cohésion est-elle produite ?
Cette perspective s’appuie sur la réalisation d’une enquête ethnographique approfondie, conduite pendant plus de trois ans au sein de la « communauté Spip[2] », qui développe un logiciel de publication dynamique sur Internet. Ce terrain a été choisi parce qu’il correspond à un projet inscrit dans une dynamique d’expansion et de réussite, ayant dépassé la phase du démarrage et de la confidentialité pour atteindre une taille significative (plusieurs dizaines de développeurs habituels, plusieurs centaines de contributeurs occasionnels, plusieurs milliers d’utilisateurs). Il se situe entre les rares projets de large envergure et de grande réputation qui s’appuient sur de puissants filtres à l’entrée et la multitude de petits projets bloqués au stade de la recherche d’utilisateurs ou plus encore de contributeurs. Le choix de ce terrain d’enquête a été effectué dans une perspective d’échantillonnage théorique (Corbin et Strauss, 1990 : 192) permettant de considérer le projet Spip comme un cas emblématique de l’idéal promu par les partisans du logiciel libre : il s’enracine dans des orientations idéologiques contestataires ou anti-capitalistes partagées par ses initiateurs, et bénéficie d’une forte image dans les milieux associatifs alternatifs ; il fonctionne grâce à l’apport d’individus dispersés et non reliés par quelque arrangement institutionnel, tandis que nombre de projets sont pilotés de manière plus ou moins ouverte par des institutions ou des entreprises ; il est délibérément orienté vers les utilisateurs non informaticiens et privilégie pour cela une bonne accessibilité d’usage, servie par des interfaces commodes et des fonctionnalités simples.
Le fondement heuristique de l’enquête ethnographique réside dans le caractère durable et prolongé de la présence de l’enquêteur au sein du groupe social étudié. Ici, cette collectivité n’est ni un village, ni un club, ni une entreprise, ensembles qui pourraient aisément être définis en termes spatiaux et dont les limites seraient assez claires (Clifford, 1992). La « communauté Spip » constitue un réseau qui n’est pas aisément localisable même s’il s’incarne dans des espaces électroniques : ses frontières sont imprécises et mouvantes car les appartenances y sont graduées ; sa composition est instable car soumise au flux des entrées et sorties ; il est distribué dans une multitude de vecteurs et d’instruments de communication (Wellman et al., 1996 : 224-228). Compte tenu de ces traits, l’ethnographie exige un travail patient et prolongé de découverte de ce collectif en permanente configuration, d’insertion progressive du chercheur, d’investissement de multiples lieux d’échange et de communication, d’accumulation de contacts et d’interactions avec les participants, mais aussi de restitution de conclusions partielles, toutes pratiques d’enquête destinées à se faire admettre comme observateur et à collecter les informations les plus variées possible, de manière à croiser et à recouper les matériaux (Yin, 1994 : 58-62). Suivant les principes de l’ethnographie virtuelle (voir Hine, 2000 ; Rutter et Smith, 2005 : 84-88), nous avons multiplié les angles d’observation : analyse des messages électroniques échangés sur des listes d’envoi et sur des forums de discussion, en privilégiant des moments et conjonctures où des questions vives étaient en débat ; observation directe de multiples réunions rassemblant un nombre variable de contributeurs (apéritifs et petits-déjeuners d’échanges, ateliers de travail, journées de rencontre autour du logiciel) ; entretiens approfondis portant sur les contributions individuelles au logiciel, sur le fonctionnement collectif et sur les parcours biographiques, avec vingt-sept participants ayant des activités et des engagements différenciés (initiateurs du projet, codeurs habituels, contributeurs épisodiques, traducteurs et débogueurs…).
Les résultats sont présentés en trois étapes. Nous montrerons d’abord que la socialisation est effective : elle passe par une multitude de canaux d’échanges, pour partie à distance et pour partie en coprésence, qui permettent d’élargir l’interconnaissance, de structurer l’activité collective, d’initier les nouveaux entrants et d’obtenir la cohésion du groupe. Nous soulignerons ensuite que cette socialisation est limitée dans la mesure où elle modèle peu les significations que les contributeurs les plus actifs donnent à leur participation : les engagements sont soutenus par des objectifs hétérogènes, les orientations en valeurs sont diversifiées et contradictoires, le sens des expériences est stabilisé et enraciné dans des parcours contrastés, l’investissement dans le groupe ne s’accompagne guère de conversion. Puis nous argumenterons combien cette socialisation est discriminante et s’appuie sur deux types de mécanismes diffus d’évaluation des participations : le premier affirme de manière implicite les normes de référence du groupe à travers la distinction et la promotion de certains contributeurs ; le second affiche de manière explicite un ordre de légitimité à travers la stigmatisation de certaines conduites dénoncées comme des transgressions. Ces deux mécanismes dessinent un espace symbolique pour l’expression des conduites acceptables. À l’issue de l’analyse, nous reviendrons sur les ressorts et sur les caractéristiques de la cohésion dans la « communauté » étudiée.
2. Une socialisation effective : des échanges et interactions multiples
Les participants aux projets de logiciels libres sont en principe dispersés géographiquement, d’autant plus que la taille des collectifs est importante, le recours aux réseaux informatiques permettant de coopérer en s’affranchissant des contraintes de mobilité. Le projet Spip correspond à ce cas de figure : initié en France par trois amis résidant en région parisienne et formant l’ossature du noyau central actuel, le cercle des contributeurs habituels s’est élargi, s’étendant désormais sur plusieurs continents, notamment pour ce qui concerne l’activité de traduction[3]. Les échanges à distance ont des conséquences sur les identifications et les interactions entre participants, mais ils n’entraînent pas forcément un appauvrissement relationnel. De plus, comme c’est souvent le cas, ces relations se nourrissent de rencontres directes qui soutiennent, selon d’autres mécanismes, les liens de chacun au groupe et la cohésion de celui-ci. La « communauté Spip », à l’image de nombreux autres groupes comparables (Castells, 2001 : 157), est ainsi consolidée par divers mécanismes de coordination et d’échange destinés à étayer les engagements des contributeurs.
2.1. Pseudonymes, identification, sociabilité
Les échanges médiatisés par Internet, comparativement aux interactions directes, favorisent le maintien d’une certaine distance entre les uns et les autres. Ils fournissent un support relationnel moins solide. Les retraits ou défections sont plus aisés et moins coûteux quand les participants ne se connaissent pas, ni de vue ni de nom. En ce sens, les participants aux projets de logiciels libres sont moins tenus au collectif. Et même si les motifs d’engagement soutiennent les appartenances, nous le verrons, il est nécessaire de produire de l’identification collective malgré la distance. À cet égard, l’usage des pseudonymes apparaît comme une ressource pour la gestion des identités et ne fait pas obstacle à l’essor d’une sociabilité entre participants.
Chaque contributeur est connu par un pseudonyme, librement choisi et pauvre en informations personnelles : il évoque parfois un diminutif (Fil, Nat33), sa signification est souvent indéchiffrable (Izo, RealET, Allergie, Toggg). Les pseudonymes favorisent peu les échanges dans la mesure où ils gomment les éléments qui dans un face-à-face constitueraient des repères d’identification (tel l’âge, le sexe ou l’apparence physique) (Velkovska, 2002 : 206). L’identification qui en résulte élimine pratiquement tout élément personnel, au point que c’est ce qui est fait et produit par chacun qui est le support de son identité pour les autres : selon nos observations, tel participant est « celui qui a fait le compilateur », tel autre est « un codeur hyper balèze », tel autre encore est « à l’origine du mag », etc. Pourtant, comme chacun conserve son pseudonyme dans la durée, celui-ci devient le support d’une identité nominale et, au fil des échanges, les informations s’accumulent sur les participants, ceci renforçant l’interconnaissance. Certains épisodes l’indiquent clairement : ainsi, le décès d’un contributeur habituel, bien que nombre de participants ne l’aient jamais rencontré physiquement, a provoqué des échanges nourris constituant un moment de mise en commun des éléments d’identification accumulés par les uns et les autres, échanges portant non seulement sur son rôle dans le groupe et sa contribution au projet, mais aussi sur sa situation sociale et personnelle.
Par ailleurs, les relations distantes entre contributeurs s’inscrivent dans des dispositifs techniques (sites, listes de diffusion, forums), qui délimitent des espaces de collaboration diversifiés en correspondance avec la variété des activités : écriture du code, support aux utilisateurs, réflexion sur les développements futurs, traduction, documentation, gestion de contributions périphériques (Demazière et al., 2007 : 113). Cette différenciation de sous-espaces de travail est un indice de la priorité donnée aux objectifs de production : il s’agit de canaliser l’hétérogénéité des participants, qui croît rapidement avec leur nombre, tout en favorisant les échanges fonctionnels. Car une trop grande disparité dans les attentes et les compétences a des effets démobilisateurs : les préoccupations d’un novice en informatique et d’un expert des langages de programmation ont peu en commun, et leur participation à une même liste de discussion risque de provoquer des incompréhensions réciproques, sources d’insatisfactions, voire de défections. La spécialisation permet de rassembler des pairs, ou quasi-pairs, dans des espaces bien différenciés. À l’intérieur de ces cadres permettant une intercompréhension minimale, suffisante pour coopérer, chaque participant peut gérer à sa guise ses engagements et ses interactions avec autrui. Certains dévoilent de multiples pans de leur identité, échangent sur des sujets variés, privilégient une sociabilité de type amical (Pahl, 2002 : 413), tandis que d’autres restent focalisés sur la résolution de problèmes techniques, maintiennent leur identité à distance ou même stigmatisent ceux qui, à l’inverse, discutent sans fin, multiplient les échanges improductifs ou lancent des polémiques sans fondement, autant de pratiques dénoncées comme des « trolls ».
Les relations distantes entre pseudonymes ne se réduisent donc pas à des relations dépersonnalisées entre anonymes : elles autorisent des identifications et des sociabilités variées. Le support technique qui s’y prête le mieux est l’Internet Relay Chat (IRC) — un dispositif technique d’interaction en temps réel —, car les échanges y sont synchrones, prennent la forme de conversations et permettent la participation (passive ou active) de toutes les personnes connectées. La finalité de ces IRC renvoie clairement à l’objectif plus global de production logicielle, comme l’indique la différenciation de ces fils de discussion entre développeurs (plus ou moins chevronnés) et utilisateurs (plus ou moins novices). Mais les échanges portent sur de nombreux sujets, relatifs au développement du logiciel (pertinence de travailler à telle ou telle fonctionnalité), au monde des logiciels en général (nouvelle version de tel ou tel produit), à la vie privée (confidences sur la vie de famille) ou encore, basculent dans le registre humoristique qui crée une autre forme de complicité (blagues, vannes). Ces échanges renforcent les liens entre participants, car ils y introduisent des repères et des signes qui organisent et orientent les interactions ordinaires (opinions, idées, informations personnelles, plaisanteries, etc.). Ils sont souvent abscons pour les nouveaux arrivants, lesquels manifestent leur désorientation, suscitant alors des échanges s’apparentant à une initiation à l’histoire collective, véritable socialisation rudimentaire et accélérée. Les relations à distance entre les participants sont donc marquées par une sociabilité modulée et élargie, qui exprime et soutient les appartenances collectives.
2.2. Interconnaissance, cohésion, adhésion
Si la spécialisation des espaces de travail, virtuels, répond en premier lieu à des objectifs de pilotage du projet et de gestion de la production, elle comporte un risque d’érosion de la cohésion d’ensemble, chaque participant pouvant s’identifier au segment dans lequel il investit son activité plutôt qu’au projet dans son ensemble, à la « communauté Spip ». Aussi des initiatives ont été lancées, qui contribuent de manière directe à faciliter l’interconnaissance des participants, à renforcer la cohésion du groupe et à consolider les adhésions en valeurs. Elles ont pour double particularité d’être transversales aux espaces de travail spécialisés et d’être basées sur la coprésence.
Ces interactions dans leur forme la plus souple correspondent à des réunions locales et récurrentes, rassemblant des participants relativement proches géographiquement. Leur finalité première est le développement de la sociabilité, comme l’indique leur nom : « apéro-Spip ». Ces rencontres, dont l’ordre du jour reste informel et flou, prennent la forme d’échanges non finalisés. L’éventail des sujets abordés est large : événements relatifs au logiciel libre en général, questions en débat à l’intérieur de la « communauté Spip », sujets d’actualité politique, épisodes de la vie personnelle des présents. Nos observations indiquent que ces rencontres, sauf à des moments spécifiques où le projet Spip éprouvait un problème précis ou était à un tournant de son évolution, n’ont d’autre objectif que les progrès de l’interconnaissance : « En fait [lors de ces rencontres], on ne discute pas tellement technique, parce que la discussion technique, elle se fait par les listes ou sur IRC. Souvent on parle de tout sauf de Spip. C’est ce qui nous relie au départ, mais après on sait discuter d’autres choses aussi, hein » (entretien avec un contributeur habituel, réalisé lors d’un apéro-Spip, mars 2005).
D’autres rencontres sont destinées à réunir le plus largement possible les contributeurs de Spip. Baptisées « Spip-partys », faisant l’objet d’une préparation collective minutieuse, elles donnent lieu à diverses activités : écriture collective de code informatique ou encore discussion sur l’évolution future du logiciel. Elles sont tournées, explicitement, vers la célébration du groupe, et visent à renforcer sa cohésion de multiples manières. Ainsi, elles sont des moments de mise en scène du collectif, de démonstration de la vigueur du groupe et d’affirmation de la force du logiciel, oeuvre commune. Elles sont aussi des occasions pour les initiateurs du projet (le noyau) de mettre en discussion des perspectives de développement, de mobiliser les membres autour des options privilégiées et d’argumenter les orientations favorisées, autant de composantes d’un principe de participation ou d’expression sur le projet susceptibles de renforcer l’adhésion des participants.
En ce sens, la rencontre directe relaie les contacts à distance dans la fabrication d’une interconnaissance et d’une connivence au sein du groupe. Elle offre de nouvelles prises à la perception, se rattachant moins à ce que les contributeurs font qu’à ce qu’ils sont (Turkle, 1995 : 267). Les prises de parole publiques comme les discussions plus informelles offrent d’autres informations sur les identités individuelles et livrent de nouveaux indices sur les valeurs et les croyances. Ces signaux apparaissent particulièrement importants pour les fondateurs et pilotes du projet, car ils renseignent sur le niveau d’adhésion aux principes de « la philosophie de Spip », sur « les raisons profondes » des engagements, sur le niveau d’attachement à « l’identité politique de Spip », sur le degré d’accord avec « ce que nous on défend ». L’un des fondateurs indique ainsi : « C’est important de pouvoir avoir un peu plus de profondeur dans la relation, pour voir un peu si on a la même vision des choses, la philosophie de Spip du moins. C’est un peu tout ce qui est derrière, même si on n’a pas besoin d’être d’accord sur tout, mais dans les grandes lignes, oui. Sinon on va aller au conflit avec des personnes qui ont des responsabilités, et ça va rejaillir sur toute la communauté » (entretien réalisé en septembre 2005). Ils permettent de mieux comprendre les significations associées à la participation, d’apprécier la proximité avec leurs propres orientations en valeurs, et de repérer des membres actifs à qui l’administration de sites spécialisés et l’animation des espaces de travail correspondants pourraient être confiées.
Si la « communauté Spip » est orientée vers la production d’un logiciel, son fonctionnement ne consiste pas seulement à agencer les contributions de façon à obtenir un produit fonctionnel et cohérent ; il est aussi d’agencer les contributeurs dans un groupe ouvert et cohésif. C’est ainsi que se développe une socialisation, d’autant plus nécessaire que la participation au groupe revêt des significations subjectives contrastées et résulte de logiques biographiques d’engagement hétérogènes.
3. Une socialisation limitée : des engagements durablement hétérogènes
Les projets de logiciels libres ne peuvent survivre et grandir qu’à la condition d’attirer un nombre suffisant de contributeurs habituels. Le projet Spip doit en permanence chercher à limiter les défections et à mobiliser de nouveaux participants : quelques dizaines de développeurs y contribuent assez régulièrement, et la pérennité du projet dépend du maintien de ce niveau de participation. L’enquête biographique conduite auprès des deux tiers environ des contributeurs habituels révèle que leurs engagements diffèrent sensiblement — et durablement —, par les objectifs poursuivis, les valeurs défendues, les significations subjectives. Elle montre aussi que ces raisons d’agir et de participer ne se réduisent pas à des motivations idéologiques (Blondeau et Latrive, 2000), mais sont enracinées dans les parcours de vie, les expériences accumulées, les situations rencontrées, bref, les carrières (Hughes, 1967 : 175-185), de sorte qu’elles apparaissent stables et durables.
Trois polarités ont été identifiées quant à ces raisons d’agir, qui s’écartent plus ou moins des orientations au principe du lancement du projet Spip. Le premier pôle se caractérise par le poids et l’expérience du militantisme politique. Ici, la participation au projet, plus globalement au monde des logiciels libres, s’ajoute à d’autres activités militantes, menées dans des associations, partis politiques, mouvements sociaux, situés du côté de la gauche non institutionnelle. Les parcours biographiques sont marqués par le militantisme, de différentes manières : « Moi je suis uruguayen de naissance et réfugié politique donc les histoires d’engagement, j’y suis tombé malgré moi, si tu veux » (entretien avec Ernesto[4], mars 2005). « J’ai créé un syndicat étudiant, mais j’ai toujours eu d’autres investissements, parce que forcément, tu t’intéresses à un tas de choses et tu te fais comme ça ta conscience politique » (entretien avec Georges, juillet 2005). Ces expériences sont convergentes avec le militantisme des initiateurs du projet Spip, tous très engagés dans de multiples réseaux militants, faisant remonter l’émergence du projet à la conviction partagée d’une menace croissante d’appropriation d’Internet par les industries du contenu, de la nécessité de mettre au point des outils nouveaux facilitant la « libre expression numérique ». L’entrée dans le projet Spip ne s’appuie que rarement sur une connaissance de cette perspective politique sous-jacente. Elle s’apparente à une logique d’utilisateurs, orientés vers le logiciel Spip du fait de sa forte notoriété dans les milieux associatifs, une logique de demandeurs d’outils intéressés à fabriquer un site Internet pour leur organisation militante. Dans un deuxième temps, le « projet politique » en faveur de la libre expression sur Internet au fondement de Spip suscite un intérêt spécifique, résonne avec les expériences militantes antérieures et alimente une implication croissante. « On trouve très peu de projets de logiciels libres où il y a une dimension politique qui est aussi fortement marquée. […] On n’hésite pas à avoir des discussions à portée éthique, politique, y compris sur des fonctionnalités. […] Ici dans Spip, il y a en plus la dimension “quel modèle de société on promeut à travers ça” » (entretien avec Georges, juillet 2005). Si Spip est initialement une ressource informatique utile et efficace, il devient une cause appelant un soutien, et un groupe réclamant participation et investissement personnel : « On en arrive très rapidement à se sentir coresponsable du machin, et de se dire que c’est intéressant que ce projet puisse vivre, moi j’ai envie de le soutenir, et c’est ce qui fait qu’on répond aux utilisateurs […], c’est parce qu’on se dit que c’est intéressant pour Spip d’avoir un vivier de plusieurs dizaines de milliers d’utilisateurs. Et ça oui, c’est clair, on se sent partie prenante du truc » (entretien avec Yves, octobre 2006).
Un autre pôle de participants s’intéresse à ce qu’on pourrait nommer « la beauté technique », pour reprendre l’expression d’un répondant. L’investissement dans le projet y est justifié par la passion de l’informatique et l’intérêt technologique qu’offre le logiciel : « Dans mon cas, je suis plus tombé dedans par le côté technique que par le côté utilisateur, comme je suis informaticien de formation, quand j’ai entendu parler de ce machin-là, j’ai plus été intéressé de savoir comment ça marchait plutôt que qu’est-ce qu’on pouvait en faire » (entretien avec Gilbert, mai 2005). L’engagement s’inscrit dans le prolongement de cursus de formation et de parcours professionnels marqués par l’activité informatique et soutenus par un rapport passionné à la technique. Pour ces spécialistes de l’informatique, dont la plupart travaillent dans des sociétés de services, l’activité de programmation est considérée comme un support de créativité. Elle est un mode d’expression de soi permettant de relever des défis et de produire des innovations. Plus, elle est une véritable activité de création, à forte composante esthétique, valorisée sur le mode « l’art pour l’art » : « Ce qui me tient là, c’est de pouvoir faire du beau code, pouvoir m’exprimer sans obligation de délai ou de choses comme ça » (entretien avec Victor, septembre 2005). La participation au projet Spip succède ou s’additionne à l’investissement dans d’autres logiciels libres. Elle résulte d’abord d’une curiosité pour les développements techniques du produit : il ne s’agit pas de trouver un outil mobilisable pour fabriquer un site, mais plutôt d’investir un espace stimulant pour exercer ses compétences de développeur. L’engagement dans le projet Spip s’apparente à une sorte de passe-temps, dont la dimension technique constitue le carburant et le stimulant. L’attachement y est d’autant plus fort que l’activité professionnelle est soumise à des contraintes organisationnelles, commerciales, hiérarchiques qui ne permettent pas suffisamment l’exercice d’une professionnalité informatique « authentique ». Par contraste, le projet Spip offre un espace de loisir technologique, une occasion de rencontre avec d’autres virtuoses de l’informatique — des geeks —, qui permet la réalisation de projets dont l’intérêt n’est pas évalué à l’aune d’une réponse à des besoins ou d’un rapport coût/bénéfice, mais bien de considérations de « beauté technique ».
Enfin, dans le troisième pôle, la participation à Spip ne s’articule pas à des engagements politiques militants, elle ne correspond pas non plus à un goût pour les défis techniques ; elle s’insère dans, et alimente, des activités professionnelles. Celles-ci sont généralement le fait de travailleurs indépendants : ces consultants informatiques espèrent consolider leur offre de services informatiques en approfondissant leur connaissance de Spip et en participant à son développement. C’est pourquoi ce pôle peut être désigné comme celui d’une « activité marchande » : « Je suis arrivé dans une période de chômage où c’était vital pour moi de faire des sous […] et donc j’ai lu tout le manuel, tout le manuel, et puis Spip a constitué un autre mode de continuer à vivre » (entretien avec Damien, décembre 2005). Ici, l’engagement dans le projet relève d’une sorte de calcul économique : ce logiciel a une certaine notoriété, il est développé par une « communauté » active, il se situe sur un créneau porteur répondant aux besoins croissants de conception de sites Internet. La participation au projet est justifiée par l’anticipation d’usages commerciaux : « C’est une aubaine, dans le sens où Spip, c’est un produit performant. Tu peux vendre du service en toute confiance, parce que tu sais que ça tourne, tu sais que ça développe, voilà, ça marche et c’est vivant » (entretien avec José, mars 2005). Cette participation se concrétise de diverses manières : aide aux utilisateurs, proposition de contributions, discussion sur les fonctionnalités, correction de bugs. Dans tous les cas, elle s’apparente à une stratégie d’appropriation fine du logiciel, de compréhension de ses spécificités, de ses fonctionnalités et de ses failles les plus profondes. Elle permet d’accumuler des compétences de plus en plus pointues, d’acquérir une véritable expertise professionnelle relative au produit dans le but de la faire valoir auprès de la clientèle à laquelle s’adresse l’offre de services (conception de sites web) : « C’est un plus d’être sur du libre, dans le sens où on est dans le code vraiment. Alors c’est un argument pour les clients, parce que tu peux dire que tu maîtrises » (entretien avec Maurice, mars 2006). La réussite économique de cette stratégie est variable, puisque aux côtés de consultants qui cherchent à enchaîner les contrats commerciaux, d’autres participants réalisent des prestations occasionnelles. Mais du moins la participation au projet Spip est le support d’activités professionnelles consultantes et rétribuées, même si celles-ci sont parfois menées sur un mode plutôt mineur et intermittent.
Les ressorts des engagements, les significations des activités et les objectifs poursuivis dans la participation apparaissent ainsi hétérogènes et désaccordés. Plus, ils se situent à distance variable de l’ordre de légitimité construit dans la genèse et l’histoire du groupe : le projet politique initial rencontre l’adhésion de certains contributeurs et l’indifférence de certains autres, cette indifférence s’incarnant dans des orientations plus ou moins compatibles ou contradictoires, selon qu’elles relèvent de la beauté technique ou de l’activité marchande. Ainsi la participation au projet, même régulière, n’a pas pour effet d’homogénéiser les points de vue et de susciter une conversion aux valeurs tenues pour les plus légitimes. En ce sens, la socialisation est limitée. Si cette hétérogénéité persiste, c’est aussi parce qu’elle s’enracine dans des expériences socialisatrices antérieures contrastées, ou parce qu’elle s’articule à des situations ou à des engagements professionnels différenciés. Cela résulte également de la configuration du collectif lui-même, dont la force socialisatrice est limitée par la variété des valeurs et des conduites acceptées en interne. Du reste, cette caractéristique d’hétérogénéité en valeur(s) n’est pas si rare dans les collectifs d’engagement volontaire non institutionnalisés — à l’inverse des partis politiques — et fédérés autour d’un projet à réaliser (Havard-Duclos et Nicourd, 2005 : 113-142). Toutefois, dans ces groupes de projet, la socialisation est nécessaire, elle doit être suffisante pour produire ou maintenir la cohésion du groupe. Il reste donc à comprendre comment des logiques d’engagement aussi diversifiées peuvent se combiner dans une action collective cohérente, pour aboutir à la mise au point d’un produit consistant. C’est-à-dire quels agencements sociaux permettent non seulement la coexistence de ces perspectives si dissemblables, mais, plus encore, leur synergie ?
4. Une socialisation discriminante : des participations évaluées et contrôlées
Nos observations montrent que le fonctionnement du groupe et les échanges entre membres sont marqués par des jeux d’énonciation et de rappel des valeurs ou normes de référence ayant présidé au lancement du projet. Ces jeux, qui ne sont pas exclusivement langagiers, visent à entretenir la cohésion et la cohérence d’un collectif dont la composition évolue continûment. Mais ils ne produisent pas une conformité uniforme et obligatoire ; plutôt, ils traduisent certaines différences dans la légitimité accordée aux diverses participations individuelles et la reconnaissance dont elles font l’objet. Deux mécanismes distincts apparaissent prégnants : l’un affirme de manière implicite les valeurs de référence à travers la différenciation de rôles et de statuts dans l’organisation du projet, l’autre affiche de manière explicite les valeurs de référence à travers la production de jugements construisant les réputations. Dans un cas, les contributeurs qui accèdent à des responsabilités apparaissent comme des modèles de référence ; dans l’autre, la désignation publique de conduites comme déviantes constitue un rappel du référentiel. L’articulation de ces deux mécanismes balise un espace de conduites acceptables valable pour l’ensemble des participants.
4.1. La valorisation des conduites tenues pour légitimes
La délégation de responsabilités à des contributeurs, auxquels on confie l’animation d’espaces de travail, le pilotage de sous-projets ou la coordination de certaines tâches, ne répond pas seulement à une nécessité fonctionnelle liée à l’afflux de demandes, de sollicitations ou de questions qui accompagnent la diffusion rapide du logiciel. Elle participe aussi de la gestion du groupe et de ses participants. Ainsi, les projets de logiciels libres qui, à l’image de Spip, parviennent à maturité se caractérisent par des mécanismes de reconnaissance et de gratification des contributeurs (Di Maggio et Anheier, 1990 : 142), qui peuvent s’apparenter à l’attribution de véritables statuts (Stewart, 2005 : 840). De fait, nous avons observé combien cette délégation était vécue par ceux qui en bénéficient comme une reconnaissance des efforts et des apports fournis, comme une valorisation des contributions pour lesquelles les individus ont payé de leur personne, comme une progression dans l’organisation du projet, comme une promotion. Pour ceux qu’elles concernent, ces gratifications soutiennent les engagements.
Mais, de manière plus large, elles sont aussi un vecteur de reconnaissance et de diffusion d’attentes normatives à l’ensemble des participants. Car ce n’est pas seulement le travail produit, la contribution, qui est pris en compte, ce sont aussi les qualités du contributeur. Certes, tous les participants qui exercent des responsabilités particulières dans le groupe ont effectué des contributions considérées comme « significatives » et « fiables » selon les critères suivants : elles correspondent à des réalisations techniques importantes, elles requièrent une dépense temporelle élevée, elles s’étalent sur une durée suffisamment longue. La fiabilité de la contribution ne s’épuise toutefois pas dans sa valeur technique, elle renvoie également à la régularité de l’engagement qui la soutient et, par conséquent, à la fiabilité du contributeur lui-même. Fiabilité qui se rapporte à la posture adoptée à l’égard du projet et se décline en deux dimensions distinctes largement indépendantes. La première renvoie à la participation à la production, à la capacité de concrétiser ses contributions ou à mener à bien des projets qui exigent une certaine ténacité. Être fiable signifie tenir ses engagements, même implicites, et c’est la stabilité de l’engagement, appréciée dans le registre du faire, qui est en jeu ici : « Celui qui s’investit beaucoup, tu le repères vite. Quelqu’un qui s’accroche, qui va au bout de ses intentions, c’est très important […]. La question c’est de savoir si on peut compter dessus, et jusqu’où » (entretien avec un contributeur réalisé en janvier 2006, à un moment où il s’investissait fortement dans l’animation d’un des espaces de travail). La seconde dimension concerne le sens de l’engagement et non plus son résultat. Elle renvoie à l’adéquation de « l’esprit du projet » — et non plus à sa production —, dont, en l’espèce, la coloration et l’identité idéologiques sont affirmées. La fiabilité se traduit ici par des affinités idéologiques, en particulier par l’accord explicite avec les principes politiques à la base de Spip. N’impliquant aucun engagement dans des organisations militantes, elle suppose toutefois l’expression d’orientations en valeurs justifiant la participation au projet.
Cette régulation des reconnaissances par les valeurs n’est pas explicitée auprès des participants, et n’est pas toujours exprimée dans les entretiens réalisés avec les animateurs du projet Spip. Mais elle est lisible dans certaines de leurs stratégies visant à mieux connaître les contributeurs qui par leur production paraissent fiables, et à apprécier les significations qu’ils apposent à leur participation. Ces animateurs (membres du noyau) établissent ainsi des contacts informels ou privés (conversations téléphoniques, rencontres directes, déjeuners) permettant d’apprécier — ou plus exactement de vérifier — quelles valeurs sous-tendent l’engagement de ces contributeurs : « Quelqu’un qui fait un tel boulot peut pas non plus être un gratos et tout, ça ne peut pas être une enflure dangereuse […]. Alors là, on essaye de se faire une bouffe, on se rencontre, pour voir les gens quoi » (entretien avec l’un des initiateurs, décembre 2005). Cette deuxième épreuve, après celle de la contribution, est d’autant plus affirmée que les responsabilités à déléguer sont importantes et rapprochent les individus concernés du noyau. Elle contribue aussi à distinguer les engagements enracinés dans des parcours qui gravitent autour du pôle du militantisme politique, ou du moins qui n’en sont pas trop éloignés.
Mais des responsabilités importantes sont aussi confiées à des contributeurs qui justifient leur participation par un attrait pour la technique informatique plutôt que par des valeurs politiques ou éthiques. Il s’agit d’individus proches du pôle de la beauté technique, mais qui ont manifesté des signes minimaux de socialisation et d’adhésion, par exemple en participant à des discussions non techniques (lors de rencontres entre contributeurs ou sur des canaux IRC). Plus généralement, les contributeurs les plus compétents en ce qui concerne la programmation informatique font l’objet d’une attention toute particulière, parce que leur production est précieuse, même si le sens de leur engagement est peu lisible. Des positions leur sont attribuées pour qu’ils puissent exercer leur créativité : certains espaces essentiellement techniques leur sont dédiés (Lab, Dev, Zone). Ils font donc l’objet de processus spécifiques de reconnaissance et de valorisation.
4.2. La stigmatisation des conduites considérées comme illégitimes
Un autre mécanisme de valorisation différentielle des participations et de régulation du groupe s’appuie sur la production discursive de jugements et non sur l’attribution de positions dans l’organisation, débouchant sur la construction de réputations et non sur la délégation de responsabilités. On sait que le logiciel Spip est porté par le projet d’accroître les possibilités d’expression sur Internet. Cette visée, politique, éthique ou idéologique, participe à la construction d’un ordre de légitimité qui sert de référence pour qualifier les attitudes et conduites des contributeurs : l’enracinement dans une mouvance militante de gauche est à cet égard renforcé par l’affirmation d’un principe de désintéressement, qui dévalorise ipso facto les usages commerciaux du logiciel. Dans un tel cadre normatif, les contributeurs dont l’engagement se rapproche du pôle de l’activité marchande ont une posture décalée par rapport à ce principe, se trouvant durablement marqués, stigmatisés. Aussi, la préservation de l’identité du logiciel, comme la survie du projet, requièrent de contenir la participation de tels contributeurs, tout en bénéficiant de leur apport. La limitation et la stigmatisation des conduites considérées comme illégitimes ou déviantes empruntent plusieurs voies.
La première voie consiste à rappeler explicitement le référentiel originel du projet, à travers une série de supports variés (manifestes, chartes, bandeaux) implantés dans les espaces virtuels de travail et d’échange. Ces pratiques permettent de diffuser en continu les valeurs légitimes et centrales. Ainsi, le lancement en 2005 d’un nouvel espace de développement (Spip-Zone) est l’occasion de mettre l’accent sur les valeurs originelles, à travers l’élaboration d’une charte destinée à encadrer la participation et qui bannit explicitement les usages marchands, comme l’indique cet extrait :
La participation à la Spip-Zone doit être faite dans le cadre des buts et valeurs promus par le projet initial du minirézo […]. Cela implique, entre autres, […] une priorité accordée aux besoins associatifs sur les besoins marchands, etc. Ce site n’est pas une plateforme de développement pour des versions militaires ou business-oriented de Spip qui viendraient en changer la nature. Il n’a pas non plus vocation à servir de support de communication ou de publicité pour consultants (extrait de la charte figurant sur Spip-Zone).
Certaines attitudes et conduites sont ainsi clairement proscrites, parce qu’elles sont jugées contradictoires et incompatibles avec « l’esprit du projet », défini comme un « projet de société » dans certains échanges — sur les forums ou lors de rencontres directes. Ces orientations ne sont pas déclinées en un règlement qui fixerait des obligations et des interdits. Mais les textes de cadrage, comme les chartes, fixent en creux les limites de l’éventail des conduites acceptables et véhiculent des formes plus diffuses de contrôle des conduites. Ainsi, certains contributeurs se réfèrent à ces textes pour refuser de fournir de l’aide à d’autres participants engagés dans la réalisation de sites pour une clientèle jugée illégitime (industrie de l’armement, parlementaires ou partis de droite), et font largement connaître leur position sur les listes d’envoi. En outre, des contributeurs ayant une activité indépendante autour de Spip essuient la critique d’autres membres du groupe quand ils utilisent leur adresse électronique commerciale. Ils expérimentent ainsi le sens des limites à ne pas dépasser, et sont conduits à éliminer de leur signature toute référence à la composante marchande de leur activité.
Les forums de discussion (IRC) sont un lieu privilégié de stigmatisation de certaines conduites, donc de diffusion de valeurs et normes tenues pour légitimes. Si les jugements se rapportent à un petit nombre de participants, durablement stigmatisés, leur portée est beaucoup plus large. En effet, ils sont énoncés au cours d’échanges publics regroupant tous les participants au forum, et non seulement les individus pris pour cible. De plus, nous avons observé qu’une pluralité de membres intervenait lors de ces échanges, ce qui indique que l’activité de jugement, public, est largement partagée. Les recadrages portent sur des conduites qui s’écarteraient des cadres de l’engagement légitime et transgresseraient les valeurs communes. Cet extrait d’un échange sur IRC en donne une illustration, le contributeur dont le pseudonyme est Polux33 y étant recadré (IRC, canal Spip, le 5 mai 2006, à 11 h 58) :
Hervé : Je suis pas sûr que ton dernier commit soit libre... C’est quoi ces codes Picasa ?
Polux33 : Euh, c’est le logiciel gratuit de Google pour visionner ses photos.
Hervé : Mais c’est de la pub ?
Polux33 : C’est un code dans le squelette pour appeler la pub, oui.
Hervé : Ah oui mais c’est hors charte, à mon sens. Si les gens veulent rajouter de la pub sur leur site, grand bien leur fasse, mais ça n’a rien à faire sur la Spip-Zone.
Hervé : « Comment coller un tag de pub dans un squelette ? » Fais un tutoriel sur ton site :-) Mais la Charte de Spip-Zone est claire sur ce point (ou alors il faut la clarifier) : pas de pub.
Polux33 : La zone parle : « une défiance vis-à-vis de l’argent », « une priorité accordée aux besoins associatifs sur les besoins marchands ».
Polux33 : Une association peut avoir besoin d’afficher des pubs sur son site.
Hervé : C’est hors charte.
Hervé : Et je précise que, si c’est pas clair il faut revoir la charte.
Les discussions, dénonciations, condamnations se concentrent sur les conduites qui manifestent des usages marchands, profitables du logiciel Spip. Elles sont le fait de participants exerçant l’activité de consultant en informatique, dont les contributions, même très solides, sont fréquemment interprétées comme étant des instruments de leurs propres stratégies marchandes plutôt que des apports désintéressés au projet collectif.
La coexistence d’engagements très hétérogènes est possible parce que ceux-ci sont affectés de niveaux différenciés de reconnaissance. Les orientations éthiques, politiques et idéologiques à l’origine du projet fonctionnent comme une matrice centrale plutôt que comme une norme impérative. La proximité avec cette matrice est reconnue et valorisée à travers la délégation de responsabilités, ceci fournissant de manière implicite un modèle de référence. De façon complémentaire, la distance à cette matrice provoque des stigmatisations explicites destinées à limiter les écarts de conduite, ceci diffusant en creux le même modèle de référence. Celui-ci fonctionne comme une balise fixant un ordre de légitimité et délimitant un espace ordonné de conduites acceptables. Il n’est pas un opérateur de socialisation homogène, mais produit, à travers divers mécanismes, une socialisation discriminante, modulée selon la position occupée par chacun dans l’espace symbolique des conduites possibles.
5. Conclusion
Le collectif étudié se caractérise par une grande ouverture concernant les motivations et ressorts de l’engagement des membres, ce qui n’est pas sans lien avec la nécessité d’élargir le cercle des contributeurs habituels. La réussite du projet dépend directement de la capacité à attirer et à retenir des participants, ce qui interdit l’instauration de filtres à l’entrée. En même temps, un contrôle social diffus mais prégnant s’exerce, se traduisant dans un traitement différentiel des membres et visant à l’entretien des valeurs initiales du projet et de l’identité du produit. Sont ainsi combinées une tolérance maximale et une reconnaissance différenciée des participants.
Cette combinaison se traduit par des modes spécifiques de socialisation. Celle-ci ne modifie guère la signification que chacun donne à son activité, ni sa logique biographique d’engagement, n’entamant pas non plus l’hétérogénéité des justifications. En ce sens, cette socialisation régule moins les identités personnelles des participants que l’identité collective du projet — incluant le produit et le groupe de production. Les mécanismes socialisateurs identifiés visent moins la conversion des contributeurs à « l’esprit de Spip » que la conservation et la réussite du projet. La préservation d’une identité collective forte est d’ailleurs une condition du maintien des participations, un étayage du sens que chaque participant donne à son engagement. Car il faut un produit cohérent et performant pour que les contributeurs puissent y réaliser leur finalité propre : certains y trouveront un projet politique faisant écho à leurs orientations idéologiques ou éthiques, d’autres y trouveront un espace pour réaliser leurs aspirations techniques ou esthétiques, d’autres encore y trouveront une niche économique permettant d’élaborer des stratégies commerciales ou compétitives.
La collectivité qui en résulte est donc bien éloignée de la forme sociale communautaire dans laquelle les identités individuelles sont absorbées ou subsumées par une identité collective qui les modèle. Mais, à l’inverse, l’expression des identités individuelles est contenue et maîtrisée afin de ne pas menacer l’existence du groupe, son activité de production ou son projet idéologique. L’équilibre construit associe la priorité donnée à l’identité collective, matérialisée par la performance du produit de l’action collective et symbolisée par la visée normative du groupe, la limitation de l’expression des identités individuelles à travers des mécanismes variés d’attribution de légitimités différenciées aux conduites des membres. Aussi, les collectifs de production de logiciels libres, du moins celui qui a été analysé, ne sont pas des groupes faiblement intégrés, même si la plupart des échanges entre membres s’effectuent à distance. La distance est en quelque sorte contrebalancée par la permanence des contacts, ou du moins des connexions, la mémorisation des échanges, ou du moins leur enregistrement, le caractère public des relations, ou du moins leur visibilité. Ces propriétés des échanges sont les vecteurs d’une socialisation spécifique, qui permet de tenir un équilibre entre une forte cohésion de l’identité collective du groupe et une forte dispersion des identités individuelles des membres.
Appendices
Notes
-
[1]
Le site de développement collaboratif SourceForge.net, qui fédère très largement le monde du logiciel libre, héberge 117 000 projets. Ce chiffre est sans commune mesure avec le nombre limité de logiciels libres qui circulent et sont utilisés. De fait, la plupart des projets recensés sont inactifs ou en sommeil.
-
[2]
La signification du terme « Spip » est multiple. Pour certains, il s’agirait d’une référence au nom du bateau d’un ami des initiateurs, pour d’autres, c’est l’acronyme de système de publication pour l’Internet participatif ou encore la traduction française de la sentence latine Scientia populi ingeniose partita (« le savoir du peuple partagé avec intelligence »).
-
[3]
Classiquement, la structuration des collectifs de développement de logiciels libres est organisée en cercles concentriques, depuis un noyau stratégique de taille restreinte, jusqu’à une nébuleuse de contributeurs éphémères dont l’apport est limité (Demazière et al., 2006 : 78).
-
[4]
Les prénoms mentionnés ont été modifiés pour respecter l’anonymat des personnes qui ont accepté de faire un entretien avec nous.
Bibliographie
- Adler, P. S. (2001). « Market, Hierarchy, and Trust : The Knowledge Economy and the Future of Capitalism », Organization Science, n° 12, p. 215-234.
- Auray, N. (2004). « La régulation de la connaissance : arbitrage sur la taille et gestion aux frontières dans la communauté Debian », Revue d’économie politique, numéro spécial : « Marchés en ligne et communautés d’agents », p. 74-99.
- Beuscart, J.-S. (2002). « Les usagers de Napster entre communauté et clientèle : construction et régulation d’un collectif sociotechnique », Sociologie du travail, vol. 44, n° 4, p. 461-480.
- Blondeau, O. et F. Latrive (dir.) (2000). Libres enfants du savoir numérique, Paris, L’Éclat.
- Boltanski, L. et E. Chiapello (1999). Le nouvel esprit du capitalisme, Paris, Gallimard.
- Castells, M. (2001). La galaxie Internet, Paris, Fayard.
- Clifford, J. (1992). « Travelling Cultures », in L. Grossberg, C. Nelson et P. A. Treichler (dir.), Cultural Studies, Londres, Routledge, p. 96-116.
- Conein, B. (2004). « Communautés épistémiques et réseaux cognitifs : coopération et cognition », Revue d’économie politique, numéro spécial : « Marchés en ligne et communautés d’agents », p. 141-159.
- Corbin, J. et A. Strauss (1990). Basics of Qualitative Research. Grounded Theory : Procedures and Techniques, Newbury Park, Sage Publications.
- Demazière, D. et C. Dubar (2004). Analyser les entretiens biographiques, Québec, Presses de l’Université Laval.
- Demazière, D., F. Horn et N. Jullien (2005). « Le travail des développeurs de logiciels libres. La mobilisation dans des communautés distantes », Cahiers lillois d’économie et de sociologie, n° 45, p. 171-194.
- Demazière, D., F. Horn et M. Zune (2007). « Des relations de travail sans règles ? L’énigme de la production des logiciels libres », Sociétés contemporaines, n° 66, p. 101-125.
- Demazière, D., F. Horn et M. Zune (2006). « Dynamique de développement des communautés du logiciel libre. Conditions d’émergence et régulations des tensions », Terminal, n° 97-98, p. 71-84.
- Demil, B. et X. Lecocq (2006). « Neither Market nor Hierarchy or Network : The Emergence of Bazaar Governance », Organization Studies, vol. 27, n° 10, p. 1447-1466.
- Di Maggio, P. J. et H. Anheier (1990). « The Sociology of Nonprofit Organizations and Sectors », Annual Review of Sociology, n° 16, p. 137-159.
- Dubar, C. (1991). La socialisation. Construction des identités sociales et professionnelles, Paris, Armand Colin.
- Elias, N. (1987). « Les transformations de l’équilibre “Nous-Je” », in La société des individus, Paris, Fayard, p. 205-301.
- Elliot, M. et W. Scacchi (2004). « Free Software Development : Cooperation and Conflict in a Virtual Organizational Culture », in S. Koch (dir.), Free/Open Source Software Development, Herschley, IGI Publishing, p. 152-172.
- Erpicum, M. (2005). D’amour et de neutralité. Ce(ux) qui résiste(nt), Miméo, Liège, Université de Liège.
- Fernback, J. et B. Thompson (1995). « Virtual Communities : Abort, Retry, Failure ? », http://www.well.com/ user/hlr/texts/VCcivil.html.
- Gensollen, M. (2004). « Biens informationnels et communautés médiatées », Revue d’économie politique, numéro spécial : « Marchés en ligne et communautés d’agents », p. 3-40.
- Ghosh, R. A., R. Glott, B. Krieger et G. Robles (2002). Free/Libre/Open Source Software : Survey and Study-FLOSS Final Report. Part 4 : Survey of Developers, Maastricht, University of Maastricht.
- Glass, R. L. (2003). « A Socio-Political Look at Open Source », Communications of the ACM, n° 46, p. 21-23.
- Harrison, P.M. (1960). « Weber’s Categories of Authority and Voluntary Associations », American Sociological Review, vol. 25, n° 2, p. 232-237.
- Havard-Duclos, B. et S. Nicourd (2005). Pourquoi s’engager ? Bénévoles et militants dans les associations de solidarité, Paris, Payot.
- Healy, K. et A. Schussman (2003). The Ecology of Open-Source Software Development, http://opensource.mit.edu/papers/healyschussman.pdf.
- Hertel, G., S. Niednet et S. Herrmann (2003). « Motivation of Software Developers in Open Source Projects : An Internet-Based Survey of Contributors to the Linux Kernel », Research Policy, n° 32, p. 1159-1177.
- Himanen, P., L. Torvalds et M. Castells (2001). The Hacker Ethic, New York, Random House.
- Hine, C. (2000). Virtual Ethnography, Londres, Sage Publications.
- Holtgrewe, U. et R. Werle (2001). « De-Commodifying Software ? Open Source Software between Business Strategy and Social Movement », Science Studies, n° 15, p. 43-65.
- Horn, F. (2004). L’économie des logiciels, Paris, La Découverte.
- Hughes, E. C. (1996 [1967]). Carrières, in Le regard sociologique, Paris, Éditions de l’EHESS, p. 175-185.
- Kollock, P. (1998). « Social Dilemmas : The Anatomy of Cooperation », Annual Review of Sociology, n° 24, p. 183-214.
- Lakhani, K. et R. Wolf (2005). « Why Hackers Do What They Do : Understanding Motivation and Effort in Free/Open Source Software Projects », in J. Feller, B. Fitzgerald, S. Hissam et K. Lakhani (dir.), Perspectives on Free and Open Source Software, MIT Press, p. 3-22.
- Lerner, J. et J. Tirole (2002). « Some Simple Economics of Open Source », Journal of Industrial Economics, vol. 50, n° 2, p. 197-234.
- Moon, J. et L. Sproull (2002). « Essence of Distributed Work : The Case of the Linux Kernel », in P. Hinds et S. Kiesler (dir.), Distributed Work, Cambridge, MIT Press, p. 381-404.
- O’Mahony, S. (2003). « Guarding the Commons : How Community Managed Projects Protect Their Work », Research Policy, vol. 32, n° 7, p. 1179-1198.
- Pahl, R. (2002). « Towards a More Significant Sociology of Friendship », Archives européennes de sociologie, vol. 43, n° 3, p. 410-423.
- Powell, W. W. (1990). « Neither Market nor Hierarchy : Network Forms of Organization », Research in Organizational Behavior, n° 12, p. 295-336.
- Proulx, S. et G. Latzko-Toth (2001). « La virtualité comme catégorie pour penser le social : l’usage de la notion de communauté virtuelle », Sociologie et sociétés, vol. 32, n° 2, p. 99-122.
- Raymond, E. S. (1998). La cathédrale et le bazar, traduction de S. Blondeel, http://www.lifl.fr/~blondeel/traduc/Cathedral-bazaar/Main_file.html.
- Rothschild, J. et R. Russell (1986). « Alternatives to Bureaucracy : Democratic Participation in the Economy », Annual Review of Sociology, n° 12, p. 307-328.
- Rutter, J. et G. Smith (2005). « Ethnographic Presence in a Nebulous Setting », inC. Hine (dir.), Virtual Methods. Issues in Social Research on the Internet, Oxford, Berg, p. 81-92.
- Stewart, D. (2005). « Social Status in an Open Source Software Community », American Sociological Review, vol. 70, n° 5, p. 823-842.
- Turkle, S. (1995). Life on the Screen : Identity in the Age of Internet, New York, Simon and Schuster.
- Velkovska, J. (2002). « L’intimité anonyme dans les conversations électroniques sur les webchats », Sociologie du travail, vol. 44, n° 2, p. 193-213.
- Von Hippel, E. G. et G. Von Krogh (2003). « Open Source Software and the “Private-Collective” Innovation Model : Issues of Organization Science », Organization Science, n° 14, p. 209-223.
- Von Krogh, G., S. Spaeth et K. R. Lakhani (2003). « Community, Joining, and Specialization in Open Source Software Innovation : A Case Study », Research Policy, n° 32, p. 1217-1241.
- Weber, M. (1971 [1921-1922]). Économie et société, tome 1, Paris, Plon.
- Weber, S. (2005). The Success of Open Source, Harvard, Harvard University Press.
- Wellman, B. et M. Gulia (1999). « Virtual Communities as Communities : Net Surfers Don’t Ride Alone », in M. Smith et P. Kollock (dir.), Communities in Cyberspace, Londres, Routledge, p. 167-194.
- Wellman, B., J. Salaff, D. Dimitrova, L. Garton, M. Gulia et C. Haythornthwaite (1996). « Computer Networks as Social Networks : Collaborative Work, Telework, and Virtual Community », Annual Review of Sociology, n° 22, p. 213-238.
- Wenger, E. (1998). Communities of Practice : Learning, Meaning, and Identity, Cambridge, Cambridge University Press.
- Yin, R. K. (1994). Case Study Research : Design and Methods, Beverly Hills, Sage Publications.