Linux : méritocratie et vision managériale
Chapitre 4
Pratiques et idéologie
Le general intellect, les intelligences connectées, l’errante intelligentsia qui voyage d’une tribu à l’autre ne sauraient être qu’un suave mensonge.
Geert Lovink, Florian Schneider
Nous avons jusqu’à présent omis de poser une question très simple aux différents discours sur la collaboration distribuée : fournissent-ils une description adéquate des pratiques effectivement mises en œuvre dans les grands collectifs du logiciel libre ?
Ces pratiques sont aujourd’hui bien documentées, puisqu’elles ont donné lieu à de nombreux travaux universitaires, notamment américains1.
Dans son ouvrage The Success of Open Source, Steven Weber met ainsi en garde contre l’emploi trop fréquent de notions abstraites comme celle de « système auto-organisé », et insiste sur la nécessité de partir d’une « description minutieuse des conduites réelles »2.
Il faut dès lors se demander si le modèle de coopération ouverte, décentralisée, et anti-hiérarchique véhiculé par la mythologie de la collaboration distribuée ne serait pas, non seulement une formalisation et une légitimation, mais aussi une idéalisation des pratiques effectives.
1 On pourra ainsi citer, parmi d’autres : Steven WEBER, The Success of Open Source, Cambridge and London, Harvard University Press, 2004; Christopher KELTY, Two Bits, op. cit.; Karim R. LAKHANI et Eric von HIPPEL, « How open source software works : «free» user-to-user assistance », op. cit.; James LEACH, Dawn NAFUS et Bernhard KRIEGER, « Freedom Imagined : Morality and Aesthetics in Open Source Software », Ethnos, vol 74, n° 1, 2009, p. 51-71, en ligne : www.jamesleach.net/downloads/Freedom%20imagined%20draft.pdf (consulté le 05/09/2011). En français, on pourra notamment se référer aux ouvrages et articles suivants : Didier DEMAZIÈRE, François HORN, Nicolas JULLIEN, « Le travail des développeurs de logiciels libres. La mobilisation dans des «communautés distantes» », Cahiers lillois d’économie et de sociologie, n°46, 2005, p. 171-194, en ligne : http://hal.archives-ouvertes.fr/hal-00282214/en/ (consulté le 14/11/2011); Christophe LAZARO, La liberté logicielle. Une ethnographie des pratiques d’échange et de coopération au sein de la communauté Debian, op. cit.; Bernard CONEIN, « Communautés épistémiques et réseaux cognitifs : coopération et cognition distribuée », Revue d’Economie Politique, n°113, 2004, p.141-159.
2 Steven WEBER, op. cit., p. 83.
Afin de répondre à cette question, il est indispensable de confronter le discours de la collaboration distribuée à une analyse précise de l’organisation du travail dans les grands collectifs open source.
C’est ce que nous nous proposons de faire sur trois exemples, qui renvoient à des projets à la fois emblématiques de la culture « libre » et relativement dissemblables : Linux, Debian et Wikipédia.
L’analyse comparative fait ressortir les spécificités de ces collectifs, en termes de règles formelles d’organisation mais aussi de valeurs sous-jacentes à celles-ci.
Elle conduit à aborder un deuxième versant de l’idéologie : non plus la légitimation du monde tel qu’il est, mais le voile posé sur le réel empêchant d’en saisir la complexité et les singularités1.
Linux : méritocratie et « vision » managériale
Le processus de développement du noyau Linux est souvent présenté comme l’archétype de l’organisation en vigueur dans les grands collectifs open source.
Il s’agit du premier projet à avoir tiré profit à une telle échelle des possibilités ouvertes par Internet, Linus Torvalds étant considéré par certains (Eric Raymond par exemple) comme « l’inventeur » des principes de la collaboration distribuée.
Il s’agit en outre d’un logiciel libre extrêmement emblématique, puisqu’il fournit le cœur du système d’exploitation GNU/Linux, symbole de l’opposition au monde « propriétaire » incarné par Windows et Mac OS X.
Durant les premières années, l’organisation du projet Linux était relativement simple.
Les développeurs soumettaient de nouvelles sections de code (patches) à Linus Torvalds, et celui-ci décidait de celles qui étaient incorporées dans le noyau.
La croissance de Linux, tant au niveau de sa complexité technique que du nombre de ses contributeurs, poussa à la mise en place de procédures plus élaborées.
En 1995 fut ainsi prise une décision technique, qui était aussi un choix quant à l’organisation du travail : le noyau Linux devint modulaire2.
Autrement dit, il n’était plus constitué d’un unique bloc de code, mais de différents modules accomplissant différentes fonctions3. Il devenait dès lors plus aisé de répartir le travail, et notamment la révision des modifications proposées, en fonction de ces différents blocs de code indépendants.
1 Ces deux sens de l’idéologie ne sont évidemment pas nécessairement contradictoires.
2 L’intrication entre les décisions techniques de conception et les principes d’organisation du travail est bien mise en évidence par Linus Torvalds : « Les impératifs de gestion du code et de gestion des gens aboutirent à la même décision de conception : pour réussir à coordonner tous les gens qui travaillent sur Linux, nous avions besoin d’une forme de modularité du noyau » (cité par Steven WEBER, op. cit., p. 173).
3 Théoriquement, on distingue en général deux grands types d’architectures pour les noyaux : les noyaux monolithiques et les micro-noyaux. Les premiers sont constitués d’un seul « bloc » de code, qui assure l’ensemble des fonctions du système. Les seconds ne prennent en charge qu’un minimum de fonctions fondamentales, et « externalisent » les autres dans l’espace utilisateur. Il s’agit donc de deux conceptions radicalement opposées. Dans la pratique, ce sont cependant la plupart du temps des solutions intermédiaires qui ont été adoptées. Linux est ainsi depuis 1995 un « noyau monolithique modulaire », ce qui signifie que de nombreuses fonctions dépendent de modules indépendants, et que le code source peut être séparé en plusieurs blocs [cf. « Noyau de système d’exploitation », Wikipédia (version française), en ligne : http://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27exploitation (consulté le 27/04/2011)].
À partir du milieu des années 1990, Linus Torvalds commença donc à déléguer certaines décisions concernant les modifications à intégrer. Cette évolution se déroula de façon à la fois progressive et informelle.
Il laissa d’abord à quelques personnes de confiance (ses « lieutenants », parfois aussi appelés core developers) le soin de sélectionner les patches destinés à enrichir certains modules du noyau, et leur fit suivre les propositions de modification qui lui étaient soumises.
Les contributeurs se mirent ensuite à envoyer leurs patches directement à ces nouveaux intermédiaires, avec charge pour ceux-ci de les incorporer au code source, de tester le résultat, et de décider s’il était satisfaisant.
Puis ces lieutenants en vinrent eux-mêmes à déléguer la responsabilité de certains sous-modules à des « mainteneurs » (maintainers). Une structure d’organisation pyramidale se mit ainsi progressivement en place, mais sans qu’aucun document n’établisse formellement qui était exactement en charge de quoi1.
Ces éléments de hiérarchie furent tacitement acceptés, au sens où la pratique consistant à envoyer les patches directement aux responsables « de fait » de chaque partie du code source se généralisa peu à peu parmi les développeurs.
En 1996, ces modifications organisationnelles firent néanmoins l’objet d’une certaine formalisation, avec l’adoption de la distinction entre « credited developers » et « maintainers », qui conféra aux derniers nommés un statut plus élevé. À la faveur de nouvelles « crises de croissance », notamment en 1998 et 2002, de nouveaux rôles furent spécifiés, et de nouveaux outils techniques adoptés.
En 2002, Linus Torvalds commença ainsi officiellement à utiliser un système de gestion de versions (Source Code Management Systems)2 plus puissant, nommé Bitkeeper.
La nature « propriétaire » de cet outil fut cependant à la source de nombreuses controverses, pour savoir si un logiciel non libre pouvait être utilisé pour faire du logiciel libre1. Bitkeeper fut finalement abandonné en 2005, et remplacé par un logiciel libre développé par Linus Torvalds lui-même : Git.
1 Cf. Steven WEBER, op. cit., p. 91.
2 Les systèmes de gestion de versions facilitent la coordination des développeurs, grâce au suivi des versions concurrentes du code source. Ils rendent par exemple plus aisée la gestion des modifications apportées de manière simultanée sur une même partie du code source. Ils peuvent aussi permettre de limiter le nombre de personnes auxquelles est accordée l’autorisation de modifier directement le code source (« commiter » en langage développeur). Techniquement, les systèmes de gestion de versions les plus courants dans les années 1990, comme CVS (Concurrent Versions System), étaient centralisés, c’est-à-dire reposaient sur un serveur dans lequel les développeurs « poussaient » leurs patches. Aujourd’hui, les logiciels les plus utilisés comme Git sont décentralisés, ce qui permet à chacun de « tirer » vers lui les nouveaux patches et ouvre de nouvelles possibilités.
L’expansion quasi continue de Linux n’a ainsi cessé de mettre à l’épreuve les procédures de coordination existantes. Aujourd’hui, une nouvelle version de Linux sort tous les trois mois, et chacune d’entre elles réunit les contributions d’environ trois mille développeurs à travers le monde, dont une grande majorité est salariée par des entreprises du secteur informatique2.
Par ailleurs la volonté d’adapter le noyau Linux au rythme effréné d’apparition de nouvelles technologies et de nouveaux protocoles, notamment dans le domaine de « l’embarqué » (smartphones, tablettes numériques, etc.), a entraîné une inflation parfois difficilement maîtrisable du nombre de lignes de code à intégrer3.
La réponse organisationnelle apportée à ces contraintes se présente aujourd’hui comme un mélange subtil de hiérarchie et de décentralisation, résultat des différents ajustements opérés depuis vingt ans.
Chaque développeur qui souhaite proposer un patch commence par l’envoyer sur une liste de diffusion dédiée à la section de code sur laquelle porte ses modifications. Durant deux semaines environ, le patch y est discuté et corrigé, au cours de ce que les développeurs décrivent souvent comme un « processus itératif ».
Au terme de celui-ci, lorsqu’un consensus émerge pour estimer le patch satisfaisant, le mainteneur en charge de la section le stocke dans son système de gestion de versions Git4.
Puis, tous les trois mois environ, lorsqu’une nouvelle version de Linux doit sortir, s’ouvre la « fenêtre de merge ». Les mainteneurs qui ont mis en attente les patches qu’ils ont reçus les renvoient alors à un second mainteneur en charge d’une section de code plus étendue, qui fait lui-même remonter les patches jusqu’au sommet de la pyramide.
1 Pour plus de précisions, voir Christopher KELTY, Two Bits, op. cit., p. 233-235.
2 Il existe des statistiques très précises sur l’origine des contributions au noyau. Celles-ci font apparaître que la part des bénévoles (hobbyists) se situe pour chaque version entre 10 et 20% du total des contributions, le reste étant pris en charge par des entreprises comme Red Hat, Intel, IBM, Novell et même Microsoft ! [Cf. « Linux Kernel Patch Statistic », en ligne : http://www.remword.com/kps_result/ (consulté le 02/09/2011)]. Par ailleurs, la Linux Foundation créée en 2007 réunit au sein d’une même structure toutes les principales entreprises qui ont un intérêt au développement de Linux. Elle paye Linus Torvalds et d’autres core developers du projet, protége la marque Linux, et essaye de favoriser l’adoption de normes techniques de standardisation entre industriels. Cf. http://www.linuxfoundation.org/ (consulté le 02/09/2011).
3 Voir par exemple : Cyrille CHAUSSON, « ARM et Linux : une pagaille dans la communauté du noyau », Le Mag IT, 20 juin 2011, en ligne : http://www.lemagit.fr/article/mobilite-linux-arm-embarque/8977/1/arm-linux-une-pagaille-dans-communaute-noyau/ (consulté le 01/09/2011).
4 En cas de conflit sur un patch, le mainteneur peut aussi avoir un rôle d’arbitre, mais le consensus demeure de loin le cas le plus général.
Le nombre d’échelons hiérarchiques à parcourir varie selon les parties du code en jeu. Il peut arriver que des portions de code très spécifiques n’aient pas de mainteneur attitré, et des corrections de bogues particulièrement critiques peuvent par ailleurs remonter directement au sommet sans étapes intermédiaires.
À l’autre extrême, certaines contributions sont susceptibles de passer par quatre niveaux hiérarchiques. Dans tous les cas, le « chemin » parcouru doit être aisément traçable. Chaque patch est ainsi signé par son auteur, mais aussi par les différents mainteneurs entre les mains desquels il est passé.
Peuvent ainsi y figurer des mentions telles que « tested by », « reviewed by » ou « acknowledged by », ajoutées par les personnes impliquées dans son évaluation.
Au sommet et au terme de ce processus ascendant (bottom-up) trône encore aujourd’hui Linus Torvalds. Son rôle consiste essentiellement à fusionner (« merger ») tous les patches qui lui arrivent, afin que puisse sortir (être « releasée ») la nouvelle version de Linux.
Cela implique d’effectuer des arbitrages, par exemple quand plusieurs personnes ont travaillé sur une même portion de code, et qu’il est nécessaire d’éliminer certaines contributions. Le fait que Linus Torvalds ait le dernier mot sur les conflits n’ayant pas été réglés aux échelons inférieurs explique qu’on lui ait attribué, avec une certaine dose d’humour, le titre de « dictateur bienveillant » (benevolent dictator)1.
Il serait toutefois plus juste de décrire son rôle comme celui d’un manager. Linus Torvalds a ainsi un pouvoir de décision sur les changements intégrant in fine le noyau Linux, mais c’est surtout lui qui « insuffle la direction générale du projet »2, en mettant en lumière ses principaux problèmes et en établissant des priorités de développement.
Il est également une des seules personnes (avec quelques core developers) à posséder une vision d’ensemble du code, bien qu’il ne connaisse plus dans le détail toutes les sections, chose aujourd’hui humainement impossible du fait de la taille du projet.
Des commentateurs ont vu en Linus Torvalds un mélange étonnant de charisme et d’auto-dérision3 que l’on pourrait également décrire comme un alliage entre qualités managériales et traits spécifiques à la culture hacker.
Ainsi les normes en vigueur parmi les développeurs exigeant que les décisions venues « d’en haut » soient expliquées dans le langage de la rationalité technique pour que chacun puisse juger de leur bien-fondé, Linus Torvalds s’est toujours efforcé d’argumenter ses choix de développement.
Par ailleurs, il a toujours su déléguer le travail, et minore régulièrement l’importance de sa contribution au projet. Il veille par exemple à envelopper nombre de ses décisions de traits d’humour dirigés contre lui-même, dans un mélange d’humilité plus ou moins jouée et d’auto-dérision assez caractéristique du monde hacker1.
Cela n’exclut pas non plus quelques violentes colères, ainsi qu’un langage parfois direct et peu porté sur les circonvolutions lorsqu’il s’agit de faire entendre certains choix techniques. Cette violence verbale occasionnelle est toutefois tolérée, notamment car le pouvoir de fait de Linus Torvalds n’est pas vu comme étant pas exercé pour lui-même, mais comme le moyen de favoriser la production du meilleur logiciel possible2.
1 Cette expression est assez courante, et elle a également été employée pour d’autres créateurs de projets « libres » qui continuent à en assumer le leadership : Guido van Rossum pour Python, ou Mark Shuttleworth d’Ubuntu, lequel se qualifie de « dictateur bienveillant auto-proclamé à vie » (self-appointed benevolent dictator for life).
2 Simon GUINOT, entretien cité.
3 Cf. Steven WEBER, op. cit., p. 90.
Linus Torvalds n’a ainsi cessé d’inspirer le respect parmi les développeurs, du fait de ses compétences d’informaticien, de ses qualités de meneur d’hommes et de la justesse de sa « vision »3.
Eben Moglen a eu des mots sans doute très justes, en écrivant qu’il avait réussi « avec un style génialement efficace » à maintenir « la direction globale sans refroidir l’enthousiasme »4. Il est assez frappant de mettre cette description en regard avec la caractérisation du nouveau management proposée par Luc Boltanski et Ève Chiapello :
La vision […] assure l’engagement des travailleurs sans recourir à la force en donnant du sens au travail de chacun. Grâce à ce sens partagé auquel tous adhèrent, chacun sait ce qu’il a à faire sans qu’on ait à le lui commander.
Une direction est fermement imprimée sans avoir recours à des ordres et le personnel peut continuer à s’auto-organiser.
Rien ne lui est imposé parce qu’il adhère au projet. Le point clé de ce dispositif est le leader qui est précisément celui qui sait avoir une vision, la transmettre et y faire adhérer les autres.5
1 Steven Weber écrit ainsi : « Le hacker n’est pas censé se mettre en avant aux dépens des autres; en fait, la norme est d’être humble en apparence, et de se rabaisser (si possible de façon humoristique). La vantardise n’est pas tolérée : la norme est que votre travail parle pour vous » (Steven WEBER, op. cit., p. 140).
2 Linus Torvalds a du reste lui-même toujours présenté les choses en ce sens : « Le seul contrôle que j’ai gardé sur Linux tient au fait que je le connais mieux que n’importe qui » (Linus Torvalds, cité par Steven WEBER, Ibid., p. 90). Peut-être ne peut-on néanmoins totalement écarter l’hypothèse que le goût du pouvoir ait pu constituer une motivation psychologique pour Linus Torvalds. Quoi qu’il en soit, cette question est ici de peu d’intérêt. Il nous semble avant tout important de souligner que la recherche du « pouvoir pour le pouvoir » est étrangère aux représentations des hackers. Le pouvoir n’est pour eux tolérable que s’il n’est pas une fin en soi, mais un moyen d’atteindre un objectif auquel ils accordent de la valeur, par exemple la production d’un bon logiciel.
3 Cf. Steven WEBER, op. cit., p. 90.
4 Eben MOGLEN, « L’anarchisme triomphant : le logiciel libre et la mort du copyright », op. cit..
5 Luc BOLTANSKI et Ève CHIAPELLO, Le nouvel esprit du capitalisme, op. cit., p. 119.
Linus Torvalds semble ainsi être une incarnation quasi parfaite de l’idéal mis en avant par le nouveau management. Il est précisément cet homme dont la « vision » et la puissance de conviction assurent que les contributeurs s’investissent dans le projet, sans qu’il soit besoin de recourir pour cela à des formes de contraintes explicites.
Son leadership demeure en effet soumis à son acceptation volontaire et renouvelée par les développeurs. Comme tout projet de logiciel libre, Linux est toujours sous la menace du fork : du fait des quatre « libertés », quiconque n’est pas satisfait de la tournure prise par le projet est susceptible à tout moment de copier le code source, et de lancer un autre projet avec d’autres choix techniques et une autre organisation du travail1.
Une telle scission est sans doute rendue plus difficile du fait de la complexité actuelle de Linux et de l’enjeu industriel considérable qu’il représente pour nombre d’entreprises, elle n’en demeure pas moins possible que ce soit pour des motifs personnels ou pour des raisons techniques, comme l’a montré récemment le fork initié pour le développement d’Android, un système d’exploitation pour smartphones fondé sur le noyau Linux.
Le projet de développement du noyau Linux est donc depuis le milieu des années 1990 organisé de façon hiérarchique, et il a à sa tête un leader charismatique en la personne de Linus Torvalds.
Cependant, il s’agit d’une hiérarchie d’un genre particulier, puisqu’elle peut être décrite comme « volontaire »2, c’est-à-dire librement acceptée par les développeurs, auxquels s’offre toujours la possibilité du fork.
Cette acceptation est étroitement tributaire du fait que les personnes dotées de positions éminentes le sont en fonction de leurs mérites techniques.
De même, le statut privilégié de Linus Torvalds tient à la reconnaissance renouvelée de ses compétences, et à l’adhésion qu’il a su susciter parmi les programmeurs et les entreprises intéressés aux développements de Linux.
En cela, l’organisation en vigueur dans le projet renvoie à un mixte entre les valeurs méritocratiques caractéristiques des communautés techniciennes et les mécanismes de mobilisation mis en avant par le nouveau management.
1 La possibilité du fork est considérée par de nombreux développeurs comme l’essence même du logiciel libre. Linus Torvalds affirme ainsi : « Je pense que les forks sont une bonne chose, ils ne me rendent pas triste. Pas mal de développement dans Linux s’est fait via des forks, et c’est la seule manière de continuer à avoir des développeurs intègres – la menace que quelqu’un d’autre puisse faire un meilleur travail et mieux satisfaire le marché en faisant les choses de façon différente. Le but même de l’open source, pour moi, est vraiment la possibilité de «forker » (mais aussi la possibilité pour toutes les parties de réintégrer le contenu qui a été » forké «, s’il s’avère que c’était le «forkeur » qui avait eu raison !)» (Linus TORVALDS, « L’interview anniversaire des vingt ans du noyau », op. cit.). L’histoire du logiciel libre est du reste jalonnée de forks. Parmi les plus célèbres, on peut citer ceux qui ont abouti au développement de différentes versions de BSD par des communautés distinctes : FreeBSD, NetBSD, OpenBSD. La carte graphique des distributions Linux met quant à elle en évidence de façon frappante tous les forks connus par les différentes distributions Linux, et l’arborescence extrêmement complexe qui en résulte (voir dans la partie « Documents » : Document 4. Les différents forks de GNU/Linux).
2 Cf. Felix STALDER, « Open Source Projects as Voluntary Hierarchies », Global Media and Communication, Vol 2(2), été 2006, en ligne : http://felix.openflows.com/html/weber_review.html (consulté le 14/11/2011).
