Hier soir je suis tombé sur un article conseil en anglais de la FSFE qui déclinait quelques bonnes et mauvaises pratiques si vous voulez faire connaître le logiciel libre autour de vous (et tout le bien que vous en pensez).

Pour ne pas surcharger la barque Framalang (qui doit tanguer quelque part entre les Seychelles et les Maldives), j’ai choisi de m’adresser à d’autres esclaves bonnes volontés du Libre. Ceux de l’émérite site LinuxFr qui présente la particularité d’abriter en son sein des êtres prêts à tous les sacrifices pour faire avancer La Cause.

Et hop, un rapide journal bien senti avec un Framapad inside, et le tour est joué.

Suffit d’attendre et de ne pas oublier de bien saluer tous ceux qui franchissent le pad (par contre j’avais oublié la bière, désolé).

Et c’est ainsi qu’en plein samedi soir du mois d’août, nous traduisîmes en à peine trois heures et à plusieurs mains (une bonne petite vingtaine, soit, si vous me suivez, dix personnes) ce court exposé plein de bon sens (à la limite de l’enfonçage de portes ouvertes ?) qui devrait, à n’en pas douter, faire au moins doubler le taux de convertis dès la rentrée prochaine.

Ça a bossé dur et vite en tout cas, rien que pour le titre, on a eu les propositions suivantes : « De la communication efficace du logiciel libre », « Plaidoyer efficace pour le logiciel libre »^[1], « De l’évangélisation efficace du logiciel libre », « Défense efficace du logiciel libre », pour finalement retenir « Promouvoir efficacement le logiciel libre ».

Plus sérieusement, grand merci à mes (éphémères) compagnons de route (longue mais libre) pour ce traducthon improvisé. Je reste, comme au premier jour, fasciné par tout ce que l’on peut réaliser ensemble, de GNU/Linux à cette toute modeste traduction plurielle.

Promouvoir efficacement le logiciel libre

Effective Free Software advocacy

Sam Tuke – 10 août 2011 – FSFE
(Traduction collective LinuxFr : NeoX, mansuetus, Roro7302, Jeece, eastwind, crabs, fiuzzy, oktail, qdii et quelques autres anonymous)

Expliquer ce qu’est le logiciel libre est une tâche importante mais parfois délicate et difficile. Des concepts et une terminologie complexes, de subtiles variantes et un contexte social, politique et économique particulier, peuvent nous éloigner d’une communication efficace. Ces quelques lignes ont pour but de vous aider à présenter vos propos pour qu’ils soient à la fois plus clairs, cohérents et convaincants.

1) À faire : Dès qu’une occasion se présente, parler ouvertement et régulièrement du logiciel libre avec vos amis et vos proches.

1) À éviter : Critiquer les autres pour leur désintérêt ou leur manque de compréhension du logiciel libre. Essayez plutôt d’écouter ceux qui ne sont pas d’accord avec vous en n’essayant pas de les forcer à adopter votre point de vue. Le logiciel libre est un sujet intrinsèquement important. Mais si une personne en particulier ne peut en appréhender sa valeur, alors n’insistez pas et attendez de trouver quelqu’un d’autre qui sera prêt à poursuivre la discussion avec vous.

2) À faire : Présenter, de manière constructive, des exemples réels de problèmes posés par les logiciels propriétaires. Faire allusion au vendeur peut être tout aussi efficace que de mentionner le nom d’une entreprise.

2) À éviter : Focaliser sa critique du logiciel propriétaire sur une seule et unique entreprise. Si vous avez besoin de nommer une entreprise, essayez d’en citer d’autres. Les problèmes liés aux logiciels non libres sont génériques. Partir d’une situation globale affectant une pratique ou un marché donnera plus de poids à vos arguments et évitera les partis pris.

3) À faire : Citer les faits et les sources à chaque fois que cela est possible et être clair sur la provenance des informations. Si vous ne pouvez pas vous souvenir immédiatement de la référence, pensez à la transmettre plus tard par courrier électronique.

3) À éviter : Baser votre argumentation sur des informations non ou mal sourcées. Tenez-vous-en aux faits, et laissez les hypothèses de travail, les généralités et les suppositions pour les rares occasions où elles pourront être vraiment utiles.

4) À faire : Choisir avec soin vos arguments selon votre propre niveau de compréhension et celui de votre auditoire. Restez concentré sur les sujets que vous maîtrisez, ceux pour lesquels vous avez une expérience personnelle (même modeste) et dans lesquels vos auditeurs seront susceptibles de se reconnaître.

4) À éviter : Ennuyer ou irriter un auditoire inadapté et non préparé à un discours par trop technique ou philosophique. Vous êtes naturellement motivé pour parler en long et en large de vos sujets ou concepts favoris, mais rappelez-vous que si le but est de communiquer sur le logiciel libre, alors il vous faut déterminer au préalable l’interêt et le niveau technique de votre auditoire et adapter votre discours en conséquence.

5) À faire : Faire preuve de patience, de calme, de raison et d’objectivité dans votre communication. Évitez les situations de crises et sinon tentez de les désamorçer.

5) À éviter : Être pressant, aggressif ou trop impliqué personnellement dans vos propos. Vous n’avez rien à prouver et le logiciel libre continuera à vivre quel que soit l’avis d’un individu ou d’un groupe. Soyez simplement constructif dans vos propositions.

6) À faire : Rencontrer et discuter avec des personnes potentiellement intéressées par le logiciel libre. Sollicitez ces contacts et veillez à vous montrer disponible pour répondre à leurs demandes.

6) À éviter : Passer votre temps à contacter des personnes qui ont clairement manifesté leur désintérêt pour le sujet. Vous seriez plus utile en d’autres lieux.

7) À faire : Effectuer des démonstrations de logiciels libres de qualité, en particulier si vous les utilisez vous-même. Voir c’est retenir, et montrer comment vous tirez profit des logiciels libres au quotidien peut être plus percutant que n’importe quel argument idéologique.

7) À éviter : Promettre ou insinuer des choses que les logiciels libres ne peuvent pas apporter. Vous pouvez faire énormément de choses avec des logiciels libres, mais vous ne pouvez pas tout faire, et prétendre le contraire ne ferait que nourrir des attentes et mènerait à la frustation et la déception.

8) À faire : Trouver des moyens d’inviter les nouveaux venus à rencontrer d’autres partisans du logiciel libre et à assister à des évènements organisés par des groupes d’utilisateurs locaux. Essayez de réunir des personnes ayant des centres d’intérêts communs est également un terreau favorable pour les nouveaux arrivants dans le monde du logiciel libre.

8) À éviter : Espérer que chaque personne croisée souhaite adhérer et participer à vos groupes d’utilisateurs de logiciels libres (LUG) ou à votre hackerspace. La plupart des gens ne se déplacent à une manifestation, une rencontre, que si cela correspond à leurs centres d’intérêts et leur niveau de compréhension. Seuls certains de vos contacts sont prêts à accorder une partie de leur temps libre à ce genre d’évènement . Lorsque c’est le cas, n’oubliez pas de rester accueillant et patient.

