Le témoignage d’un développeur qui considère qu’à partir du moment où vous vivez bien il est moralement important de rendre à la communauté un peu de ce qu’elle vous a donnée.

L’open source, une responsabilité civique

Open Source as a Civic Duty

Jeremy Kahn – 13 juillet 2013 – Blog personnel
(Traduction : Asta, r0u, aKa, GregR, regularuser, Tentate, dig, Fol, Maijin + anonymes)

On me demande parfois la raison pour laquelle je passe autant de mon temps libre à écrire des logiciels et à les mettre à disposition librement et gratuitement. Il y a un certain nombre de raisons à cela. J’aime construire des choses et cela me sert de prétexte pour pratiquer et m’améliorer, mais une de mes principales motivations est que je vois dans les contributions open source un devoir civique, une obligation morale envers le reste du monde.

Étant donné que je suis un programmeur actif travaillant dans la Silicon Valley, et qu’on me considère généralement comme pas trop incompétent, vous vous doutez bien que je ne me soucie pas trop de comment j’arriverai à payer mon prochain repas. Je ne suis pas « riche », mais j’ai un style de vie plutôt confortable, et c’est tout ce que j’ai toujours voulu. Après tout, un programmeur a-t-il besoin d’autre chose qu’un ordinateur portable et d’une tasse de café pour être heureux ? Ceci étant, je n’ai pas à m’inquiéter de savoir si je vais avoir, ou non, un endroit pour vivre et à manger le mois prochain, je suis parmi les gens les plus heureux du monde. Et si vous avez toute la technologie nécessaire à la lecture de cet article, vous l’êtes sûrement tout autant.

La morale est un sujet sensible qui dépend des individus et de leurs cultures, et ce texte ne suggère pas que ma conception de la moralité soit nécessairement correcte. Cependant, je pense que les gens assez chanceux pour parvenir à vivre par leurs propres moyens ont une obligation de rendre quelque chose à leur communauté. Je crois qu’un certain niveau de sacrifice personnel et de devoir civique est nécessaire afin de bâtir et de maintenir un collectif au sein duquel nous souhaitons tous vivre. Cela peut prendre plusieurs formes, des dons, du travail bénévole ou, dans mon cas, la conception et le développement de logiciels libres. La manière dont vous tentez de contribuer à la communauté n’est pas vraiment importante, ce qui compte est que vous le fassiez.

Bien sûr, je ne code pas des logiciels qui permettront de fournir de l’eau à des pays pauvres en Afrique ou à soigner la malaria. Je me focalise plutôt sur des outils d’animations pour le Web et d’autres utilitaires pour les interfaces utilisateurs. Cependant, je travaille dessus afin que d’autres n’aient pas à le faire. Mon but à mon niveau est de faire gagner du temps à d’autres personnes, et leur permettre de résoudre des problèmes qui n’ont pas encore de solutions. Pour prendre un exemple significatif, considérons le projet GNU. Au final, GNU a permis de faire gagner à l’humanité des siècles en temps de travail. De nos jours, on ne passe plus beaucoup de temps à développer des systèmes d’exploitation et autres outils basiques, car c’est une tâche quasiment résolue. À la place nous utilisons des outils GNU que d’autres ont laborieusement développé, nous permettant alors ainsi de poursuivre et nous concentrer vers d’autres défis comme la modélisation statistique ou la lutte contre le SIDA. Si vous avez des doutes sur l’intérêt du logiciel libre, il vous suffit de regarder le projet GNU.

L’altruisme n’est malheureusement pas très répandu dans la Silicon Valley. Au mieux, les grandes firmes ont une division s’occupant de responsabilité sociale et environnementale, et les plus petites organisent une collecte de fonds à but solidaire de temps en temps. Mais il semble qu’une grande partie des entreprises technologiques de la Silicon Valley se concentrent sur une vision autocentrée et des problèmes « de niche », spécifiques à leur fondateur et à ses amis. Je ne veux pas d’une culture dans laquelle les seuls problèmes résolus sont ceux que les techniciens rencontrent. Je pense que l’écriture de logiciels libres sur mon temps personnel est un petit pas dans la bonne direction, même indirect. Mon rêve est qu’un jour, un outil libre que j’aurai écrit soit utilisé à des fins vraiment utiles. N’importe qui peut accomplir cela, ça ne requiert que peu de temps ou d’argent — seulement de prendre un peu de recul.

Crédit photo : David Orban (Creative Commons By)

Imaginez-vous partir en avion dans un autre pays en ayant emporté dans votre valise quelques livres à lire lors de votre séjour. Vous arrivez à destination, récupérez votre valise sur le tapis de roulant de l’aéroport, l’ouvrez pour vérifier son contenu et là surprise : tous vos livres ont purement et simplement disparu par l’opération du Saint-Esprit !

C’est c’est qui arrivé récemment à un bibliothécaire américain, à ceci près que les livres en question étaient électroniques et qu’ils avaient été achetés sur Google Play qui ne semble pas effectif à Singapour !

La conclusion s’impose d’elle-même mais nous ne vous ferons pas l’injure de l’expliciter 😉

DRM en folie

DRM follies

Jim O’Donnell – 15 août 2013 – Liste Liblicense
(Traduction : ProgVal, maximem, Slystone, Mathieu, Solarus, Feadurn, LordPhoenix, Kéviin, lamessen, Mogmi + anonymes)

Je suis à Singapour pour assister aux réunions de l’IFLA (Fédération Internationale des Associations de Bibliothécaires et des Bibliothèques). C’est un long voyage, mais j’ai pris la décision courageuse et audacieuse de ne dépendre que de mon iPad pour toutes mes lectures durant ce séjour, à partir des applications Kindle, iBooks, et « Google Play » (connu auparavant sous le nom de Google Books). Un simple petit exemplaire de sonnets de Shakespeare m’accompagne en version papier, pour que je puisse lire quelque chose pendant la période d’extinction des appareils électroniques à bord de l’avion.

Donc quand je suis arrivé, j’ai remarqué que plusieurs des applications de mon iPad pouvaient être mises à jour, j’ai donc cliqué et accepté. L’une d’elles était Google Play. Quand ce fut terminé et que j’ouvris l’application, elle m’annonça qu’il fallait mettre à jour les livres et que cela pourrait prendre quelques minutes. Le temps passa, et l’écran se remplit des couvertures des 30 ou 40 œuvres que je garde sur mon appareil. Deux d’entre elles étaient des livres que je lis beaucoup pour les cours que je donnerai cet automne.

Mais tous mes livres avaient disparu et devaient être à nouveau téléchargés L’application est un outil de téléchargement défaillant, presque aussi mauvaise que celui du New Yorker. Je le redoutais, mais j’ai cliqué sur les deux dont j’avais le plus besoin à cet instant. (J’ai vérifié la quantité d’espace de stockage utilisée, et effectivement, les fichiers avaient bel et bien disparu de ma tablette.)

Et le téléchargement n’aboutissait jamais. Il s’avère que, parce que je ne suis pas dans un pays où Google Books est une entreprise reconnue (ce qui englobe la plupart des pays sur la planète), je ne peux pas télécharger mes livres électroniques. Le peu de connaissances que j’ai en informatique me permettent de supposer que la suppression a eu lieu lorsque, à l’occasion de la mise à jour automatique, le système a détecté que j’étais en dehors des États-Unis, et a donc réagi.

Une fois n’est pas coutume, Google a une assistance pour Google Play disponible par courriel, mais une succession d’échanges a démontré que les droïdes de l’Android Market n’étaient ni en mesure de comprendre mon problème, ni de faire preuve d’empathie, ni de proposer une solution. Je dois nécessairement retourner aux États-Unis pour être autorisé à passer quelques heures à re-télécharger « mes » livres avant de pouvoir les lire à nouveau. À un moment on m’a demandé quelle fonctionnalité je pourrais suggérer d’ajouter à Google Play. J’ai suggéré « Don’t Be Evil » (NdT « Ne soyez pas malveillant », le fameux slogan de Google), mais je n’ai eu aucune réponse.

