1

Un étudiant nous propose un appareil photo libre en impression 3D pour 25 €

Léo Marius vient à peine de sortir diplômé de l’École supérieure d’art et design de Saint Etienne. Son projet de recherche consistait à créer de toutes pièces (l’expression est bien trouvée) rien moins qu’un appareil photo en impression 3D !

Nom de code du projet : O3DPC (Open 3D Printed Camera). Nom de code de l’appareil : OR-01 (OpenReflex 01).

Le plus simple est encore d’illustrer tout de suite cela par une image explicite.

OpenReflex - Léo Marius

Il ne s’agit donc pas de photo numérique mais argentique, avec de vieilles pellicules dedans, et il reste le coût (non négligeable) des objectifs. Il n’empêche que le résultat est saisissant, fonctionnel et surtout mis à disposition de tous grâce au choix du Libre.

Nous avons évidemment eu envie d’en savoir plus en interviewant ci-dessous ce jeune créateur.

On voit ici, une nouvelle fois, combien le Libre peut être utile en situation d’étude et d’apprentissage. Combiné avec une accessibilité croissante des nouvelles technologies, il permet à tout un chacun, ayant un peu d’imagination, de réaliser puis partager des choses formidables.

On voit également se dessiner une nouvelle génération de makers/hackers, qui n’a pas eu à batailler (comme nous) pour faire connaître et exister le Libre, et qui l’adopte presque naturellement. Une génération qui donne, somme toute, espoir et confiance en l’avenir 😉

OpenReflex - Léo Marius

Entretien avec Léo Marius

Léo Marius, bonjour, peux-tu te présenter succinctement ?

Je suis un jeune designer tout juste diplômé de l’École supérieure d’art et design de Saint Etienne. Passionné par les nouvelles technologies et en particulier l’impression 3D dans laquelle je vois des opportunités de créations incroyables souvent sous-exploitées (je milite contre les têtes de Yoda et les coques pour smartphone imprimés !).

Libriste et actif dans le milieu associatif depuis quelques années. J’apprécie beaucoup la photographie mais je ne suis pas moi-même photographe.

Qu’est-ce donc que le projet O3DPC ? Comment est-il né ? Et en quoi est-il relié à tes études ?

Le projet O3DPC (pour Open 3D Printed Camera) est un travail de recherche que j’ai mené en rapprochant l’impression 3D libre et la photographie, il rassemble plusieurs projets sur lesquels j’ai travaillé, dont plusieurs sténopés et dernièrement le reflex imprimé.

J’ai mené ce travail en tant que projet personnel tout au long de mes études en design, c’était l’occasion pour moi de rapprocher deux domaines qui m’intéressent : l’impression 3D et la photographie.

OpenReflex - Léo MariusDe ce projet est donc sorti le prototype OR-01, quelles sont ces principales caractéristiques ? ces atouts ? ces améliorations futures (j’ai cru lire un projet avec la carte Arduino) ?

C’est un reflex argentique classique avec une visée directe (on peut voir directement ce que l’ont vise sur le petit rectangle dessus et un obturateur manuel qui fonctionne à environ 1/60° de seconde).

Son atout principal c’est que l’ensemble de ses sources sont libres, et donc adaptable, il est ainsi facile de le modifier pour l’adapter si certaines choses fonctionnement mal ou si on souhaite l’adapter pour des usages particuliers.

Dans sa forme actuelle je retiendrai deux éléments particulièrement intéressants :

  • En premier la bague d’adaptation pour les optiques est démontable, on peut donc facilement s’imprimer des baïonnettes différentes pour s’adapter a plusieurs types d’objectifs sans avoir à changer de boîtier.
  • Il y a également le dos autonome et démontable que j’apprécie, la partie où l’on met sa pellicule. Lorsque j’utilise le mien j’ai deux dos prêts avec deux pellicules différentes et je peux les changer rapidement pour m’adapter à la luminosité (ou switcher entre une pellicule noir et blanc et couleur, tout cela en plein milieu du rouleau d’une pellicule)

Le choix de l’open source, c’est un choix pragmatique, éthique ou les deux mon général ? Je lis (avec joie) une licence CC by-sa pour tes pièces, pourquoi n’as-tu pas retenu la clause non commerciale NC ?

Un peu des deux. À mon arrivée à l’école, j’ai intégré l’association Le_Garage (dont j’ai été président pendant deux ans) qui fait de la sensibilisation dans l’école aux questions du libre en art et design. Ça a donc été assez naturel pour moi de redistribuer ce travail sous licence libre.

L’idée principale derrière l’OR-01 c’est la réappropriation et la compréhension des nos appareils quotidiens, fermer les sources aurait interdit et contredit cet objectif

Pour ce qui est des la clause NC je préfère ne pas l’utiliser car je la trouve trop floue et contraignante dans la pratique. Si on souhaite qu’un projet se diffuse il ne faut pas lui mettre des bâtons dans les roues. Je n’ai aucune raison de m opposer à ce que quelqu’un souhaite se rapproprier le projet, l’améliorer et le vendre, s’il a lui même fourni un travail et qu’il respecte les conditions de redistribution de la licence copyleft.

Quelle imprimante 3D utilises-tu ? La « full libre » RepRap ou la « moins libre » MakerBot[1] ?

J’ai commencé le projet O3DPC il y a un peu plus de trois ans avec une Makerbot de 1ere génération (la numéro 660 ! une pièce de collection) que nous avions acquis avec notre association libriste et qui était encore libre à l’époque. Le reflex a été réalisé avec une Makerbot de dernière génération, la Replicator 2X qui a été achetée par notre école en complément d’une imprimante 3D haut de gamme que nous avions déjà.

L’utilisation de la Makerbot est un moindre mal, les technologies utilisées sont les même que sur les RepRaps traditionnels et les pièces qu’il est possible d’imprimer avec une Makerbot le seront aussi sur une RepRap bien calibrée. Je souhaitais, pour aider à sa diffusion, que le boîtier soit imprimable sur une imprimante de type RepRap. Si j’avais pu choisir je pense que j’aurais opté pour une Lulzbot. 😉

OpenReflex - Léo Marius

Au niveau logiciel, quels sont ceux que tu utilises et pourquoi ? Sont-ils tous libres ?

J’ai essentiellement utilisé Blender, c’est un logiciel que je connais bien et que je trouve extrêmement polyvalent et flexible. Les formes produites avec ce logiciel sont souvent très souples, et on déplace avec aisance les points pour adapter nos formes et nos courbes. Souvent en design on nous fait utiliser l’application propriétaire Rhino qui est beaucoup plus stricte dans son utilisation (« un tout petit peu plus haut » sur Blender correspond à un « Z+0,23mm » sur un Rhino mais il faut alors redessiner toute sa courbe avant de refaire sa révolution). Avec Blender on peut se permettre des approximations, ce qui est bien pratique dans une démarche de recherche.

J’ai également utilisé le libre OpenScad pour certaines pièces qui nécessitaient des formes et des distances très précises. Le fait de pouvoir coder ses pièces s’est avéré très utile. La pièce ne correspond pas ? Il suffit de changer quelques lignes de code pour tout modifier ! L’ensemble est libre 😉

Ce qui était particulièrement pratique c’est que, n’ayant pas d’ordinateur portable performant, je me déplaçais avec mon disque dur et les versions mobiles de toutes mes application pour les principaux OS dessus et je pouvais alors travailler où je le souhaitais.

