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

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

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

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

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

Did You Know that Mozilla is Hijacking the Internet?

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

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

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

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

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

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

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

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

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

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

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

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

Mais revenons à la fine analyse de l’IAB :

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

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

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

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

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

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

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

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

Léo Marius vient à peine de sortir diplômé de l’École supérieure d’art et design de Saint Etienne. Son projet de recherche consistait à créer de toutes pièces (l’expression est bien trouvée) rien moins qu’un appareil photo en impression 3D !

Nom de code du projet : O3DPC (Open 3D Printed Camera). Nom de code de l’appareil : OR-01 (OpenReflex 01).

Le plus simple est encore d’illustrer tout de suite cela par une image explicite.

Il ne s’agit donc pas de photo numérique mais argentique, avec de vieilles pellicules dedans, et il reste le coût (non négligeable) des objectifs. Il n’empêche que le résultat est saisissant, fonctionnel et surtout mis à disposition de tous grâce au choix du Libre.

Nous avons évidemment eu envie d’en savoir plus en interviewant ci-dessous ce jeune créateur.

On voit ici, une nouvelle fois, combien le Libre peut être utile en situation d’étude et d’apprentissage. Combiné avec une accessibilité croissante des nouvelles technologies, il permet à tout un chacun, ayant un peu d’imagination, de réaliser puis partager des choses formidables.

On voit également se dessiner une nouvelle génération de makers/hackers, qui n’a pas eu à batailler (comme nous) pour faire connaître et exister le Libre, et qui l’adopte presque naturellement. Une génération qui donne, somme toute, espoir et confiance en l’avenir 😉

Entretien avec Léo Marius

Léo Marius, bonjour, peux-tu te présenter succinctement ?

Je suis un jeune designer tout juste diplômé de l’École supérieure d’art et design de Saint Etienne. Passionné par les nouvelles technologies et en particulier l’impression 3D dans laquelle je vois des opportunités de créations incroyables souvent sous-exploitées (je milite contre les têtes de Yoda et les coques pour smartphone imprimés !).

Libriste et actif dans le milieu associatif depuis quelques années. J’apprécie beaucoup la photographie mais je ne suis pas moi-même photographe.

Qu’est-ce donc que le projet O3DPC ? Comment est-il né ? Et en quoi est-il relié à tes études ?

Le projet O3DPC (pour Open 3D Printed Camera) est un travail de recherche que j’ai mené en rapprochant l’impression 3D libre et la photographie, il rassemble plusieurs projets sur lesquels j’ai travaillé, dont plusieurs sténopés et dernièrement le reflex imprimé.

J’ai mené ce travail en tant que projet personnel tout au long de mes études en design, c’était l’occasion pour moi de rapprocher deux domaines qui m’intéressent : l’impression 3D et la photographie.

De ce projet est donc sorti le prototype OR-01, quelles sont ces principales caractéristiques ? ces atouts ? ces améliorations futures (j’ai cru lire un projet avec la carte Arduino) ?

C’est un reflex argentique classique avec une visée directe (on peut voir directement ce que l’ont vise sur le petit rectangle dessus et un obturateur manuel qui fonctionne à environ 1/60° de seconde).

Son atout principal c’est que l’ensemble de ses sources sont libres, et donc adaptable, il est ainsi facile de le modifier pour l’adapter si certaines choses fonctionnement mal ou si on souhaite l’adapter pour des usages particuliers.

Dans sa forme actuelle je retiendrai deux éléments particulièrement intéressants :

• En premier la bague d’adaptation pour les optiques est démontable, on peut donc facilement s’imprimer des baïonnettes différentes pour s’adapter a plusieurs types d’objectifs sans avoir à changer de boîtier.
• Il y a également le dos autonome et démontable que j’apprécie, la partie où l’on met sa pellicule. Lorsque j’utilise le mien j’ai deux dos prêts avec deux pellicules différentes et je peux les changer rapidement pour m’adapter à la luminosité (ou switcher entre une pellicule noir et blanc et couleur, tout cela en plein milieu du rouleau d’une pellicule)

Le choix de l’open source, c’est un choix pragmatique, éthique ou les deux mon général ? Je lis (avec joie) une licence CC by-sa pour tes pièces, pourquoi n’as-tu pas retenu la clause non commerciale NC ?

Un peu des deux. À mon arrivée à l’école, j’ai intégré l’association Le_Garage (dont j’ai été président pendant deux ans) qui fait de la sensibilisation dans l’école aux questions du libre en art et design. Ça a donc été assez naturel pour moi de redistribuer ce travail sous licence libre.

L’idée principale derrière l’OR-01 c’est la réappropriation et la compréhension des nos appareils quotidiens, fermer les sources aurait interdit et contredit cet objectif