Heureusement, archive.org hébergeait une version scannée, et non produite par Google, du livre du XIXe siècle dont j’avais le plus besoin. Je l’ai téléchargée sans problème et je peux la lire dans l’app GoodReader, qui ne semble pas se préoccuper de savoir dans quel pays je me trouve.

Crédit photo : Melenita2012 (Creative Commons By)

Déjà 20 ans pour Debian, l’une des plus célèbres et emblématiques distributions GNU/Linux. En effet, en août 1993 est sorti la très modeste version 0.01.

L’occasion pour nous de lui rendre hommage en traduisant ces quelques vibrants témoignages.

Bon 20e anniversaire Debian

Happy 20th birthday Debian

Ana Guerrero Lopez et Francesca Ciceri – 16 août 2013 – Bits from Debian
(Traduction : Gaetanm, Se7h, ProgVal, Jeff_, Kéviin, Asta + anonymes)

Aujourd’hui, c’est le vingtième anniversaire de Debian. Cet anniversaire aurait été impossible sans la forte communauté d’utilisateurs et de développeurs. C’est pourquoi, pour fêter cet anniversaire, nous avons demandé à la communauté Debian ce que Debian signifie, pour elle. Voici une sélection des réponses.

— Depuis que j’utilise Debian sur mes ordinateurs, je ne joue plus aux jeux de guerre en 3D, et ce non parce que il n’y a pas de drivers 3D libres, mais parce que développer Debian est bien plus fun et addictif.

— Debian est une vraie distribution basée sur la communauté et dévouée à la cause des logiciels libres et aux standards. Elle marche parfaitement sur une large gamme de matériel. Des utilisatrices et utilisateurs du monde entier ont utilisé et contribué à Debian depuis 20 ans. Et je suis fier d’être l’un d’eux. Bon anniversaire, Debian !

— Quand je me suis posé la question de passer à Linux, j’ai demandé à des connaissances quelle distribution choisir. Elles m’ont dit de laisser les distributions pour débutants et de passer directement à Debian. « Ça sera peut-être plus difficile au début, mais ça t’évitera de devoir t’habituer à Debian plus tard, vu que ce sera sans doute un passage obligé » m’ont-elles dit. Preuve en est-il qu’elles avaient raison ! J’ai commencé sous Linux il y a plus de 10 ans avec Debian, et je vois que c’est encore la meilleure distribution.

— Vous êtes une communauté mondiale de volontaires travaillant ensemble depuis 20 ans maintenant. Pour moi c’est un exemple encourangeant, compte tenu de l’état déplorable du monde dans lequel nous vivons, plus important que la qualité technique du système d’exploitation. J’espère que les 20 prochaines années seront aussi bénéfiques, et que vous resterez aussi indépendant que vous l’êtes.

— J’ai commencé au début avec Debian car c’était un challenge technique intéressant. Au fil des annés, la communauté et le fait d’avoir de bons standards sur ce qui constitue le Logiciel Libre sont devenus plus importants.

— En tant qu’utilisateur Debian depuis 14 ans, et un ex-développeur depuis 10, j’aimerais souhaiter un joyeux anniversaire au meilleur projet d’Internet, et à la meilleure distribution. Merci pour toute votre aide au cours de ces années !

— « Fiabilité à toute épreuve, stabilité et liberté absolue ». C’est ce que Debian signifie à mes yeux.

— Debian me donne l’impression que j’utilise le meilleur de ce que Linux a à offrir. Vous savez que votre machine est entre de bonnes mains.

— En tant qu’utilisateur Debian depuis longtemps et parfois supporters … je souhaite à Debian le meilleur pour les 20 prochaines années et au-delà !

— Debian est le système d’exploitation universel. Et il est libre

— Debian est l’incroyable combinaison de l’obsession du logiciel de grande qualité et de la liberté du logiciel. C’est un plaisir de pouvoir utiliser et contribuer à ce projet. Merci pour leur excellent travail ! À dans 2**20 ans de plus !

— Je suis extrêmement reconnaissant envers tous les gens qui ont contribué et qui continuent de le faire à un écosystème d’outils génial. J’adore cet engagement en termes de sécurité, de liberté et de transparence avec le respect des systèmes informatiques que nous utilisons tous et auquels nous faisons confiance pour conserver les données que nous y mettons.

— Debian est le système d’exploitation qui m’a libéré.

— Debian est une famille réunie autour d’une grande idée. C’est du pur amour.

The Pirate Bay fête ses dix ans d’âge cette année.

L’occasion pour Rick Falkvinge (souvent traduit par le Framablog) d’en faire un petit bilan et perspectives…

La décennie Pirate Bay : combattre la censure, les monopoles du copyright octet par octet

Pirate Bay decade: Fighting censorship, copyright monopolies bit by bit

Rick Falkvinge – 16 août 2013 – RT
(Traduction Framalang : Slystone, gaetanm, Alain_111, maximem, greygjhart, Asta, lamessen, FF255, angezanetti, @zKooky, Genma + anonymes)

Pendant 10 ans, The Pirate Bay a fait apparaître clairement qu’aucune loi dans le monde ne peut couper un service Internet voulu par des centaines de millions de personnes. Il continuera à se décentraliser pour se protéger des assauts légaux, affirme ici le fondateur du Parti Pirate suédois Rick Falkvinge.

Le phénomène de partage de la culture et du savoir semble osciller entre des cycles de décentralisation et de centralisation. The Pirate Bay est apparu sans tambour ni trompette il y a 10 ans en 2003. À cette époque, BitTorrent n’était pas du tout la technologie privilégiée pour le partage, et le groupe de réflexion suédois appellé The Pirate Bureau voulut tester cette technologie, qui semblait prometteuse car décentralisée.

Alors que nous pourrions penser que le partage devrait être décentralisé par nature, il apparaît que c’est rarement le cas. Quand nous partagions culture et savoir pendant notre adolescence, cela se faisait sur cassettes audio. Les lecteurs de cassette de cette époque étaient d’ailleurs livrés avec deux emplacements à cassettes et un bouton copier A sur B, fournissant des fonctionnalités pour faciliter le partage de la culture et du savoir entre les gens.

Quand les ordinateurs sont arrivés, ils utilisaient également les cassettes pour stocker la culture, la connaissance et les programmes, ainsi le partage au sein de ce nouveau monde n’en était que plus facilité.

Autour des années 90, les modems sur ligne téléphonique devinrent populaires, et un pré-Internet composés de proto-sites BBS (Bulletin Board System) émergea. Plutôt que de se connecter au Net et d’être en ligne avec tout le monde en même temps, on connectait son ordinateur à un seul BBS via sa ligne téléphonique, et ces BBS partageaient ensuite les fichiers entre eux, les rendant de ce fait disponibles à tous leurs utilisateurs.

Comme c’était toujours plus pratique que de partager et copier des cassettes entre amis, le partage de culture et de connaissance via les BBS se répandit rapidement. Il y avait des dépôts centralisés d’où vous pouviez télécharger les tendances du moment, principalement des fichiers textes, des jeux et occasionnellement de la pornographie pixélisée en faible résolution (Un BBS avec un demi gigaoctet d’espace disque était énorme à cette époque).

Centralisé versus décentralisé

Faisons avance rapide pour arriver au temps du déploiement d’Internet en général, et de Napster en particulier. Quand les BBS avaient l’intégralité des catalogues sur leurs disques durs, le génie de Napster fut de connecter les disques durs des utilisateurs les uns aux autres plutôt que de tenter de tout rassembler de façon centralisée.

