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

Traduction Framalang : Ouve, merlin8282, Julius22, fubik, lamessen, okram, goofy, Munrek, Asta, Jej, Alpha

Les projets trop ambitieux échouent

Jos Poortvliet

Jos Poortvliet travaille en tant que gestionnaire de communauté pour SUSE Linux. Auparavant, il était actif dans la communauté KDE internationale en tant que responsable de l’équipe marketing. Dans sa « vie hors-ligne », il a travaillé dans différentes entreprises en tant que conseiller en stratégie d’entreprise. Il passe son temps libre à expérimenter dans sa cuisine, où il tente de parvenir à quelque chose de comestible.

« Mieux vaut faire beaucoup de petits pas dans la bonne direction qu’un grand bond en avant pour retomber en arrière. » (Vieux proverbe chinois)

Une idée géniale…

Il était une fois, au sein de l’équipe marketing d’un projet de logiciel libre, quelqu’un qui eut une idée géniale pour faire se développer le projet. Un programme serait mis en place pour permettre à des étudiants en informatique de prendre connaissance du projet et de le rejoindre. Des universités seraient contactées et quelqu’un s’adresserait à elles pour susciter leur intérêt. Des ambassadeurs iraient alors dans ces universités pour y donner des cours et encadrer les premiers pas des étudiants dans le monde du logiciel libre. Une fois qu’ils auraient rejoint le projet en ligne, ils seraient encadrés sur des tâches simples et deviendraient finalement des contributeurs chevronnés ! Les universités adoreraient ce programme, bien sûr, et, avec un peu de chance, commenceraient à participer plus activement, en donnant à leurs étudiants du code à écrire pour le projet et bien plus encore.

… qui n’a pas fonctionné…

J’ai vu l’idée développée dans la fiction ci-dessus sous bien des formes dans de nombreuses communautés et projets. C’est une idée géniale et d’un fort potentiel ! Nous savons tous qu’il faut commencer tôt — nos concurrents du logiciel propriétaire sont très bons pour ça. Nous savons également que nous disposons de suffisamment d’arguments pour convaincre les universités et les étudiants de participer — le logiciel libre et open source représente le futur, il offre de très belles possibilités de développement des compétences. Les compétences en programmation ou en administration sous Linux sont davantage demandées que des développeurs Java ou .NET ou que des administrateurs système Windows. Et surtout : c’est plus amusant. Quoi qu’il en soit, si vous allez dans des universités, vous ne verrez pas beaucoup d’affiches vous invitant à rejoindre des projets de logiciels libres. La plupart des professeurs n’en ont jamais entendu parler. Que s’est-il passé ? Permettez-moi de continuer mon histoire.

… pas à cause d’un manque d’efforts…

L’équipe en a discuté longtemps. D’abord en mettant des idées en commun — de nombreuses idées concernant la concrétisation du concept ont fusé. Le responsable de l’équipe les a rassemblées et mises sur le wiki. Un calendrier a été établi avec des échéances et le responsable a réparti les tâches, pour certaines parties. Certains ont commencé à rédiger des supports de cours, d’autres à lister les références des universités. Ils ont régulièrement demandé des suggestions et des idées sur la liste de diffusion et ont reçu beaucoup de réponses proposant d’autres supports de cours, que le responsable a ajoutés à la liste des choses à rédiger. Tout devait être fait pendant le temps libre des volontaires, mais on pouvait toujours compter sur le responsable pour rappeler les échéances aux volontaires.

Après quelques mois, une structure était visible et de nombreuses pages étaient créées sur le wiki.

Entre-temps, néanmoins, le nombre de personnes impliquées depuis la discussion initiale a diminué, passant de plus de 30 à environ cinq qui faisaient encore mine de travailler. Le responsable a décidé de revoir la feuille de route avec des dates butoirs et, après quelques appels lancés sur la liste de diffusion, 10 nouveaux volontaires s’engagèrent à réaliser diverses tâches. Le rythme s’est à nouveau un peu accéléré. Un certain nombre de choses qui avaient déjà été faites ont dû être mises à jour et il y avait d’autres ajustements à faire. Malheureusement, les choses ont continué à s’aggraver et le nombre de personnes impliquées a continué à diminuer. Des sprints mensuels furent mis en place, et ils ont en effet abouti à terminer davantage de choses. Mais il y avait simplement trop à faire. Au bout d’environ un an, les dernières personnes ont jeté l’éponge. Il n’en reste qu’une page wiki obsolète et quelques ressources dépassées…