Pour ce qui est des la clause NC je préfère ne pas l’utiliser car je la trouve trop floue et contraignante dans la pratique. Si on souhaite qu’un projet se diffuse il ne faut pas lui mettre des bâtons dans les roues. Je n’ai aucune raison de m opposer à ce que quelqu’un souhaite se rapproprier le projet, l’améliorer et le vendre, s’il a lui même fourni un travail et qu’il respecte les conditions de redistribution de la licence copyleft.

Quelle imprimante 3D utilises-tu ? La « full libre » RepRap ou la « moins libre » MakerBot^[1] ?

J’ai commencé le projet O3DPC il y a un peu plus de trois ans avec une Makerbot de 1ere génération (la numéro 660 ! une pièce de collection) que nous avions acquis avec notre association libriste et qui était encore libre à l’époque. Le reflex a été réalisé avec une Makerbot de dernière génération, la Replicator 2X qui a été achetée par notre école en complément d’une imprimante 3D haut de gamme que nous avions déjà.

L’utilisation de la Makerbot est un moindre mal, les technologies utilisées sont les même que sur les RepRaps traditionnels et les pièces qu’il est possible d’imprimer avec une Makerbot le seront aussi sur une RepRap bien calibrée. Je souhaitais, pour aider à sa diffusion, que le boîtier soit imprimable sur une imprimante de type RepRap. Si j’avais pu choisir je pense que j’aurais opté pour une Lulzbot. 😉

Au niveau logiciel, quels sont ceux que tu utilises et pourquoi ? Sont-ils tous libres ?

J’ai essentiellement utilisé Blender, c’est un logiciel que je connais bien et que je trouve extrêmement polyvalent et flexible. Les formes produites avec ce logiciel sont souvent très souples, et on déplace avec aisance les points pour adapter nos formes et nos courbes. Souvent en design on nous fait utiliser l’application propriétaire Rhino qui est beaucoup plus stricte dans son utilisation (« un tout petit peu plus haut » sur Blender correspond à un « Z+0,23mm » sur un Rhino mais il faut alors redessiner toute sa courbe avant de refaire sa révolution). Avec Blender on peut se permettre des approximations, ce qui est bien pratique dans une démarche de recherche.

J’ai également utilisé le libre OpenScad pour certaines pièces qui nécessitaient des formes et des distances très précises. Le fait de pouvoir coder ses pièces s’est avéré très utile. La pièce ne correspond pas ? Il suffit de changer quelques lignes de code pour tout modifier ! L’ensemble est libre 😉

Ce qui était particulièrement pratique c’est que, n’ayant pas d’ordinateur portable performant, je me déplaçais avec mon disque dur et les versions mobiles de toutes mes application pour les principaux OS dessus et je pouvais alors travailler où je le souhaitais.

Tu déposes les fichiers numériques de tes pièces sur Thingiverse et Instructables. Aujourd’hui quand on est développeur et qu’on cherche du boulot, on peut mettre dans son CV ses contributions sur GitHub. Penses-tu qu’il en ira de même demain dans le design sur ce type de dépôts ?

Oui, et de plus en plus. Je prends par exemple le designer Samuel Bernier qui a diffusé une partie de son travail en libre sur Instructables et que j’ai interogé pour mon mémoire (sur les Designers/Makers). Lorsque je lui ai demandé ce que lui avait apporté le libre, il m’a répondu : « des contacts et beaucoup d’opportunités ».

J’ai d’ailleurs mis récemment une note sur mon compte Instructables précisant que je cherchais un emploi, et j’ai reçu une proposition assez intéressante la semaine dernière (rien de défini, mais on verra). Ça fonctionne. Et si cela n’aboutit pas je peux me dire que 95% de mes employeurs potentiels auront vu mon projet de diplôme avant que je les contacte, ce qui est pas mal déjà comme entrée en matière.

25 euros en pièces détachées pour une appareil photo, c’est possible ? Et si oui, ne crains-tu pas pas qu’une société s’en empare et commercialise ton projet sans toi puisque c’est open source (question troll-piège :)) ?

Comme je l’ai mentionné plus haut, tant qu’ils respectent la clause de redistribution à l’identique (SA), cela me va. Je pourrais ainsi à mon tour récupérer leurs sources (que j’espère améliorées) pour mes propres boîtiers 😉

Éprouves-tu une certaine « nostalgie » de la photo argentique ?

Pas vraiment de la nostalgie, mais c’est une sensibilité différente à l’image que l’on ne retrouve pas avec le numérique : l’attente et l’incertitude de la photo, le coût aussi qui limite l’utilisation abusive. On réfléchit avant d’appuyer sur le bouton, on n’en prend pas cinquante à la volée comme cela se fait trop souvent.

Je me souviens du temps où les objectifs étaient obligatoirement reliés à une marque (ceux pour Canon, Nikon, etc.). Avec ton OR-01 et sa bague adaptable, tu donnes en quelque sorte de l’interopérabilité aux appareils photos, non ?

Oui, toujours dans l’idée de se rapproprier la technologies. Si l’appareil avait été dépendant d’un type d’objectifs, cela n’aurait pas fonctionné.