Le pari de Napster était que l’industrie de l’enregistrement du disque verrait les opportunités de profits, et ferait de Napster une partie de cette industrie. L’alternative serait de forcer le partage clandestin, d’encourager la décentralisation.

Comme le dit Cory Doctorow : « Copier devient toujours plus simple, partager ne sera jamais plus difficile que ça ne l’est à présent. »

Napster était aussi une merveille dans sa facilité d’utilisation. Vous tapiez le nom d’une chanson, vous l’écoutiez quasiment instantanément. On ne pouvait pas mieux faire. À toutes les conférences sur le peer-to-peer et l’architecture technique qui expliquait le succès de Napster, c’était la simplicité d’utilisation qui était la caractéristique principale et non sa technique sous-jacente.

Maintenant, comme nous le savons, l’industrie de la musique a choisi la folie plutôt que la raison (et continue de faire ainsi), en décidant de tuer Napster.

À ses débuts, un protocole relativement décentralisé appelé DirectConnect est apparu, qui donnait la possibilité à tout un chacun de déployer son propre clone de Napster. Mais les transferts étaient plutôt inefficaces – vous deviez trouver spécifiquement la personne qui avait le contenu que vous vouliez, et ensuite créer votre propre copie du fichier culturel partagé depuis les sources fournies par cette personne.

L’ère Pirate Bay : combattre la censure

La technologie BitTorrent, rendue très populaire par The Pirate Bay, a amélioré cela de deux manières.

Dans un premier temps, tout le monde transférait à tout le monde. Si vous cherchiez des sources pour produire votre propre copie de Game of Thrones et que 10.000 personnes partageaint ces sources, vous ne les obteniez pas à partir d’une seule personne, mais à partir de différents morceaux de milliers de personnes à la fois. Ce qui était bien plus efficace.

La seconde amélioration eut ceci de remarquable qu’elle n’était pas technique mais juridique. Des personnes avaient été mises en cause pour le partage de milliers de fichiers culturels, permettant aux autres d’avoir leurs propres copies pour leurs propres usages, mais il n’était pas possible de voir quelles autres sources partageait une personne, juste parce que l’on ne recevait d’elle qu’une partie de ses fichiers pour un élément spécifique. Cela ajoutait une protection significative contre des poursuites éventuelles pour avoir enfreint le monopole du copyright.

Mais la vraie percée de The Pirate Bay ne repose pas dans sa technologie, mais dans sa défense des droits civiques. Lorsqu’ils étaient persécutés par les avocats de l’industrie du copyright, les opérateurs de The Pirate Bay leurs ont répondu, et les gens les aimaient pour cela. Ils n’ont pas perdu leur temps à être poli non plus. « Allez vous faire foutre » était une une réponse très gentille à une une menace vide d’un point de vue légal. Une fois qu’ils ont publié toutes les menaces reçues et leur réponse en ligne, ils sont instantanément devenus les héros d’une génération du partage.

Ce qui est le plus intrigant est que les avocats de ces industries du copyright martèlent que les droits exclusifs (les monopoles) sont une « propriété », alors que ce n’est clairement pas le cas dans la loi. On pourrait penser que les avocats ne mentiraient pas à propos de ce que dit réellement la loi. Pourtant ils persistent à le faire, pour de simples questions de relations publiques : essayer de faire apparaître le monopole comme de la propriété alors qu’en réalité c’est un monopole qui limite les droits à la propriété.

L’industrie du copyright n’a pas perdu de temps dans sa lutte visant à censurer The Pirate Bay, en utilisant tous les prétextes, de la pornographie infantile (oui, ils ont constamment tenté d’associer la culture du partage libre avec le viol d’enfant) aux embargos à l’échelle mondiale.

Dans certains pays, l’industrie du copyright a réussi à introduire ce type de censure en théorie, mais des outils pour la contourner apparaissent alors presque instantanément. Ainsi, The Pirate Bay se présente comme le site BitTorrent le plus résistant du monde, une réputation durement gagnée et à laquelle le site a tous les droits de prétendre. Il a combattu la censure à peu près partout dans le monde, enseignant par là-même à la population comment éviter la censure gouvernementale.

Il est clair et évident que The Pirate Bay évolue peu. Du point de vue technique, il reste à peu près le même site qu’en 2006. Il faut remarquer que c’est le seul dans son genre au sein du top 100 mondial des sites.

Ce fait en dit aussi beaucoup sur la demande actuelle pour les services fournis. La condamnation des premiers opérateurs de The Pirate Bay en 2009 n’a évidement rien changé en ce qui concerne le site lui-même. Alors que le procès en tant que tel était une blague juridique commandée par correspondance depuis les États-Unis que le futur jugera très sévèrement, il n’a pas fait la moindre égratignure au partage.

Aucune loi ne peut l’arrêter

À l’heure actuelle, en 2013, il existe des cartes recensant les endroits où les gens se livrent le plus au partage de la culture et de la connaissance, en violation du monopole du copyright. Les États-Unis sont systématiquement en dessous de la moyenne sur ces cartes, mais il n’y a pas de quoi se vanter : en comparant les cartes du partage à celles de la bande-passante domestique, on s’aperçoit qu’elles sont très fortement corrélées.

Ainsi, le fait que les gens résidant aux États-Unis partagent moins que leurs collègues européens ou asiatiques n’a rien à voir avec leur respect des monopoles qui faussent le marché : s’ils partagent moins, les causes réelles en sont les infrastructures gravement sous-développées et lentes présentes aux États-Unis.

Cet article a débuté avec une étude de l’opposition entre la centralisation et la décentralisation. Cela aurait tout aussi bien pu être une étude de la confrontation entre la communauté de la justice et celle des entrepreneurs techniques. Là où les juristes attaquent la technologie, cette dernière répond par la décentralisation, devenant de ce fait résistante aux attaques.

Une décennie avec The Pirate Bay a rendu quatre choses limpides quant aux prévisions pour le futur.

La première est que The Pirate Bay a montré qu’aucune loi existante ne peut arrêter un service voulu par des centaines de millions de personnes ; la seconde est que la censure gouvernementale est aussi détestée universellement qu’elle est facilement détournée ; la troisième est que les services continuent à se décentraliser pour se protéger des attaques légales ; et la quatrième est que le partage de la culture et de la connaissance en violation du monopole du droit d’auteur continue de croître tous les jours après avoir déjà atteint des sommets.

Je pense que des enseignements importants peuvent être tirés de ces quatre observations. Si seulement nos hommes politiques pouvaient en prendre conscience, nous nous en porterions beaucoup mieux.

Crédit photo : Sopues (Creative Commons By)

« Les cons ça ose tout, c’est même à ça qu’on les reconnaît » disaient nos tontons.

Je ne connaissais pas l’Interactive Advertising Bureau, organisation regroupant des acteurs de la publicité sur Internet, mais ce qui est sûr c’est qu’elle ne gagne rien à se ridiculiser en attaquant ainsi Mozilla (qui nous protège justement de la prolifération actuelle des cookies intrusifs).

Qu’en pensent Google, Microsoft, Orange, TF1, etc., tous membres de la branche française de l’Interactive Advertising Bureau ?

Commentaire : L’image ci-dessous est extraite de l’article de l’Interactive Advertising Bureau qui a fait bondir Glyn Moody. Ce serait donc Mozilla qui enferme ses utilisateurs, vraiment trop forts nos publicitaires !

Saviez-vous que Mozilla est en train de détourner l’Internet ?

Did You Know that Mozilla is Hijacking the Internet?

Glyn Moody – 12 août 2013 – ComputerWorld (Open Entreprise)
(Traduction Framalang : ane o’nyme, Sky, LordPhoenix, bruno, Cryptie, anneau2fer, simplementNat, Zii, greygjhart + anonymes)

