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

Libre ou propriétaire, open source ou sources closes, voilà des lignes de fracture radicales qui sont familières dans le monde du logiciel. Les choses sont moins tranchées peut-être du côté des entreprises qui se définissent non sans arrière-pensées comme plus ou moins « ouvertes ».

Tim Wu nous invite à prendre un peu de recul par rapport à notre conception commune suivant laquelle les modèles ouverts sont destinés à l’emporter. La réussite ou non des grandes entreprises de technologies informatiques ces dernières années montre que la question n’est pas si simple et la partition pas si flagrante.

En adoptant une perspective bien étatsunienne, celle du pragmatisme qui consiste à comparer les résultats, l’auteur tend à évaluer l’ouverture en termes de degrés. À vous de dire si les valeurs du libre ne sont pas écornées au passage.

Une entreprise fermée comme Apple peut-elle réussir sans le talent d’un Steve Jobs ?

par Tim Wu dans cet article du New Yorker

Traduction Framasoft : Texmix, Sphinx, Garburst, Husi10, lamessen, Paul-Arthur, ehsavoie, goofy

On dit depuis un bon moment dans le milieu techno que « le modèle ouvert l’emporte sur le modèle fermé ». En d’autres termes, les systèmes technologiques ouverts, ou bien ceux qui permettent l’interopérabilité, finissent toujours par surpasser leurs concurrents fermés. C’est une véritable profession de foi chez certains ingénieurs. C’est aussi la leçon qu’on peut tirer de l’échec de MacIntosh face à Windows dans les années 90, du triomphe de Google au début des années 2000 et plus largement, de la victoire d’Internet sur ses rivaux au modèle fermé (vous souvenez-vous d’AOL ?). Mais est-ce encore justifié ?

Depuis quelques années, cet adage a été remis en question, principalement à cause d’Apple. Cette entreprise, ignorant les idéaux des ingénieurs et les prêches des experts techno, s’est rapidement cloisonnée dans une une stratégie semi-fermée — ou « intégrée » comme elle aime à le dire — et a défié la règle. Sur le plan structurel, Apple pratique l’intégration bien mieux que ses rivales. Elle possède le matériel, le logiciel et le circuit de distribution. Elle bloque et dessert également beaucoup plus ses concurrents. Eh oui, de cette manière, elle est devenue l’entreprise la plus rentable la planète. Au dernier trimestre, Apple a enregistré plus de bénéfices qu’Amazon n’en a réalisé depuis sa création.

Mais maintenant, depuis les six derniers mois, de manière plus ou moins flagrante, Apple a commencé à trébucher. Vous allez dire que j’exagère, mais je propose une révision du vieil adage « le modèle fermé peut l’emporter, mais vous devez être un génie ». Dans des conditions normales, dans une industrie imprévisible, et étant donné le niveau normal d’erreurs humaines, le libre continue à surpasser le fermé. Pour le dire autrement, une entreprise doit être fermée dans l’exacte proportion de ses talents de visionnaire et de conception.

Pour m’expliquer, je vais d’abord devoir soigneusement exposer ce que j’entends par « ouvert » et « fermé », des mots qui sont largement employés dans le monde de l’informatique, mais avec de multiples sens. La vérité c’est qu’aucune des entreprises n’est complètement ouverte ou fermée ; elles se répartissent sur un spectre, un peu comme celui qu’utilisait Alfred Kinsey pour décrire la sexualité humaine. Pour moi, ici, cela signifie la combinaison de trois éléments.

Tout d’abord, « ouvert » et « fermé » peuvent faire référence à la permissivité de l’entreprise technologique vis-à-vis des partenariats et des interconnexions qu’elle peut créer pour que ses produits arrivent jusqu’aux utilisateurs. Nous disons qu’un système d’exploitation comme GNU/Linux est « ouvert » parce que n’importe qui peut concevoir un produit sur lequel faire tourner GNU/Linux. En revanche, Apple est très exclusif : il ne laissera jamais iOS s’exécuter sur un téléphone Samsung ni vendre des Kindle dans un Apple store.

