Comment mobiliser et gérer une communauté autour d’un projet ?

Nous vous proposons aujourd'hui un compte-rendu d'un événement qui s'est tenu vendredi 5 mars 2010 à La Cantine, sur le thème : Les modèles de développement et de collaboration au sein des projets Open Source.

L’événement a été animé par Charles-H. Schulz d'Ars Aperta, avec les invités :

- Louis Montagne, AF83.
Louis dirige af83 et Bearstech, il est secrétaire de Silicon Sentier et président de Collibri, la communauté Web2 et Logiciel Libre de Cap Digital.

- Tristan Nitot, Mozilla Europe
Tristan est fondateur et président de l’association Mozilla Europe depuis 2003.

- Nicolas Barcet, Ubuntu (Canonical)
Nicolas fait partie de Canonical, la société derrière Ubuntu. Nicolas est en charge de la version serveur d’Ubuntu.

- John Lejeune, Hackable Devices
John gère une communauté autour d’une e-boutique spécialisée dans le matériel librement modifiable.

- Luis Belmar, Itaapy
Luis s’occupe de recherche et développement chez Itaapy et il est le directeur scientifique de Caritat.

Voici une retranscription des thèmes évoqués pendant la matinée :

Comment gère-t-on une communauté ?

Louis Montagne : Sur nos projets technologiques financés par la région, notre gestion des communautés commence par la communication avec nos entreprises partenaires. Nous sommes nous-mêmes les premiers membres de notre communauté, une communauté de chefs de projets en somme.

Tristan Nitot : Il faut voir que la communauté est au service d’elle-même, au service de son idéal. Dans notre activité, nous ne faisons pas la différence entre Mozilla et la communauté Mozilla car l’un est issu de l’autre et nous poursuivons les mêmes objectifs cités dans le Mozilla Manifesto. On ne retrouve donc pas la dichotomie fréquente entre les objectifs financiers de l’entreprise et les valeurs des open-sourceurs. Nous formons tous ensemble une communauté d’entrepreneurs sociaux.

Luis Belmar : nous travaillons en open-source GPL v3 car nous croyons fondamentalement à l’efficacité supérieure du travail collaboratif. Il ne s’agit pas seulement de profiter du travail des autres mais de participer à une dynamique globale. Pour créer une communauté, il y a des outils à maîtriser : la politesse sociale, l’énergie, communiquer sur IRC, interroger la communauté, faire des retours, maintenir des listes de diffusion, un portail, un wiki, des trackers du type bugzilla… Ce sont les besoins des participants qui font bouger la communauté mais il faut également leur fournir les outils qu’ils réclament.

Nicolas Barcet : Publier du code n’est pas suffisant pour créer une communauté, il faut également insuffler un code de conduite et expliquer aux personnes comment interagir. Il faut bien sûr documenter le code et fournir des outils de travail collaboratif, mais cela ne suffit pas. Dans une communauté, chacun a ses propres motivations (satisfaire un besoin, envie de gloire, rejoindre des amis déjà engagés dans le projet, etc.). C’est par la capacité à percevoir ces motivations, à les respecter et y consacrer des ressources (au moins une personne à mi-temps) qu’on peut cristalliser et faire vivre la communauté. C’est ainsi qu’on donnera de la cohérence au projet et que la communauté se mobilisera. Par ailleurs, le projet doit rester ouvert, l’entreprise ne devrait pas tenter de garder la mainmise dessus en interne. Elle doit laisser une marge de manœuvre à la communauté car elle n’est pas un simple exécutant. Enfin, il faut rendre la communauté accessible au plus grand nombre en établissant des tâches faisables pour que chacun puisse participer à son échelle.

Tristan Nitot : Chaque participant doit pouvoir « grandir » en étant dans la communauté, sur le plan personnel ou professionnel. Ce n’est qu’une juste contrepartie du travail du bénévole et il appartient à l’entreprise de réfléchir à la façon de favoriser ce retour.

John Lejeune : Appartenir et participer au travail d’une communauté est très chronophage. C’est avant tout un système de valeur qui justifie ce travail bénévole : par exemple parce que l’on croit à l’open source, à l’intérêt général. L’entreprise doit donc posséder ces valeurs aussi pour collaborer avec la communauté.

Charles Schulz : Pour nuancer les termes utilisés, disons que l’on ne « gère » pas une communauté mais plutôt les ressources mises à sa disposition. La communauté est une entité qui vit par elle-même en gravitant autour de ces ressources.