Il y a quelques semaines j’ai relaté l’attaque à peine croyable de la branche européenne du « Interactive Advertising Bureau (IAB) » envers Mozilla au motif que cette dernière aurait « renoncé à ses valeurs » car elle persisterait à défendre les droits des utilisateurs à contrôler comment les cookies sont utilisés sur leur système.

Vu l’avalanche de moqueries venues de toutes part que cette énorme idiotie tactique a provoquée, on pouvait s’attendre à ce que des conseillers plus sages l’emportent et à ce que l’IAB se replie dans un petit coin tranquille, dans l’espoir que les gens arrêtent de se moquer et oublient simplement et complètement ce déplorable incident.

Mais non. au lieu de cela, l’IAB revient à la charge avec une nouvelle attaque sous la forme d’une pleine page achetée dans le magazine Advertising Age, encore plus énorme, plus forte et plus dingue (aussi disponible en ligne pour votre plus grand plaisir).

Sous le sobre titre : « Empêchez Mozilla de détourner l’internet », on peut lire :

De nos jours, il est facile de trouver le contenu qui vous intéresse sur Internet. Cela est dû au fait que les publicitaires peuvent adapter les annonces aux intérêts précis des utilisateurs grâce à l’usage responsable et transparent de cookies.

Je dois dire que je suis vraiment reconnaissant envers l’IAB de m’avoir ouvert les yeux en mettant ceci à jour parce que jusqu’à ce que je lise ce paragraphe, je nageais dans l’ignorance la plus totale et croyais naïvement que c’était les moteurs de recherches que j’utilisais, d’abord Lycos, puis Altavista, suivi de Google et désormais Startpage, qui me permettaient de trouver les choses qui m’intéressaient. Mais je réalise maintenant mon erreur : j’apprends qu’en fait c’est grâce à tous ces petits cookies si bien disséminés à mon insu dans mon système que j’ai trouvé tout ces trucs. Qui l’eût cru ?

Ces mêmes personnes de l’IAB qui ont eu l’obligeance de mentionner cela ont aussi de mauvaises nouvelles pour moi :

Mais Mozilla veux éliminer ces mêmes cookies qui permettent aux publicitaires de toucher le public, avec la bonne publicité, au bon moment.

Méchant Mozilla. Oh, mais attendez, en fait ce n’est pas ce que Mozilla fait. Il veut au contraire juste contrôler le flot de cookies qui proviennent de sites que vous n’avez pas visités et qui sont envoyés sur votre système, aussi appelés les cookies tiers. Voici une bonne explication de ce qui se passe ici :

Tous les acteurs tiers sont en marge de la transaction et peuvent ajouter de la valeur mais leur but premier diffère du bien ou du service recherché. Ces tierces parties sont plutôt comme le type qui fait le tour du parking avec ses prospectus pendant que vous faites vos courses et met des bons de réduction sur le pare-brise de tout le monde (Oh ! Jamais en panne, 169€ par mois ?). Il ne remplit pas les rayons, ni n’emballe vos courses, mais il fait quand même partie (indirectement ou marginalement) de l’opération « aller faire ses courses ».

Il ne s’agit donc pas d’une volonté de Mozilla d’éliminer les cookies en général mais simplement de donner à l’utilisateur le pouvoir de contrôler ces publicités ennuyeuses glissées sous vos essuie-glaces numériques quand vous visitez un supermarché virtuel.

Mais revenons à la fine analyse de l’IAB :

Mozilla prétend que c’est dans l’intérêt de la vie privée. En vérité nous pensons qu’il s’agit d’aider certains modèles d’affaire à prendre un avantage sur le marché et à réduire la concurrence.

Heu, parlons-nous du même Mozilla ? Vous savez le projet open source qui a certainement fait plus pour défendre les utilisateurs et le Web ouvert que personne ? Ce projet-là ? Car j’ai bien peur d’avoir du mal à imaginer ces codeurs altruistes « aider certains modèles d’affaire à prendre un avantage sur le marché et à réduire la concurrence ».

Je veux dire, Firefox a justement été spécifiquement créé pour accroître la concurrence ; le credo de Mozilla est que chacun devrait être libre d’utiliser le Web comme il l’entend, ce qui inclut toutes sortes de modèles économiques. Penser sérieusement que donner aux utilisateurs le contrôle de leur navigateur Firefox n’est pas défendre la vie privée mais une sorte complot maléfique destiné à miner l’ensemble de l’écosystème est, pour le formuler simplement, totalement cinglé. Peut être l’IAB vit-il dans univers parallèle ?

Les consommateurs ont déjà le contrôle sur les publicités ciblées qu’ils reçoivent via le programme d’auto-régulation de la Digital Advertising Alliance.

Pas de doute, l’IAB vit bien dans un univers parallèle, un univers dans lequel les gens ont réellement rencontré ce programme d’autorégulation de la Digital Advertising Alliance. Parce que je peux honnêtement dire qu’en 20 ans de promenades sur le Web, et bien trop d’heures passées en ligne chaque jour (comme mes abonnés sur Twitter, identi.ca et G+ le savent trop bien), je ne suis jamais tombé sur ce légendaire programme d’autorégulation de la Digital Advertising Alliance, et je sais encore moins comment l’utiliser pour contrôler les publicités que je reçois. Et je me retrouve, dans ce lamentable état d’ignorance, qui suggère plutôt que peu d’autres personnes utilisant l’Internet sont tombés sur le programme d’autorégulation de la Digital Advertising Alliance ou l’ont utilisé (est-ce qu’un lecteur ici est déjà tombé dessus, je me le demande).

En fait, je pense que l’IAB a commis ici un autre faux pas. En mentionnant le programme d’autorégulation de la Digital Advertising Alliance comme une « solution » existante qui rend caduques les projets de Mozilla pour maîtriser les cookies tiers, un programme qui, autant que je puisse en juger, est utilisé par très peu de gens, l’IAB a ainsi mis en évidence le fait qu’il n’y a pas vraiment d’alternative viable à Mozilla.

Je dois également souligner le fait que l’image (voir plus haut) utilisée dans l’article en question, un ordinateur portable enchainé, relève au mieux de l’ignorance, au pire constitue une insulte pour les centaines de milliers de personnes qui ont contribué au projet Mozilla au cours de ces 15 dernières années. Mozilla s’est voué à libérer le Web et ses utilisateurs d’un monopole qui menaçait de le détruire : il est difficile de penser à une image moins appropriée !

Et si l’IAB se préoccupe vraiment de qui peut faire pression sur nos ordinateurs et nous ôter notre liberté avec des centaines de fichiers minuscules qui nous épient où que l’on aille sur Internet, et s’inquiète de qui est vraiment en train de prendre en otage les incroyables ressources du Net, que Mozilla a beaucoup contribué à développer, il ferait bien de se regarder dans une glace…

Le lanceur d’alerte Edward Snowden aurait-il réveillé les consciences ? Plus de cent mille téléchargements en trois jours pour le « PirateBrowser », navigateur spécifique (Firefox+Tor) mis récemment en ligne par The Pirate Bay pour contourner les sites bloqués par la censure, le plus souvent d’État !

Remarquons cependant que seul un exécutable Windows est pour le moment distribué, sans ses sources. Prudence donc si vous n’accordez pas une confiance aveugle à The Pirate Bay (qui s’offre là un bon coup de projecteur à moindres frais ?).

Si vous souhaitez l’anonymat en plus du contournement de la censure, allez plutôt voir directement du côté de Tor (qui propose d’ailleurs un Tor Browser bundle avec ses sources).

Le navigateur anti-censure de The Pirate Bay atteint les 100 000 téléchargements

Pirate Bay’s Anti-Censorship Browser Clocks 100,000 Downloads

Ernesto – 13 août 2013 – TorrentFreak.com
(Traduction : tetrakos, greygjhart, Genma, Penguin, ronane, Arthrik, Jeey, Tsigorf, ane o’nyme, Théotix + anonymes)

