1

Avancer ensemble vers la contribution…

Contribuer, oui, mais comment ? Comment susciter des contributions, les accueillir, les dynamiser, lever les obstacles et les blocages de tous  ordres ?

Tel a été le questionnement à l’origine du Fabulous Contribution Camp qui s’est déroulé à Lyon, du 24 au 26 novembre dernier, à l’initiative de La Quadrature et de Framasoft. Toutes les personnes qui ont participé ont eu à cœur d’identifier les difficultés honnêtement mais aussi de proposer des pistes et des pratiques pour les surmonter…

Pour en témoigner, nous donnons la parole aujourd’hui à Maiwann qui est UX designer et que nous avions invitée. L’article ci-dessous est la simple republication de son compte-rendu sur son blog. Ses observations, ses réactions et ses chouettes sketchnotes font véritablement plaisir (bientôt peut-être d’autres billets des participants?) et nous indiquent des voies qui sont déjà celles de Contributopia.. C’est un début prometteur, parions que beaucoup d’associations pourront en tirer profit et continuer l’exploration de la contribution positive.


Fabulous Contribution Camp

Pour finir ce mois de novembre en beauté, j’ai été invitée par Framasoft à participer au Fabulous Contribution Camp qu’ils co-organisaient avec La Quadrature du Net. Je suis donc partie à Lyon pour rencontrer des contributeur·ice·s de tous horizons (et pas seulement de la technique !) pour parler des outils et de comment aider celleux qui le souhaitent à contribuer plus simplement.

Un petit état des lieux

Pyg le disait lors du Capitole du Libre (dans la conférence Contributopia que vous pouvez retrouver ici), la majorité des projets de logiciel libre sont soutenus par très peu (voire pas) de contributeur·ice·s. L’exemple le plus marquant est celui des pads (une alternative à GoogleDocs permettant d’écrire collaborativement en ligne): Sur l’année dernière, il n’y a pas une seule personne ayant réalisé plus de 50 contributions, alors que le logiciel est très populaire !

C’est assez inquiétant, et en même temps pour avoir déjà échoué personnellement, parfois On a l’envie de contribuer et on y arrive pas. Ce qui est quand même assez comique lorsqu’on voit à quel point le logiciel libre a besoin encore et toujours de personnes volontaires !

J’avais donc hâte de me joindre à des groupes de réflexion sur le sujet afin d’identifier les problématiques et envisager des pistes de solution tout au long du FCC. Autant vous dire que tout le monde s’est transformé·e·s en designer pour concevoir une meilleure expérience contributeur·ice (Peut-on envisager de dire des CX Designer qui au lieu de signifier Customer eXperience sera notre Contributor eXperience Designer ? ^.^ )

FCC c’est parti !

Le FCC avait lieu à Grrrnd Zero, un lieu au caractère très affirmé, où les murs sont recouverts d’illustrations, près d’un immense chantier participatif destiné à devenir à la fois salle de concert, d’enregistrement et atelier de bricolage/dessin… Nous nous sommes fait accueillir avec un petit déjeuner fabuleux, cette première journée démarrait vraiment bien !

Après un icebreaker rigolo nous demandant de nous regrouper d’abord par provenance géographique (mais comment font les nomades ?), ensuite par coiffure, ensuite par système d’exploitation préféré (oui on était un peu chez les geeks quand même) et enfin par notre engagement associatif principal, nous nous sommes lancés sur des ateliers collaboratifs, animés par les enthousiastes Meli et lunar !

Failosophy : Identifier les problèmes

Pour démarrer, nous nous sommes regroupés par 4 et avons raconté chacun une expérience marquante où notre envie de contribuer s’est soldée par un fail. Nous notions les différentes problématiques rencontrées sur des post-its avant de toutes les regrouper sur un grand mur pour avoir une vue d’ensemble des cas les plus fréquents. Ensuite, nous avons collaborativement trié les post-it ce qui prend “étrangement toujours 8 minutes peu importe le nombre de post-its ou de personne” d’après Lunar… Il faut dire qu’il avait raison 😉

De grandes catégories regroupent les post-its et font apparaître des motifs récurrents. Ceux que je retiens (car ils me font écho) :

  • La difficulté d’identifier un interlocuteur référent pour s’intégrer au projet
  • La peur de demander « Comment faire »
  • La peur de ne pas être assez doué·e / de dire des « choses bêtes »
  • Ne pas savoir par où commencer
  • La peur de ne pas s’intégrer à la communauté
  • Le manque de temps
  • La difficulté de déléguer à d’autres un projet qu’on a toujours porté
  • Le fait de ne pas avoir réussi à créer une communauté autour d’un projet
  • Ne pas connaître la ligne de route d’un projet
  • Ne pas savoir comment exprimer les besoins de contribution pour que les intéressé·e·s les comprennent

J’ai la sensation qu’un grand nombre de ces problèmes peuvent être résolus en:

  • Listant clairement les besoins de contributions, avec les compétences nécessaires, via une interface plus facile d’accès qu’un github (qui est réellement anxiogène pour les non-développeur·euse·s)
  • Désignant une personne accueillante comme point d’entrée pour les nouveaux·lles arrivant·e·s, à laquelle il sera facile de s’adresser, et qui saura aiguiller chacun·e vers des tâches simples pour découvrir le projet.

Cela se recoupe avec les discussions du Capitole du Libre, ce qui donne la sensation que nous sommes sur la bonne voie et que les hypothèses que j’ai entendues la semaine dernière sont des solutions à des problèmes récurrents pour les contributeur·ice·s !

Étude de cas : 6 projets appelant à la contribution

Dans la phase suivante, pour s’imprégner un peu de ce qui se fait parmi les projets nécessitant contribution, nous avons eu le droit à la présentation de:

  • Exodus, une plateforme qui analyse les applications Android et liste les logiciels traquant notre activité qu’elle y trouve.
  • La Revue de Presse de la Quadrature du Net, permettant de soumettre des articles à la revue de presse de façon collaborative.
  • Diaspora, un réseau social décentralisé assez proche de la configuration initiale de facebook.
  • FAI Maison, un fournisseur d’accès associatif et nantais, qui propose le prix libre (ou contribution consciente)
  • Le PiPhone, une plateforme de La Quadrature du Net permettant d’avoir accès à des numéros de députés afin de les appeler pour les encourager à soutenir (ou non) une loi, en proposant un set d’arguments et un retour d’expérience après l’appel.
  • FramaForm, une des alternatives de Dégooglisons Internet lancée par Framasoft, que Pyg a développée seul (!) en 15 jours (!!!). Avec le souci notamment que le logiciel permet plein de choses différentes mais que les options sont difficiles à trouver.

Le tour d’horizon permet de voir que si chaque projet recherche à fédérer une communauté de contribution, ils sont tous très différents et n’intéressent sans doute pas du tout les même personnes. Les présentations étaient elles aussi très variées selon la personne, de celui qui démarre par l’aspect technique à celui qui met tout de suite en avant les problématiques d’ergonomie. Bien sur, la présentation varie énormément selon les affinités et les problématiques rencontrées par chacun·e. Peut-être qu’avoir une description homogène (qui ne parte dans l’aspect technique que face à des personnes orientées technique) puis des pistes selon les compétences / envies de la personne en face serait à envisager ? (c’est un point que je laisse en suspens, mais il faut avouer qu’à force je suis rebutée par ceux qui m’expliquent immédiatement en quelle technologie est leur application alors que je suis très interessée par celleux qui ont des problématiques de conception 😉 )

