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

Traduction Framalang : merlin8282, Sphinx, Julius22, goofy, lerouge, lamessen, Asta, peupleLà, okram

Packager : la voie royale du logiciel libre

Thorn May

Thom May est développeur Debian et membre émérite de la fondation Apache. Il a été parmi les premiers à être engagés chez Canonical, l’entreprise mère d’Ubuntu. Il vit aujourd’hui à Londres et dirige l’unité de développement chez MacMillan Digital Science.

Introduction

Ça fait plus de dix ans que j’ai débuté dans le monde du logiciel libre. J’avais utilisé Debian pendant quelques années à l’université et décidé que je voulais donner quelque chose en retour. J’ai donc commencé un long voyage à travers les étapes permettant de devenir un « nouveau responsable Debian » sans avoir jamais vraiment contribué au logiciel libre auparavant et inquiet qu’un manque d’expérience en C pourrait se révéler être un gros problème.

Il s’avéra que cette inquiétude était largement infondée. En commençant à travailler avec des paquets que j’utilisais régulièrement, j’ai pu contribuer efficacement. En même temps que mon expérience avec la myriade d’outils et de systèmes que Debian fournit à ses mainteneurs s’accroissait, je devenais plus efficace pour gérer mon temps et j’étais capable de travailler sur un ensemble de paquets plus étendu.

M’occuper de davantage de paquets m’amena à travailler avec un ensemble plus important de systèmes de compilation, de langages de programmation et de boîtes à outils. Cela m’aida également à m’intégrer à la communauté Debian. Aussi rugueuse et dogmatique soit-elle, le fait que la communauté Debian repose sur des mainteneurs doués et expérimentés est l’une des raisons principales pour lesquelles Debian a maintenu son excellence technique sur une si longue période.

À peu près à ce moment, le projet Apache httpd approchait enfin des premières versions bêta de httpd 2.0 qui était restée des années en chantier et était sur le point de subir une mise à jour majeure. L’équipe Apache de Debian avait été plutôt inactive depuis quelques temps — les paquets de la version 1.3 étaient stables et changeaient peu — et n’avait pas prévu d’empaqueter la version 2.0. J’avais un intérêt majeur à garantir que les paquets httpd étaient bien maintenus. Je travaillais comme administrateur système en charge de nombreux serveurs web Apache, il tombait donc sous le sens que je devais relever le défi de la production de paquets pour la nouvelle version.

Avec un ami, nous avons commencé le travail sur les paquets et nous avons rapidement découvert que, alors que le code approchait le niveau de qualité d’une bêta toute fraîche, l’outillage autour de la compilation et de la personnalisation de httpd était hélas manquants, ce qui est assez représentatif de bien des projets logiciels complexes.

Au cours de la majeure partie de l’année — alors que les développeurs en amont stabilisaient leur code et qu’un nombre croissant d’utilisateurs précoces commençaient à tester et à déployer la nouvelle version — nous avons travaillé dur pour garantir que le système de compilation soit suffisamment flexible et robuste pour satisfaire aux rigoureux prérequis de la politique de Debian. Nous devions non seulement garantir que nos paquets étaient techniquement corrects, mais également nous assurer que notre relation avec les développeurs en amont nous permettait de leur faire remonter des correctifs dès que possible, de les avertir dès que des problèmes de sécurité faisaient surface et de leur transmettre les tests préliminaires des versions candidates.

Mes interactions avec Apache pendant l’empaquetage et la maintenance de httpd 2.0 m’ont amené à m’engager en amont du projet, ce qui signifiait que je pouvais directement contribuer au code. C’est, en général, la dernière étape avant de passer de l’empaquetage d’un logiciel à son développement actif à destination d’un public plus large que celui de votre distribution. À titre personnel, cette reconnaissance m’a donné la confiance pour contribuer à bien plus de projets libres puisque je savais que mon code était de qualité suffisante pour être bien accueilli.

L’évolution, du packager au développeur

Comment est-ce arrivé ? La création de paquets, dans sa forme la plus simple, permet d’assurer qu’un projet logiciel donné se conforme à la politique de la distribution ; dans mon cas, Debian. De manière générale, cela signifie configurer le logiciel au moment de la compilation afin qu’il soit installé dans les répertoires idoines spécifiés par le Filesystem Hierarchy Standard, ou FHS (NdT : Norme de la hiérarchie des systèmes de fichiers), que les dépendances aux autres paquets soient correctement spécifiées et que les logiciels fonctionnent normalement sur la distribution.

La création de paquets complexes peut nécessiter la division d’un projet en amont en de multiples paquets. Par exemple, les bibliothèques et les fichiers d’en-tête permettant à l’utilisateur de compiler le logiciel avec leur bibliothèque sont fournis dans des paquets distincts, et des fichiers dépendant de la plate-forme peuvent être fournis séparément de ceux qui en sont indépendants. S’assurer que le logiciel en amont se déploie correctement dans ces situations nécessitera souvent des changements dans le code. Ces changements sont la première étape vers un travail actif sur un projet, plutôt que le travail parfois passif de création de paquet.

Une fois que votre paquet est disponible dans la distribution, il est exposé à des millions d’utilisateurs potentiels. Ces utilisateurs vont sans aucun doute exécuter votre logiciel selon des pratiques que ni vous, en tant que packager, ni vos développeurs en amont n’aviez prévues. Sans surprise, avoir de nombreux utilisateurs implique l’arrivée de nombreux rapports de bogue. Debian, comme la plupart des distributions, encourage ses utilisateurs à lui soumettre directement les rapports de bogue plutôt qu’à chacun des projets individuels en amont. Ceci permet aux mainteneurs de trier les rapports de bogue et d’assurer que les modifications effectuées lors du processus de création de paquet ne sont pas la cause du problème rapporté. Souvent, il peut y avoir un grand nombre d’interactions entre le rapporteur du problème et le mainteneur du paquet avant que les développeurs en amont ne soient impliqués.

Au fur et à mesure que le mainteneur du paquet accroît sa connaissance du projet, il sera en mesure de résoudre directement la plupart des problèmes. Le mainteneur publiera souvent des correctifs de bogue directement dans Debian tout en les faisant remonter en amont, permettant ainsi à la fois une résolution rapide des problèmes et de nombreux tests de correctifs. Une fois qu’un correctif est validé, le mainteneur travaillera alors avec le projet amont pour s’assurer que les changements requis y ont bien lieu, de manière à ce qu’ils soient disponibles aux autres utilisateurs du logiciel.

