Un guide Framabook pour les communautés

Une communauté, comment ça marche ?
Et surtout comment faire pour que ça marche bien, que ça s’épanouisse et que ça dure ?

Nous sommes bien placés pour le savoir à Framasoft, la vie quotidienne d’une communauté se fait le plus souvent en mode bazar — peut-être devrais-je dire à la gauloise — jusqu’à ce qu’une bonne volonté à l’esprit plus cartésien prenne en charge une mise en ordre efficace, avec processus, deadline et animation d’une équipe (nous appelons ça des « comités »). Heureusement notre projet pluriannuel et planétaire dégooglisons internet nous fixe les grandes lignes d’une action qui reste empirique au jour le jour. Heureusement aussi que nous pouvons compter sur vous pour nous propulser, car c’est ainsi que nous avançons.
Bref, nous avons beaucoup à apprendre du nouveau Framabook que nous vous présentons aujourd’hui, car il s’agit d’un ouvrage fondé sur l’expérience et des cas concrets, et dont la démarche est celle d’un guide pas à pas pour une gestion optimale d’une communauté autour d’un projet libre. Vous allez le découvrir dans ce précieux manuel, les trois compères qui l’ont conçu n’ont rien oublié, car tous les détails qu’ils abordent peuvent s’avérer décisifs pour une communauté.
Avant d’ouvrir le Framabook qui vous attend, faisons connaissance avec Patrick et les deux Stéphane qui nous viennent d’INRIA, nous en saurons plus sur leurs motivations et l’esprit dans lequel ils ont travaillé.

Vous publiez aujourd’hui un guide très complet et riche en recommandations sur la façon d’animer une communauté. Selon votre expérience, on innove plus facilement à partir d’organisations communautaires qu’à partir de structures verticales et officielles ?

Les communautés de pratique qui se construisent autour de projets ouverts font partie des structures humaines les plus fécondes en innovations que l’on connaisse. Je dirais que l’on innove plus facilement avec des structures de type communautaire, pair à pair, encore faut-il qu’elles soient dynamiques.

Une des clés de succès est de bien choisir son modèle de gouvernance. Le modèle de gouvernance en « approche descendante » (top down) est souvent un frein à l’émergence de nouveautés, c’est même un puissant stérilisateur d’innovation. Cependant, les organisations qui ont choisi ce modèle sont alors davantage utilisatrices et/ou consommatrices d’innovation… Il est important de collaborer aussi avec ces structures. Une fois que les projets ont pris de l’élan, elles peuvent avoir du sens car elles permettent d’institutionnaliser les innovations produites.

Je crois que ces deux modes d’organisation sont complémentaires, à la condition cependant de laisser les inventions germer puis se transformer en innovations selon leur mouvement naturel qui est bottom-up.

Et dans l’institut de haut niveau où vous travaillez, on est plutôt bottom-up ou top-down ?

Le modèle Inria est selon nous à la fois une structure top down et une structure bottom up. L’écosystème bottom up est constitué des chercheurs et ingénieurs de recherche alors que le top down est représenté par les équipes de valorisation. L’organisation bottom up (accompagnée d’actions encourageant la prise d’initiatives) facilite l’émergence de projets très divers et dont l’usage dans la société est insoupçonné (quel impact ?)… en somme la structure bottom up produit de l’innovation et la structure top down pioche dedans. Tel est le cas pour Inria, pas forcément pour les projets FLOSS…

Vous publiez un guide dont le sous-titre est « Animer une communauté autour d’un projet ouvert », c’est parce que vous trouvez que les communautés libristes ne sont pas bien « animées » ?
Pas du tout ! Il nous semblait d’une part que ce sujet n’était pas encore largement traité et d’autre part que la diffusion et la mise en commun de nos expériences pouvaient être utiles. Stéphane Ribas apporte, en tant qu’expert en management de communautés, une assistance à l’ensemble des équipes de recherche et aux projets de développement logiciel au sens large chez Inria. Comme la demande est bien trop large pour être traitée par un seul spécialiste, ce guide a été écrit pour tenter d’amplifier la diffusion des quelques principes de base de la gestion de communauté.