À l’occasion de la sortie de Google Plus, on a beaucoup évoqué la question de l’identité numérique via le choix, imposé ou non, du pseudo ou du vrai nom (lire par exemple l’article d’Owni Google Plus, la dictature des vrais noms).

Dans l’article ci-dessous, traduit par Clochix^[1], l’influente Danah Boyd nous rappelle l’impact, souvent non prévisibles, des normes sociales dans la direction et les usages d’une plateforme Web communautaire telle qu’un réseau social^[2].

Elle affirme ainsi : « Les normes sociales ne font pas partie du logiciel. Elles n’apparaissent pas en expliquant aux gens comment ils doivent se comporter. Les normes sociales apparaissent lorsque les utilisateurs comprennent comment une technologie a du sens et s’intègre dans leur vie. Les normes sociales se renforcent à mesure que les gens intègrent leur propres valeurs et croyances dans le système. »

Certes oui, sauf peut-être lorsque le logiciel est un logiciel libre car alors on peut émettre l’hypothèse qu’un certain nombre de normes sociales, positives et directement induites par la licence libre, feront d’emblée leur apparition. Ce qui pourrait faire l’objet d’un débat dans les commentaires et justifier la présence de cet article sur le Framablog 🙂

Concevoir en respectant les normes sociales, ou comment ne pas créer de foules en colère

Designing for Social Norms (or How Not to Create Angry Mobs)

Danah Boyd – 5 aout 2011 – Apophenia
(Traduction Framalang : Clochix)

Dans son livre de référence « Code », Larry Lessig soutient que les systèmes sociaux sont régis par quatre forces : le marché, la loi, les normes sociales et l’architecture ou le code. En réfléchissant aux médias sociaux, beaucoup de gens ne pensent qu’en terme de monétisation. De même, lorsqu’apparaissent des problématiques comme la vie privée, on voit régulièrement entrer en scène une régulation légale. Et naturellement, les gens pensent toujours à ce que le code permet ou non de faire. Mais je trouve déprimant que si peu de gens pensent au pouvoir des normes sociales. En fait, on ne pense souvent au pouvoir régulateur des normes sociales que lorsque les choses tournent vraiment mal. Et à ce moment, elles sont souvent hors de contrôle, réactionnaires et confuses pour tout le monde. On a vu cela avec les problèmes de vie privée et on le voit encore avec les débats sur les politiques en matière d’utilisation de son « vrai nom ». Au fur et à mesure que je lis la discussion que j’ai provoquée sur ce sujet, je ne peux m’empêcher de penser que nous avons besoin d’un échange plus critique sur l’importance de concevoir en ayant en tête les normes sociales.

Les bons concepteurs d’interface utilisateur savent qu’ils ont le pouvoir d’influencer certaines pratiques sociales par la façon dont ils conçoivent les systèmes. Et les ingénieurs oublient souvent de créditer les gens qui font l’interface pour leur important travail. Mais concevoir le logiciel lui-même n’est qu’une fraction du défi en matière de conception lorsque l’on pense à toutes les implications. Les normes sociales ne font pas partie du logiciel. Elles n’apparaissent pas en expliquant aux gens comment ils doivent se comporter. Et elles ne suivent pas forcément les logiques du marché. Les normes sociales apparaissent lorsque les gens — devrait-on dire les utilisateurs — comprennent comment une technologie a du sens et s’intègre dans leur vie. Les normes sociales se renforcent à mesure que les gens intègrent leur propres valeurs et croyances dans le système et aident à structurer comment les utilisateurs suivant le comprendront. Et de même qu’en matière d’interactions sociales, « la première impression compte », je ne peux pas sous-estimer l’importance des utilisateurs précoces. Ils façonnent la technologie sur des points critiques et jouent un rôle central dans l’édification des normes qui régissent un système.

La façon dont est lancé un nouveau média social a une importance critique. Votre compréhension d’un système en réseau sera largement influencée par les gens qui vous y ont introduit. Lorsqu’un logiciel se répand lentement, les normes ont le temps de bien cuire, les gens peuvent travailler à ce qu’elles devraient être. Mais lorsqu’il se développe rapidement, il y a beaucoup plus de chaos en matière de normes sociales. À chaque fois qu’un nouveau système apparaît, il y a inévitablement plusieurs normes en compétition, promues par des gens déconnectés les uns des autres. (Je ne peux vous dire combien j’aimais regarder Friendster lorsque les gays, les participants au festival Burning man et les blogueurs n’étaient pas conscients de l’existence des autres). Plus les choses vont vite, plus rapidement ces collisions arrivent et plus il y a de confusion sur les normes à adopter.

La culture de l’utilisation de son « vrai nom » sur Facebook ne s’est pas répandue à cause des conditions d’utilisation. Elle s’est développée parce que les normes ont été fixées par les premiers utilisateurs du service, que les gens l’ont vu et s’y sont adaptés. De même, la culture des pseudonymes s’est développée parce que les gens ont vu que c’est ce que faisaient les autres et ont reproduit cette norme. Lorsque les dynamiques sociales sont autorisées à se développer de façon organique, les normes sociales ont un pouvoir de régulation plus puissant que n’importe quelles règles d’utilisation formalisées. À ce moment, vous pouvez souvent formaliser la norme dominante sans rencontrer trop de résistance, surtout si vous laissez une marge de manœuvre. Mais lorsque vous commencez avec une politique de régulation sévère qui ne s’inspire pas de normes sociales — comme l’a fait Google Plus — la résistance sera forte.

Pensons à nouveau un instant à Friendster… Vous vous souvenez de Fakester ? J’ai écrit à leur sujet ici (NdT: les faux profils, notamment de célébrités). Friendster a perdu un temps fou à jouer au jeu de la taupe avec eux, supprimant les « faux » comptes et en s’en prenant à quelques-uns des plus influents de ses utilisateurs. Le « génocide de Fakester » a amené un nombre impressionnant de gens à quitter Friendster pour rejoindre MySpace, notamment des groupes de musique, parce qu’ils ne voulaient pas être façonnés par Friendster. Le concept de Fakester est mort sur MySpace, mais sa pratique principale — la possibilité pour des groupes d’avoir des représentations reconnaissables — a fini par devenir la principale fonctionnalité de MySpace.

Les gens n’aiment pas être façonnés. Ils n’aiment pas qu’on leur impose la façon d’utiliser un service. Ils ne veulent pas qu’on leur dise de se comporter comme ses concepteurs attendent qu’ils le fassent. Les conditions d’utilisation strictes ne créent pas de bon comportements, elles génèrent des utilisateurs énervés.

Ça ne signifie pas que vous ne pouvez pas ou ne devriez pas concevoir votre produit pour encourager certains comportements. Naturellement vous devriez. Tous l’art de la conception est de créer un environnement où les gens s’investissent de la manière la plus fructueuse et la plus saine possible. Mais concevoir un système pour encourager le développement de normes sociales saines et fondamentalement différent d’arriver et de dire brutalement aux gens comment ils devraient se comporter. Personne n’aime recevoir de fessée, et surtout pas une foule d’adultes obstinés.

