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

Traduction Framalang : lamessen, Sputnik, lerouge, RavageJo, Sky, Astalaseven, goofy, KoS, peupleLa + Julius22

Une bonne documentation change la vie des débutants

Atul Jha

Atul Jha utilise des logiciels libres depuis 2002. Il travaille en tant que spécialiste des applications au CSS Corp, à Chennai en Inde. Il aime parcourir les universités, rencontrer des étudiants et propager la bonne parole du logiciel libre.

En 2002, on naviguait sur Internet dans des cybercafés en raison du coût important des accès par lignes commutées. À l’époque, la messagerie instantanée de Yahoo était très populaire et j’avais pris l’habitude de discuter sur le canal #hackers. Il y avait quelques fous furieux là-dedans qui prétendaient qu’ils pouvaient pirater mon mot de passe. J’étais très impatient d’en savoir plus sur le piratage et de devenir l’un d’eux. Le lendemain, je suis retourné au cybercafé et j’ai tapé « comment devenir un hacker » sur le moteur de recherche Yahoo. La toute première URL dirigeait sur le livre d’Eric S. Raymond. J’étais fou de joie à l’idée d’entrer dans le cercle des initiés.

J’ai commencé à lire le livre et à ma grande surprise la définition de hacker était « quelqu’un qui aime résoudre les problèmes et dépasser les limites ». Il y est également écrit : « les hackers construisent des choses, les casseurs les brisent »(1). Hélas, je cherchais le côté obscur, celui des crackers, et ce livre m’a mené de l’autre côté de la force, celui des hackers. J’ai continué à lire le livre et à rencontrer divers termes nouveaux tels que GNU/Linux, liste de diffusion, groupe d’utilisateur Linux, IRC, Python et bien d’autres encore.

En poursuivant mes recherches, j’ai pu trouver un groupe d’utilisateurs de Linux à Delhi et j’ai eu l’opportunité de rencontrer de vrais hackers. J’avais l’impression d’être dans un autre monde quand ils parlaient de Perl, RMS, du noyau, des pilotes de périphériques, de compilation et d’autres choses qui me passaient bien au-dessus de la tête.

J’étais dans un autre monde. J’ai préféré rentrer à la maison et trouver une distribution Linux quelque part. J’avais bien trop peur pour leur en demander une. J’étais loin de leur niveau, un débutant totalement idiot. J’ai réussi à en obtenir une en payant 1 000 Roupies indiennes [NdT : environ 13,92 €] à un gars qui en faisait le commerce. J’en ai essayé beaucoup mais je n’arrivais pas à faire fonctionner le son. Cette fois-là, je décidai de consulter un canal IRC depuis le cybercafé. Je trouvai #linux-india et lançai : « g ok1 son ». Des injonctions fusèrent alors : « pas de langage SMS » et « RTFM ». Ça m’a fait encore plus peur et j’ai mis du temps à faire la relation entre « RTFM » et « read the fucking manual » [NdT : « lis le putain de manuel » dans la langue de Molière].

J’étais terrifié et j’ai préféré rester à l’écart de l’IRC pendant quelques semaines.

Un beau jour, j’ai reçu un courriel qui annonçait une réunion mensuelle de groupes d’utilisateurs Linux. J’avais besoin de réponses à mes nombreuses questions. C’est là que j’ai rencontré Karunakar. Il m’a demandé d’apporter mon ordinateur à son bureau, où il avait l’intégralité du dépôt de Debian. C’était nouveau pour moi, mais j’étais satisfait à l’idée de pouvoir enfin écouter de la musique sur Linux. Le lendemain, j’étais dans son bureau après avoir fait le trajet avec mon ordinateur dans un bus bondé, c’était génial. En quelques heures, Debian était opérationnel sur mon système. Il m’a aussi donné quelques livres pour débutants et une liste des commandes de base.