Tu déposes les fichiers numériques de tes pièces sur Thingiverse et Instructables. Aujourd’hui quand on est développeur et qu’on cherche du boulot, on peut mettre dans son CV ses contributions sur GitHub. Penses-tu qu’il en ira de même demain dans le design sur ce type de dépôts ?

Oui, et de plus en plus. Je prends par exemple le designer Samuel Bernier qui a diffusé une partie de son travail en libre sur Instructables et que j’ai interogé pour mon mémoire (sur les Designers/Makers). Lorsque je lui ai demandé ce que lui avait apporté le libre, il m’a répondu : « des contacts et beaucoup d’opportunités ».

J’ai d’ailleurs mis récemment une note sur mon compte Instructables précisant que je cherchais un emploi, et j’ai reçu une proposition assez intéressante la semaine dernière (rien de défini, mais on verra). Ça fonctionne. Et si cela n’aboutit pas je peux me dire que 95% de mes employeurs potentiels auront vu mon projet de diplôme avant que je les contacte, ce qui est pas mal déjà comme entrée en matière.

25 euros en pièces détachées pour une appareil photo, c’est possible ? Et si oui, ne crains-tu pas pas qu’une société s’en empare et commercialise ton projet sans toi puisque c’est open source (question troll-piège :)) ?

Comme je l’ai mentionné plus haut, tant qu’ils respectent la clause de redistribution à l’identique (SA), cela me va. Je pourrais ainsi à mon tour récupérer leurs sources (que j’espère améliorées) pour mes propres boîtiers 😉

OpenReflex - Léo Marius

Éprouves-tu une certaine « nostalgie » de la photo argentique ?

Pas vraiment de la nostalgie, mais c’est une sensibilité différente à l’image que l’on ne retrouve pas avec le numérique : l’attente et l’incertitude de la photo, le coût aussi qui limite l’utilisation abusive. On réfléchit avant d’appuyer sur le bouton, on n’en prend pas cinquante à la volée comme cela se fait trop souvent.

Je me souviens du temps où les objectifs étaient obligatoirement reliés à une marque (ceux pour Canon, Nikon, etc.). Avec ton OR-01 et sa bague adaptable, tu donnes en quelque sorte de l’interopérabilité aux appareils photos, non ?

Oui, toujours dans l’idée de se rapproprier la technologies. Si l’appareil avait été dépendant d’un type d’objectifs, cela n’aurait pas fonctionné.

Techniquement, comment réussis-tu avec des pièces à monter à rendre l’appareil totalement opaque ?

Le tout est imprimé avec du plastique opaque et, en mettant des rebords et des emboîtements bien placés, l’étanchéité se fait sans trop de difficultés. Pour certaines zones, un peu plus sensibles, j’ai ajouté de la patafix noire pour combler les trous potentiels.

Toutes les parties étant autonomes c’est surtout le dos dans lequel se trouve la pellicule qu’il faut rendre étanche à la lumière, on peut se permettre des petits jours dans les autres. Ça reste un appareil DIY. 🙂

Un petit mot sur Framasoft que tu sembles connaître ?

Merci ! Continuez ce que vous faites. Le libre l’emportera ! 😉

Un appel à lancer ? Une actualité à annoncer ?

Peut être une nouvelle version plus aboutie de l’OpenReflex qui devrait être disponible en financement participatif en septembre ou octobre (selon mes engagements professionnels). N’hésitez pas à suivre mon blog ou à me poster un message sur le dépôt Instructables pour être tenus au courant.

Et sinon, permettez-moi un petit clin d’oeil hommage à Gilles Roussi, le professeur à l’origine de l’association Le_Garage qui nous lira surement 😉

OpenReflex - Léo Marius

Photo ci-dessous réalisée avec l’OR-01




Framanews : libérez vos flux ! (RIP Google Reader)

Framanews - Copie d'écran

Le 1er juillet prochain (J-4, donc !), Google Reader fermera ses portes.

Lancé en 2005, ce service permettait aux utilisateurs d’organiser et de lire des flux d’actualités (appelés « flux RSS ») issus de multiples sites en un seul endroit.

Plusieurs dizaines (centaines ?) de milliers d’utilisateurs se retrouvent donc « victimes » de cette fermeture annoncée il y a trois mois. Cela nous amène à nous poser deux questions :

  • Quelle confiance accorder à Google[1], qui centralise vos données en ligne ?
  • Quelle réponse le monde du logiciel libre a-t-il à proposer aux utilisateurs « mis à la porte » par Google Reader ?

De nombreuses applications libres permettant de lire des flux RSS ont vu leur développement s’accélérer ces derniers mois. Certaines nous ont semblé être d’excellentes alternatives à Google Reader. Mais comment les faire connaitre au grand public ? Comment inciter les utilisateurs a tester et valider une solution libre, plutôt que de foncer tête baissée dans la gueule grande ouverte d’un autre service privé ? Feedly, Digg, Yahoo!, et même … AOL (!) sont sur les rangs pour exploiter vos données sous forme de publicité classique ou de revente à des tiers. Pour au final fermer le service dans quelques mois ?

À sa modeste échelle, Framasoft annonce donc la mise en place de Framanews, un service de lecture de flux RSS basé sur le logiciel libre Tiny Tiny RSS. Il ne s’agit pas ici d’en faire un « concurrent » de Google Reader, qui ne résoudrait pas la question de la centralisation des données, mais bien de proposer à tout un chacun de pouvoir évaluer une alternative libre et gratuite, sans publicité, sans exploitation de vos données personnelles et que vous pouvez vous-même installer (pour une académie, un centre de recherche, etc.).

Notez bien que le projet est en bêta, que les inscriptions s’ouvrent peu à peu (afin de nous permettre de dimensionner l’infrastructure technique), et que nous prévoyons d’améliorer la documentation sur l’installation[2].

Pour vous faire patienter, nous vous proposons ici une interview de Luc, le sympathique et dynamique bénévole[3] qui est en charge de la mise en place de ce service.

Google Reader

Bonjour Luc, peux-tu te présenter ?

Bonjour. Mmh, c’est toujours dur de se présenter, mais je vais tenter quand même. Je suis un geek libriste de pas loin de 30 ans, grand fan des manchots, du Dr Who, de livres (romans, bds), du nombre 42 et des vannes pourries. On me connaît parfois sous le pseudo Sky sur le grand Ternet mais c’est plutôt rare (en dehors de LinuxFr ou de framalang, je ne sors pas beaucoup de mon lecteur de flux RSS)

Mon parcours fut assez mouvementé : 2 facs, 3 DUT, 1 Licence, clerc d’huissier, assistant de sénateur et maintenant administrateur systèmes et réseaux dans l’équipe Lothaire de l’Université de Lorraine… C’est moi qui ai appris à Jean-Claude Van Damme à faire le grand écart 🙂