De manière ironique, la plupart des gens qui ont adopté Google Plus parmi les premiers utilisaient leur vrai nom, par habitude, ou parce qu’ils pensaient que c’est ainsi que le système devrait fonctionner. Quelques uns ne le faisaient pas. La plupart de ceux-ci utilisaient un pseudonyme reconnaissable, ils n’essayaient même pas de duper quiconque. Leur faire la chasse était juste complètement stupide. C’était faire étalage de sa force, et les gens se sont sentis désemparés. Ils sont devenus furieux. Et à ce moment là, il ne s’agit même plus de savoir si la politique du « vrai nom » était initialement une bonne idée; à présent, c’est un acte d’oppression. Google Plus aurait été dix bazillions de fois meilleur s’ils avaient encouragé discrètement cette politique sans en faire un plat, s’ils avaient choisi de ne la suivre strictement que dans les cas les plus flagrants. Mais à présent ils sont coincés entre le marteau et l’enclume. Ils doivent soit continuer dans cette voie et gérer les foules en colère, ou laisser tomber en signe d’apaisement dans l’espoir que la colère se calme. Il n’aurait pas dû en être ainsi, et ça ne l’aurait pas été s’ils avaient pensé à encourager les pratiques qu’ils voulaient davantage par la conception que par la force.

Il y a bien sûr des raisons légitimes de vouloir encourager les comportements civiques en ligne. Et naturellement les trolls font de sérieux dommages sur un média social. Mais une politique d’usage du « vrai nom » n’arrête pas un troll non repenti ; ce n’est qu’une haie de plus qu’il s’amusera à franchir. Dans mes travaux avec des adolescents, je rencontre tous les jours des cas de harcèlement écrit entre des gens qui savent exactement qui est qui sur Facebook. L’identité de nombreux trolls est connue. Mais ça ne résout pas le problème. Ce qui compte c’est comment la situation sociale est façonnée, les normes sur ce qui est approprié et ne l’est pas, et les mécanisme de régulation à la disposition de chacun (en faisant honte publiquement ou via une intervention technique). Une culture où les gens peuvent bâtir leur réputation sur leur présence en ligne (que ce soit avec leur « vrai » nom ou avec leur pseudonyme) a un long combat à mener contre les trolls (bien que ça ne soit en aucun cas une solution infaillible). Mais cette culture ne s’obtient pas par la force; vous y arrivez en encourageant l’apparition de normes sociales saines.

Les entreprises qui créent des logiciels que les gens utilisent ont du pouvoir. Mais elles doivent être très très prudentes dans la façon dont elles affirment cette autorité. C’est très simple d’arriver et d’essayer de façonner l’utilisateur de force. C’est beaucoup plus dur de travailler assidûment à concevoir et créer l’écosystème dans lequel des normes saine émergeront. Pourtant, ce dernier point est d’une importance capitale pour la constitution de communautés en bonne santé. Parce que vous ne pouvez pas obtenir une communauté vivace par la force.

Pour un débutant participer au logiciel libre peut être si intimidant qu’on n’hésite pas à évoquer « un aquarium à requins » pour qualifier la communauté !

Un blogueur explique pourquoi il ne contribue pas au logiciel libre (alors qu’au fond de lui il le souhaite sincèrement). Un autre lui répond, en théorie mais aussi en pratique en s’appuyant sur GitHub (qui a le vent en poupe actuellement chez les développeurs). Telle est la petite passe d’armes que nous vous proposons traduite ci-dessous^[1].

En ce qui nous concerne, c’est aussi pour cela que l’on a publié notre framabook Produire du logiciel libre. Afin de participer à ce qu’il y ait de plus en plus de développeurs francophones, notamment parmi les plus jeunes qui ne reçoivent pour le moment aucune sensibilisation ou formation pendant leur cursus scolaire.

Pourquoi je ne contribue toujours pas à l’open source

Why I still don’t contribute to open source

The Daily Flux – 3 mai 2011 – Brandonhays.com
(Traduction Framalang : Pandark)

Je suis tellement hypocrite. Il y a quelques mois, je me demandais dans un billet comment surmonter ma peur de contribuer aux logiciels open source ?¹?.

Depuis, je n’ai toujours pas vraiment participé. Sur Twitter, j’ai écrit que les FOSS ressemblent à un aquarium de requins pour les newbies, et il faut que je le confirme.

Le fait est que je contribue activement d’une manière ou d’une autre à plusieurs projets open source. Cependant, je me sens toujours extérieur au projet, car mes contributions ne sont généralement pas liées au code. Alors pourquoi est-que je ne m’implique pas complètement dans le FOSS (et je pense, beaucoup d’autres comme moi) ?

Au risque de prêter aux autres mon ressenti personnel, j’aimerais vous faire part des obstacles qui peuvent, selon moi, intimider les nouveaux devs qui voudraient contribuer à des logiciels open source.

Il n’y a pas de certification, de cérémonie ou de badge du mérite disant « Tu es prêt à contribuer au FOSS ». (Il y en a cependant un pour après)

Il n’est pas évident de savoir par où commencer. D’après ce que j’entends, beaucoup de contributions aux FOSS surviennent parce que quelqu’un a besoin d’une fonctionnalité qui n’existe pas dans un logiciel, ou trouve un bug. Il peut proposer une procédure de test reproductible, voire un patch. Dans mon utilisation quotidienne, je ne croise pas beaucoup de ces situations. Il n’y a pas beaucoup de devs qui agitent les bras en demandant spécifiquement de l’aide sur un projet, et encore moins qui voudraient prendre un nouveau développeur sous leur aile.

Les règles de participation (guidelines) rendent souvent la vie d’un mainteneur plus facile, et compliquent la mienne. Oui, maintenir un projet open source est une tâche ardue et ingrate. Cependant, j’ai vu des règles/lignes de conduite pour contribuer qui transformaient une simple idée de correction en un mur de brique bureaucratique digne de Microsoft. La page d’accueil aux contributions accompagnée d’un tutoriel vidéo de Wayne Seguin est une exception remarquable à cela.

L’open source est pour les gens qui sont meilleurs que moi. J’ai bien conscience que c’est une excuse pour ne pas me lancer, mais je ne suis simplement pas à l’aise de me retrouver à un endroit où je pourrais publier des logiciels suffisamment bons pour que de véritables développeurs les utilisent.

Essayer de contribuer et échouer me donne le sentiment d’être stupide. J’ai déjà soumis plusieurs requêtes de pull et aucune n’a été acceptée, sans commentaire expliquant pourquoi. C’est comme si l’univers confirmait que oui, je suis un idiot, et mon « aide » n’est pas utile. Quelle perte de temps profondément déprimante !

J’ai pas le temps. J’ai des enfants, un nouveau boulot, et un nombre grandissant de responsabilités. Cela me prend entre 3 et 10 fois plus de temps pour écrire du code qu’un développeur plus expérimenté. Maintenant, mes contributions non liées au code mangent le temps que je passais à coder. Oui, tout le monde a la même excuse, du genre qui se dissipe si les autres excuses disparaissent, mais ça vaut le coup de le mentionner.