… mais parce qu’elle était trop ambitieuse

Alors pourquoi ça n’a pas marché ? L’équipe avait pourtant appliqué les meilleures techniques de gestion de projet qu’il est possible de trouver sur le Web : brainstorming, puis mise en place d’un planning avec un échéancier, des objectifs précis ainsi que des responsabilités. Ils ont fait ce qu’il fallait faire sur un projet bénévole : solliciter les personnes, les impliquer, donner la possibilité à chacun d’exprimer son opinion. Ça aurait dû fonctionner !

Ce ne fut pas le cas pour une raison simple : c’était trop ambitieux. C’est une tendance. Des idées géniales reçoivent beaucoup de commentaires, sont inscrites dans de grands plannings qui se terminent en pages wiki incomplètes amenant à une faible implémentation qui finit par s’évanouir dans le néant.

Les responsables doivent admettre que la manière de travailler d’une équipe dans le domaine du logiciel libre et open source n’est pas la même que dans un environnement structuré et dirigé comme peut l’être une entreprise. Les gens ont tendance à être présents lorsque quelque chose d’excitant se produit, comme lors de la sortie d’une version majeure, puis à disparaître jusqu’au prochain gros événement. La création d’une équipe communautaire ne devrait jamais supposer que les gens resteront pleinement impliqués jusqu’à la fin. Il faut prendre en compte le fait qu’ils seront présents pendant un certain temps, puis s’absenteront durant de plus longues périodes avant de revenir. Les arrivées et les départs font qu’il y a beaucoup d’agitation superflue et que le travail avance lentement. Oui, il est possible de diriger des gens, mais il n’est pas possible de les gérer. Dès que vous apprenez à laisser l’aspect gestion de côté, vous pouvez davantage vous concentrer sur les choses à faire dans les plus brefs délais.

Ainsi, au lieu de prévoir les grandes étapes, trouvez quelque chose de plus modeste qui soit réalisable et utile en soi. Non pas une page wiki avec un planning, mais la première étape de ce que vous voulez accomplir. Et ensuite donnez l’impulsion en faisant les choses. Faites le premier brouillon d’un article. Créez la première version d’un dossier. Copiez-collez à partir de n’importe quoi d’existant ou améliorez quelque chose qui existe déjà. Ensuite, présentez le résultat à l’équipe, aussi brouillon qu’il puisse être, et demandez si quelqu’un souhaite l’améliorer. Faites une petite chose et ça fonctionnera.

Ne planifiez pas, agissez…

Comment alors allez-vous réaliser quelque chose d’aussi énorme qu’un programme de recrutement des étudiants avec le concours des universités ? Ne le faites pas ! Du moins, pas directement. Il faut en discuter avec toute l’équipe et le planifier — ça donnera certainement lieu à une discussion sympathique pouvant durer des semaines. Mais ça ne vous mènera pas loin. Gardez plutôt le plan pour vous-même. Sérieusement.

Je ne suis pas en train de dire qu’il ne faudrait pas en parler — vous le pouvez. Faites part de votre ambitieux projet à tous ceux qui sont intéressés. Et c’est tant mieux s’ils font des propositions. Mais n’en attendez pas trop, ne faites pas de plans au-delà de la première ou des deux premières étapes. Allez plutôt de l’avant, construisez sur ce qui existe déjà. Envoyez le brouillon d’un support de communication fraîchement créé ou amélioré à la liste de diffusion. Demandez à quelqu’un ayant donné un cours sur votre projet de partager son support et améliorez-le un peu. Qui sait, les personnes dont le travail vous sert de base pourraient vous venir en aide ! Les gens avec qui vous avez discuté de votre projet et qui partagent votre vision pourraient également vous aider. De cette façon, vous terminerez souvent quelque chose — un prospectus, un site web amélioré ou une présentation utilisable. Et les gens peuvent, peu à peu, commencer à les utiliser. Des ambassadeurs peuvent se rendre dans leur université et utilisant une des choses que vous avez déjà créées. Pour cela, ils auront certainement besoin de créer des éléments manquants — qui pourront ensuite se retrouver sur le wiki. Et vous progressez.

… et vous aurez votre château en Espagne !