Le lendemain, j’étais à nouveau au cybercafé, et je lisais un autre essai d’Eric S. Raymond, intitulé Comment poser les questions de manière intelligente. Je continuais de fréquenter le canal #hackers sur Yahoo chat où je m’étais fait un très bon ami, Krish, qui m’a suggéré d’acheter le livre intitulé Commandes de références sous Linux. Après avoir passé quelque temps avec ces livres et en utilisant tldp.org (The Linux Documentation Project) comme support, j’étais devenu un utilisateur débutant sous Linux. Je n’ai jamais regardé en arrière. J’ai aussi assisté à une conférence sur Linux où j’ai rencontré quelques hackers de Yahoo ; écouter leurs conférences m’a beaucoup inspiré. Quelques années plus tard, j’ai eu la chance de rencontrer Richard Stallman qui est une sorte de dieu pour beaucoup de gens dans la communauté du logiciel libre.

Je dois reconnaître que la documentation d’Eric S. Raymond a changé ma vie et sûrement celle de beaucoup d’autres. Après toutes ces années passées dans la communauté du logiciel libre, je me suis rendu compte que la documentation est la clé pour amener des débutants à participer à cette extraordinaire communauté open source. Mon conseil à deux balles à tous les développeurs serait : s’il vous plaît, documentez votre travail, même le plus petit, car le monde est plein de débutants qui aimeraient le comprendre. Mon blog propose un large éventail de publications, qui vont des plus simples comme l’activation de la vérification orthographique dans OpenOffice à celles, plus complexes, traitant de l’installation de Django dans un environnement virtuel.

[1] NdT : Un hacker sait où et comment bidouiller un programme pour effectuer des tâches autres que celles prévues par ses concepteurs alors qu’un cracker est un pirate informatique spécialisé dans le cassage des protections dites de sécurité.

Source : Il ne faut plus dire ”hashtag” mais « mot-dièse » (Numerama)

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

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

Traduction Framalang : lamessen, Sky, Kalupa, ga3lig, Wxcafe, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, peupleLa, Julius22

La Voie des tests conduit à la Lumière

Jonathan “Duke” Leto

Jonathan Leto, dit « Le Duc » est un développeur de logiciel, un mathématicien dont les travaux sont publiés, un ninja de Git et un passionné de cyclisme qui vit à Portland, en Oregon. C’est l’un des développeurs principaux de la machine virtuelle Parrot et le fondateur de Leto Labs LLC.

Lorsque j’ai commencé à m’impliquer dans le logiciel libre et open source, je n’avais aucune idée de ce que pouvaient être les tests ni de leur importance. J’avais travaillé sur des projets personnels de programmation auparavant, mais la première fois que j’ai réellement travaillé sur un projet collaboratif (c’est-à-dire en faisant un peu de commit) c’était pour Yacas, acronyme de Yet Another Computer Algebra System, (NdT : encore un autre logiciel de calcul algébrique similaire à Mathematica).

À ce stade de mon parcours, les tests ne venaient qu’après coup. Mon méta-algorithme général était : bidouiller du code > voir si ça fonctionne> écrire (éventuellement) un test simple pour démontrer que ça fonctionne. Un test difficile à écrire n’était généralement jamais écrit.

C’est le premier pas sur la voie qui mène à la Lumière grâce aux tests. Vous savez que les tests sont probablement une bonne idée, mais vous n’en avez pas vu clairement les bénéfices, alors vous vous contentez de les écrire de temps en temps.

Si je pouvais ouvrir un trou de souris dans l’espace-temps et donner à mon moi plus jeune un conseil plein de sagesse sur les tests, ce serait :

« Certains tests sont plus importants, sur le long terme, que le code qu’ils testent. »

Il y a sans doute quelques personnes qui pensent en ce moment même que je mets mon casque de protection psychique (NdT : il s’agit d’un chapeau pour se protéger contre la manipulation à distance du cerveau) quand je m’assois pour écrire du code. Comment les tests pourraient-ils être plus importants que le code qu’ils testent ? Les tests sont la preuve que votre code marche réellement ; ils vous montrent le chemin vers l’écriture d’un code propre et vous apportent aussi la souplesse qui vous permettra de modifier le code tout en sachant que les fonctionnalités seront toujours là. En effet, plus votre code source grossit, plus vos tests sont importants, car ils vous permettent de changer une partie dudit code en sachant que le reste fonctionnera.

Une autre raison essentielle qui justifie l’écriture de tests est la possibilité de spécifier que quelque chose est un souhait explicite et non une conséquence imprévue ou un oubli. Si vous avez un cahier des charges, vous pouvez utiliser des tests pour vérifier qu’il est respecté, ce qui est très important, voire indispensable dans certaines industries. Un test, c’est comme quand on raconte une histoire : l’histoire de votre conception du code et de la façon dont il devrait fonctionner. Soit le code change et évolue, soit il mute en code infectieux (1).

Très souvent, vous écrirez des tests une première fois pour ensuite remettre totalement en cause votre réalisation voire la réécrire à partir de zéro. Les tests survivent souvent au code pour lesquels ils ont été conçus à l’origine. Par exemple, un jeu de tests peut être utilisé quel que soit le nombre de fois où votre code est transformé. Les tests sont en fait l’examen de passage qui vous permettra de jeter une ancienne réalisation et de dire « cette nouvelle version a une bien meilleure structure et passe notre jeu de tests ». J’ai vu cela se produire bien des fois dans les communautés Perl et Parrot, où vous pouvez souvent me voir traîner. Les tests vous permettent de changer les choses rapidement et de savoir si quelque chose est cassé. Ils sont comme des propulseurs pour les développeurs.

Les charpentiers ont un adage qui dit quelque chose comme ça :

« Mesurer deux fois, couper une fois. »

Le code serait la coupe, le test serait la mesure.

La méthode de développement basée sur les tests fait économiser beaucoup de temps, parce qu’au lieu de vous prendre la tête à bricoler le code sans but défini, les tests précisent votre objectif.

Les tests sont aussi un très bon retour d’expérience. Chaque fois que vous faites une nouvelle passe de test, vous savez que votre code s’améliore et qu’il a une fonctionnalité de plus ou un bogue de moins.

Il est facile de se dire « je veux ajouter 50 fonctionnalités » et de passer toute la journée à bricoler le code tout en jonglant en permanence entre différents travaux. La plupart du temps, peu de choses aboutiront. La méthode de développement basée sur les tests aide à se concentrer sur la réussite d’un seul test à la fois.

Si votre code échoue devant ne serait-ce qu’un seul test, vous avez pour mission de le faire réussir. Votre cerveau se concentre alors sur quelque chose de très spécifique, et dans la plupart des cas cela produit de meilleurs résultats que passer constamment d’une tâche à une autre.

La plupart des informations relatives au développement basé sur les tests sont très spécifiques à un langage ou à une situation, mais ce n’est pas une obligation. Voilà comment aborder l’ajout d’une nouvelle fonctionnalité ou la correction d’un bogue dans n’importe quel langage :

1. Écrivez un test qui fait échouer votre code, mais qui, selon vous, sera passé quand la fonctionnalité sera implémentée ou que le bogue sera corrigé. Mode expert : pendant l’écriture du test, pensez à l’exécuter de temps en temps, même s’il n’est pas encore fini, et tentez de deviner le message d’erreur effectif que le test renverra. À force d’écrire des tests et de les faire tourner, cela devient plus facile ;
2. Bidouillez le code ;
3. Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
4. C’est fini ! Dansez le sirtaki.

Cette méthode fonctionne pour n’importe quel type de test et n’importe quel langage. Si vous ne deviez retenir qu’une seule chose de ce texte, souvenez-vous des étapes ci-dessus.

Voici maintenant quelques directives plus générales de conduite de tests qui vous serviront bien et fonctionneront dans n’importe quelle situation :

1. Comprendre la différence entre ce qu’on teste et ce qu’on utilise comme un outil pour tester autre chose ;
2. Les tests sont fragiles. Vous pouvez toujours écrire un test qui contrôle la validité d’un message d’erreur. Mais que se passera-t-il si le message d’erreur change ? Que se passera-t-il quand quelqu’un traduira votre code en catalan ? Que se passera-t-il lorsque quelqu’un exécutera votre code sur un système d’exploitation dont vous n’avez jamais entendu parler ? Plus votre test est résistant, plus il aura de valeur.