En second lieu, l’ouverture peut décrire l’impartialité avec laquelle une entreprise technologique traite les autres entreprises par rapport la manière dont elle se traite elle-même. Firefox, le navigateur, traite tous les sites internet de la même manière. En revanche, Apple se traite mieux que les autres (essayez donc de désinstaller iTunes de votre iPhone).

Troisièmement, et pour conclure, cela décrit le niveau de transparence et d’ouverture d’une entreprise selon la manière dont ses produits fonctionnent et peuvent être employés. Les produits open source, ou ceux qui dépendent de standards ouverts, rendent leur code largement accessible. En attendant, une compagnie comme Google peut être ouverte sur bien des points mais garder jalousement le secret sur certaines choses, comme le code de son moteur de recherche. Dans le monde des technologies, la métaphore classique utilisée pour décrire cette dernière différence est la cathédrale contre le bazar.

Aucune entreprise privée n’est entièrement ouverte, bien que quelques fondations à but non-lucratif, comme Mozilla, s’en approchent. De la même manière, aucune entreprise ne peut se permettre d’être entièrement fermée. Un exploitant de plateforme gagne à avoir de bonnes applications disponibles (pensons à ce que serait, hum, l’iPhone sans Google Maps), et trop bloquer détruira ce qui donne sa valeur au produit. Même Apple a besoin d’être assez ouvert pour ne pas trop déranger les consommateurs. Vous ne pouvez pas lancer le Flash d’Adobe sur un IPad, mais vous pouvez brancher presque n’importe quel type d’écouteur dessus.

L’idée que « le modèle ouvert l’emporte sur le modèle fermé » est historiquement assez récente. Dans la majeure partie du XX^e siècle, l’intégration était considérée comme la forme d’organisation commerciale supérieure. Les modèles fermés ou intégrés arrivent avec des avantages reconnus depuis longtemps et même proclamés haut et fort par les économistes. La coordination est un avantage-clé : en théorie, avec une entreprise qui coordonne tous les aspects et caractéristiques d’un produit donné, le résultat peut mieux fonctionner que celui d’un rival non-coordonné. L’économiste Joseph Farell a appelé ceci « internalisation des économies complémentaires ». Si cela ne vous dit rien, considérez l’effet Disneyland. Disney contrôle tout avec une poigne de fer ou presque, et le parc d’attractions fonctionne sans anicroches, avec une réussite impressionnante bien supérieure par exemple à une fête foraine classique.

Andrew Carnegie s’est appuyé sur une logique similaire à celle d’Apple lorsqu’il a intégré l’extraction minière avec la production d’acier au sein de U.S. Steel. Les vieux studios Hollywood des années trente et quarante ont intégré le jeu, les scénarios, la production et les cinémas dans une seule et même entreprise. Elle a ainsi chassé tous les autres de son industrie. I.B.M. avait un modèle fermé et le vieux monopole de A.T. & T. était le système fermé par excellence : vous n’aviez pas le droit de posséder votre propre téléphone mais seulement d’en utiliser un produit par quelqu’un d’autre.

La sagesse populaire commença à changer dans les années soixante-dix. Sur le marché des technologies, des années quatre-vingt au milieu des années deux mille, les systèmes ouverts ont vaincu à plusieurs reprises leurs concurrents fermés. Windows de Microsoft a battu ses rivaux en adoptant un modèle plus ouvert. À la différence du système d’exploitation d’Apple qui était supérieur sur le plan technique, Windows fonctionnait sur n’importe quel matériel et faisait marcher presque tous les logiciels. Au même moment, Microsoft surpassa I.B.M. et son modèle intégré verticalement (qui se souvient de Warp O.S. ?), Google était audacieusement ouvert dès sa conception originale et passa devant Yahoo et son système sélectif de publicité au placement. La plupart des vainqueurs, entre quatre-vingt et deux mille, tels que Microsoft, Dell, Palm, Google et Netscape, suivaient un modèle ouvert. Internet même, basé sur un projet financé par le gouvernement, était à la fois incroyablement ouvert et incroyablement réussi. Un mouvement était né et avec lui la règle selon laquelle : « le modèle ouvert l’emporte sur le modèle fermé ».