Quelle point commun ou différence entre la gestion de projet en entreprise et en communauté ?

Nicolas Barcet : Rappelons que les pratiques Agile sont originellement issues de la gestion de communautés.

Rappel sur le principe des méthodes Agile : dans les méthodes classiques, on définit au début du projet ce qu’on souhaite obtenir à la fin, afin de réduire l’incertitude grâce à un plan de route fixe. Le projet est alors découpé en phases, etc. Mais en réalité, les besoins continuent d’évoluer au fur et à mesure que le projet avance. En fin de projet, on obtient donc un résultat qui est devenu en partie obsolète et qui, de plus, nécessiterait des ajouts pour satisfaire les besoins qui ont émergé entre-temps. Les méthodes Agile incitent donc à prévoir l’évolution du projet sur une phase de temps beaucoup plus courte, afin de pouvoir s’adapter en temps réel aux besoins du client. Le cahier des charges est donc presque antinomique de la notion de communauté.

Tristant Nitot : Contrairement au travail en entreprise, dans une communauté, il est préférable d’opter pour des livraisons précoces et fréquentes (« release early, release often »). Quand bien même le code n’est pas encore fonctionnel ! Cela permet d’obtenir des retours des participants, mais aussi d’entretenir l’intérêt de la communauté. La fréquence est bien sûr à définir en fonction du projet. Par ailleurs, dans les projets communautaires comme en entreprise, il doit exister des points de contact (faire le lien entre les contributeurs) et d’autorité, des personnes qui correspondent au rôle du « manager ». Chez Mozilla, ce sont des experts désignés par module qui ont développé une légitimité après avoir démontré leurs capacités. C’est donc un manager qui a aussi les mains dans le cambouis et qui, finalement, a émergé grâce à un système de méritocratie.

Existe-t-il des critères d’évaluation des projets open-source ?

Nicolas Barcet et Luis Belmar : On peut évoquer la rapidité de correction de failles, la bonne conformité des licences au principe de l’open-source, les tests, la documentation… Mais fondamentalement, la productivité d’un projet open source reste une évaluation objective faite en fonction du sujet, de la concurrence, de l’environnement…

Tristan Nitot : Les projets open source ne sont pas fondamentalement axés sur la productivité, même si la concurrence avec d’autres navigateurs a parfois conduit à développer dans l’urgence des fonctionnalités avec du code sale. Néanmoins, les exigences en termes de qualité restent très fortes et la fondation met souvent des ressources (financières ou en temps de travail) dans les projets open source gravitant autour de Mozilla.

L’entreprise et l’open source : quel est l’objectif ?

Tristan Nitot : Mozilla est le fruit du croisement d’une base de code importante (Netscape) et d’une communauté d’internautes qui avait des attentes en matière de standards web. Dès le départ, Mozilla était destiné à évoluer dans le milieu open source, dans l’idéal de construire un « bien commun ». Ce bien commun, Firefox, n’est pas destiné à rapporter de l’argent en soi mais constitue une infrastructure qui permettra à l’ensemble de l’économie du web et au-delà de créer davantage de valeur.

Luis Belmar : Généralement, à la base, les sociétés qui travaillent sur de l’open source en partagent les valeurs. Mais si elles continuent de le faire, c’est parce qu’elles ont trouvé un modèle viable et qu’elles en ont besoin pour poursuivre leur activité.

Nicolas Barcet : la société Ubuntu est également fondamentalement liée aux valeurs d’open source et cela conditionne toute sa stratégie d’entreprise. La société investit en permanence dans le développement et atteint à peine l’équilibre budgétaire, alors qu’elle pourrait se concentrer sur les marchés plus matures et profitables. L’objectif financier étant toujours de dégager au moins les bénéfices nécessaires à la survie de la communauté.

Par ailleurs, si l’on voulait mesurer la qualité d’une communauté, on pourrait la comparer au pouvoir dont elle dispose sur la société. En effet, plus elle se développe et s’implique dans un projet, plus elle peut influencer la stratégie d’entreprise qui ne peut plus se passer d’elle. En conséquence, si l’on prend une marque comme Apple qui prend toutes ses décisions en interne : plutôt que d’une « communauté » Apple, ne devrait-on pas simplement parler d’un groupe de fans ?

Propos recueillis le 5 mars 09

• Louis Ameline's blog