Il aura suffi de trois jours pour que PirateBrower, le navigateur anti-censure de The Pirate Bay qui permet aux personnes de passer outre les filtrages mis en place par les fournisseurs d’accès à internet et ainsi d’accéder aux sites bloqués, soit téléchargé plus de cent mille fois. Les memebres de l’équipe The Pirate Bay ne s’attendait pas à ce que ce navigateur soit diffusé aussi rapidement et ils précise qu’ils sont déterminés à fournir d’autres outils anti-censure.

À l’occasion de son dixième anniversaire samedi dernier, The Pirate Bay a envoyé un cadeau à ses utilisateurs : le navigateur PirateBrowser.

Bloqué suite à des décisions de justice dans le monde entier, The Pirate Bay est sans conteste l’un des sites les plus censurés sur Internet. Le navigateur PirateBrowser permet à ses utilisateurs de contourner ces restrictions.

Il semble que l’idée du navigateur soit arrivée à point nommé. En effet, des statistiques ont été relevées aujourd’hui, et montrent que les utilisateurs bloqués l’ont téléchargé en masse.

Ainsi, trois jours après le lancement, plus de cent mille personnes ont déjà téléchargé PirateBrowser depuis le site officiel, tandis que le fichier torrent est partagé par plus de cinq mille personnes à l’heure où nous écrivons cet article.

Même si The Pirate Bay s’attendait à provoquer un certain intérêt, ils n’avaient pas prévu cette avalanche de téléchargements.

« Je ne m’attendais pas à un tel engouement » a déclaré Winston Brahma à TorrentFreak. « Je suppose que les gens veulent voir les sites que les gouvernements et les tribunaux essaient de leur cacher. »

Pour répondre à la demande massive, The Pirate Bay a dû augmenter le débit de la connexion du lien de téléchargement. Même après trois jours, le PirateBrowser reste en moyenne largement au-dessus du millier de téléchargements par heure.

Le navigateur est basé sur Firefox 23 couplé à un client Tor (Vidalia) et quelques configurations proxy pour accélérer le chargement des pages web. Il est conçu uniquement comme un outil de contournement de la censure : les équipes de The Pirate Bay souhaitent insister sur le fait qu’il n’apporte aucun anonymat aux utilisateurs.

« Le navigateur ne garantit pas l’anonymat et il n’est pas conçu pour cacher votre identité. PirateBrowser est uniquement prévu pour contourner la censure et le blocage de sites web. Si nous avions conçu un navigateur complètement anonyme, il aurait tout simplement ralenti la navigation », explique Winston.

En plus de la version actuelle pour Windows, des versions pour Mac et pour Linux du navigateur PirateBrowser sont annoncées dans un futur proche.

Le navigateur anti-censure n’est que le premier outil réalisé par The Pirate Bay. Une application basée sur BitTorrent, qui permettra à ses utilisateurs de stocker et de distribuer le site The Pirate Bay (ainsi que d’autres) sur leur propres ordinateurs est actuellement en préparation. Un tel outil rendra impossible les blocage par un tiers.

Le jeu du chat et de la souris se poursuit…

Vous trouverez ci-dessous un argumentaire exposant cinq (bonnes ?) raisons d’abandonner MySQL.

Dans la mesure où nombreux sont les sites dynamiques qui reposent encore sur cette célèbre base de données (à commencer par les nôtres), la question mérite d’être posée.

5 raisons de larguer MySQL dès maintenant

5 Reasons It’s Time to Ditch MySQL

Rikki Endsley – 10 juillet 2013 – SmartBear Blog
(Traduction : Slystone, audionuma, tetrakos, goofy, mokas01, fred, Sky, ProgVal, ymai, Asta + anonymes)

MySQL est encore et toujours la plus populaire des bases de données open source, mais a perdu des fans au fil des années. Voici cinq raisons concrètes de laisser tomber MySQL.

En 2008, MySQL gagnait rapidement en popularité lorsque Sun Microsystems acheta MySQL AB pour environ un milliard de dollars. L’année suivante, Oracle racheta Sun, et MySQL faisait partie de la transaction. Les utilisateurs de MySQL et les développeurs ont commencé à se poser des questions sur le destin de ce système de base de données open source, et nombre d’entre eux commencèrent à chercher des alternatives

Revenons en 2013. Oracle n’a pas exterminé son précédent compétiteur et MySQL reste le système de bases de données le plus populaire. Et pourtant, cette popularité de MySQL est sur le déclin : tandis qu’il perd de son attrait, des alternatives viables pour la gestion des bases de données commencent à tirer leur épingle du jeu. Voici cinq bonnes raisons de ne pas utiliser MySQL, le système de gestion de bases de données qui fut libre (pour voir l’autre côté de la médaille, lire l’article d’Andy Patrizio qui donne les cinq bonnes raisons de continuer à utiliser MySQL, faites-vous un avis, et n’hésiter pas à le partager dans les commentaires).

1. MySQL n’est pas aussi mature que d’autres systèmes de gestion de bases de données.

MySQL n’a pas commencé comme un SGBDR (Système de Gestion de Bases de Données Relationnelles), mais a changé de direction par la suite pour inclure plus de fonctionnalités. Les SGBDR plus anciens et plus matures sont toujours considérés comme ayant plus de fonctionnalités que MySQL. Si vous voulez un SGBDR riche en fonctionnalités, vous pouvez jeter un œil à PostgreSQL ou à des options non open source, telles que Oracle DB ou Microsoft SQL Server.

Selena Deckelmann, une contributrice à PostgreSQL, affirme que Postgres est considéré comme le bon choix pour les nouveaux projets parmi les développeurs-euses Web qui ont besoin d’une base de données relationnelle. « Avec le type de données JSON, et PLV8, Postgres pourrait aussi bien devenir le choix par défaut pour le NoSQL. » dit-elle.

2. MySQL est open source… enfin, plus ou moins

Techniquement, MySQL est un système de bases de données open source, mais dans la pratique ce n’est plus le sentiment que l’on ressent. Sous le couvert d’Oracle, MySQL a maintenant plusieurs modules propriétaires dont le code source n’est pas public. « Sur le papier, MySQL est toujours vivant, mais la mainmise d’Oracle sur le développement et son refus de communiquer des exemples de tests concernant des bugs et des patches de sécurité pour MySQL a renforcé son contrôle sur le code et a poussé de nombreux développeurs open source à aller voir si l’herbe n’est pas plus verte aileurs. » explique Paula Ronney dans son article sur ZDNet, Est-il temps pour Oracle de donner MySQL à Apache ?

Ce n’est pas comme s’il n’y avait pas d’alternatives open source. MariaDB, un fork de MySQL, reste « véritablement open source ». SkySQL, une entreprise développant MariaDB qui a fusionné avec Monty Program Ab (l’entreprise mère de MariaDB) plus tôt cette année explique que « Tout le code dans MariaDB est fourni sous GPL, LGPL ou BSD. MariaDB n’a pas de module closed source comme ceux que vous pouvez trouver dans la MySQL Enterprise Edition. En fait, toutes les fonctionnalités closed-source de MySQL 5.5 Enterprise Edition se trouvent dans la version open source MariaDB. »

3. Les performances de MySQL ne valent pas celles de ses concurrents

Le blog de MariaDB offre un comparatif détaillé des résultats obtenus par les versions récentes de MySQL et de MariaDB, et bien que les résultats se jouent dans un mouchoir de poche, MariaDB possède une longueur d’avance.

Selena Deckelmann, contributrice à PostgreSQL, prétend que Heroku Postgres rend Postgres plus attirant pour plusieurs raisons, y compris au niveau de l’extensibilité. « Ils possèdent clairement le plus large environnement hébergé pour Postgres, s’adaptant automatiquement pour vos applications et acceptent des extensions (add-ons) qui rendent facile l’essai de nouvelles fonctionnalités avant même que les DevOps ne rencontrent la situation » ajoute-t-elle à ses explications. « Ils viennent tout juste d’annoncer le support de PLV8 qui permet de lancer JavaScript au sein même de la base de données et tire avantage des données JSON disponibles dans les versions 9.2 et supérieures. »