Fournir des correctifs de bogue réussis pour des distributions telles que Debian relève souvent d’une forme complexe d’art. Debian fonctionne sur de nombreuses plates-formes, allant des gros serveurs IBM aux smartphones, et la gamme ainsi que la largeur de ces plates-formes révèlent rapidement les approximations dans le code. L’empaqueteur a, la plupart du temps, un accès plus aisé à une gamme de plates-formes plus étendue que les développeurs en amont et constitue, de ce fait, le premier point d’appel quand un problème épineux de portage apparaît. On apprend rapidement à reconnaître les symptômes d’une approximation de la taille d’un pointeur, les problèmes avec les endianness et bien d’autres problèmes ésotériques ; cette expérience permet de devenir un programmeur à la fois plus polyvalent et plus prudent.

Lorsqu’un paquet reçoit des corrections de bogues et des améliorations, il est essentiel que ces changements remontent en amont. Trop souvent, la différence entre un paquet et le logiciel définitif en amont peut s’accroître énormément, avec pour conséquence que les deux bases de code deviennent presque entièrement distinctes. Non seulement, cela alourdit la tâche de la maintenance des deux côtés, mais cela peut aussi créer une immense frustration et faire perdre beaucoup de temps en amont dans le cas où un utilisateur de votre paquet rapporte un bogue lié à l’un des changements dans la version empaquetée en amont. Il est en conséquence vital que s’établissent une relation de travail étroite avec la branche amont et une compréhension de la meilleure façon de collaborer entre les deux parties.

La collaboration entre les développeurs et le packager peut prendre bien des formes. Que ce soit trouver la bonne voie pour communiquer les rapports de bogue, s’assurer de l’utilisation du bon style de codage, du même usage du système de contrôle de version ou des interactions qui provoquent le moins de frictions possible. Tout ceci amène une bien meilleure relation avec l’amont et accroît grandement la probabilité que ceux qui y travaillent prendront le temps de vous aider quand vous en aurez besoin.

Une fois que la relation de travail entre l’amont et vous est établie, il devient facile de contribuer plus directement en amont. Ceci peut également se faire de bien des façons différentes. Les premières étapes, simples, peuvent impliquer la synchronisation de n’importe quel rapport de bogue en amont avec ceux de votre distribution, afin d’être sûr que ce double effort impacte la cause primaire et résolve des bogues. Une implication plus directe consiste à développer des fonctionnalités et à changer plus largement que ce qui serait acceptable dans le cadre d’une version empaquetée.

Conclusion

Je pense que les deux choses essentielles que j’aurais aimé connaître lorsque j’ai commencé sont le sens de la communauté que le logiciel libre fait naître et la merveilleuse voie que le packaging de logiciel libre ouvre vers le plus vaste monde du logiciel libre

La communauté est essentielle au succès du logiciel libre. Elle se présente sous différentes formes, de la multitude d’utilisateurs souhaitant investir du temps dans l’amélioration de votre logiciel, jusqu’aux pairs d’une distribution ou d’un projet logiciel, qui investissent leur temps et leur énergie à affûter vos compétences et à s’assurer que vos contributions sont aussi bonnes que possible.

La voie qui part du packaging pour aller vers le développement est l’une des plus empruntées. Elle présente une courbe d’apprentissage moins raide qu’aborder directement le développement et permet d’acquérir des compétences à un rythme moins soutenu qu’en suivant d’autres chemins.

Pouhiou est notre joyeux et émérite premier romancier chez Framabook. À l’occasion de la sortie prochaine du livre II du cycle des NoéNautes, il a lancé une originale campagne de crowdfunding sur Ulule qui a fait réagir le blogueur influent (parce que brillant) Calimaq.

Ce dernier s’est en effet aventuré à parier que si cette campagne aboutissait alors il élèverait lui aussi son blog dans le domaine public via la licence Creative Commons CC-0. Bien mal lui en a pris puisque la campagne vient déjà de dépasser la barre escomptée (Pouhiou vous en remercie en vidéo ici) et se poursuit d’ailleurs…

Chose promise, chose due donc, et prétexte surtout à un passionnant entretien dialogue entre deux personnalités fortes du « Libre » francophone.

Je cède la parole à Pouhiou, et ça tombe bien car il adore la prendre 😉

En lançant le blog de mon roman feuilleton, j’ai eu d’instinct l’envie que cette histoire appartienne à ses lecteurs. Qu’ils s’en emparent. C’était une certitude que je ne savais pas comment appliquer dans les faits. M’intéressant au livre et au droit d’auteur, je suivais déjà le blog S.I.Lex écrit par un certain Calimaq. Ce mec, passionné et passionnant, arrive à transformer un sujet à priori lourd et chiant (la propriété intellectuelle) en une épopée rocambolesque. A force d’exemples, de décryptages, de coups de sang et de coup de cœur, il nous plonge dans les eaux du copy-right-left-up&down, on baigne en Absurdie et l’on ressort de son blog plus juriste qu’on y est rentré… sans même s’en apercevoir.

Un de ses billets m’a fait prendre conscience que la place de mes œuvres était dans le domaine public. J’ai donc passé tous mes écrits sous la licence CC0 et l’ai chaudement remercié dans cet article.

Il est né de cet échange une amitié intellectuelle. Calimaq s’est mis à défendre et mon œuvre, et la démarche qui l’accompagnait. Je me suis engagé dans SavoirsCom1, un collectif qu’il a co-fondé pour la défense des biens communs informationnels. Je ne compte plus les fois où l’on s’est dit « merci », tant chacun semble admirer et être complice de ce que fait l’autre. C’est ce genre d’émulation où la réflexion de l’autre nourrit la tienne, et te mène un poil plus vite, un poil plus loin que là où tu te serais rendu tout seul.

Quand, avec Framasoft, on a initié ce crowdfunding fou (toujours en cours sur Ulule) pour que le lancement de #MonOrchide (livre II des NoéNautes) puisse financer la distribution gratuite d’exemplaires de #Smartarded (le livre I), Calimaq a répondu présent. Il a fait un bel article pour promouvoir cette expérience . Mais, chose inattendue, il a ajouté ce post-scriptum explosif :