Pensez à cela quand vous écrivez des tests. Vous voulez qu’ils soient résistants, c’est-à-dire que les tests, dans la plupart des cas, ne devraient avoir à changer que quand les fonctionnalités changent. Si vous devez modifier vos tests régulièrement, sans que les fonctionnalités aient changé, c’est que vous faites une erreur quelque part.

Types de tests

Bien des personnes sont perdues quand on leur parle de tests d’intégration, tests unitaires, tests d’acceptation et autres tests à toutes les sauces. Il ne faut pas trop se soucier de ces termes. Plus vous écrirez de tests, mieux vous en distinguerez les nuances et les différences entre les tests deviendront plus apparentes. Tout le monde n’a pas la même définition de ce que sont les tests, mais c’est utile d’avoir des termes pour décrire les types de tests.

Tests unitaires contre tests d’intégration

Les tests unitaires et les tests d’intégration couvrent un large spectre. Les tests unitaires testent de petits segments de code et les tests d’intégration vérifient comment ces segments se combinent. Il revient à l’auteur du test de décider ce que comprend une unité, mais c’est le plus souvent au niveau d’une fonction ou d’une méthode, même si certains langages appellent ces choses différemment.

Pour rendre cela un peu plus concret, nous établirons une analogie sommaire en utilisant des fonctions. Imaginez que f(x) et g(x) soient deux fonctions qui représentent deux unités de code. Pour l’aspect concret, supposons qu’elles représentent deux fonctions spécifiques du code de base de votre projet libre et open source.

Un test d’intégration affirme quelque chose comme la composition de la fonction, par exemple f(g(a)) = b. Un test d’intégration consiste à tester la façon dont plusieurs choses s’intègrent ou travaillent ensemble, plutôt que la façon dont chaque partie fonctionne individuellement. Si l’algèbre n’est pas votre truc, une autre façon de comprendre est de considérer que les tests unitaires ne testent qu’une partie de la machine à la fois, tandis que les tests d’intégration s’assurent que la plupart des parties fonctionnent à l’unisson. Un bel exemple de test d’intégration est le test de conduite d’une voiture. Vous ne vérifiez pas la pression atmosphérique, ni ne mesurez le voltage des bougies d’allumage. Vous vous assurez que le véhicule fonctionne globalement.

La plupart du temps, il est préférable d’avoir les deux. Je commence souvent avec les tests unitaires puis j’ajoute les tests d’intégration au besoin puisqu’on a besoin d’éliminer d’abord les bogues les plus basiques, puis de trouver les bogues plus subtils issus d’un emboitement imparfait des morceaux, à l’opposé de pièces qui ne fonctionnent pas individuellement. Beaucoup de gens écrivent d’abord des tests d’intégration puis se plongent dans les tests unitaires. Le plus important n’est pas de savoir lequel vous écrirez en premier, mais d’écrire les deux types de tests.

Vers la Lumière

La méthode de développement basée sur les tests est un chemin, pas un aboutissement. Sachez apprécier le voyage et assurez-vous de faire une pause pour respirer les fleurs si vous êtes égaré. 

(1) Équivalent approché du terme bitrot qui en argot de codeur désigne ce fait quasi-universel : si un bout de code ne change pas mais que tout repose sur lui, il « pourrit ». Il y a alors habituellement très peu de chances pour qu’il fonctionne tant qu’aucune modification ne sera apportée pour l’adapter à de nouveaux logiciels ou nouveaux matériels.

Comic strip réalisé avec le Face-O-Matic de Nina Paley et Margot Burns

Copyheart ? 2011 by Margo Burns and Nina Paley. Copying is an act of love. Please copy!

Nina Paley est une artiste étasunienne auteure de bandes dessinées et dessins animés, dont le célèbre Sita Sings The Blues. Elle a pris en grippe, depuis bien longtemps, le système du copyright de son pays. J’ai découvert ses œuvres grâce à @Calimaq dont le blog SILex  traite des problématiques du droit d’auteur. Et depuis longtemps le Framablog soutient ses choix militants et fait connaître ses œuvres.

Hier, @Calimaq m’envoie un lien vers l’article qui va suivre. Il sait que cela va me toucher : Nina parle ci-dessous de la licence CC0, annonçant l’élévation volontaire et par anticipation d’une œuvre dans le Domaine Public. J’aime tant la CC0 qu’elle pare chacune de mes œuvres <autopromo>dont mon premier roman #Smartarded, publié chez Framabook</autopromo>. Cette licence me permet de « couper le cordon » avec les histoires que j’écris. Leur enlever et la chaîne et le boulet qu’elles se traînaient pour rendre leur lectorat libre de se les approprier.

On le sait, les licences libres ne sont pas sans restrictions. Les trolls débats sur les entraves aux libertés qu’entraînent les clauses NC (condition de non commercialisation) et ND (condition de non modification) remplissent des forums entiers. Pourtant, peu de gens parlent de la contrainte que peut représenter la clause share alike, le fameux « SA » viral, imposant la licence choisie à toute nouvelle adaptation de l’œuvre.

Nina Paley nous livre ici son vécu, nous explique ce « vœu de non-violence légale » qui motive l’expérience qu’elle mène… et que je lui souhaite aussi heureuse que celle que je vis.

– Pouhiou

Article original sur le blog de Nina Paley

Traduction Framalang : nafnaf, ehsavoie, Chuckman, goofy, Pouhiou

Ahimsa : Sita Sings the Blues désormais en CC-0 « domaine public »

par Nina Paley

Par la présente, je déclare passer la licence de Sita Sing the Blues de CC-BY-SA (partage à l’identique) à CC-0.

Il y a quelques années j’ai entamé une démarche pour faire vœu de non-violence : un engagement de ne jamais poursuivre en justice qui que ce soit pour du savoir (ou de la culture, des œuvres culturelles, de l’art, de la propriété intellectuelle — ou le nom quelconque que vous préférez). Le copyright est désespérément détraqué ; bien sûr, le droit craque de partout aux USA. Mais pourquoi devrais-je recourir à cette même loi aberrante pour essayer de corriger les abus qu’elle introduit ? Nous vivons dans un univers chaotique. Les choix que j’effectue, bien que fondés sur des principes solides, n’y changeront rien. Les gens continueront à censurer, supprimer et verrouiller le savoir. La licence Share-Alike (partage à l’identique selon les mêmes conditions), nécessaire légalement pour conserver l’aspect libre du savoir, a eu pour conséquence d’en détruire la liberté

« Ne pas utiliser le savoir c’est lui faire injure »

a écrit Jeff Jarvis, dans une réflexion sur la mort d’Aaron Swartz.

J’ai appris la mort d’Aaron dimanche ; le lundi, le National Film Board of Canada (NdT : l’Office national du film du Canada) m’a demandé de remplir des formulaires pour « autoriser » le réalisateur (et ami personnel) Chris Landreth à faire référence à Sita Sings the Blues dans son court-métrage à venir, Subconscious Password, même si le Fair Use libérait le NFB de toute peur légitime des propriétés virales du Share-Alike. Je fais des compromis avec mes principes tous les jours, mais ce lundi-là je ne pouvais absolument pas. La bêtise des avocats du NFB était du même acabit que celle qu’Aaron combattait en libérant les documents du JSTOR. Je ne supportais pas l’idée de permettre d’avoir encore plus de mauvais avocats, de mauvaises décisions, de saloperie de copyright, en remplissant gratuitement des formulaires pour un système stupide et corrompu. Je ne pouvais tout simplement plus le faire.

Donc la NFB a dit à Chris d’enlever toute référence faite à SSTB dans son film.

Se lever pour défendre ses principes a des conséquences. Les gens vous critiquent, vous craignent et ont pitié de vous. Les condamnations publiques pleuvent. Vous perdez de l’argent. Parfois on vous poursuit en justice et, bien que cela ne me soit pas encore arrivé, cela pourrait venir vu ma pratique grandissante de la désobéissance civile.