C’est une activité solitaire. Je pense que la plupart des gens comprennent ces choses par eux-même, et que ce serait donc un peu trop demander que d’attendre d’être pris par la main. Mais est-ce vraiment une démarche spirituelle où personne ne peut vous accompagner, de crainte que vous n’appreniez rien ?

Donc oui, le FOSS peut sembler intimidant, voire autant qu’un aquarium de requins. Je n’ai pas toutes les réponses à ces problèmes, mais je voudrais voir plus de mainteneurs cherchant des contributions avec une certaine spécificité, et répondant ensuite aux requêtes de pull, un appel pour des cas de tests supplémentaires, des corrections de bugs et, oui, de la documentation.

Github a beau être on ne peut plus ouvert, il n’y a pas de système type Quora/StackExchange qui permette de savoir quel projets ont besoin de quelque chose qui correspond à ce que vous pouvez faire. Ça pourrait être une bonne fonctionnalité.

Toi (oui, toi !), tu devrais contribuer à l’open source

You (yes, you!) should contribute to open source

Steve Klabnik – 10 mai 2011 – TheChangelog.com
(Traduction Framalang : Pandark)

Si vous lisez ce blog, vous vous souciez évidemment de l’open source. Si vous n’avez jamais contribué à un projet open source, cependant, vous êtes peut-être frileux à ce propos. Donc, inspiré par le concours de documentation Ruby 1.9.3, j’ai écrit un billet pour mon blog à propos de la manière de contribuer à la documentation de Ruby. J’ai reçu des retours comme celui-ci :

@steveklabnik Hé, c’est génial. Il est temps pour moi de m’engager et de me mettre au boulot. Merci pour la motivation supplémentaire !

Je me suis donc dit que quelque chose de plus général pourrait vous encourager à vous impliquer dans n’importe lequel des projets open source que vous utilisez, même si ce n’est pas en Ruby. Tout projet peut avoir besoin d’un coup de main supplémentaire, en particulier les petits.

Un petit aparté à propos du fait d’être frileux.

Si vous ne contribuez pas parce que vous pensez que vous n’êtes pas prêt, ne vous inquiétez pas pour ça ! Je sais que c’est plus facile à dire qu’à faire, mais vraiment, vous êtes prêt. Un de mes amis a publié un article à propos des raisons pour lesquelles il ne contribue pas, et je suis sûr que beaucoup de personnes partagent ce genre de peurs. Greg Brown a répondu et a dissipé certaines de ses inquiétudes, mais la plupart des gens auxquels j’ai parlé s’y refusent principalement pour deux raisons :

• C’est trop dur
• Je ne suis pas assez bon pour contribuer
• Je n’ai pas le temps

Parlons de chacun de ces points dans l’ordre inverse. C’est vrai, vous pouvez avoir une vie remplie. Je ne connais pas votre emploi du temps personnel. Cependant, je suis sûr que vous pouvez trouver une heure ou deux, peut-être un week-end ? Il n’en faut pas plus pour commencer. La plupart des projets sont construits sur la base de milliers de minuscules commits. Vous n’avez pas besoin de faire une grosse contribution, même les petites sont importantes.

Si vous avez peur que la qualité de votre code ne soit pas suffisante, eh bien la seule manière de vous améliorer est de pratiquer. Alors lancez-moi cet éditeur et soumettez un patch ! En général, si quelque chose ne va pas dans votre soumission, il y aura une discussion à son propos sur GitHub et tout le monde peut y apprendre quelque chose.

Prenez cette demande de pull, par exemple. À l’origine, Colin a soumis un patch qui faisait un lien vers la mauvaise url ; wilkie l’a mentionné, et Colin a mis le code à jour. Cela sera intégré dès que j’aurai fini d’écrire ce billet pour The Changelog. 🙂 Mais c’est généralement ce qui arrive si votre première proposition est un peu inexacte. N’ayez pas peur ! C’est comme ça que l’on a tous appris, les uns des autres.

Cette lamentation « c’est trop dur » débouche souvent sur un « je ne suis pas assez bon ». Cela peut aussi arriver si vous essayez de contribuer à un gros projet ayant beaucoup de règles. Les lignes de conduite pour contribuer, obligation de relecture du code, mise à jour des fichiers AUTHORS et CHANGELOG… les gros projets doivent avoir des procédures pour gérer le grand nombre de contributeurs, mais cela peut certainement créer une barrière à l’entrée pour les nouveaux venus. Si ces procédures vous intimident, j’ai une suggestion : commencez petit ! Les petits projets ont généralement peu, voire pas du tout de procédure. De plus, vous vous sentirez incroyablement bien. Pensez à ça : Python reçoit un tas de patchs tous les jours, mais si vous avez un petit outil que vous avez écrit sur GitHub, et que soudainement vous recevez un courriel « Hé, quelqu’un a un patch pour vous, » je parie que vous en serez rudement content.

Le B.A BA

Lorsque l’on contribue à un projet open source sur GitHub, il y a un processus que presque tous les projets suivent. Trois étapes : fork, commit, demande de pull.

GitHub rend l’étape du fork très simple. Cliquez simplement sur le bouton « fork » trouvé sur la page de n’importe quel projet. Utilisons Ruby comme exemple. La page du projet est ici. Vous pouvez voir le bouton fork en haut à droite. Il ressemble à ceci :

Cliquez dessus, et vous verrez certaines « hardcore forking action, » puis vous serez dans votre propre fork ! C’est votre propre version du projet, et elle apparait sur votre page GitHub. Par exemple, voici mon fork de Ruby. Vous verrez une URL sur la page, qui vous permettra de cloner ce projet lui-même.

$ git clone git@github.com:steveklabnik/ruby.git

Cela crée un répertoire « ruby » avec tout le code à l’intérieur. Ensuite, ajouter un lien vers le projet parent pour pouvoir suivre les modifications qu’il fait.

$ cd ruby
$ git remote add upstream https://github.com/ruby/ruby.git
$ git fetch upstream

À partir de maintenant, à n’importe quel moment, nous pouvons récupérer les modifications du dépôt Ruby principal en faisant un rebase :

$ git rebase upstream/master

Une petite remarque : ruby continue d’utiliser à la fois svn subversion et git, ils appellent donc leur branche maîtresse trunk. Si vous faites cela pour Ruby, vous devrez faire git rebase upstream/trunk. Maintenant que vous avez cloné, vous pouvez faire votre boulot ! J’aime travailler dans des branches par fonctionnalités, parce que cela rend les choses plus propres et jolies, et que je peux travailler sur deux fonctionnalités à la fois.

$ git checkout -b feature/super-cool-feature
$ vim something
$ git add something
$ git commit -m "Fixed something in something"

Une fois que vous avez obtenu des commits qui fixent votre problème, envoyez les (faites un push) sur GitHub :

$ git push origin feature/super-cool-feature