On sent une volonté d’éducation populaire à la lecture de ce guide, qui dépasse le seul cadre du développement logiciel…

Éduc pop… oui. On est animés par une motivation intrinsèque incroyable : transmettre le savoir et le savoir-faire, se rendre utiles. Disons qu’on se rend bien compte de l’utilité de ce que l’on fait et c’est extrêmement motivant.

Ce guide est le fruit d’un travail collaboratif de longue haleine, qu’il a fallu coordonner et mener à terme, pas trop compliqué ?

Stéphane Ribas — Eh bien mes deux collègues ont dû supporter mon hyperactivité pendant presque 6 ans… Les périodes de disponibilité et les phases de l’écriture n’étaient pas toujours les mêmes, du coup la plupart des solutions sont venues d’un effort de coordination : calage de journées de travail dédiées au guide, Skype, etc. Il faut dire que la rédaction de ce guide est venue se superposer à des vies déjà bien remplies…

Patrick Guillaud — Notre proximité et le partage quotidien de nos interrogations, préoccupations et parfois de nos succès nous ont permis de finalement partager une vision commune et cohérente à partir de trois prismes ou angles de vue un peu décalés.

Est-ce que le choix de Framabook comme éditeur découle de l’aspect collaboratif de ce guide ou y a-t-il d’autres raisons qui vous ont poussés à placer cet ouvrage dans les communs ?
Patrick G. — Je crois que l’une des raisons qui nous poussent à agir est justement le fait que nous sommes de fervents supporters de la philosophie du libre, car nous sommes convaincus de son efficacité. Il ne faut pas oublier non plus que nous avons la chance de travailler dans un institut public de recherche, ce qui nous place dans des conditions idéales pour mettre cette philosophie en action, même si l’on voit de plus en plus d’entreprises privées y venir également. Cependant, après des années à travailler dans ce domaine, je crois que nos convictions vont bien au-delà, et nous sommes sûrement davantage aujourd’hui des supporters du mouvement appelé openness … D’ailleurs les conseils prodigués dans le guide Logiciels et Objets Libres s’appliquent aussi à d’autres domaines. On a mis un peu beaucoup d’openness dans ce guide (désolé pour l’anglicisme).

Il ne faut pas empêcher la transmission du savoir et du savoir-faire. À l’époque de la recherche de phénomènes autour de l’électricité, certains « scientifiques » présentaient des expériences au public comme des phénomènes magiques. C’était une mise en scène sans grande explication sur la logique de fonctionnement, l’explication était réservée à une toute petite partie de l’élite. Une deuxième école de pensée existait déjà, elle avait pour objectif de transmettre ce savoir au plus grand nombre, de pratiquer une sorte de médiation scientifique, de vulgarisation de la science. C’est bien sûr dans cette démarche que s’inscrit notre travail.

Le choix de la triple licence : LAL 1.3, GNU FDL 1.3 et CC By-SA 3.0, c’est par gourmandise ou par militantisme ?

Patrick Guillaud — Gourmandise ou militantisme ? Si je revendique le premier terme sans complexe, j’associerais volontiers celui d’activisme au second. En effet, l’un des principes qui fondent nos activités est celui d’action dont je dirais même qu’il précède notre discours militant et nous permet de le construire. On aurait pu aussi remplacer gourmandise par recherche du plaisir et militantisme par conviction.

Plus sérieusement, comment et pourquoi avez-vous choisi ces licences ?
En fait, nous avons suivi les conseils de Framasoft, mais en même temps nous convaincre était facile : nous avons plusieurs éditeurs dans le monde de la recherche qui ont mis en place des licences qui ne favorisent pas si facilement le partage et la diffusion, ou ne laissent pas de place à la reconnaissance de l’auteur… Nous avons donc très naturellement accepté la proposition de Christophe.

Vous donnez dans cet ouvrage des interviews et des cas concrets qui sont intéressants et qui complètent utilement les recommandations théoriques. Mais chez Inria, qui est une très vaste structure collaborative, comment se passe « l’animation » de la communauté ?

