Grande première : des chercheurs américains sont récemment parvenus à créer une cellule bactérienne vivante dont le génome est synthétique.

Il n’en fallait pas plus pour que la presse vulgarise l’évènement en nous posant cette spectaculaire question : et si l’homme venait de créer la vie ?

C’est aller un peu vite en besogne nous précise le célèbre scientifique français Joël de Rosnay : « Craig Venter, l’auteur de la fameuse publication dans Science, n’a pas créé la vie, il a fait un copier coller du génome d’une bactérie qui existe dans la nature ». Mais il reconnaît cependant que « c’est la première fois qu’un être vivant n’a pas d’ancêtre, qu’il a pour père un ordinateur ».

Nous voici donc en présence d’un être vivant dont le père serait partiellement un ordinateur. Or qui manipule cet ordinateur ? Craig Venter et son équipe, et si l’homme est avant tout un biologiste c’est également un homme d’affaire, ce ne sont pas des fonds publics mais privés qui financent ses recherches. Ainsi Le Monde nous révèle que « Venter, qui aurait déjà investi 40 millions de dollars dans ce projet, a déposé un portefeuille de brevets pour protéger son concept de Mycoplasma laboratorium, hypothétique machine à tout faire des biotechnologies ».

Une vie qui n’est alors qu’information et données entrées dans un ordinateur mais dont l’exploitation et l’accès sont strictement contrôlés et réservés aux entreprises qui l’ont enfantée. Cela ressemble à de la mauvaise science-fiction. C’est pourtant peut-être le monde qui nous attend demain. Et l’Apocalypse arrivera plus tôt que prévu^[1].

Sauf si… sauf si on insuffle là aussi un peu d’esprit « open source », nous dit cet article du The Economist traduit ci-dessous.

Avoir ou non la possibilité de « hacker la vie », telle sera l’une des questions fondamentales de ce siècle.

Et l’homme créa la vie…

And man made life

20 mai 2010 – The Economist Newspaper
(Traduction Framalang : Martin, Olivier et Don Rico)

La vie artificielle, porteuse de rêves et de cauchemars, est arrivée.

Créer la vie est la prérogative des dieux. Au plus profond de sa psyché, malgré les conclusions rationnelles de la physique et de la chimie, l’homme a le sentiment qu’il en est autrement pour la biologie, qu’elle est plus qu’une somme d’atomes en mouvement et en interaction les uns avec les autres, d’une façon ou d’une autre insufflée d’une étincelle divine, d’une essence vitale. Quel choc, alors, d’apprendre que de simples mortels ont réussi à créer la vie de façon artificielle.

Craig Venter et Hamilton Smith, les deux biologistes américains qui en 1995 ont démêlé pour la première fois la séquence d’ADN d’un organisme vivant (une bactérie), ont fabriqué une bactérie qui possède un génome artificiel – en créant une créature vivante sans ascendance (voir article). Les plus tatillons pourraient chipoter sur le fait que c’est seulement l’ADN d’un nouvel organisme qui a été conçu en laboratoire, les chercheurs ayant dû utiliser l’enveloppe d’un microbe existant pour que l’ADN fasse son travail. Néanmoins, le Rubicon a été franchi. Il est désormais possible de concevoir un monde où les bactéries (et à terme des animaux et des plantes) seront conçues sur ordinateur et que l’on développera sur commande.

Cette capacité devrait prouver combien l’Homme maîtrise la nature, de façon plus frappante encore que l’explosion de la première bombe atomique. La bombe, bien que justifiée dans le contexte de la Seconde Guerre mondiale, n’avait qu’une fonction de destruction. La biologie, elle, s’attache à « mettre en culture » et « faire croître ». La biologie synthétique, terme sous lequel on regroupe cette technologie et des tas d’autres moins spectaculaires, est très prometteuse. À court terme, elle devrait permettre d’obtenir de meilleurs médicaments, des récoltes moins gourmandes en eau (voir article), des carburants plus écologiques, et donner une nouvelle jeunesse à l’industrie chimique. À long terme, qui peut bien savoir quels miracles elle pourrait permettre d’accomplir ?

Dans cette perspective, la vie artificielle semble être une chose merveilleuse. Pourtant, nombreux sont ceux qui verront cette annonce d’un mauvais œil. Pour certains, ces manipulations relèveront plus de la falsification que de la création. Les scientifiques n’auraient-ils plus les pieds sur terre ? Leur folie conduira-t-elle à l’Apocalypse ? Quels monstres sortiront des éprouvettes des laboratoires ?

Ces questionnements ne sont pas infondés et méritent réflexion, même au sein de ce journal, qui de manière générale accueille les progrès scientifiques avec enthousiasme. La nouvelle science biologique a en effet le potentiel de faire autant de mal que de bien. « Prédateur » et « maladie » appartiennent autant au champ lexical du biologiste que « mettre en culture » et « faire croître ». Mais pour le meilleur et pour le pire, nous y voilà. Créer la vie n’est désormais plus le privilège des dieux.

Enfants d’un dieu mineur

Il est encore loin le temps où concevoir des formes de vie sur un ordinateur constituera un acte biologique banal, mais on y viendra. Au cours de la décennie qui a vu le développement du Projet Génome Humain, deux progrès qui lui sont liés ont rendu cet événement presque inévitable. Le premier est l’accélération phénoménale de la vitesse, et la chute du coût, du séquençage de l’ADN qui détient la clé du « logiciel » naturel de la vie. Ce qui par le passé prenait des années et coûtait des millions prend maintenant quelques jours et coûte dix fois moins. Les bases de données se remplissent de toutes sortes de génomes, du plus petit virus au plus grand des arbres.

Ces génomes sont la matière première de la biologie synthétique. Tout d’abord, ils permettront de comprendre les rouages de la biologie, et ce jusqu’au niveau atomique. Ces rouages pourront alors êtres simulés dans des logiciels afin que les biologistes soient en mesure de créer de nouvelles constellations de gènes, en supposant sans grand risque de se tromper qu’elles auront un comportement prévisible. Deuxièmement, les bases de données génomiques sont de grands entrepôts dans lesquels les biologistes synthétiques peuvent piocher à volonté.

Viendront ensuite les synthèses plus rapides et moins coûteuses de l’ADN. Ce domaine est en retard de quelques années sur l’analyse génomique, mais il prend la même direction. Il sera donc bientôt à la portée de presque tout le monde de fabriquer de l’ADN à la demande et de s’essayer à la biologie synthétique.

C’est positif, mais dans certaines limites. L’innovation se porte mieux quand elle est ouverte à tous. Plus les idées sont nombreuses, plus la probabilité est élevée que certaines porteront leurs fruits. Hélas, il est inévitable que certaines de ces idées seront motivées par une intention de nuire. Et le problème que posent les inventions biologiques nuisibles, c’est que contrairement aux armes ou aux explosifs par exemple, une fois libérées dans la nature, elles peuvent proliférer sans aide extérieure.

