Aujourd’hui c’est un peu spécial copinage, mais pourquoi pas ? Ils ne sont pas si nombreux les navigateurs web à la fois open source, grand public et à la pointe des technologies, respectueux des personnes qui les utilisent et de leurs données, distribués en langue locale à peu près partout dans le monde, pour toutes les plateformes, etc.

Il est temps de considérer que c’est une ressource précieuse pour tous (et pas seulement pour la communauté du libre).

– D’accord, mais comment y contribuer lorsqu’on est seulement utilisateur ou utilisatrice?

Pascal Chevrel qui répond aujourd’hui à nos questions nous présente une version de Firefox trop peu connue mais qui mérite toute notre attention et même notre implication : Firefox Nightly

Bonjour Pascal ! Commençons par le début : peux-tu te présenter ?
Bonjour, Parisien, 45 ans, je suis impliqué dans le projet Mozilla depuis pratiquement sa création et je travaille à plein temps pour Mozilla depuis 11 ans. De formation plutôt économique et linguistique, j’ai longtemps travaillé sur l’internationalisation des sites web de Mozilla, l’animation de communautés de traducteurs et le développement d’outils de suivi et d’assurance qualité de nos traductions. Depuis un an, j’ai quitté mes précédentes fonctions pour rejoindre l’équipe Release Management qui est chargée d’organiser et de planifier les livraisons de Firefox. Dans ce nouveau contexte, au sein du département Product Integrity, je suis maintenant responsable du canal Nightly de Firefox.

Alors, je doute que beaucoup des personnes qui nous lisent sachent ce qu’est exactement Nightly, tu peux nous en dire plus ?
Nightly est la version alpha de Firefox, chaque jour nous compilons Firefox avec les modifications apportées par les développeurs la veille à notre code source et nous proposons cette version de Firefox au téléchargement afin de recevoir des retours sur l’état de qualité du logiciel.

Quel est l’intérêt pour moi, péquin moyen, d’utiliser Nightly ?
Pour un internaute lambda, pas forcément à l’aise avec l’informatique, il n’y a effectivement aucun intérêt à utiliser Nightly. Les utilisateurs « ordinaires » sont encouragés à utiliser le canal Release qui est la version finale grand public et pas une version alpha ou bêta de Firefox.

Pour un utilisateur averti, utiliser Nightly signifie avoir accès à une version de Firefox qui plusieurs mois de développement d’avance sur la version finale et donc de pouvoir utiliser des fonctionnalités auxquelles n’ont pas encore accès les utilisateurs de Firefox. Depuis plusieurs mois, nous faisons un gros travail de modernisation et de nettoyage du code source de Firefox afin d’améliorer ses performances, les utilisateurs de Nightly ont donc accès à un navigateur beaucoup plus performant que la version grand public.

Pour un utilisateur averti et sensible aux valeurs véhiculées par Mozilla et par le logiciel libre, c’est aussi le meilleur moyen de participer à un projet de logiciel libre lorsque l’on a pas de temps à investir dans des activités de bénévolat. Le simple fait d’utiliser Nightly est une aide plus que précieuse au développement de Firefox car Nightly envoie par défaut des données de télémétrie et les rapports de plantage à nos développeurs qui peuvent ainsi repérer immédiatement toute nouvelle régression.

Attends ! Ça veut dire que vous préparez toutes les nuits une nouvelle version de Firefox ?! Elle doit être pleine de bogues ! Ça marche vraiment ton machin ?
Toutes les nuits en effet (d’où son nom de Nightly), nous compilons Firefox avec le code de la veille, dans toutes les langues, pour tous les systèmes d’exploitations que nous supportons, en 32 comme en 64 bits. Toutes ces versions (builds) doivent passer notre batterie de tests automatisés qui valident un niveau de qualité minimal. Évidemment, c’est une version alpha, donc moins stable, elle peut planter plus facilement qu’une version destinée au grand public…

Ceci dit c’est très utilisable, j’utilise des nightlies depuis 2002 et les véritables problèmes sont rares. Lorsqu’un vrai problème passe entre nos filets, en général la télémétrie nous en informe en quelques heures et nous livrons une deuxième nightly dans la journée pour le régler ou fournir une solution d’atténuation de l’impact causé par le bug (retour arrière sur le patch fautif, désactivation temporaire d’une nouvelle fonctionnalité si le retour arrière n’est pas possible).

Et si j’installe Nightly, ça veut dire que ça me remplace mon Firefox habituel ? Et mes favoris et mots de passe enregistrés ?

Déjà, on dit marque-page, « favori » c’est de la terminologie Microsoft, je peux avoir dans mes marque-pages le site des impôts, ça ne veut pas dire que ce soit un des mes sites favoris 😉

On peut tout à fait installer Nightly à côté d’un Firefox classique, la chose importante est de ne pas leur faire partager le même profil de données. Le plus simple est d’installer Nightly dans un nouveau profil et de synchroniser les données (marque-pages, historiques, mots de passe…) entre les deux versions via Firefox Sync, notre service de synchronisation de données.

Histoire de bien comprendre : je dois télécharger Nightly tous les matins pour profiter des dernières mises à jour ?

Non, Nightly se met à jour en arrière-plan tout seul, lorsque la nouvelle version est disponible et peut être installée, une petite flèche verte apparaît sur l’icône de menu et il suffit de cliquer dans ce menu sur un bouton qui appliquera la mise à jour, ce qui se traduit concrètement par la fenêtre qui se ferme et se rouvre en quelques secondes.

Allez, fais-nous rêver : c’est quoi les nouvelles fonctionnalités attendues ?
En novembre, nous allons sortir une mise à jour majeure de Firefox, la plus grosse mise à jour du logiciel depuis 2011. Nous travaillons à une modernisation importante du moteur de rendu des pages (Gecko) en intégrant des parties mûres de notre autre moteur de rendu en R&D, Servo. Ce moteur est écrit dans un nouveau langage informatique très performant, Rust, les gains attendus en termes de performances sont importants. Ce projet de modernisation des fondations s’appelle Quantum. Il s’agit d’un projet proprement titanesque sur lequel plusieurs équipes de développeurs travaillent à plein temps depuis plusieurs mois, la version de novembre intégrera les premiers fruits de ce travail.

