Quand on parle de logiciel libre, on a souvent en tête l'exemple de GNU/Linux, à l'image du titre du journal dans lequel sont publiées ces lignes. Ils ne sont qu'une partie des centaines de milliers de projets existants, portés par des équipes de développement qui varient d'une seule personne (la très grande majorité) à plusieurs centaines de développeurs (une poignée de projets). D'autres domaines de la connaissance ont vu l'émergence de projets collaboratifs, organisant la contribution volontaire de collaborateurs sur Internet. Wikipédia est sans doute le plus emblématique, mais les projets d'« open hardware », d'encyclopédies plus spécialisées comme l'encyclopédie des espèces (Encyclopedia of Life, http://eol.org/), de la botanique (http://www.tela-botanica.org), jusqu'aux substituts alimentaires (Soylent, http://diy.soylent.me/recipes), témoignent de la variété de cette dynamique.
Soulignons tout de suite l'importance d'Internet dans cette dynamique : parce que ce réseau permet de mettre en contact, à un niveau mondial (au moins tous ceux qui partagent une même langue), il permet de constituer des groupes de « pairs », de personnes partageant la même passion ou les mêmes objectifs. À condition, bien sûr, que ces groupes puissent échanger et créer en ligne. Les projets basés sur une production écrite de connaissance (logiciel, textes encyclopédiques, recettes) sont évidemment favorisés par ce média (le lecteur intéressé par creuser ce point pourra consulter l'ouvrage de mes collègues, G. Dang Nguyen et S. Dejean, particulièrement les chapitres 3 et 4 [1]).
Reste que, pour un économiste, le fait de contribuer à un projet dont on peut bénéficier « gratuitement » intrigue. La réponse, corroborée par de nombreuses études, dans différentes communautés de production de connaissance - logiciel libre, Wikipédia, botanique, géomatique, pour ne citer que celles que je connais - est simple. Tout d'abord, seule une minorité des utilisateurs participe, et seule une minorité de projets attire suffisamment de contributeurs pour être des projets collectifs. Ensuite, les participants s'engagent parce que cela leur apporte des bénéfices immédiats : soit parce qu'ils ont besoin de développer le logiciel/d'écrire un document de toute façon, et que le faire dans le cadre d'un projet existant est plus simple (l'architecture existe déjà, il y aura des retours utilisateur, la contribution sera maintenue, etc.) ; soit parce que cela représente un challenge intellectuel, permet d'apprendre quelque chose ; dans tous les cas, cet engagement est perçu comme amusant, stimulant. Ensuite, pour les plus investis, dans le temps et en termes de volume de contribution, d'autres raisons poussent à ne pas arrêter : une dimension sociale (on connaît des personnes, avec qui on travaille, même virtuellement), et, parfois, une dimension professionnelle, notamment dans le logiciel libre : ce qu'on fait dans les communautés est reconnu par le marché du travail et permet d'accéder à des postes, des projets plus intéressants. Arrêter le projet voudrait dire renoncer à ces « connexions », abandonner des collègues, des camarades, renoncer à un statut social d'expert, ce qui est toujours difficile.
Ces différents rôles, et la taille respective de la population qui les endosse, sont souvent représentés sous la forme d'un schéma en « oignon » (figure 1) : au centre, quelques développeurs très investis, qui sont aussi ceux qui réalisent la plupart des développements, et à la périphérie les utilisateurs, bien plus nombreux.
Fig. 1 : Organisation d'un projet libre
La flèche représente le parcours « type » d'un contributeur, ou « carrière » (au sens sociologique du mot, http://sociologie.revues.org/1197), qui commence parfois par une simple utilisation, avant de proposer des modifications et, pour certains, de s'engager encore plus avant dans la production. Cette carrière peut prendre plusieurs mois, mais est souvent assez rapide pour les plus curieux ou les plus engagés.
Le graphique met en avant une autre caractéristique de ces communautés : leur organisation. Ouvert ne veut pas dire anarchique, ou sans hiérarchie. Il existe, dans toutes ces communautés de production, dès qu'elles dépassent l'individu unique, des règles, plus ou moins explicites (comme la « constitution » du projet Debian, https://www.debian.org/devel/constitution.fr.html), et une hiérarchie entre les personnes : certains ont droit de contribution, d'autres seulement de proposition, certains ont droit d'exclusion des membres, etc. Rappelons que la règle des « 20/80 », ou principe de Pareto, s'applique : les contributeurs principaux sont peu nombreux (20 % des utilisateurs) et assurent pourtant l'essentiel de la production (80 %), les autres développeurs et les testeurs étant là en support. Dans les très gros projets, comme Linux, ou Apache, cette organisation peut être répétée dans des sous-projets qui s'occupent chacun d'un module, ce qui permet de maintenir des équipes de petite taille dans chaque module. Un point faible de cette organisation est qu'il faut être précis sur les communications entre les modules. Le fait que le code soit ouvert facilite cette coordination, mais il existe aussi des développeurs qui appartiennent à plusieurs projets/modules et qui assurent la transmission d'information. Des discussions de planification des évolutions majeures doivent être organisées, afin de coordonner les feuilles de route de ces différents sous-projets. Enfin, le développement d'outils de travail coopératif permettant de synchroniser les contributions et les versions est évidemment un facteur clef du succès de ces organisations (Subversion, ou SVN, GitHub pour les plus connus). Il est amusant de noter que, mis à part le fait que les personnes sont volontaires et choisissent où elles veulent contribuer - différence évidemment fondamentale - toute cette organisation est très proche de celle développée par Microsoft dans les années 1980 (voir l'analyse de Cusumano et Standley [2]).
L'autre point qui rapproche les organisations de production du logiciel libre des entreprises est que, toujours pour les projets les plus connus, l'implication des entreprises est de plus en plus importante. On sait par exemple que, au moins depuis la fin des années 1990, pour la grande majorité des développeurs d'Apache, participer au développement fait partie de leur travail [3]. De même, les personnes présidant les groupes de travail ou appartenant au bureau de la fondation Apache sont aussi, pour la plupart, salariées des grandes entreprises de l'informatique, comme IBM.
Pour conclure, le mouvement du logiciel libre, et plus généralement, des communautés en ligne produisant de la connaissance, repose sur le volontariat et il est unique par sa taille, mais aussi par son impact sur certaines industries (informatique, mais aussi encyclopédies). Il est favorisé par le fait que les personnes échangent des documents écrits, qui sont en même temps l'objet de la coopération et le produit final (contrairement au mouvement open hardware, par exemple, il n'y a pas besoin d'usine pour obtenir le produit final). Mais il s'ancre aussi dans des pratiques humaines bien plus anciennes :
- sur la participation, les motivations sont proches de celles qu'on trouve chez les participants aux associations (un de mes amis faisait même l'analogie avec le mouvement des « scouts », ou éclaireurs) ;
- sur l'organisation, on retrouve les règles en vigueur dans la gestion par des communautés de biens communs locaux, si bien analysées par Elinor Ostrom [4], et plus généralement des actions collectives (Marwell et Oliver [5]), et en termes d'organisation de la production, sur des organisations industrielles.
Enfin, dans la confrontation et le métissage avec ces organisations industrielles, qui interviennent quand les produits se diffusent, ces groupes s'affirment, se structurent et s'institutionnalisent. Les raisons et les modalités d'implication des entreprises feront l'objet du prochain article.
Références
[1] Dang Nguyen G. et Dejean S., « Le numérique. Économie du partage et des transactions », Economica, 2014.
[2] Cusumano M., et Standley A., « Beyond the waterfall: software development at Microsoft », Document de travail No 3844-95, Massachusetts Institute of Technology (MIT), Sloan School of Management, 1995.
[3] Lakhani K. et von Hippel E., « How open source software works: “free” user-to-user assistance », Research Policy, Volume 32, Issue 6, June 2003, p. 923 à 943.
[4] Hess C. et Elinor O. (éditrices), « Understanding Knowledge as a Commons. From Theory to Practice », MIT Press, 2006.
[5] Marwell G. et Oliver P., « The Critical Mass in Collective Action », Cambridge University Press, 1993.
