Linux : méritocratie et vision managériale

  1. L’utopie du logiciel libre, le mouvement du free software
  2. L’utopie comme fiction, mystificateur, idéologie…
  3. L’utopie concrète d’Ernst Bloch
  4. L’utopie et le mythe d’une société réconciliée
  5. L’utopie et l’imaginaire social
  6. Présent et futur utopique – Quelles utopies concrètes ?
  7. Qu’est-ce qu’un logiciel libre ?
  8. L’extension de la portée du logiciel libre
  9. Libre circulation de l’information, Logiciel libre et Utopie
  10. Les critiques de l’utopie de la communication
  11. La conspiration de l’utopie et de l’idéologie
  12. Le logiciel libre comme utopie concrète
  13. Penser l’utopie sans renoncer à la critique
  14. Les difficultés méthodologiques – l’utopie du logiciel libre
  15. Richard Stallman : hacker et utopiste
  16. La naissance de l’industrie du logiciel
  17. Le laboratoire d’intelligence artificielle du MIT
  18. La naissance du projet GNU
  19. Le copyleft : le meilleur hack de Richard Stallman
  20. La dimension utopique de la création du logiciel libre
  21. Le logiciel libre : Idéologie ou Utopie ?
  22. La naissance du mouvement open source
  23. L’open source : le pragmatisme contre l’idéologie
  24. L’idéologue n’est pas nécessairement celui qu’on croit
  25. Open source et Free software : Modes d’extension du logiciel libre
  26. Open source et Nouveau management de l’intelligence collective
  27. De l’open source au crowdsourcing
  28. L’open source et le self-entrepreneuriat
  29. Le modèle de l’intelligence collective
  30. Le modèle de l’innovation distribuée
  31. Mythologie de la collaboration distribuée et Mouvement open source
  32. Linux : méritocratie et vision managériale
  33. Debian : une communauté de libristes
  34. Wikipédia : Méandres d’une régulation procédurale par les pairs
  35. Modèle et idéologie – Collectifs du logiciel libre
  36. Extension du domaine de la lutte contre les brevets logiciels
  37. Le débat sur la brevetabilité des logiciels
  38. L’affaire DeCSS et la lutte contre les DRM
  39. De DADVSI à Hadopi en France
  40. L’opposition à ACTA : aboutissement des luttes des années 2000
  41. L’émergence du lobbying citoyen
  42. Le mouvement du logiciel libre comme public récursif
  43. La transparence : entre mythe et idéologie – le logiciel libre
  44. Free Software, Free Society ? – L’utopie du logiciel libre
  45. L’influence politique et intellectuelle – Le logiciel libre
  46. La découverte du logiciel libre par une partie de la gauche radicale
  47. Les enjeux du mouvement des Creative Commons
  48. Propriété intellectuelle et Nouvelles mobilisations du logiciel libre
  49. La coalition des biens communs et le mouvement du logiciel libre
  50. L’unification autour de la notion d’information
  51. Une critique interne, Partisans des biens communs
  52. Les logiciels et les semences en tant que biens informationnels
  53. L’information et la connaissance : la distinction conceptuelle
  54. L’universalité et la communauté, et le logiciel libre
  55. Le récit du general intellect
  56. Un nouveau capitalisme parasitaire – cognitif et informationnel
  57. Capitalisme parasitaire et Nouvelles contradictions
  58. General intellect et sortie du capitalisme
  59. Le logiciel libre comme modèle productif
  60. Le logiciel libre : emblème du présent, embryon de l’avenir
  61. Le revenu d’existence : une grande proposition utopique ?
  62. Le récit du general intellect : un utopisme (néo-)marxiste
  63. Le récit des biens communs
  64. Modifications des droits de propriété intellectuelle depuis 30 ans
  65. Les 3 effets du renforcement de la propriété intellectuelle
  66. Le logiciel libre, matrice du mouvement pour les biens communs
  67. Une approche jeffersonienne de la propriété intellectuelle
  68. Un 2ième mouvement des enclosures, Défenseurs des biens communs
  69. L’idéal communautaire de la contre-culture californienne
  70. Un libéralisme communautarien, le récit des biens communs
  71. Le récit des biens communs : un utopisme libéral
  72. La société technologique et les enseignements du logiciel libre
  73. L’auto-organisation de la société civile comme idéal utopique
  74. L’État, le marché et l’utopie

Pratiques et idéologie – Chapitre 4.

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 n
ouvelles « 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 occasi
onnelle 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).

L’utopie du logiciel libre, le mouvement du free software

Thèse pour l’obtention du grade de docteur de l’Université Paris 1 – Discipline : sociologie

Université Paris 1 Panthéon/Sorbonne – École doctorale de philosophie

Cliquez sur suivant article pour lire la suivante partie de ce mémoire:

Abonnez-vous!
Inscrivez-vous gratuitement à la Newsletter et accédez à des milliers des mémoires de fin d’études !
Publier son mémoire!
WikiMemoires - Publier son mémoire de fin d’études !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *