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…

Notre ami Jean-François Cauche, alias Kaneda aka Tetsuoka, nous a fait parvenir cet article léger spécial été en pente douce.

Enfin léger, façon de parler, car il sera question de succulentes gaufres tout du long !

Jean-François précise : « C’est à force de comparer le logiciel libre et les 4 libertés à une recette de cuisine que m’est venu en tête cette petite histoire. Cafougnette est un personnage du folklore patoisant du Nord, un personnage récurrent des histoires amusantes, des blagues que l’on se raconte entre amis. Il a vécu plein d’aventures en compagnie de son ami, Zeff, et vous trouverez nombre de sites où l’on raconte des cafougnettes. »

PS : Vous avez la traduction « française » juste après mais c’est plus rigolo de parcourir l’original avant pour s’apercevoir (ou pas) qu’on comprend le ch’ti 😉

Le logiciel libre expliqué à Cafougnette

Em grand-mère ale faijot des gauffes qu’cétot à s’in pourléker les babines. A ch’teure, em mère ale in fait, em seur aussi, mi j’in mange et et’femme ale pourrot in faire auchi. Te vos pas du que j’veux in v’nir ? Te verras. Ch’é simpe. In mange des gauffes à ch’t’heure pasqu’em grand-mère ale a mis s’recette sous licence libe sin l’savoir. Ale aurot pu la warder et in entendrot pus parler d’cha ach’teure mais ale avot d’l’idée em’grand-mère.

Ch’est comme el bio. In faijot comme cha autrefos et pis in a oblié et in recomminche à ch’teure. Min grand-père quétot cinsier i faijot du bio. 

Ravises bin ches gauffes. Te n’en verras pon d’parelles. Mi j’les ai fort quere minger. J’pourros in minger gramint. Te sais bin qu’ichi ch’est l’usache. Dins chaque famille, in a eune recette ed’gauffes.

Sus ches markés ou al’ducasse, te vos ches gins qui n’in vintent. Mi j’dis qu’ch’est nin bon et qu’ch’est kèr et pis qu’y a qu’les gauffes d’em grand-mère. In les appele les gauffes ed’Mémé. In d’a pon d’autes. Ch’est les meilleures. Les seules qu’j’avos trouvé pas mauvaises, ch’est les gauffes ed’chez Meert^[1]. Te connos Meert ? Ch’est une patisserie, un marchand d’chuques ed’Lille. Je n’d’ai jamais acaté mais durant tous ches salons et ches colloques, y’a toudis quéqu’in qui n’en acate et in en donne à ches gins à la fin avec el’champane.

Alors el’gauffe d’em grand-mère, ch’est l’gauffe libe, el’gauffe défreumée. El’gauffe ed’chez Meert, ch’est l’gauffe propriétaire. Te vos ? J’vas t’dire. Te s’ras déberloqué.

Em’gauffe quand em’mère ale in fait, j’peux in minger à m’convenance. Mi j’l’aime bin minger caute el’soir quand ale sort de l’gauffrier. Et pis j’in mange el’lendemain : al pikète du jour, à nonne, à l’ermontée, à l’brunnète et même par nuit. Ch’est min dessert, em’friandisse. Cha n’m’aide pas à perdre des kilos. Mais ch’est rin…

Te vas m’dire : el’gauffe ed’chez Meert, j’peux l’minger comme ej’veux. T’as qu’a in acater in tiot peu. Te porras les faire recauffer, in minger frod. Te fais ch’que te veux avec. Cha ch’est bin vrai.

Mais…

Mais si ches gins d’chez Meert, i n’in font plus qu’pour tous ches salons et ches colloques et qu’te peux pus in acater, ch’est fini. Ch’est cha el liberté 0. Te vos c’que j’veux dire ? Minger l’gauffe comme te veux. Te peux même in vinte su ch’marké si te veux.

Min bio-frère il aime bin avec pus que d’castonade ou d’chuque roux qu’d’beurre ed’barratte. Pus qu’y a d’chuque, mieux qu’ch’est. I rajoutot de l’castonade din l’beurre pour la farce. Em seur ale n’aime pas l’chuque. Ale aime bin chez gauffes sans rin, comme cha. Alors ale mettot rin d’ssus. Avec el’gauffe ed’chez Meert, te peux pas. Te peux toudis écrire pour bertonner mais cha m’étonnerot qui zin fassent autrement rin qu’pour ti. I vont t’arconter des carabistouilles, alors qu’ti, j’te l’avos bin dit, te peux faire che qu’te veux. Ch’est cha el liberté 1.

Et pis, te vos, si cha n’avot pas été sous licence libe, in n’in parlerot pus. In jour min grand-père i a écrit l’recette pour em mère. Ale l’a collé dins sin cahier et pis ale in fait souvent. Em grand-mère et min grand-père i n’sont pus mais in pense toudis à eux quand in in mange. I z’étot pas riches. I z’étot cinsiers mais i zavot chel’recette et i pouvot in faire cadeau aux amisses.

