Internet est (devenu) un État policier

Un article qui ne nous apprend à priori rien de nouveau mais dont les exemples et les arguments enchaînés aboutissent à quelque chose d’absolument terrifiant.

Ce n’est pas un cauchemar c’est la réalité. Une réalité, née d’un accord tacite entre le public (les États) et le privé (les multinationales), qui s’est mise en place sans véritablement rencontrer consciences ni oppositions.

Raison de plus pour soutenir tous ceux qui voient le monde autrement et participer à faire en sorte que nous soyons de plus en plus nombreux à réclamer une éthique et faire vivre le bien commun…

Mixer - CC by-sa

Internet est un État policier

The Internet is a surveillance state

Bruce Schneier – 16 mars 2013 – CNN Opinion
(Traduction : Antoine, Neros, Sky, guillaume, audionuma, Asta + anonymes)

Note de la rédaction : Bruce Schneier est un expert en sécurité et l’auteur de Liars and Outliers: Enabling the Trust Society Needs to Survive (NdT : Menteurs et Atypiques : mettre en œuvre la confiance dont la société à besoin pour survivre).

Je vais commencer par trois points factuels.

Un : certains des hackers militaires chinois qui ont été récemment impliqués dans une attaque d’envergure contre le gouvernement et des entreprises des États-Unis ont été identifiés car ils accédaient à leur compte Facebook depuis la même infrastructure réseau qu’ils utilisaient pour leurs attaques.

Deux : Hector Monsegur, un des dirigeants du mouvent hacker LulzSec, a été identifié et arrêté par le FBI l’année dernière. Bien qu’il prenait de fortes mesures de sécurité informatique et un relais anonyme pour protéger son identité, il s’est quand même fait prendre.

Et trois : Paula Broadwell, qui avait une relation extra-conjugale avec David Petraeus, le directeur de la CIA, a également pris de nombreuses mesures pour masquer son identité. Elle ne se connectait jamais à son service de courriel anonyme depuis le réseau de son domicile. À la place, elle utilisait les réseaux publics des hôtels lorsqu’elle lui envoyait un courriel. Le FBI a effectué une corrélation entre les données d’enregistrement de différents hôtels pour y trouver que son nom était le point commun.

Internet est en état de surveillance. Internet est un état de surveillance. Que nous l’admettions ou non, et que cela nous plaise ou non, nous sommes traqués en permanence. Google nous trace, tant sur ses propres pages que sur celles auxquelles il a accès. Facebook fait de même, en traçant même les utilisateurs non inscrits chez lui. Apple nous trace sur nos iPhones et iPads. Un journaliste a utilisé un outil appelé Collusion (NdT : de Mozilla) pour déterminer qui le traçait : 105 entreprises ont tracé son usage internet sur une seule période de 36 heures !

De plus en plus, nos activités sur Internet sont croisées avec d’autres données nous concernant. La découverte de l’identité de Broadwell a nécessité de croiser son activité sur internet avec ses séjours dans des hôtels. Tout ce que nous faisons aujourd’hui implique l’usage d’un ordinateur, et les ordinateurs ont comme effet secondaire de produire naturellement des données. Tout est enregistré et croisé, et de nombreuses entreprises de big data font des affaires en reconstituant les profils de notre vie privée à partir de sources variées.

Facebook, par exemple, met en corrélation votre comportement en ligne avec vos habitudes d’achat hors-ligne. Et, plus encore, Il y a les données de localisation de votre téléphone portable, les enregistrements de vos mouvements par les caméras de surveillance…

C’est de la surveillance omniprésente : nous sommes tous surveillés, tout le temps, et ces données sont enregistrées de façon permanente. C’est ce à quoi un état de surveillance ressemble, et c’est plus efficace que dans les rêves les plus fous de George Orwell.

Bien sûr, nous pouvons agir pour nous y prémunir. Nous pouvons limiter ce que nous cherchons sur Google depuis nos iPhones, et utiliser à la place les navigateurs Web de nos ordinateurs, qui nous permettent de supprimer les cookies. Nous pouvons utiliser un alias sur Facebook. Nous pouvons éteindre nos téléphones portables et payer en liquide. Mais plus le temps passe et moins de gens s’en soucient.

Il y a simplement trop de façons d’être pisté. L’Internet, les courriels, les téléphones portables, les navigateurs Web, les sites de réseaux sociaux, les moteurs de recherche : ils sont devenus nécessaires, et il est fantaisiste d’attendre des gens qu’ils refusent simplement de s’en servir juste parce qu’ils n’aiment pas être espionnés, d’autant plus que l’ampleur d’un tel espionnage nous est délibérément cachée et qu’il y a peu d’alternatives commercialisées par des sociétés qui n’espionnent pas.

C’est quelque chose que le libre marché ne peut pas réparer. Nous, les consommateurs, n’avons pas de choix en la matière. Toutes les grandes sociétés qui nous fournissent des services Internet ont intérêt à nous pister. Visitez un site Web et il saura certainement qui vous êtes; il y a beaucoup de façons de vous pister sans cookie. Les compagnies de téléphones défont de façon routinière la protection de la vie privée sur le Web. Une expérience à Carnegie Mellon a pris des vidéos en temps réél d’étudiants sur le campus et a permis d’identifier un tiers d’entre eux en comparant leurs photos avec leurs photos publiques taguées sur Facebook.

Garder sa vie privée sur Internet est désormais presque impossible. Si vous oubliez ne serait-ce qu’une fois d’activer vos protections, ou si vous cliquez sur le mauvais lien, vous attachez votre nom de façon permanente à quelque service anonyme que vous utilisez. Monsegur a dérapé une fois, et le FBI l’a choppé. Si même le directeur de la CIA ne peut garder sa vie privée sur Internet, nous n’avons aucun espoir.

Dans le monde d’aujourd’hui, les gouvernements et les multinationales travaillent de concert pour garder les choses telles qu’elles sont. Les gouvernements sont bien contents d’utiliser les données que les entreprises collectent — en demandant occasionnellement d’en collecter plus et de les garder plus longtemps — pour nous espionner. Et les entreprises sont heureuses d’acheter des données auprès des gouvernements. Ensemble, les puissants espionnent les faibles, et ils ne sont pas prêts de quitter leurs positions de pouvoir, en dépit de ce que les gens souhaitent.

Résoudre ces questions nécessite une forte volonté gouvernementale, mais ils sont aussi assoiffés de données que les entreprises. Mis à part quelques amendes au montant risible, personne n’agit réellement pour des meilleures lois de protection de la vie privée.

Alors c’est ainsi. Bienvenue dans un monde où Google sait exactement quelle sorte de pornographie vous aimez, où Google en sait plus sur vos centres d’intérêt que votre propre épouse. Bienvenue dans un monde où votre compagnie de téléphone portable sait exactement où vous êtes, tout le temps. Bienvenue à l’ère de la fin des conversations privées, puisque vos conversations se font de plus en plus par courriel, SMS ou sites de réseaux sociaux.

Bienvenue dans un monde où tout ce que vous faites sur un ordinateur est enregistré, corrélé, étudié, passé au crible de société en société sans que vous le sachiez ou ayez consenti, où le gouvernement y a accès à volonté sans mandat.

Bienvenue dans un Internet sans vie privée, et nous y sommes arrivés avec notre consentement passif sans véritablement livrer une seule bataille…

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




Le SCÉRÉN CNDP : showroom Microsoft avec la complicité du Café pédagogique ?

Le « Tour de France du Numérique pour l’Éducation » est officiellement organisé par le Café pédagogique et le service public SCÉRÉN CNDP mais la présence plus ou moins discrète de Microsoft pose question pour ne pas dire problème.

Le Framablog en avait fait écho dès l’annonce de l’évènement dans un billet vindicatif : Tour de France du Numérique pour l’Éducation ou pour Microsoft ?

Pour aller plus loin nous avons décidé de rédiger un communiqué commun avec l’April demandant l’arrêt de l’opération en l’état actuel de son dispositif qui, pur hasard, fait comme si le Libre n’existait pas.

Et en cadeau bonus, une petite comparaison : La page d’accueil de Microsoft Education…

…et la page d’accueil du Tour de France !

Quelle étrange coïncidence 😉

Le service public d’éducation SCÉRÉN CNDP est-il le nouveau showroom de Microsoft avec la complicité du Café pédagogique ?

Paris, le 12 mars 2013. Communiqué de presse.

Le Centre National de Documentation Pédagogique (CNDP) en collaboration avec le Café pédagogique organise une opération nommée « Tour de France du Numérique pour l’éducation »1. Officiellement un « tour de l’Hexagone en 20 étapes pour découvrir les meilleurs projets numériques au service de l’éducation », en réalité une tournée au profit de Microsoft partenaire de l’opération et soutien du Café pédagogique2. L’April et Framasoft demandent que cette opération soit sérieusement amendée en faisant toute la place nécessaire aux logiciels libres et ressources libres pour l’éducation. Des agents de l’État étiquetés « innovants » par on ne sait qui , un service public d’éducation ne peuvent servir de caution morale et pédagogique à une opération qui a pour effet collatéral de contribuer à enfermer élèves et personnels dans un écosystème propriétaire et fermé avec de l’argent public.

Une vision du « numérique » à l’école éloignée de la réalité

Une des principales animations de ces évènements est constituée de « démonstrations des dernières innovations technologiques : tablettes Windows 8, plateformes de communication et collaboration (visio conférence, chat, réseaux sociaux…), expériences immersives grâce à de nouveaux terminaux comme la table Pixelsens… »3 par Microsoft. Au lieu d’une présentation d’une variété de solutions existantes, les évènements sont centrés sur la présentation commerciale unique des produits Microsoft.

Ainsi, aucune place n’est faite pour le logiciel et les ressources libres dans l’éducation, alors même qu’ils en font partie intégrante. De nombreux professeurs, associations et entreprises développent des ressources et des logiciels libres pour l’enseignement4. Si certaines personnes s’en sont émues, présenter la diversité des solutions ne semble pas être la priorité de ces évènements.

Pourtant, l’enseignement et l’Éducation nationale ont beaucoup à gagner du logiciel et des ressources libres. D’abord parce que la mission d’enseignement dévolue aux professeurs est, par définition, basée sur le partage de connaissances. Dans l’intérêt de ses élèves, un professeur doit avoir la possibilité d’utiliser, d’étudier, de modifier, de mettre à la disposition de tous logiciels ou ressources éducatives. Pour fluidifier les échanges, la mutualisation, on se doit d’utiliser des formats de fichiers ouverts et interopérables. Les logiciels et ressources utilisés à l’école doivent pouvoir être utilisés librement au domicile par les élèves, les étudiants ainsi que leurs familles. Le libre est moteur sur ces aspects et en phase avec ces valeurs fondatrices pour l’école de la République.

Le modèle présenté par cette caravane est basé au contraire sur un bridage de l’innovation avec des modèles passéistes basés sur des licences privatrices et restrictives 5, des formats de fichiers propriétaires et fermés voire des brevets sur de la connaissance. Il est donc surprenant et inquiétant de voir le service public se faire le porte-parole de ce seul modèle, en excluant clairement le logiciel libre et les ressources libres pour l’éducation.

