Le Framachin de la rentrée est un jeu…

Sérieux.

Un serious game avec une infinité d’applications pédagogiques que nous proposons avant que l’ogre Microsoft ne vienne faire la sortie des écoles… voire y rentrer pour mieux dévorer les données de nos chères têtes blondes.

 

C’est parti d’une blague. Après la parution d’une traduction de Framalang sur Minetest, l’alternative libre au jeu Minecraft, un certain SVTux nous a partagé ce qu’il faisait en classe avec ce jeu tandis qu’un certain Powi nous a demandé “À quand un Framinetest ?“… Nous avons rétorqué d’un « C’est çui qui dit qui fait ! » auquel lui et SVTux ont répondu « chiche ! »

Ce n’était pas prévu. Le jeu Minecraft (racheté par Microsoft en 2014 pour 2,5 milliards de dollars) ne faisait pas partie de notre plan pour dégoogliser internet. Puis, nous avons vu que le 9 juin dernier, Microsoft a lancé la bêta de Minecraft : Education Edition…

Chère Éducation Nationale… Tu joues avec nos gosses.

Et ça, vraiment, c’est pas drôle.

Tu le sais pourtant, nous on t’aime bien. Nombre de nos membres (et de notre audience) travaillent en ton sein, les “Fra” et “ma” de Framasoft viennent même de “Français” et “Mathématiques” (les matières enseignées par les deux professeurs à l’origine du tout premier projet Framasoft)… bref, nous avons une longue histoire commune.

Nous nous sommes éloignés de toi (en nous tournant vers l’éducation populaire) un peu par dépit : car tu ne veux rien entendre. Tu te laisses courtiser par les GAFAM, tu leur ouvres grand les portes de nos établissements d’enseignement… sans assumer le fait que c’est aussi grave que d’ouvrir les portes des cantines à McDonald’s.

Quand tu échanges les données de nos collégiens et nos collégiennes contre 13 millions d’euros de Microsoft, quand tu laisses ce dernier t’instrumentaliser pour faire sa pub, au point que d’aucuns envisagent de dénoncer cet accord en justice… Tu n’entends pas nos avertissements.

Tu souhaites juste « mettre en tension » les propositions du Libre et celles de GAFAM. Comme s’il s’agissait de deux concurrents sur un marché.

Comme si protéger les vies numériques de nos élèves n’était pas un choix politique.

Ce choix, nombre d’enseignant-e-s l’ont fait, souvent bien malgré toi. C’est en pensant à elles et eux que nous ouvrons ce nouveau service, avant que Microsoft ne vienne cette fois-ci parachever son business model chez toi en faisant son marché dans nos écoles primaires avec Minecraft : Education Edition.

Framinetest Édu : à vous de jouer !

Et là, ça devient vraiment bien plus drôle.

Minetest est un clone libre de Minecraft, un jeu dit « bac à sable ». Imaginez un monde fait de cubes : terre, eau, troncs, feuillages, minéraux, sable, glace… mais aussi plantes, poules, vaches et cochons (et même des zombies !) Ce monde est régi par des règles similaires au nôtre : le jour succède à la nuit, avec le temps l’érosion y fait son office, les poules ne se reproduisent que si l’on met un coq dans l’enclos, tomber de trop haut altère votre santé.

Vous y incarnez un petit personnage dont le but est de “miner”, c’est à dire de briser les blocs de matières premières pour les mettre dans sa besace et en faire d’autres choses. Dans votre inventaire, « crafter » un bloc de bois vous permet d’obtenir des planches. Aligner planches et bâtons en T vous permet de fabriquer (crafter) une pioche… et d’aller creuser pour obtenir du grès, du granit… Dès lors vous pouvez commencer à construire !

Nous avons ouvert un monde où les ressources sont déjà dans votre inventaire, qui peut supporter jusqu’à 400 connexions simultanées (c’est de la théorie, hein, pas un défi : restez choux avec nos serveurs ^^ !), un monde dont les mods (les possibilités modulaires) ont été choisis et pensés pour des applications pédagogiques…

Bref : un monde qui n’attend que vous pour y construire collaborativement des villages et des activités pédagogiques !

Microsoft enclot Minecraft… alors changez de bac à sable !

Pour se connecter à Framinetest Édu, c’est simple ! Tout est sur la page d’accueil :