Le triomphe des systèmes ouverts a révélé un défaut majeur dans les conceptions fermées. Selon la théorie économique, dans un état d’information parfaite, un concepteur central devrait être capable de produire un meilleur produit. Mais c’est seulement vrai si le futur est prévisible, et si on ignore la tendance des êtres humains à commettre des erreurs bêtes. Dans un système fermé, avec un seul décideur, les erreurs coûtent très cher. Les décisions stupides, ou qui compromettent le produit pour des profits à court terme, ne vont pas rendre les produits seulement un peu moins bons mais vraiment pires que ceux du concurrent direct. Par exemple, la politique de chasse gardée d’AOL des années 90 consistait à essayer de deviner ce que les utilisateurs allaient vouloir, mais AOL a fait un tas d’erreurs, et finalement ça ne correspondait pas à un Web ouvert.

En revanche, un produit ouvert est mieux protégé des erreurs humaines car ce n’est pas une unique entité qui prend une décision susceptible de détruire le produit. Les économistes Tim Bresnahan et Shane Greenstein, dans les années 90, ont décrit ce phénomène sous le terme « direction technique partagée », et ils lui donnaient un sens mélioratif. Le produit est le résultat collectif de plusieurs, voire parfois de milliers de décideurs. Un produit ouvert peut aussi profiter des contributions volontaires et collectives des masses, un point mis en avant par Yochai Benkler. Ainsi, une entrée sur Wikipédia peut être vague et contenir des erreurs, mais le corpus dans son ensemble restera impressionnant. Au milieu des années 90, Windows n’était pas aussi intuitif que Macintosh, mais tous les accessoires et les applications en firent collectivement un produit supérieur.

Ce qui nous amène aux années 2000 et au magnifique parcours d’Apple. Pendant presque douze années, Apple a battu la mesure avec succès. Mais c’est parce qu’il avait le meilleur des systèmes possibles, à savoir, un dictateur disposant d’un contrôle absolu, qui était aussi un génie. Steve Jobs était la version entreprise de l’idéal de Platon : le roi-philosophe nettement plus efficace que toute forme de démocratie. L’entreprise dépendait d’un unique esprit central, mais il a fait très peu d’erreurs. Dans un monde sans erreurs, le fermé bat l’ouvert. En conséquence, pour un temps, Apple triompha de ses rivaux.

Alors que doit faire une entreprise technologique ?

Chacun est confronté à cette question du modèle ouvert ou fermé, et voici comment y répondre. Premièrement, il existera toujours un compromis difficile entre systèmes ouverts et fermés, et il est donc inutile de trop s’enfermer dans l’une ou l’autre des options. Il est facile de sous-estimer les projets ouverts (personne ne pensait que Wikipédia fonctionnerait), mais même les projets ouverts ont besoin de contrôle à certains niveaux. Finalement, plus votre vision et vos compétences de créateur sont bonnes, plus vous pouvez essayer d’être fermé. Si vous pensez que vos concepteurs de produits peuvent égaler le quasi sans-faute de Jobs ces vingt dernières années, allez-y. Mais si de simples mortels font tourner votre entreprise, ou si vous êtes face à un futur très imprévisible, les analyses économiques suggèrent qu’un système ouvert est plus sûr. Vous pourriez peut-être vous fier à ce test : en vous levant le matin, regardez dans le miroir et demandez-vous : suis-je Steve Jobs ?

Crédit image : the opensourceway CC-BY-SA

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., lerouge, Lycoris, 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.

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

Traduction Framasoft :peupleLà, elquan, tcit, Julius22, Garburst, okram, Jej, Cyrille L., lerouge, Lycoris, Goofy, CoudCoud, vvision, lamessen

Du bon usage de la couleur et des images dans le design

Eugene Trounev

Membre actif du logiciel libre et de KDE depuis près de six ans, Eugene Trounev a commencé chez KDEGames et a poursuivi pendant l’ensemble de la transition de KDE3 à KDE4. Il a participé à toute la transition de KDE3 vers KDE4. Actuellement, il s’occupe principalement de la présence de KDE sur le Web et de l’apparence du bureau principal.

Depuis la nuit des temps, les hommes ont utilisé la puissance des images et de la couleur pour transmettre des informations, attirer l’attention ou la détourner. Un célèbre dicton dit « une image vaut mille mots » et on ne saurait mieux dire. Depuis la façon dont nous nous habillons jusqu’aux néons criards des magasins de centre-ville dans le monde entier, chaque couleur, chaque forme et chaque courbe joue un rôle.