Ces étapes se déroulent en grande partie dans les Centre Régionaux de Documentation Pédagogique (CRDP). Fort opportunément pour la campagne de marketing de Microsoft, ils sont dirigés par des personnels qui sont souvent aussi les conseillers TICE6 auprès du recteur d’Académie. Voilà une bonne occasion de présenter ses produits directement auprès des décideurs académiques dans leurs propres locaux. D’ailleurs, les commerciaux de Microsoft Éducation ne se cachent même pas, sur un réseau de micro-blogging, on lit de leur part : « Inscrivez-vous dès à présent à l’une de nos 21 étapes ! »7. On appréciera le pronom possessif.

Le Café Pédagogique, cheval de Troie de Microsoft dans l’éducation ?

Le groupe éducation de l’April et Framasoft s’interrogent depuis longtemps sur les liens entre le Café Pédagogique et Microsoft8. Rappelons que le Café pédagogique représente une source d’information pour de nombreux enseignants, personnels de direction ou décideurs académiques9. Pourtant, on peut s’interroger sur la partialité des informations diffusées notamment dans le domaine des TICE. De fait, on constate que depuis la mise à jour du site réalisée par Microsoft 10, on fait très peu de cas des projets libres, pourtant nombreux, dans la revue quotidienne du Café pédagogique alors que les nouveautés des produits Microsoft sont quant à elles bien mises en avant11.

Selon Rémi Boulle, vice-président de l’April en charge des questions d’éducation : « le Café Pédagogique et Microsoft n’ont pas le monopole de l’innovation dans l’éducation. Un enseignant n’est pas innovant parce qu’il utilise une tablette sous Windows 8 et sait remplir un court dossier de candidature au format Word. Au contraire, il serait urgent de définir ce qu’est précisément l’innovation et ses objectifs : simple promotion commerciale ou ouverture de nouvelles connaissances et possibilités pour les élèves en développant leur esprit critique ? ».

Selon Alexis Kauffmann de Framasoft : « L’expression “enseignant innovant” dérive directement du programme mondial “innovative teachers” de Microsoft12. Le Café pédagogique n’a fait que répondre à la demande de son généreux sponsor en la popularisant, tout en prenant bien soin de taire son origine. Tout ceci n’est qu’un échange de bons procédés entre amis, malheureusement au détriment du développement du logiciel libre, des formats ouverts et des ressources libres dans l’éducation. C’est pour cela que le SCÉRÉN CNDP ne doit pas dérouler le tapis rouge13 à un tel projet mais bien au contraire se montrer critique vis-à-vis des risques de marchandisation de l’école par le logiciel propriétaire, ses pratiques et ses logiques. »

L’April et Framasoft demandent donc au CNDP l’arrêt de cette opération ou, à défaut, qu’elle soit sérieusement amendée pour que toute la place nécessaire aux logiciels libres et ressources libres pour l’éducation soit faite.

À propos de l’April

Pionnière du logiciel libre en France, l’April est depuis 1996 un acteur majeur de la démocratisation et de la diffusion du Logiciel Libre et des standards ouverts auprès du grand public, des professionnels et des institutions dans l’espace francophone. Elle veille aussi, dans l’ère numérique, à sensibiliser l’opinion sur les dangers d’une appropriation exclusive de l’information et du savoir par des intérêts privés.

L’association est constituée de plus de 5 500 membres utilisateurs et producteurs de logiciels libres.

Pour plus d’informations, vous pouvez vous rendre sur le site Web à l’adresse suivante : http://www.april.org/, nous contacter par téléphone au +33 1 78 76 92 80 ou par notre formulaire de contact.

Contacts presse :

Frédéric Couchet, délégué général, fcouchet@april.org +33 6 60 68 89 31
Jeanne Tadeusz, responsable affaires publiques, jtadeusz@april.org +33 1 78 76 92 82

À propos de Framasoft

Issu du monde éducatif, Framasoft est un réseau d’éducation populaire consacré principalement au logiciel libre et s’organise en trois axes sur un mode collaboratif : promotion, diffusion et développement de logiciels libres, enrichissement de la culture libre et offre de services libres en ligne.

Pour plus d’informations, vous pouvez vous rendre sur le site Web à l’adresse suivante : http://www.framasoft.org/ et nous contacter par notre formulaire de contact.

Contact presse :

Alexis Kauffmann, fondateur et chargé de mission, aka@framasoft.org +33 6 95 01 04 55




Le projet, c’est d’abord des personnes (Libres conseils 34/42)

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

Traduction Framalang : Ouve, Julius22, Sphinx, fubik, peupleLà, goofy, KoS, merlin8282, Munrek, Asta, Jej, Alpha, lamessen

L’important, c’est les gens

Nóirín Plunkett

Nóirín Plunkett est une touche-à-tout qui maîtrise plusieurs domaines. Rédactrice technique le jour, son travail open source illustre l’expression « Si vous voulez que quelque chose soit fait, demandez à une personne occupée ». Nóirín a commencé dans l’open source avec Apache, donnant un coup de main sur la documentation du projet httpd. En moins d’un an, elle a été recrutée dans l’équipe de planification des conférences, qu’elle dirige désormais. Elle a participé à la mise en place du projet de développement communautaire chez Apache et a déjà agi en tant qu’administratrice d’organisation pour le Summer of Code. Elle siège aux conseils d’administration de la fondation du logiciel Apache et de l’Initiative Open Cloud. Quand elle n’est pas en ligne, elle est dans son élément naturel sur une piste de danse. Mais c’est également une harpiste et chanteuse talentueuse et une excellente sous-chef (NdT : en français dans le texte).

Rien ne vaut une voie classique, bien que la mienne le soit peut-être moins que la plupart des autres. J’ai fait ma première contribution quand j’avais la vingtaine. À cette époque, j’avais déjà travaillé plus d’un an chez Microsoft. Mais après Microsoft, j’ai déménagé à l’étranger afin de poursuivre mes études. C’était sympathique d’avoir un divertissement, j’ai donc commencé à travailler sur différentes documentations et traductions et j’ai contribué au projet httpd d’Apache.

Comme par hasard, bien sûr, la conférence européenne sur Apache allait avoir lieu à Dublin, alors que, cet été-là, j’étudiais à Munich. Mais la chance sourit aux Irlandais et, avec un peu d’astuce, j’ai convaincu Sun Microsystems de financer ma participation à la conférence.

J’ai une photo du moment où j’ai pris conscience que cette chose appelée open source était bien réelle, et que ça allait changer le monde. C’était pendant la soirée avant la conférence. Nous n’avions toujours pas trouvé où la fibre se terminait, elle était censée constituer la colonne vertébrale de notre réseau. Nous avions vérifié chaque coin, chaque armoire et chaque plinthe, en vain. Nous avions laissé tomber pour cette nuit, et nous étions occupés à nous assurer que les salles qui accueilleraient les sessions de formation auraient au moins suffisamment de connectivité pour que les formateurs puissent utiliser leurs supports de présentation (1).

Et à mesure que la nuit tombait, que les routeurs révélaient lentement les secrets de leurs configurations par défaut, la demi-douzaine de volontaires, des gens que je n’avais rencontrés que dans l’après-midi même, devenaient des amis.

Je ne pourrais pas vous dire où sont les six filles avec lesquelles j’ai vécu pendant cet été-là à Munich. Mais je suis toujours en contact avec chacune des personnes que vous voyez sur cette photo. L’une d’elles a déménagé dans un autre pays, une autre est partie sur un autre continent. La plupart ont changé de travail entre-temps, j’ai eu mon diplôme et je me suis conformée à la grande tradition irlandaise de l’émigration pour trouver du travail.

Vous voyez, l’open source, c’est d’abord des gens. Vraiment, sur presque n’importe quel projet dont vous voudriez faire partie, le code ne vient qu’après.

Ce qui fait que travailler sur un projet est un bonheur et non une plaie, ce sont les gens. Ce qui fait qu’un projet prospère plutôt qu’il ne stagne, ce sont les gens. Bien entendu, vous serez capable de coder toute la nuit pour un projet si ça permet de résoudre un problème que vous pensez être important ; mais, à moins d’avoir des gens avec lesquels vous pouvez collaborer, discuter, concevoir et développer, vous allez probablement finir par perdre la motivation ou vous retrouver bloqué pour un bout de temps.

Les conférences, les sprints, les hackathons, les « retraites » (NdT : une ou plusieurs journées qui se concentrent sur la création de code de très bonne qualité plutôt qu’écrit dans l’urgence) ou tout ce que votre communauté appelle ses « moments de face à face », voilà leur vraie valeur : permettre de se retrouver face à face avec les gens avec lesquels vous avez travaillé. Les êtres humains sont des animaux sociaux ; les bébés reconnaissent des visages avant même de commencer à gazouiller, et peu importe à quel point les gens sont polis ou amicaux dans leurs courriels, il y a toujours quelque chose qui manque dans ces communications-là.

Rencontrer des gens en face à face nous donne une occasion de voir l’humanité de ceux avec qui on a pu avoir du mal à s’entendre, de partager la joie du travail bien fait avec ceux avec qui on aime travailler. Ainsi, si j’avais un conseil à donner à ceux qui commencent, et j’aurais aimé qu’on me le donne, ça serait de sortir, de rencontrer des gens, de coller des noms aux visages dès que l’opportunité se présente (2).

Et si vous trouvez que les occasions sont rares et trop espacées, n’hésitez pas à demander. Cherchez des gens qui voyagent près de chez vous ou qui vivent là où vous voyagez, dénichez un parrainage pour assister aux grands événements de la communauté, organisez votre propre événement !

C’est la richesse de nos communautés qui donne toute sa valeur à l’open source, ainsi que les efforts partagés vers des objectifs communs. Et, bien sûr, les sessions musique, les repas, les pintes et les soirées ! Ce sont les choses qui nous rassemblent, et vous allez découvrir qu’une fois que vous avez rencontré les gens en personne, même vos interactions par courriel seront plus riches, plus gratifiantes et plus fructueuses qu’elles ne l’étaient auparavant.

——————————————————————

Notes de l’auteur :

(1) Le lendemain matin, nous sommes allés dans les combles pour essayer de trouver la fibre, toujours rien. Pour finir, nous l’avons trouvée dans le local technique de la boîte de nuit, située dans le sous-sol à côté.

(2) Malheureusement, je dis ça comme une mise en garde : comme dans tout rassemblement important, assister à une conférence open source présente des risques. Certains pires que d’autres, mais d’après mon expérience, les agressions, particulièrement, semblent plus fréquentes dans les communautés techniques que dans les communautés non-techniques. Dénichez les événements qui publient un code de conduite ou une politique anti-harcèlement et demandez de l’aide si vous ne vous sentez pas en sécurité. La grande majorité des gens que vous trouverez dans un événement open source sont des êtres humains formidables et attentionnés. J’espère qu’avec le temps, changer les attitudes empêchera la minorité de penser qu’elle peut se permettre des comportements déraisonnables dans ce genre de lieux…