Em mère ale a donné à m’seur. Em seur ale donnera à ches zinfants et à ter tous del famille. Ch’est l’liberté 2. Te donnes à cheux qu’te veux.

Ch’est pas comme el’fricadelle^[2]. Tout l’monde i sait, mais personne i l’dit. Alors que l’gauffe ed’Mémé. Te peux savoir commint qu’chest fait et même canger. Te peux faire à t’mote si ça t’amus….

Mi j’les aime avec del chuque roux. Inda i font cha avec del’chicorée. I z’y mettent du rhum ou aute cose. Am maison, in respecte l’usache et in n’cange rin. El’castonade ch’est sacré. T’as bin vu ch’t’homme et tal’heure su ch’marké. I vindot des gauffes. I n’avot d’tous les parfums. Avec el’gauffe ed’Mémé, te peux faire parel. Te peux canger l’chuque roux, par aute cose, mette de l’crem al’plache comme si te faijos de l’tarte à gros bords. Ch’est pas l’respect de l’usache, mais y’a mie personne qui f’ra s’caboche. Et te peux même in faire profiter el zautes sins qu’in dis rin. Avec el’gauffe ed’chez Meert, te peux pas. Ch’est l’liberté 3 cha.

Allez, prends une gauffe, in’da. Te vos, si te preferes chelle la, te préféreras l’logiciel libe. T’in fais ch’que te veux, te l’donnes à qui qu’te veux. Ch’est ti pas bio, cha ?

Traduction « française »

Ça perd de son charme mais pour ceux « qui n’comprenn’te rin »…

Ma grand-mère elle faisait des gaufres que c’était à s’en pourlécher les babines. Aujourd’hui ma mère elle en fait, ma sœur aussi. Moi j’en mange et ta femme, elle pourrait en faire aussi. Tu ne vois pas où je veux en venir ? Tu verras. C’est simple. On mange des gaufres aujourd’hui parce que ma grand-mère elle a mis sa recette sous licence libre sans le savoir. Elle aurait pu la garder et on n’en entendrait plus parler maintenant mais elle avait de l’idée ma grand-mère.

C’est comme le bio. On faisait comme ça autrefois et puis on a oublié et aujourd’hui on recommence. Mon grand-père, qui était fermier, faisait du bio.

Regarde bien ces gaufres. Tu n’en verras pas de pareilles. Moi, j’adore en manger. Je pourrais en manger beaucoup. Tu sais bien qu’ici c’est la tradition. Dans chaque famille, on a une recette de gaufres.

Sur les marchés ou à la ducasse, tu vois tous ces gens qui en vendent. Moi, je dis que ce n’est pas bon, que c’est cher et que les seules ce sont les gaufres de ma grand-mère. On les appelle les Gaufres de Mémé. Il y en a pas d’autres. C’est les meilleures. Les seules que j’avais trouvées pas mauvaises, ce sont les gaufres de chez Meert. Tu connais Meert ? C’est une patisserie, un marchand de bonbons et de chocolats de Lille. Je n’en ai jamais acheté mais, dans les réceptions et les colloques, il y en a toujours quelqu’un qui en achète et en offre aux gens avec le champagne.

Alors la gaufre de ma grand-mère, c’est la gaufre libre. La gaufre de chez Meert, c’est la gaufre propriétaire. Tu vois ? Je vais te dire. Tu seras étonné.

Ma gaufre, quand ma mère elle en fait, je peux en manger comme je veux. Moi, j’aime bien la manger chaude le soir quand elle sort du gaufrier. Et puis j’en mange le lendemain le matin, le midi, l’après-midi, le soir et même la nuit. C’est mon dessert, ma friandise. Ca ne m’aide pas à perdre des kilos. Mais c’est rien…

Tu vas me dire : la gaufre de chez Meert, je peux la manger comme je veux. Tu peux en acheter un peu. Tu pourras les faire réchauffer, en manger froides. Tu fais ce que tu veux avec. Ça, c’est vrai.

Mais…

Mais si ces gens de chez Meert, ils n’en fabriquent plus que pour les réceptions et les colloques et que tu ne peux plus en acheter, c’est fini. C’est ça la liberté 0. Tu vois ce que je veux dire ? Manger la gaufre comme tu veux. Tu peux même en vendre sur le marché si tu veux.

Mon beau-frère, il aime bien avec plus de cassonade ou de sucre roux que de beurre. Plus il y a de sucre, mieux c’est. Il rajoutait de la cassonade dans le beurre pour la farce. Ma sœur, elle n’aime pas le sucre. Elle aime bien les gaufres sans rien, comme ça. Alors elle ne mettait rien dessus. Avec la gaufre de chez Meert, tu ne peux pas. Tu peux toujours écrire pour râler mais ça m’étonnerait qu’ils en fassent autrement rien que pour toi. Ils vont te raconter des histoires, alors que toi, je te l’avais bien dit, tu peux faire ce que tu veux. C’est ça la liberté 1.