Connaître ce rôle n’est cependant pas si difficile, puisque toutes ces variations de teintes et de lignes sont assemblées pour être lues et ressenties par chacun de nous. Il est donc vrai qu’un design génial doit venir droit du cœur, étant donné qu’il est censé parler d’abord au cœur. Néanmoins, le cœur seul ne pourrait pas produire un design génial si quelques règles n’étaient pas d’abord définies et respectées.

Il existe plusieurs façons de classer les couleurs, mais la plupart mettent en avant les propriétés physiques ou chimiques de la lumière ou de l’encre. Bien que cela soit important pour le résultat final, ces propriétés ne vous aideront pas à faire un design attrayant. Ce qui fonctionne le mieux, selon moi, est de séparer entre couleurs chaudes et couleurs froides. Pour faire simple, les couleurs chaudes sont celles qui sont les plus proches de la teinte rouge : le rouge, l’orange et le jaune. Les couleurs froides, à l’opposée du spectre, sont celles qui se rapprochent du bleu : le vert, le bleu et, dans une moindre mesure, le violet. Il est important de se rappeler que « froid » représente aussi le calme et la respiration, tandis que « chaud » est impulsif et dangereux. Ainsi, en fonction des sentiments que vous souhaitez éveiller au sein de votre public, vous devriez utiliser des couleurs plus chaudes ou plus froides. Des couleurs chaudes pour attirer l’attention ; des couleurs froides pour informer. Une utilisation excessive de l’une ou de l’autre aboutira soit à une surchauffe — provoquant des sentiments négatifs chez votre public — soit à un refroidissement — ce qui causera son indifférence.

Il est important de se souvenir que le noir, le blanc et les nuances de gris sont aussi des couleurs. Celles-ci, toutefois, sont neutres. Elles ne provoquent aucun sentiment mais établissent plutôt une atmosphère. Leurs propriétés seront discutées plus loin.

Chaque image est d’abord et avant tout une collection de couleurs et, en tant que telle, suivra les règles de la gestion des couleurs. Déterminer la couleur dominante de votre image est la clé du succès. Essayez d’avoir une vue d’ensemble, sans vous concentrer sur les détails. Une bonne manière de le faire consiste à placer une image sur un fond sombre, puis à se reculer de quelques pas et de l’observer de loin. Quelle couleur percevez-vous le plus ?

Toutefois, toutes les images n’ont pas une couleur dominante. Quelquefois, vous rencontrez un amas de couleurs dont vous ne pouvez déterminer la teinte dominante, quelle que soit l’intensité avec laquelle vous le regardez. Essayez d’éviter de telles illustrations car elles vont inévitablement déconcerter vos utilisateurs. Confrontés à des images de ce type, les gens auront tendance à rapidement regarder ailleurs et cela ne leur laissera pas bonne impression, quel que soit le sujet abordé.

Au delà de la couleur, les images ont aussi une texture car, en fin de compte, elles ne sont rien de plus qu’un ensemble de couleurs texturées. Identifier la texture dominante d’une image n’est pas aussi simple que de percevoir sa couleur car les textures sont rarement évidentes, particulièrement dans les photographies. Il existe néanmoins quelques indicateurs pouvant vous aider. La nature humaine fait que nous sommes attirés par les formes incurvées (aussi appelées formes « naturelles ») tandis que les formes anguleuses et effilées sont considérées comme moins attirantes. C’est pour cela que l’image d’une feuille verte et incurvée sera plus attirante que celle d’un pic en métal. Pour résumer : la clé d’un design réussi et séduisant est une bonne combinaison, correctement équilibrée, entre couleurs et textures au sein des images utilisées.

Un autre aspect aussi important de tout design réussi est la mise en forme du texte et la disposition des espaces autour de celui-ci. Tout comme pour les textures et les couleurs, vous devriez toujours garder à l’esprit que les gens aiment respirer. Cela signifie qu’il devrait y avoir suffisamment d’espace dans et autour du texte pour le rendre plus facilement repérable, lisible et compréhensible.