Techniquement, comment réussis-tu avec des pièces à monter à rendre l’appareil totalement opaque ?

Le tout est imprimé avec du plastique opaque et, en mettant des rebords et des emboîtements bien placés, l’étanchéité se fait sans trop de difficultés. Pour certaines zones, un peu plus sensibles, j’ai ajouté de la patafix noire pour combler les trous potentiels.

Toutes les parties étant autonomes c’est surtout le dos dans lequel se trouve la pellicule qu’il faut rendre étanche à la lumière, on peut se permettre des petits jours dans les autres. Ça reste un appareil DIY. 🙂

Un petit mot sur Framasoft que tu sembles connaître ?

Merci ! Continuez ce que vous faites. Le libre l’emportera ! 😉

Un appel à lancer ? Une actualité à annoncer ?

Peut être une nouvelle version plus aboutie de l’OpenReflex qui devrait être disponible en financement participatif en septembre ou octobre (selon mes engagements professionnels). N’hésitez pas à suivre mon blog ou à me poster un message sur le dépôt Instructables pour être tenus au courant.

Et sinon, permettez-moi un petit clin d’oeil hommage à Gilles Roussi, le professeur à l’origine de l’association Le_Garage qui nous lira surement 😉

Photo ci-dessous réalisée avec l’OR-01

Nous reproduisons ici un article paru initialement dans la revue du projet (belge) Barricade, avec l’aimable autorisation de son auteur (« bien sûr, tu peux reprendre l’article, c’est de l’éducation populaire, on reçoit des subventions pour écrire cela, et plus il y a de diffusion mieux c’est »).

Parce que le logiciel libre fait partie des biens communs. Parce que ces outils sont autant d’obstacles à lever pour une plus grande participation de tous.

Remarque : Pour une lecture plus confortable de l’article, vous pouvez lire et/ou télécharger sa version PDF jointe en bas de page.

Six outils pour faire vivre les biens communs

URL d’origine du document

Pablo Servigne – 30 mai 2013 – Barricade 2013

Le concept de bien commun a l’air évident : est commun ce qui appartient à tous. Mais en réalité, il est loin d’être simple car il heurte nos plus profondes convictions. Qu’est-ce qu’« appartenir » ? Qui est « tous » ? Finalement qu’est-ce que le « commun » ? Voici les moyens de franchir six obstacles mentaux à l’entrée dans l’univers des biens communs.

Le concept de bien commun a pris une place importante dans le champ médiatique depuis l’attribution en 2009 du prix (de la Banque royale de Suède en sciences économiques en mémoire d’Alfred) Nobel à la politologue étatsunienne Elinor Ostrom^[1].

Cette dernière a produit une œuvre scientifique immense démontrant magistralement que de nombreux biens communs (des ressources naturelles et des ressources culturelles) peuvent être bien gérées localement par des communautés très diverses qui se fabriquent des normes ad hoc pour éviter l’effondrement de leurs ressources (autrement appelé « la tragédie des biens communs »).

Ostrom montre qu’il n’y a pas de recette toute faite, mais qu’il y a bien des principes de base récurrents^[2]. C’est une véritable théorie de l’auto-organisation. Elle montre surtout que la voie de la privatisation totale des ressources gérées par le marché ne fonctionne pas et, plus gênant, elle montre que les cas où la ressource est gérée par une institution centralisée unique (souvent l’Etat) mène aussi à des désastres. Cela ne veut pas dire que le marché ou l’Etat n’ont pas de rôle à jouer dans les biens communs.

Elle invite à se rendre compte des limites de ces deux approches, et à plonger dans le cas par cas, le local, les conflits, les aspérités du terrain, et l’insondable complexité des institutions et des comportements humains (par opposition aux équations et aux théories). Ce qu’il faut à tout prix éviter, c’est le simplisme, la solution unique et le prêt-à-penser.

Tentons d’entrer dans la matière à reculons. L’idée de faire une liste d’obstacles est venue bien tard, suite à de nombreuses discussions, ateliers, débats et conférences. Lâcher le terme de bien commun dans une salle fait l’effet d’une petite bombe… qui explose différemment dans la tête de chaque personne. On se retrouve systématiquement avec un débat en kaléidoscope où la seule manière de démêler les incompréhensions est d’aller voir au plus profond de nos croyances et de nos imaginaires politiques.

On se situe donc bien sur le terrain de l’imaginaire, ou de l’épistémè^[3] dirait le philosophe, avec toute la subjectivité que cela implique. J’ai recensé six « obstacles » que je trouve récurrents et importants, mais ils ne sont pas classés suivant un quelconque ordre et sont loin d’être exhaustifs. Le travail d’investigation pourrait aisément continuer.

Obstacle 1 : on ne les voit pas

Comment se battre pour quelque chose dont on ignore l’existence ? L’économie dans laquelle nous avons été éduqués est celle de la rareté. Tout ce qui est rare a de la valeur. On apprend donc à prendre soin de ces ressources rares et on se désintéresse de tout ce qui est abondant. L’abondance est une évidence, puis disparaît de notre champ de vision.