Nous travaillons aussi à une modernisation de l’interface actuelle de Firefox avec notre équipe d’ergonomes et de designers afin d’améliorer aussi l’interaction avec l’utilisateur, ce projet s’appelle Photon. Tu peux voir à quoi ressemblera Firefox d’ici quelques mois en parcourant ce diaporama illustré d’aperçus de la future interface.

Tous les travaux en cours sur Quantum et Photon ne sont disponibles que sur Nightly, les amateurs de performances et de design peuvent donc avoir accès en avant première à ces avancées.

En termes de fonctionnalités spécifiques à Nightly, la gestion d’identité multiples dans une même session (qui permet d’avoir des onglets « boulot » et des onglets « perso » par exemple) semble être la nouveauté la plus appréciée de nos utilisateurs sur ce canal.

Bon si c’est pour avoir une version toute en anglais, merci bien !
Nous proposons Nightly dans toutes nos langues, il est donc disponible au téléchargement en français. Évidemment, pour les nouvelles fonctionnalités, il faut parfois attendre quelques jours pour voir celles-ci en français dans l’interface, il arrive donc parfois que certaines phrases ou items de menu soient en anglais. Mais c’est rare, les traducteurs veillent au grain.

Excellent ! Nightly, j’en veux © Je fais comment ?
Mozilla fournit des binaires pour Windows, Mac et Linux à cette adresse : https://nightly.mozilla.org. La seule difficulté à l’installation par rapport à un Firefox pour le grand public est qu’il faut créer un profil de données séparé si l’on veut installer Nightly à côté d’un Firefox déjà installé et pas le remplacer. Nous travaillons sur notre installeur pour qu’à l’avenir, ce profil séparé soit créé automatiquement sans intervention de l’utilisateur mais ce ne sera probablement pas effectif avant 2018.

Notre wiki contient des informations détaillées (mais en anglais) sur l’installation de Nightly selon son système d’exploitation, dont un screencast pour Windows.

Mais au fait, ça fait quand même beaucoup, beaucoup d’énergie dépensée par Mozilla pour une version de Firefox plutôt méconnue. C’est quoi votre intérêt ?

Pour développer Firefox qui est un projet de grande envergure (des centaines de développeurs, une base de code très importante, près de 100 langues et 4 systèmes d’exploitation pris en charge…), il faut le compiler tous les jours et avoir une infrastructure d’intégration continue en place, il était donc logique de proposer ces versions (que nous utilisons déjà en interne) à nos utilisateurs afin de pouvoir bénéficier d’un bêta test externe qio réponde à des questions comme : est-ce que le site de ma banque en Belgique fonctionne avec ? Est-ce que la traduction est bonne ? Est-ce qu’il est stable sur ma configuration ?…

Cela représente donc un investissement mais avoir une version dédiée au bêta-test communautaire est fait partie (ou devrait faire partie) de tout projet de logiciel libre communautaire.

Au fait, beaucoup de gens l’utilisent ?
Trop peu de gens utilisent Nightly, essentiellement les employés Mozilla et notre communauté de bénévoles les plus impliqués dans le projet Mozilla, quelques dizaines de milliers de personnes dans le monde. Cela peut sembler beaucoup dans l’absolu mais c’est en réalité assez faible car le Web est immense, les configurations matérielles sur lesquelles tournent Firefox sont des plus diverses dans le monde et nous n’avons pas aujourd’hui assez de retours d’utilisation (que ce soit la télémétrie ou des rapports de bugs plus formels) afin de prendre les meilleures décisions de développement.

Nous recherchons donc des utilisateurs mais bien sûr nous sommes très clairs sur le fait que Nightly est destiné à un public plus à l’aise avec l’informatique que la moyenne et prêt à accepter des changements de comportement ou d’interface du logiciel au jour le jour avec en contrepartie l’accès en avant-première à des fonctionnalités innovantes.

Si vous voulez aider Mozilla, que vous êtes à l’aise avec l’informatique, utiliser Nightly à la place ou à côté de votre navigateur actuel (qui n’a pas à être Firefox) est probablement le moyen le plus simple de participer au projet.

Donc, même si je n’y connais rien de rien en logiciel libre, en code, et tous les autres trucs techniques, rien qu’en utilisant Nightly, je fais avancer le schmilblick ?
Si vous êtes à l’aise avec l’informatique (en gros, si vous savez installer et désinstaller un logiciel sans faire appel à la cousine en école d’ingénieur), simplement utiliser Nightly aide énormément Mozilla et les développeurs de Firefox.
Nous avons aujourd’hui une qualité de Nightly qui est suffisante pour de très nombreux utilisateurs sans connaissances techniques particulières.

Si je vois des trucs qui clochent, je le signale où et comment ? Parce que moi le bugzilla, comment dire…
Pour les francophones, le plus simple est d’expliquer ce qui cloche dans nos forums de mozfr à cette adresse : https://forums.mozfr.org/viewforum.php?f=24
S’il s’avère que c’est effectivement un problème dont nous n’avons pas connaissance, nos modérateurs les plus anglophiles se chargeront d’ouvrir un ticket sur Bugzilla et d’agir comme intermédiaires avec les développeurs. Je passe sur le forum moi-même deux fois par semaine.

Et si je suis un développeur, et que les mots « code source », « mercurial », « bugzilla » ou « RTFM » me parlent, je peux aider quand même ?

Si vous êtes développeur non seulement vous pourrez rapporter des bugs directement dans Bugzilla mais on peut aussi vous aider à écrire le patch pour résoudre ce bug ! Il y a d’ailleurs une vingtaine de développeurs Firefox qui sont francophones si l’anglais vous fait un peu peur.