Imaginez un exemple constitué de deux pages — l’une venant d’un roman d’amour tandis que l’autre est tirée d’un document légal. Vous préféreriez très probablement le roman d’amour par rapport à un document légal quel que soit le moment. Mais savez-vous pourquoi ? La réponse est simplement que vous aimez respirer. Une page de roman d’amour contient vraisemblablement trois éléments importants : des dialogues, des paragraphes et des marges extra-larges, tandis que la plupart des documents légaux ne comportent d’ordinaire aucun des trois. Tous les éléments mentionnés ci-dessus font vivre la page et la rendent dynamique, tandis qu’en leur absence, la page ressemble à un gros pavé de texte. L’œil humain, étant plus habitué à un certain degré de variation de formes, se sent plus à l’aise lorsque les pages bénéficient d’une mise en page aérée et fluide.

Toutefois, cela n’implique pas que chaque texte doive avoir ces trois éléments pour avoir l’air plus attrayant, loin de là. Tout texte peut être rendu facile et agréable à lire en l’aérant suffisamment.

Un peu de respiration ou d’espace peut être injecté au texte de plusieurs manières, telles que l’espacement des lettres, des lignes et des paragraphes ; les marges du contenu, de la section et de la page ; et pour finir, la taille de la police. Essayez de garder une espace d’au moins un caractère de haut entre vos paragraphes et vos lignes ainsi que des espaces de deux caractères de haut entre vos sections. Autorisez-vous des espaces généreux autour du texte sur une page en cadrant assez largement vos marges. Essayez de ne jamais avoir une taille de police inférieure à 10 points pour vos paragraphes tout en gardant les titres assez gros pour les faire ressortir.

Tout comme les animaux, les êtres humains sont souvent attirés par les éclats de couleurs brillantes et les textures inhabituelles. Plus le regard est attiré, plus les personnes ignoreront d’autres points d’intérêt potentiels. Cette simple règle de l’attraction est utilisée indifféremment par les hommes et les femmes pour canaliser l’attention des autres loin de certains éléments qui doivent selon eux passer inaperçus. Le meilleur exemple d’une telle supercherie est celui d’un magicien de rue qui distrait souvent l’attention des spectateurs par l’utilisation de fumée, de flammes ou de tenues tape-à-l’œil.

Il est important, ici, de se rappeler que les mots sont aussi visuels puisqu’ils créent des images et des associations spécifiques. La supercherie qui peut être réalisée avec de la fumée et du feu peut également être accomplie par le biais d’une utilisation créative des mots. Le meilleur exemple de supercherie quotidiennement réalisée grâce aux mots est, de loin, celle des étiquettes de prix. Vous êtes-vous déjà demandé pourquoi les commerçants aimaient autant les 99 et les 95 centimes ? C’est parce que les 9,95€, ou même les 9,99€, semblent plus attractifs que 10€, même si, dans la réalité, ils ont le même impact sur votre porte-monnaie. Ajoutez-y une « vieille » étiquette de prix à 10€ ostensiblement barrée d’une épaisse ligne rouge et vous aurez un bon aimant à clients.

Conclusion

L’obtention d’un design à la fois beau et attractif passe par ces règles de base : soyez judicieux dans vos choix iconographiques ; faites un bon usage des couleurs et des textures pour créer une atmosphère ; donnez à votre lecteur des espaces pour respirer ; détournez l’attention des parties qui comptent le moins pour l’amener sur celles qui sont importantes.

Ce court article n’entend pas couvrir toute l’étendue du spectre des différents styles et techniques de design. Il s’agit plutôt de vous donner à vous lecteur une base sur laquelle vous pourrez vous appuyer pour construire.

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

Traduction Framasoft : Miki, peupleLà, dabou, Asta, elquan, Goofy, Julius22, okram, lamessen, Jej, lerouge, SaSha_01, Lycoris, meumeul, vvision

Ne soyez pas timide

Máirín Duffy Strode