Ensuite, vous cliquez sur le bouton pull request :

Choisissez votre branche, modifiez la description comme vous le souhaitez, et vous êtes prêt à vous lancer ! Le mainteneur du projet y jettera un coup d’œil et vous aurez peut-être droit à une discussion, et bientôt vous aurez quelque chose accepté quelque part !

À quoi devrais-je contribuer ?

Le meilleur moyen de contribuer est d’aider un projet que vous utilisez effectivement. De cette manière, vous arriverez à tirer profit du fruit de votre labeur. Vous serez plus motivé, vous comprendrez déjà le projet et ce qu’il fait, ce qui vous rendra tout ça plus facile.

Si vous ne voulez pas ou ne pouvez pas trouver comment fonctionne quelque chose que vous utilisez, le deuxième meilleur moyen est de commencer à utiliser de nouveaux logiciels ! Continuez à lire The Changelog et choisissez un projet qui a l’air intéressant, utilisez le quelques semaines, puis contribuez !

Nous sommes tous dans le même bateau

J’espère que ceci vous encouragera à vous salir les mains, vous retrousser les manches, et contribuer. Même le plus petit des patchs est important, alors s’il vous plaît, trouvez un moment dans votre emploi du temps, choisissez un projet et faites un essai. Mais attention, vous pourriez vite vous retrouver accro !

Certains résistent encore mais nombreux sont les visiteurs (et rédacteurs) de ce site à posséder un compte de messagerie Google Gmail.

Il faut dire que, techniquement parlant, c’est une excellente application en ligne^[1].

Mais il ne faut pas oublier de dire aussi que, techniquement parlant, l’application est propulsée par du code JavaScript qui est malheureusement non libre, avec toutes les conséquences (néfastes) que cela implique.

Or puisqu’il existe une version simplifiée de Gmail, épurée de ce code, cela signifie d’abord que l’on peut s’en passer et ensuite que cette surcouche pourrait fort bien devenir libre.

C’est la proposition de la Free Software Foundation qui nous invite à faire pression sur Google pour qu’il accepte ce pas dans la bonne direction.

Évitons les pièges du JavaScript de Gmail

Avoid the pitfalls of the JavaScript Trap on Gmail

Matt Lee – 30 mars 2011 – FSF.org
(Traduction Framalang : Goofy et Penguin)

Nous lançons aujourd’hui la première phase d’une série d’opérations à mener pour utiliser les sites Web les plus populaires sans leur code JavaScript propriétaire.

Vous n’êtes peut-être pas conscient des dangers du JavaScript, un problème que nous avons intitulé le piège JavaScript, lorsque du logiciel propriétaire est exécuté dans le navigateur de votre ordinateur.

Nous concentrerons notre première opération sur le service Gmail de Google.

Le piège JavaScript

Lorsque vous visitez un site Web comme Gmail, votre navigateur va télécharger et exécuter plusieurs milliers de lignes de code JavaScript. Le code JavaScript n’est pas différent de langages comme Pyhon, C++ ou Ruby (les applications qui sont exécutées sur nos ordinateurs et qui sont écrites dans ces langages doivent être des logiciels libres, afin que nous puissions les exécuter, les modifier et les partager si nous en avons envie). Le JavaScript d’aujourd’hui n’est plus le JavaScript d’autrefois, il est désormais utilisé pour écrire de puissantes applications côté serveur grâce à des logiciels libres comme Node.js et le moteur JavaScript V8.

De plus, nous avons vu récemment des entreprises comme Research In Motion (les fabricants du BlackBerry) recommander à leurs clients de désactiver complètement le JavaScript du navigateur WebKit de leurs téléphones à cause de la découverte d’un problème de sécurité. Même si les logiciels libres qui intègrent du JavaScript peuvent également avoir des problèmes de sécurité, cet exemple illustre le fait que nous avons un réel besoin d’avoir accès au code qui s’exécute sur nos ordinateurs, et de pouvoir le modifier.

Ce que JavaScript pourrait faire

Il est évident que le JavaScript est une technologie très puissante et très utile lorsqu’elle se trouve entre de bonnes mains. De nombreux développeurs de logiciels libres ont ainsi écrits des extensions et des améliorations pour des sites populaires grâce à des outils comme GreaseMonkey. Il existe une flopée de scripts Greasemonkey libres pour Gmail. L’existence de tels scripts montre à la fois que le JavaScript de Gmail n’est pas trivial, mais également que des utilisateurs pourraient faire des contributions intéressantes et utiles si le code JavaScript était publié en tant que logiciel libre pour leur permettre de le modifier.

Par ailleurs, des sites comme Gmail, Twitter et Facebook utilisent beaucoup trop de JavaScript pour proposer leurs services. La preuve en est que les mêmes services en version mobile proposent pratiquement les mêmes fonctionnalités sans JavaScript. Là où la nécessité du JavaScript se fait sentir il peut être publié en tant que logiciel libre, et là où ces raffinements supplémentaires sont facultatifs, on peut fournir une version basique du site qui n’a pas besoin de JavaScript.

Google a fait un premier pas vers cet objectif en développant une version du site Gmail en « Version HTML simplifiée », qui ne dépend donc pas d’un copieux code JavaScript pour proposer une interface utilisateur. Google propose également les protocoles IMAP et POP qui permettent d’accéder aux comptes Gmail sans passer du tout par la case site Web. Ces initiatives constituent toutes deux des avancées positives vers un idéal plus vaste.

Notre requête à Google : une étape de plus dans la bonne direction

Si vous utilisez Gmail, demandez gentiment mais fermement à Google d’être « logiciel libre friendly » en publiant le code JavaScript de Gmail sous une licence libre. En acceptant de le faire, Google permettrait aux utilisateurs qui accordent de l’importance aux libertés logicielles d’utiliser Gmail dans une version avancée, et de proposer des contributions et modifications utiles à tout le monde.

Nous serions ravis de recevoir vos réactions et suggestions, ainsi que les démarches que vous proposez pour les sites les plus connus. Vous pouvez dès maintenant ajouter vos idées et contributions sur le wiki de LibrePlanet.

Fabrice Epelboin nous révèle aujourd’hui que ReadWriteWeb met fin à ses éditions européennes, avec toutes les questions que cela pose quant au devenir et aux archives de la version française de RWW.

C’est le risque lorsque l’on dépend d’une maison mère américaine et que les articles n’ont jamais eu l’honneur d’une licence Creative Commons (sauf justement ce dernier billet où Epelboin à décidé de s’affranchir de la tutelle dans un dernier baroud d’honneur).

Notez bien que pareille mésaventure peut arriver à tous ceux qui placent du contenu sur Facebook, Twitter ou Google (autant dire à tous le monde). Puisque en vous inscrivant à ces services vous adhérez à des conditions dont il est bien stipulé qu’elles peuvent changer à tout moment si le propriétaire en décide ainsi. Par exemple si les actionnaires de ces sociétés décident d’en modifier le modèle économique CQFD.