Ma création artistique est illégale ! — Bouge pas, je vais réformer la loi !

(Commentaire de Nina Paley : Les vrais artistes n’attendent pas que les juges et les lois les autorisent)

Ce n’est pas moi mais bien mon travail, qui est la vraie victime de mes prises de positions. Quand j’ai refusé par principe les DRM (verrous limitant l’utilisation d’œuvres numériques afin de limiter les copies) de Netflix, le résultat fut que moins de gens ont vu SSTB. Quand de nombreuses chaînes de télévision me demandaient les droits de SSTB et que je leur répondais qu’ils les avaient déjà, le résultat fut qu’ils ne le diffusèrent pas. Quand des éditeurs ont voulu adapter SSTB en livre, la licence Share-Alike fut une cause de rupture des négociations, et il n’y eut pas de livre SSTB.

Ne pas utiliser le savoir, c’est lui faire injure.

Donc, chers NFB et Netflix, chers éditeurs et patrons de chaînes, chers vous qui formez cette putain de légion d’avocats : Sita Sings the Blues est désormais dans le Domaine Public. Désormais, vous n’avez plus aucune excuse pour entraver sa diffusion.

Est-ce que je continuerai de me battre ? Oui. MAIS PLUS PAR LA LOI. Je crois toujours aux raisons qui motivent la BY-SA mais la vérité c’est que jamais, au grand jamais, je ne poursuivrai quiconque en justice pour SSTB ou une autre œuvre culturelle. Je continuerai à condamner publiquement des abus tels que le verrouillage et la mauvaise attribution volontaire… Mais quelle utilité de menacer le monde d’une arme chargée si l’on ne s’en sert pas ? La licence CC-0 (NdT : versement volontaire et par anticipation dans le Domaine Public) est l’affirmation que jamais je ne serai procédurière contre qui que ce soit, peu importent les abus et la malfaisance.

Pour moi, la CC-0 est ce qu’il y a de plus proche d’un vœu de non-violence légale. La loi est un âne que je refuse de monter.

Je ne peux pas abolir le mal. La Loi ne peut abolir le mal, au contraire, elle le perpétue et l’amplifie. Les gens continueront à censurer, faire taire, menacer et maltraiter le savoir, et ce désastreux morcellement qu’est la propriété intellectuelle continuera d’encourager de telles choses. Mais je me refuse, pour combattre des monstres, à en devenir un ou à nourrir le monstre que je combats.

Ni la CC-BY-SA ni la CC-0 ne sont la solution à notre monde à la dérive avec son régime de copyright parfaitement détraqué.

Ce que je peux dire c’est que SSTB a été sous licence CC-BY-SA durant les 4 dernières années, donc je connais bien le sujet et je peux partager les résultats de cette expérience. En avançant sous la licence CC-0 j’apprendrai de nouvelles choses et j’aurai de nouveaux résultats à partager. Cela ressemble à une victoire même si de mauvais scénarios peuvent entrer en jeu. Honnêtement je n’ai pas été capable de déterminer quelle licence Libre est la « meilleure », et passer sous licence CC-0 peut contribuer à apporter une réponse.

Crédit photo : ouest-communications (CC BY-NC-ND 2.0)

Goofy et ses complices ont dédié cet article au domaine public en renonçant dans le monde entier à leurs droits selon les lois sur le droit d’auteur, droit voisin et connexes, dans la mesure permise par la loi.

Ugh.

L’association COMMUNIA, l’Open Knowledge Foundation France, La Quadrature du Net, Framasoft, Regards Citoyens, Veni Vidi Libri, le Parti Pirate, Libre Accès et SavoirsCom1 publient ce jour un communiqué dénonçant la signature par la BNF, le Commissariat aux investissements d’avenir et le ministère de la Culture et de la communication d’accords qui privatisent l’accès numérique à une part importante de notre patrimoine culturel.

