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

Traduction Framalang :Julius22, Sphinx, fubik, peupleLà, okram, goofy, merlin8282, Munrek, Texmix, Asta, Jej, gregseth, lamessen

Qui êtes-vous, qu’avez-vous à vendre et en quoi ça pourrait m’intéresser ?

Sally Khudairi

Active sur le Web depuis 1993, Sally Khudairi est la publicitaire en embuscade derrière certaines des organisations et des standards les plus importants de cette industrie. Ancienne adjointe de Sir Tim Berners-Lee et championne toutes catégories de l’innovation collaborative, elle a aidé au lancement de The Apache Software Foundation en 1999 et en fut la première femme et membre non-technique élue. Sally est vice-présidente du marketing et de la publicité pour The Apache Software Foundation et directrice générale de HALO Worldwide, une société de conseil en communication pour des marques de luxe.

Tout le monde est vendeur. Du PDG à la star des commerciaux, en passant par le gars qui répartit le courrier, chacun est un représentant de votre entreprise. Les technologies et les stratégies ont changé au fil des années mais une bonne communication reste primordiale. Au bout du compte, tout le monde vend quelque chose, et c’est un équilibre intéressant à trouver dans la publicité ; qui vous êtes, ce que vous faites et ce que vous vendez sont souvent étroitement imbriqués. Quand les gens me disent qu’ils ne savent pas qui je suis, je leur demande s’ils ont entendu parler du W3C, d’Apache ou des Creative Commons.

La réponse habituelle est « bien sûr ! », ce qui me confirme que je fais bien mon boulot. Si vous savez qui ils sont et ce qu’ils font, tout va bien. Après tout, c’est le produit qui compte, pas le publicitaire. Je n’ai jamais cherché à être là : me faire les dents dans la communication à la naissance du Web n’était pas facile, mais grâce au ciel j’ai pu observer les autres et esquiver un certain nombre de torpilles. Après une forte montée en puissance et quelques projets très en vue, quel conseil pourrais-je partager avec un chargé de relations publiques en herbe, avec un porte-parole chevronné rompu à la pratique des médias, ou un technologue qui ose enfourcher le cheval ombrageux de la promotion, malgré ses ruades ?

N’oubliez jamais de vous manifester

Quand vous vendez votre histoire à la presse, souvenez-vous que les médias, eux aussi, ont quelque chose à vendre. Bien sûr, au plus haut niveau, le rôle d’un journaliste est de raconter une histoire irrésistible et convaincante — qu’elle soit vraie ou non, que les faits soient exacts ou non —, qu’elle réponde ou non à une éthique, c’est une autre question. Qu’il s’agisse d’attirer le lectorat, de fidéliser les abonnés ou de promouvoir les espaces publicitaires, eux aussi sont en train de vendre quelque chose. Votre boulot, c’est de les aider à faire le leur. À dire vrai, il est possible que certaines personnes n’aient jamais entendu parler de vous, même si vous êtes dans le métier depuis déjà pas mal de temps. Même si ce n’est pas le cas, ils peuvent ne pas savoir exactement qui vous êtes. Soyez clair sur ce que vous avez à offrir. Quelle est l’accroche pour la presse — quelle est la nouvelle ? Assurez-vous qu’elle est vraiment nouvelle. Soyez direct et venez-en rapidement au fait. Vous devez être prêt à répondre aux questions suivantes : « et alors ? », « En quoi ça pourrait m’intéresser ? » et « Qu’est-ce qu’il y a là-dedans pour moi ? ». Cela veut dire que vous devez vous poser des questions sur vous-même et sur votre produit. Les gens achètent des idées, pas des produits. Faire la promotion des avantages de ce que vous lancez vous aidera à améliorer vos chances d’obtenir une couverture médiatique. Faites un pas de côté : qu’êtes-vous vraiment en train de vendre ?

Jamais le vendredi

Le pire des jours pour lancer un nouveau site web, diffuser un communiqué de presse ou informer les médias, c’est le vendredi. La probabilité qu’il se passe quelque chose et que personne ne soit disponible pour gérer les retombées est plus importante que vous ne pouvez l’imaginer. J’en ai eu une cuisante expérience dès le début de ma carrière. J’avais lancé la nouvelle page d’accueil du W3C un vendredi soir puis quitté le bureau et embarqué dans un avion pour Paris. Comme je venais du monde de la publication commerciale sur Internet, utiliser un tag propriétaire ne me posait aucun problème à partir du moment où il faisait le travail. Faire de même sur le site internet d’une organisation vouée à l’interopérabilité, en revanche, n’était pas une bonne idée. En quelques minutes, des douzaines de messages arrivèrent, demandant comment la <balise-aujourd’hui-dépréciée> était arrivée sur notre site. Et non, ça n’était pas <blink>…

