Le travail intellectuel des programmeurs souffrirait-il d’un manque de visibilité et de reconnaissance aux yeux d’une logique managériale qui cherche à mesurer le travail effectif avec des critères dépassés ? C’est ce que laisse entendre ce témoignage qui au détour d’une plaisante anecdote met l’accent sur un relatif malaise d’une profession qu’il est difficile de cerner de l’extérieur, et même de l’intérieur d’une entreprise.

Are Your Programmers Working Hard, Or Are They Lazy? article paru sur le blog de l’auteur

Traduction Framalang : sinma, goofy, KoS

Vos programmeurs travaillent-ils dur, ou sont-ils fainéants ?

par Mike Hadlow

Quand quelqu’un effectue une tâche physique, il est facile d’évaluer à quel point il travaille dur. Vous pouvez le voir physiquement en mouvement et en transpiration. Vous pouvez aussi voir le résultat de son travail : le mur de briques s’élève, le trou dans le sol devient plus profond. Reconnaître et récompenser un dur labeur est un instinct assez fondamental chez l’être humain, c’est l’une des raisons pour lesquelles nous trouvons les sports d’endurance si fascinants. Cette reconnaissance d’un dur travail physique devient un problème quand on l’applique à la gestion de personnes qui travaillent à des activités techniques ou créatives. Souvent, les travailleurs intellectuels efficaces n’ont pas l’air de travailler très dur.

En 2004, j’étais développeur junior dans une grande équipe qui s’occupait du système de fourniture et de facturation d’une entreprise de télévision par câble. Comme tous les grands systèmes, il était constitué de plusieurs unités relativement indépendantes dont s’occupaient des personnes ou des équipes différentes. Les départements de TV analogiques et numériques étaient presque entièrement séparés, pris en charge par des équipes différentes.

L’équipe de la TV analogique avait décidé de fonder son système autour d’une pré-version de Microsoft Biztalk. Quatre gars de chez nous et une équipe de Microsoft le développaient et le faisaient tourner en production. Ils avaient tous l’air de travailler très dur. On les voyait souvent travailler tard dans la nuit et pendant le weekend.

Chacun laissait tomber ce qu’il était en train de faire si un problème survenait en production, ils se réunissaient souvent autour du bureau d’un type, faisaient des suggestions pour régler ce qui n’allait pas, ou pour réparer quelque chose. L’activité était permanente, et tout le monde pouvait voir non seulement qu’il y avait un véritable esprit d’équipe, mais que tout le monde travaillait très très dur.

L’équipe chargée de la TV numérique était tout à fait différente. Le code avait été, en majorité, écrit par une seule personne que l’on appellera Dave. Il était développeur de maintenance junior dans l’équipe. Au départ, j’ai eu beaucoup de difficultés à comprendre le code. Au lieu d’une seule longue procédure dans un endroit précis où tout le travail se serait effectué, il y avait des tas de petites classes et méthodes avec seulement quelques lignes de code. Plusieurs collègues se plaignirent que Dave rendait les choses extrêmement compliquées. Mais Dave me prit sous son aile et me conseilla de lire quelques livres sur la programmation orientée objet. Il m’apprit les patrons de conception, les principes SOLID, et les tests unitaires. Le code commença alors à avoir du sens, et plus je travaillais dessus plus j’appréciais l’élégance de sa conception. Il ne posait pas de problème en phase de production, il ronronnait dans son coin et faisait le boulot. Il était assez facile d’opérer des modifications dans le code, du coup l’implémentation de nouvelles fonctionnalités se faisait souvent sans aucun problème. Les tests unitaires permettaient de trouver la plupart des bugs avant la mise en production.

Le résultat de tout cela est que nous n’avions pas l’air de travailler très dur du tout. Je rentrais chez moi à 18h30, je ne travaillais jamais pendant les weekends, nous ne passions pas des heures attroupés autour du bureau de quelqu’un d’autre pour deviner le problème avec un quelconque système planté en production. De l’extérieur, notre tâche devait sembler beaucoup plus facile que celle des gens de la TV analogique. En vérité, les exigences étaient très similaires, mais nous avions un logiciel mieux conçu et implémenté, et une meilleure infrastructure de développement, notamment les tests unitaires.

La direction fit savoir que des augmentations seraient accordées sur la base de nos performances. Quand ce fut mon tour de parler au directeur, il expliqua qu’il était normal que les augmentations soient accordées à ceux qui travaillaient vraiment dur, et que l’entreprise ne semblait pas importer beaucoup à notre équipe, au contraire de ces héros qui lui consacraient leurs soirées et leurs weekends.

photo par nic’s events – CC BY-SA 2.0

Cette entreprise était l’un des rares laboratoires où l’on pouvait comparer directement les effets d’une bonne ou d’une mauvaise conception logicielle et le comportement d’une équipe. La plupart des organisations ne permettent pas une telle comparaison. Il est très difficile de dire si ce type, transpirant sang et eau, travaillant tard les soirs et weekends, constamment sur la brèche, fait preuve d’une grande volonté pour faire fonctionner un système vraiment très complexe, ou s’il est simplement nul. Sauf si vous pouvez vous permettre d’avoir deux ou plusieurs équipes concurrentes travaillant à résoudre le même problème, mais bon, personne ne fait ça, on ne saura donc jamais. Et au contraire, le type assis dans son coin, travaillant de 9 heures à 17 heures et qui semble passer beaucoup de temps à lire sur internet ? Est-il très compétent pour écrire un code stable et fiable, ou son boulot est-il plus facile que celui des autres ? Pour l’observateur moyen, le premier travaille vraiment dur, pas le second. Travailler dur c’est bien, la paresse c’est mal, n’est-ce pas ?

Je dirais qu’avoir l’air de travailler dur est souvent un signe d’échec. Le développement logiciel est souvent mal fait dans un environnement sous pression et dans lequel on est souvent interrompu. Ce n’est généralement pas une bonne idée de travailler de longues heures. Quelquefois, la meilleure façon de résoudre un problème est d’arrêter d’y penser, d’aller prendre l’air, ou encore mieux, de prendre une bonne nuit de sommeil et de laisser faire notre subconscient. Un de mes livres favoris est « A Mathematician’s Apology » (traduit sous le titre L’apologie d’un mathématicien) par G. H. Hardy, un des mathématiciens anglais les plus importants du XX^e siècle. Il y décrit sa routine : quelques heures de travail le matin suivies par un après-midi à regarder le cricket. Il dit qu’il est inutile et contre-productif d’effectuer un travail mental intensif plus de quatre heures par jour.

photo par sfllaw – CC BY-SA 2.0

J’aimerais dire aux manageurs de juger les gens en regardant leurs résultats, leurs logiciels qui tournent bien, et non en regardant si les programmeurs ont l’air de travailler dur. C’est contre-intuitif, mais il est sans doute préférable de ne pas vous assoir tout près de vos développeurs, vous pourrez ainsi avoir une meilleure idée de ce qu’ils ont produit, sans être affecté par des indicateurs conventionnels ou intuitifs. Le travail à distance est particulièrement bénéfique ; vous devez apprécier vos employés pour leur travail, plutôt que par la solution de facilité qui consiste à les regarder assis à leur bureau 8 heures par jour, martelant de façon lancinante sur leur IDE, ou se pressant autour du bureau des autres pour offrir des suggestions « utiles ».

Aujourd’hui nous choisissons de mettre en lumière un jeune développeur qui devrait donner des idées à tous les étudiants en informatique qui nous lisent. Comme vous allez le voir, en choisissant la voie de l’open source, les projets qui paraissaient hors d’atteinte sont finalement accessibles. Rien n’est gagné d’avance mais la voie est libre !

De Firefox à Chromium en passant par Midori, ce ne sont pas les navigateurs Web qui manquent. Il y en a pour tous les goûts, des plus complets aux plus légers. Parmi eux se trouve QupZilla, un navigateur lancé en 2010 par son actuel développeur principal, David Rosca. Alliant légèreté et fonctionnalités, il a aussi la particularité d’être développé par un étudiant qui a lancé ce projet à l’âge de 17 ans, alors qu’il était encore lycéen. Il étudie maintenant l’informatique à l’Université technique de Prague, en République Tchèque. Aujourd’hui, il répond à nos questions pour le Framablog.

Contributeurs Framasoft : lamessen, eyome, Asta , lyn

David Rosca aka Nowrep, développeur de QupZilla

F : Bonjour David, merci de nous accorder cette interview. Peux-tu nous présenter le projet QupZilla ?

David : QupZilla est un navigateur web multi-plateforme écrit sur l’infrastructure Qt. Il utilise le moteur de rendu Webkit à travers le module Qt. L’utilisation de Qt fait que QupZilla est parfaitement adapté à la plate-forme KDE mais il fonctionne aussi très bien sur les autres environnements. Il fonctionne avec tous les systèmes d’exploitation. La dernière version (1.4.1) est sortie il y a peu de temps.

Il est important de dire que QupZilla est un navigateur web qui a pour objectif de rester léger, ne vous attendez donc pas à ce qu’il devienne aussi énorme que les navigateurs les plus courants.

F : Comment a démarré cette aventure ?

David : Cela ne devrait pas vous surprendre : j’aime coder et créer de nouvelles choses. J’avais déjà quelques expériences dans l’écriture d’applications et j’étais assez confiant sur les langages de script. Mon souhait était de créer une vraie application. L’élément déclencheur a été de passer sous un système d’exploitation Linux, à partir de ce moment, je me suis dit : « Pourquoi pas ? Il n’y a plus rien qui t’arrête maintenant ! ». En fait mon plus gros problème a été de trouver quel type d’application créer. J’avais commencé à suivre quelques tutoriels, je commençais à comprendre les bases de ce type de programmation mais l’ennui serait vite arrivé si je n’avais pas su quelle appli développer. Au cours d’une discussion, un ami m’a suggéré de créer un navigateur, c’était sans doute une plaisanterie mais j’ai vraiment aimé cette idée et j’ai donc commencé à travailler dessus.

F : Une fois que tu as su quoi créer, comment t’es-tu organisé ?

David : J’ai d’abord choisi un langage de programmation. Mon choix s’est porté vers Python, un langage plus facile que le C++. Bizarrement, choisir la facilité a été la cause de mon plus gros problème. Quand vous apprenez un nouveau langage de programmation, vous rencontrez de nombreux problèmes et vous cherchez des solutions sur Internet. Plus votre langage est populaire, plus vous trouverez de réponses. Mais même si PyQt (Python pour Qt) est très populaire, la majorité des tutoriels, exemples, etc. sont pour le C.