Paris, le 18 janvier 2013 — Le ministère de la Culture a annoncé hier la conclusion de deux accords, signés entre la Bibliothèque nationale de France et des firmes privées, pour la numérisation de corpus de documents appartenant pour tout (livres anciens) ou partie (78 et 33 tours) au domaine public. Les fonds concernés sont considérables : 70 000 livres anciens français datant de 1470 à 1700, ainsi que plus de 200 000 enregistrements sonores patrimoniaux. Ces accords, qui interviennent dans le cadre des Investissements d’avenir et mobilisent donc de l’argent public, vont avoir pour effet que ces documents ne seront pas diffusés en ligne, mais uniquement sur place à la BnF, sauf pour une proportion symbolique.

Ces partenariats prévoient une exclusivité de 10 ans accordée à ces firmes privées, pour commercialiser ces corpus sous forme de base de données, à l’issue de laquelle ils seront mis en ligne dans Gallica, la bibliothèque numérique de la BnF. Les principaux acheteurs des licences d’accès à ces contenus seront des organismes publics de recherche ou des bibliothèques universitaires, situation absurde dans laquelle les acteurs du service public se retrouveront contraints et forcés, faute d’alternative à acheter des contenus numérisés qui font partie du patrimoine culturel commun.

Les conditions d’accès à ces éléments de patrimoine du domaine public seront restreintes d’une façon inadmissible par rapport aux possibilités ouvertes par la numérisation. Seule la minorité de ceux qui pourront faire le déplacement à Paris et accéder à la BnF seront en mesure de consulter ces documents, ce qui annule le principal avantage de la révolution numérique, à savoir la transmission à distance. Partout enFrance et dans le monde, ce sont les chercheurs, les étudiants, les enseignants, les élèves, les amateurs de culture, les citoyens qui se trouveront privés de l’accès libre et gratuit à ce patrimoine.

La valeur du domaine public réside dans la diffusion de la connaissance qu’il permet et dans la capacité à créer de nouvelles œuvres à partir de notre héritage culturel. Sa privatisation constitue une atteinte même à la notion de domaine public qui porte atteinte aux droits de chacun. Ces pratiques ont été condamnées sans ambiguïté par le Manifeste du domaine public, rédigé et publié par le réseau européen COMMUNIA financé par la Commission européenne :

Toute tentative infondée ou trompeuse de s’approprier des œuvres du domaine public doit être punie légalement. De façon à préserver l’intégrité du domaine public et protéger ses usagers de prétentions infondées ou trompeuses, les tentatives d’appropriation exclusive des œuvres du domaine public doivent être déclarées illégales.

Les institutions patrimoniales doivent assumer un rôle spécifique dans l’identification efficace et la préservation des œuvres du domaine public. (…) Dans le cadre de ce rôle, elles doivent garantir que les œuvres du domaine public sont accessibles à toute la société en les étiquetant, en les préservant et en les rendant librement accessibles.

À titre de comparaison, les partenariats validés par le ministère de la Culture aboutissent à un résultat encore plus restrictif pour l’accès à la connaissance que celui mis en œuvre par Google dans son programme Google Livres, dans lequel les ouvrages restent accessibles gratuitement en ligne sur le site des institutions partenaires. La mobilisation de l’emprunt national n’aura donc en aucun cas permis de trouver une alternative acceptable aux propositions du moteur de recherche.

Le ministère de la Culture affirme dans son communiqué que ces partenariats sont compatibles avec les recommandations du Comité des sages européens « A New Renaissance ». C’est à l’évidence faux, le rapport du Comité des sages admettant que des exclusivités commerciales puissent être concédées à des firmes privées pour 7 ans au maximum, mais insistant sur la nécessité que les documents du domaine public restent accessibles gratuitement en ligne, y compris dans un cadre transfrontalier. Plus encore, les accords sont en flagrante contradiction avec la Charte Europeana du Domaine Public (pdf) alors même que l’un de ses signataires occupe aujourd’hui la présidence de la fondation Europeana.