N’imaginez jamais que cela n’a aucune importance

La crédibilité est essentielle. Même si vous êtes surchargé de travail, dévoué corps et âme ou partout à la fois, vous ne pouvez pas empêcher l’heure de sonner. Essayez de produire autant que vos capacités vous le permettent et demandez de l’aide si vous le pouvez. Certaines échéances doivent être négociées, et beaucoup d’éditeurs peuvent s’accommoder d’un retard dans le calendrier mais cela n’aura probablement pas (autant) d’importance une fois l’urgence passée si vous n’êtes pas capable de finir le travail. Tout comme pour l’art, le développement de standards et la relecture-correction, le processus peut se poursuivre et recommencer ad nauseam. Tandis que la créativité ne peut pas être gérée par le temps, des dates butoir strictes obligent à tracer une limite à un moment donné. Mais vous devez vous soucier des détails. Arrêtez-vous. Révisez tout et testez tous les liens. Assurez-vous que cela correspond parfaitement à la stratégie de la campagne ou de la marque. Les cycles de répétition font partie des grands principes structurants de la communication et le travail continuera à s’accumuler. Organisez-le et protégez votre réputation.

Allez-y seul

Il est important d’avoir confiance en vos instincts, spécialement lorsque vous sortez des sentiers battus. Aux premiers jours du Web supercool et ultramoderne, tout le monde semblait s’en remettre aux stratégies habituelles des marques/relations publiques/marketing qui consistaient à faire des sites vitrines. Puis tout le monde « suivait le meneur » (le meneur est « le premier à l’avoir fait », dans de nombreux cas). Les tendances sont une chose, les attentes et les besoins de l’industrie en sont une autre : « c’est comme ça que tout le monde fait » ne veut pas dire que c’est bien pour vous, votre projet ou votre communauté. Ma carrière dans la communication a commencé lorsque j’ai renvoyé le sous-traitant que nous avions choisi et tout ramené en interne.

Nous avons été parmi les premières organisations à mettre une adresse URL sur notre plaquette commerciale, et nous avons été les premiers à utiliser une URL comme source d’un communiqué de presse alors que les agences de presse nous disaient que cela n’était pas conforme et contraire aux règles. Faites confiance à vos connaissances. Allez à contre-courant et bousculez les règles de manière responsable. Sachez vous différencier. Il est permis d’être un dissident tant que vous pouvez soutenir vos idées.

Offrez vraiment des perspectives

Bon nombre des technologies dans lesquelles je suis impliquée finissent en produits au bout de trois à cinq ans. Ceci signifie que, dans bien des cas, il est difficile d’établir une quelconque relation à un produit comparable. Il est crucial que vous expliquiez clairement votre position en utilisant le moins de jargon possible. La plupart des journalistes et analystes non-développeurs avec lesquels je suis en contact ne suivent pas les activités d’une certaine communauté au quotidien et ne savent pourquoi telle fonctionnalité est meilleure qu’une autre, même si c’est une évidence pour vous.

Dire qu’on va « privilégier la forme plutôt que le fond » est plus pertinent aujourd’hui que jamais. Forme. Fond. Je marque toujours une séparation à ce sujet lorsque je fais de la formation aux médias : présentez trop le fond ou trop la forme et votre campagne risque d’échouer. La perception est fondamentale et la cause de bien des conflits. Tout sur la forme = « branché + hyperbole » = « Ah, ces marketeux ! ». Tout sur le fond = « des zéros et des uns » = « Ah, ces geeks ! ».

Il vous faut comprendre et pouvoir expliquer clairement quel est le problème que résout votre produit. En sachant mieux présenter le problème, vous pourrez mieux en expliquer la solution. Les détails accessoires, les anecdotes et les succès, voilà ce qui donne à la presse un moyen d’attirer l’attention de son lectorat. Vous devez savoir répondre à la question « Qu’y a-t-il pour moi là-dedans ? », parce que c’est ce qui incite les journalistes à fouiller un peu plus dans votre histoire, qui, en retour, permet aux lecteurs d’en savoir plus sur vous. La forme répond à la question « Qu’y a-t-il pour moi là-dedans ? », c’est donc l’hameçon. Le fond est le comment on y parvient.

Ayez des porte-parole sur la brèche