Patrick G. — Au sein d’Inria l’animation des communautés (je le mets au pluriel parce qu’elles sont nombreuses) se faisait au gré des vents et des courants et dépendait entièrement du contexte : lorsque l’équipe comptait un leader, charismatique et bon manager, elle était parfaite, mais parfois c’était plus compliqué. Dans ce genre de cas, un brin de méthode — on appelle ça « les bonnes pratiques » — ne peut pas faire de mal. Et c’est la fonction principale de Stéphane Ribas que d’améliorer les choses en la matière. Cela ne permet certainement pas de tout régler partout, mais cela permet de limiter la casse dans certains contextes difficiles, et surtout, à travers des activités de diffusion et « d’évangélisation », cela peut aider significativement les communautés un peu livrées à elles-mêmes de monter en compétence sur ce sujet et donc de gagner en efficience.

Stéphane R. — Il faut aussi ajouter le rôle très important de Stéphane Ubéda et de son rôle au sein d’Inria en 2011, qui ont grandement facilité la mise en place d’un service autour de la gestion de communauté, de manière plus formelle que cela ne se pratiquait auparavant au sein de l’institut. Patrick était responsable de l’animation de plusieurs projets clés dans les domaines de la science et de la société et il a beaucoup travaillé sur l’attractivité de l’institut auprès des étudiants et jeunes diplômés. En somme il a fait le community manager pour plusieurs projets structurants.

Il existe une différence sensible entre les deux exemples de cas concrets, très structurés et se déroulant dans le milieu de la recherche universitaire et/ou industrielle, et les deux projets exposés en interviews, Mozilla et Debian, pour lesquels un certain degré d’empirisme est de mise, avec un mode d’organisation non-directif qui laisse davantage de place à l’autonomie. Est-ce que vous ne voyez pas là une différence entre les projets du monde du Libre associatif et ceux du monde universitaire ?
Stéphane R. (rire) — En fait je ne suis pas sûr que la vision extérieure que l’on peut avoir d’Inria corresponde tout à fait à ce qui se passe à l’intérieur de l’institut. Les infrastructures sont entièrement au service de ses équipes de recherche, 200 environ, réparties dans et autour des huit centres implantés au niveau national. Les actions menées depuis le top management de l’institut ont plus pour but de coordonner que de contrôler. Du coup ce sont en réalité les chercheurs qui dirigent leur barque et les velléités de comportement exagérément top down sont assez efficacement filtrées. Il est permis de supposer que c’est l’un des facteurs qui font que l’institut conserve un niveau de pointe en recherche.

Vous parlez des bonnes pratiques et vous faites état de réussites (AspireRFID, Poppy Project) mais ne peut-on aussi tirer des leçons utiles des échecs ? Pour prendre à l’envers la démarche de votre ouvrage, qu’est-ce qui est défaillant lorsqu’une communauté ne fonctionne pas ?
Pour tout dire nous avons commis un article (publié chez OSS 2011) intitulé Comment tuer une communauté avec un diaporama…

Vous ne craignez pas de décourager un peu ceux qui voudraient débuter dans la gestion-animation de communauté ? Parce que, dites donc, c’est copieux tout ce processus idéal… et ça prend du temps ! Ce n’est pas possible pour une communauté de bénévoles, si ?

Oui, cette question de savoir quoi mettre et où s’arrêter a été souvent débattue. Pour l’anecdote, au départ l’idée était de produire un petit document d’une vingtaine de pages maximum, vite écrit (mouahahaha), facile à diffuser et à lire, ne donnant que quelques principes-clés. Aujourd’hui on en rit mais au milieu du gué, euh…

On a voulu faire simple mais à la fois complet. On pense que vous pouvez créer une communauté de 10 membres comme une communauté de 800 membres et plus… Le guide s’adresse à ces deux possibles configurations. On peut le lire de différentes manières : on peut s’arrêter au premier chapitre qui donne les grandes lignes de la méthode. On peut aussi, si on le souhaite, rentrer dans les détails grâce à une lecture plus approfondie du reste des chapitres. Mais on peut aussi lire ce guide en picorant certains passages, certains chapitres. Il faut prendre ce guide comme une sorte de « bible » qui vous suivra tout au long de votre vie de Community Manager.