1. Téléchargez le logiciel « client » (celui qui permet de se connecter.)
2. Connectez-vous sur le serveur framinetest.org (onglet « client », justement ^^)
3. Euh… jouez ? Oui : jouez !

L’avantage d’un jeu open source (développé en C/C++, et sous licence CC-BY-SA) est qu’il est adaptable sur toutes les plateformes, que vous soyez sous Windows, sous Mac, sous une des nombreuses distributions libres GNU/Linux, sur Android ou même sur un RaspberryPi : vous jouerez au même jeu partout.

Cela parait évident, mais les personnes qui ont testé Minecraft Windows10 Edition (qui est un peu le même que le Pocket Edition sur smartphone, donc incompatible avec la version PC du jeu, oui cette phrase fait mal au crâne, merci Microsoft & Mojang !) savent de quoi on parle.

Autre avantage, Minetest regroupe aussi une joyeuse communauté de libristes qui seront ravi-e-s de vous aider et vous conseiller. D’ailleurs, Powi a contribué à mettre à jour le wiki francophone pour que nous soyons certains que vous y trouviez les informations qui vous manquent ! (EDIT du 2 sept. : les contributions au wiki-fr se poursuivent : venez rejoindre la fine équipe en lisant ceci ;) ) Et s’il vous reste des questions, pensez à les poser sur le forum…

L’avantage enfin, c’est que les règles concernant le jeu sont les vôtres ! Impossible pour Microsoft d’interdire ceci, de restreindre cela ou de faire payer l’accès à telle fonctionnalité : le Libre vous offre la maîtrise de votre monde. D’ailleurs, avant de vous connecter sur notre serveur, pensez à lire nos conditions générales d’utilisation ! (cela prend moins de 5 minutes et s’applique à tous nos services ^^)

Si ces dernières ne vous conviennent pas, ou que vous souhaitez un serveur et un monde réservé à votre classe / école / collège / famille / bande de potes / etc., vous vous donnons toutes nos astuces pour installer facilement Minetest chez vous et gagner en indépendance.

Changer l’école malgré l’Éducation Nationale

Les possibilités pédagogiques dans Framinetest Édu (et de Minetest, plus généralement) sont tellement nombreuses que nous avons décidé de leur consacrer un article complet. C’est un article écrit par Frédéric Véron, le fameux SVTux, professeur de Sciences de la Vie et de la Terre qui utilise Minetest dans son collège et nous a transmis son savoir-faire.

Sa démarche prouve qu’il est possible de proposer des activités numériques ludiques, pédagogiques et innovantes en respectant les données des élèves et sans les accoutumer aux produits commerciaux des GAFAM. Ce n’est qu’une démarche d’enseignant parmi les centaines d’autres dont nous avons été témoins chez Framasoft.

Nous n’avons plus vraiment d’espoir d’un changement provenant « d’en haut », comme on dit. Mais nous savons la force et l’implication du personnel encadrant nos élèves… Voilà pourquoi nous nous adressons à vous, et nous espérons que vous saurez vous emparer de ce nouvel outil.

Bref : à vous de creuser !

Pour aller plus loin :

• Découvrir Framinetest Édu
• Les applications pédagogiques de Framinetest Édu
• Plus de ressources pédagogiques sur le site de SVTux.
• Installez votre serveur Minetest
• Le site officiel de Minetest [EN]
• Le wiki francophone de Minetest
• Le forum francophone de Minetest

Vous êtes libriste et vous avez envie de dégoogliser avec nous ?

Les milliers de visiteur-euse-s de la Fête de l’Humanité n’attendent que vous !

En septembre, c’est vraiment the place to be, comme disent nos amis de chez Apple !

Ce sont des milliers de personnes, depuis le simple amateur de bonne musique jusqu’à la militante la plus dévouée en passant par les curieux, qui se pressent à la Fête de l’Huma chaque année. Habituées à débattre, vigilants quant à leurs droits, beaucoup négligent pourtant leur hygiène numérique, offrant innocemment leurs données privées au premier GAFAM venu.

Depuis des années, la Fête accueille accueille un espace dédié à la culture libre, aux hackers et aux fablabs.