Merci au passage à Fabrice Epelboin^[1] et à RWW France pour la pertinence et la pugnacité de leurs informations, reportages et analyses (cf l’excellente compilation Chroniques de l’Infowar 2010 De l’Hadopi à Wikileaks à conserver au cas où). Nous n’étions pas de trop pour tenter d’apporter un autre son de cloche face à des institutions publiques et privées qui ont la fâcheuse tendance à prendre le Net et les nouvelles technologies par le mauvais bout de la lorgnette.

Mais ce qui m’a le plus marqué c’est la conclusion du billet. Un peu comme si l’auteur s’était lâché en livrant véritablement le fond de sa pensée. Et cette pensée est d’autant plus pro-fonde que le gus sait de quoi il parle :

« Les temps qui viennent en France sont terrifiants pour internet et les libertés numériques. Du point de vue des lois qui s’y appliquent, nous ne sommes plus, sur l’internet Français, dans une démocratie.

Avec quelques gus dans un garage, nous avons réussi a sensibiliser pas mal de monde à ce problème, mais force est de reconnaître que nous avons, au mieux, mis des bâtons dans les roues d’un char d’assaut qui écrase toutes les velléités de liberté sur internet, et veut le civiliser comme il a colonisé hier ceux qu’il qualifiait de sauvages.

Un autre monde est possible, mais en France, ça va prendre du temps. Une fois de plus, le pays va prendre un retard considérable en matière de numérique, au point que sa place dans le monde de demain est désormais totalement compromise, mais ça, même sans comprendre quoi que ce soit à la neutralité du net ou aux enjeux sociétaux d’Hadopi et de Loppsi, vous avez du vous en apercevoir. »

Aux dernières nouvelles Fabrice Epelboin s’en irait rouler sa bosse en Tunisie. Parce qu’il souhaite désormais « construire avec » et non plus « lutter contre ».

Il reste une place dans l’avion ?

« Apple c’est un peu le Disneyland des nouvelles technologies… »

Aussi étrange que cela puisse sembler j’ai fait une très brève apparition ce matin sur les ondes de France Culture pour évoquer non pas le logiciel libre mais… Apple !

Le journaliste avait à peine trois minutes pour réaliser un sujet d’actualité sur la première Assemblée générale de la société sans Steve Jobs. Et il m’a contacté car il avait visiblement besoin d’un regard critique au milieu d’autres interventions plus laudatives.

Pourquoi moi ?

Je ne le lui ai pas directement demandé mais l’explication la plus plausible est à chercher dans la série d’articles (cf ci-dessous) que nous avons récemment publiés sur ce blog et qui sont assez bien placés dans le référencement des moteurs de recherche (ce qui en creux en dit long sur la présence d’une véritable critique d’Apple^[1] dans le Web francophone).

Sachant que ces articles sont eux-mêmes des traductions collectives issues du travail de Framalang, je n’avais aucune légitimité pour m’exprimer. Mais peu importe, me suis-je dit, profitons-en pour tenter de faire passer quelques idées.

Et bien je suis désolé de vous décevoir mais c’est raté 🙁

On ne peut pas trop en vouloir au journaliste qui avait un temps limité (ainsi qu’un sujet qui n’avait rien à voir avec le logiciel libre) et qui a extrait ce qu’il jugeait pertinent de notre entretien téléphonique. Mais ce pertinent pour lui est malheureusement un insignifiant pour moi.

C’est le risque et c’est la loi du genre lorsque l’on n’est pas en direct, mais je me sens solidaire de tous les interviewés qui sont restés frustrés des coupes au montage effectués lors d’un passage radiophonique.

Le reportage tel qu’entendu par les auditeurs de France Culture (3 min – 2 Mo – lien direct au format ogg) :

L’entretien téléphonique presque au complet que le journaliste a eu la gentillesse de mettre en ligne sur le site de la radio (5 min – 6 Mo – lien direct au format ogg) :

Quelques articles du Framablog sur Apple mentionnés plus haut :

• À qui la faute si les logiciels libres sous licence GPL sont éjectés de l’App Store ?
• Combien de futurs hackers Apple est-il en train de tuer ?
• Les logiciels libres ne sont pas les bienvenus dans l’App Store d’Apple
• La fin du Web ouvert – Apple ou la banlieue riche du Web
• Dis-moi si tu préfères bidouiller Arduino ou consommer iPad et je te dirai qui tu es
• Pourquoi je n’achèterai pas un iPad
• L’Éclaternet ou la fin de l’Internet tel que nous le connaissons ?
• iPad et éducation sont des mots qui ne vont pas bien ensemble
• iPad is iBad for freedom

Notez que je ne suis pas forcément non plus très satisfait de ma prestation globale lors de l’interview. Vous auriez dit quoi, vous, à ma place ?

J’en conclue donc naïvement que pour réussir ce genre d’exercice, il faut d’abord être bon lors de l’entretien et ensuite prier pour qu’on en tire la substantifique moelle au montage.

Je vous laisse, je vais quand même prévenir ma maman que son fils est passé à France Culture dans le cadre de son quart d’heure warholien de célébrité 😉

Ca y est, le mouvement est définitivement lancé. Pas un jour sans que l’expression « Open Source » (ou plus simplement « Open ») se décline en ceci ou en cela.

Voici par exemple ce que j’ai rapidement trouvé sur la Wikipédia anglophone (prendre un grande respiration) : Open Source Hardware, Open Format, Open Standard, Open Data, Open Access, Open Content, Open Education, Open Educational Resources, Open Textbooks, Open Source Governance, Open Source Political Campaign, Open Design, Open Source Car, un très étonnant Open Source Religion, Open Cola et, le meilleur pour la fin, Open Source Beer !

Avec plus ou moins de bonheur du reste, car à l’échelle de tout ce qui est et sera possible de faire nous n’en sommes souvent qu’au stade de la genèse (ou en version 0.1 si vous préférez), car le logiciel libre a ses spécificités qui n’en font pas nécessairement un modèle transposable ailleurs. Mais le simple fait que des initiatives pullulent un peu partout est déjà signicatif en soi.

Il faut dire que si j’avais 20 ans aujourd’hui et que je prenais le temps d’observer la société qu’on me propose, j’aurais bigrement envie moi aussi d’explorer toutes ces tentatives d’alternatives à une déprimante réalité. En prenant appui sur les nouvelles technologies et en s’inspirant de ce qu’a déjà fait le logiciel libre, on peut effectivement contribuer à construire un autre monde possible. On vous regardera comme un doux rêveur au début, mais tenez bon, Wikipédia ne s’est pas construite en un jour 🙂

Dans la famille Open Source je demande donc aujourd’hui la carte écologie, avec un site Web découvert hier soir grâce à la fée Sérendipité.

Le projet s’appelle Open Source Ecology. C’est un titre vaste et ambitieux qui, pour le moment, se concrétise avant tout par le fascinant « Global Village Construction Set » dont la courte vidéo sous-titrée ci-contre vous donnera de suite un bref aperçu.

—> La vidéo au format webm
—> Le fichier de sous-titres

Voici une description plus générale telle qu’on la trouve sur la page francophone du projet :