On ne voit plus l’air que l’on respire. On ne voit (presque) plus l’eau, puisqu’elle tombe du ciel abondamment. On ne voit plus le silence car personne n’en parle. On ne voit plus les langues, les chiffres, les fêtes traditionnelles, le jazz, la possibilité d’observer un paysage, la sécurité, la confiance, la biodiversité ou même internet. Nous n’avons pas été éduqués à les voir, et encore moins à les « gérer ».

Les trois affluents du fleuve des biens communs. Illustration d’après Peter Barnes^[4]

Tout l’enjeu du mouvement des biens communs est donc d’abord de les rendre visibles ; de leur donner, non pas un prix, mais de la valeur à nos yeux. Montrer leur utilité, leur existence, leur fragilité et surtout notre dépendance à leur égard. Rendre visible implique d’avoir aussi un langage commun, savoir désigner les choses.

La question de la définition des biens communs est bien évidemment cruciale, mais elle passe d’abord par un tour d’horizon des cas concrets, et par un émerveillement. Les communs pourraient être une fête permanente. C’est une première étape à faire ensemble, avant toute discussion théorique.

Obstacle 2 : le marché tout puissant

Bien sûr, certaines ressources abondantes deviennent rares. On pense aux poissons, à certaines forêts, à l’air pur, à des animaux ou des plantes, à l’eau propre… On utilise alors deux types d’outils pour les « sauver » : le droit et l’économie. En général, la main gauche utilise les lois et la protection juridique, alors que la main droite leur colle un prix, les fait marchandises et utilise volontiers le marché pour réguler les stocks et les flux. Ce sont les mains gauche et droite d’une doctrine de philosophie politique appelée libéralisme et dans laquelle nous baignons depuis plus de deux siècles.

Le problème est que la main droite a pris le pouvoir durant ces dernières décennies et impose ses méthodes. La vague néolibérale des années 80 n’a pas fini de privatiser tous les domaines de la société et de la vie. Cette attaque frontale aux biens communs se passe généralement de manière silencieuse à cause justement de leur invisibilité. Sauf dans certains cas trop scandaleux (l’eau en Bolivie, les gènes dans les laboratoires pharmaceutiques, etc.) où une partie de l’opinion publique réagit ponctuellement (on pense à toutes les luttes autour de l’AMI^[5] menées entre autres par l’association ATTAC dans les années 2000).

L’idéologie du marché débridé est corrosive pour les biens communs. Malheureusement, elle est bien implantée dans l’imaginaire collectif de nos sociétés, et en particulier dans la tête des élites financière, politique et médiatique, qui imposent leurs méthodes au reste du monde et contribuent à maintenir invisible les biens communs… jusqu’à ce qu’ils soient privatisés et rentables pour l’actionnaire !

Obstacle 3 : le réflexe de l’Etat

Face à cette colonisation massive et inexorable, les personnes indignées se tournent le plus souvent vers la figure de l’Etat. Un Etat protecteur et régulateur, garant de la chose publique (la res publica). Publique ? Mais ne parlait-on pas de commun ?

C’est bien là le problème. Car le public est différent du commun. La chose publique appartient et/ou est gérée par l’Etat : c’est le cas de la sécurité sociale, des infrastructures routières, de l’école, du système de santé, etc. Mais réfléchissez bien : l’Etat gère-t-il l’air, la mer, le climat, le silence, la musique, la confiance, les langues ou la biodiversité ? Oui et non. Il essaie parfois de manière partielle, tant bien que mal, face aux assauts des biens privés. Mais selon le nouveau courant de pensée des biens communs, il n’a pas vraiment vocation à le faire. En tout cas pas tout seul.

Il y a plus de 1500 ans, déjà, le Codex Justinianum de l’Empire romain proposait quatre types de propriété : « Les res nullius sont les objets sans propriétaire, dont tout le monde peut donc user à volonté. Les res privatae, par contre, réunissent les choses dont des individus ou des familles se trouvent en possession. Par le terme res publicae, on désigne toutes les choses érigées par l’Etat pour un usage public, comme les rues ou les bâtiments officiels. Les res communes comprennent les choses de la nature qui appartiennent en commun à tout le monde, comme l’air, les cours d’eau et la mer. »^[6] Ainsi classées, les choses prennent une toute autre tournure !

Le problème vient du fait que les pratiques de gestion des biens communs ont disparu au fil des siècles (par un phénomène appelé les enclosures^[7]) et que ce vide tente d’être comblé tant bien que mal par la seule institution qui nous reste et que nous considérons comme légitime, l’Etat.

Or, non seulement il est totalement inefficace dans certains cas (le climat par exemple), mais comme l’a observé Elinor Ostrom, une organisation centralisatrice et hiérarchique est loin d’être le meilleur outil pour gérer des systèmes complexes (ce que sont les biens communs), et il peut faire beaucoup de dégâts.