Mon premier contact (sans le savoir) avec les logiciels libres date de l’époque où Free envoyait un cd contenant divers logiciels dont un truc qui s’appelait “Suite Mozilla” si je me souviens bien. Quand est sortie la première version de Firefox, j’y ai tout de suite adhéré, mais je n’étais pas encore prêt. C’est en 2005 qu’un ami d’enfance m’a dit « Essaye Linux, c’est vachement bien ! », ce qui m’a poussé à acheter un magazine contenant un cd d’installation d’OpenSuse. Là-dessus mon ami m’a dit « Pff, mais prends donc une Debian, ça déchire[4] ! ». Et là c’était fini, j’étais pris au piège et je n’ai plus quitté Debian, ni tout ce qui a rapport au libre. 3 ans plus tard, j’entrais en DUT d’info. Encore 5 ans de plus et j’organisais les Journées Perl 2013 (qui ont eu lieu à Nancy les 14 et 15 juin dernier).

Je fais actuellement partie de Lorraine Data Network, FAI associatif issu de l’essaimage de FDN qui milite pour un Internet Libre Décentralisé et Neutre en encourageant les gens à héberger eux-même leurs services, ou tout du moins à le faire chez des personnes de confiance… un peu comme quand Framasoft propose Framadate, Framapad, Framacalc et tous les autres Framaservices, non ? 😉

Tu t’es proposé pour mettre en place et animer le projet Framanews. Mais qu’est-ce donc que Framanews ?

Framanews est un lecteur de flux RSS en ligne. Un flux RSS est un fichier contenant les articles du site du flux dans un format normalisé qui permet d’afficher ces articles dans un lecteur, sans tout l’« emballage » du site. Cela permet de suivre l’actualité du site en question, sans y aller, ou parfois d’avoir juste un résumé des articles, ce qui permet de choisir si ça vaut le coup d’aller faire un tour sur le site. Si un certain nombre de médias du Web parlent de la fin du flux RSS car dépassé par Twitter, Google+ et consorts, je trouve qu’au contraire, c’est un excellent moyen de choisir ses sources d’informations plutôt que se laisser enfermer dans un bulle constituée de « on sait mieux que toi ce qu’il te faut ». Je ne suis certainement pas le seul à penser ainsi, vu le tollé qu’a soulevé l’annonce de la fermeture de Google Reader et le nombre de lecteurs de flux libres qu’on a vu (re)surgir ça et là : Kriss Feed, Miniflux, Leed, etc. Et surtout Tiny Tiny RSS (ttrss pour les intimes) qui a vu son développement repartir de plus belle et qui sert de base à Framanews.

J’ai légèrement forké Tiny Tiny Rss pour le franciser au maximum (mais il y a encore des bouts de texte qui m’ont échappé), certains textes comme les emails ne passant pas par le module d’internationalisation.

Mais Framanews, c’est aussi un projet « éducatif », pour (re)faire découvrir les flux RSS et présenter une alternative aux sites propriévateurs (merge de propriétaire et privateur, pour dérouter les trolls) comme (bientôt feu) Google Reader, Feedly et consorts. Le pourquoi du flux RSS, les spécificités de ttrss (interface mobile, partage de flux…), un mode d’emploi, tout ça est expliqué sur la page d’accueil du projet (surtout dans la FAQ).

Pourquoi avoir choisi ce projet-là, dans tous les framacartons[5] possibles ?

Parce que j’aime les flux RSS et que je suis un peu opportuniste : je me suis dit que la fermeture de GReader était une bonne occasion de prêcher la bonne parole du Libre. Aussi parce que je connais plutôt pas mal ttrss pour l’avoir installé pendant longtemps sur mon serveur. Je me sers de Framanews maintenant, pour voir les problèmes tout de suite et être encore plus motivé à les résoudre : vos problèmes sont aussi mes problèmes, soyez sûrs que je m’en occupe 😉

Ah ! Non ! C’est un peu court jeune homme !
On pouvait dire… oh ! Dieu ! … bien des choses en somme…
En variant le ton, —par exemple, tenez :
Agressif : « moi, monsieur, si j’avais un tel etherpad,
Il faudrait sur le champ que je le mette à jour[6] ! »
Amical : « mais il n’y a pas de css framasoft :
laissez-moi donc vous faire un boilerplate ! »

Et puis, il faut bien commencer quelque part 😀

Techniquement, la mise en place a été plutôt difficile, peux-tu nous en dire plus sur les coulisses de ce projet ?

Oulà ! Alors, en ce moment, le ttrss tourne sur un des serveurs de Framasoft qui héberge d’autres services, avec la base de données sur un autre serveur, qui sert aussi à faire tourner le script de mise à jour des flux. Je n’avais au départ que le serveur Framasoft pour jouer. J’ai utilisé une base MySQL puisqu’elle était déjà installée dessus, mais avec l’ouverture progressive de la bêta, j’ai vu que ça n’allait plus du tout. Le serveur souffrait de surcharge, et pourtant c’est une bête de course. J’ai donc tuné la base MySQL, mais les problèmes sont revenus quelques jours après. J’ai ensuite tenté quelques essais infructueux de conversion des données MySQL au format PostgreSQL pour une migration en douceur, mais j’ai dû me résoudre à demander à nos courageux testeurs de migrer eux-mêmes leurs comptes, à coup d’export des flux et des préférences. Après quelques jours de répit, de divers essais de réglage des paramètres du script de mise à jours, le serveur était de nouveau en surcharge. C’est Nassim Kacha – un ami lui aussi sysadmin qui s’occupe de pas mal de base de données au boulot – qui m’a montré que la surcharge était due à des accès disques trop lents. Framasoft m’a donc fourni un nouveau jouet : un vps (Serveur Privé Virtuel) avec un disque en SSD. Tout allait bien jusqu’à ce que certains utilisateurs abusent un peu du nombre de flux : plus de 5% du total de flux pour UN utilisateur (représentant 0,5% du nombre d’utilisateurs)…

Dallas, à côté de la saga Framanews, c’est Martine à la plage !

Donc, pour l’instant, le service reste en “beta” ? Quelles sont les limitations ?

Malheureusement, oui. Suite au dernier épisode (trop de flux pour certains utilisateurs), nous avons décidé de limiter le nombre de flux par personnes (je suis en train d’écrire un système de quota de flux pour ttrss). Le système de cache de ttrss a été un peu modifié pour garder le cache plus longtemps (ce qui réduit la vitesse de mise à jour) et on ouvre les inscriptions au compte-goutte, pour nous permettre d’augmenter les capacités de la plateforme au fur et à mesure. Je n’ai pas envie que tout s’écroule de nouveau ! Une fois que j’aurais dimensionné correctement les besoins (un serveur = xxx utilisateurs), je vais tenter de transformer notre petite base de données en un cluster PostgreSQL, on repart pour des tests et on pourra enfin ouvrir les vannes en grand ! (ou pas)

Ceci dit, tant qu’on est en beta, je ne m’interdis pas de loucher vers d’autres applications de lecture de flux RSS en ligne qui pourraient mieux tenir la charge.

Si tout se passe bien au niveau technique, la prochaine limitation risque d’être le nombre de serveurs que Framasoft pourra louer. Rappelons-le, Framasoft est une association qui ne vit que par les dons de ses sympathisants. C’est pourquoi je vous invite à faire un petit tour sur http://soutenir.framasoft.org (je l’avais dit que j’étais opportuniste ! Hop, pub :D).

Au bout du compte, pourquoi utiliser Framanews plutôt que Feedly, Netvibes ou autre ?

C’te bonne blague ! Parce que c’est libre, tiens !