Máirín Duffy Strode utilise des logiciels libres et open source depuis le lycée et y contribue depuis huit ans. Elle contribue aux communautés Fedora et GNOME et a travaillé sur l’identité visuelle des interactions, l’image de marque ou l’iconographie de plusieurs applications libres et open source importantes telles que Spacewalk, Anaconda, virt-manager, SELinux et SSSD. Elle s’est également engagée dans des activités de sensibilisation en enseignant les techniques de design à des enfants à l’aide d’outils libres et open source tels que GIMP et Inkscape qu’elle défend ardemment. Elle est à la tête de l’équipe de conception graphique de Fedora et designer d’interaction senior chez Red Hat, Inc.

Je connaissais et utilisais des logiciels libres et open source bien avant de devenir contributrice. Ce n’est pas faute d’avoir essayé — il y a eu quelques faux départs auxquels je n’ai pas donné suite principalement parce que j’étais trop timide et que j’ai eu peur d’aller plus loin. Sur la base de ces tentatives avortées et de ce que m’ont rapporté d’autres designers qui se sont embarqués dans des projets libres et open source, j’ai cinq astuces à vous offrir si vous êtes un designer aspirant au statut de contributeur au logiciel libre et open source.

1. Sachez que l’on a besoin de vous et qu’on vous veut (très fort !)

Mon premier faux départ s’est produit alors que j’étais étudiante en première année d’informatique au Rensselaer Polytechnic Institute. Il y avait un projet particulier que j’utilisais beaucoup et auquel je voulais participer. Je ne connaissais personne au sein du projet (ni qui que ce soit investi dans le logiciel libre). J’ai donc fait une tentative à froid. Le site web du projet signalait que les contributeurs voulaient de l’aide et qu’ils avaient un canal IRC. J’y ai alors traîné pendant une semaine ou deux. Un jour, après une pause dans la conversation, j’ai osé élever la voix. J’ai dit que j’étais une étudiante en informatique intéressée par l’ergonomie et que j’adorerais participer.

On m’a répondu : « Dégage ! ». Qui plus est, on m’a fait comprendre que mon aide n’était ni nécessaire ni désirée.

Cela a retardé mon engagement de quelques années — il avait suffi de quelques mots un peu rudes sur IRC pour me dissuader de réessayer pendant près de cinq ans. Je ne découvris que bien plus tard que la personne qui m’avait plus ou moins expulsée du canal IRC de ce projet était en marge du projet, qu’elle avait un lourd passif de ce genre et que je n’avais vraiment rien fait de mal. Si seulement j’avais persévéré dans mes tentatives d’approche et conversé avec d’autres personnes, j’aurais pu commencer à ce moment-là.

Si vous souhaitez contribuer au logiciel libre et open source, je vous garantis qu’il y a un projet quelque part qui a vraiment besoin de votre aide, en particulier si vous êtes orienté design ! Faites-vous du design web ? De l’iconographie ? De l’ergonomie ? De l’habillage ? Des maquettes d’interface utilisateur ? J’ai parlé à de nombreux développeurs de logiciels libres et open source qui non seulement sont désespérément à la recherche d’aide dans ce domaine, mais qui en plus l’apprécieraient vraiment et vous vénéreraient pour l’avoir apportée.

Si vous rencontrez des résistances la première fois que vous essayez de participer dans un projet, apprenez de mon expérience et n’abandonnez pas tout de suite. Si, en définitive, le projet n’est pas fait pour vous, ne vous inquiétez pas et passez votre chemin. Il y a des chances pour que vous trouviez un projet que vous adorerez et qui vous adorera en retour.

2. Aidez le projet pour qu’il vous aide à aider les autres

Bien des projets libres et open source sont aujourd’hui dominés par les programmeurs et les ingénieurs. Et si certains ont la chance qu’une ou deux personnes créatives s’investissent, dans la plupart des projets, un designer, un artiste ou une autre présence créative représente un rêve souvent-caressé-mais-jamais-réalisé. En d’autres termes, même s’ils comprennent qu’ils ont besoin de vos compétences, ils peuvent ne pas savoir quelle sorte d’aide ils peuvent vous demander, quelle information ils doivent vous donner pour que vous puissiez être productif ni même les bases pour travailler avec vous efficacement.

