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.

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.

Comme le soulignait PCInpact récemment Microsoft interdit le transfert de la licence Office 2013 vers un autre PC.

L’arrivée de la nouvelle version de la célèbre suite bureautique s’accompagne en effet d’un contrat de licence encore plus restrictif qu’auparavant, ce qui revient bien moins à acheter un logiciel qu’à le louer sur un seul et unique ordinateur en priant pour que ce dernier n’expire pas tout de suite (malgré son obsolescence programmée, ce qui est un autre sujet).

Du coup, certains utilisateurs, même parmi les plus fidèles, réalisent (enfin) qu’on les prend vraiment pour des vaches à lait et lorgnent (enfin) du côté de GNU/Linux et LibreOffice.

Microsoft perd un fanboy de plus

Microsoft loses yet another fanboy

Jack Wallen – 19 février 2013 – TechRepublic.com
(Traduction : jay91, lukkas35, Goodbox, aKa, nepski, VIGNERON, RavageJo, goguette, Texmix, Kyriog, Penguin, QC, chdorb, Norore, maxlath + anonymes)

Un autre mord la poussière pendant que Microsoft (et son utilisation déplaisante des licences) fait fuir un fan de longue date. Jack Wallen jette un œil à ce qui attend Microsoft.

Non, ce n’est pas quelqu’un de connu. Ce n’est même pas quelqu’un qui soit déjà apparu dans les médias, dans un mème, ou qui aurait participé à un hashtag ou une flashmob. Microsoft a perdu un des fanboys avec lesquels je travaille. Cette personne est un de ces types qui comprennent les choses à plusieurs niveaux. Non seulement il est incroyablement intelligent, mais c’est aussi un brillant électronicien.

Mais lorsque Microsoft a commencé à annoncer leurs termes de licence pour Office 2013 — il a commencé à me poser des questions. Elles commençaient toutes par « Au fait Jack, parle moi de Linux ». Et c’est ce que j’ai fait. Il n’a pas fallu longtemps pour qu’il installe Ubuntu 12.10 à la place de Windows 7 et qu’il soit heureux de travailler, sans Microsoft, et ce sans perdre le rythme.

Vous devez vous demander en quoi exactement les nouveaux termes du contrat de licence d’Office 2013 peuvent faire changer d’avis un fan Microsoft de longue date ? Laissez-moi vous lister les points les plus importants :

• Chaque licence est liée à un compte Microsoft Live (qu’il vous faut posséder) ;
• Seules cinq licences peuvent être liées à un même compte (nous avons des clients qui en passent par une dizaine de versions d’Office par semaine — ça pourrait causer quelques problèmes) ;
• Chaque licence sera définitivement assignée à une seule machine.

Ces points sont seulement les plus néfastes, des points qui vont faire mal aux utilisateurs à différents niveaux. Ces conditions de licence partent du principe que les machines ne tombent jamais en panne – et que si elles le font, les utilisateurs ne verront pas d’inconvénient à sortir à nouveau la liasse de billets pour racheter la licence.

Faux et archi faux.

Les ordinateurs tombent en panne, certains sont parfois d’emblée défectueux avec des défauts qui ne seront parfois visibles qu’après plusieurs jours (ou semaines) d’utilisation. Que vont faire ces utilisateurs là ? Acheter Office 2013 deux fois en l’espace de quelques semaines ?

À cela, Microsoft va répondre, « Vous pouvez souscrire à Office 365 ». À ça, je répondrai d’utiliser gratuitement Google Docs pour n’avoir plus aucun problème.

Au cours de l’année dernière, Microsoft en a fait plus pour pousser les gens vers des solutions alternatives qu’il ne l’avait fait pendant très longtemps. D’abord, il a mis sur le marché l’une des interfaces graphiques les moins intuitives qui soit. Aujourd’hui, c’est la licence de Microsoft Office qui change. En bref, Microsoft est en train de perdre des fans et des utilisateurs. Vers quoi se tournent-t-il ? Linux. De plus en plus de gens se rendent finalement compte qu’il y a une alternative et que cette alternative est en fait MEILLEURE !

« Toutes ces années gâchées. » disais-je, secouant ma tête, tentant de cacher ma joie.

Les entreprises et les consommateurs ont beaucoup dépensé dans les produits Microsoft. Comment sont-ils remerciés de leur fidélité ? Une baffe en plein visage, et un trou dans le porte-monnaie ! Cette pagaille ne va pas bien se finir pour Microsoft. En revanche, cela va dans le bon sens pour les systèmes d’exploitation et logiciels comme Ubuntu et LibreOffice.

Beaucoup d’entre nous ont dit qu’il serait inévitable d’en arriver là. À un moment, on a vu venir le côté binaire — Microsoft allait brûler le seul pont qu’il ne pouvait se permettre de brûler — celui qui se trouvait entre Redmond et ses légions de fanboys. Cela ne se fera sans doute pas en une nuit, mais les aficionados d’une des plus grosses entreprises à avoir jamais honoré les bits et les octets vont lui tourner le dos et chercher de plus (ou)vertes pâtures. Quand cela va se produire, Linux aura enfin ce qui lui est dû. L’effet cascade forcera Microsoft à re-calibrer ses pratiques commerciales dans l’urgence.

Bien sûr, on a déjà entendu cet air-là avant. Microsoft va probablement tenter de mener le combat devant les tribunaux, mais pas là où il devrait : dans les cœurs et les esprits de ses consommateurs.

Crédit photo : Pcs007 (Creative Commons By-Sa)

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

Traduction Framasoft : Miki, peupleLà, dabou, Asta, elquan, Goofy, Julius22, okram, lamessen, Jej, lerouge, SaSha_01, Lycoris, meumeul, vvision

Ne soyez pas timide

Máirín Duffy Strode

Máirín Duffy Strode utilise des logiciels libres et open source depuis le lycée et y contribue depuis huit ans. Elle contribue aux communautés Fedora et GNOME et a travaillé sur l’identité visuelle des interactions, l’image de marque ou l’iconographie de plusieurs applications libres et open source importantes telles que Spacewalk, Anaconda, virt-manager, SELinux et SSSD. Elle s’est également engagée dans des activités de sensibilisation en enseignant les techniques de design à des enfants à l’aide d’outils libres et open source tels que GIMP et Inkscape qu’elle défend ardemment. Elle est à la tête de l’équipe de conception graphique de Fedora et designer d’interaction senior chez Red Hat, Inc.