La biologie, un monde à part

Le club informatique Home Brew a été le tremplin de Steve Jobs et d’Apple, mais d’autres entreprises ont créé des milliers de virus informatiques. Que se passerait-il si un club similaire, actif dans le domaine de la biologie synthétique, libérait par mégarde une bactérie nocive ou un véritable virus ? Imaginez qu’un terroriste le fasse délibérément…

Le risque de créer quelque chose de néfaste par accident est sans doute faible. La plupart des bactéries optent pour la solution de facilité et s’installent dans de la matière organique déjà morte. Celle-ci ne se défend pas, les hôtes vivants, si. Créer délibérément un organisme nuisible, que le créateur soit un adolescent, un terroriste ou un État-voyou, c’est une autre histoire. Personne ne sait avec quelle facilité on pourrait doper un agent pathogène humain, ou en choisir un qui infecte un certain type d’animal et l’aider à passer d’une espèce à une autre. Nous ne tarderons toutefois pas à le découvrir.

Difficile de savoir comment répondre à une telle menace. Le réflexe de restreindre et de bannir a déjà prouvé son efficacité (tout en restant loin d’être parfait) pour les armes biologiques plus traditionnelles. Mais celles-ci étaient aux mains d’états. L’omniprésence des virus informatiques montre ce qu’il peut se produire lorsque la technologie touche le grand public.

Les observateurs de la biologie synthétique les plus sensés favorisent une approche différente : l’ouverture. C’est une manière d’éviter de restreindre le bon dans un effort tardif de contrer le mal. Le savoir ne se perd pas, aussi le meilleur moyen de se défendre est-il de disposer du plus d’alliés possible. Ainsi, lorsqu’un problème se présente, on peut rapidement obtenir une réponse. Si l’on peut créer des agents pathogènes sur ordinateur, il en va de même pour les vaccins. Et à l’instar des logiciels open source qui permettent aux « gentils sorciers » de l’informatique de lutter contre les « sorciers maléfiques » (NdT : white hats vs black hats), la biologie open source encouragerait les généticiens œuvrant pour le bien.

La réglementation et, surtout, une grande vigilance seront toujours nécessaires. La veille médicale est déjà complexe lorsque les maladies sont d’origine naturelle. Dans le cas le la biologie synthétique, la surveillance doit être redoublée et coordonnée. Alors, que le problème soit naturel ou artificiel, on pourra le résoudre grâce à toute la puissance de la biologie synthétique. Il faut encourager le bon à se montrer plus malin que le mauvais et, avec un peu de chance, on évitera l’Apocalypse.

Un billet très court qui s’interroge furtivement sur l’efficacité réelle ou supposée de l’activisme sur Internet.

Lorsque d’un simple clic, vous décidez d’adhérer au groupe de l’apéro Facebook de votre ville, non seulement cela ne vous engage pas à grand-chose mais en plus l’action proposée est plutôt vide de sens. D’autant que rien ne nous dit que vous vous rendrez bien le jour J sur le lieu du rendez-vous.

Est-ce de l‘activisme ?

Non.

En revanche lorsque vous mettez les pieds dans un projet de logiciels libres, vous voici embarqué dans une aventure riche et complexe tendant vers un objectif commun : l’amélioration collective du code^[1]. Il y a un cadre, une finalité, des outils techniques et des modes opératoires bien précis pour y arriver.

Et si les mouvements de résistance aux brevets logiciels, à l‘ACTA , à DADVSI, à Hadopi… ont pu rencontrer quelques succès, c’est aussi voire surtout parce qu’ils se sont fortement inspirés des modèles d’organisation et de développement du logiciel libre.

Est-ce que cette fois-ci c’est de l’activisme ?

Oui, mais c’est surtout de l’hacktivisme.

Tout ça pour dire qu’à l’ère du réseau, mettre un peu d’hacktivisme dans son activisme participe à augmenter vos chances de réussite 😉

À quoi bon être hacktiviste ?

What’s the Point of Hacktivism?

Glyn Moody – 5 juin 2010 – Open…
(Traductions Framalang : Olivier Rosseler)

Grâce à l’Internet, rien de plus aisé que de participer à de grands débats ; crise environnementale, oppression, injustice. C’est même trop simple : d’un clic votre e-mail s’en va, on ne sait où, d’un clic voilà votre avatar affublé de ce magnifique bandeau de protestation. Si vous pensez que ça a un quelconque effet, lisez le blog Net Effect tenu par Evgeny Morozov, vous changerez rapidement d’avis (d’ailleurs, lisez-le tout court, il est très bien rédigé).

Alors, à quoi bon ? En fait, ce genre d’hacktivisme peut avoir des effets, Ethan Zuckerman en parle très bien dans son article Overcoming apathy through participation? – (not)my talk at Personal Democracy Forum (NdT : Vaincre l’apathie par la participation ? ma présentation (pas de moi) au Personal Democracy Forum). Il y développe une idée qui me parle tout particulièrement :

Si l’on émet l’hypothèse que l’activisme, comme la majorité de ce qui se fait en ligne, est caractérisé par une distribution de Pareto, on peut alors supposer que pour 1000 sympathisants plutôt passifs on a 10 activistes vraiment engagés et 1 meneur qui émerge. Et si l’assertion « la participation engendre la passion » est vraie, cette longue traine (NdT : de la distribution de Pareto) pourrait être un terrain glissant ascendant d’où émergent plus de meneurs que dans les mouvements classiques.

Les lecteurs les plus attentifs auront fait le lien avec le succès des modèles open source qui permettent aux meneurs naturels de se démarquer de tous les participants. Cette méthode a déjà fait ses preuves, tous ceux à qui on n’aurait pas donné leur chance autrement et qui ont pu ainsi prouver leur valeur en sont témoins. Pour moi, cela justifie amplement la nécessité d’encourager l’hacktivisme, dans l’espoir de faire émerger quelque chose de similaire dans d’autres sphères.

Le 5 mars dernier, Tristan Nitot se pose la question suivante sur Identi.ca : « Je me demande s’il existe une version française de Code is Law, ce texte sublime de Lessig ».

Monsieur Nitot qui évoque un texte sublime de Monsieur Lessig… Mais que vouliez-vous que nos traducteurs de Framalang fassent, si ce n’est participer à modifier favorablement la réponse de départ étonnamment négative !

Écrit il y a plus de dix ans, cet article majeur a non seulement fort bien vieilli mais se serait même bonifié avec le temps et l’évolution actuelle du « cyberespace » où neutralité du net et place prise par les Microsoft, Apple, Google et autres Facebook occupent plus que jamais les esprits et nos données^[1].