Les développeurs mais aussi les utilisateurs les plus techniques peuvent ouvrir des bugs et faire une recherche du patch qui a causé une régression grâce à l’outil mozregression

Tiens une question qu’on nous pose souvent, qui peut paraître hors sujet, mais en fait pas du tout : qu’est-ce que je peux dire à mon cousin qui utilise Google Chrome, afin qu’il envisage de passer à Firefox ?

Il n’y a pas de réponse unique à cette question car pour cela il faudrait savoir pourquoi il utilise Chrome. Si ton cousin est sensible au respect de sa vie privée, utiliser Firefox va probablement de soi. Si ce qui importe pour lui ce sont les performances, alors Nightly est certainement dans la course avec Chrome, voire plus performant sur certaines activités, ce n’a pas toujours été le cas donc c’est important à souligner. S’il est un utilisateur compulsif d’onglets, la gestion des onglets de Nightly est certainement plus riche et performante que celle de Chrome ; avoir une session avec plusieurs centaines d’onglets ouverts sur une machine récente ne pose aucun problème sous Nightly.

Je pense que de nombreux utilisateurs qui sont passés de Firefox à Chrome il y a quelques années seraient très surpris des avancées (performances, ergonomies, fonctionnalités) que nous avons intégrées dans Firefox. C’est encore plus vrai pour Nightly et je reçois quasiment quotidiennement du feedback d’utilisateurs Chrome passés avec bonheur à Nightly, C’est très encourageant pour notre grosse livraison 57 en novembre évidemment. Le magazine en ligne américain CNET a publié en juin un article intitulé « New speed boost means maybe it’s time to try Firefox again » plus qu’élogieux et ils n’ont testé que la version grand public 54. Nightly qui est en 56 est déjà bien plus performant.

Merci Pascal ! Un dernier mot ? Ou une question que tu aurais aimé qu’on te pose ?

Un grand merci à toi pour l’intérêt que tu portes à Firefox, Mozilla et mon travail sur Firefox Nightly ! Merci aussi pour le travail de vulgarisation que fait Framasoft en ce qui concerne le logiciel et la culture libre. Firefox est l’outil qui permet à Mozilla d’avoir un impact sur le Web. Étant donné le travail que fait Framasoft sur la décentralisation et de dégooglisation du web, les lecteurs de cet article seront peut être intéressés par cette récente annonce de Mozilla dans laquelle nous annonçons un budget de 2 millions de dollars dédié à financer les projets de décentralisation du Web.

… et le slogan du blog de Nightly pour le mot de la fin :
Améliorons ensemble la qualité, version après version (Let’s improve quality, build after build!)

Comment participer à des projets open source et s’y sentir légitime ? La réponse habituelle un peu désinvolte consiste à dire : « il suffit de commencer à proposer ne serait-ce qu’un signalement de bug ou une correction mineure dans la documentation et hop ». En commençant par une contribution minime, on peut donc trouver sa place dans une équipe. Théoriquement, c’est exact.

Mais quand on est une jeune femme à peine sortie de ses études d’informatique et qu’on éprouve un peu d’appréhension au contact des contributeurs supposés expérimentés, rien n’est tout à fait simple.

Comme on le lira dans le témoignage de Shubheksha, il faut non seulement parvenir à surmonter son manque de confiance en soi, mais aussi avoir la chance de rencontrer sur son chemin des mentors qui vous accueillent avec bienveillance, vous guident et vous invitent à contribuer davantage encore.

Le parcours cahoteux d’une débutante dans le monde de l’open source

Article original paru dans Medium : A Beginner’s Very Bumpy Journey Through The World of Open Source

Par Shubheksha

Traduction :  Lyn, audionuma, goofy, Lumibd, Manguito,et un anonyme

Avez-vous atterri ici en recherchant des conseils sur la meilleure manière de contribuer à l’open source ? Il y a des milliers d’histoires de ce genre sur Internet, n’est-ce pas ?
Je suis sûre que vous en avez lu beaucoup à présent, car vous essayez de contribuer depuis un bon moment. Et vous avez toujours l’impression de ne pas avoir progressé.
Je connais ce sentiment. J’étais exactement dans la même situation il y a quelques semaines. Laissez-moi vous conter mon histoire.

Voilà à peu près deux ans que j’essaie de contribuer à l’open source.

Oui. Deux ans.

Et il y a bien une chose que je peux affirmer : c’est intimidant. C’est dur de commencer. Vous devez apprendre comment travailler sur un long code source. Vous devez apprendre et adopter les règles de style de code d’un projet.

Tout paraît confus. L’ordre des instructions, comment les différents modules interagissent entre eux, comment et pourquoi le code est organisé de la manière dont il l’est : tout cela constitue un grand labyrinthe.

Je ressens cela en permanence car je ne suis, après tout, qu’une amatrice qui essaie d’en apprendre autant qu’elle le peut.

J’ai donc choisi de suivre la voie la plus facile : la correction de fautes dans la documentation ou les commentaires, et la résolution de bugs triviaux où il était évident de trouver ce qui devait être modifié. Je ne voulais pas poser trop de questions ni essayer de comprendre l’ensemble du code.

Chaque fois que je voulais contribuer, j’allais sur github — ou un autre gestionnaire de bugs – et j’essayais de rechercher des problèmes étiquetés « facile », « débutant », « premier bug facile ». Après en avoir consulté des centaines, je trouvais quelque chose de suffisamment simple à traiter sans beaucoup d’aide extérieure.

Alors, cela a bien fonctionné jusqu’au moment où j’ai pris conscience que je pourrais mieux utiliser les compétences que j’étais en train de développer. J’avais appris tant de nouvelles choses, mais je ne voyais pas à quoi j’aurais pu les utiliser. Apprendre sans mettre en application, c’est bien peu gratifiant. J’étais bloquée sur un palier et je n’avançais plus du tout.