Je connaissais et utilisais des logiciels libres et open source bien avant de devenir contributrice. Ce n’est pas faute d’avoir essayé — il y a eu quelques faux départs auxquels je n’ai pas donné suite principalement parce que j’étais trop timide et que j’ai eu peur d’aller plus loin. Sur la base de ces tentatives avortées et de ce que m’ont rapporté d’autres designers qui se sont embarqués dans des projets libres et open source, j’ai cinq astuces à vous offrir si vous êtes un designer aspirant au statut de contributeur au logiciel libre et open source.

1. Sachez que l’on a besoin de vous et qu’on vous veut (très fort !)

Mon premier faux départ s’est produit alors que j’étais étudiante en première année d’informatique au Rensselaer Polytechnic Institute. Il y avait un projet particulier que j’utilisais beaucoup et auquel je voulais participer. Je ne connaissais personne au sein du projet (ni qui que ce soit investi dans le logiciel libre). J’ai donc fait une tentative à froid. Le site web du projet signalait que les contributeurs voulaient de l’aide et qu’ils avaient un canal IRC. J’y ai alors traîné pendant une semaine ou deux. Un jour, après une pause dans la conversation, j’ai osé élever la voix. J’ai dit que j’étais une étudiante en informatique intéressée par l’ergonomie et que j’adorerais participer.

On m’a répondu : « Dégage ! ». Qui plus est, on m’a fait comprendre que mon aide n’était ni nécessaire ni désirée.

Cela a retardé mon engagement de quelques années — il avait suffi de quelques mots un peu rudes sur IRC pour me dissuader de réessayer pendant près de cinq ans. Je ne découvris que bien plus tard que la personne qui m’avait plus ou moins expulsée du canal IRC de ce projet était en marge du projet, qu’elle avait un lourd passif de ce genre et que je n’avais vraiment rien fait de mal. Si seulement j’avais persévéré dans mes tentatives d’approche et conversé avec d’autres personnes, j’aurais pu commencer à ce moment-là.

Si vous souhaitez contribuer au logiciel libre et open source, je vous garantis qu’il y a un projet quelque part qui a vraiment besoin de votre aide, en particulier si vous êtes orienté design ! Faites-vous du design web ? De l’iconographie ? De l’ergonomie ? De l’habillage ? Des maquettes d’interface utilisateur ? J’ai parlé à de nombreux développeurs de logiciels libres et open source qui non seulement sont désespérément à la recherche d’aide dans ce domaine, mais qui en plus l’apprécieraient vraiment et vous vénéreraient pour l’avoir apportée.

Si vous rencontrez des résistances la première fois que vous essayez de participer dans un projet, apprenez de mon expérience et n’abandonnez pas tout de suite. Si, en définitive, le projet n’est pas fait pour vous, ne vous inquiétez pas et passez votre chemin. Il y a des chances pour que vous trouviez un projet que vous adorerez et qui vous adorera en retour.

2. Aidez le projet pour qu’il vous aide à aider les autres

Bien des projets libres et open source sont aujourd’hui dominés par les programmeurs et les ingénieurs. Et si certains ont la chance qu’une ou deux personnes créatives s’investissent, dans la plupart des projets, un designer, un artiste ou une autre présence créative représente un rêve souvent-caressé-mais-jamais-réalisé. En d’autres termes, même s’ils comprennent qu’ils ont besoin de vos compétences, ils peuvent ne pas savoir quelle sorte d’aide ils peuvent vous demander, quelle information ils doivent vous donner pour que vous puissiez être productif ni même les bases pour travailler avec vous efficacement.

Quand j’ai commencé à m’investir dans différents projets libres et open source, j’ai rencontré beaucoup de développeurs qui n’avaient jamais travaillé directement avec un designer auparavant. Au début, je me suis sentie un peu inutile. Je ne pouvais pas suivre toutes leurs conversations sur IRC parce qu’ils parlaient de leur cuisine interne et de détails techniques qui ne m’étaient pas familiers. Quand ils se sont donné la peine de me prêter attention, ils m’ont posé des questions comme « Quelle couleur dois-je mettre ici ? » ou « Quelle police dois-je utiliser ?  ». Ce que je voulais vraiment en tant que designer d’interactions, c’était d’être associée à la prise de décision lorsqu’on abordait les contraintes spécifiques du projet. Si un utilisateur voulait une fonctionnalité particulière, je voulais avoir mon mot à dire sur le design — mais je ne savais pas où ni quand ces décisions se prenaient et je me sentais exclue.

Le design couvre une gamme assez large de compétences : l’illustration, la typographie, la conception des interactions, la conception visuelle, la conception d’icônes, la conception graphique, la rédaction, etc. et il y a peu de chances qu’un seul concepteur les possède toutes. Il est alors compréhensible qu’un développeur ne soit pas sûr de ce qu’il peut vous demander. Ce n’est pas qu’ils essaient de vous faire obstacle — c’est seulement qu’ils ne savent pas dans quelle mesure vous avez besoin de vous investir ou le désirez.

Aidez-les à vous aider. Montrez-leur clairement le type de contributions que vous pouvez apporter en fournissant des exemples de contributions antérieures. Faites-leur comprendre vos besoins de sorte qu’ils comprennent mieux comment vous aider à vous engager dans leur projet. Par exemple, lorsque vous vous impliquez pour la première fois dans une initiative spécifique pour le projet, prenez le temps de présenter les grandes lignes de son processus de conception et postez cela dans la liste de développement principale afin que les autres contributeurs puissent vous accompagner. Si vous avez besoin d’idées sur des points particuliers, soulignez-les dans votre présentation. Si vous n’êtes pas certain de la façon dont certaines choses se produisent — comme le processus de développement d’une nouvelle fonctionnalité — entrez en contact avec quelqu’un en parallèle et demandez-lui de vous l’expliquer pas à pas. Si quelqu’un vous demande de faire quelque chose au-delà de vos capacités techniques — travailler sur de la gestion de versions, par exemple — et que vous n’êtes pas à l’aise avec ça, dites-le.

Communiquer sur votre processus et vos besoins vous évitera de jouer aux devinettes dans le projet et ses membres seront au contraire capables d’utiliser au mieux vos talents.

3. Posez des questions, beaucoup de questions ; il n’y a pas de question idiote

Nous avons parfois remarqué chez Fedora que, lorsque de nouveaux designers arrivaient à bord, ils avaient peur de poser des questions techniques, par crainte de paraître stupides.