Open Source Ecology est un mouvement dédié à l’élaboration conjointe de technologies reproductibles, open source et modernes pour des communautés villageoises résilientes. En utilisant tout à la fois la permaculture et les ateliers de conception numérique pour la satisfaction des besoins de base, selon une méthodologie open source favorisant la reproduction à bas coût de l’ensemble des opérations, nous souhaitons aider chaque personne qui le souhaite à dépasser le stade de la survie et à évoluer vers la liberté.

Dans notre analyse, la plupart des technologies nécessaires à un mode de vie durable et plaisant peuvent se réduire au coût de la ferraille et du travail. Il y a un potentiel immense de transformation sociale dès lors que ces technologies seront pleinement développées de manière à construire des communautés auto-suffisantes reliées entre elles. Nous serons alors libérés des contraintes matérielles et aptes à nous réaliser nous-mêmes.

Bien sûr, il s’agit d’une tâche ambitieuse, mais nous avons déjà accompli beaucoup et nos progrès sont rapides. Nous mettons la théorie en œuvre à Factor e Farm, notre installation à la campagne. Nos moyens d’atteindre ces objectifs sont minutieusement détaillés dans le Global Village Construction Set ainsi que dans nos Propositions pour une écologie open source.

L’ensemble du site et donc, j’imagine, du projet est sous double licence GNU FDL et Creative Commons By-Sa. Et les machines dont il est question semblent déjà bien documentées si j’en juge par l’exemple du tracteur LifeTrac.

On dirait un peu des Amish qui ne refuseraient plus la modernité pour au contraire en tirer le meilleur profit, des « Amish 2.0 » en quelque sorte.

Vous en avez assez des vicissitudes de la ville et son stressant et démotivant métro, boulot, dodo ? Alors partez dans la Creuse avec vos amis Facebook fonder une communauté écologique et open source !

Visitez le site du projet (entrée en français)…

Google vient de sortir un énième nouveau projet : Google Art Project.

Il est ainsi décrit dans cette dépêche AFP : « Google a lancé une plate-forme permettant aux amateurs d’art de se promener virtuellement dans 17 des plus grands musées du monde, dont le MoMA de New York et le Château de Versailles, grâce à sa technologie Street View, familier des utilisateurs du site de cartes Google Maps ».

La présentation vidéo de Google est spectaculaire et la visite virtuelle l’est tout autant. Ce qui m’a le plus impressionné c’est le fait que chaque musée offre l’une de ses œuvres à une précision numérique hors du commun (7 milliards de pixels !). Regardez un peu ce que cela donne dans le détail pour La Naissance de Vénus de Boticceli.

Faites un zoom sur son visage et vous serez peut-être comme moi saisi par une certaine émotion. Et si j’ai pris cet exemple ce que j’étais encore récemment devant le vrai tableau à Florence. L’émotion est tout autre, sans commune mesure, elle est bien plus intense évidemment, mais pouvoir regarder à la loupe un tel chef-d’œuvre n’est pas sans intérêt^[1].

On a alors vu toute la presse, petit et grande, s’enthousiasmer sur ce nouveau service gratuit (cela allait sans dire avec Google). J’ai ainsi pu comptabiliser plus d’une centaine d’articles dans… Google Actualités (sic, on n’en sort pas !), et jamais je n’y ai lu la moindre critique.

La seule question que l’on se pose éventuellement est de se demander furtivement si un tel projet peut se substituer à la visite réelle. Et la réponse, aussi bien du côté Google que du côté musées, est au contraire que cela stimule la curiosité et amplifie le désir de venir. Un peu comme la vitrine d’un magasin vous donne envie de rentrer en somme. Et puis pour ceux qui ne peuvent vraiment pas y aller comme les enfants d’Afrique ou d’Amérique Latine, c’est toujours bien mieux que rien.

Personne n’est donc venu apporter un seul bémol. On aurait pu souligner que c’est encore et toujours du Google, qui de projets sympas en projets sympas, commence à atteindre une taille intrinsèquement monstrueuse. On aurait pu regretter que pour pouvoir bénéficier d’un parcours individualisé et former ses propres collections il faille évidemment un compte Google (c’est gratuit mais c’est bien là le prix à payer à Google). Plus subtil mais pas moins important, on aurait pu se demander quelles étaient exactement les conditions juridiques des accords entre Google et les musées, notamment pour ce qui concerne l’épineuse question de la reproduction d’œuvres dans le domaine public (d’ailleurs on voit déjà fleurir dans Wikimedia Commons des reproductions d’œuvres directement issues des reproductions de Google Art Project !).

Personne, sauf peut-être Adrienne Alix, présidente de Wikimedia France, qui a publié sur son blog personnel sa « vision critique » du projet, dans un billet que nous avons reproduit ci-dessous parce que nous partageons sa perplexité.

« Les wikimédiens passent énormément de temps à prendre de belles photographies de ces œuvres pour les mettre librement à disposition sur Wikimedia Commons et permettre à tous de les réutiliser. Il est souvent difficile de faire admettre aux musées qu’il est bon de permettre cette très large diffusion de la culture. Les choses changent peu à peu, le dialogue s’engage ces derniers temps, et c’est une très bonne chose (…) Quelle est ma crainte ? Que ces musées qui commencent timidement à ouvrir leurs portes et se lancent avec nous en faisant confiance, en prenant le pari de la diffusion libre de contenus dans le domaine public, se replient sur une solution verrouillée comme celle proposée par Google Art Project, où l’internaute ne peut absolument pas réutiliser les œuvres ainsi montrées. On visite, on ne touche pas. On ne s’approprie pas. On est spectateur, et c’est tout. Je crains que par envie de contrôle de l’utilisation des reproductions d’œuvres conservées dans les musées, la notion de domaine public recule. »

Vous trouverez par ailleurs en annexe, un petit clip vidéo montrant un photographe wikipédien à l’œuvre. Quand Google nous propose une visite virtuelle clinquante mais balisée et pour tout dire un brin étouffante, Wikipédia donne envie d’arpenter le vaste monde et d’en garder traces au bénéfice de tous.

Google Art Project : vision critique

URL d’origine du document

Adrienne Alix – 3 février 2011 – Compteurdedit
Licence Creative Commons By-Sa

Depuis deux jours, le web (et notamment le web « culturel », mais pas seulement) s’enthousiasme pour le dernier-né des projets développés par Google, Google Art Project.

Le principe est compréhensible facilement : Google Art Project, sur le modèle de Google Street View, permet de visiter virtuellement des musées en offrant aux visiteurs une vue à 360°, un déplacement dans les salles. On peut aussi zoomer sur quelques œuvres photographiées avec une très haute résolution et pouvoir en apprécier tous les détails, certainement mieux que ce qu’on pourrait faire en visitant réellement le musée.

Et donc, tout le monde s’extasie devant ce nouveau projet, qui permet de se promener au musée Van Gogh d’Amsterdam, au château de Versailles, à l’Hermitage, à la National Gallery de Londres, etc. En effet c’est surprenant, intéressant, on peut s’amuser à se promener dans les musées.