Savoir vendre un projet (Libres conseils 33/42)

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

Traduction Framalang :Julius22, Sphinx, fubik, peupleLà, okram, goofy, merlin8282, Munrek, Texmix, Asta, Jej, gregseth, lamessen

Qui êtes-vous, qu’avez-vous à vendre et en quoi ça pourrait m’intéresser ?

Sally Khudairi

Active sur le Web depuis 1993, Sally Khudairi est la publicitaire en embuscade derrière certaines des organisations et des standards les plus importants de cette industrie. Ancienne adjointe de Sir Tim Berners-Lee et championne toutes catégories de l’innovation collaborative, elle a aidé au lancement de The Apache Software Foundation en 1999 et en fut la première femme et membre non-technique élue. Sally est vice-présidente du marketing et de la publicité pour The Apache Software Foundation et directrice générale de HALO Worldwide, une société de conseil en communication pour des marques de luxe.

Tout le monde est vendeur. Du PDG à la star des commerciaux, en passant par le gars qui répartit le courrier, chacun est un représentant de votre entreprise. Les technologies et les stratégies ont changé au fil des années mais une bonne communication reste primordiale. Au bout du compte, tout le monde vend quelque chose, et c’est un équilibre intéressant à trouver dans la publicité ; qui vous êtes, ce que vous faites et ce que vous vendez sont souvent étroitement imbriqués. Quand les gens me disent qu’ils ne savent pas qui je suis, je leur demande s’ils ont entendu parler du W3C, d’Apache ou des Creative Commons.

La réponse habituelle est « bien sûr ! », ce qui me confirme que je fais bien mon boulot. Si vous savez qui ils sont et ce qu’ils font, tout va bien. Après tout, c’est le produit qui compte, pas le publicitaire. Je n’ai jamais cherché à être là : me faire les dents dans la communication à la naissance du Web n’était pas facile, mais grâce au ciel j’ai pu observer les autres et esquiver un certain nombre de torpilles. Après une forte montée en puissance et quelques projets très en vue, quel conseil pourrais-je partager avec un chargé de relations publiques en herbe, avec un porte-parole chevronné rompu à la pratique des médias, ou un technologue qui ose enfourcher le cheval ombrageux de la promotion, malgré ses ruades ?

N’oubliez jamais de vous manifester

Quand vous vendez votre histoire à la presse, souvenez-vous que les médias, eux aussi, ont quelque chose à vendre. Bien sûr, au plus haut niveau, le rôle d’un journaliste est de raconter une histoire irrésistible et convaincante — qu’elle soit vraie ou non, que les faits soient exacts ou non —, qu’elle réponde ou non à une éthique, c’est une autre question. Qu’il s’agisse d’attirer le lectorat, de fidéliser les abonnés ou de promouvoir les espaces publicitaires, eux aussi sont en train de vendre quelque chose. Votre boulot, c’est de les aider à faire le leur. À dire vrai, il est possible que certaines personnes n’aient jamais entendu parler de vous, même si vous êtes dans le métier depuis déjà pas mal de temps. Même si ce n’est pas le cas, ils peuvent ne pas savoir exactement qui vous êtes. Soyez clair sur ce que vous avez à offrir. Quelle est l’accroche pour la presse — quelle est la nouvelle ? Assurez-vous qu’elle est vraiment nouvelle. Soyez direct et venez-en rapidement au fait. Vous devez être prêt à répondre aux questions suivantes : « et alors ? », « En quoi ça pourrait m’intéresser ? » et « Qu’est-ce qu’il y a là-dedans pour moi ? ». Cela veut dire que vous devez vous poser des questions sur vous-même et sur votre produit. Les gens achètent des idées, pas des produits. Faire la promotion des avantages de ce que vous lancez vous aidera à améliorer vos chances d’obtenir une couverture médiatique. Faites un pas de côté : qu’êtes-vous vraiment en train de vendre ?

Jamais le vendredi

Le pire des jours pour lancer un nouveau site web, diffuser un communiqué de presse ou informer les médias, c’est le vendredi. La probabilité qu’il se passe quelque chose et que personne ne soit disponible pour gérer les retombées est plus importante que vous ne pouvez l’imaginer. J’en ai eu une cuisante expérience dès le début de ma carrière. J’avais lancé la nouvelle page d’accueil du W3C un vendredi soir puis quitté le bureau et embarqué dans un avion pour Paris. Comme je venais du monde de la publication commerciale sur Internet, utiliser un tag propriétaire ne me posait aucun problème à partir du moment où il faisait le travail. Faire de même sur le site internet d’une organisation vouée à l’interopérabilité, en revanche, n’était pas une bonne idée. En quelques minutes, des douzaines de messages arrivèrent, demandant comment la <balise-aujourd’hui-dépréciée> était arrivée sur notre site. Et non, ça n’était pas <blink>…

N’imaginez jamais que cela n’a aucune importance

La crédibilité est essentielle. Même si vous êtes surchargé de travail, dévoué corps et âme ou partout à la fois, vous ne pouvez pas empêcher l’heure de sonner. Essayez de produire autant que vos capacités vous le permettent et demandez de l’aide si vous le pouvez. Certaines échéances doivent être négociées, et beaucoup d’éditeurs peuvent s’accommoder d’un retard dans le calendrier mais cela n’aura probablement pas (autant) d’importance une fois l’urgence passée si vous n’êtes pas capable de finir le travail. Tout comme pour l’art, le développement de standards et la relecture-correction, le processus peut se poursuivre et recommencer ad nauseam. Tandis que la créativité ne peut pas être gérée par le temps, des dates butoir strictes obligent à tracer une limite à un moment donné. Mais vous devez vous soucier des détails. Arrêtez-vous. Révisez tout et testez tous les liens. Assurez-vous que cela correspond parfaitement à la stratégie de la campagne ou de la marque. Les cycles de répétition font partie des grands principes structurants de la communication et le travail continuera à s’accumuler. Organisez-le et protégez votre réputation.

Allez-y seul

Il est important d’avoir confiance en vos instincts, spécialement lorsque vous sortez des sentiers battus. Aux premiers jours du Web supercool et ultramoderne, tout le monde semblait s’en remettre aux stratégies habituelles des marques/relations publiques/marketing qui consistaient à faire des sites vitrines. Puis tout le monde « suivait le meneur » (le meneur est « le premier à l’avoir fait », dans de nombreux cas). Les tendances sont une chose, les attentes et les besoins de l’industrie en sont une autre : « c’est comme ça que tout le monde fait » ne veut pas dire que c’est bien pour vous, votre projet ou votre communauté. Ma carrière dans la communication a commencé lorsque j’ai renvoyé le sous-traitant que nous avions choisi et tout ramené en interne.

Nous avons été parmi les premières organisations à mettre une adresse URL sur notre plaquette commerciale, et nous avons été les premiers à utiliser une URL comme source d’un communiqué de presse alors que les agences de presse nous disaient que cela n’était pas conforme et contraire aux règles. Faites confiance à vos connaissances. Allez à contre-courant et bousculez les règles de manière responsable. Sachez vous différencier. Il est permis d’être un dissident tant que vous pouvez soutenir vos idées.

Offrez vraiment des perspectives

Bon nombre des technologies dans lesquelles je suis impliquée finissent en produits au bout de trois à cinq ans. Ceci signifie que, dans bien des cas, il est difficile d’établir une quelconque relation à un produit comparable. Il est crucial que vous expliquiez clairement votre position en utilisant le moins de jargon possible. La plupart des journalistes et analystes non-développeurs avec lesquels je suis en contact ne suivent pas les activités d’une certaine communauté au quotidien et ne savent pourquoi telle fonctionnalité est meilleure qu’une autre, même si c’est une évidence pour vous.

Dire qu’on va « privilégier la forme plutôt que le fond » est plus pertinent aujourd’hui que jamais. Forme. Fond. Je marque toujours une séparation à ce sujet lorsque je fais de la formation aux médias : présentez trop le fond ou trop la forme et votre campagne risque d’échouer. La perception est fondamentale et la cause de bien des conflits. Tout sur la forme = « branché + hyperbole » = « Ah, ces marketeux ! ». Tout sur le fond = « des zéros et des uns » = « Ah, ces geeks ! ».

Il vous faut comprendre et pouvoir expliquer clairement quel est le problème que résout votre produit. En sachant mieux présenter le problème, vous pourrez mieux en expliquer la solution. Les détails accessoires, les anecdotes et les succès, voilà ce qui donne à la presse un moyen d’attirer l’attention de son lectorat. Vous devez savoir répondre à la question « Qu’y a-t-il pour moi là-dedans ? », parce que c’est ce qui incite les journalistes à fouiller un peu plus dans votre histoire, qui, en retour, permet aux lecteurs d’en savoir plus sur vous. La forme répond à la question « Qu’y a-t-il pour moi là-dedans ? », c’est donc l’hameçon. Le fond est le comment on y parvient.

Ayez des porte-parole sur la brèche

Ayez toujours quelqu’un de disponible pour parler à la presse. Oui, ça peut être vous, mais sachez qu’il y aura un moment où, même si vous avez une histoire bien planifiée à raconter, vous pourriez ne pas être disponible. Avec qui d’autre travaillez-vous ? Qui vous connaît ? Qui vous soutient ? Définir ces personnes et distribuer les rôles pour clarifier qui dit quoi contribue beaucoup à diminuer les maux de tête potentiels. J’agis habituellement en tant que porte-parole d’arrière-plan afin de pouvoir passer du temps avec un journaliste pour trouver ce qu’il recherche spécifiquement et comment nous pouvons lui donner les informations pertinentes du mieux possible.

J’explique comment les choses fonctionnent, principalement sur les processus ; cela met mes « vrais » porte-parole en meilleure position pour dire quels sont leurs besoins et minimise le risque de perdre leur participation en chemin. Préparer les bonnes personnes est aussi important que de les rendre disponibles. Pendant mes cours de formation aux médias, je mets quelques diapositives « surprenantes » qui soulignent les leçons particulièrement intéressantes apprises au fil des ans.

Nous avons par exemple connu une pagaille de représentants dans les premiers jours de l’incubateur Apache, où 15 personnes ont répondu à une demande de la presse en 48 heures… beaucoup d’opinions, mais qui était la « bonne » personne à citer ? Ne laissez pas la presse en décider ! Un autre scénario suprenant comprenait une fête de lancement globale avec des centaines d’invités, des représentants de la presse partout, des DJ, de la musique à fond, des cocktails à flot, et tout ça durerait jusqu’à très tard dans la nuit avec des rumeurs de soirées en after.

Très tôt le matin suivant, la presse a débarqué (oui, bien sûr, j’accepte les appels du Financial Times à quatre heures du matin !). J’ai accepté avec excitation. Cependant, il s’avéra que nous n’avions pas de représentant disponible : le président était dans un avion à destination du Japon, le téléphone portable du directeur était éteint (avec une bonne raison, apparemment) ; les membres du conseil d’administration indisponibles, l’équipe non préparée. Des dizaines d’occasions manquées. Rappelez-vous : quand le communiqué de presse est diffusé, le travail commence tout juste.