Ayez toujours quelqu’un de disponible pour parler à la presse. Oui, ça peut être vous, mais sachez qu’il y aura un moment où, même si vous avez une histoire bien planifiée à raconter, vous pourriez ne pas être disponible. Avec qui d’autre travaillez-vous ? Qui vous connaît ? Qui vous soutient ? Définir ces personnes et distribuer les rôles pour clarifier qui dit quoi contribue beaucoup à diminuer les maux de tête potentiels. J’agis habituellement en tant que porte-parole d’arrière-plan afin de pouvoir passer du temps avec un journaliste pour trouver ce qu’il recherche spécifiquement et comment nous pouvons lui donner les informations pertinentes du mieux possible.

J’explique comment les choses fonctionnent, principalement sur les processus ; cela met mes « vrais » porte-parole en meilleure position pour dire quels sont leurs besoins et minimise le risque de perdre leur participation en chemin. Préparer les bonnes personnes est aussi important que de les rendre disponibles. Pendant mes cours de formation aux médias, je mets quelques diapositives « surprenantes » qui soulignent les leçons particulièrement intéressantes apprises au fil des ans.

Nous avons par exemple connu une pagaille de représentants dans les premiers jours de l’incubateur Apache, où 15 personnes ont répondu à une demande de la presse en 48 heures… beaucoup d’opinions, mais qui était la « bonne » personne à citer ? Ne laissez pas la presse en décider ! Un autre scénario suprenant comprenait une fête de lancement globale avec des centaines d’invités, des représentants de la presse partout, des DJ, de la musique à fond, des cocktails à flot, et tout ça durerait jusqu’à très tard dans la nuit avec des rumeurs de soirées en after.

Très tôt le matin suivant, la presse a débarqué (oui, bien sûr, j’accepte les appels du Financial Times à quatre heures du matin !). J’ai accepté avec excitation. Cependant, il s’avéra que nous n’avions pas de représentant disponible : le président était dans un avion à destination du Japon, le téléphone portable du directeur était éteint (avec une bonne raison, apparemment) ; les membres du conseil d’administration indisponibles, l’équipe non préparée. Des dizaines d’occasions manquées. Rappelez-vous : quand le communiqué de presse est diffusé, le travail commence tout juste.

Ne soyez pas surpris de le voir affluer de partout

Ils ont tous un avis. Et ils vont probablement vous le donner.

Ne compliquez pas les choses à outrance

Si vous pensez que vous avez trop de choses à dire, c’est probablement le cas. Les facultés d’attention ne sont plus ce qu’elles étaient ; la distraction/l’échec est à portée de clic. Rappelez-vous que vous pouvez toujours travailler par étapes. Décomposez votre histoire si nécessaire. Coupez un long communiqué de presse et utilisez des supports documentaires comme des fiches de description technique et des pages de témoignages à la place. Le principe de segmentation (« cinq plus ou moins deux ») est quelque chose que j’utilise encore et encore. Créez votre propre cycle de publication pour vos messages et renforcez régulièrement votre présence. Créez une FAQ ; si une question mérite d’être posée et n’y est pas, trouvez le moyen de compléter votre message. La répétion engendre la familiarité. Le renforcement progressif de votre appel à l’action est une bonne chose.

N’y touchez plus pendant 24 heures

Parfois, vous avez besoin de prendre du champ. Vous éloigner d’un projet, d’un raisonnement, du travail en général. Accordez-vous une pause et essayez de garder un certain rythme. Prenez une journée pour laisser décanter et vous permettre de souffler. Bien que ce ne soit pas possible dans une entreprise gouvernée par les dates butoir, c’est un but à viser. La course effrénée, les courriels incessants et les tweets en continu déclenchent souvent des réactions à des urgences qui n’existent pas. Laissez le projet de côté, videz-vous la tête et revenez avec des idées claires. Faites un pas de côté et reprenez votre vie en main.

Visez haut

Placez haut la barre et soyez conscient de votre valeur.

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

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

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

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

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

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

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

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

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

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

La révolution ne sera pas centralisée

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

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

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

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

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

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

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

La décentralisation comme démocratie

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

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

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

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

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

Faciliter les usages

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

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

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

Éviter de réinventer la roue

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

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

Soutenir un écosystème plus vaste

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

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

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

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

Traduction 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 !

Dans le milieu du design et de la CAO, la part belle est encore trop souvent faite aux logiciels propriétaires.

Mais il n’y pas que 3ds Max & co dans la vie logicielle. On peut faire tout aussi bien, voire mieux, avec le libre Blender et son moteur de rendu Cycles.