Et puis, tu vois, si ça n’avait pas été sous licence libre, on n’en parlerait plus. Un jour mon grand-père il a écrit la recette pour ma mère. Elle l’a collé dans son cahier et puis elle en fait souvent. Ma grand-mère et mon grand-père, ils ne sont plus mais on pense toujours à eux quand on en mange. Ils n’étaient pas riches, ils étaient fermiers mais ils avaient cette recette et ils pouvaient en faire cadeau aux amis.

Ma mère, elle l’a donné à ma sœur. Ma sœur, elle la donnera à ses enfants et à toute la famille. C’est la liberté 2. Tu la donnes à ceux que tu veux.

C’est pas comme la fricadelle. Tout le monde sait mais personne ne le dit. Alors que la gaufre de Mémé, tu peux savoir comment c’est fait et même changer. Tu peux faire à ta convenance si ça t’amuse…

Moi je les aime avec du sucre roux. Il y en a qui font ça avec de la chicorée. Ils y mettent du rhum ou autre chose. À la maison, on respecte la tradition et on ne change rien. La cassonade, c’est sacré. Tu as bien vu cet homme tout à l’heure sur le marché. Il vendait des gaufres. Il en avait de tous les parfums. Avec la gaufre de Mémé, tu peux faire pareil. Tu peux changer le sucre roux par autre chose, mettre de la crème à la place comme si tu faisais un flan. C’est pas le respect de la tradition, mais personne ne t’embêtera. Et tu peux même en faire profiter les autres sans qu’on ne te dise rien. Avec la gaufre de chez Meert, tu ne peux pas. C’est la liberté 3 ça.

Allez, prends des gaufres. Il y en a. Tu vois, si tu préfères celle là, tu préféreras le logiciel libre. Tu en fais ce que tu veux, tu le donnes à qui tu veux. C’est pas beau ça ?

Crédit photo : JavaSquid (Creative Commons By)

Bonjour Céline, peux-tu nous expliquer comment tu en es venue à utiliser le système d’exploitation Free BSD ? Tu l’as attrapé tout d’un coup ou bien c’est l’effet d’une lente incubation ?

Je suis arrivée sur FreeBSD un peu par hasard. En fait, quand j’ai décidé de passer à Linux (en 1999, je sais ça remonte), j’ai testé plusieurs distributions dont La Lycoris Desktop LX, Debian et Ubuntu 6.06. J’ai utilisé Ubuntu et Debian en parallèle pendant énormément de temps jusqu’à ce que je décide de tester OpenBSD (réputé pour sa sécurité) pour l’utiliser sur un serveur de développement. À cause de l’absence de Java et comme je suis développeuse C/Java, j’ai éprouvé de la frustration de ne pas pouvoir tout faire sur ma machine nouvellement acquise. J’ai donc cherché une alternative la plus proche possible : FreeBSD s’est avéré être mon choix final. Une installation sans fioriture, simple et qui n’installait que ce dont j’avais besoin sur mon serveur (seul ArchLinux m’avait satisfaite au même degré jusque-là), je ne demandais rien de plus. Donc pour en revenir à l’usage de ce système d’exploitation, c’est bien l’effet d’une incubation d’une bonne dizaine d’années.

Bon c’est bien joli FreeBSD mais son installation et son usage réclament un certain niveau de compétence technique, non ? est-ce que tu le conseillerais vraiment à des usagers qui comme moi choisissent Ubuntu parce que c’est la distribution la plus abordable ? Il n’existe pas une version plus simple avec une interface graphique qui simplifie la vie ?

C’est vrai que quand on arrive sur FreeBSD, il ne faut pas avoir peur de la console. C’est pareil pour certaines distributions Linux, il faut s’armer de patience, lire la documentation (très bien réalisée) et parfois galérer dans les pages man. L’installation ne se fait pas en quelques clics, une fois l’installation finie, on ne dispose vraiment que des outils de base. Mais c’est ce que j’adore sur OpenBSD et FreeBSD (bon et aussi ArchLinux), c’est que je sais ce qu’il y a sur mon poste, ce qui démarre quand j’allume mon ordinateur, alors qu’au fil de temps je trouve que le fonctionnement des distributions Linux, pour se rendre facile d’accès au grand public, devient de plus en plus opaque. Il suffit de taper un petit ps aux sur Ubuntu pour voir tout ce qui peut tourner (des fois pour rien)… Pour ce qui est d’une version plus facile d’accès, j’ai entendu parler de PC-BSD qui a justement pour objectif de rendre FreeBSD accessible à tous : installation aisée en quelques clics, KDE est fourni en bureau par défaut… Je testerai peut-être un jour sur un autre PC ou avec VirtualBox 😉