Icebreaker rigolo

Petite recette: Prenez une feuille et écrivez en gros au marqueur ce dont vous avez envie de parler / un truc à apprendre à quelqu’un, montrez la feuille à tout le monde et formez un binôme avec une personne qui est intéressé·e par votre thème et a un thème qui vous intéresse (ou pas) !

Grodébat I

Après déjeuner (des lasagnes végétariennes à tomber <3) nous avons repris certaines catégories de problématiques listées le matin et nous sommes séparés en petits groupes pour déterminer:

  • C’est quoi le problème ?
  • Dans l’idéal, avec une baguette magique, qu’est-ce qu’on fait ?
  • Quelles solutions concrètes pour y arriver ?

Nous sommes arrivés à tout un tas de solutions pour nous mettre le pied à l’étrier:

Vision :

Créer un manifeste et créer des rencontres mêlant communauté de contributeur·ice·s et utilisateur·ice·s

Accès au savoir & Appropriation :

Formuler des avantages concurrentiels pour les marchés publics et rendre transparents les logiciels utilisés dans le service public

Sortir de l’entre-soi :

Trouver des métaphores pour expliquer sans être technique, lister les communautés avec des objectifs similaires mais des besoins différents.

Répartition des tâches :

Lister l’ensemble des tâches à faire et leur avancement.

Expression des besoins :

Lister & Publier les besoins de contribution en petites tâches, Créer un bouton “J’ai un problème” qui s’adresse à un humain (facilitateur ou UX designer)

Rapports de pouvoir :

Mettre et afficher un système de résolution des conflits.

Gestion du temps (et de l’argent) :

Mesurer le temps mis pour une tâche pour le prioriser dans le futur et compléter le financement par le don.

Accueil :

Avoir un·e référent·e du projet, co-rédiger une charte d’accueil “Comment accueillir les personnes”.

Toutes ces solutions qui sont autant de petits pas à mettre en œuvre m’ont beaucoup enthousiasmée : j’ai l’impression que le chemin est tout tracé pour réaliser de belles choses ensemble ! Nous avons d’ailleurs enchaîné avec de petits groupes de travail concrets permettant de débuter la rédaction d’une charte, designer un bouton “J’ai un problème” ou encore réfléchir à une plateforme listant les besoins de contribution.

Tout ça en une seule journée autant vous dire que nous étions lessivé·e·s à la fin, mais après un bon repas (préparé par les cuistots de Grrrnd Zero) il était temps de se coucher pour être fraî·che·s le lendemain !

C’est reparti pour un tour !

C’est avec une fraîcheur toute relative que nous avons entamé la seconde journée du FCC. La fatigue est là, mais la bonne humeur et l’enthousiasme général donnent vraiment envie de finir le week-end en beauté. Nous entamons un tour de météo avec pas mal de personnes dans le brouillard du matin, mais très vite nous faisons chauffer les méninges collectivement.

Contributeur·ice·s, où êtes-vous ?

Nous démarrons par une séance de « boule de neige » où nous sommes invité·e·s à lister les endroits où, demain, nous pourrions aller pour parler du logiciel libre et trouver de nouvelles personnes pour contribuer ! Sur un autre tas, nous écrivons plutôt ce qui nous empêche de le faire actuellement.

Je liste personnellement mes précédentes écoles de design qui sont, à mon avis, des nids à designers motivé·e·s mais pour qui le monde du libre est inexistant (on a tendance à nous parler principalement de droit d’auteur et nous n’entendons jamais parler de licences libres). Pour y aller cependant, il me faut plus de connaissances sur les licences et une liste de projet dont ils pourraient s’emparer afin de commencer à contribuer rapidement.

À la fin nous collons tout nos post-it sur les murs et, comme a dit lunar: “Si chacun ramène 3 personnes, la prochaine fois on est 300.”. Il n’y a plus qu’à !

Gros Débat II : Le retour

Nous enchaînons sur des groupes de travail thématiques. Je rejoins celui qui aborde le sujet du financement, et y apprends sans surprise que les subventions demandent un investissement énorme (environ 1/3 du temps total de travail passé pour les demander) et que, si le fonctionnement grâce aux dons permet beaucoup plus de liberté, il est soumis à des règles strictes, notamment au fait qu’on ne peut pas donner de contrepartie en échange d’un don, qui doit être fait uniquement pour soutenir le travail passé et à venir de l’association (dans les grandes lignes).
Le monde des financements a l’air très nébuleux, ce qui nous fait envisager de rechercher des contributeur·ice·s s’y connaissant en financement comme l’on en rechercherait en design ou en admin sys !

Les autres groupes ont pour leur part envisagé :

Accueil :

Montrer de l’intérêt aux personnes qui arrivent, lister les besoins afin qu’iels puissent s’en emparer.

Discutons ensemble :

Diversifier les compétences en listant les besoins (les solutions se regroupent, chouette !), ne pas imposer des outils libres aux futurs utilisateur·ice·s mais partir de leurs problèmes plutôt (on dirait bien une démarche de conception centrée utilisateur·ice \o/ )

Rencontrer les utilisateur·ice·s :

Avoir des relais au sein de l’association ou se greffer à une rencontre existante afin de faciliter les échanges, demander à des UX Designers de se joindre aux rencontres et motiver certains devs à venir voir les tests utilisateurs.

Comment on garde le lien post-FCC :

Avoir une plateforme ou l’on puisse mettre des photos, un article de blog (collaboratif ?) récapitulant le week-end, et au-delà, une plateforme listant les besoins de contribution (oui, encore, chouette !)

La machine infernale !

Après le repas composé de pizzas maison (c’est vraiment sympa Grrrnd Zero), nous nous lançons dans la machine infernale : une première personne se place et commence à enchaîner un son et un geste, de façon répétitive. Une seconde personne la rejoint et va elle aussi réaliser son geste, et chacun va à son tour rejoindre la machine infernale, en répétant indéfiniment son geste et son son jusqu’à ce que… la machine s’emballe ! C’était un petit jeu très chouette et revigorant après la phase digestive !

Gros Débat III

Pour ce troisième groupe de réflexion, je rejoins pyg qui a envie de réunir des associations afin de les informer sur le logiciel libre, qui leur plaît pour des raisons évidentes de prix, mais aussi de valeurs ! Cependant le numérique est un domaine assez vaste et pour des assos qui ne s’y connaissent pas, il y a besoin de faire de l’éducation aux usages et à ce que cela engendre d’utiliser tel ou telle logiciel ou application.

Le groupe fourmille d’idées, je retiens pêle-mêle:

  • Il y a un besoin de sensibilisation, de démonstration des possibilités des logiciels libres, et d’accompagnement à la transition,
  • Les associations ont besoin d’indépendance, de communiquer et de collaborer
  • Les mettre en relation vis à vis de leurs besoins peut permettre une mise en commun de financement pour développer des logiciels ouverts et adaptés
  • Il faut aller voir les assos pour savoir ce dont elles ont besoin et ce qu’elles recherchent
  • Selon les retours, décider du format, plutôt conférence organisée ou Summer Camp très ouvert ?