Alors, il est arrivé quelque chose qui m’a terriblement effrayée en tant que nouvelle contributrice qui essaie de naviguer dans le monde de l’open source. J’avais trouvé un bug qui avait l’air assez facile dans un grand projet renommé.

J’ai pensé qu’il valait mieux demander quelques éclaircissements avant de procéder à la moindre modification car je craignais de tout bousiller. J’ai donc envoyé un commentaire indiquant que j’étais une nouvelle contributrice, et demandant quelle serait la meilleure manière de modifier un bout de texte pour corriger le bug.

La réponse que je reçus fut :

« Si tu n’arrives pas à déterminer comment effectuer cette modification, c’est que tu n’es pas qualifiée pour effectuer cette modification. »

Cette réponse me laissa complètement décontenancée, et m’effraya davantage encore à l’idée de poser des questions lorsque je ne comprenais pas quelque chose à propos d’un projet.

Peut-être étais-je indésirable parce que je n’en savais pas assez ? Peut-être devais-je travailler davantage pour acquérir des compétences au lieu de poser des questions stupides et maladroites à des personnes expérimentées beaucoup trop occupées pour me répondre ?

C’est aussi à cette époque que ma recherche d’un mentor a commencé. J’ai pensé que si je connaissais quelqu’un avec qui je serais plus à l’aise pour poser des questions, les choses se passeraient bien et je pourrais me rendre plus utile.

J’ai donc écrit à de nombreuses personnes en leur demandant de m’aider à débuter, vu que je me sentais particulièrement intimidée par mes précédentes expériences. J’ai reçu beaucoup de réponses positives, pleines d’encouragements, mais je n’ai jamais exactement trouvé ce que je cherchais.

J’avais l’impression de buter contre un environnement clos dans le monde ouvert de l’open source.

Tout semblait suggérer que je n’avais qu’à m’y mettre et à ne pas avoir peur. Mais je n’étais pas prête à ce moment là.

Ma découverte de Mozilla

Par une belle soirée, alors que je cherchais des bugs à corriger, j’ai atterri sur le projet de Mozilla qui vous aide à tester des extensions web. J’étais contente de voir qu’il y avait quelques problèmes étiquetés comme « premier bug facile » mais aucun d’entre eux n’était aussi simple que de corriger une petite coquille.

Bon sang, j’en suis tellement heureuse maintenant.

J’ai commencé à travailler sur l’un de ces bugs, mais j’ai vite compris qu’il me faudrait poser des questions si je voulais être capable de résoudre le problème. J’ai parcouru le code source. Après avoir compris les grandes lignes du problème, j’ai demandé plus d’informations. et voila ! J’ai été capable de résoudre le problème une fois que j’ai eu tous les détails nécessaires.

Maintenant que j’ai soumis trois pull requests [NDT : demandes de modification du code source] (l’une a été acceptée, les deux autres sont en passe de l’être), je suis heureuse d’avoir franchi le pas. Je suis contente de ne pas avoir hésité à poser des questions pertinentes, même si je risquais parfois d’avoir l’air de poser des questions stupides.

Ce n’est pas un problème de ne pas tout savoir et de progresser par étapes pour apprendre quelque chose de nouveau.

Les gens de Mozilla qui encadrent ces corrections m’ont beaucoup aidée et ont toujours été très positifs. Ils m’ont guidée du début à la fin, prenant le temps de m’expliquer les choses de façon à la fois simple et très détaillée. Et cela malgré le fait qu’ils n’auraient mis que quelques heures à corriger ces problèmes eux-mêmes au lieu de prendre le temps de me guider vers une solution de mon cru, dont la conception m’a pris plusieurs jours.

J’ai appris et découvert énormément de choses juste en travaillant sur ces trois problèmes basiques. Et je suis vraiment excitée à l’idée de travailler sur des problèmes encore plus difficiles et d’augmenter ma compréhension de ce sujet et mes connaissances.

Je ne peux pas les remercier assez pour cette expérience tellement positive et enrichissante, qui m’amène à installer Firefox localement et à parcourir les bugs sur Bugzilla un jour sur deux (je garde mes questions sur « Pourquoi » et « Comment » pour un billet plus long).

Je prévois de contribuer à Mozilla aussi régulièrement que possible. À chaque fois que j’ai posé une question pertinente, que ce soit sur IRC, Github ou Bugzilla, j’ai reçu des réponses très aimables.
Jusqu’à aujourd’hui, j’ai résolu trois problèmes dans web-ext, et j’ai eu un correctif accepté et intégré dans Firefox.

Mes contributions ont été remarquées par la communauté, et j’ai aussi été nommée dans le « Addons Contribution Recognition document » [NdT : la liste des contributeurs aux extensions de Mozilla].

En définitive, mes expériences de ces dernières semaines ont été vraiment merveilleuses. J’ai appris tellement de choses, petites et grandes, qu’aucun manuel de programmation n’aurait pu m’apprendre.
Voici mes conseils pour les développeurs débutants qui veulent contribuer à un projet open source :

Conseil n°1 : n’ayez pas peur de poser des questions

Je ne saurais trop insister sur ce point. J’ai perdu beaucoup de temps parce que je ne cessais de me censurer, et c’était ma plus importante inhibition.

Tout le monde a peur de paraître stupide. Mais ne laissez pas cette peur paralysante devenir une entrave à votre progression.

Il est normal de demander si vous ne comprenez pas quelque chose qui est en rapport avec le projet. Les développeurs du projet sont devenus des experts au fil des années. Ils peuvent vous aider très rapidement. Sinon vous risquez de perdre des heures le nez dans le code source à essayer de deviner quelque chose que vous n’êtes même pas censés savoir au départ.

Mais quand vous demandez des informations, vérifiez si elles ne sont pas déjà disponibles dans une documentation ou une recherche Google. Ainsi, vous prendrez garde à respecter le temps libre des développeurs du projet.

Conseil n°2 : c’est normal d’avoir des lacunes