Tu en fais un usage dans ta vie professionnelle ou bien c’est choix de passionnée pour ton usage personnel ?

Dans ma vie professionnelle, je travaille sur RedHat, Debian et Solaris, hélas pas encore de FreeBSD en vue, mais ça viendra ! 😉

Merci, je te laisse le soin de présenter l’article…

Il y a de cela 20 ans, le 19 juin 1993, David Greenman, Jordan Hubbard et Rod Grimes annonçaient la création d’un nouveau logiciel basé sur le code source de BSD (Berkeley Software Distribution, voyez cette page Wikipédia) : FreeBSD était né. Peu connu du grand public, ce système d’exploitation est pourtant utilisé partout : en tant que solution d’hébergement pour des sociétés telles que Yahoo!, ou comme solution de sécurité pour la mise en place de firewall. Deux systèmes d’exploitation reposent sur son noyau : FreeNAS et MacOS. FreeNAS est une solution libre grand public pour héberger du contenu à travers un réseau, tandis que MacOS est le système d’exploitation propriétaire que nous connaissons tous au moins de nom. Pour fêter ce cap des 20 ans, voici un petit article qui vous fera découvrir une partie du monde BSD.

— Céline

FreeBSD fête ses 20 ans et met toute sa puissance à votre service.

Traduction Framalang : lamessen, Céline, Garburst, Asta, audionuma d’après l’article original de Lawrence Latif

Le système d’exploitation open source FreeBSD vient de fêter son vingtième anniversaire.

FreeBSD a vu au fil des années sa popularité auprès du grand public diminuer alors que le noyau Linux et les nombreuses distributions qui l’utilisent ont connu un développement rapide. Cependant, FreeBSD a eu 20 ans le 19 juin et continue de faire fonctionner des infrastructures réseaux vitales.

FreeBSD a introduit de nombreuses innovations qui ont été adoptées par certaines distributions Linux. Par exemple, la collection de ports FreeBSD, qui compile des logiciels à partir du code source plutôt qu’à partir de binaires pré-assemblés, a été copiée par Gentoo Linux pour son système Portage.

FreeBSD est également connu pour avoir l’une des piles réseau les plus robustes. Il est fréquemment utilisé par les chercheurs et les industriels comme base pour la simulation et les systèmes de production. Monowall et Pfsense sont des distributions populaires basées sur FreeBSD destinées à être utilisées sur des périphériques réseaux qui embarquent tous les types de fonctionnalités, des firewalls aux réseaux privés virtuels en passant par les liaisons ADSL, sur un système facile à utiliser.

Alors que FreeBSD n’est pas la seule variante libre et largement distribuée de BSD Unix, il est différent de OpenBSD qui essaie d’être le système d’exploitation le plus sécurisé et de NetBSD qui tente de fonctionner sur n’importe quel appareil possédant un microprocesseur. Il est devenu la référence pour une utilisation générale de BSD.

Cependant, FreeBSD n’est pas que réseau et démons, puisque durant ces dernières années les distributions de bureau BSD Unix reposant sur FreeBSD sont apparues, notamment avec PC-BSD qui est la plus célèbre.

FreeBSD, grâce à ses performances et sa licence, est utilisé par des sociétés commerciales comme Citrix, Netapp et Juniper.

Ces dernières années, même la communauté Linux a commencé à reprendre des parties de FreeBSD, avec Debian qui propose une version de sa distribution utilisant le kernel FreeBSD. Malgré la blague récurrente sur le fait que BSD soit mort ou non, étant donné son support à l’industrie, il est probable qu’il continuera son combat dans les décennies à venir.

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)

Vous connaissiez la suite bureautique libre Joeffice ?

Nous, non ! Et quand nous avons appris qu’elle avait été conçue en 30 jours par un développeur (qui plus est français), nous avons évidemment eu envie d’en savoir plus…

Bonjour Anthony, peux-tu te présenter succinctement ? Quel a été ton parcours de développeur ?

Bonjour, je m’appelle Anthony Goubard, j’ai 40 ans et j’habite à Amsterdam. J’ai commencé Java durant ma dernière année d’ingénieur avec la version 1.0 alpha puis j’ai fait du détachement sur la région parisienne. Il y a 14 ans je suis allé travailler pour une start-up aux Pays-Bas puis pour Wanadoo Pays-Bas et il y a 5 ans je me suis mis à mon compte.

Alors Joeffice c’est quoi exactement ? Comment et pourquoi est né le projet ?

Joeffice est une suite bureautique open source écrite en Java. L’idée m’est venue il y a environ 2 ans lorsque je me suis aperçu que c’était galère d’avoir 10 documents d’ouverts avec Microsoft Office ou Libre Office alors que ce n’est pas un problème d’avoir 30 documents ouverts dans Eclipse ou NetBeans.

Dans quel sens évoques-tu une version « online » et « offline » ?