PS : allez, moi aussi, je mets quelque chose dans la balance. Si Pouhiou réussit son pari, je passe S.I.lex en CC0. Ceci n’est pas une parole en l’air !

Le pari est réussi. En 22 jours, on a atteint les 2200 € qui nous permettront de distribuer au moins 32 exemplaires de #Smartarded. Grâce à une mobilisation peu commune il ne nous a fallu que la moitié des 45 jours prévus (ce qui veut dire qu’il reste trois semaines pour battre tous les records et accroître le nombre de livres à distribuer !)

Le pari est réussi, et S.I.Lex devient un dommage collatéral : Calimaq tient sa part du contrat, élevant son blog dans le Domaine Public Vivant. Je sais que, le connaissant, ce n’est pas un geste anodin. Une belle occasion de discuter avec lui de licences, d’écriture, et de qu’est-ce que ça veut bien dire, toutes ces choses-là…

Pouhiou : Tu m’as fait un super article sur ton blog S.I.Lex, qui a été repris par ActuaLitté. Cela m’a beaucoup aidé à faire connaitre le projet. C’était déjà énorme (merci ^^). Pourquoi avoir en plus ajouté la licence de ton blog dans la balance ?

Calimaq : Cela fait un moment que je m’intéresse à ce que tu fais autour du cycle des Noenautes et d’après ce que tu as écrit sur ton blog, un des billets que j’avais écrit sur S.I.Lex t’avait influencé dans ta décision d’adopter la licence CC0 pour ton premier roman #Smartarded.

Quand j’ai vu que tu lançais cette opération de crowdfunding, j’ai voulu la soutenir et la faire connaître, parce que je trouve qu’elle bouscule la manière dont nous avons l’habitude d’appréhender des notions fondamentales, comme celles du gratuit et du payant. Avec la licence CC0, tu as renoncé à tes droits d’auteur pour que tes œuvres soient complètement libres, tout en réussissant à faire paraître ton roman chez Framabook. C’est déjà en soi assez perturbant pour les schémas habituels. Mais tu ne t’es pas arrêté là et par le financement collaboratif, tu as cherché à faire en sorte qu’un maximum de livres en papier deviennent gratuits afin de pouvoir les offrir.

Le plus intéressant dans ta démarche, je trouve, c’est que derrière ces décisions, il y a un modèle économique bien pensé, qui utilise le crowdfunding pour raccourcir la chaîne de l’auteur au lecteur, dans le but de diminuer les coûts. Tu démontres de manière paradoxale que la gratuité a toujours un coût. C’est typiquement le genre d’approches alternatives qui retiennent mon attention, parce que je trouve qu’elles font avancer la réflexion. Dans le contexte actuel de crispations autour des questions de droit d’auteur, qui sont particulièrement vives dans le secteur du livre, je pense que des initiatives comme les tiennes sont importantes. J’ai aussi beaucoup apprécié la lecture de ton premier roman #Smartarded et j’ai commencé à lire la suite #MonOrchide par petites touches sur ton blog. Tout cela a fait que j’ai voulu te soutenir en écrivant un billet sur S.I.lex et je me réjouis de ta réussite.

Merci ! Mais là tu parles plus de moi que de toi, hein… J’ai bien saisi que ce billet a été un élément déclencheur, mais est-ce qu’il s’agit d’un coup de tête ou est-ce que ça fait partie d’une réflexion personnelle plus… ancienne ?

Au-delà du billet, pourquoi avoir promis de changer la licence de mon blog si ton pari réussissait ? Peut-être d’abord un peu par superstition, pour porter chance à ton projet, en engageant quelque chose qui me tenait vraiment à cœur. Par ailleurs, je me posais des questions à propos de la licence de S.I.Lex depuis un certain temps. À vrai dire depuis le moment où j’ai écrit le billet Rien n’est à nous : grandeur et misère du domaine public volontaire. J’y montrais comment un certain nombre de créateurs dans le passé avaient choisi pour diverses raisons de renoncer aux droits sur leurs œuvres pour se placer en dehors de la logique de la propriété intellectuelle : Léon Tolstoï, Romain Rolland, Jean Giono, les affichistes de mai 68, les situationnistes, le musicien folk Woodie Guthrie.

Le domaine public est une notion qui a un grande importance pour moi et pour laquelle j’essaie de me battre. Il m’a semblé que le moment était venu de franchir le pas et de placer ma propre création, S.I.Lex, dans le domaine public volontaire.

Ton blog était en licence CC-BY (la seule condition de partage est de citer l’auteur). Là tu le passes en CC0. C’est quoi, au fond, la différence ?

