CHAPITRE III-LA COORDINATION DANS LES COMMUNAUTES OPEN
Section 2. La coordination au sein des communautés Open Source
II. A Légitimation du pouvoir et contrôle des contributions
Dans une étude sur la gouvernance des projets Open Source, Markus (2007) propose une définition selon laquelle les mécanismes de coordination dans l‘Open Source sont perçus comme des solutions aux problèmes de contrôle et plus généralement des solutions pour gérer le développement du travail:
« In the operational coordination literature, OSS governance is understood as a solution to [… the problem of] loss of operational control and the solution is techniques for managing the process of OSS development work. » (Markus, 2007, p. 156)
Comme nous l‘avons souligné dans le second chapitre, la coordination dans les communautés Open Source implique une nature particulière de contrôle qui peut être centralisé au niveau d‘un leader ou d‘une équipe leader (Raymond, 1998 ; Lerner et Tirole, 2002) mais doit être constamment reproduite et légitimée par ceux qui constituent « les couches inférieures » de la pyramide. La légitimation n‘est pas un concept statique, et doit être renouvelé à chaque fois (O‘Mahony et Ferraro, 2007). D‘après O‘Mahony et Ferraro (2007), la structure de gouvernance des projets Open Source tel que Debain émerge progressivement et évolue, en fonction de la complexité du projet. La coordination de l‘activité se base ainsi sur une structure d‘autorité ou de contrôle qui émerge progressivement, mais encore une fois basée sur des mécanismes de légitimation.
98 dans la communauté. Certains ont un rôle plus important que d‘autres et influent par leurs décisions sur le devenir du projet. Ces contributeurs assurent la coordination du projet et contrôle son développement. L‘étude de Mockus et al. (2000) sur le projet Apache montre qu‘un noyau ou une équipe de petite taille (24 personnes) gère l‘ensemble du projet. Nous avons également observé que l‘intégration des contributions au code source du projet Mozilla n‘est pas systématique mais nécessite un haut niveau de filtrage. Le filtrage est assuré par les responsables de modules qui veillent a ce que la version du code soie cohérente (cf. chapitreI-section 2). Moon et Sproull (2000) observent la même structure dans le projet Linux, puisque toute intégration de modification doit être validée par les responsables, et parfois même par le fondateur du projet Linus Thorvald lorsque les modifications concernent le noyau central du système d‘exploitation.
Nous avons montré que le développement Open Source repose sur les contributions libres de participants dispersés géographiquement. Cependant, la coordination de l‘activité nécessite un système de contrôle ou de filtrage de contributions assuré par les leaders ou les responsables des projets. Ces responsables ont pour fonction de décider quels traits devraient être intégrés dans le logiciel, quand et comment autoriser le changement du code source, et donner l‘accès pour modifier le code (Raymond, 1999) : «Core group membership can bestow some rights, including deciding what features should be integrated in the release of the software, when and how to empower other code maintainers, or to "pass the baton" to the next volunteer ». (Raymond 1999, p 25)
Les responsables de projets disposent, selon Crowston et al. (2006), d‘une autorité ou d‘un pouvoir informel dont la légitimité n‘est pas définie par une structure formelle mais par des mécanismes informels comme la réputation, les compétences et l‘intensité des efforts. La fonction de l‘équipe leader ressemble ainsi à celles d‘une organisation traditionnelle. Néanmoins, le développement Open Source repose sur le principe de distribution du pouvoir (Crowston et al., 2006).En effet, ce principe donne la possibilité au contributeur externe (la périphérie) de devenir responsable par un mécanisme fondé sur les compétences (Crowston et al., 2006) :
« In comparison to traditional organizations, more people can share power and be involved in group activities». (Crowston et al. ,2006, p. 567)
La distribution du pouvoir se fonde sur l‘hypothèse selon laquelle la participation des utilisateurs (la périphérie) joue un rôle très important dans l‘activité de développement
Open Source (Heckman et al., 2006). Selon Heckman et al. (2006), les utilisateurs contribuent au projet dans de multiples chemins, et deviennent une source cruciale de recrutement potentiel. Les intérêts des utilisateurs doivent, cependant correspondre aux objectifs du projet pour assurer son succès. La manière de gérer la relation entre les exigences de la périphérie et les valeurs des équipes représente donc un grand défi qui amène à s‘interroger sur le degré de distribution du pouvoir entre la périphérie et l‘équipe de développement.
D‘après Crowston et al. (2006), un « pouvoir abusif » de la part des leaders, ou des décisions prises sur la base de préférences personnelles peut décourager les contributeurs (la périphérie) de s‘investir plus dans la communauté:
« The first and most significant change firms make to FLOSS projects is to the authority structure by controlling decisions such as access to mailing lists, which code contributions are accepted and combined into the project and who should be empowered to be subproject leader or succeed the current leaders. As a result, volunteers may feel detached from open-source projects because they are not included in the decision making process. » (Crowston et al., 2006)
Inversement, l‘absence de leadership dans le cadre d‘un développement distribuée rend la gestion de l‘activité difficile. Lorsque les projets sont dirigés informellement, les contributeurs communiquent essentiellement de manière textuelle et les utilisateurs sont impliqués fortement dans l‘activité du développement, le conflit est inévitable dans le cadre de développement logiciel. Le rôle des leaders est donc de résoudre les conflits, en assurant la cohésion du groupe et son efficacité.