Par ailleurs, le rapport du Comité des sages énonce comme première recommandation que les partenariats public-privé de numérisation soient rendus publics afin de garantir la transparence, ce qui n’est pas été fait ici. L’opacité a régné de bout en bout sur la conclusion de ces partenariats, au point qu’une question parlementaire posée au ministère de la Culture par le député Marcel Rogemont est restée sans réponse depuis le 23 octobre 2012, alors même qu’elle soulevait le problème de l’atteinte à l’intégrité du domaine public. Enfin, les partenariats publics-privés ont été récemment dénoncés par l’Inspection générale des finances dans un rapport commandé par le ministre de l’Économie, Pierre Moscovici, et par celui du Budget, Jérôme Cahuzac. Ces partenariats sont jugés trop onéreux, trop risqués, trop complexes et trop profitables aux seuls intérêts privés.

Nous, associations et collectifs signataires de cette déclaration, attachés à la valeur du domaine public et à sa préservation comme bien commun, exprimons notre plus profond désaccord à propos de la conclusion de ces partenariats et en demandons le retrait sans délai. Nous appelons toutes les structures et personnes partageant ces valeurs à nous rejoindre dans cette opposition et à manifester leur désapprobation auprès des autorités responsables : BnF, Commissariat général à l’investissement et ministère de la Culture. Nous demandons également la publication immédiate du texte intégral des accords.

Contacts presse

• L’association internationale COMMUNIA L’association a pour mission d’éduquer sur l’importance du domaine public numérique, de le défendre auprès des institutions, et de constituer une source d’expertise et de recherche en la matière. Elle a succédé au Réseau thématique COMMUNIA actif sur les mêmes sujets et financé par la Commission européenne. Contact : info@communia-association.org

• L’Open Knowledge Foundation France L’Open Knowlegde Foundation (OKFN) est une organisation à but non lucratif fondée en 2004 à Cambridge qui promeut la culture libre sous toutes ses formes. Ses membres considèrent qu’un accès ouvert aux informations associé aux outils et aux communautés pour les utiliser sont des éléments essentiels pour améliorer notre gouvernance, notre recherche, notre économie et notre culture.

• La Quadrature du Net La Quadrature du Net est une organisation de défense des droits et libertés des citoyens sur Internet. À ce titre, la Quadrature du Net intervient notamment dans les débats concernant la liberté d’expression, le droit d’auteur, la régulation du secteur des télécommunications ou encore le respect de la vie privée. Contact : Philippe Aigrain, co-fondateur et conseiller stratégique pa@laquadrature.net +33 6 85 80 19 31

• Framasoft Réseau d’education populaire au Libre en général et au logiciel libre en particulier. Contact : Alexis Kauffmann, fondateur de Framasoft

• Regards Citoyens est un collectif transpartisan qui vise à utiliser un maximum de données publiques pour alimenter le débat politique tout en appliquant les principes de la gouvernance ouverte. En plus de faire la promotion de l’OpenData et l’OpenGov en France, il réalise des projets web n’utilisant que des logiciels libres et des données publiques pour faire découvrir et valoriser les institutions démocratiques françaises auprès du plus grand nombre.

• Le Parti Pirate est un mouvement politique ralliant celles et ceux qui aspirent à une société capable de : partager fraternellement les savoirs culturels et scientifiques de l’humanité, protéger l’égalité des droits des citoyens grâce des institutions humaines et transparentes, défendre les libertés fondamentales sur Internet comme dans la vie quotidienne.

• Veni, Vidi, Libri a pour objectif de promouvoir les licences libres ainsi que de faciliter le passage de créations sous licence libre.

• Libre Accès a pour objet de sensibiliser le plus grand nombre aux enjeux de l’art libre et de défendre les droits de ses amateurs et auteurs.

• SavoirsCom1 est un collectif qui s’intéresse aux politiques des biens communs de la connaissance. SavoirsCom1 défend les positions exprimées dans son Manifeste. Contact : savoirscom1@gmail.com

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

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

Traduction Framalang : 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

C’est un Geektionnerd très spécial que nous propose Gee cette semaine (cliquez sur l’image pour l’agrandir).

Vous pouvez également lire les traductions de quelques uns de ses articles que nous avons publié cette semaine, ainsi que ce Manifeste Hacker qui lui va si bien.

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