Ne soyez pas surpris de le voir affluer de partout

Ils ont tous un avis. Et ils vont probablement vous le donner.

Ne compliquez pas les choses à outrance

Si vous pensez que vous avez trop de choses à dire, c’est probablement le cas. Les facultés d’attention ne sont plus ce qu’elles étaient ; la distraction/l’échec est à portée de clic. Rappelez-vous que vous pouvez toujours travailler par étapes. Décomposez votre histoire si nécessaire. Coupez un long communiqué de presse et utilisez des supports documentaires comme des fiches de description technique et des pages de témoignages à la place. Le principe de segmentation (« cinq plus ou moins deux ») est quelque chose que j’utilise encore et encore. Créez votre propre cycle de publication pour vos messages et renforcez régulièrement votre présence. Créez une FAQ ; si une question mérite d’être posée et n’y est pas, trouvez le moyen de compléter votre message. La répétion engendre la familiarité. Le renforcement progressif de votre appel à l’action est une bonne chose.

N’y touchez plus pendant 24 heures

Parfois, vous avez besoin de prendre du champ. Vous éloigner d’un projet, d’un raisonnement, du travail en général. Accordez-vous une pause et essayez de garder un certain rythme. Prenez une journée pour laisser décanter et vous permettre de souffler. Bien que ce ne soit pas possible dans une entreprise gouvernée par les dates butoir, c’est un but à viser. La course effrénée, les courriels incessants et les tweets en continu déclenchent souvent des réactions à des urgences qui n’existent pas. Laissez le projet de côté, videz-vous la tête et revenez avec des idées claires. Faites un pas de côté et reprenez votre vie en main.

Visez haut

Placez haut la barre et soyez conscient de votre valeur.




Coordonner les flux de contributions (Libres Conseils 30/42)

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

Traduction Framasoft : merlin8282, Sphinx, Julius22, goofy, Corentin, lerouge, Asta, peupleLà, okram, Alpha, lamessen

Au confluent de l’amont et de l’aval

Vincent Untz

Vincent Untz est un activiste passionné du logiciel libre, un amoureux partisan de GNOME, ainsi qu’un élément moteur d’openSUSE. Il a été responsable des versions de GNOME de 2008 à 2011, jusqu’à la sortie de GNOME 3.0 ; il a été directeur exécutif de la fondation GNOME (2006-2010) et il dirige l’équipe GNOME chez openSUSE. Quoi qu’il en soit, il trouve plus simple de se décrire comme un « touche-à-tout » (NdT : en français dans le texte) et il travaille dans divers services (certains diraient au petit bonheur la chance) du bureau pour aider openSUSE à rester extraordinaire. Vincent continue à faire du forcing pour que le français soit la langue officielle de GNOME et espère bien réussir bientôt. Sinon, il aime la crème glacée.

Il y a bien longtemps, dans une chambre, la nuit…

J’étais en train de jeter un dernier coup d’œil sur une liste de bogues pour voir si je n’avais pas oublié de fusionner un correctif. Je m’étais bien assuré d’écrire ce que je pensais être une entrée NOUVEAUTÉS au sujet de la nouvelle version. J’ai entré make distcheck (NdT : commande GNU permettant de créer un paquet et de le tester automatiquement dans un répertoire différent de celui de développement pour démarrer le processus de diffusion) et je regardais la console afficher des centaines de lignes. Une archive avait été créée, et j’ai à nouveau vérifié que l’archive se construisait correctement. J’ai vérifié, encore et encore : j’étais inquiet. D’une certaine manière, je ne faisais pas totalement confiance à la commande make distcheck. Après avoir tout vérifié plusieurs fois, j’ai envoyé l’archive sur le serveur et expédié un courriel d’annonce.

J’avais réussi à le faire : j’avais sorti ma première archive d’un logiciel sur le développement dont j’étais récemment devenu co-responsable. Et j’ai certainement pensé : « Ah, maintenant les utilisateurs vont pouvoir apprécier un bon truc ! ». Mais à peine quelques secondes après le chargement de mon archive, quelques personnes l’ont téléchargée et ont rendu ma version réellement accessible aux utilisateurs.

C’est une chose que je tenais pour acquise, car je pensais que c’était une tâche banale. J’avais tort.

Amont et aval

De nombreuses personnes participent au processus d’acheminement du logiciel. Et cet effort se répartit généralement entre deux groupes de personnes d’égale importance dans la manière dont fonctionne le logiciel libre aujourd’hui.

En amont : c’est le groupe qui crée le logiciel. Il inclut évidemment les programmeurs mais, en fonction du projet, d’autres catégories de contributeurs sont également essentielles : designers, traducteurs, rédacteurs de documentation, testeurs, trieurs de bogues, etc. En général, l’amont se charge seulement de livrer le code source sous forme d’archive.

En aval : c’est le groupe responsable de la distribution du logiciel aux utilisateurs. Tout comme en amont, les contributeurs ont une gamme de profils très variée et travaillent à la traduction, la documentation, les tests, le triage de bogues, etc. Il y a cependant un profil qui, jusqu’à présent, est spécifique au travail en aval : le packager, qui prépare le logiciel afin de le rendre disponible sous forme de paquet, un format mieux adapté à un usage facile que le seul code source.

Chose intéressante, les utilisateurs ont plutôt bien l’intuition de cette séparation également, bien que nous n’en soyons pas conscients : nous supposons souvent que les développeurs de logiciels sont inaccessibles et nous envoyons plutôt nos retours et demandes d’aide aux distributeurs.

Pour éclairer cette séparation entre amont et aval, une analogie parlante et classique est celle du circuit des biens de consommation, avec les magasins de détail (« l’aval ») qui distribuent des produits manufacturés (« l’amont ») et jouent un rôle important pour les clients (« les utilisateurs »).

Un regard plus attentif sur l’aval

Si je devais résumer le rôle de l’aval en une phrase, voici comment je le décrirais :

L’aval est le pont entre les utilisateurs et l’amont.

Lorsque j’ai sorti ma première archive en amont, je supposais que, pour l’aval, le travail consisterait principalement à compiler la source pour construire un paquet avec, et rien d’autre. Construire un paquet est effectivement la première étape. Mais c’est seulement le début du voyage vers l’aval : différentes tâches viennent ensuite. Certaines sont purement techniques tandis que d’autres sont sociales. Je vais me contenter de décrire très brièvement ce voyage ici, de manière non-exhaustive, puisque ça pourrait faire l’objet d’un chapitre entier de ce livre (1).

La construction du paquet proprement dit peut se révéler moins triviale que prévu. Il n’est pas rare qu’un packager rencontre des problèmes qui étaient inconnus de l’amont. Comme lorsqu’une nouvelle version du compilateur est utilisée (avec de nouvelles erreurs), qu’une bibliothèque spécifique a d’abord besoin d’être mise à jour (parce que l’archive utilise de nouvelles interfaces de programmation) ou bien que le système de compilation de l’archive est conçu pour une certaine façon de fonctionner (qui ne suit pas les directives de la distribution cible). Ce qui est encore plus méconnu par beaucoup est le fait que tous ces problèmes peuvent également se produire après que l’archive a déjà été empaquetée, comme lors de la migration d’une distribution entière vers un nouveau compilateur ou bien une nouvelle chaîne de compilation. Aucun de ces problèmes techniques n’est vraiment compliqué à résoudre en lui-même, et l’amont est souvent content de contribuer à la solution. Mais sans l’aval, ces problèmes pourraient ne pas être remarqués par l’amont avant un long moment.

Ce qui selon moi est plus important que ces défis techniques, c’est que l’aval est généralement en contact avec davantage d’utilisateurs que l’amont. Cela se traduit par des rapports de bogue, des demandes de support, des requêtes de changement de la configuration par défaut ou bien d’autres choses encore. C’est là que la foule en aval donne la mesure éclatante de sa force : au lieu de simplement transférer ça en amont, l’aval va travailler sur les retours des utilisateurs afin de ne renvoyer que des synthèses qui seront utilisables en amont. Bien souvent, les rapports de bogue sont soumis avec trop peu d’informations sur le problème (auquel cas l’aval demandera plus de détails). Souvent, les demandes de support sont issues d’une incompréhension du côté de l’utilisateur (ce que l’aval peut, parfois, traduire par une suggestion visant à modifier le programme afin d’éviter cette incompréhension). Souvent, de nouveaux paramètres par défaut sont suggérés sans réflexion suffisante (l’aval travaillant alors avec les utilisateurs pour voir si le raisonnement est valide). À partir de cette énorme quantité de données, l’aval produira un ensemble d’informations plus compact que l’amont sera en mesure de digérer facilement. Ce qui amènera à des améliorations sur le logiciel.

Il existe généralement deux récompenses pour les contributeurs en aval : les contributions directes et indirectes vers le projet en amont grâce aux efforts effectués par l’aval sont suffisantes pour beaucoup. Mais plus important encore, le contact direct avec davantage d’utilisateurs amène à recueillir la satisfaction qu’ils expriment. Et une situation aussi gratifiante rend facilement heureux beaucoup de gens.

Une petite note au passage : lorsqu’on considère la quantité de travail fournie en aval, je ne serais pas surpris qu’au bout du compte, beaucoup de contributeurs en amont soient bien contents d’avoir des gens agissant comme intermédiaires : cela diminue significativement la quantité de retours tout en améliorant leur qualité (en évitant les commentaires en double, les problèmes non documentés, etc.). Cela permet à ceux qui travaillent en amont de rester focalisés sur le développement lui-même, au lieu de les obliger à soit trier les retours, soit les ignorer.

Rien qu’en regardant mon expérience en amont, je ne compte plus le nombre de correctifs que j’ai reçus de l’aval pour résoudre des problèmes de compilation. Je me rappelle aussi d’innombrables discussions que j’ai eues à propos des bogues qui affectaient le plus les utilisateurs et qui m’ont permis de prioriser mon travail. De fait, depuis que j’ai rejoint les équipes en aval, j’ai commencé à faire remonter des correctifs proches de ceux liés à des problèmes de compilation à l’amont et à discuter avec ma base en aval pour transmettre des retours d’expérience d’utilisateurs. Une telle collaboration amont-aval participe à l’amélioration de la qualité générale de notre écosystème du logiciel libre et je la considère comme essentielle à notre bonne santé.

Remonter de l’aval vers l’amont !

Je crois fermement que, pour qu’un projet réussisse, il faut qu’il y ait une forte collaboration amont-aval. Je doute que beaucoup désapprouvent. Cependant, par « aval », les gens pensent généralement au travail fait dans les distributions. Mais, particulièrement pour les applications, il devient de plus en plus viable de pousser ce travail fait en aval en dehors des distributions et de tirer parti d’un tel mouvement vers l’amont.