Mais aussi parce que Framasoft — et donc par définition Framanews aussi — cherche à libérer les internautes, en leur faisant découvrir des services qu’ils peuvent installer eux-mêmes, dans leur placard, sur leur serveur dédié, chez un hébergeur mutualisé associatif, sur un raspberry collé au dos de leur chat… De plus, nous respectons votre vie privée : la seule information dont on se sert, c’est votre adresse mail pour vous tenir au courant des évolutions du services et autres maintenances, et juste pour ça. Je pourrais aussi parler de la qualité de ttrss, de sa fonctionnalité qui permet de partager les articles que l’on aime sur un flux public[7], du superbe plugin que j’ai développé de mes blanches mains pour faciliter la navigation dans les flux (ok, c’est juste un fork d’un autre plugin)…

Je pense que la meilleure raison d’adopter Framanews, c’est de l’essayer et de comparer 🙂

Comment vois-tu l’avenir de ce projet ?

Moi et les autres membres de Framasoft sur une plage de sable blanc avec suffisamment d’argent pour racheter Google. Ah c’est pas payant ? Zut alors !

Je verrais bien un espace de partage des flux publics[8] des framanewseurs, un compteur des instances de ttrss que les gens auront montées parce qu’on leur en a donné envie…

Un petit mot pour la fin ?

Internet n’est pas compliqué, Internet est ce que vous en faites.


Rappel des principaux liens :

Crédit photo : Danny Sullivan (Creative Commons By)

Notes

[1] ou tout autre intermédiaire, Framasoft compris.

[2] Les utilisateurs sous Windows souhaitant tester le logiciel en standalone (sur leur poste de travail plutôt qu’en ligne) peuvent même télécharger notre WebApp TT-RSS, mise à jour pour l’occasion.

[3] S’il avait su dans quoi il mettait les doigts, il ne serait peut-être pas venu, d’ailleurs…

[4] Et c’est bien vrai !

[5] Les Framacartons ?! http://lite.framapad.org/p/framatools

[6] Oui, la mise à jour sur le champ a pris du retard à cause de Framanews, je sais, je sais.

[7] Twitter, c’est tellement 2012 !

[8] un flux public Framanews a une URL unique et tarabiscotée. Il faut que la personne vous la communique, sinon vous ne la trouverez jamais ! Par bonheur, les raccourcisseurs d’URLs existent, ce qui donne par exemple pour mon flux public : http://fiat-tux.fr/sh/LucPublRSS




Framasoft rembobine, bientôt l’avance rapide

C’est la semaine FramAccueil. Une semaine où, chaque jour, on vous présentera un peu plus les coulisses de notre nouvelle page d’accueil. Car revenir sur cette présentation de toute la galaxie Framasoft, c’est surtout revenir sur plus de 10 ans d’aventures clavistes et AFK, de sites et outils web, de travail collaboratif au service du Libre au sens large. Avec la nouvelle page d’accueil de Framasoft, toute la galaxie Frama est accessible en quelques roulements de molette.

Cette semaine est l’occasion pour nous de mieux communiquer sur l’ensemble des services proposés, grâce à vos dons, à vos apports, à notre travail commun. De faire le point sur le présent avant de mieux se tourner vers l’avenir.

Nous avons donc demandé à Christophe, le président de l’association, de répondre à quelques questions pour faire l’historique de l’association et de ses projets…

— Pouhiou

Framablog : Christophe, quand on entre dans l’association Framasoft, il y a toujours quelqu’un pour dire : « Tu vas voir : avant de connaitre tous les projets qui existent et de comprendre tout ce qui s’est fait, t’en as au moins pour un an. » Tu confirmes ?

Après un an et demi de présidence, j’en suis encore là. À ma décharge, je précise que certains framasoftiens sont beaucoup plus anciens que moi dans l’asso… Ce que d’aucuns pourraient voir comme une pléthore d’activités est en réalité le reflet du foisonnement Framasoftien. Au fil des rencontres, Alexis a su tisser des liens plus ou moins solides avec d’autres acteurs du Libre, et il a su aussi attirer des volontaires qui ont collaboré activement à certains projets plus que d’autres, ou ont pris en charge un projet en particulier, et se sont ainsi intégrés petit à petit dans le cercle associatif.

Une expression qui est longtemps restée pour décrire Framasoft était : « un réseau à géométrie variable ». C’était et c’est toujours plus ou moins le cas : qu’on adhère ou non aux valeurs de Framasoft, qu’on soit un acteur du libre, un ardent défenseur ou parfaitement ignorant de la différence entre Gnome et KDE ou entre les licences GNU GPL et BSD, il est toujours possible de participer à l’un des projets de Framasoft.

Les années aidant, nous devons aux donateurs comme à la bonne santé des projets une certaine stabilité dans nos objectifs, et c’est tout un projet de structurer Framasoft autour de projets phares… avec tout ce que cela comporte comme risques, puisque un projet mis en valeur peut très bien s’avérer complètement inutile face à l’avancement inexorable du Libre dans bien des domaines.

L’idée est donc désormais de structurer les activités autour de trois grands piliers d’une éducation populaire au Libre : le logiciel, la culture et les services.

Framablog : Pour savoir comment nous en sommes arrivés là, partons du début. Ca veut dire quoi Framasoft ? Il paraît qu’au départ, c’est une bande de potes ?

Si on comprend tous que le « soft » fait référence aux logiciels, il est plus difficile de savoir d’où vient la racine « Frama » que l’on retrouve en préfixe à tous les projets. Framasoft était au départ un petit catalogue en ligne qui était hébergé comme une rubrique du site Framanet (pour FRAnçais et MAthématiques en IntraNET), co-animé par Alexis Kaufmann et Caroline d’Atabekian(1), tous deux enseignants du secondaire. Fin 2001, Framasoft est devenu un site à part entière, axé sur les logiciels libres et proposant un annuaire collaboratif. Depuis lors, l’annuaire a toujours été une activité centrale de Framasoft, mais il était devenu de plus en plus évident que le Libre ne se résume pas à des logiciels(2).

Quand, en 2004, l’association (loi 1901) fut créée, il y avait déjà beaucoup de contributeurs. L’annuaire dépassait déjà largement les seuls logiciels libres disponibles sous Windows, mais concernait les trois grands systèmes d’exploitation du marché. Pour structurer la communauté ainsi formée et permettre davantage de dialogue non seulement entre contributeurs mais aussi avec le grand public découvrant le libre, le forum Framagora fut créé et nombreux sont ceux qui, tout comme moi, ont découvert et intégré Framasoft grâce à ce forum. Et c’est « seulement » en 2005 que le projet d’un DVD-Rom compilation de logiciels libre (aujourd’hui FramaDVD) et le projet Framakey sont nés.

Le premier reprenant l’idée de The Open CD a été créé par un groupe d’étudiants, encadrés par Pierre-Yves (alias Pyg) et le second que le même Pierre-Yves menait. Ceci amorça la dynamique que nous connaissons aujourd’hui, qui se caractérise par plusieurs projets avec des communautés autour. Celles-ci s’entrecroisent, et grâce à elles, c’est aux frontières des projets que l’innovation se fait.

Dans le slogan « la route est longue mais la voie est libre », je n’ai jamais vu cette longueur comme le chemin de croix harassant vers la libération quasi-théologique de l’informatique, mais au contraire comme une suite infinie de choix possibles vers une ligne d’horizon.