4. MySQL est la propriété d’Oracle, pas un projet communautaire

MySQL n’a pas radicalement changé d’objectif depuis son acquisition par Oracle, mais demeure la propriété d’Oracle, ce qui rend certains développeurs nerveux. « Et, pire encore, il est impossible pour la communauté de collaborer avec les développeurs de chez Oracle » dit Michael « Monty » Widenius, fondateur de MySQL et de MariaDB.

Widenius remarque qu’Oracle n’accepte pas les patchs et ne fournit aucune roadmap publique. « Il n’y a pas moyen de discuter avec les développeurs de MySQL sur l’implémentation de fonctionnalités ou le fonctionnement du code actuel » ajoute-t-il. S’il vous importe d’employer une base de données open source et développée par la communauté, Widenius vous conseille MariaDB (doh!), car elle est bâtie sur MySQL et offre plus de fonctionnalités, de vitesse et de stabilité, mais moins de failles de sécurité.

5. De plus en plus de grand projets abandonnent le navire

Lors des rencontres RedHat Summit 20013 Boston, RedHat a annoncé sa rupture avec MySQL. La distribution Linux Red Hat Entreprise (RHEL) intégrera MariaDB. Fedora a d’ores et déjà annoncé qu’il passerait de MySQL au fork MariaDB avec Fedora 19. Slackware Linux a annoncé la transition de MySQL à MariaDB en mars 2013 et openSUSE a fait une annonce similaire en janvier 2013.

Les distributions Linux ne sont pas les seules. En avril 2013, la Wikimedia Foundation a annoncé que Wikipédia, le septième site le plus populaire au monde allait adopter MariaDB. Dans le communiqué, Asher Feldman, le concepteur de sites de la Wikimedia Foundation, expliquait que les améliorations de l’optimisateur de MariaDB, et que l’ensemble de fonctionnalités XtraDB de Percona étaient des raisons très favorables à un changement. « Tout aussi important, en tant que supporters du mouvement de la culture libre, la Wikipedia Foundation préfère fortement les projets logiciels libres : cela inclut une préférence pour les projets sans base de code divisée entre éditions gratuites/libres et pour entreprises », ajoute-t-il. « Nous accueillons et supportons la MariaDB Foundation comme délégué à but non lucratif de la communauté de la base de données MySQL libre et ouverte. » Comme le fit remarquer le journaliste spécialisé en technologie Steven J. Vaughan-Nichols (et contributeur à SmartBear) à la fin de l’année 2012, peu importe ce que vous ressentez vis-à-vis d’Oracle ou du débat des logiciels open source/non-libres, « les meilleures performances de MariaDB à l’un des sites Web les plus chargés du monde va attirer l’attention de n’importe quelle personne utilisant des piles logicielles Linux, Apache, MySQL, PHP/Python/Perl (LAMP). »

Donc, que savent ces entreprises spécialisées dans la technologie et le Big Data que les utilisateurs fidèles de MySQL ignorent ? MySQL n’est plus le seul gros poisson dans le petit étang des solutions de bases de données. Au contraire, MySQL est en concurrence avec sa propre solution émancipée d’Oracle, une engeance véritablement open source, MariaDB, le SGBDR toujours plus populaire PostgreSQL, et un marché toujours plus florissant de solutions NoSQL.

Si vous n’avez pas encore laissé tomber MySQL, il y a plein de raisons pour y réfléchir à nouveau.

Qu’il s’agisse de son code ou de son utilisation, la faiblesse de la documentation d’un logiciel libre est souvent montrée du doigt.

Voici, selon Andy Lester, 13 défauts ou lacunes communément rencontrés, qui sont autant d’écueils que l’on peut contourner avec un minimum d’efforts aujourd’hui pour gagner demain un temps précieux.

13 choses que les gens détestent sur vos documentations open source

13 Things People Hate about Your Open Source Docs

Andy Lester – 10 janvier 2013 – SmartBear Blog
(Traduction : Lamessen, calou, Shanx, sinma, Asta + anonymes)

La plupart des développeurs open source aiment penser à la qualité du logiciel qu’ils développent, mais la qualité de la documentation est souvent laissée de côté. Il est rare de voir vanter la documentation d’un projet, et pourtant elle a un impact direct sur sa réussite. Sans une bonne documentation, les utilisateurs n’utiliseront pas votre projet, ou ils n’y prendront pas de plaisir. Les utilisateurs comblés sont ceux qui diffusent des infos à propos de votre projet – ce qu’ils ne font qu’après avoir compris comment il fonctionne. Et ils apprennent cela à partir de la documentation du projet.

Malgré tout, de trop nombreux projets ont une documentation décevante. Et cela peut être décevant de plusieurs manières.

Les exemples que je donne ci-dessous sont purement arbitraires, je ne veux pas cibler un projet en particulier. Ce sont seulement ceux que j’ai utilisés récemment, cela ne veut pas dire qu’ils représentent les pires atrocités. Chaque projet a commis au moins quelques-uns de ces péchés. Que vous soyez utilisateur ou développeur, à vous d’évaluer à quel point votre logiciel préféré est ou non coupable, et comment vous pouvez aider à y remédier le cas échéant.

1. Le manque d’une bonne introduction ou d’un README/LISEZ-MOI

Le README/LISEZ-MOI est la première impression que les utilisateurs potentiels ont de votre projet. Si le projet est sur GitHub, le README/LISEZ-MOI est automatiquement affiché sur la page d’accueil du projet. Si vous l’avez mal rédigé, ils peuvent ne jamais revenir.

Vous voulez capter l’attention du lecteur et l’encourager à continuer la découverte de votre projet ? Le README/LISEZ-MOI devrait alors au moins expliquer :

• ce que le projet fait
• pour qui il est fait
• sur quel matériel ou plateforme il tourne
• toutes les dépendances majeures, comme « Requiert Python 2.6 et libxml »
• comment l’installer, ou un accompagnement de chaque étape à la suivante.

Tout cela doit pouvoir être compris par quelqu’un qui n’a jamais entendu parler de votre projet, et peut-être même jamais imaginé un projet pouvant s’en rapprocher. Si le projet possède un module calculant la distance de Levenshtein, ne partez pas du principe que n’importe qui lisant votre README/LISEZ-MOI sait ce que c’est. Expliquez que la distance de Levenshtein est utilisée pour comparer deux chaînes de caractères, et ajoutez quelques renvois vers des explications plus poussées pour celui qui aimerait approfondir le sujet.

Ne décrivez pas votre projet par rapport à un autre projet, comme « NumberDoodle est comme BongoCalc, mais meilleur ! » Ça n’est d’aucune aide pour quelqu’un qui n’a jamais entendu parlé de BongoCalc.

2. La documentation non disponible en ligne

Bien que je n’ai pas lu d’études à ce sujet, je serais prêt à parier que 90% des recherches de documentation sont faites avec Google et un navigateur sur Internet. La documentation de votre projet doit être en ligne, et disponible. Partant de là, il serait embarrassant que la documentation de mon propre projet, ack, ne soit pas disponible à l’endroit où la majorité des gens vont la chercher. Mon hypothèse est basée sur ma propre expérience, à savoir que si je veux connaître le fonctionnement d’un outil en ligne de commande, je vais vérifier sa page man.