De plus, à notre époque, les Etats entretiennent des rapports de soumission aux marchés. « Dans bien des cas, les véritables ennemis des biens communs sont justement ces Etats qui devraient en être les gardiens fidèles. Ainsi l’expropriation des biens communs en faveur des intérêts privés — des multinationales, par exemple — est-elle souvent le fait de gouvernements placés dans une dépendance croissante (et donc en position de faiblesse) à l’égard des entreprises qui leur dictent des politiques de privatisation, de consommation du territoire et d’exploitation. Les situations grecque et irlandaise sont de ce point de vue particulièrement emblématiques. »^[8]

Nous aurons bien sûr toujours besoin de l’instrument public, il n’est nullement question de l’ignorer ou de le remplacer, mais de l’utiliser pour enrichir les biens communs et leur gestion communautaire. L’enjeu est de recréer ces espaces et ces collectifs propices à la gestion des communs, et de construire des interactions bénéfiques entre commun et public. L’Etat comme garant du bien public et comme pépinière des biens communs.

Une vision en trois pôles est définitivement née : privé, public, commun.

Obstacle 4 : la peur du goulag

Bien plus facile à expliquer, mais bien plus tenace, il y a cette tendance chez beaucoup de personnes à considérer toute tentative d’organisation collective comme une pente (forcément glissante) vers le communisme, puis le goulag. Dans les discussions, il arrive que l’on passe rapidement un point Godwin « de gauche »^[9].

L’imaginaire de la guerre froide est encore tenace, et le communisme a mauvaise réputation (à juste titre d’ailleurs). Mais il est abusivement assimilé à l’unique expérience soviétique. Or, l’important est de se rendre compte, comme invite à le faire Noam Chomsky, que l’expérience soviétique a été la plus grande entreprise de destruction du socialisme de l’histoire humaine^[10]. Ça libère ! Penser et gérer les communs n’est pas synonyme de goulag, bien au contraire.

Obstacle 5 : « l’être humain est par nature égoïste »

Il est une autre croyance bien tenace et profondément ancrée dans nos esprits, celle d’un être humain naturellement égoïste et agressif. Cette croyance s’est répandue après les interminables guerres de religions que l’Europe a subie au Moyen-Age.

Las de ces conflits, les philosophes politiques de l’époque (dont Hobbes) ont alors inventé un cadre politique à l’éthique minimale qui pourrait servir à organiser les sociétés humaines. Un cadre le plus neutre possible qui permette de cohabiter sans s’entre-tuer : le libéralisme était né.

Cette doctrine s’est donc constituée sur cette double croyance que seul l’Etat pouvait nous permettre de sortir collectivement de notre état de bestialité agressive, baveuse et sanglante ; et que seul le marché (neutre et protégé par l’Etat) pouvait nous permettre de satisfaire les besoins de tous en favorisant nos instincts naturellement égoïstes^[11].

Nous savons aujourd’hui que ces croyances ne sont pas basées sur des faits. L’être humain possède bien évidemment des instincts égoïstes, mais également coopératifs, voire altruistes. Il développe très tôt dans l’enfance et tout au long de sa vie des capacités à coopérer avec des inconnu-es, à faire confiance spontanément, à aider au péril de sa vie, à favoriser les comportements égalitaires, à rejeter les injustices, à punir les tricheurs, à récompenser les coopérateurs, etc.

Tous ces comportements ont été découverts par des expériences et des observations simultanément dans les champs de l’économie, la psychologie, la sociologie, la biologie, l’éthologie, l’anthropologie, et les sciences politiques.

En économie, par exemple, presque tous les modèles sont basés sur l’hypothèse d’un humain calculateur, égoïste et rationnel, l’Homo oeconomicus. Or, sur le terrain, les recherches anthropologiques se sont avérées infructueuses : il n’existe pas. Les peuples, partout dans le monde, coopèrent bien plus que ne le prédisent les modèles économiques. Les faits et les observations accumulées depuis plusieurs décennies sont peu connues mais incontestables^[12].

Nous avons désormais les moyens de savoir que l’humain est l’espèce la plus coopérative du monde vivant, mais … disposons-nous des moyens d’y croire ? Ce sera pourtant la condition nécessaire (mais pas suffisante) à la construction d’une nouvelle épistémè favorable à l’auto-organisation, la création et la préservation des biens communs.

Obstacle 6 : se reposer sur les institutions

Il est inutile d’insister sur le fait que l’école ne nous enseigne pas à cultiver l’esprit démocratique et nous maintient dans une état d’inculture politique grave. L’école n’est pas la seule fautive, presque toutes les institutions publiques et privées que nous côtoyons tout au long de notre vie ne stimulent guère notre imagination politique.