Des outils comme l’Open Build Service (NdT : distribution open source dédiée à la compilation de paquets pour diverses distributions GNU/Linux) permettent plus facilement d’avoir des personnes qui compilent et distribuent des paquets d’une application pour plusieurs distributions. Cela présente des avantages à la fois pour les utilisateurs (qui peuvent profiter plus rapidement et plus facilement des mises à jour de leurs applications préférées) et pour l’amont (qui peut aider à construire une relation plus forte avec sa base d’utilisateurs). Le seul défi qu’un tel mouvement représente est le besoin perpétuel d’avoir quelqu’un qui s’occupe de l’empaquetage, mais aussi qui gère des retours plus nombreux des utilisateurs. Dans les faits, il y a toujours besoin de quelqu’un pour faire le travail de l’aval, sauf qu’il serait fait au sein de la branche amont.

Pour moi, cela semble une perspective excitante et j’irais même plus loin en suggérant que nous, la communauté du logiciel libre, devrions migrer lentement le travail d’aval fait sur les distributions vers un travail d’aval fait directement, aussi souvent que possible, en amont. C’est souvent possible, au moins pour les applications. Cela requiert évidemment de penser différemment. Mais ça permettrait de partager un travail qui, actuellement, est le plus souvent dupliqué sur toutes les différentes branches en aval.

Pour ceux qui souhaitent actuellement commencer à contribuer aux applications qu’ils apprécient, ce travail sur les paquets en amont est une toute nouvelle approche qui pourrait vraiment être une réussite !

J’ai essayé, je suis resté. Pourquoi pas vous ?

L’aval a toujours été essentiel à ma vie en tant qu’utilisateur de logiciels libres — après tout, seules quelques personnes installent manuellement leur système à partir de zéro et je n’en fais pas partie. Cependant, c’est aussi devenu un atout pour moi en tant que développeur en amont, étant donné que j’ai commencé à prendre plus de temps pour discuter avec des personnes en aval afin d’obtenir plus de retours sur les bogues, les fonctionnalités, la qualité générale et même les directions futures du logiciel sur lequel je travaillais.

C’est seulement lorsque j’ai commencé à être moi-même en aval que j’ai compris que cette position est en effet privilégiée afin de conseiller en amont, grâce au contact direct avec les utilisateurs et la perspective différente que l’on retient de cette position différente.

Sans l’aval, nous ne serions pas là où nous sommes aujourd’hui. Si vous souhaitez avoir un impact significatif, soyez persuadé qu’en participant en aval et en discutant avec l’amont, vous réussirez.

Et vous y prendrez du plaisir.

(1) Note de l’auteur : Il est bon de mentionner que je ne crois pas que l’aval devrait modifier significativement le logiciel mis à disposition par l’amont. Certains, en aval, le font tout de même et cela s’ajoute à leur charge de travail.




Préparer un logiciel à sa diffusion (Libres conseils 29/42)

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

Traduction Framalang : merlin8282, Sphinx, Julius22, goofy, lerouge, lamessen, Asta, peupleLà, okram

Packager : la voie royale du logiciel libre

Thorn May

Thom May est développeur Debian et membre émérite de la fondation Apache. Il a été parmi les premiers à être engagés chez Canonical, l’entreprise mère d’Ubuntu. Il vit aujourd’hui à Londres et dirige l’unité de développement chez MacMillan Digital Science.

Introduction

Ça fait plus de dix ans que j’ai débuté dans le monde du logiciel libre. J’avais utilisé Debian pendant quelques années à l’université et décidé que je voulais donner quelque chose en retour. J’ai donc commencé un long voyage à travers les étapes permettant de devenir un « nouveau responsable Debian » sans avoir jamais vraiment contribué au logiciel libre auparavant et inquiet qu’un manque d’expérience en C pourrait se révéler être un gros problème.

Il s’avéra que cette inquiétude était largement infondée. En commençant à travailler avec des paquets que j’utilisais régulièrement, j’ai pu contribuer efficacement. En même temps que mon expérience avec la myriade d’outils et de systèmes que Debian fournit à ses mainteneurs s’accroissait, je devenais plus efficace pour gérer mon temps et j’étais capable de travailler sur un ensemble de paquets plus étendu.

M’occuper de davantage de paquets m’amena à travailler avec un ensemble plus important de systèmes de compilation, de langages de programmation et de boîtes à outils. Cela m’aida également à m’intégrer à la communauté Debian. Aussi rugueuse et dogmatique soit-elle, le fait que la communauté Debian repose sur des mainteneurs doués et expérimentés est l’une des raisons principales pour lesquelles Debian a maintenu son excellence technique sur une si longue période.

À peu près à ce moment, le projet Apache httpd approchait enfin des premières versions bêta de httpd 2.0 qui était restée des années en chantier et était sur le point de subir une mise à jour majeure. L’équipe Apache de Debian avait été plutôt inactive depuis quelques temps — les paquets de la version 1.3 étaient stables et changeaient peu — et n’avait pas prévu d’empaqueter la version 2.0. J’avais un intérêt majeur à garantir que les paquets httpd étaient bien maintenus. Je travaillais comme administrateur système en charge de nombreux serveurs web Apache, il tombait donc sous le sens que je devais relever le défi de la production de paquets pour la nouvelle version.

Avec un ami, nous avons commencé le travail sur les paquets et nous avons rapidement découvert que, alors que le code approchait le niveau de qualité d’une bêta toute fraîche, l’outillage autour de la compilation et de la personnalisation de httpd était hélas manquants, ce qui est assez représentatif de bien des projets logiciels complexes.

Au cours de la majeure partie de l’année — alors que les développeurs en amont stabilisaient leur code et qu’un nombre croissant d’utilisateurs précoces commençaient à tester et à déployer la nouvelle version — nous avons travaillé dur pour garantir que le système de compilation soit suffisamment flexible et robuste pour satisfaire aux rigoureux prérequis de la politique de Debian. Nous devions non seulement garantir que nos paquets étaient techniquement corrects, mais également nous assurer que notre relation avec les développeurs en amont nous permettait de leur faire remonter des correctifs dès que possible, de les avertir dès que des problèmes de sécurité faisaient surface et de leur transmettre les tests préliminaires des versions candidates.

Mes interactions avec Apache pendant l’empaquetage et la maintenance de httpd 2.0 m’ont amené à m’engager en amont du projet, ce qui signifiait que je pouvais directement contribuer au code. C’est, en général, la dernière étape avant de passer de l’empaquetage d’un logiciel à son développement actif à destination d’un public plus large que celui de votre distribution. À titre personnel, cette reconnaissance m’a donné la confiance pour contribuer à bien plus de projets libres puisque je savais que mon code était de qualité suffisante pour être bien accueilli.

L’évolution, du packager au développeur

Comment est-ce arrivé ? La création de paquets, dans sa forme la plus simple, permet d’assurer qu’un projet logiciel donné se conforme à la politique de la distribution ; dans mon cas, Debian. De manière générale, cela signifie configurer le logiciel au moment de la compilation afin qu’il soit installé dans les répertoires idoines spécifiés par le Filesystem Hierarchy Standard, ou FHS (NdT : Norme de la hiérarchie des systèmes de fichiers), que les dépendances aux autres paquets soient correctement spécifiées et que les logiciels fonctionnent normalement sur la distribution.

La création de paquets complexes peut nécessiter la division d’un projet en amont en de multiples paquets. Par exemple, les bibliothèques et les fichiers d’en-tête permettant à l’utilisateur de compiler le logiciel avec leur bibliothèque sont fournis dans des paquets distincts, et des fichiers dépendant de la plate-forme peuvent être fournis séparément de ceux qui en sont indépendants. S’assurer que le logiciel en amont se déploie correctement dans ces situations nécessitera souvent des changements dans le code. Ces changements sont la première étape vers un travail actif sur un projet, plutôt que le travail parfois passif de création de paquet.

Une fois que votre paquet est disponible dans la distribution, il est exposé à des millions d’utilisateurs potentiels. Ces utilisateurs vont sans aucun doute exécuter votre logiciel selon des pratiques que ni vous, en tant que packager, ni vos développeurs en amont n’aviez prévues. Sans surprise, avoir de nombreux utilisateurs implique l’arrivée de nombreux rapports de bogue. Debian, comme la plupart des distributions, encourage ses utilisateurs à lui soumettre directement les rapports de bogue plutôt qu’à chacun des projets individuels en amont. Ceci permet aux mainteneurs de trier les rapports de bogue et d’assurer que les modifications effectuées lors du processus de création de paquet ne sont pas la cause du problème rapporté. Souvent, il peut y avoir un grand nombre d’interactions entre le rapporteur du problème et le mainteneur du paquet avant que les développeurs en amont ne soient impliqués.

Au fur et à mesure que le mainteneur du paquet accroît sa connaissance du projet, il sera en mesure de résoudre directement la plupart des problèmes. Le mainteneur publiera souvent des correctifs de bogue directement dans Debian tout en les faisant remonter en amont, permettant ainsi à la fois une résolution rapide des problèmes et de nombreux tests de correctifs. Une fois qu’un correctif est validé, le mainteneur travaillera alors avec le projet amont pour s’assurer que les changements requis y ont bien lieu, de manière à ce qu’ils soient disponibles aux autres utilisateurs du logiciel.

Fournir des correctifs de bogue réussis pour des distributions telles que Debian relève souvent d’une forme complexe d’art. Debian fonctionne sur de nombreuses plates-formes, allant des gros serveurs IBM aux smartphones, et la gamme ainsi que la largeur de ces plates-formes révèlent rapidement les approximations dans le code. L’empaqueteur a, la plupart du temps, un accès plus aisé à une gamme de plates-formes plus étendue que les développeurs en amont et constitue, de ce fait, le premier point d’appel quand un problème épineux de portage apparaît. On apprend rapidement à reconnaître les symptômes d’une approximation de la taille d’un pointeur, les problèmes avec les endianness et bien d’autres problèmes ésotériques ; cette expérience permet de devenir un programmeur à la fois plus polyvalent et plus prudent.

Lorsqu’un paquet reçoit des corrections de bogues et des améliorations, il est essentiel que ces changements remontent en amont. Trop souvent, la différence entre un paquet et le logiciel définitif en amont peut s’accroître énormément, avec pour conséquence que les deux bases de code deviennent presque entièrement distinctes. Non seulement, cela alourdit la tâche de la maintenance des deux côtés, mais cela peut aussi créer une immense frustration et faire perdre beaucoup de temps en amont dans le cas où un utilisateur de votre paquet rapporte un bogue lié à l’un des changements dans la version empaquetée en amont. Il est en conséquence vital que s’établissent une relation de travail étroite avec la branche amont et une compréhension de la meilleure façon de collaborer entre les deux parties.

La collaboration entre les développeurs et le packager peut prendre bien des formes. Que ce soit trouver la bonne voie pour communiquer les rapports de bogue, s’assurer de l’utilisation du bon style de codage, du même usage du système de contrôle de version ou des interactions qui provoquent le moins de frictions possible. Tout ceci amène une bien meilleure relation avec l’amont et accroît grandement la probabilité que ceux qui y travaillent prendront le temps de vous aider quand vous en aurez besoin.