Comment je m’en suis aperçu ? Les utilisateurs m’écrivaient pour me poser des questions dont les réponses se trouvaient dans la FAQ. Ce qui m’a ennuyé : ils ne lisaient pas ma FAQ. Il se trouve qu’ils avaient cherché sur le site internet, mais je n’avais pas mis la FAQ à cet endroit. C’est une erreur facile à faire. Je suis proche du projet et je n’ai jamais eu besoin d’utiliser moi-même la FAQ, je n’avais donc pas remarqué qu’elle n’était pas présente en ligne. Beaucoup de problèmes sont dus à ce piège : les auteurs ne se mettent pas à la place des utilisateurs.

3. La documentation disponible uniquement en ligne

Le revers de ce problème est d’avoir la documentation disponible uniquement en ligne. Certains projets ne distribuent pas la documentation avec les livrables du projet, ou incluent une version médiocre de la documentation.

Le moteur de recherche Solr, par exemple, a un excellent wiki qui sert à la documentation du projet. Malheureusement, la documentation liée au téléchargement comporte 2200 pages de Javadoc d’API auto-générées. Au final, la seule documentation pour l’utilisateur est une unique page de tutoriel.

Le langage PHP n’est distribué avec aucune documentation. Si vous voulez la documentation, vous devez aller sur une page séparée pour les obtenir. Pire, seule la documentation du cœur est disponible au téléchargement, sans les annotations utiles des utilisateurs (voir « Ne pas accepter les remarques des utilisateurs » plus bas), et ce n’est pas le même format facile à parcourir que celui qui est disponible en ligne.

Les projets open source ne peuvent pas supposer que les utilisateurs ont accès à Internet quand ils ont besoin de la documentation. Le mode avion existe toujours. De toute façon, vous ne souhaitez pas que l’utilisateur dépende uniquement du fait que votre site web est disponible ou non. Au moins à deux reprises durant les derniers mois, le wiki de Solr était indisponible au beau milieu de ma journée de travail alors que je recherchais des informations sur un problème de configuration épineux.

Un projet qui fait les choses bien est Perl et son dépôt de module CPAN. La documentation pour chaque module est disponible soit à search.cpan.org ou metacpan.org dans un format hypertexte facile à lire. Pour la consultation hors-ligne, la documentation de chaque module est intégrée dans le code lui-même, et quand le module est installé sur le système d’un utilisateur, la documentation locale est créée sous forme de pages man. Les utilisateurs peuvent aussi utiliser « perldoc Module::Name » pour obtenir la documentation depuis le shell. En ligne ou hors-ligne : c’est votre choix.

4. La documentation non installée avec le paquet

Ce problème est généralement une erreur des paquageurs, pas des auteurs du projet. Par exemple, sur Ubuntu Linux, la documentation du langage Perl est séparée, ce sont des paquets optionnels pour le langage lui-même. L’utilisateur doit savoir qu’il doit explicitement installer la documentation de la même façon que le langage principal ou il n’y aura pas accès quand il en aura besoin. Ce compromis de quelques mégabites d’espace disque au détriment de la documentation à portée de main de l’utilisateur dessert tout le monde.

5. Le manque de captures d’écran

Il n’y a pas de meilleur moyen d’obtenir l’attention potentielle d’un utilisateur, ou d’illustrer un usage correct, qu’avec des captures d’écran judicieuses. Une image vaut mieux qu’un long discours, c’est encore plus important sur Internet parce que vous ne pouvez obtenir d’un lecteur de lire plus de quelques centaines de mots en tout.

Les captures d’écran accompagnant le texte sont inestimables pour guider l’utilisateur voulant faire les choses au mieux. Une capture d’écran lui permet de comparer visuellement ses résultats à ceux de la documentation et va le rassurer d’avoir exécutée la tâche correctement ou l’aidera à trouver facilement ce qui ne va pas.

Il est de plus en plus commun de trouver des vidéos sur le site internet d’un projet pour en donner un aperçu, et c’est génial. Tout autant que le fait d’avoir une vidéo pour chaque étape d’un processus complexe. Le projet Plone, par exemple, a un site entier dédié aux tutoriels vidéos. Cependant, les vidéos ne peuvent pas remplacer les captures d’écran. Un utilisateur veut voir rapidement l’allure des captures d’écran sans s’arrêter devant une vidéo. Les vidéos n’apparaissent également pas dans une recherche Google Image, à l’inverse des captures d’écran.

6. Le manque d’exemples réalistes

Pour les projets basés sur du code, l’analogue des captures d’écran sont de bons et solides exemples du code en action. Ces exemples ne devraient pas être abstraits, mais directement issus du monde réel. Ne créez pas d’exemples bateaux plein de « nom de la démo ici » et lorem ipsum. Prenez le temps de créer des exemples signifiants avec une histoire d’utilisateur qui représente la façon dont votre logiciel résout un problème.

Il y a de bonnes raisons de vous embêter avec des problèmes de maths en classe. Ils permettent d’appliquer ce que vous avez appris.

Disons que j’ai écrit un module d’un robot Web, et que j’explique la méthode follow_link. Je pourrais montrer la définition de la méthode ainsi :

$mech->follow_link( text_regex => $regex_object, n => $link_index );

Mais admirez à quel point cela devient évident en ajoutant de la réalité dans l’exemple.

# Suit le 2e lien où la chaîne de caractères « download » apparait
$mech->follow_link( text_regex => qr/download/, n => 2 );

Les noms des variables $regex_object et $link_index sont maintenant compréhensibles par le lecteur.

Bien entendu, vos exemples ne doivent pas être aussi brefs. Comme Rich Bowen du projet Apache le souligne, « Un exemple correct, fonctionnel, testé et commenté l’emporte sur une page de prose, à chaque fois. »

Montrez autant que possible. L’espace n’est pas cher. Créez une section dédiée aux exemples dans la documentation, ou même un livre de cuisine. Demandez aux utilisateurs d’envoyer du code qui fonctionne, et publiez leurs meilleurs exemples.

7. Liens et références inadéquats

Vous avez les hyperliens. Utilisez-les.

Ne pensez pas, parce que quelque chose est expliquée dans une certaine partie de la documentation, que le lecteur a déjà lu cette partie, ou bien qu’il sait où elle se trouve. Ne vous contentez pas de signaler que cette partie du code manipule des objets frobbitz. Expliquez brièvement lors du premier usage de ce terme ce qu’est un objet frobbitz, ou donnez le lien vers la section du manuel l’expliquant. Encore mieux, faites les deux !

8. Oublier les nouveaux utilisateurs

Il arrive trop souvent que l’écriture de la documentation soit rédigée à partir du point de vue de son auteur, alors que es nouveaux utilisateurs ont besoin de documentation d’introduction pour les aider.

L’introduction devrait être une page séparée de la documentation, idéalement avec des exemples qui permettent à l’utilisateur de réussir quelques manipulations avec le logiciel. Pensez à l’excitation que vous ressentez quand vous commencez à jouer avec un nouveau logiciel et qu’il vous permet de faire quelque chose de cool. Faites que ça arrive aux nouveaux utilisateurs également.

Par exemple, un package graphique pourrait présenter une série de captures d’écran qui montrent comment ajouter des données dans un fichier, comment faire intervenir le grapheur, et ensuite montrer les graphes obtenus. Une bibliothèque de codes pourrait montrer quelques exemples d’appels à la bibliothèque, et montrer le résultat obtenu. Pensez simplicité. Offrez une victoire facile. Le texte devrait introduire les termes aux endroits appropriés, avec des liens vers une documentation plus détaillée sur le long terme.

Un document de démarrage séparé donne à l’utilisateur une compréhension rapide du logiciel. Il garde aussi les explications d’introduction en dehors de la partie principale de votre documentation.

9. Ne pas écouter les utilisateurs

Les développeurs doivent écouter les utilisateurs de la documentation. La chose évidente est d’écouter les suggestions et requêtes des personne qui utilisent activement votre logiciel. Quand un utilisateur prend le temps d’écrire un mail ou de poster quelque chose comme « ça aurait pu m’aider à mieux installer le programme s’il y avait eu une explication ou des liens au sujet des pilotes de la base de données », prenez ce message au sérieux. Pour chaque utilisateur vous envoyant un mail pour un problème, vous devez vous attendre à ce que dix utilisateurs silencieux aient le même problème.