Bonne lecture…

Le code fait loi – De la liberté dans le cyberespace

Code is Law – On Liberty in Cyberspace

Lawrence Lessig – janvier 2000 – Harvard Magazine
(Traduction Framalang : Barbidule, Siltaar, Goofy, Don Rico)

À chaque époque son institution de contrôle, sa menace pour les libertés. Nos Pères Fondateurs craignaient la puissance émergente du gouvernement fédéral ; la constitution américaine fut écrite pour répondre à cette crainte. John Stuart Mill s’inquiétait du contrôle par les normes sociales dans l’Angleterre du 19e siècle ; il écrivit son livre De la Liberté en réaction à ce contrôle. Au 20e siècle, de nombreux progressistes se sont émus des injustices du marché. En réponse furent élaborés réformes du marché, et filets de sécurité.

Nous sommes à l’âge du cyberespace. Il possède lui aussi son propre régulateur, qui lui aussi menace les libertés. Mais, qu’il s’agisse d’une autorisation qu’il nous concède ou d’une conquête qu’on lui arrache, nous sommes tellement obnubilés par l’idée que la liberté est intimement liée à celle de gouvernement que nous ne voyons pas la régulation qui s’opère dans ce nouvel espace, ni la menace qu’elle fait peser sur les libertés.

Ce régulateur, c’est le code : le logiciel et le matériel qui font du cyberespace ce qu’il est. Ce code, ou cette architecture, définit la manière dont nous vivons le cyberespace. Il détermine s’il est facile ou non de protéger sa vie privée, ou de censurer la parole. Il détermine si l’accès à l’information est global ou sectorisé. Il a un impact sur qui peut voir quoi, ou sur ce qui est surveillé. Lorsqu’on commence à comprendre la nature de ce code, on se rend compte que, d’une myriade de manières, le code du cyberespace régule.

Cette régulation est en train de changer. Le code du cyberespace aussi. Et à mesure que ce code change, il en va de même pour la nature du cyberespace. Le cyberespace est un lieu qui protège l’anonymat, la liberté d’expression et l’autonomie des individus, il est en train de devenir un lieu qui rend l’anonymat plus difficile, l’expression moins libre et fait de l’autonomie individuelle l’apanage des seuls experts.

Mon objectif, dans ce court article, est de faire comprendre cette régulation, et de montrer en quoi elle est en train de changer. Car si nous ne comprenons pas en quoi le cyberespace peut intégrer, ou supplanter, certaines valeurs de nos traditions constitutionnelles, nous perdrons le contrôle de ces valeurs. La loi du cyberespace – le code – les supplantera.

Ce que contrôle le code

Le code élémentaire d’Internet est constitué d’un ensemble de protocoles appelé TCP/IP. Ces protocoles permettent l’échange de données entre réseaux interconnectés. Ces échanges se produisent sans que les réseaux aient connaissance du contenu des données, et sans qu’ils sachent qui est réellement l’expéditeur de tel ou tel bloc de données. Ce code est donc neutre à l’égard des données, et ignore tout de l’utilisateur.

Ces spécificités du TCP/IP ont des conséquences sur la régulabilité des activités sur Internet. Elles rendent la régulation des comportements difficile. Dans la mesure où il est difficile d’identifier les internautes, il devient très difficile d’associer un comportement à un individu particulier. Et dans la mesure où il est difficile d’identifier le type de données qui sont envoyées, il devient très difficile de réguler l’échange d’un certain type de données. Ces spécificités de l’architecture d’Internet signifient que les gouvernements sont relativement restreints dans leur capacité à réguler les activités sur le Net.

Dans certains contextes, et pour certaines personnes, cette irrégulabilité est un bienfait. C’est cette caractéristique du Net, par exemple, qui protège la liberté d’expression. Elle code l’équivalent d’un Premier amendement dans l’architecture même du cyberespace, car elle complique, pour un gouvernement ou une institution puissante, la possibilité de surveiller qui dit quoi et quand. Des informations en provenance de Bosnie ou du Timor Oriental peuvent circuler librement d’un bout à l’autre de la planète car le Net empêche les gouvernements de ces pays de contrôler la manière dont circule l’information. Le Net les en empêche du fait de son architecture même.

Mais dans d’autres contextes, et du point de vue d’autres personnes, ce caractère incontrôlable n’est pas une qualité. Prenez par exemple le gouvernement allemand, confronté aux discours nazis, ou le gouvernement américain, face à la pédo-pornographie. Dans ces situations, l’architecture empêche également tout contrôle, mais ici cette irrégulabilité est considérée comme une tare.

Et il ne s’agit pas seulement des discours nazis et de pornographie enfantine. Les principaux besoins de régulation concerneront le commerce en ligne : quand l’architecture ne permet pas de transactions sécurisées, quand elle permet de masquer facilement la source d’interférences, quand elle facilite la distribution de copies illégales de logiciels ou de musique. Dans ces contextes, le caractère incontrôlable du Net n’est pas considéré comme une qualité par les commerçants, et freinera le développement du commerce.

Que peut-on y faire ?

Nombreux sont ceux qui pensent qu’il n’y a rien à faire : l’irrégulabilité d’Internet est définitive. Il n’est rien que nous puissions faire pour y remédier. Aussi longtemps qu’il existera, Internet restera un espace incontrôlable. C’est dans sa nature même.

Mais rien n’est plus dangereux pour l’avenir de la liberté dans le cyberespace que de croire la liberté garantie par le code. Car le code n’est pas figé. L’architecture du cyberespace n’est pas définitive. L’irrégulabilité est une conséquence du code, mais le code peut changer. D’autres architectures peuvent être superposées aux protocoles de base TCP/IP, et ces nouvelles couches peuvent rendre l’usage du Net fondamentalement contrôlable. Le commerce est en train de construire une architecture de ce type. Le gouvernement peut y aider. Les deux réunis peuvent transformer la nature même du Net. Il le peuvent, et le font.

D’autres architectures

Ce qui rend le Net incontrôlable, c’est qu’il est difficile d’y savoir qui est qui, et difficile de connaître la nature des informations qui y sont échangées. Ces deux caractéristiques sont en train de changer : premièrement, on voit émerger des architectures destinées à faciliter l’identification de l’utilisateur, ou permettant, plus généralement, de garantir la véracité de certaines informations le concernant (qu’il est majeur, que c’est un homme, qu’il est américain, qu’il est avocat). Deuxièmement, des architectures permettant de qualifier les contenus (pornographie, discours violent, discours raciste, discours politique) ont été conçues, et sont déployées en ce moment-même. Ces deux évolutions sont développées sans mandat du gouvernement ; et utilisées conjointement elles mèneraient à un degré de contrôle extraordinaire sur toute activité en ligne. Conjointement, elles pourraient renverser l’irrégulabilité du Net.