Ce qu’on ne vous dit pas, c’est que les développeurs peuvent être tellement spécialisés qu’il y a beaucoup de détails techniques qui sortent de leur domaine de compétence et qu’ils ne comprennent pas non plus — cela se produit même au sein du même projet. La différence, c’est qu’ils n’ont pas peur de demander — donc vous ne devriez pas avoir peur non plus ! Dans mon travail de design des interactions, par exemple, j’ai dû contacter de nombreuses personnes du même projet pour comprendre comment un processus se déroulait dans leur logiciel, car ce dernier comportait plusieurs sous-systèmes et tous les participants du projet ne comprenaient pas forcément comment chaque sous-système fonctionnait.

Si vous ne savez pas sur quoi travailler, que vous ne savez pas par quoi commencer ou que vous ne comprenez pas pourquoi ce que quelqu’un a dit sur le chat est si drôle — demandez. Vous avez des chances que quelqu’un vous réponde qu’il ne sait pas non plus et peu de risques de passer pour stupide. Dans la plupart des cas, vous allez apprendre quelque chose de nouveau qui vous aidera à devenir un meilleur contributeur. Il peut être particulièrement efficace de chercher un tuteur — certains projets ont même un programme de tutorat — et de lui demander s’il veut bien être votre référent quand vous avez des questions.

4. Partagez et partagez souvent, même si ce n’est pas encore prêt, surtout si ce n’est pas encore prêt

Nous avons aussi remarqué que de nouveaux designers pour Fedora et d’autres projets libres et open source sont un peu timides lorsqu’il est question de montrer leur travail. Je comprends qu’on ne veuille pas ruiner sa réputation en publiant quelque chose qui n’est pas ce qu’on peut faire de mieux ni même fini ; mais une grande partie du travail sur des projets libres et open source est de partager souvent et ouvertement.

Plus vous aurez avancé sur un élément avant de le partager, plus il sera difficile à d’autres de vous apporter un retour utilisable, de se lancer et de s’investir. Il est aussi plus difficile pour autrui de collaborer à votre travail et d’avoir un sentiment d’appartenance au projet, de le soutenir et de le pousser jusqu’à l’implémentation. Dans certains projets libres et open source, ne pas être communicatif avec vos ébauches, compositions et idées est même considéré comme offensant !

Publiez vos idées, maquettes ou compositions sur le Web plutôt que par courriel, afin qu’il soit plus aisé pour les autres collaborateurs de faire référence à votre contribution en faisant un copier-coller de l’URL — c’est particulièrement pratique au cours d’une discussion. Plus vos éléments de design seront faciles à trouver, plus il est probable qu’ils seront utilisés.

Essayez ce conseil et gardez l’esprit ouvert. Partagez votre travail tôt et souvent. Rendez disponibles vos fichiers sources. Vous serez peut-être agréablement surpris par ce qui va se passer !

5. Soyez aussi visible que possible au sein de la communauté du projet

Un outil qui — de manière totalement involontaire — a fini par m’aider énormément à démarrer en tant que contributeur de logiciels libres et open source a été mon blog. J’avais commencé à entretenir un blog, simplement pour moi, à l’image d’un portfolio grossier des choses sur lesquelles j’avais travaillé par le passé. Mon blog est un énorme atout pour moi, parce que :

• En tant qu’enregistrement de l’historique des décisions de projet, il représente un moyen pratique pour rechercher d’anciennes décisions de design — comprendre pourquoi nous avons décidé de laisser tomber tel ou tel visuel à nouveau ou pourquoi une approche particulière, précédemment essayée, n’a pas fonctionné, par exemple ;
• En tant que dispositif de communication, il aide les autres contributeurs associés à votre projet et même les utilisateurs à être au courant des travaux en cours et des changements à venir pour le projet. De nombreuses fois, j’ai omis quelque chose d’essentiel dans un design et ces personnes ont très rapidement posté un commentaire pour m’en informer !
• Il m’a aidé à construire ma réputation en tant que designer de logiciels libres et open source, ce qui m’a aidé à gagner la confiance des autres envers mes choix de design avec le temps.

Vous bloguez ? Trouvez quels agrégateurs de blogs lisent les membres du projet auquel vous participez et demandez à ce que votre blog y soit ajouté (il y a en général un lien pour cela dans la barre latérale). Par exemple, l’agrégateur de blogs que vous devrez rejoindre pour faire partie de la communauté Fedora se nomme Planet Fedora. Écrivez un premier billet pour vous présenter aux autres et leur faire savoir ce que vous aimez une fois que vous y aurez été ajouté — des informations du genre de celles listées dans la première astuce.

Le projet aura certainement une liste de diffusion ou un forum où les discussions ont lieu. Rejoignez-les et présentez-vous là aussi. Quand vous apportez une contribution au projet — peu importe qu’elle soit petite ou loin d’être aboutie — postez des billets sur ce que vous faites, téléchargez-le vers le wiki du projet, tweetez à ce sujet et envoyez des liens aux membres importants de la communauté via IRC afin d’avoir leur retour.

Rendez votre travail visible et les gens commenceront à vous associer à votre travail et à vous proposer des projets sympas ou d’autres opportunités, simplement grâce à ça. C’est tout ce que j’aurais aimé savoir quand j’ai essayé de m’investir pour la première fois dans le logiciel libre et open source comme designer. Si vous ne deviez retenir qu’un message de tout cela, c’est que vous ne devriez pas être timide — faites-vous entendre haut et fort, faites connaître vos besoins, faites savoir aux autres quels sont vos capacités et ils vous aideront à les utiliser pour que le logiciel libre envoie du lourd.

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

Traduction Framalang : Floxy, ga3lig, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, 4nti7rust, peupleLa, Luc Didry, + Julius22

Même en multipliant les regards, les bogues ne sautent pas aux yeux.

Ara Pulido

Ara Pulido est ingénieure d’essais pour Canonical, d’abord comme membre de l’équipe assurance qualité d’Ubuntu (QA team), et maintenant dans le cadre de l’équipe de certification du matériel. Même si elle a commencé sa carrière en tant que développeuse, elle a vite découvert que ce qu’elle aimait vraiment, c’était tester les logiciels. Elle est très intéressée par les nouvelles techniques d’analyse et tente d’utiliser son savoir-faire pour améliorer Ubuntu.

Les tests maison ne suffisent pas

Je me suis impliquée dans le logiciel libre dès le début de mes études à l’Université de Grenade. Là-bas, avec des amis, nous avons fondé un groupe local d’utilisateurs de Linux et organisé plusieurs actions pour promouvoir le logiciel libre. Mais, depuis que j’ai quitté l’université, et jusqu’à ce que je commence à travailler chez Canonical, ma carrière professionnelle s’est déroulée dans l’industrie du logiciel propriétaire, d’abord comme développeuse puis comme testeuse.