Il est important d’écouter les problèmes des utilisateurs et d’en chercher les causes. S’ils ont souvent des problèmes pour effectuer des mises à jour groupées de bases de données, la première chose à faire est d’ajouter une question à la FAQ (vous avez bien une FAQ, n’est-ce pas ?) qui traite de ces questions-là. Cependant, la question peut aussi indiquer que la section traitant des mises à jour de base de données n’est pas assez claire. Ou peut-être qu’il n’y a pas de référence à cette section depuis la vue d’ensemble introductive du document, avec pour conséquence que vos utilisateurs ne pensent jamais à lire le reste du manuel.

En plus d’aider plus de gens à découvrir à quel point votre projet est utile, ça diminuera aussi la frustration de la communauté déjà existante. Si votre liste de diffusion, forum ou canal IRC est remplie de personnes qui posent toutes les mêmes questions idiotes (ou pas si idiotes) au point que tout le monde devient lassé d’y répondre, sachez reconnaître que ce sont des questions récurrents pour la FAQ, et mettre les réponses à un endroit facile à trouver aidera tout le monde à se concentrer sur des choses plus amusantes.

Gardez aussi un œil sur les questions des forums externes. Consultez les sites comme StackOverflow régulièrement, et placez une Google Alert sur votre nom de projet pour être maintenu au courant des discussions concernant votre projet sur Internet.

10. Ne pas accepter les entrées des utilisateurs

Si votre projet a une base d’utilisateur assez grande, il peut être judicieux d’incorporer les commentaires des utilisateurs directement dans la documentation. Le meilleur exemple que j’ai pu voir est celui donné par PHP. Chaque page de la documentation permet aux utilisateurs authentifiés d’ajouter des commentaires sur la page, aidant ainsi à clarifier certains points ou ajoutant des exemples qui ne sont pas dans la documentation principale. L’équipe PHP laisse aussi le choix au lecteur de lire la doc avec ou sans les commentaires des autres utilisateurs.

Aussi pratique cela soit-il, cela nécessite de la maintenance. Les commentaires doivent être éliminés de temps en temps pour éviter la prolifération. Par exemple, la page de la documentation PHP sur comment lancer PHP depuis la ligne de commande inclut 43 commentaires d’utilisateurs qui remontent à 2001. Les commentaires écrasent la documentation principale. Les commentaires devraient être archivés ou supprimés, tout en incluant les points les plus importants dans la documentation principale.

Un wiki est également une bonne approche. Cependant, si votre wiki ne permet pas à l’utilisateur de télécharger toutes les pages en une seule grosse archive (cs. point n°3 ci-dessus), alors vos utilisateurs sont à la merci de votre connexion internet et du serveur hébergeant le projet.

11. Impossibilité de voir ce que fait le logiciel sans l’installer

Au minimum, chaque projet de logiciel nécessite une liste de fonctionnalités et une page de captures d’écran pour permettre au potentiel utilisateur intéressé de savoir pourquoi il devrait l’essayer. Aidez l’utilisateur, comparant les différents paquets à utiliser, à voir pourquoi cela vaut la peine de prendre le temps de le télécharger et de l’installer.

Les images sont un bon moyen de faire cela. Votre projet devrait avoir une page « Captures d’écran » qui montre des exemples de l’outil en action (cf. point n°5 ci-dessus). Si votre projet se résume uniquement à du code, comme une librairie, alors il devrait y avoir une page d’exemples montrant ce code utilisant le projet.

12. S’appuyer sur la technologie pour votre rédaction

Trop souvent, les auteurs de logiciels utilisent des systèmes de documentation automatisés pour faire leur travail. Ce système automatisé rend les choses plus facile à maintenir, mais il ne supprime pas la nécessité d’un travail d’écriture humain.

Le pire des cas concerne le changelog, qui n’est rien de plus qu’un dump des messages de commit du système de gestion de version, mais sans un résumé qui l’explique. Un changelog devrait lister les nouvelles fonctionnalités, les problèmes résolus et les incompatibilités potentielles. Sa cible est l’utilisateur final. Un log de commit est pratique et simple à générer pour les personnes travaillant sur le projet, mais ce n’est pas ce dont l’utilisateur a besoin.

Jetez un œil à cette page de la documentation de Solarium, une interface PHP pour le moteur de recherche Solr. Tout d’abord, l’avertisemment prend la moitié supérieure de l’écran, ne donnant aucune information au lecteur. Ensuite, il n’y a vraiment rien de véritablement descriptif sur la page que la liste des noms de fonctions. Il n’y a aucune explication sur les différentes méthodes, ni de liens indiquant où trouver l’explication. Les pages générées automatiquement sont jolies, et elles pourraient ressembler à de la documentation, mais elles n’en sont pas.

13. Arrogance et hostilité vis-à-vis de l’utilisateur

L’attitude du type RTFM (Read The Freaking Manual) est mauvaise pour votre projet et votre documentation.

C’est le summum de l’arrogance que de croire que tous les problèmes qui ont trait au fait que quelqu’un ne sache pas utiliser votre logiciel sont de la faute de l’utilisateur.

Même s’il est probablement vrai que les utilisateurs peuvent trouver leurs réponses dans votre documentation mais ne le font pas, il est stupide de penser que c’est la faute de l’utilisateur. Peut-être votre documentation est-elle mal écrite, ou difficile à lire, ou présente mal à l’écran. Peut-être avez-vous besoin d’améliorer la section « Mise en route » (lien #8 ci-dessus) qui explique ce que le logiciel a pour but de faire. Peut-être que certaines parties d’information nécessitent d’être répétées à de multiples endroits de la documentation.

N’oubliez pas que les nouveaux utilisateurs de votre logiciel peuvent arriver sur votre projet sans rien n’en savoir. Votre documentation doit faire de son mieux pour s’assurer que cette ignorance soit facilement résolue.

Synthèse

Je suis sûr que vous avez déjà eu affaire à quelques-uns de ces problèmes listés ci-dessous, et peut-être que pour d’autres vous n’y avez pas pensé. Faites-nous connaître les problèmes que vous avez rencontrés dans les commentaires ci-dessous, sachant qu’il ne s’agit pas de pointer du doigt certains projets en particulier.

Surtout, j’espère que si vous reconnaissez un problème dans la documentation de vos projets, vous prendrez la peine d’améliorer la situation. Heureusement, améliorer la documentation est une manière idéale de faire participer les nouveaux arrivants dans votre projet. On me demande souvent : « Comment puis-je commencer dans l’open source », et je recommande des améliorations dans la documentation comme une bonne manière de commencer.

Faites-en sorte que ce soit aussi facile que possible, pour les novices comme les plus anciens, de savoir où il est nécessaire de travailler la documentation. Créez une liste des tâches, par exemple dans votre système de suivi des bogues, qui explique ce qui a besoin d’être amélioré. Soyez précis dans ce que sont vos besoins. Ne vous contentez pas de dire que vous avez besoin d’exemples, sans plus de précision. Créez des tâches spécifiques, comme « ajoutez un code d’exemple sur le fonctionnement de la tâche X », « ajouter une capture d’écran du générateur de rapports » ou « ajouter des informations de dépendances au fichier README/LISEZ-MOI ». Les contributeurs souhaitent aider mais trop souvent ils ne savent pas par où commencer.

La documentation n’est pas la partie la plus glamour d’un projet open source, et pour la plupart d’entre nous ce n’est pas amusant. Mais sans une bonne documentation, les utilisateurs ne sont pas servis comme ils pourraient l’être, et votre projet en souffrira sur le long terme.

Crédit photo : Rosalux Stiftung (Creative Commons By)