En revanche, au-delà de l’aspect anecdotique et de l’enthousiasme à présent de rigueur à chaque sortie de projet Google, j’aimerais pointer quelques petits points, qui peuvent paraître pinailleurs, mais qui me semblent importants.

1- d’une part, la qualité n’est pas toujours là. Vous pouvez en effet vous promener dans le musée, mais ne comptez pas forcément pouvoir regarder chaque œuvre en détail. On est dans de la visite « lointaine », un zoom sur une œuvre donnera quelque chose de totalement flou. Les deux captures d’écran ci-dessous sont, je pense, éloquentes.

2- Google rajoute une jolie couche de droits sur les œuvres qui sont intégrées dans ces visites virtuelles. Une part énorme de ces œuvres est dans le domaine public. Pourtant, les conditions générales du site Google Art Project sont très claires : cliquez sur le « Learn more » sur la page d’accueil. Vous verrez deux vidéos expliquant le fonctionnement du service, puis en descendant, une FAQ. Et cette FAQ est très claire :

Are the images on the Art Project site copyright protected?

Yes. The high resolution imagery of artworks featured on the art project site are owned by the museums, and these images are protected by copyright laws around the world. The Street View imagery is owned by Google. All of the imagery on this site is provided for the sole purpose of enabling you to use and enjoy the benefit of the art project site, in the manner permitted by Google’s Terms of Service.

The normal Google Terms of Service apply to your use of the entire site.

On y lit que les photos en haute résolution des œuvres d’art sont la propriété des musées et qu’elles sont protégées par le « copyright » partout dans le monde. Les images prises avec la technologie « street view » sont la propriété de Google. Les images sont fournies dans le seul but de nous faire profiter du Google Art Projetc. Et on nous renvoie vers les conditions générales de Google.

En gros, vous ne pouvez rien faire de ce service. Vous pouvez regarder, mais pas toucher.

3 – D’ailleurs vous ne pouvez techniquement pas faire grand chose de ces vues. Y compris les vues en très haute définition. Effectivement le niveau de détail est impressionnant, c’est vraiment une manière incroyable de regarder une œuvre. Mais après ? Vous pouvez créer une collection. Soit, je décide de créer une collection. Pour cela il faut que je m’identifie avec mon compte google (donc si vous n’avez pas de compte google, c’est dommage pour vous, et si vous vous identifiez, cela fait encore une donnée sur vous, votre personnalité, que vous fournissez à Google. Une de plus). Je peux annoter l’œuvre (mettre un petit texte à côté, sauvegarder un zoom, etc). Que puis-je faire ensuite ? Et bien, pas grand chose. Je peux partager sur Facebook, sur Twitter, sur Google Buzz ou par mail.
Mais en fait, je ne partage pas réellement l’œuvre, je partage un lien vers ma « collection ». C’est à dire que jamais, jamais je ne peux réutiliser cette œuvre en dehors du site.

Donc si par exemple je suis professeur d’histoire ou d’histoire de l’art, je suis obligée de faire entrer mes élèves sur ce site pour leur montrer l’œuvre, je ne peux pas la réutiliser à l’intérieur de mon propre cours, en l’intégrant totalement. Ni pour un exposé. Je ne peux pas télécharger l’œuvre. Qui pourtant est, dans l’immense majorité des cas, dans le domaine public. Il faut donc croire que la photographie en très haute résolution rajoute une couche de droits sur cette photo, ce qui pourrait se défendre, pourquoi pas, mais aujourd’hui ça n’est pas quelque chose d’évident juridiquement.

Vous me direz qu’après tout, cela résulte de partenariats entre des musées et Google, ils prennent les conditions qu’ils veulent, c’est leur problème, on a déjà de la chance de voir tout cela. Ok. Mais ce n’est pas la conception de partage de la culture que je défends.

Je me permettrai de rappeler que, en tant que wikimédienne, et défendant la diffusion libre de la culture, je suis attachée à la notion de « domaine public ». Au fait que, passé 70 ans après la mort d’un auteur, en France et dans une très grande partie du monde, une œuvre est réputée être dans le domaine public. Et donc sa diffusion peut être totalement libre. Sa réutilisation aussi, son partage, etc.

Les wikimédiens passent énormément de temps à prendre de belles photographies de ces œuvres pour les mettre librement à disposition sur Wikimedia Commons et permettre à tous de les réutiliser. Il est souvent difficile de faire admettre aux musées qu’il est bon de permettre cette très large diffusion de la culture. Les choses changent peu à peu, le dialogue s’engage ces derniers temps, et c’est une très bonne chose. Nos points d’achoppement avec les musées tiennent souvent à la crainte de « mauvaise utilisation » des œuvres, le domaine public leur fait peur parce qu’ils perdent totalement le contrôle sur ces œuvres (notamment la réutilisation commerciale). Ils discutent cependant avec nous parce qu’ils ont conscience qu’il est impensable aujourd’hui de ne pas diffuser ses œuvres sur internet, et Wikipédia est tout de même une voie royale de diffusion, par le trafic énorme drainé dans le monde entier (pour rappel, plus de 16 millions de visiteurs unique par mois en France, soit le 6e site fréquenté).

Quelle est ma crainte ? Que ces musées qui commencent timidement à ouvrir leurs portes et se lancent avec nous en faisant confiance, en prenant le pari de la diffusion libre de contenus dans le domaine public, se replient sur une solution verrouillée comme celle proposée par Google Art Project, où l’internaute ne peut absolument pas réutiliser les œuvres ainsi montrées. On visite, on ne touche pas. On ne s’approprie pas. On est spectateur, et c’est tout. Je crains que par envie de contrôle de l’utilisation des reproductions d’œuvres conservées dans les musées, la notion de domaine public recule.

Alors certes, la technologie est intéressante, le buzz est légitime, l’expérience de visite est plaisante. Mais au-delà de cela, est-ce vraiment une vision moderne et « 2.0 » du patrimoine qui est donnée ici ? Je ne le pense pas. J’ai même une furieuse impression de me retrouver dans un CD-ROM d’il y a 10 ans, ou dans le musée de grand-papa.

Pour terminer, je vous invite à aller vous promener sur Wikimedia Commons, dans les catégories concernant ces mêmes musées. C’est moins glamour, pas toujours en très haute résolution, mais vous pouvez télécharger, réutiliser, diffuser comme vous voulez, vous êtes libres…

• Metropolitan Museum of Art
• Musée de l’Hermitage
• MoMa
• Etc…

Au cas où il serait nécessaire de le préciser : je m’exprime ici en mon nom personnel, et uniquement en mon nom personnel. Les opinions que je peux exprimer n’engagent en rien l’association Wikimédia France, qui dispose de ses propres canaux de communication.

Annexe : Vidéo promotionnelle pour Wiki loves monuments

Réalisée par Fanny Schertzer et Ludovic Péron (que l’on a déjà pu voir par ailleurs dans cet excellent reportage).

—> La vidéo au format webm

URL d’origine du document