Quand j’ai commencé à m’investir dans différents projets libres et open source, j’ai rencontré beaucoup de développeurs qui n’avaient jamais travaillé directement avec un designer auparavant. Au début, je me suis sentie un peu inutile. Je ne pouvais pas suivre toutes leurs conversations sur IRC parce qu’ils parlaient de leur cuisine interne et de détails techniques qui ne m’étaient pas familiers. Quand ils se sont donné la peine de me prêter attention, ils m’ont posé des questions comme « Quelle couleur dois-je mettre ici ? » ou « Quelle police dois-je utiliser ?  ». Ce que je voulais vraiment en tant que designer d’interactions, c’était d’être associée à la prise de décision lorsqu’on abordait les contraintes spécifiques du projet. Si un utilisateur voulait une fonctionnalité particulière, je voulais avoir mon mot à dire sur le design — mais je ne savais pas où ni quand ces décisions se prenaient et je me sentais exclue.

Le design couvre une gamme assez large de compétences : l’illustration, la typographie, la conception des interactions, la conception visuelle, la conception d’icônes, la conception graphique, la rédaction, etc. et il y a peu de chances qu’un seul concepteur les possède toutes. Il est alors compréhensible qu’un développeur ne soit pas sûr de ce qu’il peut vous demander. Ce n’est pas qu’ils essaient de vous faire obstacle — c’est seulement qu’ils ne savent pas dans quelle mesure vous avez besoin de vous investir ou le désirez.

Aidez-les à vous aider. Montrez-leur clairement le type de contributions que vous pouvez apporter en fournissant des exemples de contributions antérieures. Faites-leur comprendre vos besoins de sorte qu’ils comprennent mieux comment vous aider à vous engager dans leur projet. Par exemple, lorsque vous vous impliquez pour la première fois dans une initiative spécifique pour le projet, prenez le temps de présenter les grandes lignes de son processus de conception et postez cela dans la liste de développement principale afin que les autres contributeurs puissent vous accompagner. Si vous avez besoin d’idées sur des points particuliers, soulignez-les dans votre présentation. Si vous n’êtes pas certain de la façon dont certaines choses se produisent — comme le processus de développement d’une nouvelle fonctionnalité — entrez en contact avec quelqu’un en parallèle et demandez-lui de vous l’expliquer pas à pas. Si quelqu’un vous demande de faire quelque chose au-delà de vos capacités techniques — travailler sur de la gestion de versions, par exemple — et que vous n’êtes pas à l’aise avec ça, dites-le.

Communiquer sur votre processus et vos besoins vous évitera de jouer aux devinettes dans le projet et ses membres seront au contraire capables d’utiliser au mieux vos talents.

3. Posez des questions, beaucoup de questions ; il n’y a pas de question idiote

Nous avons parfois remarqué chez Fedora que, lorsque de nouveaux designers arrivaient à bord, ils avaient peur de poser des questions techniques, par crainte de paraître stupides.

Ce qu’on ne vous dit pas, c’est que les développeurs peuvent être tellement spécialisés qu’il y a beaucoup de détails techniques qui sortent de leur domaine de compétence et qu’ils ne comprennent pas non plus — cela se produit même au sein du même projet. La différence, c’est qu’ils n’ont pas peur de demander — donc vous ne devriez pas avoir peur non plus ! Dans mon travail de design des interactions, par exemple, j’ai dû contacter de nombreuses personnes du même projet pour comprendre comment un processus se déroulait dans leur logiciel, car ce dernier comportait plusieurs sous-systèmes et tous les participants du projet ne comprenaient pas forcément comment chaque sous-système fonctionnait.

Si vous ne savez pas sur quoi travailler, que vous ne savez pas par quoi commencer ou que vous ne comprenez pas pourquoi ce que quelqu’un a dit sur le chat est si drôle — demandez. Vous avez des chances que quelqu’un vous réponde qu’il ne sait pas non plus et peu de risques de passer pour stupide. Dans la plupart des cas, vous allez apprendre quelque chose de nouveau qui vous aidera à devenir un meilleur contributeur. Il peut être particulièrement efficace de chercher un tuteur — certains projets ont même un programme de tutorat — et de lui demander s’il veut bien être votre référent quand vous avez des questions.

4. Partagez et partagez souvent, même si ce n’est pas encore prêt, surtout si ce n’est pas encore prêt