Les logiciels Java peuvent être installés sur un ordinateur comme un logiciel classique ou bien être lancé en ligne dans le navigateur avec l’aide du plugin Java. C’est ce qu’on appelle le mode Applet. Il suffit donc d’aller à l’URL et le logiciel s’installe et se lance dans le navigateur automatiquement. J’ai donc décidé d’offrir les deux possibilités. La version « online » est soumise à un abonnement.

Pourquoi le choix Java ?

Java offre beaucoup d’avantages. Il est portable sur plusieurs OS, il est relativement facile à lire, beaucoup d’étudiants apprennent Java et il est très utilisé dans le monde de l’entreprise. Beaucoup de projets open source utilisent Java. Joeffice offre aux étudiants et développeurs Java la possibilité de travailler sur un projet assez visuel et utile.

Pourquoi le choix de la licence libre ?

L’union fait la force.Tous les développeurs Java que je connais se servent de temps en temps d’une suite bureautique. Avoir un projet bien mené par un grand groupe de contributeurs permettra à long terme de créer un bien meilleur logiciel qu’avec une petite équipe. En plus, beaucoup d’entreprises et de pays en voix de développement sont attirés par l’open source et mon but est de toucher le plus de personnes possible.. Le premier groupe d’utilisateurs pour Joeffice est donc l’entreprise. Dans ce cas la licence Apache 2.0 donne beaucoup de liberté, plus que GPL et LGPL. Cette licence est par exemple utilisée pour le framework Spring.

Comment se positionne Joeffice, aujourd’hui et demain, par rapport à des « monstres » comme Google Docs, Microsoft Office ou LibreOffice ?

Joeffice est moins complet que ces autres offices mais il a aussi des atouts que d’autres n’ont pas. Il est donc open source sous licence Apache. Il est développé entièrement en Java. Il peut s’installer « offline » ou « online ». Il est facilement portable. Il n’a pas une fenêtre par document mais un système d’onglet et d’amarrage ou les documents peuvent être l’un à côté de l’autre ou détachés en groupe. Les mises à jour et plugins, même si pour l’instant non utilisés, peuvent se faire en ligne. Toutes les librairies Java peuvent être facilement utilisées pour créer des actions spéciales, afin par exemple de remplir un document.

La légende dit que tu l’aurais codé tout seul en moins d’un mois ? La légende dit vrai ?

Je l’ai codé en 30 jours. Mais ce sont 30 jours non consécutifs. Pour chaque journée j’ai fait une vidéo que j’ai postée sur YouTube. Il a fallu que je sois efficace sur le code et pragmatique sur certains choix.

En France, on vient d’introduire cette année l’informatique comme discipline à part entière au lycée (pour le moment en option de Terminale S). Bonne ou mauvaise idée ?

Bien sûr, je trouve ça une bonne idée. Même en n’étant pas informaticien, les gens ont de plus en plus besoin de savoir développer. Par exemple un plug-in, une macro ou un site Web.

Joeffice se présente en version alpha. Que lui manque-t-il exactement pour une première version ?

Je me sers de la librairie open source Apache POI pour lire les documents malheureusement il manque encore certaines parties. Chaque partie du logiciel doit être améliorée pour avoir quelque chose de plus utilisable pour l’utilisateur final. Cette version alpha est plus destinée aux développeurs et aux entreprises qui ont des besoins spécifiques. Le but pour la version 1.0 est de s’approcher de ce que peut faire Google Docs.

Et comment vois-tu le futur du projet ? Un appel à lancer ?

Tous les développeurs qui veulent participer à ce projet ou à une des librairies dont Joeffice se sert sont les bienvenus. Le code se trouve sur BitBucket.

Edit : en fait c’était un bug (mais un bug troublant quand même). Fausse alerte donc, le contenu du billet ci-dessous n’est plus pertinent.

Quand on saute d’une version 5.5.30 à la 5.5.31, il ne se passe généralement pas grand chose mis à part quelques bugs fixés.

Sauf qu’ici on a décidé en catimini de changer la licence des pages man de MySQL et ce n’est pas très fair-play de la part de son propriétaire Oracle.

Heureusement qu’on a le fork MariaDB, d’où est d’ailleurs issue cette traduction.

Les pages man de MySQL changent discrètement de licence pour ne plus être sous GPL

MySQL man pages silently relicensed away from GPL

Colin Charles – 18 juin 2013 – MariaDB Blog
(Traduction : Lgodard, ehsavoie, Asta, rou, BastienLQ)

On nous a récemment rapporté que la licence des pages man de MySQL a été modifiée. Le changement a été fait en douce lors du passage de MySQL 5.5.30 à MySQL 5.5.31. Cela affecte toutes les pages du répertoire man/ du code source.

On peut voir que ces changements sont intervenus durant cette courte période (5.5.30->5.5.31). Les anciennes pages du manuel étaient publiées sous la licence suivante :