En marketing communautaire, la bonne stratégie ne réside pas dans le wiki. Elle ne dépend pas d’un programme ni d’un planning. Elle n’est pas non plus discutée chaque semaine avec l’équipe complète. Elle fait partie d’une vision qui s’est développée au cours du temps. Elle est portée par quelques personnes-clés qui indiquent le planning à court terme ainsi que les objectifs et elle est partagée par l’équipe. Mais elle n’a pas de date butoir ni de risque d’échouer. Elle est flexible et ne dépend de rien ni de personne en particulier. Et ça restera toujours un château en Espagne…

En conséquence, si vous voulez piloter un effort marketing pour une communauté de logiciel libre, faites en sorte que la vision d’ensemble reste une vision d’ensemble. Ne planifiez pas trop, mais faites en sorte que des choses se réalisent !

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.

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.

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

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

Packager : la voie royale du logiciel libre

Thorn May

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

Introduction

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

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

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

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

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

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

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

L’évolution, du packager au développeur

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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.

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

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

Ce que je suis contente de ne pas avoir su

Alexandra Leisse

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

Introduction

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

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

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

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

Les noms

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

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

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

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

« Projet de grande envergure »

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

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

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

L’œil étranger

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

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

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

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

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

Conclusion

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

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

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

Traduction Framasoft : Miki, Vilnus Atyx, Sphinx, peupleLà, Goofy, tcit, Julius22, Garburst, Cyrille L., lerouge, Lycoris, vvision, lamessen

Comment ne pas lancer une communauté

Robert Kaye

Robert Kaye associe son amour de la musique et de l’open source dans l’encyclopédie de musique ouverte MusicBrainz. Robert a créé et dirige la MetaBrainz Foundation, une organisation à but non-lucratif basée en Californie, dans la continuité d’un travail de longue haleine pour améliorer l’expérience de la musique numérique. Au-delà du hack pour MusicBrainz, Robert recherche des festivals intéressants comme le Burning Man et des projets périphériques tels que bidouiller des robots pour préparer des cocktails. Comme il est invariablement couronné d’une chevelure aux vives couleurs, vous n’aurez aucun mal à le reconnaître dans une foule.

En 1998, je travaillais pour Xing Technology à San Luis Obispo et j’étais à fond sur notre nouveau projet AudioCatalyst. C’était l’un des premiers programmes d’extraction de MP3 intégré utilisant la base de données CDDB. Il s’agit de la base de données de CD qui permet à chaque lecteur de trouver le titre et la composition de tout CD. Si le CD n’est pas enregistré, on peut saisir les données afin que la prochaine personne qui en a besoin puisse s’en servir. J’adorais ce projet collaboratif en ligne et j’y ai enregistré des centaines de CD en quelques années.

Un jour, il nous a été annoncé que CDDB avait été achetée par Escient, une société qui deviendrait GraceNote par la suite. La base de données CDDB avait été privatisée, de sorte que plus personne ne pouvait la télécharger dans son intégralité ! Pour parachever le tout, Escient ne dédommagea aucun des contributeurs pour leurs efforts. En manœuvrant ainsi, ils arnaquaient le grand public. J’étais plutôt furieux de cette décision et je le suis encore aujourd’hui.

Plus tard dans la semaine, lors d’une fête avec des amis, je me plaignais de ce qui était en train de se passer et expliquais à quel point j’étais mécontent. Mon ami Kevin Murphy me dit : « Pourquoi tu ne démarrerais pas ton propre projet open source pour faire concurrence à ces enfoirés ? »

Quelques semaines plus tard, je finissais de travailler pour Xing et j’avais quelques semaines de temps libre avant de commencer chez EMusic. Je décidai d’apprendre le Perl et la programmation web en autodidacte et de démarrer la création de CD Index, un projet sans compatibilité et sans infraction avec CDDB. J’ai bidouillé le projet pendant cette pause mais l’ai rapidement oublié lorsque je suis devenu membre du projet FreeAmp chez EMusic.

C’est alors que Slashdot demanda, en mars 1999, quelle solution open source allait remplacer CDDB. J’ai passé le reste de la journée et la majeure partie de la nuit à finir CD Index et à le déployer. J’ai soumis un billet sur Slashdot parlant de mon projet (1) et il fut mis en ligne rapidement. Comme prévu, des centaines de geeks se manifestèrent en quelques minutes si bien que mon serveur tomba et rendit l’âme.