Contrairement aux événements libristes où nous croisons souvent des geeks déjà convaincus, nous aurons là la vraie famille Dupuis-Morizeau, celle dont nous vous parlons à longueur d’année. Il y a du boulot, nous ne serons jamais trop nombreux-ses.

Venez donc nous aider à tenir le stand !

Ça permettrait de se voir en vrai, et d’assurer des relais (pour les pauses techniques et les coups de fatigues). En général il y a une ambiance d’enfer. ;-)

Manifestez-vous sur la page Contact, histoire de s’organiser.

Fête de l’Huma, Parc de la Courneuve, du 9 au 11 septembre 2016.

Julie Guillot est une artiste graphique (son book en ligne) qui vient d’entamer le récit de son cheminement vers le partage libre de ses œuvres. Elle y témoigne de façon amusante et réfléchie de ses doutes et ignorances, puis de sa découverte progressive des libertés de création et de copie…

C’est avec plaisir que nous republions ici cette trajectoire magnifiquement illustrée.

Droit de copie #1

Une chronique de Julie Guillot publiée d’abord sur son blog

Quand j’ai créé ce blog il y a 2 ans, puis le second sur les violences scolaires, mes proches m’ont encouragée et soutenue. Mais beaucoup (parfois les mêmes) m’ont aussi mise en garde, voire se sont sérieusement inquiétés.

Ces peurs étaient très liées à Internet, à l’idée d’un espace immense, obscur, peu ou pas réglementé, ainsi qu’à la notion de gratuité qui en fait partie. Y publier ses images et ses productions reviendrait à les jeter par la fenêtre.

Mais la crainte était, au-delà d’Internet et du support blog, une crainte (vraiment forte) du pillage, de l’expropriation et de la copie.

Personnellement, je ne pensais pas d’emblée à ces “risques”. J’avais envie et besoin de montrer mon travail, donc de le partager. Mais devant ces alertes, et voyant que tout le monde semblait partager le sentiment du danger et le besoin de s’en protéger, j’ai apposé un copyright en bas de mon blog, avec la mention “tous droits réservés”, et j’ai supprimé le clic droit.

En fait je n’avais pas du tout réfléchi à cette question. Je ne savais pas grand chose du droit d’auteur et du copyright.

Mais dès le début je ressentais une forme de malaise. Je savais que supprimer le clic droit n’empêcherait personne de récupérer une image. Et j’avais vaguement entendu que cette mention de copyright ne servait pas à grand-chose non plus.

Était-ce une saine prudence… ou une forme de paranoïa ?

Et puis, j’ai commencé à recevoir des demandes de personnes qui souhaitaient utiliser mes images. Pour une expo, un travail de recherche, une conférence, un cours…. Spontanément, je disais toujours oui. Parce que je ne voyais aucune raison de refuser. Non seulement je trouvais cela flatteur, mais en plus cela m’apparaissait comme une évolution logique et saine de mon travail : à quoi sert-il s’il ne peut être diffusé, partagé, utile aux autres ?

Petit à petit cela m’a fait réfléchir. Des gens venaient me demander mon autorisation simplement pour citer mon blog quelque part (ce qui n’est pas interdit par le droit d’auteur… !). Je ne pouvais pas le leur reprocher : après tout, j’avais apposé une mention “touts droits réservés”. Mais l’absurdité de la situation commençait à me parvenir.

Un jour, j’ai reçu une demande d’ordre plus “commercial” : quelqu’un qui souhaitait utiliser mes images pour une campagne de financement d’une épicerie végane.

Spontanément, j’ai hésité. Ne devais-je pas lui demander de l’argent ?
J’ai exprimé des conditions : je voulais être informée des images qu’il utiliserait, à quel endroit, des textes qu’il allait modifier, etc. Ce qu’il a accepté.
Mais très vite je me suis demandé pourquoi j’avais posé de telles conditions. Parce qu’en réalité, ça m’était égal.

Finalement, il n’a pas utilisé mes images. Mais il m’a permis de réaliser que je n’avais pas de position claire sur la manière dont je voulais partager ou non mon travail, que je ne connaissais rien à la législation, aux licences d’utilisation et à de possibles alternatives.

 

J’ai donc commencé à m’intéresser de plus près à ces questions de copyright, de droit d’auteur, de culture libre et de licences.

Ce qui m’a amenée à réfléchir à me conception de l’art, de la créativité, et même, plus largement, du travail.