Moi qui recherche à participer à des choses qui ont du sens, me voilà pile au bon endroit et j’en suis très heureuse ^.^

Ça sent la fin !

Enfin, pour finaliser le FCC, nous avons 4 catégories de post-it, à remplir puis à afficher au mur:

  • ❤️ Ce que nous avons fait ce week-end et qui nous a plu !
  • 🌟 Ce que j’ai envie de faire dès demain pour contribuer.
  • ➡ Ce que je fais dans les prochains mois.
  • 😊 Ce que j’ai envie que quelqu’un d’autre ici fasse (et chacun pouvait récupérer un post-it de ce type pour s’y engager)

Voici les miens :

Merci le FCC !

Ce Fabulous Contribution Camp a été une très bonne expérience : J’ai pu parler UX en long, en large et en travers, à des personnes qui se sont montrées à l’écoute de ce que j’avais à leur raconter (et ça ça fait plaisir !). Les différentes solutions énoncées, avec des pistes concrètes de réalisation pour se lancer rapidement me donnent des ailes, et j’espère que cette motivation ne va pas retomber de sitôt !

Je vous tiendrai au courant de mes avancées dans le monde du libre et de la contribution, en tout cas je remercie Framasoft de m’avoir permis de venir partager un week-end à Lyon avec eux à parler et rêver du futur du numérique !

Pour finir, voici les sketchnotes de ce week-end collaboratif. Prenez soin de vous 🙂

novembre 2017

Licence Creative Commons