Lorsque l’on travaille au sein d’un projet de logiciel propriétaire, les ressources pour tester sont très limitées. Une petite équipe reprend le travail initié par les développeurs avec les tests unitaires, utilisant leur expérience pour trouver autant de bogues que possible afin de mettre à disposition de l’utilisateur final un produit aussi abouti que possible. Dans le monde du logiciel libre, en revanche, tout est différent.

Lors de mon embauche chez Canonical, hormis la réalisation de mon rêve d’avoir un travail rémunéré au sein d’un projet de logiciel libre, j’ai été émerveillée par les possibilités des activités de test dans le cadre d’un tel projet. Le développement du produit s’effectue de manière ouverte, et les utilisateurs ont accès au logiciel dès son commencement, ils le testent et font des rapports de bogues dès que c’est nécessaire. C’est un nouveau monde rempli de beaucoup de possibilités pour une personne passionnée par les tests. Je voulais en profiter au maximum.

Comme beaucoup de personnes, je pensais que les tests « maison », c’est-à-dire l’utilisation par soi-même du logiciel que l’on envisage de mettre à disposition, était l’activité de test la plus importante qu’on puisse mener dans le logiciel libre. Mais si, selon la formule de Raymond dans La cathédrale et le bazar « avec suffisamment d’observateurs, tous les bogues sautent aux yeux », alors comment se fait-il qu’avec ses millions d’utilisateurs Ubuntu comporte encore des bogues sérieux à chaque nouvelle version ?

La première chose dont je me suis aperçue quand j’ai commencé à travailler chez Canonical c’est que les activités de test organisées étaient rares ou inexistantes. Les seules sessions de test qui étaient d’une certaine façon organisées se présentaient sous la forme de messages électroniques envoyés à une liste de diffusion, manière de battre le rappel pour tester un paquetage dans la version de développement d’Ubuntu. Je ne pense pas que cela puisse être considéré comme une vraie procédure de test, mais simplement comme une autre forme de « test maison ». Cette sorte de test génère beaucoup de doublons, car un bogue facile à débusquer sera documenté par des centaines de personnes. Malheureusement le bogue potentiellement critique, vraiment difficile à trouver, a de bonnes chances de passer inaperçu en raison du bruit créé par les autres bogues, et ce même si quelqu’un l’a documenté.

En progrès

La situation s’améliore-t-elle ? Sommes-nous devenus plus efficaces pour les tests au sein des projets de développement libre ? Oui, j’en suis convaincue.

Pendant les derniers cycles de développement d’Ubuntu, nous avons commencé bon nombre de sessions de test. La gamme des objectifs pour ces sessions est large, elle comprend des domaines comme de nouvelles fonctionnalités de bureau, des tests de régression, des tests de pilotes X.org ou des tests de matériel d’ordinateur portable. Les résultats sont toujours suivis et ils s’avèrent vraiment utiles pour les développeurs, car ils leur permettent de savoir si les nouveautés fonctionnent correctement, au lieu de supposer qu’elles fonctionnent correctement à cause de l’absence de bogues.

En ce qui concerne les outils d’assistance aux tests, beaucoup d’améliorations ont été apportées :

• Apport(1) a contribué à augmenter le niveau de détail des bogues signalés concernant Ubuntu : les rapports de plantage incluent toutes les informations de débogage et leurs doublons sont débusqués puis marqués comme tels ; les utilisateurs peuvent signaler des bogues sur base de symptômes, etc.
• Le Launchpad(2), avec ses connexions en amont, a permis d’avoir une vue complète des bogues – sachant que les bogues qui se produisent dans Ubuntu se situent généralement dans les projets en amont, et permet aux développeurs de savoir si les bogues sont en cours de résolution.
• Firefox, grâce à son programme et à son extension Test Pilot, mène des tests sans qu’on ait à quitter le navigateur(3). C’est, à mon sens, une bien meilleure façon de rallier des testeurs qu’une liste de diffusion ou un canal IRC.
• L’équipe Assurance Qualité d’Ubuntu teste le bureau en mode automatique et rend compte des résultats toutes les semaines(4), ce qui permet aux développeurs de vérifier très rapidement qu’il n’y a pas eu de régression majeure pendant le développement.

Cependant, malgré l’amélioration des tests dans les projets de logiciel libre il reste encore beaucoup à faire.

Pour aller plus loin

Les tests nécessitent une grande expertise, mais sont encore considérés au sein de la communauté du le logiciel libre comme une tâche ne demandant pas beaucoup d’efforts. L’une des raisons pourrait être que la manière dont on les réalise est vraiment dépassée et ne rend pas compte de la complexité croissante du monde du logiciel libre durant la dernière décennie. Comment est-il possible que, malgré la quantité d’innovations amenées par les communautés du logiciel libre, les tests soient encore réalisés comme dans les années 80 ? Il faut nous rendre à l’évidence, les scénarios de tests sont ennuyeux et vite obsolètes. Comment faire grandir une communauté de testeurs supposée trouver des bogues avérés si sa tâche principale est de mettre à jour les scénarios de test ?

Mais comment améliorer la procédure de test ? Bien sûr, nous ne pouvons pas nous débarrasser des scénarios de test, mais nous devons changer la façon dont nous les créons et les mettons à jour. Nos testeurs et nos utilisateurs sont intelligents, alors pourquoi créer des scripts pas-à-pas ? Ils pourraient aisément être remplacés par une procédure de test automatique. Définissons plutôt une liste de tâches que l’on réalise avec l’application, et certaines caractéristiques qu’elle devrait posséder. Par exemple, « l’ordre des raccourcis dans le lanceur doit pouvoir être modifié », ou « le démarrage de LibreOffice est rapide ». Les testeurs trouveront un moyen de le faire, et créeront des scénarios de test en parallèle des leurs.

Mais ce n’est pas suffisant, nous avons besoin de meilleurs outils pour aider les testeurs à savoir ce qu’ils testent, où et comment. Pourquoi ne pas avoir des API (interfaces de programmation) qui permettent aux développeurs d’envoyer des messages aux testeurs à propos des nouvelles fonctionnalités ou des mises à jour qui doivent être testées ? Pourquoi pas une application qui nous indique quelle partie du système doit être testée ? en fonction des tests en cours ? Dans le cas d’Ubuntu, nous avons les informations dans le Launchpad (il nous faudrait aussi des données sur les tests, mais au moins nous avons des données sur les bogues). Si je veux démarrer une session de test d’un composant en particulier j’apprécierais vraiment de savoir quelles zones n’ont pas encore été testées ainsi qu’une liste des cinq bogues comptant le plus de doublons pour cette version en particulier afin d’éviter de les documenter une fois de plus. J’aimerais avoir toutes ces informations sans avoir à quitter le bureau que je suis en train de tester. C’est quelque chose que Firefox a initié avec Test Pilot, bien qu’actuellement l’équipe rassemble principalement les données sur l’activité du navigateur.