Gwenn Seemel explique très bien que le droit d’auteur n’est pas uniquement un système juridique, mais un paradigme :

Nous envisageons l’art, la production de la pensée, comme des productions inaliénables ; nous assimilons la copie à du vol ; nous considérons l’imitation comme un acte malhonnête, une paresse, quelque chose de forcément blâmable. Il va de soi que nous devons demander l’utilisation à quelqu’unE pour utiliser ses écrits, ses images, sa musique, afin de créer quelque chose avec. Et nous ne remettons quasiment jamais ce paradigme en question.

Nous avons tous grandi avec l’idée que copier était (très) (très) mal. Et punissable.

Quand j’étais à la fac, certainEs étudiantEs refusaient de dire quel était leur sujet de mémoire ou de thèse…de peur qu’on leur “pique” leur(s) idée(s). J’étais naïve…et consternée.

C’était pour moi incompatible avec la conception que j’avais de la recherche et du travail intellectuel.

Bien sûr, ces comportements sont le résultat de la compétition qui structure notre société et une grande partie de nos relations. Toute production est considérée comme strictement individuelle, personnelle, comme si nous étions capables de créer à partir de rien.

Je me suis sentie profondément enthousiaste de découvrir des artistes qui rendent leurs oeuvres publiques, c’est à dire qui en permettent la libre diffusion, la copie, l’utilisation, la modification, des gens qui réfléchissent à ces questions et militent pour une culture différente.

Comme Nina Paley, par exemple :

J’étais convaincue, au fond, par la pertinence d’une culture sans copyright et je me sentais soulagée à l’idée de franchir le pas, moi aussi.

Je n’ai jamais ressenti un sentiment fort de propriété vis-à-vis de mes dessins.

J’ai toujours aimé copier, je m’inspire du travail des autres (comme tout le monde), et je trouve a priori naturel que mes productions puissent circuler, servir à d’autres, être utilisées et même transformées.

L’idée de pouvoir utiliser les œuvres des autres, comme me dessiner habillée en Gwenn Seemel, est tout aussi enthousiasmante.

Cet élan spontané cohabitait en moi avec la persistance de craintes et de méfiances :

et si on se faisait de l’argent “sur mon dos” ? Et si je le regrettais ? Ne suis-je pas responsable de tout ce que je produis, et donc de tout ce que deviennent mes productions ? Ne devrais-je pas demander de l’argent pour toute utilisation de ce que j’ai fait ? Est-ce que je ne fais donc rien d’original et de personnel ? Et si cela m’empêchait de gagner de l’argent avec mon travail artistique ? Et comment faire dans une société où le principe du droit d’auteur est la règle ?

J’avais besoin d’en savoir plus sur les aspects juridiques de la question, même si ça me semblait au départ rébarbatif.

Alors je me suis penchée sur le sujet. Comme dit Gwenn Seemel, personne ne va se brosser les dents à votre place.

(mais il y a des gens qui fournissent le dentifrice, et ça c’est sympa).

[À suivre…]

Gwenn Seemel m’a beaucoup aidée à avancer dans ma réflexion sur le droit d’auteur, la culture libre, la pratique de l’art en général. Ses vidéos et ses articles ont répondu à beaucoup de mes questions (puisqu’elle s’était posé les mêmes que moi, logiquement). Je vous conseille la lecture de son blog, et de son livre sur le copyright.

Le blog de S.I.lex est aussi une mine d’informations sur le sujet.

0.6.0.0 !

Ce numéro de version fait la fierté de la communauté Diaspora*.

Le réseau social décentralisé, dont Framasoft héberge un pod sous le nom de Framasphère, fait le plein de nouveautés.

 

Cela fait aujourd’hui quatre ans que diaspora*, le réseau social libre et respectueux de la vie privée, a été confié à sa communauté par ses fondateurs. Quatre années de nettoyage du code, de correction de bogues, de refonte et de nouvelles fonctionnalités. Durant ces quatre ans, 42 (ça ne s’invente pas) contributeurs bénévoles ont ajouté 44 221 lignes de code et en ont supprimé 38 560 au sein de 6 versions majeures. Car oui, aujourd’hui, pour l’anniversaire de diaspora*, cette sixième version majeure est la plus grande jamais sortie par la communauté.