Framablog : Et des projets avortés, ou qui sont tombés en désuétude… genre le « cimetière Framasoft »… il y en a ?

Je ne veux pas éluder la question, mais regarder en arrière n’est jamais quelque chose de productif. Nous sommes des bénévoles et, à ce titre, si nous donnons du temps à Framasoft, ce n’est pas pour être nostalgiques. À vrai dire, des projets avortés, il y en a tous les jours : tout ce que nous aimerions faire et ce que nous n’avons pas le temps ni les moyens (humains surtout) de réaliser. Il arrive très souvent que nous dépensions beaucoup d’énergie pour rien.

Malgré l’enthousiasme de la communauté, le projet Framavion n’a jamais vraiment décollé.

C’est le lot de n’importe quel projet associatif et communautaire. Par exemple, nous aimerions développer davantage le projet Framaphonie, les services Cloud que nous proposons peuvent toujours être améliorés, et notre annuaire…. là je ne dis rien pour l’instant parce qu’il se trouve que nous avons la solution !

Framablog : Du coup, aujourd’hui, quels sont les projets qui enthousiasment le plus la communauté ?

Là encore il est difficile d’établir une hiérarchie. Certains projets ne nécessitent pas forcément une grande communauté et sont pourtant très célèbres, comme Framadate. Donc il faut décrire les choses non en termes de productivité mais en termes de rapport entre le nombre de contributeurs et la dynamique journalière (le nombre d’actions par contributeur). De ce point de vue, le groupe Framalang qui s’occupe de traduire des textes, le plus souvent anglophones, est de loin celui qui a une activité très soutenue… et comme il utilise Framapad pour travailler, et le Framablog pour produire des textes à destination du public, on voit ici nettement les interactions entre les projets.

Le projet Framabook aussi connaît de l’activité ces temps derniers. C’est invisible pour le public, mais la production d’un livre représente beaucoup d’heures de la part des membres, en particulier la relecture d’un ouvrage. Donc ici, ce n’est pas en termes de dynamique qu’il faut envisager les choses mais en termes d’heures travaillées. Tout comme le Framablog, qui exige une veille soutenue de l’ensemble de la sphère du Libre, ou le développement de la Framakey qui mobilise de temps à autre Pierre-Yves durant de longues heures pour l’adapter à un projet de partenariat.

Framablog : Est-ce qu’on peut dire un mot sur les FramaTrucs de demain ?

C’est bien simple : nous en avons plein les cartons. Mais ce qui est certain, c’est que le déballage ne peut se faire qu’à partir du moment où nous aurons structuré… allez je lâche le nom de code : Framalibre !

Quelques logos à l’étude pour les projets à venir

(1) Caroline d’Atabekian ne tardera pas à fonder le plus important portail collaboratif des enseignants de Lettres, le WebLettres, dont la naissance est évoquée dans ce billet .

(2) L’ouvrage Histoires et Cultures du Libre (Coll. Framabook, 2013) se veut être une illustration de l’immensité des domaines concernés par le Libre.

* * *

Crédit photo : Musée de l’air et de l’espace de San Diego




Le projet, c’est d’abord des personnes (Libres conseils 34/42)

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

Traduction Framalang : Ouve, Julius22, Sphinx, fubik, peupleLà, goofy, KoS, merlin8282, Munrek, Asta, Jej, Alpha, lamessen

L’important, c’est les gens

Nóirín Plunkett

Nóirín Plunkett est une touche-à-tout qui maîtrise plusieurs domaines. Rédactrice technique le jour, son travail open source illustre l’expression « Si vous voulez que quelque chose soit fait, demandez à une personne occupée ». Nóirín a commencé dans l’open source avec Apache, donnant un coup de main sur la documentation du projet httpd. En moins d’un an, elle a été recrutée dans l’équipe de planification des conférences, qu’elle dirige désormais. Elle a participé à la mise en place du projet de développement communautaire chez Apache et a déjà agi en tant qu’administratrice d’organisation pour le Summer of Code. Elle siège aux conseils d’administration de la fondation du logiciel Apache et de l’Initiative Open Cloud. Quand elle n’est pas en ligne, elle est dans son élément naturel sur une piste de danse. Mais c’est également une harpiste et chanteuse talentueuse et une excellente sous-chef (NdT : en français dans le texte).

Rien ne vaut une voie classique, bien que la mienne le soit peut-être moins que la plupart des autres. J’ai fait ma première contribution quand j’avais la vingtaine. À cette époque, j’avais déjà travaillé plus d’un an chez Microsoft. Mais après Microsoft, j’ai déménagé à l’étranger afin de poursuivre mes études. C’était sympathique d’avoir un divertissement, j’ai donc commencé à travailler sur différentes documentations et traductions et j’ai contribué au projet httpd d’Apache.

Comme par hasard, bien sûr, la conférence européenne sur Apache allait avoir lieu à Dublin, alors que, cet été-là, j’étudiais à Munich. Mais la chance sourit aux Irlandais et, avec un peu d’astuce, j’ai convaincu Sun Microsystems de financer ma participation à la conférence.

J’ai une photo du moment où j’ai pris conscience que cette chose appelée open source était bien réelle, et que ça allait changer le monde. C’était pendant la soirée avant la conférence. Nous n’avions toujours pas trouvé où la fibre se terminait, elle était censée constituer la colonne vertébrale de notre réseau. Nous avions vérifié chaque coin, chaque armoire et chaque plinthe, en vain. Nous avions laissé tomber pour cette nuit, et nous étions occupés à nous assurer que les salles qui accueilleraient les sessions de formation auraient au moins suffisamment de connectivité pour que les formateurs puissent utiliser leurs supports de présentation (1).

Et à mesure que la nuit tombait, que les routeurs révélaient lentement les secrets de leurs configurations par défaut, la demi-douzaine de volontaires, des gens que je n’avais rencontrés que dans l’après-midi même, devenaient des amis.

Je ne pourrais pas vous dire où sont les six filles avec lesquelles j’ai vécu pendant cet été-là à Munich. Mais je suis toujours en contact avec chacune des personnes que vous voyez sur cette photo. L’une d’elles a déménagé dans un autre pays, une autre est partie sur un autre continent. La plupart ont changé de travail entre-temps, j’ai eu mon diplôme et je me suis conformée à la grande tradition irlandaise de l’émigration pour trouver du travail.

Vous voyez, l’open source, c’est d’abord des gens. Vraiment, sur presque n’importe quel projet dont vous voudriez faire partie, le code ne vient qu’après.

Ce qui fait que travailler sur un projet est un bonheur et non une plaie, ce sont les gens. Ce qui fait qu’un projet prospère plutôt qu’il ne stagne, ce sont les gens. Bien entendu, vous serez capable de coder toute la nuit pour un projet si ça permet de résoudre un problème que vous pensez être important ; mais, à moins d’avoir des gens avec lesquels vous pouvez collaborer, discuter, concevoir et développer, vous allez probablement finir par perdre la motivation ou vous retrouver bloqué pour un bout de temps.

Les conférences, les sprints, les hackathons, les « retraites » (NdT : une ou plusieurs journées qui se concentrent sur la création de code de très bonne qualité plutôt qu’écrit dans l’urgence) ou tout ce que votre communauté appelle ses « moments de face à face », voilà leur vraie valeur : permettre de se retrouver face à face avec les gens avec lesquels vous avez travaillé. Les êtres humains sont des animaux sociaux ; les bébés reconnaissent des visages avant même de commencer à gazouiller, et peu importe à quel point les gens sont polis ou amicaux dans leurs courriels, il y a toujours quelque chose qui manque dans ces communications-là.