Une fois que la relation de travail entre l’amont et vous est établie, il devient facile de contribuer plus directement en amont. Ceci peut également se faire de bien des façons différentes. Les premières étapes, simples, peuvent impliquer la synchronisation de n’importe quel rapport de bogue en amont avec ceux de votre distribution, afin d’être sûr que ce double effort impacte la cause primaire et résolve des bogues. Une implication plus directe consiste à développer des fonctionnalités et à changer plus largement que ce qui serait acceptable dans le cadre d’une version empaquetée.

Conclusion

Je pense que les deux choses essentielles que j’aurais aimé connaître lorsque j’ai commencé sont le sens de la communauté que le logiciel libre fait naître et la merveilleuse voie que le packaging de logiciel libre ouvre vers le plus vaste monde du logiciel libre

La communauté est essentielle au succès du logiciel libre. Elle se présente sous différentes formes, de la multitude d’utilisateurs souhaitant investir du temps dans l’amélioration de votre logiciel, jusqu’aux pairs d’une distribution ou d’un projet logiciel, qui investissent leur temps et leur énergie à affûter vos compétences et à s’assurer que vos contributions sont aussi bonnes que possible.

La voie qui part du packaging pour aller vers le développement est l’une des plus empruntées. Elle présente une courbe d’apprentissage moins raide qu’aborder directement le développement et permet d’acquérir des compétences à un rythme moins soutenu qu’en suivant d’autres chemins.




Dialogue Pouhiou Calimaq sur le domaine public et plus parce qu’affinités

Pouhiou est notre joyeux et émérite premier romancier chez Framabook. À l’occasion de la sortie prochaine du livre II du cycle des NoéNautes, il a lancé une originale campagne de crowdfunding sur Ulule qui a fait réagir le blogueur influent (parce que brillant) Calimaq.

Ce dernier s’est en effet aventuré à parier que si cette campagne aboutissait alors il élèverait lui aussi son blog dans le domaine public via la licence Creative Commons CC-0. Bien mal lui en a pris puisque la campagne vient déjà de dépasser la barre escomptée (Pouhiou vous en remercie en vidéo ici) et se poursuit d’ailleurs…

Chose promise, chose due donc, et prétexte surtout à un passionnant entretien dialogue entre deux personnalités fortes du « Libre » francophone.

Je cède la parole à Pouhiou, et ça tombe bien car il adore la prendre 😉

monorchide-chaton02-ulule.jpg

En lançant le blog de mon roman feuilleton, j’ai eu d’instinct l’envie que cette histoire appartienne à ses lecteurs. Qu’ils s’en emparent. C’était une certitude que je ne savais pas comment appliquer dans les faits. M’intéressant au livre et au droit d’auteur, je suivais déjà le blog S.I.Lex écrit par un certain Calimaq. Ce mec, passionné et passionnant, arrive à transformer un sujet à priori lourd et chiant (la propriété intellectuelle) en une épopée rocambolesque. A force d’exemples, de décryptages, de coups de sang et de coup de cœur, il nous plonge dans les eaux du copy-right-left-up&down, on baigne en Absurdie et l’on ressort de son blog plus juriste qu’on y est rentré… sans même s’en apercevoir.

Un de ses billets m’a fait prendre conscience que la place de mes œuvres était dans le domaine public. J’ai donc passé tous mes écrits sous la licence CC0 et l’ai chaudement remercié dans cet article.

Il est né de cet échange une amitié intellectuelle. Calimaq s’est mis à défendre et mon œuvre, et la démarche qui l’accompagnait. Je me suis engagé dans SavoirsCom1, un collectif qu’il a co-fondé pour la défense des biens communs informationnels. Je ne compte plus les fois où l’on s’est dit « merci », tant chacun semble admirer et être complice de ce que fait l’autre. C’est ce genre d’émulation où la réflexion de l’autre nourrit la tienne, et te mène un poil plus vite, un poil plus loin que là où tu te serais rendu tout seul.

Quand, avec Framasoft, on a initié ce crowdfunding fou (toujours en cours sur Ulule) pour que le lancement de #MonOrchide (livre II des NoéNautes) puisse financer la distribution gratuite d’exemplaires de #Smartarded (le livre I), Calimaq a répondu présent. Il a fait un bel article pour promouvoir cette expérience . Mais, chose inattendue, il a ajouté ce post-scriptum explosif :

PS : allez, moi aussi, je mets quelque chose dans la balance. Si Pouhiou réussit son pari, je passe S.I.lex en CC0. Ceci n’est pas une parole en l’air !

Le pari est réussi. En 22 jours, on a atteint les 2200 € qui nous permettront de distribuer au moins 32 exemplaires de #Smartarded. Grâce à une mobilisation peu commune il ne nous a fallu que la moitié des 45 jours prévus (ce qui veut dire qu’il reste trois semaines pour battre tous les records et accroître le nombre de livres à distribuer !)

Le pari est réussi, et S.I.Lex devient un dommage collatéral : Calimaq tient sa part du contrat, élevant son blog dans le Domaine Public Vivant. Je sais que, le connaissant, ce n’est pas un geste anodin. Une belle occasion de discuter avec lui de licences, d’écriture, et de qu’est-ce que ça veut bien dire, toutes ces choses-là…

2012-12-08_19.23.44.JPG

Pouhiou : Tu m’as fait un super article sur ton blog S.I.Lex, qui a été repris par ActuaLitté. Cela m’a beaucoup aidé à faire connaitre le projet. C’était déjà énorme (merci ^^). Pourquoi avoir en plus ajouté la licence de ton blog dans la balance ?

Calimaq : Cela fait un moment que je m’intéresse à ce que tu fais autour du cycle des Noenautes et d’après ce que tu as écrit sur ton blog, un des billets que j’avais écrit sur S.I.Lex t’avait influencé dans ta décision d’adopter la licence CC0 pour ton premier roman #Smartarded.

Quand j’ai vu que tu lançais cette opération de crowdfunding, j’ai voulu la soutenir et la faire connaître, parce que je trouve qu’elle bouscule la manière dont nous avons l’habitude d’appréhender des notions fondamentales, comme celles du gratuit et du payant. Avec la licence CC0, tu as renoncé à tes droits d’auteur pour que tes œuvres soient complètement libres, tout en réussissant à faire paraître ton roman chez Framabook. C’est déjà en soi assez perturbant pour les schémas habituels. Mais tu ne t’es pas arrêté là et par le financement collaboratif, tu as cherché à faire en sorte qu’un maximum de livres en papier deviennent gratuits afin de pouvoir les offrir.

Le plus intéressant dans ta démarche, je trouve, c’est que derrière ces décisions, il y a un modèle économique bien pensé, qui utilise le crowdfunding pour raccourcir la chaîne de l’auteur au lecteur, dans le but de diminuer les coûts. Tu démontres de manière paradoxale que la gratuité a toujours un coût. C’est typiquement le genre d’approches alternatives qui retiennent mon attention, parce que je trouve qu’elles font avancer la réflexion. Dans le contexte actuel de crispations autour des questions de droit d’auteur, qui sont particulièrement vives dans le secteur du livre, je pense que des initiatives comme les tiennes sont importantes. J’ai aussi beaucoup apprécié la lecture de ton premier roman #Smartarded et j’ai commencé à lire la suite #MonOrchide par petites touches sur ton blog. Tout cela a fait que j’ai voulu te soutenir en écrivant un billet sur S.I.lex et je me réjouis de ta réussite.


Merci ! Mais là tu parles plus de moi que de toi, hein… J’ai bien saisi que ce billet a été un élément déclencheur, mais est-ce qu’il s’agit d’un coup de tête ou est-ce que ça fait partie d’une réflexion personnelle plus… ancienne ?


Au-delà du billet, pourquoi avoir promis de changer la licence de mon blog si ton pari réussissait ? Peut-être d’abord un peu par superstition, pour porter chance à ton projet, en engageant quelque chose qui me tenait vraiment à cœur. Par ailleurs, je me posais des questions à propos de la licence de S.I.Lex depuis un certain temps. À vrai dire depuis le moment où j’ai écrit le billet Rien n’est à nous : grandeur et misère du domaine public volontaire. J’y montrais comment un certain nombre de créateurs dans le passé avaient choisi pour diverses raisons de renoncer aux droits sur leurs œuvres pour se placer en dehors de la logique de la propriété intellectuelle : Léon Tolstoï, Romain Rolland, Jean Giono, les affichistes de mai 68, les situationnistes, le musicien folk Woodie Guthrie.

Le domaine public est une notion qui a un grande importance pour moi et pour laquelle j’essaie de me battre. Il m’a semblé que le moment était venu de franchir le pas et de placer ma propre création, S.I.Lex, dans le domaine public volontaire.

Ton blog était en licence CC-BY (la seule condition de partage est de citer l’auteur). Là tu le passes en CC0. C’est quoi, au fond, la différence ?