J’ai donc essayé de traduire le C++, utilisé dans les tutoriels, en Python. C’était très difficile car je n’avais aucune expérience du C++ et que je commençais à peine à apprendre Python. J’ai donc finalement décidé d’utiliser le C++ et j’ai réécrit tout le code que j’avais. Et ça a vraiment été une bonne chose.

À ce moment-là, je ne pensais pas que mon code puisse être rendu public. Je plaisantais bien sûr sur le fait qu’un jour, j’aurais des centaines de milliers de téléchargements, mais c’était tout. Je ne pouvais même pas imaginer que quelqu’un puisse vouloir participer à mon projet. Ce ne sont donc pas les choses auxquelles vous pensez quand vous êtes en train d’apprendre un nouveau langage et que vous commencez un « projet d’apprentissage ».

F : Tu as choisi de développer ton logiciel sous licence GPLv3. Peux-tu nous expliquer pourquoi ?

David : Pour être honnête, j’ai choisi la GPLv3 uniquement parce que la majorité des projets open source l’utilisaient (kernel linux inclus, mais en GPL V2). Je ne connaissais pas vraiment les différences entre les licences. Mais maintenant, je suis content de mon choix. Je ne voudrais pas choisir une autre licence pour Qupzilla. Je ne sais pas exactement ce que serait la licence de mes rêves, je ne suis pas un expert en licence. Mais je suis vraiment satisfait avec la GPLv3.

F : Cela fait maintenant plusieurs années que tu travailles sur QupZilla, peux-tu nous dire ce que cela t’a apporté, ce qui a marché et moins bien marché ?

David : Tu as raison, ça fait un bon moment que j’ai commencé à coder QupZilla. Même si il y a eu des périodes où je n’avais pas assez de temps pour développer, parfois à cause de l’école ou simplement par manque d’intérêt, je suis toujours revenu vers QupZilla. QupZilla m’a d’abord apporté beaucoup d’expérience, à la fois en codage, en utilisation de nouveaux outils et en gestion d’un projet qui au final n’est pas si petit. J’ai aussi rencontré beaucoup de nouvelles personnes. Pour résumer, j’ai savouré chaque instant. Bien sûr, il y a eu quelques erreurs, petites ou grandes. C’était essentiellement à cause d’un manque de connaissances et d’expérience dans les domaines concernés. Mais j’en ai toujours tiré une leçon. Il y a beaucoup de choses que je ferais différemment si je pouvais revenir en arrière dans le temps. Par exemple, j’aurais commencé à écrire des tests pour les fonctions de base dès le début du projet, pour éviter les régressions (c’est ce que je fais maintenant).

F : Aujourd’hui, QupZilla est un projet bien vivant, apprécié, et qui compte de nombreux contributeurs. Il est intégralement traduit dans plus de 20 langues. Imaginais-tu que ça puisse prendre une telle ampleur alors que le marché des navigateurs est extrêmement concurrentiel ? Comment a-t-il selon toi trouvé son public ?

David : Les navigateurs légers sont très populaires, principalement sur les machines Linux étant donné qu’il est possible de les faire fonctionner sur de très vieux matériels. Du coup, j’ai pensé qu’il y avait peut-être une place pour QupZilla. Maintenant, je peux dire que j’avais raison. Je pense également que « léger » ne veut pas forcément dire « manque de fonctionnalités ». C’est cette optique de développement que suit QupZilla.

F : Tu as choisi d’utiliser de nombreux outils facilitant le travail communautaire autour de ton projet : Qt comme base de travail, Github pour le code, récemment Transifex pour la traduction. Quels étaient tes critères ? Ont-ils été satisfaits ?

David : J’ai choisi Qt parce qu’il est disponible partout. Il convient parfaitement aux applications multi-plateformes. GitHub comme hébergeur pour le dépôt git est aussi le choix n°1. Ils offrent un bon plan pour les projets open source, et avec l’approche « codage social », il est plus facile de trouver de nouveaux contributeurs. Pour moi, GitHub est le meilleur choix pour n’importe quel projet open source.

J’ai récemment déplacé toutes mes traductions vers Transifex. Ça facilite la gestion, et c’est aussi un moyen de trouver de nouveaux traducteurs (ce qui s’est déjà confirmé). Je ne suis toutefois pas satisfait de la vitesse à laquelle ils implémentent les nouveaux éléments (essentiellement les nouvelles langues). Il faut plus d’un an et demi pour une demande de nouvelle langue. Du coup, il y a des soucis, notamment avec les traductions serbes.

F : Comment vois-tu la suite de QupZilla ? Tu as longtemps été le seul développeur. Tu as maintenant quelques contributions au niveau du code. Penses-tu à l’avenir te faire davantage épauler ?

David : Je ne pense pas que ça va changer tant que ça. Ce n’est pas vraiment facile d’attirer de nouveaux contributeurs. La situation actuelle me convient : je suis le développeur principal et d’autres personnes m’envoient des patch (correctifs et contributions) de temps en temps. Mais ça va peut-être changer si QupZilla a de la chance 🙂

F : Nous savons que les projets grandissants ont souvent besoin de trouver de nouveaux contributeurs pour avancer. Peut-être même qu’en ce moment, l’un de tes plus importants contributeurs est en train de lire cette interview. Peux-tu nous dire quels sont tes besoins humains sur le projet ?