Rencontrer des gens en face à face nous donne une occasion de voir l’humanité de ceux avec qui on a pu avoir du mal à s’entendre, de partager la joie du travail bien fait avec ceux avec qui on aime travailler. Ainsi, si j’avais un conseil à donner à ceux qui commencent, et j’aurais aimé qu’on me le donne, ça serait de sortir, de rencontrer des gens, de coller des noms aux visages dès que l’opportunité se présente (2).

Et si vous trouvez que les occasions sont rares et trop espacées, n’hésitez pas à demander. Cherchez des gens qui voyagent près de chez vous ou qui vivent là où vous voyagez, dénichez un parrainage pour assister aux grands événements de la communauté, organisez votre propre événement !

C’est la richesse de nos communautés qui donne toute sa valeur à l’open source, ainsi que les efforts partagés vers des objectifs communs. Et, bien sûr, les sessions musique, les repas, les pintes et les soirées ! Ce sont les choses qui nous rassemblent, et vous allez découvrir qu’une fois que vous avez rencontré les gens en personne, même vos interactions par courriel seront plus riches, plus gratifiantes et plus fructueuses qu’elles ne l’étaient auparavant.

——————————————————————

Notes de l’auteur :

(1) Le lendemain matin, nous sommes allés dans les combles pour essayer de trouver la fibre, toujours rien. Pour finir, nous l’avons trouvée dans le local technique de la boîte de nuit, située dans le sous-sol à côté.

(2) Malheureusement, je dis ça comme une mise en garde : comme dans tout rassemblement important, assister à une conférence open source présente des risques. Certains pires que d’autres, mais d’après mon expérience, les agressions, particulièrement, semblent plus fréquentes dans les communautés techniques que dans les communautés non-techniques. Dénichez les événements qui publient un code de conduite ou une politique anti-harcèlement et demandez de l’aide si vous ne vous sentez pas en sécurité. La grande majorité des gens que vous trouverez dans un événement open source sont des êtres humains formidables et attentionnés. J’espère qu’avec le temps, changer les attitudes empêchera la minorité de penser qu’elle peut se permettre des comportements déraisonnables dans ce genre de lieux…




S’intégrer au projet par l’action, sans attendre (Libres Conseils 31/42)

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

Traduction Framalang : merlin8282, goofy, Corentin, lerouge, Asta, peupleLà, Alpha, lamessen, Julius22

Trouver ses marques dans une équipe de promotion

Stuart Jarvis

Stuart Jarvis a commencé à travailler avec l’équipe de promotion de KDE en 2008 en écrivant des articles pour le site web d’actualités de KDE. Il a appris à la dure comment faire bouger les choses dans une communauté du logiciel libre et participe davantage aux activités de l’équipe de promotion en écrivant les annonces des nouvelles versions de KDE et en rédigeant des articles sur les logiciels KDE dans la presse Linux. Il siège maintenant dans le groupe de travail marketing de KDE, contribue à définir la ligne de conduite pour la promotion de KDE et les activités marketing et aide les nouveaux contributeurs à trouver leurs marques. Il fait maintenant aussi partie de l’équipe éditoriale de KDE.News, là où il a commencé à participer.

« C’est celui qui code qui décide » est le mantra du développement dans le logiciel libre. Mais que faire quand il n’y a pas de code ?

Rejoindre l’équipe de promotion et de marketing de votre projet de logiciel libre préféré représente un défi particulier. Pour les nouveaux codeurs, la plupart des projets ont des systèmes de révision du code, des mainteneurs et des pré-versions du logiciel qui les aident à mettre en évidence les erreurs dans le code, ce qui rend moins effrayante la contribution à leur premier correctif.

La promotion peut nécessiter que votre travail soit visible par le public, après une relecture minimale, parfois immédiatement. La nature non-hiérarchisée des communautés de logiciel libre implique qu’il y a rarement une unique personne vers qui vous pouvez vous tourner et qui pourra vous dire si vos idées sont bonnes et prendre des responsabilités à votre place.

Obtenir un consensus versus obtenir des résultats

J’ai d’abord commencé à contribuer à KDE en écrivant des articles pour le site d’actus officiel, KDE.News. J’avais déjà écrit pour des organes de presse, mais j’avais toujours affaire à une personne bien identifiée à qui j’envoyais un brouillon pour avoir un retour et faire les corrections demandées. Dans l’équipe de promotion de KDE, il n’y avait pas une seule personne ou un seul groupe de personnes pour assumer cette tâche. Je devais essayer, juger aux réponses que j’avais sur les brouillons d’articles et décider si j’avais tous les retours dont j’avais besoin et si l’article était prêt pour une publication.

Avec les conseils de contributeurs plus expérimentés, j’ai finalement appris à proposer quelque chose et à le publier en quelques jours s’il n’y avait pas d’objection majeure. Cette approche peut être utilisée par n’importe quel contributeur d’une équipe de promotion de logiciel libre, qu’il soit nouveau ou ancien.

Tout d’abord, travaillez sur la façon dont vous feriez quelque chose, que ce soit écrire un article, changer le texte d’un site web ou donner une conférence dans votre école locale. Planifiez, écrivez l’article ou le nouveau texte. Envoyez vos idées, pour relecture, sur la liste de diffusion de l’équipe de promotion de votre organisation. Surtout, ne demandez pas aux gens ce qu’ils en pensent — vous pourriez attendre des jours ou des semaines sans obtenir de réponse définitive. Signalez plutôt que vous allez publier ou soumettre votre texte, ou mettre en œuvre votre programme à telle date précise, en attendant les objections d’ici là.

Lorsque vous soumettez une date limite, pensez au temps nécessaire à chaque membre actif de l’équipe pour lire ses messages et évaluer votre proposition. Vingt-quatre heures est un minimum absolu pour un simple oui ou non en réponse à une question fermée. Lorsqu’il s’agit de quelque chose nécessitant une lecture ou une recherche, vous devriez envisager un délai de réponse de plusieurs jours.

Si la date limite que vous fixez ne rencontre pas une forte opposition, vous pouvez avancer. S’il existe de gros problèmes par rapport à votre projet, quelqu’un vous le dira. Les choses se font, en réalité. Vous ne serez pas frustré par un manque de progrès et vous aurez la réputation de mener à bien les tâches.

Finalement, c’est vous qui décidez

Les communautés du logiciel libre peuvent facilement devenir des groupes de discussion. Tout le monde a son opinion. Si vous n’êtes pas prudent, les discussions peuvent s’éterniser, s’évanouir au fur et à mesure que les personnes s’en désintéressent et finir sans conclusion convaincante. Cela peut paraître assez difficile à gérer lorsque vous faites partie de la communauté depuis quelque temps : vous avez l’habitude de prendre vos propres décisions et d’avoir votre propre idée sur ceux dont les avis vous importent. Quand vous débutez, cela peut être très déroutant.