Nous avons aussi remarqué que de nouveaux designers pour Fedora et d’autres projets libres et open source sont un peu timides lorsqu’il est question de montrer leur travail. Je comprends qu’on ne veuille pas ruiner sa réputation en publiant quelque chose qui n’est pas ce qu’on peut faire de mieux ni même fini ; mais une grande partie du travail sur des projets libres et open source est de partager souvent et ouvertement.

Plus vous aurez avancé sur un élément avant de le partager, plus il sera difficile à d’autres de vous apporter un retour utilisable, de se lancer et de s’investir. Il est aussi plus difficile pour autrui de collaborer à votre travail et d’avoir un sentiment d’appartenance au projet, de le soutenir et de le pousser jusqu’à l’implémentation. Dans certains projets libres et open source, ne pas être communicatif avec vos ébauches, compositions et idées est même considéré comme offensant !

Publiez vos idées, maquettes ou compositions sur le Web plutôt que par courriel, afin qu’il soit plus aisé pour les autres collaborateurs de faire référence à votre contribution en faisant un copier-coller de l’URL — c’est particulièrement pratique au cours d’une discussion. Plus vos éléments de design seront faciles à trouver, plus il est probable qu’ils seront utilisés.

Essayez ce conseil et gardez l’esprit ouvert. Partagez votre travail tôt et souvent. Rendez disponibles vos fichiers sources. Vous serez peut-être agréablement surpris par ce qui va se passer !

5. Soyez aussi visible que possible au sein de la communauté du projet

Un outil qui — de manière totalement involontaire — a fini par m’aider énormément à démarrer en tant que contributeur de logiciels libres et open source a été mon blog. J’avais commencé à entretenir un blog, simplement pour moi, à l’image d’un portfolio grossier des choses sur lesquelles j’avais travaillé par le passé. Mon blog est un énorme atout pour moi, parce que :

• En tant qu’enregistrement de l’historique des décisions de projet, il représente un moyen pratique pour rechercher d’anciennes décisions de design — comprendre pourquoi nous avons décidé de laisser tomber tel ou tel visuel à nouveau ou pourquoi une approche particulière, précédemment essayée, n’a pas fonctionné, par exemple ;
• En tant que dispositif de communication, il aide les autres contributeurs associés à votre projet et même les utilisateurs à être au courant des travaux en cours et des changements à venir pour le projet. De nombreuses fois, j’ai omis quelque chose d’essentiel dans un design et ces personnes ont très rapidement posté un commentaire pour m’en informer !
• Il m’a aidé à construire ma réputation en tant que designer de logiciels libres et open source, ce qui m’a aidé à gagner la confiance des autres envers mes choix de design avec le temps.

Vous bloguez ? Trouvez quels agrégateurs de blogs lisent les membres du projet auquel vous participez et demandez à ce que votre blog y soit ajouté (il y a en général un lien pour cela dans la barre latérale). Par exemple, l’agrégateur de blogs que vous devrez rejoindre pour faire partie de la communauté Fedora se nomme Planet Fedora. Écrivez un premier billet pour vous présenter aux autres et leur faire savoir ce que vous aimez une fois que vous y aurez été ajouté — des informations du genre de celles listées dans la première astuce.

Le projet aura certainement une liste de diffusion ou un forum où les discussions ont lieu. Rejoignez-les et présentez-vous là aussi. Quand vous apportez une contribution au projet — peu importe qu’elle soit petite ou loin d’être aboutie — postez des billets sur ce que vous faites, téléchargez-le vers le wiki du projet, tweetez à ce sujet et envoyez des liens aux membres importants de la communauté via IRC afin d’avoir leur retour.

Rendez votre travail visible et les gens commenceront à vous associer à votre travail et à vous proposer des projets sympas ou d’autres opportunités, simplement grâce à ça. C’est tout ce que j’aurais aimé savoir quand j’ai essayé de m’investir pour la première fois dans le logiciel libre et open source comme designer. Si vous ne deviez retenir qu’un message de tout cela, c’est que vous ne devriez pas être timide — faites-vous entendre haut et fort, faites connaître vos besoins, faites savoir aux autres quels sont vos capacités et ils vous aideront à les utiliser pour que le logiciel libre envoie du lourd.