La communication entre l’amont et l’aval et vice-versa doit aussi être améliorée. Pendant le développement d’une distribution, un bon nombre des versions amont sont également en cours de développement, et ont déjà une liste des bogues connus. Si je suis un testeur de Firefox sous Ubuntu, j’aimerais avoir une liste des bogues connus aussitôt que le nouveau paquet est poussé dans le dépôt. Cela pourrait se faire à l’aide d’une syntaxe reconnue pour les notes de versions, syntaxe qui pourrait ensuite être facilement analysée. Les rapports de bogue seraient automatiquement remplis et reliés aux bogues amont. Encore une fois, le testeur devrait avoir facilement accès à ces informations, sans quitter son environnement de travail habituel.

Les tests, s’ils étaient réalisés de cette manière, permettraient au testeur de se concentrer sur les choses qui comptent vraiment et font de la procédure de test une activité qualifiée ; se concentrer sur les bogues cachés qui n’ont pas encore été découverts, sur les configurations et environnements spéciaux, sur la création de nouvelles manières de casser le logiciel. Et, in fine, s’amuser en testant.

Récapitulons

Pour ce que j’en ai vu ces trois dernières années, les tests ont beaucoup progressé au sein d’Ubuntu et des autres projets de logiciels libres dans lesquels je suis plus ou moins impliquée, mais ce n’est pas suffisant. Si nous voulons vraiment améliorer la qualité du logiciel libre, nous devons commencer à investir dans les tests et innover dans la manière de les conduire, de la même façon que nous investissons dans le développement. Nous ne pouvons pas tester le logiciel du XXIe siècle avec les techniques du XXe siècle. Nous devons réagir. Qu’il soit open source ne suffit plus à prouver qu’un logiciel libre est de bonne qualité. Le logiciel libre sera bon parce qu’il est open source et de la meilleure qualité que nous puissions offrir.

1 http://wiki.ubuntu.com/Apport

2 http://launchpad.net

3 http://testpilot.mozillalabs.com

4 http://reports.qa.ubuntu.com/reports/desktop-testing/natty

Source : Impression 3D : une Américaine conçoit son propre disque vinyle (Numerama)

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

3. Hors du labo, au grand air

La croissance des communautés open source autour des projets universitaires

par Markus Kroëtzsch

Markus Kroëtzsch est post-doctorant au Département des Sciences Informatiques de l’Université d’Oxford. Il a soutenu son doctorat en 2010 à l’Institut d’Informatique Appliquée et Méthodes Formelles de description du Karlsruhe Institute of Technology. Ses recherches portent sur le traitement automatique de l’information, depuis les fondements de la représentation de la connaissance formelle jusqu’à leurs domaines d’application, tel le Web Sémantique. Il est le développeur principal de la plate-forme Semantic MediaWiki, application de Web sémantique, co-éditeur des spécifications W3C OWL2, administrateur principal du portail communautaire semanticweb.org, et co-auteur de l’ouvrage Foundations of Semantic Web Technologies. 

Au sein des universités, les chercheurs développent de grandes quantités de logiciels, que ce soit pour valider une hypothèse, pour illustrer une nouvelle approche, ou tout simplement comme outil en appui à une étude. Dans la plupart des cas, un petit prototype dédié fait le travail, et il est déployé rapidement tandis que l’enjeu de la recherche évolue. Cependant, de temps à autres, une nouvelle approche ou une technologie émergente a le potentiel de changer complétement la manière de résoudre un problème. Ce faisant, cela génère de la réputation professionnelle, du succès commercial, et la gratification personnelle d’amener une nouvelle idée à son plein potentiel. Le chercheur qui a fait une découverte de ce genre est alors tenté d’aller au-delà du prototype vers un produit qui sera réellement utilisé. Il est alors confronté à une toute nouvelle série de problèmes pratiques.

La peur de l’utilisateur

Dans l’un de ses célèbres essais sur l’ingénierie logicielle, Frederick P. Brooks, Jr. permet de se faire une bonne idée des efforts liés à la maintenance d’un vrai logiciel et nous met en garde contre l’utilisateur :

« Le coût total de la maintenance d’un programme largement utilisé est habituellement de 40% ou plus de son coût de développement. De façon surprenante, ce coût est fortement influencé par le nombre d’utilisateurs. Plus il y a d’utilisateurs, plus il y a de bugs » [1]

Bien que les chiffres soient probablement différents dans le contexte actuel, la remarque reste fondamentalement vraie. Elle pourrait même avoir été confirmée par l’usage généralisé de la communication instantanée. Pire encore : davantage d’utilisateurs ne produit pas seulement davantage de bugs ; en général, ils expriment aussi plus de demandes. Qu’il s’agisse d’une véritable erreur, d’une demande de fonctionnalité, ou tout simplement d’une mauvaise compréhension du fonctionnement du logiciel, les demandes de l’utilisateur lambda ne ressemblent en rien à un rapport de bug précis et technique. Et chaque demande requiert l’attention des développeurs et occupe un temps précieux qui n’est plus disponible pour écrire du code.

Avec son esprit d’analyse, le chercheur anticipe sur ce problème. Dans sa lutte naturelle pour éviter un avenir sombre dans le service client, il peut carrément développer de la peur envers l’utilisateur. Dans le pire des cas, cela peut le mener à prendre des décisions qui vont à l’encontre du projet dans son ensemble ; sous des formes plus légères, cela peut tout de même mener le chercheur à cacher des produits logiciels brillants à ses utilisateurs potentiels. Plus d’une fois, j’ai entendu des chercheurs dire : « Nous n’avons pas besoin de plus de visibilité : nous recevons déjà suffisamment d’emails ! ». Il est vrai que parfois la communication pour un outil logiciel nécessite un effort supérieur à celui que peut fournir un chercheur sans laisser tomber son emploi principal.