David : Il n’y a jamais assez de contributeurs. Non seulement pour coder, mais aussi pour traduire, tester les nouvelles versions, etc. Mais ce qui aiderait vraiment QupZilla, mais aussi tous les autres projets basés sur QtWebKit serait d’insister d’avantage sur la partie en C++ de QtWebKit. Il y a en ce moment une nouvelle version pour Qt 4.8, QtWebKit 2.3. C’est une release vraiment bonne. Cependant, le développement est nécessaire pour garder le projet compétitif. Ce serait donc la meilleure façon d’aider QupZilla.

F : Tu fais maintenant partie de la grande famille du logiciel libre. Es-tu impliqué dans d’autres projets ? Souhaites-tu t’investir sur certains en particulier ?

David : J’ai envoyé de petits correctifs pour de nombreux autres projets, mais je n’ai jamais fait quelque chose de grand. Par exemple, je peux parler du lecteur de musique Tomahawk ou encore QtWebkit (sur lequel QupZilla est basé). J’aimerais contribuer d’avantage à QtWebKit, mais ce n’est pas facile de travailler sur un projet aussi important. J’aimerais aussi participer au Google Summer of Code project pendant les vacances d’été.

F : Tu es pour le moment étudiant, mais la vie professionnelle arrive à grand pas. Comment vois-tu ton avenir ?

David : Tu as raison, j’étudie maintenant à l’université. J’ai choisi une université ouverte sur l’open source, mes expériences ont donc déjà été utiles.

J’espère vraiment réussir à travailler dans une société basée sur des technologies open source. J’aime la communauté open source. Mais qui sait ce qui arrivera ? Quoi qu’il en soit, je n’ai pas l’intention d’arrêter de contribuer à des projets libres et open source.

F : Merci d’avoir pris le temps de répondre à nos questions. Nous te souhaitons une bonne continuation, en espérant voir Qupzilla grandir dans le bon sens.

David : Merci à vous aussi.

Bientôt la dernière séance… rejoignez-nous jeudi prochain sur le framapad de traduction

Traduction Framalang : Ouve, tcit, Julius22, goofy, merlin8282, lamessen, Jej, Alpha

Sous-estimer la valeur d’un modèle économique pour le logiciel libre

Frank Karlitschek

Frank Karlitschek est né en 1973 à Reutlingen, en Allemagne, et a commencé à écrire des logiciels à l’âge de 11 ans. Il a étudié l’informatique à l’université de Tübingen et s’est impliqué dans le logiciel libre et les technologies de l’internet dans le milieu des années 1990. En 2001, il a commencé à contribuer à KDE en lançant KDE-Look.org, un site communautaire d’œuvres qui deviendrait plus tard le réseau openDesktop.org. Frank a initié plusieurs projets et initiatives open source comme Social Desktop, Open Collaboration Services, Open-PC et ownCloud. En 2007, il a fondé une société appelée hive01 qui offrait des services et des produits autour de l’open source et des technologies de l’internet. Aujourd’hui, Frank est membre du conseil et vice-président de KDE e.V. et c’est un intervenant habitué des conférences internationales.

Introduction

Il y a dix ans, j’ai sous-estimé la valeur d’un modèle économique. Logiciel libre et modèle économique ? Deux concepts incompatibles. Du moins, c’est ce que je pensais lorsque j’ai commencé à contribuer à KDE en 2001. Le logiciel libre, c’est pour le plaisir et pas pour l’argent. N’est-ce pas ? Les libristes veulent un monde où chacun peut écrire du logiciel et où les grandes entreprises, telles que Microsoft ou Google, sont superflues. Tout logiciel devrait être libre et tous ceux qui souhaitent développer du logiciel devraient en avoir la possibilité — même les développeurs du dimanche. Donc, gagner de l’argent importe peu. N’est-ce pas ? Aujourd’hui, j’ai une opinion différente. Les développeurs devraient parfois être rémunérés pour leurs efforts.

Les raisons d’être du logiciel libre

La plupart des développeurs de logiciels libres ont deux principales motivations pour travailler sur le logiciel libre. La première motivation est le facteur plaisir. C’est une expérience fantastique de travailler avec d’autres personnes très talentueuses du monde entier et de créer des technologies exceptionnelles. KDE, par exemple, est une des communautés les plus accueillantes que je connaisse. C’est tellement amusant de travailler avec des milliers de contributeurs du monde entier pour créer des logiciels qui seront utilisés par des millions de personnes. Pour faire simple, tout le monde est expert dans un ou plusieurs domaines et nous collaborons pour créer une vision partagée. Pour moi, c’est toujours génial de rencontrer d’autres contributeurs de KDE, d’échanger des idées ou de travailler sur nos logiciels ensemble, que nous nous rencontrions en ligne ou dans la vie réelle à une des nombreuses conférences ou événements. Et il s’agit aussi d’amitié. Au fil des années, je me suis fait beaucoup de bons amis au sein de KDE.