C’est que ne nous prouve par l’exemple cet entretien du talentueux ukrainien Igor Shevchenko.

Un salon de beauté conçu et visualisé grâce à Blender et Cycles

Beauty salon designed and visualized with Blender and Cycles

Alexandre Prokoudine – 25 février 2013 – LibreGraphicsWorld.org
(Traduction : Alpha, Max, KoS + anonymes)

Parmi toutes les choses intéressantes qui sont réalisables à l’aide de logiciels libres, ce que LGW aime faire le plus, c’est produire un travail commandé qui soit reconnu. Parlons d’un cas particulier, celui de l’utilisation de Blender et Cycles pour la visualisation d’architectures commerciales.

Je suis récemment tombé sur ce travail sur Behance (NdT : une plateforme de partage de projets de design pour les professionnels) et je n’ai pas pu résister à l’envie de contacter Igor Shevchenko, son auteur.

Igor travaille pour une entreprise ukrainienne appelée « Magis ». Il s’occupe de la modélisation, du texturage et du rendu d’intérieur. « Backstage », le salon de beauté en question, est un véritable établissement qui a ouvert à Kiev en septembre 2012.

Igor, s’agit-il de ton premier projet sérieux réalisé à l’aide de Blender ? Le reste de ton album sur Behance semble porter les étiquettes de 3DS Max, Adobe Photoshop et d’autres logiciels du même genre.

Oui, c’est vrai, c’est le premier vrai projet que l’on m’a commandé et que j’ai réalisé avec Blender. J’étais vraiment curieux de savoir s’il allait être possible de réaliser un tel projet uniquement avec un logiciel libre et de voir les difficultés auxquelles on pouvait s’attendre. Lorsque j’ai commencé à travailler sur le projet, j’ai eu peur que ma connaissance de Blender ne soit pas suffisante pour le mener à bien et de devoir retourner sous 3DS Max. Ça ne s’est pas produit.

Combien de temps cela a-t-il pris ?

Le travail sur le design intérieur a été fait en 3 mois. Mais les rendus du portfolio pour Behance ont été une toute autre affaire. Je suis parti de rien, surtout pour Behance.

Vraiment ?

L’année dernière, en novembre, notre administrateur système m’a demandé de lui envoyer quelques rendus de ce que j’avais fait avec Blender. Il souhaitait les montrer à un ami qu’il tentait de convaincre que Blender était en fait un outil très correct. J’ai donc fouillé parmi mes fichiers et je fus horrifié de constater que je n’avais aucun rendu lissé. J’ai alors décidé de repartir de zéro pour refaire les rendus du projet « Backstage ».

Attends, donc tu n’as pas fait ces visualisations pour le client ?

Le client ne voulait pas des rendus de haute qualité dans un premier temps. Nous avons juste fait le design et décrit le reste avec des mots.

OK, donc de combien de temps as-tu eu besoin pour réaliser la version portfolio du projet ?

Je n’avais aucune date limite, ça ne pressait donc pas, je l’ai fait pendant mon temps libre. Je pense qu’en m’y mettant et en ne faisant rien d’autre, ça m’aurait pris une journée pour faire la modélisation, une autre pour peaufiner les détails et encore une autre pour effectuer le rendu global.

D’où vient ton intérêt pour Blender ?

Il y a environ trois ans, j’ai fini par en avoir marre d’utiliser 3DS Max, j’ai donc commencé à chercher des alternatives. J’ai d’abord essayé Maya et Cinema 4D et j’ai opté pour Maya. Cependant, je me suis rendu compte que soit je n’arrivais pas à trouver le temps pour apprendre à l’utiliser, soit il ne me convenait pas. Peut-être un peu des deux.

J’ai fini par revenir à 3DS Max, faute d’autre chose. Notre administrateur système, qui est un grand adepte du logiciel libre m’a suggéré d’utiliser Blender, mais il s’agissait de la version 2.49 que je n’ai vraiment pas appréciée.

Fin 2011, j’ai lu un article sur « Sintel » le film libre, je l’ai alors regardé. J’ai adoré à la fois l’histoire et les visuels, j’ai donc donné une seconde chance à Blender : j’ai téléchargé une version plus récente et je me suis mis à lire les tutoriels d’Andrew Price, j’ai alors commencé à comprendre comment ce logiciel fonctionnait.