Les masses de gens qui arrivèrent commencèrent immédiatement à gueuler pour que les choses se fassent. Il n’y avait même pas encore de liste de diffusion ou de logiciel de suivi de problèmes ; ils insistèrent pour en avoir tout de suite. Comme j’étais novice dans l’open source, je ne savais pas vraiment ce qui était nécessaire ou non pour lancer un tel projet, j’ai fait comme les gens le demandaient. Les protestations reprirent de plus belle et davantage de gens encore insistèrent pour que je ferme le service étant donné qu’il n’était pas parfait. Mais même au milieu de ce vaste bazar, nous avons reçu plus de 3 000 soumissions de CD au cours des premières 24 heures.

Une fois que les choses furent calmées, il y avait encore beaucoup de gens qui rouspétaient. Greg Stein déclara qu’il allait écrire une meilleure version immédiatement. Mike Oliphant, l’auteur de Grip, annonça qu’il allait également travailler à une nouvelle version. Alan Cox vint et proclama que les bases de données SQL n’y suffiraient pas et que je devais utiliser DNS pour créer un meilleur service de recherche de CD. — Hein, quoi ? J’étais très mécontent de la communauté qui grandissait autour du billet publié sur Slashdot. Je ne voulais pas d’un lieu où les gens se manquent de respect et où certains se croient permis de gueuler encore plus fort pour obtenir ce qu’ils veulent. Je perdis rapidement tout intérêt pour le projet et CD Index déclina. Les autres projets que des personnes avaient promis de commencer (à l’exception de FreeDB) ne prirent jamais forme.

Alors, quand la bulle du point com a éclaté, j’ai eu besoin de réfléchir à ce que j’allais faire ensuite. Il était clair que mon boulot chez EMusic n’avait rien de sûr ; je continuais à conduire un roadster Honda S2000, ma voiture trophée de l’époque point com. Avec les traites de la voiture qui doublaient mon loyer, je devais décider : soit mener ma propre entreprise et vendre ma voiture de rêve, soit déménager à Bay Area (San Francisco) et travailler sur le rêve de quelqu’un d’autre, si jamais je parvenais à y trouver un travail. Je décidai que le plus intéressant serait de travailler sur une encyclopédie musicale complète construite par les utilisateurs. Je vendis la S2000 et me concentrai pour commencer à travailler sur une nouvelle mouture de CD Index.

Au cours d’une autre soirée, le nom MusicBrainz me vint et j’enregistrai le nom de domaine pendant la fête. Le jour suivant, motivé par le nouveau nom du projet, je commençai à bidouiller sérieusement et, à l’automne 2000, je lançai musicbrainz.org. Lancer n’est pas le bon mot, ici — je mis le site en place et me demandai alors comment éviter une nouvelle communauté de gosses hystériques venant de Slashdot. Je n’importai jamais de données depuis CD Index, ni ne mentionnai MusicBrainz sur les listes de diffusion de CD Index. Je me suis simplement éloigné du projet CD Index ; je ne voulais plus rien avoir à faire avec celui-ci. À la fin, j’ai décidé d’ajouter un simple bouton à la page web de FreeAmp qui mentionnait MusicBrainz.

Et une chose très étonnante s’est produite : des gens sont venus jeter un coup d’œil au projet. C’était seulement quelques personnes au début, mais quand quelqu’un me signalait quelque chose, je commençais une conversation et recueillais autant de retours d’informations que possible. J’améliorais le logiciel grâce à ces retours. J’ai aussi imposé un ton de respect sur les listes de discussion et, à chaque fois que quelqu’un était irrespectueux, j’intervenais et haussais le ton.

Mes efforts concentrèrent le projet vers son amélioration. Je l’ai fait pendant trois ans avant qu’il ne devienne clair que cette approche était efficace. La base de données croissait régulièrement et la qualité des données passa d’exécrable à bonne en quelques années.

Les bénévoles, ça va ça vient, mais je suis la colonne vertébrale du projet, c’est toujours moi qui donne le la et sa direction à l’ensemble. Aujourd’hui, nous avons une association à but non-lucratif avec 3,25 employés dans quatre pays, Google, la BBC et Amazon comme clients et notre bilan financier est bon. Je ne pense pas que cela aurait pu se produire avec la communauté CD Index.

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

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

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

Eugene Trounev

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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