Mais les contributeurs de KDE ne sont pas uniquement motivés par le plaisir de rejoindre KDE. Il y a aussi l’idée que chacun de nous peut rendre le monde meilleur par nos contributions. Le logiciel libre est essentiel si vous vous souciez de l’accès à la technologie et à l’informatique pour les pays en voie de développement. Cela permet aux personnes pauvres d’avoir leur place dans l’ère de l’information sans acheter des licences coûteuses pour des logiciels propriétaires. Il est essentiel pour les personnes qui se soucient de la confidentialité et de la sécurité, parce que le logiciel libre est le seul et unique moyen de savoir exactement ce que votre ordinateur fait avec vos données privées. Le logiciel libre est important pour un écosystème informatique sain, parce qu’il permet à tout le monde de bâtir à partir du travail des autres et de vraiment innover. Sans le logiciel libre, il n’aurait pas été possible à Google ou Facebook de lancer leurs entreprises. Il n’est pas possible d’innover et de créer la nouvelle technologie marquante si vous dépendez de logiciels propriétaires et que vous n’avez pas accès à toutes les parties du logiciel.

Le logiciel libre est aussi indispensable pour l’éducation, parce que tout le monde peut voir les entrailles du logiciel et étudier son fonctionnement. C’est comme cela que le logiciel libre contribue à faire du monde un endroit meilleur et c’est pourquoi je participe à des projets de logiciel libre comme KDE.

La nécessité d’un écosystème

Voilà les principales raisons pour lesquelles je veux que le logiciel libre et particulièrement le bureau libre soient largement répandus. Pour y parvenir, il nous faut bien plus de contributeurs qu’aujourd’hui. Par contributeurs, j’entends des gens qui écrivent les infrastructures centrales, le bureau et les grandes applications. Nous avons besoin de gens qui travaillent sur l’utilisabilité, sur les illustrations, sur la promotion et sur bien d’autres aspects importants. KDE est déjà une grande communauté avec des milliers de membres. Mais nous avons besoin de davantage de gens pour aider à rivaliser de manière sérieuse avec le logiciel propriétaire.

La communauté du logiciel libre est minuscule comparée au monde du logiciel propriétaire. D’un côté, ce n’est pas un problème car le modèle de développement logiciel distribué du monde du logiciel libre est bien plus performant que la façon d’écrire du logiciel à sources fermées. Un grand avantage est, par exemple, la possibilité de mieux réutiliser du code. Mais même avec ces avantages, nous avons besoin de bien plus de contributeurs qu’aujourd’hui si nous voulons réellement conquérir le marché de l’ordinateur de bureau et celui du mobile.

Nous avons aussi besoin d’entreprises pour nous aider à apporter notre travail sur le marché de masse. Bref, nous avons besoin d’un grand écosystème en forme permettant de vivre en travaillant sur le logiciel libre.

La situation actuelle

J’ai commencé à contribuer à KDE il y a plus de 10 ans et, depuis, j’ai vu d’innombrables volontaires très motivés et talentueux rejoindre KDE. C’est vraiment génial. Le problème, c’est que j’ai aussi vu beaucoup de contributeurs expérimentés abandonner KDE. C’est vraiment triste. Parfois, c’est simplement la marche normale du monde : les priorités changent et les gens se concentrent sur autre chose. Le problème, c’est que beaucoup abandonnent aussi à cause de l’argent. Il arrive un moment où les gens décrochent leur diplôme et veulent bouger de leur chambre d’étudiant.

Plus tard, ils veulent se marier et avoir des enfants. À partir de là, ils doivent trouver du travail. Il y a quelques entreprises dans l’écosystème de KDE qui proposent des postes liés à KDE. Mais cela ne représente qu’une petite part des emplois disponibles dans le secteur informatique. Du coup, beaucoup de membres chevronnés de KDE doivent travailler dans des entreprises où ils doivent utiliser des logiciels propriétaires qui n’ont rien à voir avec KDE ou le logiciel libre. Tôt ou tard, la plupart de ces développeurs abandonnent KDE. J’ai sous-estimé cette tendance il y a 10 ans, mais je pense que c’est un problème pour KDE sur le long terme, parce que nous perdons nos membres les plus expérimentés au profit des entreprises de logiciel propriétaire.

Le monde de mes rêves

Dans le monde idéal que j’imagine, les gens peuvent payer leur loyer en travaillant sur les logiciels libres et ils peuvent le faire de telle sorte que ça n’entre pas en conflit avec nos valeurs. Ceux qui contribuent à KDE devraient avoir tout le temps qu’ils veulent pour contribuer à KDE et au monde libre en général. Ils devraient gagner de l’argent en aidant KDE. Leur passe-temps deviendrait leur travail. Cela permettrait à KDE de se développer de manière spectaculaire, parce que ce serait super de contribuer et de fournir en même temps de bonnes perspectives d’emploi stables et à long terme.

Quelles possibilités avons-nous ?

Du coup, quelles sont les solutions possibles ? Que pouvons-nous faire pour que ça arrive ? Y a-t-il des moyens pour que les développeurs paient leur loyer tout en travaillant sur du logiciel libre ? Je voudrais exposer ici quelques idées que j’ai rassemblées au cours de plusieurs discussions avec des contributeurs au logiciel libre. Certaines d’entre elles sont probablement polémiques, parce qu’elles introduisent des idées complètement neuves au sein du monde du logiciel libre. Mais je pense qu’il est essentiel pour nous de voir au-delà de notre monde actuel si nous voulons mener à bien notre mission.

Du développement sponsorisé

Aujourd’hui, de plus en plus d’entreprises apprécient l’importance du logiciel libre et contribuent à des projets de logiciels libres, ou sortent même leurs propres projets de logiciel libre. C’est une chance pour les développeurs de logiciels libres. Nous devrions parler à davantage d’entreprises et les convaincre de s’associer au monde du logiciel libre.