Prendre du champ (Libres conseils 26/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Lycoris, grosfarmerlin8282, Sky, Julius22, _noskill, Nyx, lenod, KoS, lerouge, alexb, Ex0artefact, name?, SaSha_01, peupleLàlamessen

Prendre de la distance pour atteindre l’excellence

Jono Bacon

Jono Bacon est gestionnaire de communauté, directeur technique, consultant et auteur. Il travaille actuellement comme gestionnaire de la communauté Ubuntu chez Canonical. Il dirige une équipe afin de faire croître, de stimuler et d’enthousiasmer l’ensemble de la communauté Ubuntu. Il est l’auteur d’Art of Community, le fondateur du Community Leadership Summit et le cofondateur du populaire podcast LugRadio.

Jono Bacon au tableau blanc

La première fois que j’ai entendu parler de Linux et d’open source remonte à 1998. La technologie était alors horriblement compliquée et il fallait fournir de gros efforts pour obtenir un système qui tourne correctement ; pourtant, le concept d’une communauté collaborative globale me subjugua. À l’époque, je ne possédais aucune connaissance, mes compétences techniques étaient limitées et j’avais des boutons.

J’étais un adolescent typique : tourmenté, cheveux longs, T-shirt Iron Maiden. Mon chemin était déjà tout tracé, au sens le plus traditionnel ; j’irais à l’école, puis au lycée, puis à l’université, puis je trouverais un travail.

Quatorze ans plus tard, le chemin que j’ai finalement suivi n’a rien de conventionnel. Cette fascination personnelle envers le communautaire m’a conduit partout dans le monde et m’a lancé des défis captivants. C’est intéressant de prendre du recul et d’analyser cette période. Enfin, ça pourrait être intéressant pour moi… Vous préférerez peut-être passer au chapitre suivant…

… Toujours avec moi ? OK, allons-y.

La science contre l’art

J’ai toujours cru que la gestion d’une communauté était moins une science qu’un art. Je définis la science comme l’exploration de méthodes permettant de reproduire des phénomènes à travers des étapes établies et clairement comprises. Dans le monde de la science, si vous connaissez la théorie et la recette pour un résultat donné, vous pouvez souvent reproduire ce résultat comme tout un chacun.

L’art est différent. Il n’y a pas de recette pour produire une chanson populaire, pour créer une peinture exceptionnelle ou pour sculpter une statue magnifique. De même, il n’y a pas vraiment d’ensemble d’étapes reproductibles pour créer une communauté prospère. Bien sûr, il y a des astuces et des techniques pour parvenir à réunir certaines composantes du succès, mais c’est la même chose pour les autres formes d’art : nous pouvons tous apprendre les notes et les accords d’une guitare, mais cela ne veut pas dire que nous allons écrire la prochaine Bohemian Rhapsody. La formule qui donne naissance à un titre comme Bohemian Rhapsody, c’est une dose de compétence acquise et une dose de magie.

Je ne suggère cependant pas que la gestion de communauté soit une forme d’art désespérément branchée et introvertie que seuls quelques bienheureux élus très talentueux peuvent accomplir. Ce dont je me plains est qu’il n’y ait pas de manuel sur la façon de créer une communauté magnifique et enthousiasmante ; il s’agit toujours d’une dose d’apprentissage et d’une dose de magie mais la part de magie ne vous sera pas insufflée par la grâce des dieux ; il vous faudra plutôt la chercher en essayant de nouvelles voies, en restant à l’écoute des retours et en évaluant ce qui fonctionne et ce qui ne fonctionne pas.

C’est plutôt frustrant car cela veut dire que cette « magie » ne s’obtient pas en suivant une recette unique. Mais il reste la possibilité de partager les compétences acquises, comme j’ai cherché à le faire avec The Art of Community 1 et la conférence annuelle Community Leadership Summit 2.  

Avant de commencer mon introspection, et pour ceux que ma carrière n’ennuie pas mortellement, je vais résumer rapidement les communautés avec lesquelles j’ai travaillé afin de poser le contexte. En bref, j’ai commencé dans mes jeunes années chevelues par la création de l’un des premiers sites web communautaires britanniques sur Linux, appellé Linux UK, et j’ai intégré la communauté des Groupes d’utilisateurs de Linux (Gul). Je me suis ensuite lancé dans la création de mon propre Gul à Wolverhampton, au Royaume-Uni, et j’ai fondé le projet Infopoint pour encourager les Gul à prêcher Linux sur les salons informatiques du Royaume-Uni. J’ai ensuite poursuivi en contribuant à la communauté KDE et en fondant le site KDE::Enterprise ; j’ai établi le KDE Usability Study et contribué de-ci, de-là à diverses petites applications. J’ai ensuite fondé le groupe d’utilisateurs PHP des West Midlands. J’ai aussi commencé à m’intéresser à GNOME. J’ai développé quelques applications (GNOME iRiver, XAMPP Control panel, Lernid, Acire) et également participé à la conception et un peu au code d’une nouvelle application audio simplifiée appelée Jokosher. C’est à peu près à cette époque que j’ai co-fondé le podcast LugRadio qui fonctionna pendant quatre ans avec plus de deux millions de téléchargements, ce qui a entraîné la mise en place de cinq événements en direct au Royaume-Uni et aux États-Unis. À cette époque, j’ai également commencé à travailler comme consultant open source pour l’initiative publique OpenAdvantage. Là, j’ai vraiment eu l’occasion de me faire les dents sur le communautaire en aidant des organisations à travers tout les West Midlands à passer à l’open source. Après quelques années passées chez OpenAdvantage, je suis parti rejoindre Canonical comme gestionnaire de la communauté Ubuntu où j’ai mis en place une équipe de quatre personnes. Ensemble, nous nous investissons dans des projets très variés chez Ubuntu et Canonical. Vous êtes toujours là ?

Ouah, vous êtes tenace. Ou assommé d’ennui. Probablement assommé. Il y aura interro à la fin, ça vous apprendra…

Réfléchir

Ceci m’amène donc à l’objet de cet article : la curieuse question de savoir ce que je me dirais si je savais ce que je sais aujourd’hui. À ce jour, je pense que ce que j’ai appris au cours de ma carrière peut se diviser en deux grosses catégories :

Pratique — les trucs et astuces du métier, par exemple, les différentes approches des moyens de communication, les différentes façons d’utiliser la technologie, la gestion du temps, les différentes approches de la gestion de projet, etc.

Personnel — les leçons de vie et apprentissages qui modifient l’approche que nous avons de notre monde.

Je ne vais pas m’étendre sur la catégorie pratique — vous devriez lire mon livre si vous souhaitez en savoir plus sur ce sujet (le livre couvre aussi l’aspect personnel). Aujourd’hui, je vais plutôt m’intéresser aux leçons de vie. Les approches et les pratiques changeront toujours, mais les leçons que l’on en tire ne changent pas tant que ça : elles évoluent plutôt au fur et à mesure que votre sagesse grandit.

L’importance des convictions

Les communautés sont fondamentalement des réseaux de personnes poussées par leurs convictions. Chaque communauté possède son propre état d’esprit et un domaine d’expertise propre. Cela peut être une idée aussi grandiose que de rassembler l’intégralité des savoirs de l’humanité, changer la face du monde avec le logiciel libre ou, plus simplement, animer un « club » pour que les gens puissent échanger autour de leurs livres préférés. Que ce soit pour changer le monde ou simplement pour s’amuser, chaque communauté fait valoir son propre système de valeurs ; l’humble club de lecture accorde beaucoup de valeur au fait de fournir un environnement amusant, sécurisé et libre afin de pouvoir partager des avis et des conseils de lecture. Cela ne change pas le monde, mais cela reste toujours une bonne chose à laquelle n’importe qui peut se rallier.

La règle, souvent tacite, d’une communauté est que chaque contribution d’un membre de la communauté doit bénéficier à l’ensemble de celle-ci. C’est pourquoi il est amusant d’écrire un correctif pour un bogue d’un logiciel libre, de contribuer à la documentation ou d’organiser un événement gratuit. Mais il est rare que quiconque veuille contribuer de façon bénévole si sa contribution ne bénéficie qu’à une seule personne ou entreprise.

Bien sûr, je suis certain que vous tous, enfoirés cyniques que vous êtes, allez chercher et trouver une exception. Mais souvenez-vous que cette décision est profondément personnelle : les membres de la communauté décident par eux-mêmes si leur contribution doit bénéficier à tous. Par exemple, certains vont arguer que n’importe quelle contribution à Mono va seulement bénéficier à Microsoft et à l’ubiquité de leur infrastructure .NET. Mais des centaines de contributeurs participent à Mono parce qu’ils ne le voient pas de cette manière : ils voient leurs contributions comme un moyen utile et amusant de permettre aux développeurs d’écrire des logiciels libres plus facilement.

Si je devais parler au Jono de 1998, j’insisterais sur l’importance de cette conviction. J’avais alors une intuition à ce propos, mais je ne compte plus les exemples qui m’ont prouvé depuis que cette conviction incite réellement les gens à participer. J’ai souvent parlé de l’histoire du gamin d’Afrique qui m’a envoyé un courriel pour me dire qu’il devait marcher trois heures aller-retour jusqu’au cybercafé le plus proche pour contribuer à Ubuntu. Il le faisait car il était convaincu par notre mission d’apporter le logiciel libre aux masses. On pourrait aussi citer l’énorme croissance de Wikipédia, l’incroyable réunion de la communauté GNOME autour de GNOME 3, le succès d’OpenStreetMap et bien d’autres exemples.

Ceci dit, la conviction n’est pas juste un artifice pour les relations publiques. Il faut qu’elle soit réelle. Bien que nous ayons tous des convictions différentes — certains ont des convictions sur le logiciel, sur l’éducation, sur le savoir, sur la transparence ou sur n’importe quoi d’autre — vous ne pouvez pas fabriquer un système de convictions à moins qu’il n’ait un but valide, auquel un groupe puisse s’intéresser. Certes, il peut être obscur, mais il doit être réel. Avec le succès du mouvement open source, nous avons vu des exemples d’entreprises qui tentaient de jouer cette approche et ce registre sémantique autour de la conviction, mais dans le but de servir leurs propres besoins. Je pourrais essayer de vous faire adhérer à cette idée : « Travaillons tous ensemble pour aider Jono à devenir riche » et fabriquer de toutes pièces quelques sophismes pour justifier de cette acte de foi (par exemple, si j’étais riche, je pourrais me concentrer sur d’autres travaux, au bénéfice d’autres communautés ; mes enfants seraient élevés et éduqués dans de bien meilleures conditions, ce qui profiterait à tout le monde), mais ce serait n’importe quoi.

En tant que telle, la conviction est un puissant moteur pour la contribution comme pour la collaboration, mais il est important de l’utiliser de manière équilibrée et de l’associer au respect. Alors qu’elle peut déclencher d’incroyables changements, elle peut être terriblement dévastatrice (comme c’est le cas avec certains prédicateurs à la TV qui utilisent la religion comme un moyen de vous soustraire de l’argent, ou encore les faux médiums qui utilisent la lecture à froid et s’accrochent à votre besoin désespéré de croire que vous pouvez à nouveau vous connecter à un être cher disparu).

Votre rôle

Aujourd’hui, les gestionnaires de communauté ont un rôle intéressant. Par le passé, j’avais parlé de deux types de gestionnaires de communauté ; ceux qui sortent, font des conférences et s’agitent en parlant d’un produit ou d’un service et ceux qui travaillent avec une communauté de volontaires pour les aider à connaître une expérience collaborative, productive et amusante. Le second type m’intéresse plus — je pense que c’est ce que fait un vrai gestionnaire de communauté. Le premier de ces positionnements est tout à fait sympa et respectable mais cela convient mieux dans le domaine de la promotion et des relations publiques et cela nécessite d’autres compétences. J’ai quelques conseils que je pense être assez intéressants pour être partagés.

La première et probablement la plus importante des leçons est d’accepter que vous pouvez et allez parfois avoir tort. Jusqu’ici, dans ma carrière, j’ai fait certaines choses correctement et j’ai commis des erreurs. Bien que je croie être généralement sur le bon chemin et que l’essentiel de mon travail soit couronné de succès, il y a eu quelques flops ici ou là. Ces loupés, accidents et faux pas n’ont jamais été dus à de la malveillance ou de la négligence ; ils ont plutôt été causés par une sous-estimation de la difficulté de mon objectif.

Ça a l’air assez évident, mais ça l’est moins quand vous avez une fonction relativement publique. En gros, les gestionnaires de communautés sont souvents vus comme les représentants d’une communauté donnée. Par exemple, je sais qu’à titre personnel, on me considère comme l’une des figures publiques d’Ubuntu et cette responsabilité, s’accompagne d’une certaine pression publique quant à la manière dont les gens vous perçoivent.

Avoir les projecteurs braqués sur soi en se retrouvant à la tête d’une communauté déclenche chez certains un mécanisme défensif. Ils reculent à l’idée de faire des erreurs en public, comme si les masses dans leurs bavardages s’attendaient à une prestation parfaite. C’est dangereux, et on a déjà vu, par le passé, des personnages publics qui ne reconnaissent jamais avoir fait une erreur par crainte d’être ridicules en public. Non seulement, c’est une idée fausse (nous faisons tous des erreurs), mais cela ne donne pas non plus à la communauté un bon exemple de chef de file honnête et transparent tant dans les choses qu’ils font bien que dans celles qu’ils font moins bien. Il est important de se rappeler que nous gagnons souvent le respect d’autrui par leur acceptation de nos erreurs : c’est la caractéristique d’un individu honnête et accompli.

Je me rappelle mes débuts en tant que responsable chez Canonical. À l’époque, Colin Watson et Scott James Remnant, deux vieux briscards des tous débuts de Canonical et d’Ubuntu, faisaient aussi partie des responsables de l’équipe d’ingénierie d’Ubuntu. Nous avions des réunions hebdomadaires avec notre directeur technique, Matt Zimmerman, et j’y entendais régulièrement Colin et Scott avouer ouvertement qu’ils étaient mauvais dans ceci ou avaient fait une erreur dans cela ; ils étaient étonnamment humbles et acceptaient leurs forces et leurs faiblesses. En tant que responsable débutant, je l’ouvrais moins souvent, mais cela m’a appris que ce genre d’ouverture d’esprit et d’honnêteté est important non seulement en tant que responsable, mais en tant que leader d’une communauté. Depuis, je n’hésite plus à admettre publiquement mes erreurs ou à m’excuser si je foire quelque chose.

Écouter

De même qu’être ouvert aux erreurs est primordial, il est tout aussi important d’être à l’écoute et d’apprendre de ses pairs. Dans de nombreux cas, nos communautés perçoivent les responsables et les leaders de communauté comme des personnes qui devraient toujours fournir des orientations et des directions, mener activement le projet et réaliser ses objectifs. C’est sans aucun doute une responsabilité. Mais tout autant qu’être la voix qui montre la voie, il est important de prêter l’oreille pour écouter, guider quand c’est opportun et apprendre de nouvelles leçons et idées.

Les membres de nos communautés ne sont pas juste des mécaniques froides et insensibles qui font leur travail. Ce sont des humains qui vivent, respirent, ont des opinions, des sentiments et des idées. J’ai vu de nombreux exemples — et j’en ai déjà moi-même provoqué —, de ces situations où quelqu’un est tellement habitué à donner des instructions et des conseils qu’il oublie parfois de simplement s’asseoir, écouter et apprendre de l’expérience de quelqu’un d’autre. Toute industrie possède ses maîtres-à-penser et ses experts… des gens célèbres et reconnus pour leur sagesse. Mais, d’après mon expérience, certaines des leçons de vie les plus révolutionnaires que j’ai apprises sont venues de membres tout à fait anonymes, ordinaires. Savoir écouter les gens n’est pas seulement important pour nous aider à apprendre et à nous améliorer dans ce que nous faisons, c’est également essentiel pour gagner le respect et avoir de bonnes relations avec sa communauté.

Temps de travail contre temps libre

Pendant que je parle de la façon dont nous collaborons avec notre communité, il y a un autre résultat de mon expérience que je n’ai vraiment assimilé qu’assez récemment. Comme beaucoup de gens, de nombreux centres d’intérêts remplissent mes journées. À part être marié et essayer d’être le meilleur mari possible, et à part mon travail quotidien en tant que gestionnaire de la communauté d’Ubuntu, je participe aussi à des projets tels que Severed Fifth, le Community Leadership Summit et quelques autres choses. Comme on pourrait s’y attendre, je consacre mes journées à mon travail rémunéré : au boulot, je ne passe pas de temps à travailler sur ces autres projets. Et, comme on pourrait s’y attendre, lorsque ma journée de travail se termine, je me mets à travailler sur ces autres projets. La leçon qu’il faut retenir ici, c’est qu’il n’est pas toujours clair pour votre communauté de savoir où tracer les limites.

Au fil des années, j’ai développé toute une série de services en ligne que j’utilise tant dans mon travail qu’à titre personnel. Mes comptes Twitter, identi.ca et Facebook, mon blog et d’autres ressources sont les endroits où je parle de ce que je fais. Le problème est que si l’on tient compte de leur caractère public, du fait que je suis un représentant officiel du projet Ubuntu et de tous les fuseaux horaires autour du globe, même Einstein aurait du mal à faire la différence entre ce que j’écris en tant que Jono et ce que j’écris pour le compte de Canonical.

Ce qui a pu causer de la confusion. Par exemple, malgré mes clarifications répétées, OpenRespect n’est pas et n’a jamais été une initiative de Canonical. Bien sûr, quelques idiots ont choisi d’ignorer mes explications à ce sujet mais je comprends néanmoins comment la confusion a pu arriver. La même chose s’est produite pour d’autres projets tels que Severed Fifth, The Art of Community et le Community Leadership Summit, qui ne font pas et n’ont jamais fait partie de mon travail chez Canonical.

C’est une leçon pour moi car j’ai moi-même partagé un moment, cette vision des choses et disais : « Évidemment que c’est activité de loisirs, j’ai posté ça à 20 h. » tout en haussant les épaules à propos de la confusion entre travail et projets personnels. Quand votre travail vous met dans une position relativement publique, vous ne pouvez pas vous offrir le luxe de voir les choses comme ça. Au contraire, vous devez considérer que les gens vont avoir tendance à faire la confusion et que vous allez devoir travailler plus dur pour bien clarifier les choses.

Ne voyagez pas trop

À propos du travail pour une société qui vous a recruté pour être à la tête d’une communauté, vous devriez toujours avoir conscience des risques comme des bénéfices des voyages. C’est une chose que j’ai apprise assez tôt dans ma carrière chez Canonical. Je voyais toujours les mêmes têtes dans les conférences, et il était évident que ces personnes avaient très bien communiqué sur les bénéfices des voyages auprès de leurs employeurs, tout comme je l’avais fait, sauf que j’en ai aussi appris les dangers.

Je voyageais et ce n’était pas seulement un travail fatigant et épuisant psychologiquement, mais j’étais aussi plus loin de mes courriels, moins présent sur IRC, j’étais dans l’impossibilité d’assister à de nombreuses réunions et j’avais moins de temps à consacrer à mes engagements professionnels. Ainsi, mon rôle était principalement devenu de sortir et d’aller assister à des événements et, même si c’était amusant, cela ne rendait pas autant service à ma communauté qu’il l’aurait fallu. Aussi ai-je drastiquement réduit mes déplacements — pour tout dire, je suis allé au Linux Collab Summit il y a quelques jours, et hormis quelques événements d’Ubuntu auxquels je devais assister, je n’ai assisté à aucune conférence depuis près d’un an. J’ai l’impression à présent d’être allé un peu trop loin dans l’autre direction. Tout est donc une question d’équilibre. Mais j’ai aussi le sentiment de mieux servir ma communauté quand je peux prendre le temps d’être au bureau et d’être en ligne et disponible.

La planification

Pour certains, être à la tête d’une communauté, ou simplement l’animer, est un rôle qui tient moins de la structure pré-établie que du fait d’être réactif. À mes débuts, c’est également ce que je pensais. Bien qu’il n’y ait absolument aucun doute sur la nécessité de se montrer réactif et de pouvoir répondre aux choses qui se présentent, il est également essentiel de planifier suffisamment son travail sur une période donnée.

Cette planification devrait être effectuée de manière ouverte quand c’est possible et remplit plusieurs objectifs :

Partager la feuille de route — ça aide la communauté à comprendre sur quoi vous travaillez et lui offre souvent des opportunités de vous aider.

Apporter des garanties — ça prouve qu’un responsable de communauté fait quelque chose. Votre communauté peut constater votre travail effectif à l’œuvre. C’est très important puisque la majeure partie du travail d’un responsable de communauté s’effectue souvent sans que la communauté au sens large en ait connaissance (par exemple, avoir une conversation en tête à tête avec un des membres de la communauté). Et ce manque de visibilité peut parfois générer des inquiétudes sur le fait que peu de choses se produisent dans des domaines-clé alors qu’en fait, beaucoup de choses se produisent en coulisses.

Communiquer les progrès vers le haut et vers le bas de l’organisation — c’est pertinent si vous travaillez dans une entreprise. Avoir établi de bons processus de planification montre votre travail effectif à votre hiérarchie ; ça rassure votre équipe sur le fait que vous saurez toujours sur quoi travailler et ça donne beaucoup de valeur ajoutée à la communauté.

Au fil des années, j’ai attaché de plus en plus d’importance à la planification. Mais je garde suffisamment de temps et de flexibilité pour rester réactif. Quand j’ai débuté comme gestionnaire de la communauté Ubuntu, mon planning était plutôt personnel et je le gérais au coup par coup : je prenais le pouls de la communauté et je consacrais temps et moyens à m’occuper des domaines que je jugeais adéquats.

À présent, je répartis les objectifs dans un ensemble de projets qui couvrent chacun un cycle d’Ubuntu, je rassemble des informations avec les parties prenantes, je compose une feuille de route, je fais le suivi du travail dans des schémas directeurs. J’estime également les progrès effectués en utilisant toute une gamme d’outils et de processus tels que mon diagramme des tâches réalisées, des réunions régulières et d’autres encore. Bien que la méthode actuelle nécessite plus de planification, elle est d’une aide significative en termes de bénéfices sur les points cités ci-dessus.

Perception et conflit

Dans le monde de la gestion et de la gouvernance de communautés, j’entends souvent s’exprimer l’avis selon lequel tout serait affaire de perception. En règle générale, quand j’entends ça, c’est en réponse à quelqu’un qui se trouve du mauvais côté du bâton, le plus souvent au cours d’une période de conflit.

Bien sûr, la perception joue un rôle important dans nos vies, c’est vrai ; mais ce qui peut alimenter des perceptions erronées ou inadéquates, c’est le manque d’information, de mauvaises informations et, dans certains cas, des tensions et des tempéraments échauffés. Cela peut être une des tâches les plus complexes pour celui qui est à la tête de la communauté. Et j’en suis ressorti en tirant quelques leçons dans ce domaine également.

Les communautés sont des groupes de personnes et, dans chaque groupe, on trouve souvent des rôles stéréotypés dans lesquels les gens se glissent. On y trouve, en général, quelqu’un que l’on considère comme une rockstar ou un héros, quelqu’un de compréhensif pour les préoccupations et les soucis et qui prêtera son épaule pour pleurer, quelqu’un qui a son franc-parler et souvent quelqu’un qui est… disons… intentionnellement pénible. Les héros, les oreilles compatissantes et les grandes gueules ne posent pas particulièrement de problèmes, mais les personnes qui créent délibérément des difficultés peuvent être pénibles ; lorsqu’il devient carrément difficile de gérer une personne, cela peut provoquer des tensions avec les autres membres et amener du conflit dans une communauté qui, sinon, est heureuse. Il faut étouffer ce genre de problèmes dans l’œuf.

Une partie du défi, ici, c’est que les gens sont des gens, que les groupes sont des groupes et qu’il n’est pas rare qu’une personne (ou un petit nombre de personnes) se fasse connaître et soit critiquée derrière son dos et passe pour quelqu’un avec qui il est difficile de travailler. En plus de cela, la plupart des gens n’ont pas envie d’être impliqués dans un quelconque conflit et, du coup, la personne dont on se plaint ne peut pas toujours se rendre compte de la façon dont les gens la perçoivent, étant donné que personne ne veut la confronter à ce sujet. Il en résulte une des situations les plus dangereuses pour les membres d’une communauté — une réputation se propage, sans même que la personne concernée ne s’en rende compte. Et du coup, puisqu’elle ne le sait pas, elle n’a jamais l’occasion de changer de comportement. C’est une situation plutôt inconfortable.

Une réponse habituelle à cette conclusion consiste à dire : « ils sont si difficiles à gérer qu’essayer de les raisonner c’est peine perdue, de toute façon ». Même si cela se produit certainement de temps à autres, ne supposez pas trop vite que ce sera l’issue ; j’ai quelquefois eu la désagréable expérience de sentir que je devais faire savoir à certaines personnes, la réputation qu’elles avaient développée. Et, dans la plupart des cas, cela a été une réelle surprise pour elles. Et elles ont quasiment toutes modifié leur comportement après ce retour.

Sur un sujet lié, bien que ça n’est pas si courant dans la routine quotidienne d’un leader de communauté, un conflit va souvent se pointer ici ou là. Je voudrais juste partager deux éléments à ce propos.

La première chose, c’est de comprendre comment les conflits naissent. Pour expliquer cela, permettez-moi de vous raconter une anecdote. La semaine dernière, un de mes amis est venu en avion dans la baie de San Fransisco pour une conférence. Il est arrivé le soir, je suis donc allé le chercher à l’aéroport et nous sommes allés au pub pour discuter des dernières nouvelles. Là-bas, il commença à me raconter à quel point il était déçu d’Obama et de son administration. Il a cité des exemples : la réforme de la sécurité sociale, la réforme de Wall Street, les droits du numérique et d’autres choses. Ce qui l’embêtait n’était pas la politique menée en elle-même, mais il trouvait qu’Obama n’en faisait pas assez. Ma vision des choses était légèrement différente.

Je ne suis ni Démocrate, ni Républicain ; je prends ma décision sur chaque problème, sans m’aligner sur l’une ou l’autre des parties. Là où je diffère de mon ami, cependant, c’est que je suis un peu plus favorable à Obama et son travail quotidien. C’est parce que je crois que lui, et que n’importe qui dans un poste en relation avec le public — qu’il soit internationalement reconnu comme le président ou qu’il soit obscur et spécifique comme un gestionnaire de communauté — a conscience que l’histoire lue et comprise par le public est souvent un simple fragment de l’histoire complète. Il y a eu des cas, par le passé, où quelque chose de controversé a démarré dans les communautés auxquelles j’appartenais. De nombreux commentateurs et spectateurs n’avaient pas l’entière connaissance des faits, soit parce qu’ils n’avaient pas compris les nuances et les détails du sujet, soit parce que certains éléments de l’histoire n’avaient pas été partagés.

Bon, je sais ce que vous allez dire — , quoi, certains éléments n’avaient pas été partagés !? Il vaudrait mieux être transparent, n’est-ce pas ? Bien sûr que c’est nécessaire. Et nous devrions toujours nous attacher à être ouverts et honnêtes. Mais il y a des cas où il serait inapproprié de partager certaines parties de l’histoire. Cela pourrait être en raison de fragments de conversations privées avec des gens qui ne souhaitent pas partager leurs commentaires ou tout simplement faire son boulot bien comme il faut sans éclabousser les réputations. Par exemple, j’ai toujours eu comme pratique de ne pas faire de coups bas à des concurrents, peu importe la situation. Par le passé, il y a eu des comportements critiquables de la part de certains concurrents dans les coulisses. Mais je ne vais pas me mettre à salir leurs réputations car cela n’aurait pas vraiment d’intérêt. Je dois cependant accepter que des critiques de la communauté peuvent ne pas connaître toute la situation avec toutes les magouilles ayant eu lieu dans les coulisses.

Enfin, à propos de conflits, je crois que j’ai appris une vraie leçon de vie au sujet de l’approche idéale à propos des critiques et des issues heureuses. Bien que les billets de blogs aient eu un impact très positif sur la manière dont les gens peuvent exposer leur pensée et partager leurs opinions et visions des choses, ils présentent une facette bien plus sombre. Les blogs sont aussi devenus un moyen d’exprimer parfois un peu trop rapidement des opinions excessivement zélées. Malheureusement, j’ai un exemple plutôt embarrassant de quelqu’un qui est tombé dans ce piège : c’est votre serviteur.

Pour commencer, quelques éléments de contexte. Il existait une entreprise appelée Lindows qui distribuait une version de Linux qui présentait beaucoup de similarités visuelles et fonctionnelles avec Windows. Microsoft voulout interdire l’emploi du nom « Lindows » et une bataille s’engagea pour changer le nom. D’abord, Lindows résista. Mais après que la pression eut monté, l’entreprise se rebaptisa Linspire.

Maintenant, le problème. Je prends la liberté de l’expliquer dans les termes de l’article lui-même :

Il y a peu de temps, un type nommé Andrew Betts a décidé de retirer les éléments non-libres de Linspire et de publier les parties libres dans une distribution dérivée de Linspire qu’il a appelée Freespire. Le fait de rediffuser des distributions ou du code n’a certainement rien de nouveau et s’inscrit parfaitement dans la culture de l’open source. À vrai dire, bien des distributions que nous utilisons aujourd’hui ont été dérivées d’outils existants.

Malheureusement, Linspire a considéré que c’était un problème et a demandé à Freespire de changer de nom. En lisant l’annonce du changement, son langage et son style, j’ai l’impression que tout ça pue le pur marketing. Loin de moi l’idée d’insinuer que Betts a été contraint d’écrire cette page ou que les drones marketing de Linspire l’ont écrite et annexée en son nom, mais cela ne me semble pas sonner très juste. Je me serais attendu à trouver des lignes du style « Le nom de Freespire a été changé pour Squiggle afin d’éviter toute confusion avec le produit Linspire. », mais ce n’est pas le cas. Au lieu de cela, on a droit à des morceaux choisis de marketing comme « Afin de prévenir toute confusion, j’ai contacté Linspire qui m’a fait une offre extrêmement généreuse pour nous tous. » La vache ! Quelle peut bien être cette offre-exclusive-qu’on-ne-rencontre-qu’une-fois-dans-sa-vie-et-qu’on-ne-trouve-pas-dans-les-magasins ? Fort heureusement, il poursuit : « Ils souhaitent que tous ceux qui ont suivi mon projet puissent faire l’expérience du vrai Linspire, ET GRATUITEMENT !!! ». Maintenant, dites-nous, je vous prie, comment nous pouvons obtenir cette vraie version du logiciel « ET GRATUITEMENT » ?

« Pour une période limitée de temps, ils mettent à disposition un code de réduction dénommé FREESPIRE qui vous donnera une copie numérique gratuite de Linspire ! Veuillez visiter http://linspire.com/ pour les détails. » Ho… merci.

Dans un billet de mon blog, J’ai décoché à Linspire un bon coup de genou dans les bijoux de famille. J’ai raconté l’histoire, protesté contre ce que je considérais comme de l’hypocrisie considérant leur propre bataille dans des histoires similaires de marques déposées, et j’ai fulminé. J’aurais aimé que Guitar Hero existe à cette époque, cela aurait été un bien meilleur moyen d’utiliser mon temps.

Je me suis trompé. Mon article n’allait jamais servir à quoi que ce soit. Peu de temps après la publication de l’article, le PDG d’alors, Kevin Carmony, m’envoya un courriel. Il n’avait pas l’air satisfait de ma prestation. Son objection, et elle était valable, visait l’absence de concertation mutuelle préalable. Ma première réaction fut de répondre sur mon blog. La réalité de l’histoire était beaucoup moins noire. Et les gens de Linspire n’était pas les ogres que j’avais dépeints. J’ai présenté mes excuses à Kevin et me suis senti idiot.

Beaucoup de conflits sont résolus par des discussions privées où les gens peuvent être ouverts et concentrés sur les solutions sans être dérangés. Au fil des années, j’ai vu beaucoup d’exemples d’une guerre publique houleuse par blogs interposés continuant, alors que, dans les coulisses, il y avait un échange calme et une recherche de solutions.

Jono Bacon a appris à communiquer avec toutes les communautés

Pour conclure

Lorsque j’ai commencé à écrire cet article, il était bien plus court. Mais j’ai continué à ajouter des éléments un par un. Il est sûrement déjà assez long pour que je puisse compter le nombre de personnes lisant cette partie sur les doigts d’une main. Je vais donc l’arrêter ici. Je pourrais continuer éternellement avec des anecdotes croustillantes et des expériences dans lesquelles j’ai été suffisamment chanceux pour être impliqué et pour étendre mes horizons. Mais je finirais par écrire L’art de la communauté II : cette fois-ci, c’est personnel.

La vie est une expérimentation permanente. Et j’espère que votre investissement dans la lecture de cet article vous a apporté un peu d’expérience.

1 http://artofcommunityonline.org

2 http://communityleadershipsummit.com

Crédit photos : gidgetkitchen  (CC-BY-SA) et Ubuntu-news.ru




Apprendre de ses erreurs (Libres conseils 25/42)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framasoft : Miki, Vilnus Atyx, Sphinx, peupleLà, Goofy, tcit, Julius22, Garburst, Cyrille L., lerougeLycoris, vvision, lamessen

Comment ne pas lancer une communauté

Robert Kaye

Robert Kaye associe son amour de la musique et de l’open source dans l’encyclopédie de musique ouverte MusicBrainz. Robert a créé et dirige la MetaBrainz Foundation, une organisation à but non-lucratif basée en Californie, dans la continuité d’un travail de longue haleine pour améliorer l’expérience de la musique numérique. Au-delà du hack pour MusicBrainz, Robert recherche des festivals intéressants comme le Burning Man et des projets périphériques tels que bidouiller des robots pour préparer des cocktails. Comme il est invariablement couronné d’une chevelure aux vives couleurs, vous n’aurez aucun mal à le reconnaître dans une foule.

En 1998, je travaillais pour Xing Technology à San Luis Obispo et j’étais à fond sur notre nouveau projet AudioCatalyst. C’était l’un des premiers programmes d’extraction de MP3 intégré utilisant la base de données CDDB. Il s’agit de la base de données de CD qui permet à chaque lecteur de trouver le titre et la composition de tout CD. Si le CD n’est pas enregistré, on peut saisir les données afin que la prochaine personne qui en a besoin puisse s’en servir. J’adorais ce projet collaboratif en ligne et j’y ai enregistré des centaines de CD en quelques années.

Un jour, il nous a été annoncé que CDDB avait été achetée par Escient, une société qui deviendrait GraceNote par la suite. La base de données CDDB avait été privatisée, de sorte que plus personne ne pouvait la télécharger dans son intégralité ! Pour parachever le tout, Escient ne dédommagea aucun des contributeurs pour leurs efforts. En manœuvrant ainsi, ils arnaquaient le grand public. J’étais plutôt furieux de cette décision et je le suis encore aujourd’hui.

Plus tard dans la semaine, lors d’une fête avec des amis, je me plaignais de ce qui était en train de se passer et expliquais à quel point j’étais mécontent. Mon ami Kevin Murphy me dit : « Pourquoi tu ne démarrerais pas ton propre projet open source pour faire concurrence à ces enfoirés ? »

Quelques semaines plus tard, je finissais de travailler pour Xing et j’avais quelques semaines de temps libre avant de commencer chez EMusic. Je décidai d’apprendre le Perl et la programmation web en autodidacte et de démarrer la création de CD Index, un projet sans compatibilité et sans infraction avec CDDB. J’ai bidouillé le projet pendant cette pause mais l’ai rapidement oublié lorsque je suis devenu membre du projet FreeAmp chez EMusic.

C’est alors que Slashdot demanda, en mars 1999, quelle solution open source allait remplacer CDDB. J’ai passé le reste de la journée et la majeure partie de la nuit à finir CD Index et à le déployer. J’ai soumis un billet sur Slashdot parlant de mon projet (1) et il fut mis en ligne rapidement. Comme prévu, des centaines de geeks se manifestèrent en quelques minutes si bien que mon serveur tomba et rendit l’âme.

Les masses de gens qui arrivèrent commencèrent immédiatement à gueuler pour que les choses se fassent. Il n’y avait même pas encore de liste de diffusion ou de logiciel de suivi de problèmes ; ils insistèrent pour en avoir tout de suite. Comme j’étais novice dans l’open source, je ne savais pas vraiment ce qui était nécessaire ou non pour lancer un tel projet, j’ai fait comme les gens le demandaient. Les protestations reprirent de plus belle et davantage de gens encore insistèrent pour que je ferme le service étant donné qu’il n’était pas parfait. Mais même au milieu de ce vaste bazar, nous avons reçu plus de 3 000 soumissions de CD au cours des premières 24 heures.

Une fois que les choses furent calmées, il y avait encore beaucoup de gens qui rouspétaient. Greg Stein déclara qu’il allait écrire une meilleure version immédiatement. Mike Oliphant, l’auteur de Grip, annonça qu’il allait également travailler à une nouvelle version. Alan Cox vint et proclama que les bases de données SQL n’y suffiraient pas et que je devais utiliser DNS pour créer un meilleur service de recherche de CD. — Hein, quoi ? J’étais très mécontent de la communauté qui grandissait autour du billet publié sur Slashdot. Je ne voulais pas d’un lieu où les gens se manquent de respect et où certains se croient permis de gueuler encore plus fort pour obtenir ce qu’ils veulent. Je perdis rapidement tout intérêt pour le projet et CD Index déclina. Les autres projets que des personnes avaient promis de commencer (à l’exception de FreeDB) ne prirent jamais forme.

Alors, quand la bulle du point com a éclaté, j’ai eu besoin de réfléchir à ce que j’allais faire ensuite. Il était clair que mon boulot chez EMusic n’avait rien de sûr ; je continuais à conduire un roadster Honda S2000, ma voiture trophée de l’époque point com. Avec les traites de la voiture qui doublaient mon loyer, je devais décider : soit mener ma propre entreprise et vendre ma voiture de rêve, soit déménager à Bay Area (San Francisco) et travailler sur le rêve de quelqu’un d’autre, si jamais je parvenais à y trouver un travail. Je décidai que le plus intéressant serait de travailler sur une encyclopédie musicale complète construite par les utilisateurs. Je vendis la S2000 et me concentrai pour commencer à travailler sur une nouvelle mouture de CD Index.

Au cours d’une autre soirée, le nom MusicBrainz me vint et j’enregistrai le nom de domaine pendant la fête. Le jour suivant, motivé par le nouveau nom du projet, je commençai à bidouiller sérieusement et, à l’automne 2000, je lançai musicbrainz.org. Lancer n’est pas le bon mot, ici — je mis le site en place et me demandai alors comment éviter une nouvelle communauté de gosses hystériques venant de Slashdot. Je n’importai jamais de données depuis CD Index, ni ne mentionnai MusicBrainz sur les listes de diffusion de CD Index. Je me suis simplement éloigné du projet CD Index ; je ne voulais plus rien avoir à faire avec celui-ci. À la fin, j’ai décidé d’ajouter un simple bouton à la page web de FreeAmp qui mentionnait MusicBrainz.

Et une chose très étonnante s’est produite : des gens sont venus jeter un coup d’œil au projet. C’était seulement quelques personnes au début, mais quand quelqu’un me signalait quelque chose, je commençais une conversation et recueillais autant de retours d’informations que possible. J’améliorais le logiciel grâce à ces retours. J’ai aussi imposé un ton de respect sur les listes de discussion et, à chaque fois que quelqu’un était irrespectueux, j’intervenais et haussais le ton.

Mes efforts concentrèrent le projet vers son amélioration. Je l’ai fait pendant trois ans avant qu’il ne devienne clair que cette approche était efficace. La base de données croissait régulièrement et la qualité des données passa d’exécrable à bonne en quelques années.

Les bénévoles, ça va ça vient, mais je suis la colonne vertébrale du projet, c’est toujours moi qui donne le la et sa direction à l’ensemble. Aujourd’hui, nous avons une association à but non-lucratif avec 3,25 employés dans quatre pays, Google, la BBC et Amazon comme clients et notre bilan financier est bon. Je ne pense pas que cela aurait pu se produire avec la communauté CD Index.