Cette documentation est un logiciel libre : vous pouvez la redistribuer et/ou la modifier uniquement sous les termes de la licence GNU GPLv2 telle que publiée par la Free Software Foundation.

Les nouvelles pages man (5.5.31 et ultérieures — toujours en vigueur pour 5.5.32) sont sous la licence suivante :

Ce logiciel et la documentation rattachée sont soumis à un accord de licence contenant des restrictions sur leur utilisation et leur divulgation et sont protégés par les lois sur la propriété intellectuelle. Sauf autorisation expresse dans cet accord de licence ou par la loi, vous ne pouvez pas utiliser, copier, reproduire, traduire, diffuser, modifier, changer de licence, transmettre, distribuer, exposer, publier ou montrer une quelconque partie, quelque soit sa forme ou les moyens utilisés. Il est interdit de faire de la rétroingénierie, désassembler ou décompiler ce logiciel, sauf si la loi le requiert pour l’interopérabilité…

Ce n’est clairement pas une marque d’affection pour MySQL de la part d’Oracle. La nouvelle licence est également devenue bien plus longue (en clair ce n’est pas sous licence GPL). Tandis que ce qui suit a été récupéré de l’outil resolveip, le copyright est le même pour toutes les pages man. Vous pouvez comparer la page man de la version 5.5.30 et celle de la version 5.5.31.

Vibrante allocution en faveur du logiciel libre, la ministre Fleur Pellerin a prononcé un discours remarqué lors de l’inauguration des nouveaux locaux Mozilla le 13 juin dernier à Paris.

Ira-t-on plus loin que ses belles paroles ? Seront-elles véritablement suivies de faits et d’effets ?

Une vidéo tournée par Roberto Di Cosmo. et éditée par Stéfane Fermigier

Transcript

(Merci à Goofy, aKa, Z, Asta, Peekmo)

Madame la présidente, chère Mitchell, madame la vice-présidente, chère Debbie,

Mesdames et messieurs, il y a vingt ans un grand chercheur a, je le cite, « pris le principe d’hypertexte et l’a relié au principe du TCP et du DNS, et alors boom, ce fut le World Wide Web. »

Et en 1993, donc, le CERN, cet organisme de recherche européen qui avait inventé le Web a décidé de donner cette invention au monde, en la distribuant sous ce qu’on n’appelait pas encore une « licence libre ». Ce choix, anodin en apparence, a changé la face du monde.

Il y a 10 ans, la fondation Mozilla naissait et quelques mois plus tard, cher Tristan Nitot, vous fondiez sa branche européenne. J’imagine combien cela doit vous faire plaisir d’être ici 10 ans après, dans ce magnifique hôtel particulier du XVIII^e siècle, ancienne demeure de l’ambassadeur d’Autriche, m’avez-vous dit tout à l’heure. Mozilla Firefox, construit sur l’ancien Netscape, et œuvrant inlassablement pour promouvoir les standards du Web, a aussi changé le Web et par là la manière dont nous nous informons et dont nous innovons.

Je suis donc très fière d’inaugurer ce soir les nouveaux bureaux de la fondation Mozilla à Paris. Pourquoi être venue inaugurer ces nouveaux locaux ?

D’abord en raison des valeurs de la fondation Mozilla, et du logiciel libre. Ces valeurs, ce sont l’accès à la connaissance pour tous, la confiance ou encore l’amplification des aspects d’intérêt publics d’internet. Ce sont aussi les valeurs sociales qui portent un modèle de société vertueux, ouvert, participatif, où toute donnée est d’abord considérée comme un bien accessible au plus grand nombre, et une source de connaissances que chacun peut utiliser, améliorer, partager. Le logiciel libre, les formats ouverts, c’est enfin une communauté de personnes qui constitue un véritable patrimoine de connaissances qu’est le code, sans cesse inachevé, toujours à enrichir. Au-delà des innovations et des technologies permises par le Web, des acteurs comme Wikimedia ou la fondation Mozilla ont démontré que l’innovation et le progrès peuvent aussi passer par le partage, l’absence de propriété. C’est une victoire essentielle sur les esprits qui nous permet aujourd’hui d’avancer dans d’autres domaines : je pense à l’open innovation ou à l’open data. Je sais que Mozilla n’est pas une formation politique, mais toutes ces valeurs résonnent particulièrement doux à une ministre de gauche comme moi, et je pense que le monde politique a des choses à apprendre de cette réussite.

Par ailleurs le logiciel libre est aussi un atout décisif pour notre économie. À plus d’un titre il permet d’abord de lutter contre les phénomènes de dépendance technologique envers tous ces acteurs qui sont propriétaires de nos outils informatiques quotidiens, et est donc un véritable garant de la souveraineté numérique. De plus comme on le voit aujourd’hui, et contrairement à certaines idées reçues, le libre et l’open source sont créateurs d’emploi. Des modèles d’affaire originaux ont été créés et c’est un facteur important de productivité et de compétitivité pour les entreprises et les administrations. En effet elles peuvent ainsi mieux maîtriser leurs patrimoines respectifs et concentrer leurs efforts sur ce qui représente pour elles la valeur ajoutée. Enfin le logiciel libre remet en cause les rentes de situation, peu favorables à l’innovation, et par là-même aide à l’émergence de nouveaux champions économiques. L’émergence de Firefox et des navigateurs est emblématique de cette capacité.