En fait, quand il s’agit de s’organiser, nous avons tendance à nous reposer sur des institutions déjà en place (gouvernement, lois, cours de justice, commissariat de police, etc.) dont les règles sont (presque) incontournables. Ces institutions existent en tant qu’entités indépendantes de nous-mêmes, elles nous surplombent et imposent des normes sociales difficilement discutables par le citoyen lambda, et dont seule une minorité tente de les faire évoluer.

La facilité incite à « se laisser vivre » passivement sous leur tutelle, sans trop les discuter, en étant certains qu’elles nous survivront. Nous avons pris l’habitude de nous reposer sur les institutions existantes, à les considérer comme stables et acquises d’avance.

Pour les biens communs, c’est précisément l’inverse. Il nous faudra sortir de cette facilité. Leur gestion est une affaire d’effort démocratique et de citoyens émancipés et actifs. Les biens communs sont des pratiques qui naissent de la confrontation d’une communauté avec des problèmes locaux et particuliers.

Les « parties prenantes » (les différents acteurs concernés) doivent se forger eux-mêmes des normes (récompenses, quotas, sanctions, etc.) dans un processus créatif et sans cesse renouvelé. La gestion des biens communs ne se décrète pas, elle se pratique. Ce n’est pas un statut, c’est un processus dynamique.

Si les acteurs arrêtent de « pratiquer leur bien commun », alors il s’éteint, car il n’y a pas (ou peu) d’institution qui le soutienne. Les anglais ont inventé un verbe pour cela, commoning. C’est en marchant que le bien commun se crée, il suffit de s’arrêter pour qu’il disparaisse. Cela nécessite un engagement et un devoir constant.

Mais comme disait Thucydide^[13], « il faut choisir : se reposer ou être libre ».

Pour aller plus loin

• Elinor Ostrom, Gouvernance des biens communs. Pour une nouvelle approche des ressources naturelles, Etopia/DeBoeck, 2010.
  • Un livre-clé mais assez difficile d’accès, très touffu et à la prose scientifique. De plus, il date de 1990, et depuis, Ostrom a écrit de nombreux livres et articles, non encore traduits en français. Indispensable… pour curieux motivés.

• Silke Helfrich, Rainer Kuhlen, Wolfgang Sachs et Christian Siefkes. Biens communs – La prospérité par le partage. Rapport de la Fondation Heinrich Böll, 2009. Disponible gratuitement ici.
  • Cette brochure, pédagogique et originale, est une très bonne introduction aux biens communs. Bien plus digeste que le livre d’Ostrom. Vivement recommandée !

• Collectif. Les biens communs, comment (co)gérer ce qui est à tous ? Actes du colloque Etopia du 9 mars 2012, Bruxelles. Disponible en pdf.
  • Tour d’horizon rapide et complet (mais pas ennuyeux) de la galaxie des biens communs. A lire d’urgence car il est complémentaire du rapport de la fondation Heinrich Böll.

Crédit photo : Eneas (Creative Commons By)

« C’est bien joli de vouloir de la culture libre, mais au fond on peut rien y faire, hein ? Déjà le droit d’auteur c’est compliqué, personne n’y comprend rien à part les juridico-geeks. En plus c’est une tradition bien trop ancrée, née pour protéger les auteurs. Et puis nous on n’a pas le pouvoir de changer la loi, et on sait même pas comment la modifier… »

J’ai pensé toutes ces phrases, et je suis persuadé de ne pas être seul. Ce n’est pas glorieux, c’est un peu déprimant, mais ces généralités sont bien présentes dans nos esprits, engluant nos désirs d’évolution, d’ouverture et de liberté. Imaginez donc ma joie quand j’ai eu vent d’un projet qui démonte un par un tous ces lieux communs, explique les choses de façon simple et complète et propose des réformes concrètes favorisant et le public et les créateurs.

Le principe est simple : un petit livre de 50 pages, libre et éditable , qui se lit en une heure maxi.

Deux parties, l’une proposant 18 mesures concrètes et argumentées, l’autre contant combien chacun-e s’y retrouverait.

Et un crowdfunding (au succès aussi rapide que motivant) pour imprimer et envoyer la première partie à nos député-e-s. En 15 jours seulement, ce projet a trouvé son financement. Il reste encore 2 mois au compteur pour participer, franchir les paliers de financement suivants et diffuser largement cet ouvrage.

Derrière ce magnifique travail de synthèse se trouve l’impulsion de @Sploinga, qui a accepté de répondre à mes questions.

Interview de Xavier par Pouhiou

Bonjour Xavier Peux-tu te présenter aux lecteurices du Framablog ?

Xavier. 24 ans. Étudiant en sciences politiques, après un master de philosophie. Ubuntero de longue date et amateur de confitures au cassis ou à la rhubarbe.

Tu annonces clairement, dès l’avant-propos, que ce livre est un remix, qu’il s’inspire et reprend un ensemble de travaux sur la question du droit d’auteur. Tu peux brièvement en citer quelques-uns ?