Pourtant, cette issue tragique aurait bien souvent pu être évitée. Brooks pouvait difficilement l’anticiper. Quand il a écrit ses essais, le fait est que les utilisateurs étaient des clients et que la maintenance logicielle faisait partie du produit qu’ils achetaient. Il fallait trouver un équilibre entre l’effort de développement, la demande du marché, et le prix. C’est toujours le cas pour de nombreux produits logiciels commerciaux de nos  jours, mais ça a peu de choses à voir avec la réalité du développement à petite échelle de l’open source. Les utilisateurs habituels de l’open source ne paient pas pour le service qu’ils reçoivent. Leur attitude n’est donc pas celle d’un client exigeant, mais bien plus souvent celle d’un partisan enthousiaste et reconnaissant. Transformer cet enthousiasme en un soutien plus que nécessaire n’est pas négligeable pour réussir dans l’art de la maintenance d’un logiciel open source : l’intérêt croissant de l’utilisateur doit aller de pair avec une contribution croissante.

Reconnaitre que les utilisateurs de logiciels open source ne sont pas que « des consommateurs qui ne paient pas » est une notion importante. Mais cela ne doit pas mener à surestimer leur potentiel. Le contre-pied optimiste de la peur irrationnelle de l’utilisateur est la croyance que des communautés actives croissent naturellement avec pour seule base la licence choisie pour publier le code. Cette grave erreur de jugement est bizarrement toujours aussi commune, et a scellé le destin de bien des tentatives de création de communautés ouvertes.

Semer et récolter

Le pluriel d’ « utilisateur » n’est pas « communauté ». Si l’un peut s’accroître en nombre, l’autre ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.

Préparer le support technologique

Créer une communauté commence avant même que le premier utilisateur n’apparaisse. D’emblée, le choix du langage de programmation va déterminer le nombre de personnes qui pourront déployer et déboguer notre code. Objective Caml est sans doute un beau langage, mais si l’on utilise plutôt Java, la quantité d’utilisateurs et de contributeurs potentiels augmentera de plusieurs ordres de grandeur. Les développeurs doivent donc faire des compromis puisque la technologie la plus répandue est rarement la plus performante ou la plus élégante. Cela peut être une démarche particulièrement difficile pour des chercheurs qui privilégient souvent la supériorité formelle du langage. Quand je travaillais sur Semantic MediaWiki, on m’a souvent demandé pourquoi nous utilisions PHP alors que Java côté serveur serait tellement plus propre et performant. Comparons la taille de la communauté de Semantic MediaWiki et les efforts que demanderait le même développement basé sur du Java : voilà peut-être un début de réponse. Cet exemple illustre aussi que l’audience ciblée détermine le meilleur choix de la technologie de base. Le développeur lui-même devrait avoir le recul nécessaire pour prendre la décision la plus opportune.

Préparer minutieusement le terrain

Dans le même ordre d’idées, il faut créer un code lisible et bien documenté dès le début. Dans un environnement universitaire, certains projets logiciels rassemblent de nombreux contributeurs temporaires. Les changements dans les plannings et les projets des étudiants peuvent nuire à la qualité du code. Je me souviens d’un petit projet de logiciel à l’Université technique de Dresde qui avait été très bien maintenu par un assistant étudiant. Après son départ, on a constaté que le code était minutieusement documenté… en turc. Un chercheur ne peut être programmeur qu’à temps partiel, une discipline particulière est donc nécessaire pour mettre en œuvre le travail supplémentaire indispensable à l’élaboration d’un code accessible. En retour il y aura de bien meilleures chances par la suite d’avoir de bons rapports de bogues, des patchs utiles ou même des développeurs extérieurs.

Semer les graines des communautés

Les développeurs open source inexpérimentés considèrent souvent comme un grand moment la publication ouverte de leur code. En réalité, personne d’autre qu’eux ne la remarquera. Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile. Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation d’utilisation basique.

Au cours de sa vie, le projet devrait être mentionné dans tous les endroits adéquats, y compris des sites web — à commencer par votre page d’accueil ! — des conférences, des papiers scientifiques, des discussions en ligne. On ne dira jamais assez le pouvoir du simple lien qui conduira un futur contributeur important sur le site du projet dès sa première visite. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche. Les autres chercheurs sont rarement la meilleure base pour une communauté active.

Fournir des espaces pour grandir

Banal mais souvent négligé, le devoir des personnes qui maintiennent le projet est de fournir des espaces de communication afin que la communauté puisse se développer. Si un projet n’a pas de liste de discussion dédiée, alors toutes les demandes d’aide seront envoyées en message privé à la maintenance. S’il n’y a pas de bugtracker (NdT : logiciel de suivi de problèmes), les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki éditable par tout un chacun pour la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence. Si la version de développement du code source n’est pas accessible, alors les utilisateurs ne seront pas dans la capacité de tester la dernière version avant de se plaindre de problèmes. Si le dépôt de code est intrinsèquement fermé, il n’est alors pas possible d’accueillir des contributeurs externes. Toute cette infrastructure est disponible gratuitement par l’intermédiaire d’un certain nombre de fournisseurs de service. Toutes les formes d’interaction ne sont pas forcément désirées, par exemple, il y a des raisons de garder fermé le cercle des développeurs. Mais il serait inconscient d’espérer le soutien d’une communauté sans même préparer des espaces de base pour celle-ci.

Encourager et contrôler la croissance

Les développeurs inexpérimentés sont souvent préoccupés par le fait que l’ouverture de listes de diffusions, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas, mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre rigoureuse des usages de communication publique. Les utilisateurs ont besoin d’apprendre à poser des questions publiquement, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide du bugtracker plutôt que par e-mail. J’ai tendance à rejeter toutes les demandes d’aide privées, ou à répondre via des listes publiques. Cela garantit au passage que les solutions sont disponibles sur le web pour les futurs utilisateurs qui les chercheront. Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup d’enthousiasme et des gens bien intentionnés pour construire une communauté solide.

Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer d’avantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté. De même, l’enthousiasme le mieux intentionné n’est pas toujours productif et il faut parfois savoir dire non — gentiment mais clairement – pour éviter les dérapages possibles.

Le futur est ouvert

Construire une communauté initiale autour d’un projet contribue fortement à transformer un prototype de recherche en un logiciel open source. Si ça porte ses fruits, il existe de nombreuses options pour le développer en fonction des buts fixés par le mainteneur du projet et la communauté. Voici quelques indications :

Persévérer dans l’expansion du projet et de sa communauté open source, augmenter le nombre de personnes ayant des droits de contributions « directs », en réduisant la dépendance à son origine universitaire. Par ce biais, vous impliquez plus fortement la communauté – notamment au travers d’événements dédiés –;et vous pourrez établir un soutien organisationnel.

Créer une entreprise commerciale pour exploiter le projet, basée, par exemple, sur une double licence ou un business model de consultant. Des outils ayant fait leurs preuves et une communauté active sont des atouts majeurs dès le lancement d’une entreprise, et peuvent être bénéfiques dans chacune de vos stratégies d’entreprise sans abandonner le produit original open source.