On ne s’attend pas à ce que vous sachiez tout de A à Z lorsque vous commencez à contribuer à un projet. Le processus, c’est plutôt que vous appreniez et gagniez en compétence en résolvant des problèmes de plus en plus difficiles, et en vous familiarisant avec le projet et les outils qu’il utilise. Le temps nécessaire pour cela varie d’un projet à l’autre et d’une personne à l’autre.

Conseil n°3 : lancez-vous !

Ne perdez pas un temps considérable à choisir le projet idéal. Si vous connaissez un projet ou une organisation dont la communauté accueille amicalement les débutants, faites-en votre point de départ.

Trouvez un problème avec lequel vous êtes à l’aise, de préférence dans un langage que vous pratiquez déjà depuis un moment, et essayez d’imaginer ce qui a besoin d’être fait. Demandez des informations pertinentes afin de combler vos lacunes, et après, lancez-vous ! N’attendez pas.

Merci à tous ceux qui travaillent dans l’open source

Une dédicace spéciale à tous les contributeurs aux projets open source qui sont super réactifs et qui encouragent les nouveaux. Vous aidez les nouveaux venus à se frayer un chemin au milieu d’interminables lignes de code et les faites contribuer de manière peut-être limitée mais néanmoins significative. Vos efforts sont nécessaires et sincèrement appréciés.

En tant que débutante et développeuse junior, j’essaie juste de trouver mon chemin dans le vaste et formidable monde de l’informatique. Quelques minutes de votre temps, que ce soit pour me présenter une simple technique de débogage ou pour me montrer comment écrire correctement des tests logiciels, m’aideront, au fil du temps, à devenir une meilleure développeuse.

Vous avez l’expérience et j’ai l’envie insatiable d’apprendre autant que je peux.

Un grand merci à Guido, Kumur McMillan et Luca qui ont été de fabuleux mentors tout au long de ce parcours, ils m’ont suivie à chaque instant et ont répondu à mes diverses questions. J’ai vraiment apprécié le temps et les efforts que vous m’avez consacrés 🙂

Si vous êtes un nouveau venu qui peine à entrer dans le monde de l’open source, j’aimerais que vous me parliez de votre histoire et de votre expérience. Si je peux vous aider de quelque façon que ce soit, surtout n’hésitez pas à me contacter.

J’envisage de rendre compte de mon parcours chez les contributeurs de l’open source, donc si vous désirez que j’aborde un sujet en particulier, merci de laisser un commentaire.
Merci à Pawan Dubey et Quincy Larson pour m’avoir aidée à peaufiner cet article.

Nous saluons aujourd’hui une initiative exemplaire qui conjugue les démarches auxquelles nous sommes attachés : un projet éducatif à destination des enfants d’écoles primaires et de leurs enseignants, qui les fait participer et aboutir à un ouvrage qui sera utile à d’autres… car placé en licence libre ! Avec Éric que nous interviewons ici, une équipe de contributeurs petits et grands convaincus que la culture libre, c’est bien d’en parler, mais c’est encore mieux de la créer et de la diffuser !

Une Interview d’Eric Querelle aka Odysseus

Bonjour, Odysseus… qui se cache derrière ce pseudo homérique ?
Je suis professeur de néerlandais dans l’enseignement secondaire belge. Je griffonne à mes heures perdues, lorsque l’occasion se présente ou lorsque j’ai une idée. Au départ ce choix de pseudo n’était pas guidé par Homère mais par le vaisseau d’Ulysse… 31 dont j’étais un grand fan. Ce qui donne une idée approximative de mon âge 😉

Il me semble que tu n’en es pas à tes débuts dans l’illustration d’ouvrages libres à destination des plus jeunes, qu’est-ce qui t’intéresse dans ce genre de réalisations ?
En effet, depuis quelque temps j’écris et illustre en amateur de petites histoires pour enfants que je propose en téléchargement. Ainsi, 4 petites histoires sont déjà disponibles : Petit Vénusien raconte l’histoire d’un extra-terrestre qui a un besoin urgent, Bonne nuit Doudou Lapin, une histoire très très courte, Ne pleure pas Monsieur le Loup qui évoque la phobie des ongles coupés et Super Héros, une histoire déclinée en deux versions qui aborde le thème du cauchemar.

Pour le reste, je dessine au gré de mes envies et de mes idées ou propose d’autres bidules comme un petit jeu de dominos ou une lecture de 12 fables de La Fontaine, par exemple.

Ce goût des histoires et celui du dessin se combinent bien. La simple idée de savoir — et de voir — que ceux-ci sont utilisés, exploités de manière individuelle, en classe et sur AbulEdu est un très beau cadeau, une belle récompense.

De manière plus générale, l’école est pour moi le lieu le plus adéquat pour faire découvrir et assimiler ces notions de partage, de respect, de diffusion et de valorisation du bien commun.

Comment est né ce projet d’abécédaire ?
Ce projet est né sur Babytwit, une plateforme libre de microblogging proposée par l’association AbulEdu-fr à destination principale des écoles primaires. Jonathan Tessé mainteneur de la plateforme et animateur Tice dans la région dijonnaise a lancé l’idée et un groupe de personnes ultra-motivées s’est rapidement formé pour la concrétiser. Quatre mois après, nous y voilà ! 🙂

Lien direct en cliquant sur l’image de couverture – PDF 14,1 Mo

Ce sont les enfants de diverses écoles qui t’ont envoyé des phrases cocasses pour chacune des lettres. Ça t’a compliqué la tâche ?
Oui, six groupes-classes ont participé à ce projet et leur implication a été maximale. L’idée que je me faisais au départ était celle d’un travail tranquille et je m’attendais à des phrases simples du genre « L’éléphant est près de l’étang ». C’était sans compter l’imagination débordante des enfants coachés par des professeurs gonflés à bloc qui ont pris un plaisir malin à me pousser dans mes derniers retranchements :

En faisant du xylophone, Baba Yaga et son yorkshire dévorent un yaourt au Xérès accompagné d’yeux de yéti et d’ailes de xylocope.