Juridiquement dans le cadre du droit français, il n’y a pas tellement de différences. En effet, le Code de Propriété Intellectuelle ne permet pas dans notre pays de renoncer valablement à son droit moral, ce qui signifie qu’on doit théoriquement interpréter la CC0 comme une CC-BY. Je n’ai pas la possibilité légale de renoncer à mon droit à la paternité. Ce caractère inaliénable du droit moral a été voulu pour protéger l’auteur dans le cadre des contrats d’édition. Même dans le cas des « nègres » (ou, plus joliment dit, Ghostwriters en anglais), il reste possible pour eux de réclamer devant un juge la paternité d’un texte écrit pour quelqu’un d’autre, quand bien même ils se seraient engagés par contrat à ne pas révéler leur identité (on a des jurisprudences intéressantes à ce sujet dès le 19ème siècle, notamment dans l’affaire qui opposa Alexandre Dumas à l’un de ses collaborateurs, Auguste Maquet.

Le problème, c’est que l’application trop rigide de ce principe aujourd’hui peut conduire à « protéger » l’auteur contre lui-même, alors qu’il manifeste clairement la volonté de renoncer à ses droits. La licence CC0 a d’ailleurs été obligée de prendre en compte cet état de fait, en précisant que l’auteur renonce à ces droits « dans la mesure permise par la loi ». Cela veut dire que l’effet de la CC0 varie selon les pays : aux États-Unis, où le droit moral n’existe pas vraiment, il est total ; en France, il reste juridiquement incomplet, puisque le droit moral persiste. Le seul pays à l’heure actuelle qui reconnaisse explicitement la possibilité de verser ses œuvres dans le domaine public volontaire, c’est le Chili.

Donc passer de CC-BY (licence déjà très ouverte) à CC0 n’a pas beaucoup d’effets pratiques… tant que la propriété intellectuelle n’est pas réformée en France. Malgré tout, je ne t’imagine pas homme à manier ces licences à la légère. Si passer de la CC-BY au Domaine Public Vivant n’est pas un choix pratique, il est de quel ordre ?

Cette décision revêt à mes yeux une valeur symbolique et psychologique importante, en tant qu’auteur. Je ne suis pas comme toi auteur de littérature ou de théâtre, mais j’ai un rapport profond avec l’écriture. J’écris sur S.I.Lex par besoin viscéral d’écrire et quand je décroche de l’écriture, je périclite littéralement. Pour moi, l’écriture a aussi une importance comme trace que l’on laisse de soi au-delà de son existence. Du coup, le BY – la paternité – gardait une vraie importance à mes yeux, comme une sorte de « cordon ombilical » ou de minimum minimorum du droit d’auteur, dont il était difficile de se détourner. Couper ce cordon en adoptant la CC0 n’était pas anodin et il m’a fallu un certain temps – et un coup de pouce de ta part – pour lâcher prise !


Quel est l’intérêt, pour toi, de mettre de son vivant des textes dans le domaine public ?

Pour moi, l’intérêt principal, c’est de sortir en dehors du cadre du droit d’auteur. Avec les licences libres, on passe de la logique du copyright à celle du copyleft, mais on reste encore dans le système du droit d’auteur. Les licences libres ne sont pas une négation du droit d’auteur, mais une autre manière de le faire fonctionner. Avec la licence CC0, on n’est plus dans le copyright, ni même dans le copyleft, mais littéralement dans le copy-out. On décide sciemment que son œuvre n’est plus saisie par le droit d’auteur et ne doit plus être comprise à travers ce filtre. Je ne prétends pas que cette voie doive être suivie par tous les auteurs. Mais au stade où j’en suis, c’est cohérent avec ma démarche.

Tu dis de ton côté que tu n’as pas l’impression que tes textes ne t’appartiennent pas, mais que tu “digères” des éléments extérieurs que tu restitues par tes écrits. De mon côté, j’ai très tôt été sensible aux effets d’intelligence collective sur la Toile, avec le sentiment que je me devais de rendre à l’intelligence collective ce qu’elle me donne. Il n’y a pas un seul de mes billets qui n’ait été déclenché par les conversations et les échanges dans les flux. Dès lors, le meilleur moyen d’être cohérent avec moi-même, c’est d’opter pour le domaine public volontaire.

Par ailleurs, je pense important de montrer que le domaine public n’est pas seulement une chose du passé, mais qu’il peut être vivant aujourd’hui. En tant qu’auteur de son vivant, contribuer à alimenter le domaine public, c’est la meilleure manière de s’en faire l’ambassadeur et d’agrandir le cercle des biens communs de la connaissance.

OK : on a tous les deux ce souci de cohérence. C’est bien beau d’utiliser une licence parce qu’elle te met en adéquation avec ce que tu ressens de ta production intellectuelle… Mais il y a forcément des pragmatiques qui vont nous traiter d’utopistes ! Ils vont nous rappeler qu’on vit dans un monde où les enjeux commerciaux prévalent et où — selon eux — les circonstances font qu’il vaudrait mieux armer et protéger ses œuvres… D’un point de vue pratique, la clause non commerciale (NC) est un outil redoutable quand la CC0 est une passoire ! Du coup, une licence, c’est la conséquence d’un ressenti théorique ou la résultante d’un besoin pratique d’outil légal ?

C’est sans doute assez souvent le résultat d’un compromis entre les deux. Il faut considérer la situation des auteurs dans leur diversité et de multiples stratégies sont envisageables avec les licences. Les choses peuvent varier également selon les domaines de la création. Quand on voit un Cory Doctorow ou un Lawrence Lessig publier leurs ouvrages chez des éditeurs traditionnels et placer les versions numériques sous CC-BY-NC, je trouve que c’est une stratégie compréhensible et qu’ils ont par ce biais contribué à faire avancer la cause, en diffusant leurs idées dans un large cercle.

Beaucoup de créateurs en revanche ne cherchent pas un retour financier pour les œuvres qu’ils produisent. C’est le cas pour la plupart des amateurs qui créent des contenus sur Internet. Dans ce genre de situation, la réservation de l’usage commercial n’est généralement pas justifiée et choisir cette clause impose des contraintes sans réelle nécessité. Mais dans certaines situations, la clause NC peut constituer un élément intéressant pour permettre la circulation des œuvres tout en mettant en place un modèle économique. Il y a un débat assez vif en ce moment sur la légitimité de la clause NC, notamment telle qu’elle figure dans les licences Creative Commons. Je ne fais pas partie de ceux qui condamnent cette clause de manière systématique et j’ai déjà essayé de montrer que ce serait une erreur selon moi de la supprimer.

Malgré cela, tu n’as jamais mis de clause NC sur ton blog S.I.Lex...

Dans mon propre cas, je n’en vois absolument pas l’intérêt… Mon objectif en écrivant de cette manière est d’être lu par un maximum de personnes. Si certains de mes billets sont repris sur d’autres sites, y compris des sites se livrant à des activités commerciales, cela ne peut qu’augmenter l’exposition de mes écrits. J’ai d’ailleurs toujours fonctionné depuis le lancement de S.I.Lex dans un « écosystème » de sites. Très vite, j’ai eu la chance de voir certains de mes billets repris par le regretté OWNI. Cela a grandement contribué à faire connaître S.I.Lex et à développer mon lectorat. D’autres sites me reprennent régulièrement, comme Actualitté ou plus récemment Slate.fr. J’ai toujours considéré que S.I.lex était une sorte de plateforme de tir, où je posais des écrits qui pouvaient ensuite aller faire leur vie ailleurs. Avec une licence NC, les choses auraient été beaucoup plus compliquées.

La licence CC0 est peut-être une passoire, mais dans les conditions particulières qui sont les miennes comme auteur, elle conviendra parfaitement à ce que je veux faire de mes créations. Même si un éditeur vient publier certains de mes billets sous forme de livre dans un recueil, cela ne fera que contribuer encore à leur diffusion.

Du coup, tu n’exiges plus que l’on te cite comme source de tes écrits… de manière légale, c’est ça ? C’est un peu comme moi en fait : tu ne brandis pas d’arme juridique. Plutôt que de les craindre, tu donnes ta confiance aux personnes qui s’inspireront de (ou diffuseront) tes écrits. Confiance en le fait qu’elles soient assez respectueuses pour citer leur source.

La question qui peut se poser est celle du plagiat, quelqu’un qui viendrait s’approprier certains de mes textes en les publiant sous son nom. C’est une chose qui m’est déjà arrivée une fois et j’avoue que cela m’avait laissé une sensation assez désagréable.

Mais une personne comme l’artiste Nina Paley dit des choses très intéressantes sur les rapports entre le copyright et le plagiat. Elle considère en effet que le droit d’auteur paradoxalement favorise davantage le plagiat qu’il ne l’empêche. Elle explique également que le fait de créditer l’auteur relève en fait d’un système de régulation sociale qui n’a pas nécessairement besoin du droit pour fonctionner. Il s’agit en fait davantage de règles éthiques que des communautés se donnent. Nina Paley place d’ailleurs ses créations dans le domaine public volontaire en utilisant la non-licence Copyheart ou la CC0. Elle dit vouloir en cela faire œuvre de « non-violence légale » et je trouve que c’est un discours inspirant.

Un des pivots du libre, c’est sa viralité. On m’affirme que des processus du type la clause SA ont permis au libre de se développer tel qu’il est aujourd’hui. Pour mon compte, la SA est trop paradoxale. Je dis toujours que la première des libertés c’est de ne pas me lire. Dans la même veine, obliger les gens qui adapteront/traduiront/réécriront/diffuseront mes romans à mettre leur production sous licence libre, ça me semble créer de l’enclosure. Ce serait un peu comme forcer les gens à se vacciner au lieu de leur montrer comme on est mieux une fois bien portant… Et du coup j’aperçois que ton blog S.I.Lex n’était même pas sous clause SA ? Pourquoi ?

C’est une question intéressante et là aussi, je m’étais longuement posé la question lorsque j’avais choisi ma licence.

La clause de partage à l’identique est très importante dans beaucoup de domaines, comme celui du logiciel libre qui est fondé sur cette idée qu’il ne doit pas y avoir de possibilité de supprimer les libertés conférées à tous par la licence. Contrairement à ce que tu dis, je soutiendrais que le SA garantit au contraire qu’il ne puisse jamais y avoir d’enclosure sur une œuvre. Personne ne peut plus s’approprier de manière définitive un contenu placé sous Share-Alike. C’est pourquoi il me semble que c’est un type de licence adapté pour les biens communs que des communautés veulent protéger des risques d’enclosure. Si l’on prend le cas de Wikipédia, la licence CC-BY-SA est parfaitement adaptée, à la fois au travail collaboratif et aux réutilisations des contenus. Elle garantit que cela puisse se faire, même à titre commercial, mais sans réappropriation.

Cependant, je peux comprendre que tu ne veuilles pas placer tes écrits sous le régime du partage à l’identique, et c’est aussi la conclusion à laquelle j’étais arrivé pour S.I.Lex. Si je prends le cas des billets que reprenait OWNI par exemple, les choses auraient été trop compliquées avec une CC-BY-SA. En effet, OWNI reprenait mes billets, mais en les modifiant légèrement. Les journalistes de la plate-forme changeaient généralement le titre, ajoutaient des intertitres, inséraient des illustrations, des vidéos et parfois même des infographies. Il arrivait également que certains de mes billets soient traduits en anglais pour alimenter OWNI.eu. Tout cet apport éditorial était à mes yeux excellents, mais d’un point de vue juridique, il s’agissait d’adaptations de mes créations, ce qui aurait déclenché la clause de partage à l’identique, si j’avais choisi une CC-BY-SA. Or OWNI était sous CC-BY-NC-SA et il n’aurait pas été simple pour eux d’intégrer mes billets si je n’avais pas laissé une grande ouverture avec la CC-BY.

De plus, la CC-BY-SA n’est pas toujours simple à appliquer, comme l’avait prouvé l’affaire qui avait opposé Michel Houellebecq à Wikimedia, lorsque qu’il avait intégré dans son roman La Carte et le Territoire des extraits d’articles de Wikipédia sans mention de la source, ni crédits des auteurs.

Le domaine public et le libre ne sont pas exactement superposables. Le propre du domaine public, c’est de constituer un réservoir complètement ouvert dans lequel on peut venir puiser pour alimenter sa création sans contraintes. Les deux approches sont importantes et complémentaires.

Mais attends, de nous jours, entre les CopyrightMadness, les guerres de brevets, ceux qui s’approprient mon grain de maïs ou ton rectangle à bords arrondis… Avec tous ces abus du côté de la propriété intellectuelle et des biens communs… Y’a pas plus important ou plus urgent que de s’occuper du domaine public ?

Oui, c’est certain qu’il existe des sujets alarmants sur lesquels il devient urgent d’agir. Je ne suis pas seulement engagé pour la défense du domaine public, mais plus globalement pour la promotion des biens communs de la connaissance, ce que je fais au sein du collectif SavoirsCom1. Je milite également aux côtés de la Quadrature du Net pour la légalisation des échanges non-marchands et la mise en place de solutions de financement mutualisées pour la création, comme la contribution créative ou le revenu de base.

Néanmoins, je pense que le domaine public peut constituer un bon angle d’attaque pour s’engager dans une réforme positive de la propriété intellectuelle. On a un peu l’impression d’être aujourd’hui face à une forteresse imprenable et on n’arrive pas à sortir des débats autour de la répression du partage des œuvres, qui continuent à monopoliser l’attention du législateur comme on le voit bien avec les travaux de la mission Lescure. C’est pourquoi il me paraît intéressant d’ouvrir de nouveaux fronts qui permettront de défendre l’idée que nous possédons des droits positifs sur la culture. Le domaine public peut être une piste en ce sens et j’ai fait des propositions de réforme législative pour consacrer et renforcer cette notion dans le Code de Propriété Intellectuelle.

Par ailleurs, tu évoques le Copyright Madness, mais le domaine public pourrait aussi être un moyen de lutter contre les pires dérapages de la propriété intellectuelle. On a vu par exemple récemment des laboratoires pharmaceutiques déposer valablement des brevets en Australie sur les gènes responsables du cancer du sein, ce qui est absolument terrifiant puisque cela signifie que tout chercheur qui voudra mettre au point un remède devra leur verser des royalties. Aux États-Unis, Monsanto a relancé une offensive en justice pour empêcher des agriculteurs de replanter des semences de variétés brevetées et l’entreprise semble en passe de l’emporter. Cela peut avoir des conséquences dramatiques au niveau mondial.

Ces dérives ont un lien avec le domaine public, parce que celui-ci ne contient pas seulement les œuvres anciennes, mais aussi tout ce qui ne devrait pas pouvoir faire l’objet d’une appropriation exclusive. Cela vaut pour certains éléments de la Culture, mais aussi pour des choses aussi essentielles que le génome humain ou les semences.

Le domaine public devrait être le bouclier qui protège tous ces éléments fondamentaux de la folie de l’appropriation, mais c’est à nous de le promouvoir et de le faire vivre pour qu’il puisse remplir ce rôle.

Je crois qu’on ne peut pas trouver de meilleure conclusion ! Merci à toi, Calimaq.

2012-12-08_19.24.39.JPG




Passer de l’exercice scolaire à la maintenance des paquets (Libres conseils 28/42)

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

Traduction Framalang : satanas_g, Sphinx, Sky, Julius22, peupleLà, lamessen, goofy

Du débutant au professionnel

Jonathan Riddell

Jonathan Riddell est développeur KDE et Kubuntu, actuellement employé par Canonical. Quand il n’est pas devant un ordinateur, il fait du canoë sur les rivières d’Écosse.

Il y avait un bogue dans le code. Un bien méchant en plus : un plantage sans enregistrement des données. C’est bien là le problème dès qu’on regarde le code, on trouve des trucs à réparer. C’est facile de s’impliquer dans le logiciel libre ; le plus dur est d’en sortir. Après le premier bogue réparé, il y en a d’autres, et de plus en plus, tous à portée de main. Les corrections de bogues mènent à l’ajout de fonctionnalités, ce qui mène à la maintenance de projet, ce qui mène à faire fonctionner une communauté.

Tout a commencé en lisant Slashdot, cette masse d’actualité geek et technique peu filtrée avec des commentaires de quiconque peut recharger assez vite pour être en haut de liste. Chaque actualité était intéressante et excitante, apportait un éclairage nouveau sur le monde de la technologie qui finissait par me fasciner. Je n’avais plus à accepter ce qui m’était donné par de grandes entreprises de logiciels, je pouvais voir là, dans la communauté du logiciel libre, le code se développer devant moi.

En tant qu’étudiant, il était possible de finir les exercices donnés par les professeurs très rapidement. Mais les exercices ne sont pas des programmes terminés. Je voulais savoir comment appliquer les compétences basiques qu’ils m’avaient données dans le monde réel en écrivant des programmes résolvant des problèmes réels pour les gens. J’ai donc recherché du code, qui n’était pas difficile à trouver, il se trouvait là, sur Internet, en fait. En regardant le code des programmes que j’utilisais de plus près, j’y ai décelé de la beauté. Non pas parce que le code était parfaitement soigné ou bien structuré, mais parce que je pouvais le comprendre avec les concepts que j’avais déjà appris. Ces classes, méthodes et variables étaient bien en place, me permettant de résoudre les problèmes pertinents. Le logiciel libre est le meilleur moyen de franchir le pas entre savoir comment finir ses exercices de cours et comprendre comment de vrais programmes sont écrits.

Tous les étudiants en informatique devraient travailler sur du logiciel libre comme sujet de leur mémoire. Sinon, vous avez de grandes chances d’y passer six mois à un an pour qu’il finisse au sous-sol d’une bibliothèque sans être jamais plus consulté. Seul le logiciel libre permet d’exceller en faisant ce qui va de soi : vouloir apprendre comment résoudre des problèmes intéressants. À la fin de mon projet, des programmeurs de la NASA utilisaient mon outil de création de diagrammes en UML (NdT : langage de modélisation unifié) et il reçut des prix au cours de réceptions somptueuses. Avec le logiciel libre, on peut résoudre de vrais problèmes pour de vrais utilisateurs.

La communauté des développeurs est remplie de personnes formidables, passionnées et dévouées à leur travail, sans espoir autre de récompense qu’un programme d’ordinateur couronné de succès. La communauté des utilisateurs est également incroyable. Il est satisfaisant de savoir qu’on a aidé quelqu’un à résoudre un problème. Et j’apprécie les messages de remerciement que je reçois.

Après avoir écrit un logiciel utile, il faut le mettre à la disposition du plus grand nombre. Le code source ne va pas fonctionner pour la plupart des gens, il doit être compilé. Avant d’être impliqué, je trouvais que le fait de compiler était une manière un peu paresseuse de contribuer au logiciel libre. Vous vous attirez la plus grande partie de la reconnaissance sans rien avoir à coder. C’est, quelque part, quelque chose d’injuste. De même, la gestion de la communauté nécessaire pour porter un projet de logiciel libre peut aussi être vue comme une façon de s’attirer la reconnaissance sans faire de code.

Les utilisateurs dépendent beaucoup des packagers (NdT : les « empaqueteurs » qui préparent et maintiennent les paquets logiciels). Il est nécessaire que leur travail soit à la fois rapide, pour satisfaire ceux qui veulent la dernière version, et fiable, pour ceux qui veulent la stabilité (autant dire tout le monde). La partie la plus délicate, c’est que cela implique de travailler avec les logiciels des autres, qui sont toujours « cassés ». Une fois que le logiciel est lâché dans la nature, commencent à emerger des problèmes qui n’étaient pas repérables sur l’ordinateur de l’auteur. Il est possible que le code ne puisse pas être compilé avec une version de compilateur différente, peut-être que la licence n’est pas claire et ne permet pas de le copier, peut-être que la gestion des versions est incohérente et qu’une mise à jour mineure est incompatible, ou encore que la taille de l’écran est différente, les environnements de bureau peuvent aussi l’affecter, quelquefois, des bibliothèques tierces nécessaires ne sont pas encore à jour. De nos jours, le logiciel doit pouvoir tourner sur différentes architectures. Les processeurs 64 bits ont occasionné pas mal de problèmes quand ils sont devenus courants. Aujourd’hui, ce sont les processeurs ARM qui déjouent les calculs des codeurs. Les packagers doivent régler tous ces problèmes pour donner aux utilisateurs quelque chose qui fonctionne de façon fiable.

Nous avons une règle chez Ubuntu selon laquelle les paquets avec des tests unitaires doivent inclure ces mêmes tests dans le processus de la création des paquets. Souvent, ils échouent et l’auteur du logiciel nous dit que les tests sont uniquement à son usage. Malheureusement, quand il s’agit de logiciel, il n’est jamais assez fiable de le tester soi-même, il doit aussi être testé par d’autres. Un test unique est rarement suffisant, il faut une approche à plusieurs niveaux. Les tests unitaires du programme original devraient être le point de départ, ensuite, le packager les teste sur son propre ordinateur, il faut ensuite que d’autres personnes les testent aussi. L’installation automatique et les tests de mise à jour peuvent être scriptés assez correctement sur les services d’informatique dans le nuage. L’envoyer dans la branche de développement d’une distribution permet d’effectuer plus de tests avant de le voir distribué en masse quelques mois après. À chaque étape, des problèmes peuvent être et seront découverts, ils devront être corrigés, puis ces correctifs eux-mêmes devront être testés. Il n’y a donc pas forcément à écrire beaucoup de code, mais il y a pas mal de travail pour passer le logiciel de 95 % à 100 % prêt. Ces 5 % sont la partie la plus difficile, un lent et délicat processus qui demande une grande attention pendant tout son cours.

Vous ne pouvez pas faire de paquets sans une bonne communication avec les développeurs en amont. Quand des bogues se produisent, il est vital de pouvoir trouver la bonne personne à laquelle parler rapidement. Il est important d’apprendre à bien les connaître comme des amis et des collègues. Les conférences sont vitales pour cela, car rencontrer quelqu’un apporte beaucoup plus de contexte à un message sur une liste de diffusion qu’une année entière de messages.

Une des faces cachées du monde du logiciel libre réside dans la communication par les canaux IRC privés utilisés par les principaux membres d’un projet. Tous les grands projets en ont. Quelque part, Linus Torvalds a un moyen de discuter avec Andrew Morton et les autres sur ce qui est bon et sur ce qui est mauvais dans Linux. Ils sont plus sociaux que techniques et, quand on en abuse, ils peuvent être très antisociaux pour la communauté en général. Mais pour les moments où on a besoin d’un canal de communication rapide sans bruit parasite, ils fonctionnent bien.

Tenir un blog est un autre moyen de communication important dans la communauté du logiciel libre. C’est notre principale méthode pour promouvoir à la fois le logiciel que nous produisons et nous-mêmes. Non pas que ce soit utilisé éhontément pour de l’auto-promotion (il est inutile de prétendre que vous sauverez des vies avec votre blog…), mais parler de votre travail sur le logiciel libre aide à construire une communauté. Cela peut même vous valoir de trouver un travail ou d’être reconnu dans la rue.

Ces histoires venant de Slashdot, à propos de développements de nouvelles technologies, ne concernent pas des personnalités éloignées que vous ne rencontrerez jamais comme dans la presse people. Elles concernent des personnes qui ont trouvé un problème et qui l’ont résolu en utilisant l’ordinateur qu’elles avaient en face d’elles. Pendant quelques années, j’ai édité le site d’informations de KDE, trouvant les personnes qui résolvaient des problèmes, créaient des idées novatrices, s’acharnaient longuement à améliorer un logiciel jusqu’à ce qu’il soit d’une qualité suffisante, et j’en parlais au monde entier. Je n’ai jamais été à court d’histoires à raconter ni de personnes à présenter à tout le monde.

Mon dernier conseil est de conserver de la diversité. Il existe une telle richesse de projets intéressants à explorer, qui vous permettent d’apprendre et de progresser. Mais une fois que vous avez atteint une position de responsabilité, il peut être tentant d’y rester. Après avoir aidé à créer une communauté pour Kubuntu, je repars temporairement vers un travail sur Bazaar, un projet très différent, orienté sur les développeurs plutôt que sur des utilisateurs novices en technologies. Je peux à nouveau apprendre comment le code devient une réalité utile, comment une communauté communique, comment la qualité est maintenue. Ce sera un défi amusant et j’ai hâte de m’y attaquer.