J’avais déjà traduit et publié l’année dernière grâce à deux acolytes le programme du Parti Pirate Européen au Parlement Européen. Je trouvais que certains points pouvaient être améliorés comme la réflexion sur le droit moral, le remix, la promotion des licences libres par l’État ou le financement de l’immatériel. J’ai parcouru le Web francophone à la recherche de travaux sur une réforme du droit d’auteur dans un contexte français. Je suis principalement tombé sur des travaux de la Quadrature du Net avec les travaux de Philippe Aigrain et des associations de défense du logiciel libre comme l’April ou l’Aful. Le rapport Lescure contient aussi quelques idées pertinentes sur le droit au remix. J’ai donc voulu résumer et compiler tout ça. Lionel Maurel alias @calimaq a aussi bien contribué à la précision de certaines propositions comme les échanges non-marchands ou la contribution créative.

Dans les initiatives réussies, il y eut l’opération DataLove de la Quadrature. Pourquoi lancer une nouvelle campagne vers une réforme du droit d’auteur ? Quels besoins as-tu ressentis pour te mettre à apporter ta pierre à l’édifice ?

Tout simplement, le projet de sensibiliser en masse les élus du Palais Bourbon par l’envoi d’un livre n’a jamais été fait. J’ai donc décidé qu’il fallait le tenter.

L’opération DataLove touchait les parlementaires européens, en anglais, avec des clés USB remplies de contenu libre outre le programme de la Quadrature, sans suivi particulier des citoyens. Ici il s’agit d’envoyer seulement un programme avec des lettres personnalisées pour assurer un suivi des positions des députés français.

Faire du lobbying citoyen à l’échelle européenne est très complexe. Les institutions y sont peu ou pas lisibles. Il faut s’adapter à la multiplicité des langues et des contextes nationaux. Je fais confiance à la Quadrature du Net là-dessus. Son aura est pan-européenne. Les activistes allemands les connaissent . Ils ont raison car certains problèmes du droit d’auteur ne peuvent être complètement traités qu’à cette échelle.

Malgré ces difficultés liées à la manière dont l’Europe est construite, il est déjà possible d’obtenir des avancées à l’échelle française. Le droit moral est très rigide chez nous à cause d’une jurisprudence franco-française. Le droit au remix est très limité alors qu’une extension du droit de citation est possible. La dépénalisation du partage non-commercial peut ne s’opérer qu’à l’intérieur de nos frontières. L’institution d’un registre pour résoudre le problème des œuvres orphelines n’a pas besoin d’un accord européen. Sur ce point, l’État français ne s’est de fait pas gêné pour abuser de ses pouvoirs dans le cadre de ReLIRE.

Enfin et surtout, je suis d’avis que l’assouplissement du droit d’auteur n’est pas un échec. Ce n’est pas seulement parce que le droit d’auteur est un bon prétexte pour censurer nos échanges sur Internet qu’il faut le réformer. C’est avant tout parce qu’Internet est devenu une magnifique bibliothèque d’Alexandrie où tout un chacun puise pour partager et réutiliser ce qu’il y trouve. L’État doit fournir les livres d’une bibliothèque, pas les mettre à l’enfer.

Il est normal que ceux qui tirent un bénéfice financier des œuvres trouvées à la bibliothèque rémunèrent les auteurs de ces œuvres. Mais il est tout à fait scandaleux que tous les amateurs soient criminalisés. Car encourager la culture amateure, c’est encourager la culture tout court. Tous les Mozart étaient de très bons amateurs avant d’en faire leur profession. C’est ce que défend SavoirsCom1 et c’est pourquoi le collectif m’a soutenu.

Les sources citées dans ton ouvrage sont des textes importants, pas forcément faciles d’accès… Or quand je lis « Il faut réformer le droit d’auteur ! » l’argumentaire est simple et limpide. C’était important de pouvoir être compris par le profane ? Comment t’y es-tu pris ?

Le député moyen ne connaît pas toujours grand-chose à ce domaine. Tout comme le citoyen moyen. Or ce sont ces publics que je vise. Il a donc fallu faire le grand écart entre la complexité de la loi et l’argumentation pour des non-initiés. Au lecteur de voir si ce grand écart est réussi ou pas. S’il le veut, qu’il n’hésite pas à corriger les formulations (ou les propositions !) sur le wiki. Le but est d’arriver à une version finale à la fois simple et complète. Pour ça, il faut essentiellement se forcer à résumer et à ne pas multiplier les arguments. Bien sûr, connaitre les enjeux, discuter avec d’autres des textes et les avoir déjà travaillé aide. Pour cela je remercie tous ceux avec qui j’ai échangé sur le sujet via Twitter, par mail ou ailleurs et tout particulièrement Lionel Maurel 🙂

Tu te crédites en tant que co-auteur… quelles sont les participations que ce livre a reçues ? On peut encore aider à travailler dessus ?