Puis, Cycles est arrivé, et ça a achevé de me convaincre. Mi-2012, j’étais déjà en train de réaliser des petits projets avec Blender, puis « Backstage » est devenu le premier grand projet pour lequel je m’en suis servi. Ça n’a pas été facile, mais je ne suis pas déçu. Avant je considérais que les logiciels libres performants ne pouvaient pas exister. Blender est une exception remarquable dans ce domaine.

L’un dans l’autre, une expérience positive ?

Oui. Mes collègues ont remarqué que je travaillais plus rapidement. Blender a une logique réellement différente, pas comme dans 3DS Max :

• manipulation d’objets,
• personnalisation facile de l’interface,
• approche différente de la modélisation de polygone,
• paramétrage nodal des matériaux,
• traitement « post-processing » intégré,
• modificateurs (il n’y en pas beaucoup, mais ils sont très efficaces pour accélérer le processus de modélisation),
• raccourcis clavier (il y en a beaucoup et ils améliorent grandement mon efficacité).

Blender possède des fonctionnalités sans lesquelles je ne m’imagine pas travailler aujourd’hui. 3DS Max n’en possède pas autant.

Cette liste pourrait s’allonger mais le plus important est que Blender est tout simplement mon type d’application.

Et Cycles ?

Cycles est un formidable moteur de rendu. J’ai récemment implémenté le matériau caoutchouc dans 3DS Max pour les pneus, et c’était vraiment la misère : paramétrage, rendu, paramétrage, rendu ainsi de suite… Dans Cycles, j’ai juste ajusté les paramètres et vu le résultat immédiatement.

Vois-tu une utilité au moteur de rendu interne de Blender dans ton travail quotidien ?

Non, c’est plutôt inutile en ce qui me concerne.

Est-ce que l’aspect libre et gratuit, en plus de la faible taille du fichier à télécharger a joué un rôle ?

Tout à fait. À plusieurs reprises, j’ai eu besoin de télécharger Blender lors d’un rendez-vous avec un client sur son ordinateur (5 minutes), de le lancer (2 secondes) et de travailler sur un projet. Ça fait une grande différence.

Au vu de tout ça, est-ce que l’un de tes collègues a déjà eu envie d’utiliser Blender ?

Non, et je ne m’attends pas à ce qu’ils le fassent. Soyons réalistes, la seule façon pour que cela arrive, c’est de les forcer à l’utiliser, et rien de bon n’en sortira. En réalité, les gens n’ont soit pas le temps, soit pas l’envie d’apprendre de nouvelles choses, et certains ne savent même pas que des alternatives existent.

Quels types de difficultés as-tu rencontrés lorsque tu travaillais avec Blender sur le projet « Backstage » ?

Le principal défaut de Blender est que la phase de développement actif a commencé assez récemment et beaucoup de fonctionnalités de base ne sont pas encore présentes. Il y a aussi les problèmes de compatibilité avec les formats de fichiers : c’est difficile d’ouvrir des fichiers Blender dans AutoCAD et dans 3DS Max, c’est même quasiment impossible.

As-tu rencontré des problèmes purement techniques avec Cycles ? Quelque chose qui manque ?

J’ai un peu de mal à me rappeler ce qui manque. De manière générale, les fonctionnalités compatibles par défaut dans les autres moteurs de rendu. La gestion des fichiers IES (NdT : qui gèrent la répartition de la lumière) en faisait partie il y a peu, mais ça a été résolu.

D’un autre côté, j’ai trouvé des méthodes parfaitement fonctionnelles pour contourner la plupart — sinon toutes — des fonctionnalités manquantes. La seule chose que je n’arrive pas à contourner c’est que Cycles est plutôt inutile sans une carte graphique chère.

Penses-tu que la fréquence des mises à jour de versions interfère avec les méthodes de travail en entreprise ? Les studios seraient plus enclins à n’utiliser que des mises à jour importantes et à ne les mettre à jour que pour corriger les bugs, c’est assez connu.

La fréquence d’apparition des nouvelles versions semble être une des principales particularités des logiciels libres. Je pense qu’en réalité, Blender en tire profit, parce qu’il reste beaucoup de choses à faire.

En plus, Blender a une bonne compatbilité ascendante et, de cette manière, rien n’empêche un studio de se limiter à une version particulière et à l’utiliser pendant quelques années.

La galerie complète du projet « Backstage » est disponible sur Behance.

Sources :

• Apple veut rendre les vidéos réellement incopiables (Numerama)
• Non, The Pirate Bay n’émigre pas en Corée du Nord (Numerama)
• La taxe sur la publicité en ligne de retour dans une loi sur la presse (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

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.