Un plaisir vite partagé et chaque nouvelle phrase était une vraie belle surprise !

J’ai eu également l’immense plaisir de rencontrer une classe (celle de Bordeaux). Ça a vraiment été un moment très intense : j’étais venu avec mes dessins déjà réalisés, beaucoup de questions ont été posées par les enfants (qui m’appelaient Odysseus car ils ne savaient rien d’autre que mon pseudo), des remarques adorables… et puis planait aussi ce sentiment inexplicable de rencontrer en chair et en os des personnes que l’on « connaît » uniquement virtuellement.

Concrètement, les 6 classes participantes se sont partagées les lettres de l’alphabet. Lorsque leurs phrases étaient prêtes, elles me les transmettaient via le groupe dédié #abécédaire. Les phrases étaient commentées. Il m’est très souvent arrivé de devoir faire des recherches (pour des mots comme : xylocope, Baba Yaga, urubu…). Je leur montrais le dessin ou un extrait de celui ci pour maintenir un certain suspense. J’avais des retours satisfaits ou quelquefois des remarques du genre « son nez est trop gros » ou « le bouc est trop petit », « son nez n’est pas assez crochu » ou encore « ta hyène on dirait un ours » :-D.

Bref un véritable suivi de la part des enfants. Dans toutes les classes, un travail de fond pédagogique a été réalisé quant au contenu (la recherche lexicale), la forme (ne pas dépasser 140 caractères)… et le fonctionnement du microblogging, ses codes. Cela a largement dépassé le simple cadre de l’alphabet.

La licence « art libre », c’est important pour toi ? Est-ce que ça signifie que toutes les écoles primaires peuvent se servir librement de cet abécédaire ?
Oui, et j’en ai pris conscience lors d’un événement précis : il y a quelques années j’ai posé sur mon blog de l’époque un dessin intitulé « Bulle spéculative » déjà sous licence Art Libre car j’avais découvert cet univers via Framasoft. J’ai reçu un mail d’un certain Antoine Moreau qui était à la recherche d’une bulle pour son texte de Paule et Paul qu’il publiait dans un petit livret sur l’Art. C’était la première fois qu’on me demandait l’autorisation d’utiliser un dessin. Quelques semaines plus tard, j’ai reçu dans ma boîte aux lettres ledit livret avec une partie de mon dessin (rien que la bulle). Je découvrais et vivais ce fameux : « Copyleft: cette œuvre est libre, vous pouvez la copier, la diffuser et la modifier selon les termes de la Licence Art Libre  ».

Aussi, je suppose (et espère) que quelqu’un qui copie, diffuse, modifie, utilise mes dessins l’apprécie et je considère donc cela comme une reconnaissance.

L’abécédaire est sous Licence ArtLibre 1,3 (LAL 1,3) Avec la Licence Art Libre, l’autorisation est donnée de copier, de diffuser et de transformer librement les œuvres dans le respect des droits de l’auteur. Loin d’ignorer ces droits, la Licence Art Libre les reconnaît et les protège.

Elle en reformule l’exercice en permettant à tout un chacun de faire un usage créatif des productions de l’esprit quels que soient leur genre et leur forme d’expression. Si, en règle générale, l’application du droit d’auteur conduit à restreindre l’accès aux œuvres de l’esprit, la Licence Art Libre, au contraire, le favorise.

L’intention est d’autoriser l’utilisation des ressources d’une œuvre ; créer de nouvelles conditions de création pour amplifier les possibilités de création. La Licence Art Libre permet d’avoir jouissance des œuvres tout en reconnaissant les droits et les responsabilités de chacun. La licence complète est à lire ici.

Cela signifie donc effectivement que les écoles primaires et toute personne intéressée par cet abécédaire peuvent le télécharger et l’imprimer librement. Je mets également toutes les sources à disposition (images brutes, .png, .svg, le document .odt et le .pdf) pour permettre à qui le souhaite de « jouer » avec les dessins, personnaliser l’abécédaire en supprimant les phrases pour une activité de classe par exemple ou en colorisant les images.

Une version en couleurs est prévue ?
Oui, au départ, nous étions partis pour une version colorisée. Mais impossible à réaliser en quatre mois de temps. Tenant absolument à donner aux enfants un résultat concret de leur travail avant la fin de l’année scolaire, nous avons laissé la colorisation de côté pour nous concentrer sur un produit fini en noir et blanc.

Dans l’idée de garder l’idée de travail collectif, j’ai donc lancé un appel à l’aide à la colorisation et quelques personnes se sont vaillamment lancées dans l’aventure. Cela avance bien, très bien même. Mais comme plus on est de fous plus on rit, cet appel reste tout à fait d’actualité.

Déjà un autre livre pour enfants en projet ?
J’ai quelques idées mais j’ai souvent besoin d’un certain temps pour les laisser percoler. Mais il m’arrive aussi d’avoir l’idée qui tombe de je-ne-sais-où.

Alors, un livre en projet, pour le moment non. Mais qui sait ? Peut-être demain…

Au fait, si des gens (une école, des particuliers…) veulent te remercier par un don financier ?
C’est une option que je n’envisageais pas car je ne propose évidemment pas mes histoires dans ce but et puis cela me rendait plutôt mal à l’aise.

Cependant, pour le faire moi-même aussi quelquefois pour d’autres projets, je peux comprendre que l’on souhaite ou préfère soutenir un projet financièrement . Alors si les gens tiennent vraiment à me remercier, me soutenir pour mes histoires de cette manière pourquoi pas ?

Merci Éric, et à bientôt !

Liens

• la page de l’abécédaire sur le site d’odysseuslibre
• téléchargement (pdf) de la version NB 
• appel à contribuer à la colorisation
• L’association AbdulÉdu

Dans les coulisses de l’abécédaire

