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

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

L’important, c’est les gens

Nóirín Plunkett

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

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

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

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

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

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

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

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

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

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

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

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

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

Notes de l’auteur :

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

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

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.