La France est souvent citée comme un des pays les plus actifs au monde dans le domaine du logiciel libre. La croissance soutenue dans ce secteur le confirme. Les chiffres sont éloquents : ce marché représentait en 2011 plus de 2 milliards d’euros, soit plus de 6% de la demande de logiciels et de services informatiques. Par ailleurs, il y a là un formidable levier d’emplois, environ 10 000 supplémentaires dans les 3 ans à venir, si les estimations de croissance du marché sont confirmées. Bref, ce sont des enjeux extrêmement importants. La décision de Mozilla, un acteur mondial de référence sur le logiciel libre, de s’implanter dans ces locaux, confirme l’attractivité de Paris comme place incontournable du numérique. Elle confirme l’excellence des formations françaises dans le domaine informatique et je suis certaine que les développeurs du monde entier seront attirés par les conditions d’accueil ici, dans ces magnifiques locaux.

Mon objectif est bien sûr de renforcer encore ces atouts avec notamment le projet de quartiers numériques que nous allons créer dans une quinzaine de villes. Enfin, nous avons en France une communauté parmi les plus dynamiques dans le monde pour la conception et l’utilisation des logiciels libres, un atout à évidemment ne pas négliger. Avec les Assises de l’Entreprenariat, nous avons souhaité aller encore plus loin pour renforcer notre attractivité en mobilisant notamment toutes les compétences de France et d’ailleurs. C’est pour accompagner ce mouvement que le gouvernement travaille ardemment à la création d’un visa entrepreneur et d’un visa talent, car il est impératif d’attirer les talents créateurs du monde entier en leur offrant des conditions d’installation très rapides et simplifiées. Je dois aussi rappeler que le gouvernement prête une attention toute particulière à l’utilisation des logiciels libres. Par notre action nous visons à la renforcer. Le recours au logiciel libre est un levier d’action pour moderniser et rationaliser l’action publique.

Le Libre n’est pas toujours la bonne ou la seule solution mais la circulaire du Premier Ministre de septembre 2012 concernant l’utilisation des logiciels libres dans l’administration fixe une ligne claire sur les cas où ces types de logiciels doivent être privilégiés. Les atouts du logiciel libre sont notamment, je cite, « un moindre coût, une souplesse d’utilisation, et un levier de discussion avec les éditeurs ». Il s’agit là d’une avancée majeure pour le logiciel libre dans les systèmes d’information de l’État, qui permet d’engager de véritables politiques publiques en matière de logiciel libre et d’open source.

Pour conclure, je voudrais juste insister sur un point important que j’ai déjà évoqué mais que je tiens à marteler : l’open source est avant tout un vecteur d’innovation et de changement, un véritable gisement de productivité et de compétitivité pour les entreprises, et garantit la pérennité et l’indépendance de l’État. C’est pour cela que je souhaite que la France continue de jouer un rôle moteur dans le développement de ce secteur, et je suis sûre que la présence de Mozilla à Paris nous y aidera. J’ai parlé de 1993, de 2003, quoi de neuf en 2013 ? Cette année Mozilla lance son système d’exploitation pour mobiles et tablettes, Firefox OS, sur le même constat : promouvoir les formats ouverts et empêcher les systèmes fermés de contrôler notre environnement informatique. C’est une ambition un peu folle, mais probablement pas plus folle que de s’attaquer au marché des navigateurs qui était contrôlé à 95% par un seul acteur. Je vous souhaite donc le même succès que Firefox, et comme il sera en partie développé ici, je n’ai pas de doute sur la réussite de ce projet. Merci à tous.

Ce n’est pas Framasoft qui vous dira le contraire, on peut contribuer au logiciel libre et faire ainsi partie de sa communauté sans être nécessairement un développeur de logiciel libre.

Rédiger de la documentation, signaler un bug, traduire, donner, etc. il y a plein de manières de participer, à commencer par les utiliser et le faire savoir.

Comment les non-programmeurs peuvent contribuer aux projets open source

How non-programmers can contribute to open source projects

Duncan McKean – 4 juin 2013 – Blog personnel
(Traduction : « Anonymes », nos excuses car un bug Framapad empêche de citer tous les traducteurs/ices que nous remercions au passage)

Beaucoup de gens intéressés par l’idée d’apporter leur aide à des projets open source mais n’ayant absolument aucune compétence en programmation m’ont demandé ce qu’ils pouvaient faire. Eh bien, voici quelques moyens pour ces non-programmeurs de contribuer à de tels projets.