Des dons de la part des utilisateurs

Il devrait y avoir une manière facile pour les utilisateurs de donner de l’argent directement aux développeurs. Si un utilisateur d’une application populaire veut soutenir le développeur et promouvoir ses développements à venir pour cette application, donner de l’argent devrait ne tenir qu’à un clic de souris. Le système de dons peut être construit au sein même de l’application pour rendre le don d’argent aussi facile que possible.

Des primes

L’idée derrière les primes est qu’un ou plusieurs utilisateurs d’une application peuvent payer pour le développement d’une fonctionnalité particulière. Un utilisateur peut soumettre la liste de ses demandes de nouvelles fonctionnalités sur un site web et annoncer combien il est prêt à payer pour cela. D’autres utilisateurs qui apprécient ces propositions pourraient ajouter de l’argent à la demande de fonctionnalité. Au bout d’un moment, le développeur commence à mettre au point la fonctionnalité et récupère l’argent des utilisateurs. Cette possibilité de primes n’est pas facile à introduire dans le processus. Des gens ont déjà essayé de mettre en place quelque chose de similaire, sans succès. Mais je pense que ça peut marcher si on s’y prend bien.

Du support

L’idée est que le développeur d’une application vende directement du support aux utilisateurs de l’application. Par exemple, les utilisateurs d’une application achètent du support pour, supposons, 5 € par mois et obtiennent le droit d’appeler directement le développeur à des plages horaires spécifiques de la journée, ils peuvent poser des questions à une adresse de courriel spécifique, ou le développeur peut  même aider les utilisateurs par le biais d’un bureau à distance. J’ai bien conscience que beaucoup de développeurs n’aimeront pas l’idée que les utilisateurs puissent les appeler et leur poser des questions bizarres. Mais si cela signifie qu’ils gagnent suffisamment avec le système de support pour travailler à plein temps sur leurs applications, alors c’est certainement une bonne chose.

Des soutiens

L’idée c’est que les utilisateurs finaux puissent devenir les soutiens d’une application. Le bouton « Soutenez ce projet » pourrait être intégré directement dans l’application. L’utilisateur devient alors un soutien par un paiement mensuel de, par exemple, 5 € qui vont directement au développeur. Tous les soutiens sont listés dans la fenêtre « À propos de l’application » avec leurs photos et leurs noms réels. Une fois par an, tous les soutiens sont aussi invités à une fête spéciale avec les développeurs. Il est possible qu’un développeur puisse devenir capable de travailler à plein temps sur une application, si assez d’utilisateurs deviennent des soutiens.

Des programmes de fidélité

Certaines applications ont intégré des services web, et certains de ces services Web exécutent des programmes affiliés. Par exemple, un lecteur multimédia peut être intégré à la boutique en ligne de MP3 Amazon ou un lecteur PDF peut être intégré à une boutique en ligne de livres numériques. À chaque fois qu’un utilisateur achète du contenu via cette application, le développeur obtient un peu d’argent.

Des magasins d’applications sous forme de binaires

Beaucoup de gens ne savent pas qu’il est possible de vendre des binaires de logiciels libres. La licence GPL exige simplement de fournir également le code source. Il est donc parfaitement légal de vendre des binaires bien empaquetés de notre logiciel. En réalité, les sociétés comme Red Hat et Novell vendent déjà notre logiciel dans leurs distributions commerciales. Mais les développeurs n’en bénéficient pas directement. Tous les revenus vont aux sociétés et rien ne va aux développeurs. On devrait donc permettre aux développeurs de logiciels libres de vendre à l’utilisateur final des applications bien empaquetées, optimisées et testées. Cela pourrait particulièrement bien fonctionner pour Mac ou Windows. Je suis sûr qu’un tas de gens seraient prêts à payer quelque chose pour des binaires d’Amarok pour Windows ou de digiKam pour Mac, si tout l’argent allait directement au développeur.

Conclusion

La plupart de ces idées ne sont pas faciles à mettre en œuvre. Cela nécessite de modifier notre logiciel, nos méthodes de travail et même nos utilisateurs, qu’il faut encourager à montrer qu’ils apprécient le logiciel que nous créons, en nous aidant à financer son développement. 

Cependant, les bénéfices potentiels sont énormes. Si nous pouvons assurer des sources de revenus pour notre logiciel, nous pouvons conserver nos meilleurs contributeurs et peut-être en attirer de nouveaux. Nos utilisateurs auront une meilleure expérience avec un développement logiciel plus rapide, la possibilité d’influencer directement le développement par le biais de primes et un meilleur support.

Le logiciel libre n’est plus seulement un loisir sur votre temps libre. Il est temps d’en faire un business.

Antirez est un développeur de logiciel libre… ou plutôt open source, car c’est l’expression qu’il semble privilégier.

Il nous livre ici le fruit de sa petit réflexion.

Ainsi il préfère les licences permissives à celles copyleft. Ce qui ne l’empêche pas de souhaiter voir plus de rétribution dans le domaine, parce que si l’on est obligé de payer sa facture autrement alors il y aura moins de code utile à disposition de tous.

Quelques réflexions sur le logiciel open source

A few thoughts about Open Source Software

Antirez – janvier 2013 – Blog personnel
(Traduction : FanGio, peupleLà, ehsavoie, Tibo, Sphinx, Penguin + anonymes)