• Phrases : Les phrases ont été généreusement imaginées par les élèves des classes :
  • Bibliosaigebib : Atelier informatique en bibliothèque, près de Bordeaux
  • maternelle gilly : Classe de GS de maternelle, Près de Dijon
  • les gribouilloux : Classe de MS GS de maternelle, près de Reims
  • cm1 curie : Classe de CM1, près de Bordeaux
  • brossocm : Classe de CM1 près de Nancy
  • cm1 teacher : Classe de CM1 à Pacé, près de Rennes
• Dessins : Eric Querelle aka Odysseus

• Outre crayon, gomme et feutres, cette histoire a été créée avec les logiciels libres suivants :
• Inkscape
• Gimp
• LibreOffice Draw 

• Polices de caractère : DejaVu Sans – Liberation Sans – Bromine Regular Font – Thickhead Regular Font

Le samedi 17 mai et le dimanche 18 mai à Gérardmer se déroulera un événement inédit dans la région Grand Est : Vosges Opération Libre. Il est ouvert à tous et orienté à la fois vers le grand public et les professionnels.

Cette opération libre est à l’initiative de Framasoft et d’autres d’associations d’envergure nationale ayant une grande expérience dans le Libre, l’ouverture des données, les licences libres et le libre accès.

Il s’agit de la seconde Opération Libre se déroulant sur le territoire français. La première ayant eu lieu à Brocas (Aquitaine) en 2013. Les Opérations Libres visent à rassembler, le temps d’un week-end, des acteurs du Libre en vue d’initier la démarche open data dans les petites villes et villages en présentant les outils disponibles, notamment des logiciels libres. Elles invitent les habitants à participer à l’ouverture et à la diffusion des données de leur territoire. Elles proposent aussi d’engager les citoyens dans un rapport différent avec leur territoire en montrant que le partage des connaissances leur permet d’être collectivement valorisées.

Cette initiative portera aussi sur les usages numériques, leur appropriation, leur potentiel de créativité et leur économie. Cette manifestation vise à promouvoir la culture libre et l’ouverture des données en organisant des actions thématiques formulées en stands, ateliers de formation, conférences, projection permanente de films libres, débats, etc.

Il s’agit d’un événement culturel et participatif où le logiciel libre et ses principes sont conçus comme autant de moyens au service des activités pratiques proposées à destination du grand public. Un travail préalable précédant la manifestation a été mené avec les acteurs de la vie culturelle locale, en particulier la médiathèque de Gérardmer (soirées Wikipédia, ateliers et conférence).

Le programme de la manifestation est disponible à l’adresse vosges.operation-libre.org. Il comprendra :

• 8 ateliers (4 permanents et 4 ponctuels) ;
• 9 conférences ;
• 1 conférence-débat le samedi soir
• 17 stands, des démonstrations ;
• une projection permanente de films libres…

GitHub a beau être une plateforme non libre de projets libres, force est de constater que cette « forge sociale » est devenue en quelques années l’un des centres névralgiques de la communauté.

Avec sa facilité d’usage, son appel permanent au fork et l’individuation des contributions, GitHub a permis a plus de monde de participer tout en ouvrant le Libre au delà du logiciel puisqu’il n’y a pas que du code proprement dit dedans (cf la liste de l’article traduit ci-dessous).

À tel point que certains n’hésitent pas à y voir un modèle pertinent pour toutes sorte de choses à commencer par la… démocratie !

Et si une génération toute entière était effectivement en train de naître sous nos yeux ?

La génération Github : Pourquoi vous et moi pouvons désormais faire de l’Open Source

The GitHub Generation: Why We’re All in Open Source Now

Mikeal Rogers – 7 mars 2013 – Wired Opinion
(Traduction : Moosh, Sphinx, Peekmo, Chopin, goofy, misc, Uflex + anonymes)

GitHub a été conçu pour être une plate-forme de collaboration logicielle ouverte, mais c’est devenu une plate-forme pour déposer beaucoup plus de choses que du simple code. Elle est maintenant utilisée par des artistes, des créateurs, des propriétaires de maisons et des tas d’autres gens, par des entreprises entières… et même par des municipalités.

« N’importe qui peut maintenant changer les données quand de nouvelles pistes cyclables sont aménagées, quand de nouvelles routes sont construites ou quand de nouveaux immeubles sont construits » a annoncé récemment la ville de Chicago. Les gens planifient leurs projets de rénovation de maison sur GitHub. Un cabinet d’avocats a annoncé il y a quelques jours qu’il postait des documents juridiques pour des start-ups sur GitHub. Quelqu’un a même publié toutes les lois d’Allemagne sur GitHub l’année dernière (avec, s’il vous plaît, déjà 17 pull requests pour des modifications).

Bien sûr, GitHub reste majoritairement toujours utilisé par les programmeurs et développeurs qui font voler des AR.Drones avec Node.js ou construisent des sites web avec jQuery. Mais de plus en plus de gens passent de consommateurs à producteurs, et ils redéfinissent ainsi la culture de l’open source. Je crois que GitHub transforme l’open source comme l’internet a transformé l’industrie de la publication : un fossé culturel est en train de se creuser entre l’ancienne génération de gros projets libres et la nouvelle génération d’amateurs de projets libres d’aujourd’hui.

La révolution ne sera pas centralisée

Quand la plupart des gens entendent « open » source, ils pensent démocratie, distribution, égalité : tout le monde construit des choses pour que tout un chacun les utilise.

Mais cela n’a pas toujours été le cas. La plupart des logiciels open source ont été créés et maintenus par une classe privilégiée et protégée, les développeurs professionnels, qui interagissaient avec d’autre développeurs très semblables (ils sont pourtant suffisamment différents pour avoir de belles disputes).

Avant GitHub, je passais beaucoup de temps à penser et à discuter de la meilleure façon de gérer des projets open source parce que la coordination représentait un coût important d’un projet open source. Si important que lorsqu’un projet réussissait et développait une communauté assez grande, il était logique que le projet grandisse plutôt qu’il ne se fracture en projets plus petits. Mais plus le projet du logiciel devenait grand et complexe, plus il était difficile d’y contribuer. Ainsi, un choix de membres, les commiters – étaient assignés à la gestion et à la production du projet. Cela menait souvent à des ruptures séparant ceux qui produisaient le projet et ceux qui les utilisaient.