Il est important de noter qu’il est bon de contribuer aux projets des logiciels que vous utilisez. Ainsi, vous pourrez vous-même bénéficier de vos contributions.

Utilisez le logiciel

Le meilleur moyen de contribuer à des projets open source est d’utiliser les produits eux-mêmes. Écrivez votre livre avec Libre Office Writer. Dessinez vos images avec Krita. Créez des choses à imprimer en 3D avec FreeCAD ou Blender. Réservez vos tickets de concert en ligne via Firefox. Faites vos comptes avec Grisbi. Jouez à Flightgear, Battle for Wesnoth, Vega Strike, UFO : Alien Invasion.

Traquez les bugs

Maintenant que vous utilisez le logiciel, vous pouvez éventuellement rencontrer des bugs quand vous essayez de faire quelque chose. Ou alors, le logiciel peut avoir un comportement autre que celui qui était attendu.

Entrez en contact avec les développeurs et prévenez-les. Les développeurs travaillent sur les retours de leurs utilisateurs, ceci les aide à perfectionner le produit. De plus, les sources étant libres, les bugs sont en général rapidement corrigés.

Chaque projet aura un lien pour signaler un bug. Allez-y, identifiez-vous et décrivez ce bug dans les détails. N’oubliez pas d’indiquer quelle version du logiciel vous utilisez ainsi que les caractéristiques de votre ordinateur.

Écrivez de la documentation

Contribuer à écrire la documentation d’un projet pour le rendre plus clair et plus simple à comprendre.

La plupart du temps, les développeurs sont trop occupés à coder et la documentation a besoin d’un peu d’attention. Vous pouvez la mettre en forme afin qu’elle soit plus claire, ajouter des images ou des tutoriels. Si certaines parties du projet ne sont pas claires, il suffit de demander sur les listes de diffusion. Ainsi, lorsque vous recevrez une réponse, vous pourrez l’ajouter à la documentation. Dès que les personnes qui maintiennent le projet saisiront ce que vous faites, leurs réponses seront encore plus efficaces et utiles.

Traduisez

Il y a beaucoup de personnes dans le monde qui utilisent ce projet et certaines d’entre elles pourraient ne pas parler la langue dans laquelle celui-ci a été distribué. Si vous parlez couramment un langage peu connu, contactez les développeurs/l’équipe de documentation et offrez vos services. Vous pourriez participer à la traduction de l’interface, de la documentation ou encore du site web.

Offrez vos compétences

Regardez les projets individuels et voyez ce dont ils ont besoin. Vous pouvez apporter quelque chose ? Vous êtes designer sonore et pourriez créer quelques sons pour un jeu vidéo open source ? Concepteur d’interface ? Vous pourriez aider en remaniant l’interface utilisateur pour la rendre plus ergonomique. Il est également possible de lancer des entreprises viables utilisant ou formant aux logiciels open source.

Vous pouvez aussi contribuer à la culture du libre en publiant ce que vous créez sous certaines licences Creative Commons. Vos créations peuvent ainsi aider à promouvoir le logiciel pour lequel elles ont été créées. Ceci inclut :

• les images ;
• les programmes ;
• les tutoriels ;
• les manuels d’installation et de documentation ;
• les livres.

Utilisez la licence CC BY-SA pour que chaque réutilisation de votre travail soit elle aussi placée sous licence libre, CC BY si la façon dont il est réutilisé vous importe peu. Vous trouverez plus d’informations à ce sujet sur le site des Creative Commons.

Prêchez la bonne parole

Aider à la prise de conscience des projets open-source est très important. N’agressez pas tout le monde, faites juste savoir quels projets vous utilisez. Créé avec MyPaint sous LinuxMint. Écrit en Sigil sous Ubuntu. Je suis fier d’utiliser WordPress. Toutes ces mentions sont utiles.

Faites des dons

Enfin, leur donner de l’argent. Avec de l’argent, le projet peut embaucher des développeurs supplémentaires qui pourront corriger des bugs plus rapidement, créer de nouveau outils, les améliorer pour vous. Certains projets proposent des dons occasionnels, alors que d’autres vous permettent de payer de petites sommes mensuellement. C’est une meilleure idée car cela aide les développeurs à mieux gérer leurs revenus quand ils savent quelle somme d’argent ils reçoivent de façon sûre.

Soyez professionnel

L’une des principales critiques faites aux logiciels open source est le manque de professionnalisme. Peu importe la manière dont vous contribuez à un projet open source, mettez un point d’honneur à le faire de façon professionnelle. L’élévation du niveau de qualité d’un projet commence avec ses utilisateurs. Assurez-vous que vous agissez de manière professionnelle lorsque vous discutez de projets avec d’autres et créez des contributions de qualité quand vous utilisez des logiciels open source.

Maintenant que vous savez tout ça, lancez-vous et allez aider à rendre les projets open source géniaux.

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