Voilà plus de quinze ans que je contribue régulièrement à l‘open source, et cependant je m’arrête assez rarement pour réfléchir à ce que cela représente pour moi. C’est probablement parce que j’aime écrire du code et que c’est ainsi que je passe mon temps : écrire du code plutôt que réfléchir à ce que cela signifie… Cependant ces derniers temps, je commence à avoir des idées récurrentes sur l‘open source, ses relations avec l’industrie informatique et mon interprétation de ce qu’est le logiciel open source pour moi, en tant que développeur.

Tout d’abord, l‘open source n’est pas pour moi une manière de contribuer au mouvement du logiciel libre, mais de contribuer à l’humanité. Cela veut dire beaucoup de choses, par exemple peu m’importe ce que les autres font avec mon code ou qu’ils ne reversent pas leurs modifications. Je veux tout simplement que des personnes utilisent mon code d’une manière ou d’une autre.

En particulier, je veux que les gens s’amusent, apprennent de nouvelles chose et se « fassent de l’argent » avec mon code. Pour moi, que d’autres se fassent de l’argent avec le code que j’ai écrit n’est pas une perte mais un gain.

1. J’ai beaucoup plus d’impact sur le monde si quelqu’un peut payer ses factures en utilisant mon code ;
2. Si N personnes gagnent de l’argent avec mon code, peut-être qu’elles seront heureuses de m’en faire profiter ou plus disposées à m’engager ;
3. Je peux être moi-même l’une de ces personnes qui gagnent de l’argent avec mon code, et avec celui d’autres logiciels open source.

Pour toutes ces raisons, mon choix se porte sur la licence BSD qui est en ces termes l’incarnation parfaite de la licence « faites ce que vous voulez ».

Cependant, il est clair que tout le monde ne pense pas de même, et nombreux sont les développeurs contribuant à l‘open source qui n’aiment pas l’idée que d’autres puissent prendre le code source et créer une entreprise qui ferait un logiciel commercial sous une autre licence.

Pour moi, les règles que vous devez suivre pour utiliser une licence GPL représentent une barrière qui réduit la liberté de ce que les personnes peuvent faire avec le code source. De plus, j’ai le sentiment qu’obtenir des contributions n’est pas tellement lié à la licence : si quelque chose est utile, des personnes vont contribuer en retour d’une manière ou d’une autre, car maintenir un fork n’est pas simple. La véritable valeur se trouve là où le développement se produit. Du code non corrigé, qui n’évolue pas, ne vaut rien. Si, en tant que développeur open source, vous pouvez apporter de la valeur, des parties tierces seront encouragées à faire intégrer leurs modifications.

Cependant, je suis beaucoup plus heureux quand il y a moins de correctifs à fusionner et plus de liberté du point de vue des utilisateurs, plutôt que l’inverse, il n’y a donc pas grand chose à discuter pour moi.

De mon point de vue, ce que l‘open source ne reçoit pas suffisamment en retour, ce ne sont pas les correctifs mais plutôt l’argent. Le nouveau mouvement des startups, et les faibles coûts opérationnels de nombreuses entreprises IT viennent de l’existence même de tout ce code open source qui fonctionne bien. Les entreprises devraient essayer de partager une petite partie de l’argent qu’elles gagnent avec les personnes qui écrivent les logiciels open source qui sont un facteur clé de leur réussite, et je pense qu’une manière saine de redistribuer cet argent est d’embaucher ces développeurs pour qu’ils écrivent du logiciel open source (comme VMware l’a fait pour moi), ou de faire des dons.

Beaucoup de développeurs travaillent pendant leur temps libre par passion, seul un petit pourcentage parvient à être payé pour leur contribution à l‘open source. Une éventuelle redistribution peut permettre à plus de gens de se concentrer sur le code qu’ils écrivent par passion et qui a peut être « un impact plus important » sur l’économie que le travail qu’ils font pour obtenir leur salaire chaque mois. Et malheureusement, il est impossible de payer les factures avec des PULL REQUESTS, c’est pourquoi je pense qu’apporter de l’aide à un projet sous forme de code est une bonne chose, mais ce n’est pas suffisant.

Vous pouvez avoir un point de vue différent sur tout cela, mais ce que j’observe, c’est que le logiciel open source produit beaucoup de valeur dans l’industrie informatique actuelle, et qu’il est souvent écrit sur son temps libre ou en jonglant entre les différentes tâches pendant son temps de travail, si votre employeur est assez souple pour vous permettre de le faire.

Ce que je pense, c’est que cela est économiquement sous-optimal, beaucoup de codeurs intelligents pourraient donner une impulsion à l’économie s’ils étaient plus libres d’écrire du code qu’ils aiment et que beaucoup de gens utilisent sans doute déjà pour faire de l’argent.

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

Traduction Framalang : lamessen, Sky, Kalupa, ga3lig, goofy, Astalaseven, okram, KoS, Lycoris, 4nti7rust, peupleLa + Julius22

Penser/Classer

Andre Klapper

Dans la vraie vie, Andre Klapper est maître ès débogage. Pendant sa pause déjeuner ou sa sieste, il travaille à divers trucs sur GNOME (bugsquad, équipe de release, traduction, documentation, etc.), ou Maemo, étudie ou mange de la crème glacée.

Au tout début, je n’avais qu’une seule et unique question : comment imprimer seulement une partie du courriel que j’ai reçu dans Evolution, le client de messagerie GNOME ? J’ai donc demandé sur la liste de diffusion.