Votre ouvrage s’adresse à des communautés institutionnelles assez structurées pour avoir une personne ou une équipe dédiée à l’animation, mais que conseilleriez-vous à des petites associations ?
Notre idée, souvent débattue également, c’est que, compte tenu du fléchage et des redites d’un chapitre sur l’autre qui permettent une lecture fractionnée ou partielle, le guide devrait être compatible avec de tout petits groupes.

D’ailleurs nous avons appliqué certaines parties pratiques du guide à un projet regroupant 5 à 7 personnes (un logiciel de preuves mathématiques) pour qu’il grossisse ! Nous avons suggéré au chef de ce projet de faire une journée de conférence à Paris où il a invité ses coopétiteurs dans le domaine, et l’avons incité à organiser une journée d’échange avec eux.

Au départ le porteur du projet n’en menait pas large mais il a trouvé l’idée intéressante. Finalement cette journée s’est avérée un joli succès : pleine d’échanges, de prises de contacts, bref, tout ce petit monde s’est retrouvé en mode coopération/compétition et le soir tout le monde était à la fois enchanté et ami. Suite à cette conférence, la communauté à plus que doublé, elle regroupe à présent vingt personnes à travers une liste de diffusion dynamique, où les collaborations sont quotidiennes. Cela peut prêter à sourire, mais ce qui nous importe c’est que le chef de projet soit heureux d’avoir créé une dynamique sur un sujet très, très pointu. Bien sûr, on en peut comparer un tel projet avec un projet grand public.

Je conseille d’utiliser ce guide comme un patchwork… à vous de picorer… picorer, picorer ! C’est vraiment un guide pour débutant, gourmand et grand spécialiste. Il est fait pour un large public et l’élaboration de mini-projets, de projets de taille moyenne, et de grands projets !

 Si vous aviez eu plus de temps/espace de publication, quel autre aspect auriez-vous abordé ? Ce sera pour une prochaine publication ?

Personnellement, je reviendrais sur la méthode pour choisir une licence, il manque des éléments tel que prendre en compte les objectifs du projet, ce que l’on veut partager et les valeurs que l’on veut transmettre. Je compléterais donc bien cette partie même si nous expliquons dans les deux cas concrets comment nous avons choisi les licences : selon les objectifs, le partage, les valeurs.

Nous sommes en 2016, et il y a encore beaucoup de mythes autour de ce sujet ! Je pense que les licences FLOSS décrivent suffisamment de règles pour ne pas ajouter des couches supplémentaires. Beaucoup trop de personnes se focalisent aussi sur le modèle économique au lieu de mettre en œuvre une gouvernance appropriée (avec le partage et les valeurs qui correspondent). On peut changer plus facilement de modèle économique que de modèle de gouvernance ou de licence. D’ailleurs je déconseille de tomber amoureux de son modèle économique ! Je compléterais bien le guide avec un chapitre sur le modèle économique appelé « consortium ».

Quelles sont les utilisations et/ou transformations que vous espérez pour ce guide ? Qui, selon vous, pourrait s’en emparer voire l’adapter ou le modifier ?

J’aimerais aussi travailler sur les communautés d’apprentissage telles qu’on les retrouve dans le monde éducatif. Il y aurait de quoi écrire un autre guide, qui ne serait pas redondant avec celui-ci : les techniques pour motiver et faire collaborer un monde de professeurs entre eux ne sont pas si simples et ne correspondent pas toujours aux motivations des communautés de pratique.

Enfin et surtout, on aimerait que les gens réagissent sur un wiki à propos du guide et nous donnent leur avis, ajoutent leurs conseils, leurs expériences… Et pourquoi pas faire une version 2 annotée avec les avis du public ?

Nous lançons aussi un appel à contribution pour nous aider à traduire le livre en espagnol, en anglais, en italien…

Nous vous laissons « 3 mots de la fin »…

— À plusieurs on est meilleurs !
— Community over code !
— Doing business on Open Source is not selling a code that we did not pay but earn his life around a code that is not sold.