Se retirer du projet. Il y a de nombreuses raisons pour qu’on ne puisse plus maintenir de lien avec le projet. Le fait d’avoir établi une communauté saine et ouverte maximise les chances pour que le projet continue de voler de ses propres ailes. Dans tous les cas, il est plus correct de faire une coupure nette que d’abandonner silencieusement le projet, en le tuant par une activité en chute libre au point qu’on ne trouve plus personne pour le maintenir.

Le profil de la communauté sera différent selon qu’on opte pour telle ou telle stratégie de développement. Mais dans tous les cas, le rôle du chercheur évolue en fonction des objectifs du projet. Le scientifique initial et le programmeur pourront prendre le rôle de gestionnaire ou de directeur technique. En ce sens, la différence principale entre un projet de logiciel open source d’importance et la recherche perpétuelle d’un prototype n’est pas tant la quantité de travail mais le type de travail nécessaire pour y arriver. Cela compte pour beaucoup dans sa réussite. Une fois qu’on l’a compris, il ne reste plus qu’à réaliser un super logiciel.

[1] Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on  Software Engineering. Anniversary Edition. Addison-Wesley, 1995.

3. Hors du labo, au grand air

La croissance des communautés open source autour des projets universitaires

par Markus Kroëtzsch

Markus Kroëtzsch est post-doctorant au Département des Sciences Informatiques de l’Université d’Oxford. Il a soutenu son doctorat en 2010 à l’Institut d’Informatique Appliquée et Méthodes Formelles de description du Karlsruhe Institute of Technology. Ses recherches portent sur le traitement automatique de l’information, depuis les fondements de la représentation de la connaissance formelle jusqu’à leurs domaines d’application, tel le Web Sémantique. Il est le développeur principal de la plate-forme Semantic MediaWiki, application de Web sémantique, co-éditeur des spécifications W3C OWL2, administrateur principal du portail communautaire semanticweb.org, et co-auteur de l’ouvrage Foundations of Semantic Web Technologies. 

Au sein des universités, les chercheurs développent de grandes quantités de logiciels, que ce soit pour valider une hypothèse, pour illustrer une nouvelle approche, ou tout simplement comme outil en appui à une étude. Dans la plupart des cas, un petit prototype dédié fait le travail, et il est déployé rapidement tandis que l’enjeu de la recherche évolue. Cependant, de temps à autres, une nouvelle approche ou une technologie émergente a le potentiel de changer complétement la manière de résoudre un problème. Ce faisant, cela génère de la réputation professionnelle, du succès commercial, et la gratification personnelle d’amener une nouvelle idée à son plein potentiel. Le chercheur qui a fait une découverte de ce genre est alors tenté d’aller au-delà du prototype vers un produit qui sera réellement utilisé. Il est alors confronté à une toute nouvelle série de problèmes pratiques.

La peur de l’utilisateur

Dans l’un de ses célèbres essais sur l’ingénierie logicielle, Frederick P. Brooks, Jr. permet de se faire une bonne idée des efforts liés à la maintenance d’un vrai logiciel et nous met en garde contre l’utilisateur :

« Le coût total de la maintenance d’un programme largement utilisé est habituellement de 40% ou plus de son coût de développement. De façon surprenante, ce coût est fortement influencé par le nombre d’utilisateurs. Plus il y a d’utilisateurs, plus il y a de bugs » [1]

Bien que les chiffres soient probablement différents dans le contexte actuel, la remarque reste fondamentalement vraie. Elle pourrait même avoir été confirmée par l’usage généralisé de la communication instantanée. Pire encore : davantage d’utilisateurs ne produit pas seulement davantage de bugs ; en général, ils expriment aussi plus de demandes. Qu’il s’agisse d’une véritable erreur, d’une demande de fonctionnalité, ou tout simplement d’une mauvaise compréhension du fonctionnement du logiciel, les demandes de l’utilisateur lambda ne ressemblent en rien à un rapport de bug précis et technique. Et chaque demande requiert l’attention des développeurs et occupe un temps précieux qui n’est plus disponible pour écrire du code.

Avec son esprit d’analyse, le chercheur anticipe sur ce problème. Dans sa lutte naturelle pour éviter un avenir sombre dans le service client, il peut carrément développer de la peur envers l’utilisateur. Dans le pire des cas, cela peut le mener à prendre des décisions qui vont à l’encontre du projet dans son ensemble ; sous des formes plus légères, cela peut tout de même mener le chercheur à cacher des produits logiciels brillants à ses utilisateurs potentiels. Plus d’une fois, j’ai entendu des chercheurs dire : « Nous n’avons pas besoin de plus de visibilité : nous recevons déjà suffisamment d’emails ! ». Il est vrai que parfois la communication pour un outil logiciel nécessite un effort supérieur à celui que peut fournir un chercheur sans laisser tomber son emploi principal.

Pourtant, cette issue tragique aurait bien souvent pu être évitée. Brooks pouvait difficilement l’anticiper. Quand il a écrit ses essais, le fait est que les utilisateurs étaient des clients et que la maintenance logicielle faisait partie du produit qu’ils achetaient. Il fallait trouver un équilibre entre l’effort de développement, la demande du marché, et le prix. C’est toujours le cas pour de nombreux produits logiciels commerciaux de nos  jours, mais ça a peu de choses à voir avec la réalité du développement à petite échelle de l’open source. Les utilisateurs habituels de l’open source ne paient pas pour le service qu’ils reçoivent. Leur attitude n’est donc pas celle d’un client exigeant, mais bien plus souvent celle d’un partisan enthousiaste et reconnaissant. Transformer cet enthousiasme en un soutien plus que nécessaire n’est pas négligeable pour réussir dans l’art de la maintenance d’un logiciel open source : l’intérêt croissant de l’utilisateur doit aller de pair avec une contribution croissante.

Reconnaitre que les utilisateurs de logiciels open source ne sont pas que « des consommateurs qui ne paient pas » est une notion importante. Mais cela ne doit pas mener à surestimer leur potentiel. Le contre-pied optimiste de la peur irrationnelle de l’utilisateur est la croyance que des communautés actives croissent naturellement avec pour seule base la licence choisie pour publier le code. Cette grave erreur de jugement est bizarrement toujours aussi commune, et a scellé le destin de bien des tentatives de création de communautés ouvertes.

Semer et récolter

Le pluriel d’ « utilisateur » n’est pas « communauté ». Si l’un peut s’accroître en nombre, l’autre ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.

Préparer le support technologique