Ça faisait exactement un an que j’étais passé sous Linux, frustré de ne pouvoir faire fonctionner mon modem après avoir réinstallé un OS propriétaire plutôt populaire à l’époque.

La réponse à ma question fut : « impossible ». Des petits génies auraient parcouru le code, l’auraient compilé, l’auraient bidouillé pour qu’il se comporte comme voulu, puis auraient soumis un correctif joint au rapport de bogue. Bon. Comme vous l’aurez deviné, je n’étais pas un petit génie. Mes talents de programmeur sont plutôt limités, donc sur le moment je suis resté coincé sur une solution de contournement plutôt lourde pour mon impression. La réponse que j’avais reçue sur la liste de diffusion signalait également que cette fonctionnalité était prévue, et qu’on avait complété pour moi un rapport de bogue — sans préciser où, mais je m’en fichais, j’étais content d’apprendre qu’il était prévu de corriger mon problème prochainement.

Il se peut que je sois resté abonné à la liste de diffusion par simple paresse. Certains mentionnaient le rapporteur de bogues de temps en temps, souvent comme une réponse directe aux demandes de fonctionnalités, alors j’y ai finalement jeté un coup d’œil. Mais les rapporteurs de bogue, en particulier Bugzilla, sont d’étranges outils avec beaucoup d’options complexes. Un domaine que vous préférez normalement éviter à moins que vous ne soyez masochiste. Ils contiennent maints tickets décrivant des bogues ou des demandes de fonctionnalités émanant d’utilisateurs et de développeurs. Il semblait également que ces rapports aient été en partie utilisés pour planifier les priorités (appeler cela « gestion de projet » aurait été un euphémisme ; moins d’un quart des problèmes qui étaient planifiés pour être résolus ou implémentés dans une version spécifique étaient réellement corrigés au bout du compte).

Au-delà d’une vision intéressante sur les problèmes du logiciel et sur la popularité de certaines demandes, ce que j’ai découvert, c’est beaucoup de choses incohérentes et pas mal de bruit, comme des doublons ou des rapports de bogues manquant d’éléments pour pouvoir être traités correctement. J’ai eu envie de nettoyer un peu en « triant » les rapports de bogues disponibles. Je ne sais pas bien ce que cela vous dit sur mon état d’esprit — ajouter ici des mots-clés bidon pour une caractérisation aléatoire, comme organisé, persévérant et intelligent. C’est assez ironique quand on pense à mon père qui se plaignait toujours du bordel dans ma chambre. Donc à cette époque lointaine de modems commutés, j’avais pour habitude de rassembler mes questions et de les faire remonter sur IRC une fois par jour afin de mitrailler de questions le responsable des bogues d’Evolution, qui était toujours accueillant, patient et soucieux de partager son expérience. Si jamais à l’époque il y avait un guide de triage qui couvrait les savoirs de base pour la gestion des bogues et qui exposait les bonnes pratiques et les pièges les plus courants, je n’en avais pas entendu parler.

Le nombre de signalements baissa de 20% en quelques mois, bien que ce ne fût bien évidemment pas grâce à une unique personne qui faisait le tri des tickets. Il y avait manifestement du travail en attente, comme diminuer le nombre des tickets attribués aux développeurs pour qu’ils puissent mieux se concentrer, parler avec eux, définir les priorités, et répondre aux commentaires non-traités de certains utilisateurs. L’open source accueille toujours bien les contributions une fois que vous avez trouvé votre créneau.

Bien plus tard, j’ai pris conscience qu’il y avait de la documentation à consulter. Luis Villa, qui fut probablement le premier des experts en bogues, a écrit un essai titré « Pourquoi tout le monde à besoin d’un expert en bogue » et la majorité des équipes anti-bogues sur les projets open source ont publié au même moment des guides sur le triage qui ont aidé les débutants à s’impliquer dans la communauté. De nombreux développeurs ont débuté leur fantastique carrière dans l’open source en triant les bogues et ont ainsi acquis une première expérience de gestion de projet logiciel.

Il y a aussi de nos jours des outils qui peuvent vous épargner beaucoup de temps quand arrive l’abrutissant travail de triage. Du côté serveur, l’extension « stock answers » de GNOME fournit les commentaires courants et fréquemment usités afin de les ajouter aux tickets en un clic pendant que, du côté client, vous pouvez faire tourner votre propre script  GreaseMonkey ou l’extension Jetpack de Matej Cepl, appelée  « bugzilla-triage-scripts » [2].

Si vous êtes un musicien moyen ou médiocre mais que vous aimez tout de même la musique par-dessus tout, vous pouvez toujours y travailler en tant que journaliste. Le développement de logiciels possède également ce genre de niches qui peuvent vous donner satisfaction, au-delà de l’idée première d’écrire du code. Cela vous prendra un peu de temps pour les trouver, mais ça vaut la peine d’y consacrer vos efforts, votre expérience et vos  contacts. Avec un peu de chance et de talent, cela peut même vous permettre de gagner votre vie dans le domaine qui vous intéresse personnellement… et vous éviter de finir pisse-code.

[1] http://tieguy.org/talks-files/LCA-2005-paper-html/index.html

[2] https://fedorahosted.org/bugzilla-triage-scripts

Crédit photo : Doug DuCap Food and Travel (CC BY-NC-SA 2.0)

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