Tout dépendrait de la manière dont elles seraient conçues. Les architectures ne sont pas binaires. Il ne s’agit pas juste de choisir entre développer une architecture permettant l’identification ou l’évaluation, ou non. Ce que permet une architecture, et la manière dont elle limite les contrôles, sont des choix. Et en fonction de ces choix, c’est bien plus que la régulabilité qui est en jeu.

Prenons tout d’abord les architectures d’identification, ou de certification. Il existe de nombreuses architectures de certification dans le monde réel. Le permis de conduire, par exemple. Lorsque la police vous arrête et vous demande vos papiers, ils demandent un certificat montrant que vous êtes autorisé à conduire. Ce certificat contient votre nom, votre sexe, votre âge, votre domicile. Toutes ces informations sont nécessaires car il n’existe aucun autre moyen simple pour établir un lien entre le permis et la personne. Vous devez divulguer ces éléments vous concernant afin de certifier que vous êtes le titulaire légitime du permis.

Mais dans le cyberespace, la certification pourrait être ajustée beaucoup plus finement. Si un site est réservé aux adultes, il serait possible – en utilisant des technologies de certification – de certifier que vous êtes un adulte, sans avoir à révéler qui vous êtes ou d’où vous venez. La technologie pourrait permettre de certifier certains faits vous concernant, tout en gardant d’autres faits confidentiels. La technologie dans le cyberespace pourrait fonctionner selon une logique de « moindre révélation », ce qui n’est pas possible dans la réalité.

Là encore, tout dépendrait de la manière dont elle a été conçue. Mais il n’est pas dit que les choses iront dans ce sens. Il existe d’autres architectures en développement, de type « une seule carte pour tout ». Dans ces architectures, il n’est plus possible de limiter simplement ce qui est révélé par un certificat. Si sur un certificat figure votre nom, votre adresse, votre âge, votre nationalité, ainsi que le fait que vous êtes avocat, et si devez prouver que vous êtes avocat, cette architecture certifierait non seulement votre profession, mais également tous les autres éléments vous concernant qui sont contenus dans le certificat. Dans la logique de cette architecture, plus il y a d’informations, mieux c’est. Rien ne permet aux individus de faire le choix du moins.

La différence entre ces deux conceptions est que l’une garantit la vie privée, alors que l’autre non. La première inscrit le respect de la vie privée au cœur de l’architecture d’identification, en laissant un choix clair à l’utilisateur sur ce qu’il veut révéler ; la seconde néglige cette valeur.

Ainsi, le fait que l’architecture de certification qui se construit respecte ou non la vie privée dépend des choix de ceux qui codent. Leurs choix dépendent des incitations qu’ils reçoivent. S’il n’existe aucune incitation à protéger la vie privée – si la demande n’existe pas sur le marché, et que la loi est muette – alors le code ne le fera pas.

L’identification n’est qu’un exemple parmi d’autres. Prenons-en un deuxième, concernant la confidentialité des informations personnelles. RealJukebox est une technologie permettant de copier un CD de musique sur un ordinateur, ou de de télécharger de la musique sur le Net pour la stocker sur un disque dur. Il est apparu en octobre que le système était un peu trop curieux : il inspectait discrètement le disque dur de l’utilisateur, puis transférait à l’entreprise le fruit de ses recherches. Tout ceci en secret, bien entendu : RealNetworks n’avait prévenu personne que son produit collectait et transférait des données personnelles. Quand cet espionnage a été découvert, l’entreprise a tout d’abord tenté de justifier cette pratique (en avançant qu’aucune donnée personnelle n’était conservée), mais elle a fini par revenir à la raison, et a promis de ne plus recueillir ces données.

Ce problème est dû, une fois de plus, à l’architecture. Il n’est pas facile de dire qui espionne quoi, dans le cyberespace. Bien que le problème puisse être corrigé au niveau de l’architecture (en faisant appel à la technologie P3P, par exemple), voici un cas pour lequel la loi est préférable. Si les données personnelles étaient reconnues comme propriété de l’individu, alors leur collecte sans consentement exprès s’apparenterait à du vol.

Dans toutes ces circonstances, les architectures viendront garantir nos valeurs traditionnelles – ou pas. À chaque fois, des décisions seront prises afin de parvenir à une architecture d’Internet respectueuse de ces valeurs et conforme à la loi. Les choix concernant le code et le droit sont des choix de valeurs.

Une question de valeurs

Si c’est le code qui détermine nos valeurs, ne devons-nous pas intervenir dans le choix de ce code ? Devons-nous nous préoccuper de la manière dont les valeurs émergent ici ?

En d’autres temps, cette question aurait semblé incongrue. La démocratie consiste à surveiller et altérer les pouvoirs qui affectent nos valeurs fondamentales, ou comme je le disais au début, les contrôles qui affectent la liberté. En d’autres temps, nous aurions dit « Bien sûr que cela nous concerne. Bien sûr que nous avons un rôle à jouer. »

Mais nous vivons à une époque de scepticisme à l’égard de la démocratie. Notre époque est obsédée par la non-intervention. Laissons Internet se développer comme les codeurs l’entendent, voilà l’opinion générale. Laissons l’État en dehors de ça.

Ce point de vue est compréhensible, vu la nature des interventions étatiques. Vu leurs défauts, il semble préférable d’écarter purement et simplement l’État. Mais c’est une tentation dangereuse, en particulier aujourd’hui.

Ce n’est pas entre régulation et absence de régulation que nous avons à choisir. Le code régule. Il implémente – ou non – un certain nombre de valeurs. Il garantit certaines libertés, ou les empêche. Il protège la vie privée, ou promeut la surveillance. Des gens décident comment le code va se comporter. Des gens l’écrivent. La question n’est donc pas de savoir qui décidera de la manière dont le cyberespace est régulé : ce seront les codeurs. La seule question est de savoir si nous aurons collectivement un rôle dans leur choix – et donc dans la manière dont ces valeurs sont garanties – ou si nous laisserons aux codeurs le soin de choisir nos valeurs à notre place.

Car c’est une évidence : quand l’État se retire, la place ne reste pas vide. Les intérêts privés ont des objectifs qu’ils vont poursuivre. En appuyant sur le bouton anti-Étatique, on ne se téléporte pas au Paradis. Quand les intérêts gouvernementaux sont écartés, d’autres intérêts les remplacent. Les connaissons-nous ? Sommes-nous sûrs qu’ils sont meilleurs ?