Créer une communauté commence avant même que le premier utilisateur n’apparaisse. D’emblée, le choix du langage de programmation va déterminer le nombre de personnes qui pourront déployer et déboguer notre code. Objective Caml est sans doute un beau langage, mais si l’on utilise plutôt Java, la quantité d’utilisateurs et de contributeurs potentiels augmentera de plusieurs ordres de grandeur. Les développeurs doivent donc faire des compromis puisque la technologie la plus répandue est rarement la plus performante ou la plus élégante. Cela peut être une démarche particulièrement difficile pour des chercheurs qui privilégient souvent la supériorité formelle du langage. Quand je travaillais sur Semantic MediaWiki, on m’a souvent demandé pourquoi nous utilisions PHP alors que Java côté serveur serait tellement plus propre et performant. Comparons la taille de la communauté de Semantic MediaWiki et les efforts que demanderait le même développement basé sur du Java : voilà peut-être un début de réponse. Cet exemple illustre aussi que l’audience ciblée détermine le meilleur choix de la technologie de base. Le développeur lui-même devrait avoir le recul nécessaire pour prendre la décision la plus opportune.

Préparer minutieusement le terrain

Dans le même ordre d’idées, il faut créer un code lisible et bien documenté dès le début. Dans un environnement universitaire, certains projets logiciels rassemblent de nombreux contributeurs temporaires. Les changements dans les plannings et les projets des étudiants peuvent nuire à la qualité du code. Je me souviens d’un petit projet de logiciel à l’Université technique de Dresde qui avait été très bien maintenu par un assistant étudiant. Après son départ, on a constaté que le code était minutieusement documenté… en turc. Un chercheur ne peut être programmeur qu’à temps partiel, une discipline particulière est donc nécessaire pour mettre en œuvre le travail supplémentaire indispensable à l’élaboration d’un code accessible. En retour il y aura de bien meilleures chances par la suite d’avoir de bons rapports de bogues, des patchs utiles ou même des développeurs extérieurs.

Semer les graines des communautés

Les développeurs open source inexpérimentés considèrent souvent comme un grand moment la publication ouverte de leur code. En réalité, personne d’autre qu’eux ne la remarquera. Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile. Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation d’utilisation basique.

Au cours de sa vie, le projet devrait être mentionné dans tous les endroits adéquats, y compris des sites web — à commencer par votre page d’accueil ! — des conférences, des papiers scientifiques, des discussions en ligne. On ne dira jamais assez le pouvoir du simple lien qui conduira un futur contributeur important sur le site du projet dès sa première visite. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche. Les autres chercheurs sont rarement la meilleure base pour une communauté active.

Fournir des espaces pour grandir

Banal mais souvent négligé, le devoir des personnes qui maintiennent le projet est de fournir des espaces de communication afin que la communauté puisse se développer. Si un projet n’a pas de liste de discussion dédiée, alors toutes les demandes d’aide seront envoyées en message privé à la maintenance. S’il n’y a pas de bugtracker (NdT : logiciel de suivi de problèmes), les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki éditable par tout un chacun pour la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence. Si la version de développement du code source n’est pas accessible, alors les utilisateurs ne seront pas dans la capacité de tester la dernière version avant de se plaindre de problèmes. Si le dépôt de code est intrinsèquement fermé, il n’est alors pas possible d’accueillir des contributeurs externes. Toute cette infrastructure est disponible gratuitement par l’intermédiaire d’un certain nombre de fournisseurs de service. Toutes les formes d’interaction ne sont pas forcément désirées, par exemple, il y a des raisons de garder fermé le cercle des développeurs. Mais il serait inconscient d’espérer le soutien d’une communauté sans même préparer des espaces de base pour celle-ci.

Encourager et contrôler la croissance

Les développeurs inexpérimentés sont souvent préoccupés par le fait que l’ouverture de listes de diffusions, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas, mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre rigoureuse des usages de communication publique. Les utilisateurs ont besoin d’apprendre à poser des questions publiquement, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide du bugtracker plutôt que par e-mail. J’ai tendance à rejeter toutes les demandes d’aide privées, ou à répondre via des listes publiques. Cela garantit au passage que les solutions sont disponibles sur le web pour les futurs utilisateurs qui les chercheront. Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup d’enthousiasme et des gens bien intentionnés pour construire une communauté solide.

Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer d’avantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté. De même, l’enthousiasme le mieux intentionné n’est pas toujours productif et il faut parfois savoir dire non — gentiment mais clairement – pour éviter les dérapages possibles.

Le futur est ouvert

Construire une communauté initiale autour d’un projet contribue fortement à transformer un prototype de recherche en un logiciel open source. Si ça porte ses fruits, il existe de nombreuses options pour le développer en fonction des buts fixés par le mainteneur du projet et la communauté. Voici quelques indications :

Persévérer dans l’expansion du projet et de sa communauté open source, augmenter le nombre de personnes ayant des droits de contributions « directs », en réduisant la dépendance à son origine universitaire. Par ce biais, vous impliquez plus fortement la communauté – notamment au travers d’événements dédiés –;et vous pourrez établir un soutien organisationnel.

Créer une entreprise commerciale pour exploiter le projet, basée, par exemple, sur une double licence ou un business model de consultant. Des outils ayant fait leurs preuves et une communauté active sont des atouts majeurs dès le lancement d’une entreprise, et peuvent être bénéfiques dans chacune de vos stratégies d’entreprise sans abandonner le produit original open source.

Se retirer du projet. Il y a de nombreuses raisons pour qu’on ne puisse plus maintenir de lien avec le projet. Le fait d’avoir établi une communauté saine et ouverte maximise les chances pour que le projet continue de voler de ses propres ailes. Dans tous les cas, il est plus correct de faire une coupure nette que d’abandonner silencieusement le projet, en le tuant par une activité en chute libre au point qu’on ne trouve plus personne pour le maintenir.

Le profil de la communauté sera différent selon qu’on opte pour telle ou telle stratégie de développement. Mais dans tous les cas, le rôle du chercheur évolue en fonction des objectifs du projet. Le scientifique initial et le programmeur pourront prendre le rôle de gestionnaire ou de directeur technique. En ce sens, la différence principale entre un projet de logiciel open source d’importance et la recherche perpétuelle d’un prototype n’est pas tant la quantité de travail mais le type de travail nécessaire pour y arriver. Cela compte pour beaucoup dans sa réussite. Une fois qu’on l’a compris, il ne reste plus qu’à réaliser un super logiciel.

[1] Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on  Software Engineering. Anniversary Edition. Addison-Wesley, 1995.