C’était sans doute une mauvaise idée car savoir qui a écrit la version actuelle n’est pas essentiel. J’ai déjà changé ça dans les sources en « éditeur » même si bien sûr j’ai traduit ou rédigé une partie du livre. Les auteurs sont les auteurs des textes originaux, à savoir les associations et individus cités dans les sources, puis les traducteurs, compilateurs et correcteurs qui ont rédigé la version actuelle du livre. Comme dans beaucoup de travaux collaboratifs, une minorité fait la majorité du boulot, mais toute aide même marginale est appréciée. On m’a signalé quelques idées que je compte inclure dans la version finale comme le mécénat volontaire. Les contributeurs intéressés peuvent toujours apporter leur pierre à l’édifice sur le wiki. Je créditerai avant tout dans le livre final tous les soutiens et les contributeurs 🙂

Portée par un super bouche-à-oreille sur Twitter, et avec le soutien (entre autres) du collectif SavoirsCom1, la campagne de crowdfunding n’a mis que 2 semaines pour atteindre les 100 % de financement. Tu t’attendais à un tel plébiscite ? C’est important d’aller plus loin ?

Non, je ne m’y attendais pas. Le bouche à oreille sur Twitter a été/est formidable. Ça marche par vague. On peut gagner +30% en deux jours simplement en allant de RT en RT. J’ai aussi eu plusieurs articles juste avant ou après le palier des 100%, dans PCInpact, Actualitté, Numerama, Linuxfr. Je suis heureux que les gens m’aient fait confiance sur les estimations de coût et pour le contenu. La transparence est payante. J’ai aussi tenu à garder des coûts réduits.

J’avais prévu que le financement durerait jusque début septembre à cause des vacances qui allaient former un gros creux en plein milieu. À la fin juillet, celles-ci ont déjà commencé et ont considérablement ralenti les dons. C’est dommage car, après consultation des soutiens, je viens de fixer comme objectif d’arriver à 2200€ pour passer à un palier de 1000 exemplaires 🙂

Outre les 577 députés français, le projet vise maintenant les 57 sénateurs de la commission des affaires culturelles, les 74 eurodéputés français et les hauts-fonctionaires du ministère de la culture par exemple. Une cinquantaine de journalistes sera aussi touchée. Les exemplaires surnuméraires seront distribués aux soutiens du projet et aux membres de mon collectif, SavoirsCom1, pour distribuer/vendre dans des festivals ou associations.

Que dirais-tu pour donner aux lecteurices envie de lire / partager / participer à / soutenir ce livre ? Quels sont ses arguments massue ?

Lisez pour vous faire votre opinion sur le sujet ! Ça vous prendra une heure grand maximum et vous aurez toutes les clés en main. Si vous n’êtes pas convaincu que le sujet est important, lisez seulement l’allégorie du vélo mise au début du livre. À peine 2 minutes de lecture pour vous sensibiliser à la question.

Une fois convaincu par la nécessité d’une réforme et du bien-fondé de ce qui est proposé, le risque est vous soyez défaitistes, sur le mode « Tous des pourris ! ». C’est une erreur, parce qu’en n’essayant rien vous êtes sûr de ne rien obtenir. Vos député(e)s sont des humains comme les autres et le droit d’auteur n’est qu’une question parmi d’autres pour eux. Les lobbies de l’industrie culturelle le savent et en abusent.

Pour contrebalancer ces influences, il est important que les citoyens contactent sérieusement leurs député(e)s et les élus plus généralement. C’est ce à quoi vise l’envoi d’un livre et de lettres personnalisées. Je pense que la forme papier est la plus adaptée car, malheureusement, les mails des citoyens ont tendance à finir aux oubliettes. Nos députés sont pour beaucoup nés dans les années 50 ou 60. Ils vivent dans une culture du papier. Il est important de les avoir informés et relancés du mieux que nous pouvons. Soyons diplomates !

Un dernier mot pour le plaisir ?

Je suis honoré d’être interviewé sur le Framablog dont je suis un lecteur régulier. Merci à Pouhiou et Aka pour leur soutien !

Ensuite sharing is caring 🙂 Partagez, remixez, diffusez le projet et les textes 🙂

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

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

5 raisons de larguer MySQL dès maintenant

5 Reasons It’s Time to Ditch MySQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

« Framasoftienne, framasoftien… » Dans ce court message vidéo, Jérémie Zimmermann s’adresse ici directement à notre communauté (c’est-à-dire à vous) pour nous expliquer en quoi il crucial de soutenir l’action et le développement actuel de la Quadrature du Net.

On compte sur vous (et n’hésitez pas à faire passer à votre voisin(e)).

(Téléchargement : MP4, WebM, Ogg et Torrent)

Soutenir la Quadrature du Net

En remerciement de votre don, vous obtiendrez un « Pi-xel » de la couleur de votre choix 🙂

Ce n’est pas la première fois que la Gendarmerie Nationale mérite un coup de chapeau des libristes, souvenez-vous de la migration massive vers Ubuntu.

Source :

• Comment la Gendarmerie a envoyé bouler Microsoft et McAfee (Numérama)

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

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)