Si vous voulez que votre propre travail aboutisse, vous allez probablement devoir faire des choix entre des points de vue opposés. Vous pouvez mettre un terme au débat en donnant un résumé des points principaux et en donnant votre opinion sur ces points. Essayez de ne pas laisser de questions ouvertes en suspens, à moins que vous ne souhaitiez un débat plus long — donnez simplement vos conclusions et dites ce que vous allez faire. Dès lors que vous êtes correct, les autres personnes respecteront probablement votre avis, même si elles ne sont pas d’accord.

Soyez proactif – n’attendez pas qu’on vous demande

Le premier contact avec l’équipe de promotion que vous voulez rejoindre peut très bien être l’envoi d’un courriel sur leur liste de diffusion leur offrant vos compétences. Je pensais pouvoir énumérer mes points forts et espérer que les gens me suggéreraient des choses à faire. En pratique, ça ne fonctionne pas tout à fait comme ça.

La plupart des communautés manquent de volontaires et ont vraiment besoin de vos compétences. Mais comme elles manquent de volontaires, elles peuvent aussi manquer de temps pour donner de bons conseils et encadrer. Si vous voulez travailler sur une partie spécifique du projet, dites-le. Il est beaucoup plus facile pour quelqu’un du projet de dire simplement « Vas-y ! » plutôt que d’essayer d’arriver avec un projet qui correspond à vos compétences.

Même quand vous avez travaillé sur quelques projets et prouvé vos compétences, il y a peu de chances que vous soyez contacté directement pour une tâche. Ceux qui coordonnent l’équipe marketing ne connaîtront pas votre situation personnelle et peuvent donc être mal à l’aise à l’idée de vous demander quelque chose de particulier sur votre temps libre, gratuitement. Une communauté idéale va poster régulièrement — que ce soit sur une liste de diffusion ou une page web — les tâches que des volontaires peuvent prendre en charge. Si ce n’est pas le cas, trouvez vous-même des choses à faire et prévenez la liste de diffusion que vous êtes en train de les faire. Les gens vont le remarquer et cela augmente les chances que vous soyez directement contacté dans le futur.

Si vous êtes proactif, vous pouvez rapidement vous rendre compte que vous êtes l’une des personnes expérimentées de la communauté vers qui les nouveaux venus se tourneront pour avoir des conseils ou du travail à réaliser. Essayez de vous souvenir comment c’était quand vous avez commencé et faites en sorte de faciliter au maximum leur vie de nouveau contributeur.




Coordonner les flux de contributions (Libres Conseils 30/42)

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

Traduction Framasoft : merlin8282, Sphinx, Julius22, goofy, Corentin, lerouge, Asta, peupleLà, okram, Alpha, lamessen

Au confluent de l’amont et de l’aval

Vincent Untz

Vincent Untz est un activiste passionné du logiciel libre, un amoureux partisan de GNOME, ainsi qu’un élément moteur d’openSUSE. Il a été responsable des versions de GNOME de 2008 à 2011, jusqu’à la sortie de GNOME 3.0 ; il a été directeur exécutif de la fondation GNOME (2006-2010) et il dirige l’équipe GNOME chez openSUSE. Quoi qu’il en soit, il trouve plus simple de se décrire comme un « touche-à-tout » (NdT : en français dans le texte) et il travaille dans divers services (certains diraient au petit bonheur la chance) du bureau pour aider openSUSE à rester extraordinaire. Vincent continue à faire du forcing pour que le français soit la langue officielle de GNOME et espère bien réussir bientôt. Sinon, il aime la crème glacée.

Il y a bien longtemps, dans une chambre, la nuit…

J’étais en train de jeter un dernier coup d’œil sur une liste de bogues pour voir si je n’avais pas oublié de fusionner un correctif. Je m’étais bien assuré d’écrire ce que je pensais être une entrée NOUVEAUTÉS au sujet de la nouvelle version. J’ai entré make distcheck (NdT : commande GNU permettant de créer un paquet et de le tester automatiquement dans un répertoire différent de celui de développement pour démarrer le processus de diffusion) et je regardais la console afficher des centaines de lignes. Une archive avait été créée, et j’ai à nouveau vérifié que l’archive se construisait correctement. J’ai vérifié, encore et encore : j’étais inquiet. D’une certaine manière, je ne faisais pas totalement confiance à la commande make distcheck. Après avoir tout vérifié plusieurs fois, j’ai envoyé l’archive sur le serveur et expédié un courriel d’annonce.

J’avais réussi à le faire : j’avais sorti ma première archive d’un logiciel sur le développement dont j’étais récemment devenu co-responsable. Et j’ai certainement pensé : « Ah, maintenant les utilisateurs vont pouvoir apprécier un bon truc ! ». Mais à peine quelques secondes après le chargement de mon archive, quelques personnes l’ont téléchargée et ont rendu ma version réellement accessible aux utilisateurs.

C’est une chose que je tenais pour acquise, car je pensais que c’était une tâche banale. J’avais tort.

Amont et aval

De nombreuses personnes participent au processus d’acheminement du logiciel. Et cet effort se répartit généralement entre deux groupes de personnes d’égale importance dans la manière dont fonctionne le logiciel libre aujourd’hui.

En amont : c’est le groupe qui crée le logiciel. Il inclut évidemment les programmeurs mais, en fonction du projet, d’autres catégories de contributeurs sont également essentielles : designers, traducteurs, rédacteurs de documentation, testeurs, trieurs de bogues, etc. En général, l’amont se charge seulement de livrer le code source sous forme d’archive.

En aval : c’est le groupe responsable de la distribution du logiciel aux utilisateurs. Tout comme en amont, les contributeurs ont une gamme de profils très variée et travaillent à la traduction, la documentation, les tests, le triage de bogues, etc. Il y a cependant un profil qui, jusqu’à présent, est spécifique au travail en aval : le packager, qui prépare le logiciel afin de le rendre disponible sous forme de paquet, un format mieux adapté à un usage facile que le seul code source.

Chose intéressante, les utilisateurs ont plutôt bien l’intuition de cette séparation également, bien que nous n’en soyons pas conscients : nous supposons souvent que les développeurs de logiciels sont inaccessibles et nous envoyons plutôt nos retours et demandes d’aide aux distributeurs.

Pour éclairer cette séparation entre amont et aval, une analogie parlante et classique est celle du circuit des biens de consommation, avec les magasins de détail (« l’aval ») qui distribuent des produits manufacturés (« l’amont ») et jouent un rôle important pour les clients (« les utilisateurs »).

Un regard plus attentif sur l’aval

Si je devais résumer le rôle de l’aval en une phrase, voici comment je le décrirais :

L’aval est le pont entre les utilisateurs et l’amont.

Lorsque j’ai sorti ma première archive en amont, je supposais que, pour l’aval, le travail consisterait principalement à compiler la source pour construire un paquet avec, et rien d’autre. Construire un paquet est effectivement la première étape. Mais c’est seulement le début du voyage vers l’aval : différentes tâches viennent ensuite. Certaines sont purement techniques tandis que d’autres sont sociales. Je vais me contenter de décrire très brièvement ce voyage ici, de manière non-exhaustive, puisque ça pourrait faire l’objet d’un chapitre entier de ce livre (1).