GitHub a comblé ce fossé en faisant de l’open source quelque chose de bien plus décentralisé. C’est devenu davantage centré sur les individus que sur le projet.

La façon d’utiliser GitHub est trés personnelle. Une personne (je suis github.com/mikeal) a un compte, et tout ce qu’elle publie existe à un niveau en dessous d’elle. Si quelqu’un veut corriger quelque chose, il suffit de « forker » le projet, ce qui place une copie sous son propre compte.

Cette façon de travailler est trés stimulante : elle encourage les individus à corriger les problèmes et à prendre possession des correctifs au même niveau que le projet de départ. Cela donne également à chacun une identité dans cette nouvelle culture du libre. GitHub est actuellement le premier fournisseur d’identité pour la production collaborative sur internet pour faire plus que du développement de code.

J’ai contribué à des projets libres depuis plus de 10 ans, mais ce qui est différent maintenant est que je ne suis pas un membre d’un de ces projets, je suis un simple utilisateur, et contribuer un peu est devenu une petite partie du rôle d’un utilisateur. Des petites interactions entre moi et les mainteneurs de projets arrivent plusieurs fois par semaine sur tout type de projet que j’utilise. Et ça arrive encore plus souvent dans l’autre sens : des gens dont je n”ai jamais entendu parler m’envoient des petits bouts de code sur les petits projets que j’ai publiés.

La décentralisation comme démocratie

Les premières versions de GitHub ont très bien fait une chose : rendre la publication de votre code beaucoup plus facile (que la non-publication). Ceci était suffisant pour que beaucoup de projets connus, notamment Ruby on Rails, migrent sur GitHub presque immédiatement.

Mais ce qui s’est passé après est encore plus intéressant : les gens ont commencé à tout publier sur GitHub. Pousser du code est presque devenu une habitude, comme tweeter. En abaissant la barrière pour entrer et rendant plus facile la contribution à l’open source, GitHub a élargi la production collaborative aux utilisateurs occasionnels.

Aujourd’hui un vaste choix de logiciels simples et compréhensibles est accessible à une catégorie de gens créatifs qui n’avaient jusqu’alors pas les compétences techniques requises pour participer à des projets open source par le passé.

Ce mélange des relations entre les producteurs, les contributeurs et les consommateurs valorise naturellement les projets plus petits et plus faciles à comprendre — et a conduit à de nombreuses contributions. Au cours du mois de septembre 2012 par exemple, la moitié des utilisateurs actifs de GitHub qui ont poussé au moins un changeset, l’ont fait moins de cinq fois, avec 22% (environ 44 000 personnes) qui ont poussé seulement un seul changeset ce mois-ci.

L’accès de l’open source aux amateurs présente certains avantages évidents.

Faciliter les usages

Un des problèmes récurrents, avec le logiciel open source, a été la qualité des finitions. La documentation, le design des sites web et l’ergonomie en général ont toujours été un problème — spécialement par rapport à de nombreux concurrents propriétaires.

Mais maintenant, avec les facilités de collaboration, des utilisateurs moins portés sur la technologie et la connaissance du code peuvent plus facilement participer à améliorer les logiciels sur lesquels ils travaillent (ce qui peut être des petites choses comme l’humanisation des messages d’erreur de codage ou de légers changements graphiques en une ligne de CSS qui optimisent le rendu des sites web des navigateurs, anciennes versions incluses, et sur les téléphones mobiles).

Dans le nouvel open source, les gens veulent utiliser la technologie sans avoir besoin de devenir des experts. La facilité d’utilisation est plus valorisée que jamais.

Éviter de réinventer la roue

Les développeurs aiment les défis et plus ils ont de chances de les relever, plus leurs solutions peuvent être astucieuses. C’était parfait lorsque les utilisateurs de ces solutions étaient eux aussi des gens très compétents techniquement comme ceux qui prenaient plaisir à résoudre astucieusement ces anciens problèmes.

Mais les amateurs préfèrent les solutions qu’ils peuvent tenir pour acquises : une fois qu’un problème est résolu, ils reviennent rarement en arrière pour le réexaminer. Et dans la mesure où les amateurs ne créeront qu’à partir des solutions les plus compréhensibles, cela contraint les développeurs à élaborer des solutions simples qui rendent les problèmes complexes plus faciles à appréhender.

Soutenir un écosystème plus vaste

Node.js, projet dans lequel je suis activement impliqué, définit des modèles suffisamment simples pour que les gens puissent écrire de petites bibliothèques indépendantes et les publier à leur gré. Tous ceux qui s’impliquent dans l’écosystème peuvent en tirer profit sans coordination. C’est le pôle inverse de l’énorme pile verticale qui accompagne des tas d’outils et fonctionnalités (tels que dans les systèmes intégrant des plugins, comme Ember, Dojo et YUI) qui sont nécessaires pour réussir à développer dans des environnement propriétaires (pensez à Cocoa et au développement pour iOS). Dans les environnements ouverts, tels que Node.js sur GitHub, nous constatons que des API bien plus légères peuvent facilement tirer parti du reste de l’écosystème sans coordination. Moins il y a de coordination entre les développeurs et les bibliothèques et plus nous pouvons créer de la valeur.

GitHub a donné les capacités à une nouvelle génération de collaborer, de créer, de produire. Beaucoup de développeurs regretteront l’abandon des normes culturelles précédentes, telles que le statut des commiters (ceux qui sont autorisés à envoyer le code sur le dépôt) ou la bonne vieille guerre pour le choix de la bonne licence — mais l’avenir est déjà entre les mains d’une nouvelle génération qui a évolué.

Ce n’est pas un simple outil : c’est à la naissance d’une nouvelle culture à laquelle nous assistons.

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.