Juridiquement dans le cadre du droit français, il n’y a pas tellement de différences. En effet, le Code de Propriété Intellectuelle ne permet pas dans notre pays de renoncer valablement à son droit moral, ce qui signifie qu’on doit théoriquement interpréter la CC0 comme une CC-BY. Je n’ai pas la possibilité légale de renoncer à mon droit à la paternité. Ce caractère inaliénable du droit moral a été voulu pour protéger l’auteur dans le cadre des contrats d’édition. Même dans le cas des « nègres » (ou, plus joliment dit, Ghostwriters en anglais), il reste possible pour eux de réclamer devant un juge la paternité d’un texte écrit pour quelqu’un d’autre, quand bien même ils se seraient engagés par contrat à ne pas révéler leur identité (on a des jurisprudences intéressantes à ce sujet dès le 19ème siècle, notamment dans l’affaire qui opposa Alexandre Dumas à l’un de ses collaborateurs, Auguste Maquet.

Le problème, c’est que l’application trop rigide de ce principe aujourd’hui peut conduire à « protéger » l’auteur contre lui-même, alors qu’il manifeste clairement la volonté de renoncer à ses droits. La licence CC0 a d’ailleurs été obligée de prendre en compte cet état de fait, en précisant que l’auteur renonce à ces droits « dans la mesure permise par la loi ». Cela veut dire que l’effet de la CC0 varie selon les pays : aux États-Unis, où le droit moral n’existe pas vraiment, il est total ; en France, il reste juridiquement incomplet, puisque le droit moral persiste. Le seul pays à l’heure actuelle qui reconnaisse explicitement la possibilité de verser ses œuvres dans le domaine public volontaire, c’est le Chili.

Donc passer de CC-BY (licence déjà très ouverte) à CC0 n’a pas beaucoup d’effets pratiques… tant que la propriété intellectuelle n’est pas réformée en France. Malgré tout, je ne t’imagine pas homme à manier ces licences à la légère. Si passer de la CC-BY au Domaine Public Vivant n’est pas un choix pratique, il est de quel ordre ?

Cette décision revêt à mes yeux une valeur symbolique et psychologique importante, en tant qu’auteur. Je ne suis pas comme toi auteur de littérature ou de théâtre, mais j’ai un rapport profond avec l’écriture. J’écris sur S.I.Lex par besoin viscéral d’écrire et quand je décroche de l’écriture, je périclite littéralement. Pour moi, l’écriture a aussi une importance comme trace que l’on laisse de soi au-delà de son existence. Du coup, le BY – la paternité – gardait une vraie importance à mes yeux, comme une sorte de « cordon ombilical » ou de minimum minimorum du droit d’auteur, dont il était difficile de se détourner. Couper ce cordon en adoptant la CC0 n’était pas anodin et il m’a fallu un certain temps – et un coup de pouce de ta part – pour lâcher prise !

Quel est l’intérêt, pour toi, de mettre de son vivant des textes dans le domaine public ?

Pour moi, l’intérêt principal, c’est de sortir en dehors du cadre du droit d’auteur. Avec les licences libres, on passe de la logique du copyright à celle du copyleft, mais on reste encore dans le système du droit d’auteur. Les licences libres ne sont pas une négation du droit d’auteur, mais une autre manière de le faire fonctionner. Avec la licence CC0, on n’est plus dans le copyright, ni même dans le copyleft, mais littéralement dans le copy-out. On décide sciemment que son œuvre n’est plus saisie par le droit d’auteur et ne doit plus être comprise à travers ce filtre. Je ne prétends pas que cette voie doive être suivie par tous les auteurs. Mais au stade où j’en suis, c’est cohérent avec ma démarche.

Tu dis de ton côté que tu n’as pas l’impression que tes textes ne t’appartiennent pas, mais que tu “digères” des éléments extérieurs que tu restitues par tes écrits. De mon côté, j’ai très tôt été sensible aux effets d’intelligence collective sur la Toile, avec le sentiment que je me devais de rendre à l’intelligence collective ce qu’elle me donne. Il n’y a pas un seul de mes billets qui n’ait été déclenché par les conversations et les échanges dans les flux. Dès lors, le meilleur moyen d’être cohérent avec moi-même, c’est d’opter pour le domaine public volontaire.

Par ailleurs, je pense important de montrer que le domaine public n’est pas seulement une chose du passé, mais qu’il peut être vivant aujourd’hui. En tant qu’auteur de son vivant, contribuer à alimenter le domaine public, c’est la meilleure manière de s’en faire l’ambassadeur et d’agrandir le cercle des biens communs de la connaissance.

OK : on a tous les deux ce souci de cohérence. C’est bien beau d’utiliser une licence parce qu’elle te met en adéquation avec ce que tu ressens de ta production intellectuelle… Mais il y a forcément des pragmatiques qui vont nous traiter d’utopistes ! Ils vont nous rappeler qu’on vit dans un monde où les enjeux commerciaux prévalent et où — selon eux — les circonstances font qu’il vaudrait mieux armer et protéger ses œuvres… D’un point de vue pratique, la clause non commerciale (NC) est un outil redoutable quand la CC0 est une passoire ! Du coup, une licence, c’est la conséquence d’un ressenti théorique ou la résultante d’un besoin pratique d’outil légal ?

C’est sans doute assez souvent le résultat d’un compromis entre les deux. Il faut considérer la situation des auteurs dans leur diversité et de multiples stratégies sont envisageables avec les licences. Les choses peuvent varier également selon les domaines de la création. Quand on voit un Cory Doctorow ou un Lawrence Lessig publier leurs ouvrages chez des éditeurs traditionnels et placer les versions numériques sous CC-BY-NC, je trouve que c’est une stratégie compréhensible et qu’ils ont par ce biais contribué à faire avancer la cause, en diffusant leurs idées dans un large cercle.

Beaucoup de créateurs en revanche ne cherchent pas un retour financier pour les œuvres qu’ils produisent. C’est le cas pour la plupart des amateurs qui créent des contenus sur Internet. Dans ce genre de situation, la réservation de l’usage commercial n’est généralement pas justifiée et choisir cette clause impose des contraintes sans réelle nécessité. Mais dans certaines situations, la clause NC peut constituer un élément intéressant pour permettre la circulation des œuvres tout en mettant en place un modèle économique. Il y a un débat assez vif en ce moment sur la légitimité de la clause NC, notamment telle qu’elle figure dans les licences Creative Commons. Je ne fais pas partie de ceux qui condamnent cette clause de manière systématique et j’ai déjà essayé de montrer que ce serait une erreur selon moi de la supprimer.

Malgré cela, tu n’as jamais mis de clause NC sur ton blog S.I.Lex...

Dans mon propre cas, je n’en vois absolument pas l’intérêt… Mon objectif en écrivant de cette manière est d’être lu par un maximum de personnes. Si certains de mes billets sont repris sur d’autres sites, y compris des sites se livrant à des activités commerciales, cela ne peut qu’augmenter l’exposition de mes écrits. J’ai d’ailleurs toujours fonctionné depuis le lancement de S.I.Lex dans un « écosystème » de sites. Très vite, j’ai eu la chance de voir certains de mes billets repris par le regretté OWNI. Cela a grandement contribué à faire connaître S.I.Lex et à développer mon lectorat. D’autres sites me reprennent régulièrement, comme Actualitté ou plus récemment Slate.fr. J’ai toujours considéré que S.I.lex était une sorte de plateforme de tir, où je posais des écrits qui pouvaient ensuite aller faire leur vie ailleurs. Avec une licence NC, les choses auraient été beaucoup plus compliquées.

La licence CC0 est peut-être une passoire, mais dans les conditions particulières qui sont les miennes comme auteur, elle conviendra parfaitement à ce que je veux faire de mes créations. Même si un éditeur vient publier certains de mes billets sous forme de livre dans un recueil, cela ne fera que contribuer encore à leur diffusion.

Du coup, tu n’exiges plus que l’on te cite comme source de tes écrits… de manière légale, c’est ça ? C’est un peu comme moi en fait : tu ne brandis pas d’arme juridique. Plutôt que de les craindre, tu donnes ta confiance aux personnes qui s’inspireront de (ou diffuseront) tes écrits. Confiance en le fait qu’elles soient assez respectueuses pour citer leur source.

La question qui peut se poser est celle du plagiat, quelqu’un qui viendrait s’approprier certains de mes textes en les publiant sous son nom. C’est une chose qui m’est déjà arrivée une fois et j’avoue que cela m’avait laissé une sensation assez désagréable.

Mais une personne comme l’artiste Nina Paley dit des choses très intéressantes sur les rapports entre le copyright et le plagiat. Elle considère en effet que le droit d’auteur paradoxalement favorise davantage le plagiat qu’il ne l’empêche. Elle explique également que le fait de créditer l’auteur relève en fait d’un système de régulation sociale qui n’a pas nécessairement besoin du droit pour fonctionner. Il s’agit en fait davantage de règles éthiques que des communautés se donnent. Nina Paley place d’ailleurs ses créations dans le domaine public volontaire en utilisant la non-licence Copyheart ou la CC0. Elle dit vouloir en cela faire œuvre de « non-violence légale » et je trouve que c’est un discours inspirant.

Un des pivots du libre, c’est sa viralité. On m’affirme que des processus du type la clause SA ont permis au libre de se développer tel qu’il est aujourd’hui. Pour mon compte, la SA est trop paradoxale. Je dis toujours que la première des libertés c’est de ne pas me lire. Dans la même veine, obliger les gens qui adapteront/traduiront/réécriront/diffuseront mes romans à mettre leur production sous licence libre, ça me semble créer de l’enclosure. Ce serait un peu comme forcer les gens à se vacciner au lieu de leur montrer comme on est mieux une fois bien portant… Et du coup j’aperçois que ton blog S.I.Lex n’était même pas sous clause SA ? Pourquoi ?

C’est une question intéressante et là aussi, je m’étais longuement posé la question lorsque j’avais choisi ma licence.

La clause de partage à l’identique est très importante dans beaucoup de domaines, comme celui du logiciel libre qui est fondé sur cette idée qu’il ne doit pas y avoir de possibilité de supprimer les libertés conférées à tous par la licence. Contrairement à ce que tu dis, je soutiendrais que le SA garantit au contraire qu’il ne puisse jamais y avoir d’enclosure sur une œuvre. Personne ne peut plus s’approprier de manière définitive un contenu placé sous Share-Alike. C’est pourquoi il me semble que c’est un type de licence adapté pour les biens communs que des communautés veulent protéger des risques d’enclosure. Si l’on prend le cas de Wikipédia, la licence CC-BY-SA est parfaitement adaptée, à la fois au travail collaboratif et aux réutilisations des contenus. Elle garantit que cela puisse se faire, même à titre commercial, mais sans réappropriation.

Cependant, je peux comprendre que tu ne veuilles pas placer tes écrits sous le régime du partage à l’identique, et c’est aussi la conclusion à laquelle j’étais arrivé pour S.I.Lex. Si je prends le cas des billets que reprenait OWNI par exemple, les choses auraient été trop compliquées avec une CC-BY-SA. En effet, OWNI reprenait mes billets, mais en les modifiant légèrement. Les journalistes de la plate-forme changeaient généralement le titre, ajoutaient des intertitres, inséraient des illustrations, des vidéos et parfois même des infographies. Il arrivait également que certains de mes billets soient traduits en anglais pour alimenter OWNI.eu. Tout cet apport éditorial était à mes yeux excellents, mais d’un point de vue juridique, il s’agissait d’adaptations de mes créations, ce qui aurait déclenché la clause de partage à l’identique, si j’avais choisi une CC-BY-SA. Or OWNI était sous CC-BY-NC-SA et il n’aurait pas été simple pour eux d’intégrer mes billets si je n’avais pas laissé une grande ouverture avec la CC-BY.

De plus, la CC-BY-SA n’est pas toujours simple à appliquer, comme l’avait prouvé l’affaire qui avait opposé Michel Houellebecq à Wikimedia, lorsque qu’il avait intégré dans son roman La Carte et le Territoire des extraits d’articles de Wikipédia sans mention de la source, ni crédits des auteurs.

Le domaine public et le libre ne sont pas exactement superposables. Le propre du domaine public, c’est de constituer un réservoir complètement ouvert dans lequel on peut venir puiser pour alimenter sa création sans contraintes. Les deux approches sont importantes et complémentaires.

Mais attends, de nous jours, entre les CopyrightMadness, les guerres de brevets, ceux qui s’approprient mon grain de maïs ou ton rectangle à bords arrondis… Avec tous ces abus du côté de la propriété intellectuelle et des biens communs… Y’a pas plus important ou plus urgent que de s’occuper du domaine public ?

Oui, c’est certain qu’il existe des sujets alarmants sur lesquels il devient urgent d’agir. Je ne suis pas seulement engagé pour la défense du domaine public, mais plus globalement pour la promotion des biens communs de la connaissance, ce que je fais au sein du collectif SavoirsCom1. Je milite également aux côtés de la Quadrature du Net pour la légalisation des échanges non-marchands et la mise en place de solutions de financement mutualisées pour la création, comme la contribution créative ou le revenu de base.

Néanmoins, je pense que le domaine public peut constituer un bon angle d’attaque pour s’engager dans une réforme positive de la propriété intellectuelle. On a un peu l’impression d’être aujourd’hui face à une forteresse imprenable et on n’arrive pas à sortir des débats autour de la répression du partage des œuvres, qui continuent à monopoliser l’attention du législateur comme on le voit bien avec les travaux de la mission Lescure. C’est pourquoi il me paraît intéressant d’ouvrir de nouveaux fronts qui permettront de défendre l’idée que nous possédons des droits positifs sur la culture. Le domaine public peut être une piste en ce sens et j’ai fait des propositions de réforme législative pour consacrer et renforcer cette notion dans le Code de Propriété Intellectuelle.

Par ailleurs, tu évoques le Copyright Madness, mais le domaine public pourrait aussi être un moyen de lutter contre les pires dérapages de la propriété intellectuelle. On a vu par exemple récemment des laboratoires pharmaceutiques déposer valablement des brevets en Australie sur les gènes responsables du cancer du sein, ce qui est absolument terrifiant puisque cela signifie que tout chercheur qui voudra mettre au point un remède devra leur verser des royalties. Aux États-Unis, Monsanto a relancé une offensive en justice pour empêcher des agriculteurs de replanter des semences de variétés brevetées et l’entreprise semble en passe de l’emporter. Cela peut avoir des conséquences dramatiques au niveau mondial.

Ces dérives ont un lien avec le domaine public, parce que celui-ci ne contient pas seulement les œuvres anciennes, mais aussi tout ce qui ne devrait pas pouvoir faire l’objet d’une appropriation exclusive. Cela vaut pour certains éléments de la Culture, mais aussi pour des choses aussi essentielles que le génome humain ou les semences.

Le domaine public devrait être le bouclier qui protège tous ces éléments fondamentaux de la folie de l’appropriation, mais c’est à nous de le promouvoir et de le faire vivre pour qu’il puisse remplir ce rôle.

Je crois qu’on ne peut pas trouver de meilleure conclusion ! Merci à toi, Calimaq.

Sources :

• Le piratage sert la promotion, selon l’un des réalisateurs de Game of Thrones (Numerama)
• Imminent Ned / Brace Yourselves, X is Coming (Know Your Meme)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

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

Traduction Framalang : satanas_g, Sphinx, Sky, Julius22, peupleLà, lamessen, goofy

Du débutant au professionnel

Jonathan Riddell

Jonathan Riddell est développeur KDE et Kubuntu, actuellement employé par Canonical. Quand il n’est pas devant un ordinateur, il fait du canoë sur les rivières d’Écosse.

Il y avait un bogue dans le code. Un bien méchant en plus : un plantage sans enregistrement des données. C’est bien là le problème dès qu’on regarde le code, on trouve des trucs à réparer. C’est facile de s’impliquer dans le logiciel libre ; le plus dur est d’en sortir. Après le premier bogue réparé, il y en a d’autres, et de plus en plus, tous à portée de main. Les corrections de bogues mènent à l’ajout de fonctionnalités, ce qui mène à la maintenance de projet, ce qui mène à faire fonctionner une communauté.

Tout a commencé en lisant Slashdot, cette masse d’actualité geek et technique peu filtrée avec des commentaires de quiconque peut recharger assez vite pour être en haut de liste. Chaque actualité était intéressante et excitante, apportait un éclairage nouveau sur le monde de la technologie qui finissait par me fasciner. Je n’avais plus à accepter ce qui m’était donné par de grandes entreprises de logiciels, je pouvais voir là, dans la communauté du logiciel libre, le code se développer devant moi.

En tant qu’étudiant, il était possible de finir les exercices donnés par les professeurs très rapidement. Mais les exercices ne sont pas des programmes terminés. Je voulais savoir comment appliquer les compétences basiques qu’ils m’avaient données dans le monde réel en écrivant des programmes résolvant des problèmes réels pour les gens. J’ai donc recherché du code, qui n’était pas difficile à trouver, il se trouvait là, sur Internet, en fait. En regardant le code des programmes que j’utilisais de plus près, j’y ai décelé de la beauté. Non pas parce que le code était parfaitement soigné ou bien structuré, mais parce que je pouvais le comprendre avec les concepts que j’avais déjà appris. Ces classes, méthodes et variables étaient bien en place, me permettant de résoudre les problèmes pertinents. Le logiciel libre est le meilleur moyen de franchir le pas entre savoir comment finir ses exercices de cours et comprendre comment de vrais programmes sont écrits.

Tous les étudiants en informatique devraient travailler sur du logiciel libre comme sujet de leur mémoire. Sinon, vous avez de grandes chances d’y passer six mois à un an pour qu’il finisse au sous-sol d’une bibliothèque sans être jamais plus consulté. Seul le logiciel libre permet d’exceller en faisant ce qui va de soi : vouloir apprendre comment résoudre des problèmes intéressants. À la fin de mon projet, des programmeurs de la NASA utilisaient mon outil de création de diagrammes en UML (NdT : langage de modélisation unifié) et il reçut des prix au cours de réceptions somptueuses. Avec le logiciel libre, on peut résoudre de vrais problèmes pour de vrais utilisateurs.

La communauté des développeurs est remplie de personnes formidables, passionnées et dévouées à leur travail, sans espoir autre de récompense qu’un programme d’ordinateur couronné de succès. La communauté des utilisateurs est également incroyable. Il est satisfaisant de savoir qu’on a aidé quelqu’un à résoudre un problème. Et j’apprécie les messages de remerciement que je reçois.

Après avoir écrit un logiciel utile, il faut le mettre à la disposition du plus grand nombre. Le code source ne va pas fonctionner pour la plupart des gens, il doit être compilé. Avant d’être impliqué, je trouvais que le fait de compiler était une manière un peu paresseuse de contribuer au logiciel libre. Vous vous attirez la plus grande partie de la reconnaissance sans rien avoir à coder. C’est, quelque part, quelque chose d’injuste. De même, la gestion de la communauté nécessaire pour porter un projet de logiciel libre peut aussi être vue comme une façon de s’attirer la reconnaissance sans faire de code.

Les utilisateurs dépendent beaucoup des packagers (NdT : les « empaqueteurs » qui préparent et maintiennent les paquets logiciels). Il est nécessaire que leur travail soit à la fois rapide, pour satisfaire ceux qui veulent la dernière version, et fiable, pour ceux qui veulent la stabilité (autant dire tout le monde). La partie la plus délicate, c’est que cela implique de travailler avec les logiciels des autres, qui sont toujours « cassés ». Une fois que le logiciel est lâché dans la nature, commencent à emerger des problèmes qui n’étaient pas repérables sur l’ordinateur de l’auteur. Il est possible que le code ne puisse pas être compilé avec une version de compilateur différente, peut-être que la licence n’est pas claire et ne permet pas de le copier, peut-être que la gestion des versions est incohérente et qu’une mise à jour mineure est incompatible, ou encore que la taille de l’écran est différente, les environnements de bureau peuvent aussi l’affecter, quelquefois, des bibliothèques tierces nécessaires ne sont pas encore à jour. De nos jours, le logiciel doit pouvoir tourner sur différentes architectures. Les processeurs 64 bits ont occasionné pas mal de problèmes quand ils sont devenus courants. Aujourd’hui, ce sont les processeurs ARM qui déjouent les calculs des codeurs. Les packagers doivent régler tous ces problèmes pour donner aux utilisateurs quelque chose qui fonctionne de façon fiable.

Nous avons une règle chez Ubuntu selon laquelle les paquets avec des tests unitaires doivent inclure ces mêmes tests dans le processus de la création des paquets. Souvent, ils échouent et l’auteur du logiciel nous dit que les tests sont uniquement à son usage. Malheureusement, quand il s’agit de logiciel, il n’est jamais assez fiable de le tester soi-même, il doit aussi être testé par d’autres. Un test unique est rarement suffisant, il faut une approche à plusieurs niveaux. Les tests unitaires du programme original devraient être le point de départ, ensuite, le packager les teste sur son propre ordinateur, il faut ensuite que d’autres personnes les testent aussi. L’installation automatique et les tests de mise à jour peuvent être scriptés assez correctement sur les services d’informatique dans le nuage. L’envoyer dans la branche de développement d’une distribution permet d’effectuer plus de tests avant de le voir distribué en masse quelques mois après. À chaque étape, des problèmes peuvent être et seront découverts, ils devront être corrigés, puis ces correctifs eux-mêmes devront être testés. Il n’y a donc pas forcément à écrire beaucoup de code, mais il y a pas mal de travail pour passer le logiciel de 95 % à 100 % prêt. Ces 5 % sont la partie la plus difficile, un lent et délicat processus qui demande une grande attention pendant tout son cours.

Vous ne pouvez pas faire de paquets sans une bonne communication avec les développeurs en amont. Quand des bogues se produisent, il est vital de pouvoir trouver la bonne personne à laquelle parler rapidement. Il est important d’apprendre à bien les connaître comme des amis et des collègues. Les conférences sont vitales pour cela, car rencontrer quelqu’un apporte beaucoup plus de contexte à un message sur une liste de diffusion qu’une année entière de messages.

Une des faces cachées du monde du logiciel libre réside dans la communication par les canaux IRC privés utilisés par les principaux membres d’un projet. Tous les grands projets en ont. Quelque part, Linus Torvalds a un moyen de discuter avec Andrew Morton et les autres sur ce qui est bon et sur ce qui est mauvais dans Linux. Ils sont plus sociaux que techniques et, quand on en abuse, ils peuvent être très antisociaux pour la communauté en général. Mais pour les moments où on a besoin d’un canal de communication rapide sans bruit parasite, ils fonctionnent bien.

Tenir un blog est un autre moyen de communication important dans la communauté du logiciel libre. C’est notre principale méthode pour promouvoir à la fois le logiciel que nous produisons et nous-mêmes. Non pas que ce soit utilisé éhontément pour de l’auto-promotion (il est inutile de prétendre que vous sauverez des vies avec votre blog…), mais parler de votre travail sur le logiciel libre aide à construire une communauté. Cela peut même vous valoir de trouver un travail ou d’être reconnu dans la rue.

Ces histoires venant de Slashdot, à propos de développements de nouvelles technologies, ne concernent pas des personnalités éloignées que vous ne rencontrerez jamais comme dans la presse people. Elles concernent des personnes qui ont trouvé un problème et qui l’ont résolu en utilisant l’ordinateur qu’elles avaient en face d’elles. Pendant quelques années, j’ai édité le site d’informations de KDE, trouvant les personnes qui résolvaient des problèmes, créaient des idées novatrices, s’acharnaient longuement à améliorer un logiciel jusqu’à ce qu’il soit d’une qualité suffisante, et j’en parlais au monde entier. Je n’ai jamais été à court d’histoires à raconter ni de personnes à présenter à tout le monde.

Mon dernier conseil est de conserver de la diversité. Il existe une telle richesse de projets intéressants à explorer, qui vous permettent d’apprendre et de progresser. Mais une fois que vous avez atteint une position de responsabilité, il peut être tentant d’y rester. Après avoir aidé à créer une communauté pour Kubuntu, je repars temporairement vers un travail sur Bazaar, un projet très différent, orienté sur les développeurs plutôt que sur des utilisateurs novices en technologies. Je peux à nouveau apprendre comment le code devient une réalité utile, comment une communauté communique, comment la qualité est maintenue. Ce sera un défi amusant et j’ai hâte de m’y attaquer.

Breaking news…nouvelles cassantes…molto straordinario…Donner und Blitzen…urbi et orbi

Nous vous avions pourtant mis en garde, mais rien n’y a fait : bien avant la date limite qu’il avait ululée, Pouhiou a récolté les 2200 € qui vont servir à rendre son premier tome du cycle des Noénautes non seulement libre (il est déjà en CC0) mais en plus gratuit !

Et ça continue… Plus on contribue et plus nombreux seront les livres libérés !

On attend dans les prochaines heures le témoignage d’une victime collatérale – restez tunés !

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

Traduction Framablog : Sphinx, purplepsycho, Cyrille L., lamessen

Ce que je suis contente de ne pas avoir su

Alexandra Leisse

Alexendra Leisse a quitté une scène pour en rejoindre une autre. Elle a transformé son autre passion (les logiciels et le Web) en un métier. Après une période de transition de douze mois en freelance dans le logiciel et l’opéra — et noyée par de nombreuses heures d’activités dédiées à KDE, elle a rejoint Nokia et le développement de la plateforme Qt en tant que gestionnaire de la communauté Web. C’est la femme derrière le réseau de développement Qt et les activités de sa communauté sur la toile. Bien qu’elle soit diplômée en art lyrique, elle refuse la plupart du temps de chanter en public.

Introduction

Quand Lydia m’a demandé de rejoindre son projet de livre sous-titré « les choses que j’aurais voulu savoir », mon esprit est resté vide. Les choses que j’aurais voulu savoir mais que je ne savais pas ? Rien ne me venait à l’esprit.

Je ne dis pas que je n’aie pas eu besoin de savoir quoi que ce soit, au contraire. J’ai eu beaucoup à apprendre et j’ai fait un nombre incalculable d’erreurs. Mais les situations ou les erreurs que j’aurais voulu éviter ? Je n’arrive pas à y penser.

Nous avons tous cette fâcheuse tendance à regarder les choses que nous pourrions mieux faire, les choses que nous ne savons pas, et nous les voyons comme des faiblesses. Mais que dire des faiblesses qui sont des atouts ?

Voici ma propre histoire sur l’ignorance, la naïveté, les mauvaises impressions et comme je suis heureuse de ne pas en avoir eu la moindre idée.

Les noms

Je n’avais aucune idée de qui était ce gars que j’avais rencontré lors de mon premier jour de travail. Il est entré dans la pièce, s’est présenté et a commencé à poser des questions me donnant l’impression que tout ce que je penserais serait insensé. Il était apparemment bien renseigné sur ce que je faisais sur KDE et les personnes que je côtoyais. Cependant, nos points de vue sur le sujet semblaient différents. À un moment, ses provocations ont fini par me fatiguer et j’ai perdu patience. Je lui ai alors dit qu’avec les personnes, ce n’était pas toujours aussi facile que les ingénieurs l’imaginent.

Juste après son départ après une heure de discussion, j’ai cherché son nom sur Google : Matthias Ettrich. Ce que j’ai lu m’a expliqué pourquoi il avait posé ces questions. Si j’avais su avant qu’il était un des fondateurs du projet KDE, j’aurais débattu avec lui d’une manière bien différente, voire pas du tout.

Ces dernières années, j’ai dû chercher quelques noms et à chaque fois, j’ai été heureuse de le faire après le premier contact.

C’est probablement mon idée la plus importante. Lorsque j’ai rencontré toutes ces personnalités du Libre et de l’open source pour la première fois, je n’avais jamais entendu leurs noms auparavant. Je ne savais rien de leurs histoires, mérites ou échecs. J’ai approché tout le monde de la même façon : le contact visuel. En étant ignorante (ou naïve selon certains), je ne me sentais pas inférieure par rapport aux personnes que je rencontrais lorsque j’ai commencé mon aventure au sein du Libre et de l’open source. Je savais que j’avais beaucoup à apprendre mais je n’ai jamais eu l’impression d’avoir un rang inférieur aux autres en tant qu’individu.

« Projet de grande envergure »

Je n’avais pas suivi religieusement dot.kde.org ni PlanetKDE et encore moins ces innombrables publications liées au Libre et à l’open source, avant de commencer à m’intéresser à ce qui se passait sur les listes de diffusion KDE. Je voyais ces canaux avant tout comme moyen de communiquer avec un public choisi, principalement des utilisateurs et des contributeurs du projet en tant que tel.

Pendant un certain temps, je n’avais pas conscience que les articles que je publiais sur The Dot pourraient être repris par des journalistes. Je m’appliquais à les écrire parce que je voulais faire du bon boulot et non pas parce que j’avais peur de passer pour folle auprès du reste du monde. La liste de presse était maintenue par d’autres personnes et ce que j’écrivais ne me paraissait pas important non plus. Je voulais toucher certaines personnes. Pour cela les canaux officiels et mon propre blog me semblaient être les moyens les plus efficaces.

Être citée sur ReadWriteWeb après avoir annoncé sur mon blog que je commencerai un nouveau boulot fut un choc pour moi. Non pas parce que j’ignorais que des gens lisaient ce que j’écrivais (j’espérais bien qu’ils le lisent !) mais je ne m’attendais pas à ce que ça soit un sujet d’une telle importance. Ce n’était même pas pendant les vacances d’été. Encore heureux que personne ne me l’ait dit, je n’aurais pas été capable de publier ne serait-ce qu’une seule ligne.

L’œil étranger

Il y a quelque temps, quand j’ai assisté à ma première conférence, j’avais la ferme conviction que j’étais différente des autres participants. je me voyais comme une étrangère parce que je n’avais pas grand-chose en commun avec qui que ce soit à part un vague intérêt pour la technologie : je travaillais en freelance depuis quelques années déjà, après mon diplôme universitaire ; je n’avais aucune éducation pertinente dans le domaine, et j’étais mère d’un enfant de 10 ans. Sur le papier en tout cas, il ne pouvait pas y avoir plus éloignée des suspects habituels qu’on rencontre dans les projets FOSS.

En 2008 j’ai assisté à un sprint (NdT : phase de développement, généralement perçue comme intense, aboutissant à un produit fonctionnel) KOffice au sein de l’équipe promotion et marketing de KDE pour préparer la sortie de la version 2.0. L’idée initiale était d’esquisser une série d’activités promotionnelles autour de cette sortie afin de développer à la fois le support développeur et utilisateur. Pour celui-ci, nous étions trois à suivre un chemin parallèle à celui concernant les développeurs.

Nous avons essayé de comprendre comment nous pourrions positionner KOffice et adapter la communication au public ciblé. Très tôt dans le processus, nous avons découvert que nous devions faire marche arrière : à ce stade, le manque de maturité de la suite rendait impossible son positionnement comme option pour les utilisateurs non avertis. Nous devions nous en tenir aux développeurs et aux précurseurs. C’était difficile à vendre à certains développeurs, mais en tant qu’étrangers nous avions la chance de regarder le logiciel sans penser à tout le sang, la sueur et les larmes versés dans le code.

Pour beaucoup de projets, de n’importe quelle sorte, jeter un œil objectif à la situation donne du fil à retordre aux contributeurs principaux. Nous avons tendance à ne pas voir les grands succès quand nous sommes très concentrés sur des problèmes de détails et réciproquement. Parfois, nous manquons une occasion parce que nous pensons que ça n’a rien à voir avec ce que nous faisons (ou, pour commencer, parce que personne ne voudrait que ça ait quelque chose à voir).

Dans tous ces cas, les contributeurs extérieurs au projet ont le potentiel pour apporter des points de vue différents à la discussion, particulièrement quand il s’agit de déterminer un ordre de priorité. C’est encore plus utile quand ce ne sont pas des développeurs : ils poseront différentes questions, sans ressentir de pression face à la connaissance et à la compréhension de tous les détails techniques ; ils peuvent aussi aider pour les décisions ou la communication sur un plan moins technique.

Conclusion

L’ignorance est une bénédiction. Ce n’est pas seulement vrai pour les individus qui profitent de l’insouciance qui en résulte mais aussi pour les projets que ces individus rejoignent. Ils apportent différents points de vues et expériences.

Et maintenant, filez et trouvez vous-même un projet qui vous intéresse, indépendamment de ce que vous pensez savoir.

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

Traduction Framalang : Lycoris, grosfar, merlin8282, 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

Sources :

• Le gouvernement compte revoir le cadre de la liberté d’expression (Numerama)
• Vu du Sénat # 23: La liberté sur internet, c’est quoi au juste ? (Le Huffington Post)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)