La construction du paquet proprement dit peut se révéler moins triviale que prévu. Il n’est pas rare qu’un packager rencontre des problèmes qui étaient inconnus de l’amont. Comme lorsqu’une nouvelle version du compilateur est utilisée (avec de nouvelles erreurs), qu’une bibliothèque spécifique a d’abord besoin d’être mise à jour (parce que l’archive utilise de nouvelles interfaces de programmation) ou bien que le système de compilation de l’archive est conçu pour une certaine façon de fonctionner (qui ne suit pas les directives de la distribution cible). Ce qui est encore plus méconnu par beaucoup est le fait que tous ces problèmes peuvent également se produire après que l’archive a déjà été empaquetée, comme lors de la migration d’une distribution entière vers un nouveau compilateur ou bien une nouvelle chaîne de compilation. Aucun de ces problèmes techniques n’est vraiment compliqué à résoudre en lui-même, et l’amont est souvent content de contribuer à la solution. Mais sans l’aval, ces problèmes pourraient ne pas être remarqués par l’amont avant un long moment.

Ce qui selon moi est plus important que ces défis techniques, c’est que l’aval est généralement en contact avec davantage d’utilisateurs que l’amont. Cela se traduit par des rapports de bogue, des demandes de support, des requêtes de changement de la configuration par défaut ou bien d’autres choses encore. C’est là que la foule en aval donne la mesure éclatante de sa force : au lieu de simplement transférer ça en amont, l’aval va travailler sur les retours des utilisateurs afin de ne renvoyer que des synthèses qui seront utilisables en amont. Bien souvent, les rapports de bogue sont soumis avec trop peu d’informations sur le problème (auquel cas l’aval demandera plus de détails). Souvent, les demandes de support sont issues d’une incompréhension du côté de l’utilisateur (ce que l’aval peut, parfois, traduire par une suggestion visant à modifier le programme afin d’éviter cette incompréhension). Souvent, de nouveaux paramètres par défaut sont suggérés sans réflexion suffisante (l’aval travaillant alors avec les utilisateurs pour voir si le raisonnement est valide). À partir de cette énorme quantité de données, l’aval produira un ensemble d’informations plus compact que l’amont sera en mesure de digérer facilement. Ce qui amènera à des améliorations sur le logiciel.

Il existe généralement deux récompenses pour les contributeurs en aval : les contributions directes et indirectes vers le projet en amont grâce aux efforts effectués par l’aval sont suffisantes pour beaucoup. Mais plus important encore, le contact direct avec davantage d’utilisateurs amène à recueillir la satisfaction qu’ils expriment. Et une situation aussi gratifiante rend facilement heureux beaucoup de gens.

Une petite note au passage : lorsqu’on considère la quantité de travail fournie en aval, je ne serais pas surpris qu’au bout du compte, beaucoup de contributeurs en amont soient bien contents d’avoir des gens agissant comme intermédiaires : cela diminue significativement la quantité de retours tout en améliorant leur qualité (en évitant les commentaires en double, les problèmes non documentés, etc.). Cela permet à ceux qui travaillent en amont de rester focalisés sur le développement lui-même, au lieu de les obliger à soit trier les retours, soit les ignorer.

Rien qu’en regardant mon expérience en amont, je ne compte plus le nombre de correctifs que j’ai reçus de l’aval pour résoudre des problèmes de compilation. Je me rappelle aussi d’innombrables discussions que j’ai eues à propos des bogues qui affectaient le plus les utilisateurs et qui m’ont permis de prioriser mon travail. De fait, depuis que j’ai rejoint les équipes en aval, j’ai commencé à faire remonter des correctifs proches de ceux liés à des problèmes de compilation à l’amont et à discuter avec ma base en aval pour transmettre des retours d’expérience d’utilisateurs. Une telle collaboration amont-aval participe à l’amélioration de la qualité générale de notre écosystème du logiciel libre et je la considère comme essentielle à notre bonne santé.

Remonter de l’aval vers l’amont !

Je crois fermement que, pour qu’un projet réussisse, il faut qu’il y ait une forte collaboration amont-aval. Je doute que beaucoup désapprouvent. Cependant, par « aval », les gens pensent généralement au travail fait dans les distributions. Mais, particulièrement pour les applications, il devient de plus en plus viable de pousser ce travail fait en aval en dehors des distributions et de tirer parti d’un tel mouvement vers l’amont.

Des outils comme l’Open Build Service (NdT : distribution open source dédiée à la compilation de paquets pour diverses distributions GNU/Linux) permettent plus facilement d’avoir des personnes qui compilent et distribuent des paquets d’une application pour plusieurs distributions. Cela présente des avantages à la fois pour les utilisateurs (qui peuvent profiter plus rapidement et plus facilement des mises à jour de leurs applications préférées) et pour l’amont (qui peut aider à construire une relation plus forte avec sa base d’utilisateurs). Le seul défi qu’un tel mouvement représente est le besoin perpétuel d’avoir quelqu’un qui s’occupe de l’empaquetage, mais aussi qui gère des retours plus nombreux des utilisateurs. Dans les faits, il y a toujours besoin de quelqu’un pour faire le travail de l’aval, sauf qu’il serait fait au sein de la branche amont.

Pour moi, cela semble une perspective excitante et j’irais même plus loin en suggérant que nous, la communauté du logiciel libre, devrions migrer lentement le travail d’aval fait sur les distributions vers un travail d’aval fait directement, aussi souvent que possible, en amont. C’est souvent possible, au moins pour les applications. Cela requiert évidemment de penser différemment. Mais ça permettrait de partager un travail qui, actuellement, est le plus souvent dupliqué sur toutes les différentes branches en aval.

Pour ceux qui souhaitent actuellement commencer à contribuer aux applications qu’ils apprécient, ce travail sur les paquets en amont est une toute nouvelle approche qui pourrait vraiment être une réussite !

J’ai essayé, je suis resté. Pourquoi pas vous ?

L’aval a toujours été essentiel à ma vie en tant qu’utilisateur de logiciels libres — après tout, seules quelques personnes installent manuellement leur système à partir de zéro et je n’en fais pas partie. Cependant, c’est aussi devenu un atout pour moi en tant que développeur en amont, étant donné que j’ai commencé à prendre plus de temps pour discuter avec des personnes en aval afin d’obtenir plus de retours sur les bogues, les fonctionnalités, la qualité générale et même les directions futures du logiciel sur lequel je travaillais.

C’est seulement lorsque j’ai commencé à être moi-même en aval que j’ai compris que cette position est en effet privilégiée afin de conseiller en amont, grâce au contact direct avec les utilisateurs et la perspective différente que l’on retient de cette position différente.

Sans l’aval, nous ne serions pas là où nous sommes aujourd’hui. Si vous souhaitez avoir un impact significatif, soyez persuadé qu’en participant en aval et en discutant avec l’amont, vous réussirez.

Et vous y prendrez du plaisir.

(1) Note de l’auteur : Il est bon de mentionner que je ne crois pas que l’aval devrait modifier significativement le logiciel mis à disposition par l’amont. Certains, en aval, le font tout de même et cela s’ajoute à leur charge de travail.




Passer de l’exercice scolaire à la maintenance des paquets (Libres conseils 28/42)

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

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

Du débutant au professionnel

Jonathan Riddell

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

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

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

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

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

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

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

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

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

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

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

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

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

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




Intégrer un projet en se faisant connaître (Libres conseils 23/42)

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

Traduction Framasoft : Miki, peupleLà, dabou, Astaelquan, Goofy, Julius22, okram, lamessen, Jej, lerouge, SaSha_01, Lycorismeumeul, 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.