Cette version contient de très nombreux changements, tant au niveau de l’expérience utilisateur que des rouages internes. L’interface a été entièrement refondue pour être plus moderne et plus agréable à utiliser. Elle devient dans le même temps personnalisable grâce à l’introduction des thèmes de couleur (dont le thème Original White Background pour revenir à l’ancienne interface).

Il est désormais possible de rendre son profil public, permettant ainsi à des organisations de s’en servir comme page de présentation, ou d’être utilisé comme blog.

Cette dernière version intègre un éditeur markdown, permettant une mise en forme beaucoup plus simple pour les utilisateurs et utilisatrices (vous pouvez toujours utiliser la syntaxe markdown directement).

—-
Listes des nouveautés de la v 0.6.0.0 de diaspora* (changelog complet)

• support des thèmes : il est désormais possible de changer le thème de diaspora* (#6033)
• possibilité de régler les paramètres de confidentialités et les services depuis la version mobile (#6086)
• possibilité de rendre son profil public (visible sans avoir à partager) (#6162)
• les votes et localisations sont désormais visibles sur la version mobile (#6238)
• géolocalisation (si souhaitée) via OpenStreetMap (#6256)
• un thème pour revenir à l’ancienne version de diaspora* (#6631)
• ajout d’un éditeur markdown pour simplifier la mise en page (#6551)
• accessibilité améliorée sur de nombreuses pages (#6227)
• fédération grandement améliorée (#6873)
• redesign de la page Flux (#6535)
• redesign de la page Conversations (#6431) et #6087)

On est en tout cas bien heureux de vous avoir nombreux sur framasphère depuis bientôt deux ans ! En espérant que ce service vous plaise. Nous, on est fier de le voir toujours évoluer !

Le groupe Framalang a traduit l’article de Julien, qui a listé tous les moyens de se tirer une balle dans le pied quand on coordonne un projet libre.

Apprenez à les éviter !

Conduite de projets Open Source : 10 erreurs à éviter

Article original : https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice
Auteur : Julien Danjou(CC-BY-SA)
Traduction : lyn., KoS, AlienSpoon, David 5.1, Simon, goofy, Slimane Aguercif, Fred, galadas, terhemis, gégé

Il y a quelques semaines, lors de l’OpenStack Summit (réunion annuelle des contributeurs à OpenStack, NDT), j’ai eu l’occasion de discuter de mon expérience de la conduite de projets Open Source. Je me suis rendu compte qu’après avoir fait partie de plusieurs communautés et beaucoup contribué pendant des années, je pourrais faire profiter les nouveaux venus de conseils et d’avis expérimentés.

Il existe une foule de ressources disponibles expliquant comment conduire un projet Open Source. Mais aujourd’hui, je voudrais aborder ce sujet sous un angle différent, en insistant sur ce qu’il convient de ne pas faire avec les personnes qui y participent. Je tire cette expérience des nombreux projets Open Source auxquels j’ai participé ces dernières années. Je vais décrire, sans ordre particulier, quelques mauvaises pratiques que j’ai constatées, en les illustrant par des exemples concrets.

 

1. Considérer les contributeurs comme une nuisance

Quand les informaticiens sont au travail, qu’ils soient chargés du développement ou de la maintenance d’un logiciel, il est une chose dont ils n’ont pas besoin : du travail supplémentaire. Pour la plupart d’entre eux, la première réaction à toute contribution externe est : « Zut, du travail en plus ». Et c’est effectivement le cas.

Par conséquent, certains développeurs essayent d’éviter ce travail supplémentaire : ils déclarent ne pas vouloir de contributions, ou font en sorte que les contributeurs se sentent indésirables. Cela peut prendre de nombreuses formes, comme les ignorer ou être désagréable avec eux. Ainsi, les développeurs évitent d’avoir à traiter le surplus de travail qu’on leur met sur le dos.

C’est une des plus grandes erreurs que l’on peut commettre, et une vision fausse de l’Open Source. Si des gens vous apportent du travail supplémentaire, faites tout ce que vous pouvez pour bien les accueillir afin qu’ils continuent à travailler avec vous. Il s’agit peut-être de ceux qui prendront votre relève d’ici peu. Préparez votre future retraite.

Prenons le cas de mon ami Gordon, que j’ai vu démarrer en tant que contributeur sur Ceilometer en 2013. Il examinait très bien le code, si bien qu’il me donnait en fait davantage de travail : non seulement en détectant les anomalies dans mes contributions, mais aussi en me faisant vérifier les siennes. Au lieu de m’en prendre à lui pour qu’il arrête de me faire retravailler mon code et vérifier ses correctifs, j’ai proposé qu’on lui fasse davantage confiance en l’ajoutant officiellement à l’équipe des correcteurs sur un des projets.

Et s’ils ne font pas cette première contribution, ils ne feront pas non plus la seconde. En fait, ils n’en feront aucune ; et ces projets perdraient alors leurs futurs correcteurs.

2. Ne confier aux autres que le sale boulot

Lorsque de nouveaux contributeurs se présentent pour travailler sur un certain projet, leurs motivations peuvent être très diverses. Certains sont des utilisateurs, d’autres veulent simplement voir ce que c’est de contribuer. Ressentir le frisson de la participation, comme un simple exercice ou avec la volonté d’apprendre afin de contribuer en retour à l’écosystème qu’ils utilisent.

En général, les développeurs confient le sale boulot à ces personnes, c’est à dire des tâches sans intérêt, à faible valeur ajoutée, et qui n’auront sans doute aucun impact direct sur le projet.

Pour certains, ce n’est pas grave, pour d’autres, ça l’est. Certains seront vexés de se voir confier du travail sans grand intérêt, alors que d’autres seront heureux de le faire pourvu qu’on leur témoigne de la reconnaissance. Soyez sensible à cela, et félicitez ces personnes. C’est la seule manière de les garder dans le projet.

3. Mépriser les petites contributions

Quand le premier patch d’un nouveau contributeur est une correction d’orthographe, qu’en pensent les développeurs ? Qu’ils s’en fichent, que vous gâchez de leur temps précieux avec votre petite contribution. Et personne ne s’intéresse à la perfection grammaticale d’une documentation, n’est-ce pas ?

C’est faux. Voyez mes premières contributions à home-assistant et Postmodern : j’ai corrigé des fautes d’orthographe dans la documentation.

J’ai contribué au projet Org-mode pendant quelques années. Mon premier patch corrigeait simplement une chaîne de caractères du code. Ensuite, j’ai envoyé 56 patchs, corrigeant des bogues et ajoutant de nouvelles fonctionnalités élégantes, et j’ai aussi codé quelques extensions. À ce jour, je suis toujours seizième dans la liste des plus gros contributeurs d’Org-mode, qui en contient 390. Certainement pas ce qu’on appellerait un petit contributeur, donc. Je suis sûr que la communauté est bien contente de n’avoir pas méprisé ma première correction dans la documentation.

4. Mettre la barre trop haut pour les nouveaux arrivants.

Quand de nouveaux contributeurs arrivent, leurs connaissances du projet, de son contexte, et des technologies sont très variables. L’une des erreurs que les gens font le plus souvent consiste à demander aux nouveaux contributeurs des choses trop compliquées, dont ils ne pourront pas venir à bout. Cela leur fait peur (surtout les timides ou les introvertis) et ils risquent de disparaître, se croyant trop stupides pour aider.

Avant de faire le moindre commentaire, vous ne devriez avoir strictement aucun a priori sur leur niveau. Cela permet d’éviter ce genre de situations. Il faut également mettre beaucoup de délicatesse quand vous estimez les compétences des nouveaux, car certains pourraient se vexer si vous les sous-estimez trop.

Quand son niveau est bien estimé (un petit nombre d’échanges devrait suffire), vous devez former votre contributeur en ne le guidant ni trop ni trop peu, afin qu’il puisse s’épanouir. Il faut du temps et de l’expérience pour y parvenir, et vous allez probablement perdre certains contributeurs avant de bien maîtriser ce processus, mais c’est un chemin que tous ceux qui gèrent des projets doivent suivre.

Façonner ainsi les nouveaux arrivants est au cœur de la gestion de vos contributeurs, et ce quel que soit votre projet. Et je suis quasiment sûr que cela s’applique à tout projet, même en dehors du logiciel libre.

5. Exiger des gens qu’ils fassent des sacrifices sur le plan personnel

C’est un point qui dépend beaucoup du projet et du contexte, mais il est très important. Dans le logiciel libre, où la plupart des gens vont contribuer par bonne volonté et parfois sur leur temps libre, vous ne devez surtout pas exiger d’eux qu’ils fassent des sacrifices personnels importants. Ça ne passera pas.

L’une des pires manières de faire cette erreur est de fixer un rendez-vous à l’autre bout du monde pour discuter du projet. Cela place les contributeurs qui vivent loin dans une situation injuste, car ils ne peuvent pas forcément quitter leur famille pour la semaine, prendre l’avion ou un autre moyen de transport, louer une chambre d’hôtel… Ce n’est pas bon : tout devrait être mis en œuvre pour que les contributeurs se sentent partie prenante du projet et intégrés à la communauté, sans que l’on exige cela de leur part. Entendons-nous bien, cela ne veut pas dire qu’il faut s’interdire toute rencontre ou activité sociale, au contraire. Pensez simplement à n’exclure personne lorsque vous discutez d’un projet.

Il en va de même pour les moyens de communication susceptibles de compliquer la vie des participants : se retrouver sur IRC (il est difficile pour certaines personnes de réserver une heure, surtout lorsqu’il faut tenir compte des différents fuseaux horaires), faire une visioconférence (en particulier quand on n’utilise pas de logiciel libre et gratuit), etc.

En gros, tout ce qui impose de se synchroniser en temps réel avec l’avancement du projet est contraignant pour certains contributeurs.

C’est pourquoi le meilleur moyen de communiquer reste le courriel, mais tous les outils de communication asynchrones (pisteurs de bogues, etc.) feront l’affaire dans la mesure où ils permettent à chacun de travailler à son rythme et à l’heure qui lui convient.

6. Ne pas avoir de code de conduite

À une époque où de plus en plus de communautés s’ouvrent à un public plus large que celui auquel elles étaient habituées (ce qui est fantastique), les codes de conduite semblent être un sujet à la mode, mais aussi délicat.

En réalité, toutes les communautés ont un code de conduite, qu’il soit inscrit noir sur blanc ou suivi inconsciemment par chacun. Sa forme dépend de la taille et de la culture de la communauté.

Cependant, en fonction de la taille de votre communauté et de la façon dont ce code s’applique, vous auriez peut-être intérêt à l’écrire dans un document, comme l’a par exemple fait Debian.

Ce n’est pas parce que vous aurez rédigé un code de conduite que tous les membres de votre communauté vont soudain se transformer en adorables Bisounours le suivant à la lettre, mais il fournit des règles que vous pouvez citer en cas de besoin. Il peut être utile de le transmettre à certains pour leur faire comprendre que leur comportement ne convient pas, et cela peut aider si une exclusion devient nécessaire, même s’il ne sert que rarement à cela, puisqu’en général personne ne veut aller aussi loin.

Je pense qu’on peut très bien se passer d’un tel document sur de petits projets. Mais vous devez garder à l’esprit qu’un code de conduite implicite découlera de votre comportement. La manière dont vos membres les plus influents communiqueront avec les autres installera l’ambiance à travers tout le réseau. Ne sous-estimez pas cela.

Quand nous avons commencé le projet Ceilometer, nous avons suivi le code de conduite du projet OpenStack avant même qu’il ait été écrit, et probablement avons-nous même placé la barre un peu plus haut. En étant agréables, accueillants et ouverts d’esprit, nous avons réussi à obtenir une certaine mixité, avec plus de 25 % de femmes dans notre équipe permanente — bien au dessus de la moyenne actuelle d’OpenStack et de la plupart des projets de logiciel libre !

7. Mettre les non-anglophones à l’écart

Il est important d’être conscient que la grande majorité des projets de logiciel libre utilisent l’anglais en tant que langue de communication principale. C’est logique. C’est une langue répandue, et qui semble remplir ce rôle correctement.

Mais une grande partie des codeurs n’ont pas l’anglais pour langue maternelle. Beaucoup ne le parlent pas couramment. Cela signifie que le rythme auquel ils peuvent converser peut-être très lent, ce qui peut en frustrer certains, notamment ceux qui sont nés en terre anglophone.

 

On peut observer ce phénomène dans les rencontres de codeurs, lors de conférences par exemple. Quand les gens débattent, il peut être très difficile pour certains d’expliquer leurs pensées en anglais et de communiquer à un rythme correct, ce qui ralentit la conversation et la transmission des idées. La pire chose qu’un anglophone puisse faire dans ce cas est de leur couper la parole, ou de les ignorer, pour la seule raison qu’ils ne parlent pas assez vite. Je comprends que cela puisse être frustrant, mais le problème n’est pas la façon de parler des non-anglophones mais les outils de communication utilisés qui ne mettent pas tout le monde au même niveau en privilégiant des conversations orales.

La même chose s’applique, à un moindre degré, aux rencontres sur IRC, qui sont relativement synchrones. Les médias complètement asynchrones ne pâtissent pas de ce défaut, et c’est pourquoi ils faudrait, à mon avis, les privilégier.

8. Pas de vision, aucune délégation des tâches

C’est une autre grosse erreur de gestion si le responsable ne parvient pas à gérer la croissance du projet alors que des gens sont disponibles et prêts à aider.

Évidemment, lorsque le flux des contributeurs commence à grossir, ajoutant de nouvelles fonctionnalités, demandant des retours et des instructions à suivre, certains responsables se retrouvent la tête sous l’eau et ne savent pas comment répondre. Ce qui a pour conséquences de frustrer les contributeurs, qui vont simplement partir.

Il est important d’avoir une vision de votre projet et de la communiquer. Dites clairement à vos contributeurs ce que vous voulez, et ne voulez pas, dans votre projet. Exprimer ces informations de manière claire (et non-agressive !) permet de minimiser les frictions entre vos contributeurs. Ils vont vite savoir s’ils veulent rejoindre ou non votre navire et quoi en attendre. Donc, soyez un bon capitaine.

S’ils choisissent de travailler avec vous et de contribuer, vous devez rapidement commencer à croire en eux et à leur déléguer certaines de vos responsabilités. Cela peut être n’importe quelle tâche que vous faites d’habitude vous-même : vérifier les patchs de certains sous-systèmes, traquer les bogues, écrire la documentation… Laissez les gens s’approprier entièrement une partie du projet car ils se sentiront responsables et ils y mettront autant de soin que vous. Faire le contraire en voulant tout contrôler vous-même est la meilleure façon de vous retrouver seul avec votre logiciel open source.

Aucun projet ne va gagner en taille et en popularité de cette manière.

En 2009, quand Uli Schlachter a envoyé son premier patch à awesome, cela m’a donné plus de travail. J’ai du vérifier son patch, et j’étais déjà bien occupé pour sortir la nouvelle version d’awesome sur mon temps libre en dehors de mon travail ! Le travail d’Uli n’était pas parfait, et j’ai eu à gérer les bogues moi-même. Plus de travail. Alors qu’ai-je fait ? Quelques minutes plus tard, je lui ai répondu en lui envoyant un plan de ce qu’il devait faire et de ce que je pensais de son travail.

En retour, Uli envoya d’autres patchs et améliora le projet. Savez-vous ce que fait Uli aujourd’hui ? Il est responsable du gestionnaire des fenêtres awesome à ma place depuis 2010. J’ai réussi à transmettre ma vision, déléguer, puis à quitter le projet en le laissant dans de bonnes mains !

9. Ignorer certains types de contributions

Les gens contribuent de différentes manières, et pas toujours en codant. Il y a beaucoup de choses autour d’un projet de logiciel libre : la documentation, le tri de bogues, le support, la gestion de l’expérience utilisateur, la communication, les traductions…

Par exemple, il a fallu du temps pour que Debian songe à donner le statut de Développeur Debian à leurs traducteurs. OpenStack prend la même direction en essayant de reconnaître les contributions autres que techniques.

Dès lors que votre projet commence à récompenser certaines personnes et à créer différents statuts dans la communauté, vous devez faire très attention à n’oublier personne, car c’est le meilleur moyen de perdre des contributeurs en chemin.

10. Oublier d’être reconnaissant

Cette liste est le fruit de nombreuses années de bidouillages open source et de contributions à des logiciels libres. L’expérience et le ressenti de chacun sont différents, et les mauvaises pratiques peuvent prendre différentes formes : si vous connaissez ou si vous avez vous-même rencontré d’autres obstacles dans vos contributions à des projets open-source, n’hésitez pas à compléter la liste dans les commentaires. C’est une forme de contribution.