Notre première réaction devrait être l’hésitation. Il est opportun de commencer par laisser le marché se développer. Mais, tout comme la Constitution contrôle et limite l’action du Congrès, les valeurs constitutionnelles devraient contrôler et limiter l’action du marché. Nous devrions examiner l’architecture du cyberespace de la même manière que nous examinons le fonctionnement de nos institutions.

Si nous ne le faisons pas, ou si nous n’apprenons pas à le faire, la pertinence de notre tradition constitutionnelle va décliner. Tout comme notre engagement autour de valeurs fondamentales, par le biais d’une constitution promulguée en pleine conscience. Nous resterons aveugles à la menace que notre époque fait peser sur les libertés et les valeurs dont nous avons hérité. La loi du cyberespace dépendra de la manière dont il est codé, mais nous aurons perdu tout rôle dans le choix de cette loi.

Lawrence Lessig est professeur de droit des affaires au Centre Berkman de la Harvard Law School. Son dernier livre, « Le code, et les autres lois du cyberespace » (Basic Books), vient d’être publié (voir http://code-is-law.org). Le site du Centre Berkman pour l’Internet et la Société est http://cyber.law.harvard.edu.

Voici une courte traduction qui aborde furtivement deux sujets selon nous intéressants. Le premier n’est pas nouveau puisqu’il évoque la traditionnelle différence d’approche entre le logiciel libre cher à Richard Stallman et l’open source, à ceci près que l’avènement du cloud computing lui donne un nouvel éclairage.

Le second est peut-être plus original puisqu’il met en parallèle les logiciels et les données pour constater un mouvement opposé.

Nous sommes nombreux à souhaiter que les logiciels deviennent de plus en plus libres. Mais des Google et des Facebooks ont également envie que nos données suivent le même chemin pour pouvoir les manipuler tout à leur guise. C’est même fondamental pour eux puisque c’est tout leur business model qui est construit sur cela.

Or nous nous inquiétons chaque jour davantage du devenir de nos données, et si nous les souhaitons « libres » c’est avant tout libres de ne pas être contrôlées et exploitées sans notre consentement. Liberté et ouverture n’ont donc clairement pas le même sens chez les uns et chez les autres^[1].

Il faut dire que dans les nuages : logiciels, formats, fichiers et données s’entrechoquent. Quand par exemple vous faites du traitement de texte directement en ligne (Google Docs, Zoho, etc.), c’est un peu tout à la fois qui est sollicité, sans qu’on n’arrive plus trop bien à les distinguer.

« Ouvrons » nos logiciels mais « fermons » nos données ? C’est en résumé, la question brutale que pose ce billet.

Libérez mes logiciels, pas mes données

Open source my software but not my data

Dana Blankenhorn – 27 avril 2010 – ZDNet (Blog Linux and Open Source)
(Traduction Framalang : Kovalsky, Barbidule et Goofy)

Comme Google avant lui, Facebook fait l’objet d’une attention accrue pour son interprétation du terme « ouvert » dans le monde en ligne.

Que les logiciels soient libres est une bonne chose. Mais que les données soient ouvertes ? Peut être pas tant que ça.

L’affirmation classique concernant le logiciel est qu’à moins que vous utilisiez l’AGPL, à moins que tout ne soit ouvert y compris vos sources secrètes, vous n’êtes pas vraiment ouvert, vous prétendez seulement l’être. Ouvert serait juste un autre mot pour dire que vous n’avez rien à cacher.

Je n’y ai jamais cru. L’open source n’est pas la même chose que le logiciel libre, c’est une des premières leçons qu’on m’a apprises quand j’ai commencé ce combat. (Richard Stallman s’en est chargé personnellement.)

L’open source est un continuum de choix, allant de l’idéal des logiciels libres de Stallman jusqu’au code de Microsoft sous restrictions serrées. L’open source est né en réaction logiciel libre de Stallman, et parfois en opposition à celui-ci.

Précédemment, j’ai mis au point une courbe de l’open source, pour illustrer l’étendue des choix disponibles. Plus vous avez besoin d’une participation de la communauté, plus vous êtes en bas de la courbe. Plus votre contrôle de la propriété du code augmente, plus vous êtes en haut.

Plus tard j’ai modifié cela en élaborant une courbe du développement open source, prenant en compte différents modèles de développement.

Ce qui est notable à propos de l’essentiel du code conçu pour être utilisé en ligne, c’est qu’il n’est généralement pas en bas de la courbe. Même Google n’est pas en bas de la courbe, bien qu’il soit un membre de la communauté open source tout à fait respectable. Google ne soutient pas l’AGPL.

Mais qu’en est il des données ? Qui décide du statut des données en ligne ? Est ce que la décision vous appartient, ou revient-elle aux entreprises qui hébergent les données ?

Facebook a assimilé les données à du logiciel, et il se permet alors de les diffuser dans la nature, en affirmant qu’il ne fait que suivre les principes de l’open source.

Quand vous comparez libre et propriétaire dans le monde logiciel, le libre semble formidable. Mais comparez-les sous l’angle des données, sur le mode « vos données seront ouvertes sauf si vous dites non », et les Sénateurs vont y voir une violation de la vie privée. En particulier si, comme Facebook, vous vous étiez vous-même défini jusqu’à récemment comme un réseau privé sans risque pour les enfants, et non comme un classique espace ouvert du Web.

Il est facile pour les logiciels de se déplacer vers le haut ou le bas de la courbe de l’open source. Pour les données cela se révèle problématique.

La vaste communauté Drupal compte un contributeur bien particulier puisqu’il s’agit ni plus ni moins de la Maison Blanche.

C’était déjà bien d’adopter le célèbre CMS libre pour faire tourner le site officiel (ce que nous avions signalé dans un précédent billet), mais c’est encore mieux de participer à son amélioration en reversant le code spécifique développé pour l’occasion, et en le faisant savoir sur son blog (traduit ci-dessous)^[1].

Un billet et une traduction directement suggérés par ce journal LinuxFr de Francois G (auteur de la rafraichissante nouvelle de science-fiction Églantine et les ouinedoziens) dont la présentation se suffit à elle-même :

« Le site de la Maison Blanche vient de diffuser le code source des améliorations qu’ils ont apportés au projet Drupal (à noter tous les liens vers le site du projet Drupal dans le billet).

Les 3 bonnes nouvelles :

• La Maison Blanche a compris qu’elle peut être maître de ses outils informatiques.
• Elle en profite (modifications spécifiques) et en fait profiter les autres (diffusion à tous).
• Elle communique sur cette action. De ce fait, elle annonce officiellement son support et son utilisation des logiciels libres.

Compte tenu de la volonté de l’Élysée de copier la Maison Blanche, on peut espérer un changement de politique chez nous. »

WhiteHouse.gov participe à l’Open Source

WhiteHouse.gov Releases Open Source Code

Dave Cole – 21 avril 2010 – The White House Blog
(Traduction Framalang : Quentin Theuret et Julien Reitzel)

Dans le cadre de nos efforts continus pour développer une plateforme ouverte pour WhiteHouse.gov, nous mettons à disposition de tous une partie du code source personnalisé que nous avons développé. Ce code est disponible à tous pour l’analyser, l’utiliser ou le modifier. Nous sommes impatients de voir comment des développeurs à travers le monde pourront utiliser notre travail dans leurs propres applications.

En reversant une partie de notre code source, nous bénéficions de l’analyse et de l’amélioration d’un plus grand nombre de personnes. En fait, la majorité du code source de WhitHouse.gov est dès à présent open source car il fait partie du projet Drupal. Le code source que nous relâchons aujourd’hui ajoute des fonctionnalités à Drupal dans trois domaines importants :

1. Évolutivité : Nous publions un module nommé Context HTTP Headers, qui permet aux webmasters d’ajouter de nouvelles métadonnées au contenu qu’ils publient. Nous utilisons cela pour nos serveurs qui manipulent des pages spécifiques, comme la mise en cache de ce type de page pendant 15 minutes ou ce type pendant 30. Un second module concernant l’évolutivité s’appelle Akamai et il permet à notre site web de s’intégrer avec notre réseau d’envoi de contenu Akamai.

2. Communication : Beaucoup d’agences gouvernementales ont des programmes actifs d’emails qu’ils utilisent pour communiquer avec le public à travers des services qu’ils fournissent. Nous avons une liste de diffusion pour la Maison Blanche, où vous pouvez trouver les mises à jour des nouveaux contenus et des initiatives. Pour rendre plus dynamique l’adaptation des emails aux préférences des utilisateurs, nous avons intégré l’un des services les plus populaires pour les programmes d’emails gouvernementaux dans notre CMS avec le nouveau module GoDelivery.

3. Accessibilité : Nous prenons très au sérieux nos obligations pour être sûrs que WhiteHouse.gov soit accessible le plus possible et nous nous sommes engagés à tendre vers les standards d’accessibilité décrits par la Section 508. Dans le cadre de cette conformité, nous voulons être sûrs que toutes les images sur notre site Web aient des métadonnées appropriées pour les rendre visibles sur des logiciels de lecture vocale. Pour nous aider à atteindre cela, pour que ce soit plus facile de gérer les contenus photos et vidéos que vous voyez sur notre site, nous avons développé Node Embed.

Dans la famille des grands trolls de la communauté, je demande Mono.

On attend avec impatience un futur dessin sur la Fondation Codeplex qui nous valu une belle passe d’armes entre Manuel de Icaza (à l’origine de Mono) et Richard Stallman (co-auteur de sa framabiographie) 😉

J’en profite pour signaler le concours de scénario lancé par notre ami Gee à l’occasion du prochain premier anniversaire de son blog.

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

Voici un récent article du Guardian qui tourne paradoxalement autour du logiciel libre et des formats ouverts mais sans véritablement les nommer.

Nous avons cependant jugé qu’il avait son intérêt dans la mesure où la science et la recherche ont désormais de plus en plus recourt à l’informatique pour traiter des données et en tirer analyses et conclusions^[1].

Or comment voulez-vous que l’on puisse valider les résultats si les applications utilisées sont propriétaires ou si les chercheurs eux-mêmes ne mettent pas le code de leur programme à disposition ?

L’article s’appuie sur la récente affaire dite du « Climategate » qui a fait grand bruit outre-Manche (et étrangement peu de cas chez nos grands médias français).

Quand recherche sérieuse rime avec libération du code informatique

If you’re going to do good science, release the computer code too

Darrel Ince – 5 février 2010 – The Guardian
(Traduction Framalang : Kovalsky et Olivier)

Les programmes informatiques prennent chaque jour plus de place dans le travail scientifique. Mais partie prenante dans les conditions de l’expérience vous devez pouvoir les vérifier comme en atteste la bataille qui se joue autour des données sur le changement climatique.

On retiendra de l’affaire concernant la révélation publique des e-mails et des documents de l’Unité de Recherche Climatique de l’Université d’East Anglia qu’ils mettent en lumière le rôle du code informatique dans la recherche climatique. Il y a notamment une série de « README » produite par un programmeur de l’UEA connu sous le nom de « Harry ». Ces notes sont celles de quelqu’un qui lutte avec du code ancien non-documenté, et des données manquantes. Et pourtant, on parle bien d’un élément de l’une des trois bases de données climatiques principales dont se sont servis les chercheurs du monde entier pour en tirer analyses et conclusions.

Beaucoup de scientifiques du climat ont refusé de publier leur programme informatique. À mes yeux, ça n’est ni scientifique, ni responsable, parce que les logiciels scientifiques sont réputés pour leur manque de fiabilité.

L’Histoire nous a appris à ne pas faire une confiance aveugle aux logiciels scientifiques. Par exemple le Professeur Les Hatton, un expert international en tests logiciels, résident de l’Université du Kent et de Kingston, a mené une analyse approfondie de plusieurs millions de lignes de code scientifique. Il a montré que les logiciels présentaient un nombre exceptionnellement élevé d’erreurs détectables.

Par exemple, les erreurs de communication entre les modules de logiciels qui envoient les données d’une partie d’un programme à une autre se produisent à une fréquence de 1 pour 7 communications en moyenne dans le langage de programmation Fortran, et de 1 pour 37 communications dans le langage C. C’est d’autant plus inquiétant qu’une seule et unique erreur est susceptible d’invalider un programme informatique. Plus grave encore, il a découvert que la précision des résultats chute de six chiffres significatifs à un chiffre significatif après traitement par certains programmes.

Les travaux d’Hatton et d’autres chercheurs indiquent que les logiciels scientifiques sont souvent de mauvaise qualité. Il est stupéfiant de constater que cette recherche a été menée sur des logiciels scientifiques commerciaux, produits par des ingénieurs logiciels soumis à un régime de tests, d’assurance qualité et à une discipline de contrôle des modifications plus connue sous le nom de gestion de configuration.

À l’opposé, les logiciels scientifiques développés dans nos universités et nos instituts de recherches sont souvent produits, sans assurance qualité, par des scientifiques qui n’ont pas de formation en ingénierie logicielle et donc, sans aucun doute, l’occurence des erreurs sera encore plus élevée. Les fichiers « Harry ReadMe » de l’Unité de Recherche Climatique sont une preuve flagrante de ces conditions de travail. Ils résument les frustrations d’un programmeur dans sa tentative de conformer ses séries de données à une spécification.

Le code informatique est au coeur d’un problème scientifique. La science se définit par sa potentielle remise en cause : si vous érigez une théorie et que quelqu’un prouve qu’elle est fausse, alors elle s’écroule et on peut la remplacer. C’est comme cela que fonctione la science : avec transparence, en publiant chaque détail d’une expérience, toutes les équations mathématiques ou les données d’une simulation. Ce-faisant vous acceptez et même encouragez la remise en question.

Cela ne semble pas être arrivé dans la recherche climatique. De nombreux chercheurs ont refusé de publier leur programme informatique, même ceux qui sont encore utilisés et qui ne sont pas sujet à des accords commerciaux. Le Professeur Mann, par exemple, refusa tout d’abord de fournir le code, employé pour construire en 1999 le graphique en cross de hockey, qui a démontré que l’impact de l’homme sur le réchauffement climatique est un artefact unique de la dernière décennie (il l’a finalement publié en 2005).

La situation n’est pas aussi désastreuse pour tous les travaux académiques. Certaines revues, économiques et économétriques par exemple, imposent que l’auteur soumette ses données et ses programmes au journal avant publication. Un cas fondamental en mathématiques a également fait parler de lui : la preuve « par ordinateur » de la conjoncture des quatre couleurs par Appel et Haken. Cette démonstration a partagé la communauté scientifique puisque pour la première fois le problème de la validation du théorème s’est trouvé déplacé vers le problème de la validation de l’algorithme d’exploration et de sa réalisation sous forme de programme. Bien que critiquée pour son manque d’élégance, la preuve n’en était pas moins correcte et le programme informatique, publié et donc vérifiable.

Des organismes et des individus, ralliés à l’idée du quatrième paradigme, attachent beaucoup d’importance au problème de l’informatique scientifique à grande échelle et à la publication des données. C’était l’idée de Jim Gray, un chercheur expérimenté de Microsoft, qui a identifié le problème bien avant le Climategate. Actuellement, la recherche consacrée aux mécanismes qui pourraient faire du Web un dépôt pour les publications scientifiques est très active, elle englobe également les logiciels et la formidable quantité de données qu’ils consomment et génèrent. Un certain nombre de chercheurs mettent au point des systèmes qui montrent le progrès d’une idée scientifique, des premières ébauches d’idées jusqu’à la publication papier^[2]. Les problèmes rencontrées avec la recherche climatique apporteront un élan à ce travail pour qu’il soit accéléré.

Donc, si vous publiez des articles de recherche qui s’appuient sur des programmes informatiques, si vous prétendez faire de la science mais que vous refusez de publier les programmes en votre possession, je ne peux vous considérer comme un scientifique. J’en irais même jusqu’à dire qu’à mes yeux les publications basées sur ces programmes seront nulles et non avenues.

Je trouve incroyable qu’une faute de frappe puisse être à l’origine d’une erreur dans un programme, un programme qui pourrait à son tour être à l’origine de décisions portant sur des milliards d’euros, et le pire, c’est que la fréquence de ces erreurs est élevée. Les algorithmes (ou copules gaussiennes), sur lesquels se sont appuyées les banques pour s’assurer que les crédits sub-prime étaient sans risque pour eux, ont été publiées. La facture était salée. La facture du changement climatique sera aussi élevée. Raison de plus pour qu’aucune erreur dans les calculs ne soit tolérée là non plus.

Si vous avez le malheur de développer un projet « open source » au sein de votre entreprise alors vous courrez le risque de voir arriver une « communauté » qui peut à tout moment s’agréger autour du code source de votre logiciel et en menacer sa bonne gouvernance.

Heureusement le développeur Josh Berkus est là pour vous expliquer point par point comment faire pour être certain de ruiner et dissoudre toute velléité communautaire (au cours d’une intervention donnée il y a un mois à la Linux.Conf.au et relatée ici par Jonathan Corbet)^[1].

Un article évidemment ironique (qui détourne les howto), mais qui donne à réfléchir sur les relations subtiles et complexes qui peuvent exister entre les communautés et les entreprises qui œuvrent sur un même projet.

Pas toujours facile de se comprendre en effet quand les uns disent plutôt « logiciel libre » et les autres plutôt « open source » (voire même parfois carrément « fauxopen source »).

Et puis, c’est pratique, puisqu’on dispose ainsi de tout ce qu’il ne faut pas faire pour réussir un projet communautaire.

On notera que Josh Berkus avait la société Sun Microsystems en tête lorsqu’il a énoncé son propos (Sun soutient notamment MySQL et OpenOffice.org). Mais comme il le précise lui-même a posteriori sur son blog, cela peut s’appliquer à n’importe quelle « corporate open source » et de citer alors entre autres Red Hat, Microsoft, IBM, Cisco, SugarCRM, Novell, Compiere, Borland, Google, ou encore Apple. « Si vous avez à faire à une compagnie qui possède un projet open source, vous pouvez être sûr à 95% qu’elle suit au moins un des dix points mentionnés ci-dessous »

Et de conclure positivement sur la nécessité de cultiver l’un des mots clés les plus importants de la communauté : la confiance.

Comment détruire votre communauté : mode d’emploi

How to destroy your community

Jonathan Corbet – 18 janvier 2010 – LWN.net
(Traduction Framalang : Olivier, Daria et Don Rico)

Le réputation de Josh Berkus en tant que hacker de PostgreSQL n’est plus à faire, mais ce n’est pas sa seule compétence, puisqu’il a aussi acquis une précieuse expérience durant sa pige au « Laboratoire de Destruction des Communautés », plus connu sous le nom de Sun Microsystems. Il y a suivi « l’enseignement breveté en 10 étapes » pour apprendre à débarrasser un projet de toute ingérence de la communauté.

La présentation très dynamique qu’a donnée Josh à la Linux.Conf.au sur le sujet était la première discussion de la miniconf L’économie de l’open source ; l’audience lui a réservé un accueil chaleureux.

Si vous êtes développeur dans une grosse entreprise, vous vous rendrez rapidement compte que les communautés de développement des logiciels libres sont une plaie. Dites adieu à vos plans marketing, par exemple, car elle se chargera d’introduire le logiciel dans des pays où vous êtes absents et pour lesquels vous n’avez pas de plan. Ils flanqueront par terre vos prévisions produits en sortant des innovations non-prévues, en implémentant des fonctionnalités des années avant ce que vous aviez planifié, ou pire encore, des fonctionnalités qui devaient être réservées à la version propriétaire de votre logiciel. Les communautés de logiciels libres sont d’éternelles insatisfaites, elles n’ont de cesse de vouloir améliorer les choses. Elles ont tendance à redéfinir les relations avec vos partenaires et vos clients, et vos commerciaux ne savent plus à quel saint se vouer. Et sans arrêt elles vous dérangent : un e-mail par ci, une conférence à laquelle vous devriez assister par là, etc.

Mais heureusement, des solutions existent pour vous débarrasser de la menace que représente cette communauté. Il suffit d’appliquer une ou plusieurs des étapes suivantes.

1. Rendez le projet dépendant d’outils complexes

Il a remarqué qu’en général, les entreprises n’ont pas de problème avec cette technique puisqu’elles aiment s’appuyer sur leurs propres outils. Pour les projets où la communauté n’est pas la bienvenue, il faut par exemple employer des systèmes singuliers qu’on ne trouve nulle part ailleurs. Un système de contrôle de version propriétaire (NdT : version control system) est absolument obligatoire. Mieux encore, un outil de suivi des problèmes (NdT : issue tracking system) avec un nombre limité de licences, afin que tout le monde doive s’y connecter avec le même compte.

N’oubliez pas de mettre en place un site Web qui respecte la parité : 50% du temps planté, 50% du temps opérationnel. Ne pas mettre de site à disposition ne suffira pas : dans de telles situations, la communauté a la fâcheuse habitude de créer le sien. Avec un site bancal, en revanche, vous vous en prémunirez et vous assurerez que l’information restera bien cachée.

2. Attirez les participants nocifs et optimisez les dégâts qu’ils peuvent engendrer

Ce cas particulier nécessite quelques étapes :

1. Prenez sur vous et engagez-vous dans de longs débats avec ces personnes et dénoncez-les sur les listes du projet.
2. Au bout d’un certain temps, bannissez-les par décret ; évitez à tout prix tout processus communautaire.
3. Les gens bannis déverseront leur bile ailleurs. Vous devez les suivre et poursuivre votre débat sur ces sites externes.
4. Enfin, la communauté se plaindra de ce comportement. Votre réponse sera simple : réintégrez les enquiquineurs à la communauté. Reprenez à la première étape et recommencez.

D’après Josh, un casse-pieds bien pris en main peut annihiler une communauté de plusieurs centaines de membres.

3. Ne fournissez pas de documentation

Aucune information utile ne devrait être disponible, ni pour le code, ni sur les méthodes de compilation, rien sur le processus de soumission de correctif, ni sur le processus de sortie, rien de rien. Puis, quand on demandera de l’aide, répondez « Lis la notice, bordel ! » (NdT : RTFM pour Read the fucking manual)

4. Prenez les décisions relatives au projet en petit comité

Pour bien commencer, vous pouvez organiser vos réunions en ligne en ne prévenant les participants que très peu de temps à l’avance. Pour que cette technique soit vraiment efficace, prévoyez ces réunions à des heures incompatibles avec le fuseau horaire commun à la plupart des membres de la communauté.

Le mieux est encore de tout faire en visioconférence : vous exclurez de fait environ un tiers de la planète pour qui elle se déroule de nuit, de plus, les gens ont un boulot, tant pis pour eux aussi. Mais le must reste encore d’organiser les réunions en personne au siège de la société.

5. Sortez la grosse artillerie juridique

S’impliquer dans le projet devrait rimer avec accords de participation alambiqués, contrats de licence protégeant le contenu du site Web, accords de confidentialité, marques déposées, etc. Pour ne pas faire les choses à moitié, tous ces documents devraient être modifiés en catimini à peu près tous les deux mois.

6. Choisissez avec soin l’agent de liaison avec la communauté

Votre meilleur candidat : quelqu’un de solitaire, quelqu’un qui n’a pas d’amis et qui n’apprécie pas vraiment les autres. Si vous n’en avez pas sous la main, prenez le membre de votre équipe qui a le plus de travail, quelqu’un avec des responsabilités en développement et en gestion, et qui travaille déjà au minimum 70 heures par semaine. Dans ce cas, il est primordial de ne pas le décharger de la moindre de ses responsabilités.

Quelqu’un qui ne maîtrise pas la technologie fera aussi l’affaire. Prenez un spécialiste de Java pour assurer la liaison dans un projet en Perl. Ou, si vraiment ces solutions ne sont pas possibles, laissez simplement la place vacante pendant des mois.

7. Rendez opaques les prises de décision

Les entreprises réfractaires aux communautés devraient, d’après Josh, s’inspirer des Nations Unies et créer des processus longs et complexes. Personne ne doit savoir qui prend réellement les décisions, c’est très bon pour transformer les contributeurs en éléments nocifs. Il va de soi que les règles devraient être immuables ou presque.

8. Faites n’importe quoi avec les licences

Les membres de la communauté étant souvent à cheval sur la question des licences, modifiez la licence et vous avez de bonnes chances de les faire fuir. Évoquer des changements de licence sans jamais vraiment rien modifier peut se révéler encore plus efficace : vous faites fuir les contributeurs actuels qui apprécient la licence choisie sans pour autant en attirer d’autres, adeptes eux de la future licence supposée.

9. N’accordez jamais, au grand jamais, l’accès au commit à quelqu’un d’extérieur à l’entreprise

Ce devrait être une règle (tacite évidemment) : seuls les employés peuvent avoir les droits de commit (NdT : avoir ces droits revient à avoir accès et contrôle sur le code source du dépôt officiel du logiciel). Vos réponses doivent être évasives, « problèmes légaux, on y travaille » est une bonne carte à jouer. Afin que cette mesure prenne tout son effet, choisissez un employé qui n’écrit pas de code et confiez lui l’accès au commit sur le projet.

10. Réfugiez-vous dans le silence

Laissez les questions sans réponse, ne dites rien. Maîtriser cette technique peut rendre, à elle seule, toutes les autres inutiles. C’est le meilleur moyen de détruire une communauté qui existe.

En conclusion, Josh ajoute que grâce à Sun, il peut témoigner de l’efficacité de toutes ces techniques. Mais Sun est loin d’être la seule entreprise dans cette situation. Un ancien du X Consortium a avoué à Josh qu’eux aussi avaient un jour recouru à chacune de ces méthodes. Ces compétences de destruction de communauté sont monnaie courante dans l’industrie du logiciel.

Mais que faire si votre entreprise veut au contraire se bâtir une communauté ?

Il paraît évident qu’elle devrait alors s’employer à appliquer à l’inverse les méthodes énumérées ci-dessus. Mais d’après Josh, la clé de voûte du système reste la confiance. À l’instar du mariage, développer une communauté peut prendre des années, mais une seule infidélité détruira la confiance qui en constitue le socle. Ainsi, une entreprise peut perdre la moitié de sa communauté en un week-end. Pour ne pas connaître ce triste sort, il faut avoir confiance en la communauté et agir de sorte que cette confiance soit réciproque.