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

Traduction Framalang : ga3lig, lenod, peupleLa, LAuX, billouche, Goofy, jcr83, purplepsycho, Jej, KoS, Julius22, kalupa, tuki, lamessen, okram + Sinma

La collaboration entre projets

Henri Bergius

Henri Bergius est le fondateur de Midgard(1), un dépôt de contenu pour les logiciels libres. Il a aussi été longtemps impliqué dans la géolocalisation d’ordinateurs de bureaux sous Linux ainsi que dans les communautés Maemo et Meego. Il dirige un petit cabinet de conseil nommé Nemein, bidouille CoffeeScript et PHP et passe beaucoup de son temps à faire de la moto dans des régions reculées du continent Eurasien. Il vit dans la froide ville nordique d’Helsinki, en Finlande.

Il se peut qu’il existe un système complètement nouveau dans lequel vous pouvez être défini davantage par qui vous êtes plutôt que par ce que vous possédez, par ce que vous avez créé et partagé, parce que d’autres personnes ont ensuite construit sur cette base

– John Seely Brown, ancien directeur de Xerox PARC dans An Optimist’s Tour of the Future (Mark Stevenson, 2010)

Le monde du logiciel libre est pour l’essentiel divisé en tribus rassemblées autour de choses appelées projets. Il existe des projets majeurs tels que GNOME(2), KDE(3) ou Drupal(4) et il existe bien d’autres projets plus modestes tournant autour d’une seule application ou bibliothèque logicielle.

En fait, les qualifier de « projets » est un peu ridicule.

Selon moi, un projet est l’organisation d’un effort visant un but que l’on puisse atteindre et comprend un calendrier avec dates de début et de fin. Ainsi, GNOME 3.1 serait par exemple un projet tandis que GNOME, pris dans son ensemble, n’en est pas un. Il s’agit d’une communauté d’individus qui entretiennent et créent le corps d’un logiciel par de petits efforts variés ou des projets.

Assez de pédantisme. Le souci avec le concept de projet c’est qu’il finit par maintenir une séparation entre les personnes. Cela crée des communautés isolées souvent réticentes voire incapables de collaborer avec « la concurrence ». Mais en fin de compte, toutes ces communautés sont composées de personnes écrivant des logiciels libres. Et ce sont elles qui décident de l’utilisation possible ou non d’un logiciel dans différents environnements.

En fin de compte, nous voulons tous que le logiciel que nous avons créé soit utilisé par d’autres. Mieux encore : nous voulons que les autres joignent leurs efforts aux nôtres et créent des choses sympa à partir de ce que nous avons créé. Après tout, ceci constitue le cœur même des logiciels libres.

Alors pourquoi érigeons-nous ces murs autour de nous ? Garder une communauté isolée ne fait que favoriser une mentalité de type « nous contre eux ». Les incompatibilités des différents langages de programmation contribuent déjà fortement à notre division. Pourquoi en rajouter ?

La leçon de Midgard

Il est une chose que j’aurais voulu savoir quand j’ai démarré, dans cette période optimiste des « .com » de la fin des années 90 : c’est qu’en réalité le développement de logiciels ne gagne rien à s’isoler. Avec un peu d’efforts nous pouvons partager nos logiciels et nos idées par le biais de communautés, ce qui renforce et améliore à la fois les logiciels et les communautés.

Quand j’ai démarré ma carrière dans le logiciel libre, c’était l’époque des grands projets. Netscape ouvrait son code source, la fondation Apache prenait forme et des sociétés de capital-risque venaient de partout. Tenter de bâtir sa communauté devenait la norme. C’était le chemin assuré vers la gloire, la fortune et la réalisation de choses extraordinaires.

Alors nous avons construit nos propres infrastructures web. À ce moment-là il n’y en avait pas tant que cela, en particulier pour le tout jeune langage PHP. Le PHP n’était même pas notre premier choix. Nous l’avions seulement choisi au terme d’un long débat sur l’utilisation de Scheme(5) que notre développeur principal préférait. Mais le PHP gagnait alors en popularité, devenant le langage de programmation de la Toile. Et nous voulions construire la Toile.

Au début, les choses semblaient prometteuses. Beaucoup de développeurs rejoignaient notre communauté et commençaient à y contribuer. Il y a même eu des entreprises fondées autour de Midgard. Notre infrastructure gagnait en fonctionnalités et devenait de plus en plus liée à Midgard.

Avec le recul, c’est là que nous avons fait une erreur. Nous avons positionné Midgard pour être distinct du PHP lui-même. Quelque chose que vous installeriez séparément, et utiliseriez comme base pour y construire des sites entiers. Il fallait soit suivre notre voie, soit suivre celle de tout le monde.

Avec Midgard, vous deviez utiliser notre interface de dépôt de contenus pour tout, aussi bien pour notre gestion des utilisateurs que pour le modèle de permissions. Vous deviez utiliser notre système de modèles et stocker beaucoup de votre code dans le dépôt au lieu d’utiliser un système de fichiers.

Ceci ne passait évidemment pas très bien auprès de l’ensemble de la communauté PHP. Nos idées leur semblaient étranges, et Midgard, à ce moment-là, était même distribué en tant que gigantesque correctif à la base de code puisqu’on ne pouvait pas charger de modules avec PHP3.

Les années ont passé et la popularité de PHP a connu des hauts et des bas. Pendant ce temps, la communauté Midgard est restée relativement constante : un petit groupe soudé faisant des progrès sur le long terme mais séparé du monde plus large de PHP.

Nous nous sommes toujours demandé pourquoi il était si difficile d’interagir avec le monde PHP. Même d’autres communautés faisant des choses complètement différentes, comme l’environnement de bureau GNOME, semblaient plus faciles à approcher. Ce n’est que récemment, après des années d’isolement, que nous avons pris conscience du problème. En résumé : les infrastructures nous séparent alors que les bibliothèques nous permettent de partager notre code et nos expériences.

À propos des bibliothèques et des infrastructures

En définitive, les logiciels ont pour objectif l’automatisation, la construction d’outils que les autres peuvent utiliser pour résoudre des problèmes ou se connecter entre eux. Avec les logiciels, ces outils comportent plusieurs couches. Il existe des services de bas niveau comme les systèmes d’exploitation, puis les bibliothèques, les infrastructures, les boîtes à outils et enfin les applications elles-mêmes.

Les applications sont toujours écrites pour des usages spécifiques, donc entre elles il existe peu de possibilités de partage de code.

Les possibilités les plus séduisantes se situent au niveau des bibliothèques et infrastructures. Une infrastructure, si elle est suffisamment générique, peut généralement être utilisée pour construire différentes sortes de logiciels. Une bibliothèque, quant à elle, peut être utilisée pour apporter un élément particulier de logique ou de connectivité là où le besoin s’en fait sentir. De mon point de vue, c’est dans cette couche que le plus gros de la programmation devrait être fait, avec des applications spécifiques qui ne sont que des connexions entre diverses bibliothèques au sein d’une infrastructure qui s’occupe alors de faire tourner l’application en question.

Qu’est-ce qu’une bibliothèque et qu’est-ce qu’une infrastructure ? Les gens utilisent souvent ces termes indifféremment bien qu’il existe une règle grossière qui permet de les différencier : une bibliothèque est une ressource à laquelle votre code fait appel, alors qu’une infrastructure est une ressource qui fait appel à votre code.

Si vous voulez que votre code soit utilisé et amélioré, le meilleur moyen est de maximiser le nombre de ses utilisateurs et contributeurs potentiels. Avec le logiciel libre, cela fonctionne en s’assurant que votre code peut être adapté à de multiples situations et environnements.

En définitive, ce que vous voulez développer c’est une bibliothèque. Les bibliothèques c’est cool.

Comment faire en sorte que la collaboration fonctionne

Le plus difficile est de franchir la barrière du « eux-contre-nous ». Les développeurs de l’autre communauté sont des bidouilleurs concevant du logiciel libre, tout comme vous. Il suffit donc de franchir le pas et de commencer à leur parler.

Une fois le débat engagé, voici quelques points que j’ai trouvés importants quant à l’application effective des idées communes ou des bibliothèques au-delà des frontières du projet

• Utilisez des licences permissives et essayez d’éviter les cessions de droits d’auteurs et autres exigences que les utilisateurs potentiels trouveraient onéreuses. Hébergez le projet en terrain neutre. Pour les projets web, Apache est un assez bon havre. Pour les projets bureautiques, Freedesktop est probablement le meilleur choix. Utilisez des technologies qui n’imposent pas trop de contraintes. Les bibliothèques doivent être de bas niveau, ou fournir des API (interfaces de programmation) D-Bus utilisables avec n’importe quel système.
• Évitez les dépendances spécifiques à une infrastructure. KDE a, par exemple, trouvé GeoClue difficile à adopter parce qu’il utilise des paramètres spécifiques à l’interface GNOME. Rencontrez les autres. Si vous venez du projet GNOME, allez à l’aKademy et donnez-y une conférence. Si vous êtes développeur KDE, allez parler au GUADEC. Après avoir partagé une bière ou deux, la collaboration par IRC vient beaucoup plus naturellement.
• Enfin, vous devez accepter que votre implémentation ne soit pas utilisée par tout le monde. Mais si, au moins, d’autres mettent en œuvre les mêmes idées, alors une collaboration reste possible.

Bonne chance pour abattre les frontières du projet ! Dans la plupart des cas, cela fonctionne si vos idées sont bonnes et présentées avec un esprit ouvert. Mais même si vous ne trouvez pas de terrain d’entente, tant que votre application remplit sa fonction pour vous, ça n’a pas été fait en vain. Après tout, ce qui compte c’est de proposer des logiciels et d’offrir la meilleure expérience utilisateur possible.

(1) http://midgard-project.org/

(2) gnomefr.org

(3) fr.kde.org

(4) drupalfr.org

(5) http://fr.wikipedia.org/wiki/Scheme

Crédit photo : mommy peace – (CC BY-NC-SA 2.0)

Vous avez peut-être remarqué dans les derniers articles publiés sur le framablog que quelques illustrations à l’humour approximatif étaient signées Gégé, le générateur de Geektionnerd. Ce petit jeu graphique vous est aujourd’hui offert en libre-service par Framasoft.

D’où vient-il ?

C’est une conception des Mozilla Labs dont on peut trouver toute la petite histoire et les caractéristiques techniques sur ce blog de Mozilla hacks. Pour simplifier, Willian Carvalho a voulu réaliser avec Canvas (traitement de l’image en JavaScript) ce qui existait seulement en Flash. C’est une chouette et amusante démonstration de ce qu’on peut faire désormais avec le HTML5, que Mozilla défend et promeut comme le langage du Web, plateforme ouverte de développement…

La version Framalab

C’est Cyrille (avec l’aide de Quentin pour la mise en ligne) qui a réalisé une adaptation francophone, avec la complicité de Simon “Gee” Giraudot qui a fourni les images. Vous pouvez trouver les sources librement disponibles sur le github, n’hésitez pas à le forker, à vous installer votre propre version avec vos images et à fabriquer vous-mêmes des bandes dessinées libres.

Comment ça marche ?

C’est vraiment simple et intuitif. Rendez-vous sur la page du générateur de Geektionnerd, choisissez et déplacez les éléments graphiques, saisissez du texte pour vos “bulles”, redimensionnez les éléments avec les flèches haut/bas du clavier et inversez-les avec les flèches droite/gauche. Vous pouvez enregistrer facilement vos créations ensuite.

…d’ailleurs n’hésitez pas à en faire profiter tout le monde, peut-être publierons-nous vos meilleures réalisations ici, qui sait ?

Et Simon Giraudot, le voilà piraté ? Qu’en dit-il ?

Eh bien nous lui avons posé la question…

Quelle a été ta première réaction quand tu as découvert ce générateur ?

Très bonne ! Lorsque Cyrille a partagé la première version du générateur sur la liste de l’association Framasoft, tout le monde a commencé à jouer avec et à partager ses créations sur la liste. C’est assez marrant de voir mes personnages avec des mots qui ne sont pas les miens dans leur bouche !

D’une certaine façon c’est la continuité logique des créations libres que tu as réalisées avec la série des Geektionnerds ?

À priori c’est pareil. D’ailleurs, les dessins du générateur ne sont pas des dessins « exclusifs », ils sont en fait issus d’articles du blog (donc ils sont déjà sous CC-By-Sa !). Mais oui, c’est l’exacte continuité de ce que je propose dans le Geektionnerd. J’ai placé mes œuvres sous licence libre par conviction, parce que c’est comme ça que je vois « l’art » de manière générale. Le fait que les dessins soient librement modifiables n’est qu’une liberté, mais ça ne veut pas dire que vous allez forcément l’utiliser : grâce à ce générateur, on vous propose d’expérimenter cette liberté et de créer vos propres BD dérivées du Geektionnerd !

Tout le monde peut s’amuser avec ce petit générateur que nous te remercions d’avoir alimenté de tes dessins. Penses-tu que c’est juste un gadget sympathique ou que ça peut déclencher des vocations ?

L’un n’empêche pas l’autre, non ? 😉 Blague à part, c’est surtout un outil de loisir, à mon sens. Ça reste du bidouillage de dessins et de textes, je ne me verrais pas réaliser une histoire complète avec ça, par exemple. Mais après, qui sait ? Avec les licences libres, les possibilités sont infinies : imaginez une personne qui a une idée géniale de scénario pour une BD, mais ne sait absolument pas dessiner. Grâce aux contributions que l’on met dans le pot commun de l’art libre (et je ne parle pas que de moi ici mais de tous les artistes libres), il pourrait tout à fait récupérer une énorme base de données de dessins et les arranger comme il le veut pour correspondre à son scénario. Sympa, non ?

Si l’on va un peu plus loin, ce genre de pratiques implique la fin de l’œuvre unique, puisque chacun peut utiliser, copier, remixer, re-créer et diffuser des comic strips ? l’analogie avec les 4 libertés du logiciel libre est frappante, non ?

Oui, c’est exactement ça. Pour autant, il ne faut pas voir ça comme une trahison de l’œuvre ou un manque de respect de l’auteur (ce genre d’argument revient souvent lorsqu’on parle de modifier les œuvres sans l’autorisation de l’auteur – un des principes d’une licence libre). L’œuvre originale, le Geektionnerd, reste une « œuvre unique », si l’on veut. La différence avec une œuvre sous régime de droit d’auteur classique, ce n’est pas que vous allez vous l’approprier et en faire ce que vous voulez : ça, honnêtement, vous le faites aussi avec des œuvres protégées.

La différence, c’est que là, non seulement personne ne viendra vous demander des comptes et vous traiter de voleur, mais en plus, on vous y encourage ! Tu parles de l’analogie avec les 4 libertés du logiciel libre : je pense aussi, personnellement, aux deux modèles que propose Florent Latrive dans son livre Du bon usage de la piraterie. Il explique que, classiquement, on aimait considérer les artistes comme des  « génies romantiques » qui avaient une inspiration naturelle et quasi-divine. Mais l’artiste est en fait plus proche du « hacker », qui s’approprie toutes les informations qui l’entourent pour créer quelque chose de nouveau. Tous les artistes passent leur temps à reprendre, copier, réutiliser les œuvres du passé. La licence libre ne fait que se mettre en accord avec cette réalité qui est pourtant loin d’être spécifique à l’art libre ! On connait la fameuse citation de Picasso, « Les bons artistes copient, les grands artistes volent ». Aurait-il mis ses œuvres sous licence libre si cela avait existé à son époque ? C’est une autre question 😉

Conflit de génération sur le Web…

Les pères fondateurs avaient imaginé un réseau ouvert, génératif, bidouillable.

Ils sont aujourd’hui amers de constater que le Web est devenu un adolescent qui loin de chercher à émanciper ses utilisateurs, tente plutôt de les forcer dans des cases, de les infantiliser, de ne leur laisser aucun contrôle.

Le constat dressé la semaine dernière par Anil Dash a depuis été largement partagé par les vétérans du Web. Comme l’impression d’un paradis perdu.

Mais la roue tourne et les utopistes des débuts rêvent d’un retour aux sources, d’éduquer les milliards de nouveaux internautes, de leur faire partager leur rêve. Est-ce envisageable ? Surtout, même s’ils prenaient conscience des valeurs que portait le Web à ses débuts, la majorité des utilisateurs serait-elle prête à abandonner ses usages confortables actuels pour reprendre le flambeau des fondateurs et à explorer de nouvelles voies respectueuses de ces valeurs ?

Le retour au bricolage high-tech avec un fer à souder allié au code (Ardhuino, imprimantes 3D, FabLabs…), les initiatives comme celles du projet Webmakers qui vise à éduquer au Web toute une génération pour qu’elle s’en empare au lieu de le consommer, autant de signes d’une prise de conscience qui pourrait modifier la donne. Cet article qui lance un coup d’œil dans le rétroviseur n’est pas un moment de simple nostalgie mais une invitation au renouvellement des idéaux fondateurs.

Le Web que nous avons perdu

article original The Web We Lost par Anil Dash, proposé et présenté par Clochix

Traduction framalang Zii, KoS, Goofy, Garburst, lamessen

L’industrie technologique et sa presse ont traité l’explosion des réseaux sociaux et l’omniprésence des applications pour smartphone comme une victoire sans appel pour Monsieur Tout-le-monde, un triomphe de la convivialité et de l’autonomisation. On a moins parlé de ce que nous avons perdu tout au long de cette transition, et je trouve que les jeunes générations ne savent même pas comment était le Web autrefois.
Alors voici quelques aperçus d’un Web qui pour l’essentiel a disparu :

• Il y a 5 ans, la plupart des photos qu’on voulait partager étaient chargées sur Flickr, où elles pouvaient être taguées par les humains ou même par les applications et services, en utilisant un système de balises. Les images étaient facilement accessibles sur le Web, en utilisant de simples flux RSS. Et les photos chargées pouvaient facilement l’être sous des licences permissives comme celles fournies par Creative Commons, autorisant la modifications et la réutilisation de n’importe quelle façon par des artistes, des entreprises ou des particuliers.

• Il y a une dizaine d’années, Technorati vous laissait chercher sur la majeure partie du Web social en temps réel (cependant la recherche avait tendance à être horriblement longue pour l’affichage des résultats), avec des tags qui marchaient comment le font les hashtags sur Twitter aujourd’hui. Vous pouviez trouver des sites en relation avec votre contenu avec une simple recherche, et savoir qui s’exprimait dans un fil de discussion, indépendamment des outils ou plateformes utilisés pour exposer des idées. À l’époque, c’était tellement excitant que lorsque Technorati ne put faire face au volume croissant de la blogosphère, les utilisateurs furent très déçus. Au point que même quelqu’un d’aussi habituellement circonspect que Jason Kottke se mit à descendre le service en flammes pour l’avoir laissé tomber. Dès l’instant de ses premiers succès pourtant, Technorati avait suscité les louanges de gens comme John Gruber :

Vous pouviez, en théorie, écrire un logiciel pour examiner le code source des quelques centaines de milliers de blogs, et créer une base de données des liens entre ces blogs. Si votre logiciel était assez efficace, il devait pouvoir rafraîchir ses informations d’heure en heure, ajoutant de nouveaux liens à sa base de données en quasi-temps réel. En fait, c’est exactement ce qu’a créé Dave Sifry avec son incroyable Technorati. À ce jour, Technorati surveille 375 000 blogs et a référencé plus de 38 millions de liens. Si vous n’avez jamais joué avec Technorati, vous manquez quelque chose.

• Il y a dix ans, vous pouviez laisser les gens poster des liens sur votre site ou montrer des listes de liens qui pointaient vers votre site. Car Google n’avait pas encore introduit AdWords et AdSense, les liens ne généraient pas de revenus, c’était juste un moyen d’expression ou un outil éditorial. Le Web était un endroit intéressant et différent avant la monétisation des liens, mais en 2007 il devint clair que Google avait changé le Web pour toujours, et pour le pire, en corrompant les liens.

• En 2003, si vous aviez introduit un service d’authentification individuelle opéré par une société, même en documentant le protocole et encourageant les autres à cloner le service, vous auriez été décrit comme quelqu’un qui introduisait un système de surveillance relevant du « Patriot Act ». Il y avait une telle méfiance à l’égard services d’authentification que même Microsoft abandonna ses tentatives de créer un tel système d’inscription. Même si leur expérience utilisateur n’était pas aussi simple que la possibilité omniprésente de s’identifier avec Facebook ou Twitter, le service TypeKey introduit alors avait des conditions légales de partage des données bien plus restrictives. Et pratiquement tous les systèmes qui fournissaient une identité aux utilisateurs autorisaient l’usage de pseudonymes, respectant le besoin qu’ont les gens de ne pas toujours se servir de leur identité légale.

• Au début de ce siècle, si vous aviez créé un service qui permettait aux utilisateurs de créer ou partager du contenu, ils s’attendaient à pouvoir facilement télécharger une copie fidèle de leurs données, ou importer leurs données vers d’autres services compétitifs, sans la moindre restriction. Les entreprises commerciales passaient des années à travailler sur l’interopérabilité autour des échanges de données simplement pour le bénéfice de leurs utilisateurs, quitte à lever théoriquement les barrières pour l’entrée de la concurrence.

• Aux premiers temps du Web social, il était largement admis que de simples gens pourraient être propriétaires de leur identité en ayant leurs propres sites, plutôt que d’être dépendants de quelques gros sites pour héberger leur identité numérique. Dans cette vision, vous possédez votre nom de domaine et contrôlez complètement son contenu, plutôt que d’avoir les mains liées sur un site géré par une grande entreprise. C’était une réaction sensée lorsqu’on prenait conscience que la popularité des gros sites croît et chute, mais que les gens ont besoin d’une identité plus persistante que ces sites.

• Il y a cinq ans, si vous vouliez publier sur votre site du contenu d’un autre site ou d’une application, vous pouviez le faire en utilisant un format simple et documenté, sans avoir besoin de négocier un partenariat ou un accord contractuel entre les sites. L’expérience des utilisateurs n’était donc pas soumise aux caprices des luttes politiques entre les sociétés, mais basée sur l’architecture extensible du Web lui-même.

• Il y a une douzaine d’années, lorsque les gens voulaient soutenir les outils de publication qui symbolisaient cet état d’esprit, ils mutualisaient le coût des serveurs et des technologies nécessaires à ces outils, même si cela coûtait bien plus cher avant l’avènement de l’informatique dans le nuage et la baisse du prix de la bande passante. Leurs pairs de l’univers des technologies, même s’ils étaient concurrents, participaient même à cet effort.

Ce n’est pas notre Web aujourd’hui. Nous avons perdu les éléments-clés auxquels nous faisions confiance et pire encore, nous avons abandonné les valeurs initiales qui étaient le fondement du monde du Web. Au crédit des réseaux sociaux actuels, ils ont apporté des centaines de millions de nouveaux participants sur ces réseaux, et ils ont sans doute rendu riche une poignée de personnes. Mais ils n’ont pas montré le Web lui-même, le respect et l’attention qu’il mérite comme le support qui leur a permis de réussir. Et ils sont maintenant en train de réduire les possibilité du Web pour une génération entière d’utilisateurs qui ne comprennent pas à quel point leur expérience pourrait être beaucoup plus innovante et significative.

Retour vers le futur

Aujourd’hui, lorsque vous voyez des compilations intéressantes d’informations, elles utilisent encore souvent des photos de Flickr, parce qu’il n’y a pas grand-chose à faire avec les maigres métadonnées d’Instagram, et qu’Instagram n’utilise le Web qu’à contre-cœur. Lorsque nous ne pouvons pas retrouver d’anciens messages sur Twitter ou nos propres publications sur Facebook, nous trouvons des excuses aux sites alors que nous avions de meilleurs résultats avec une recherche sur Technorati, qui n’avait portant à sa disposition que de piètres logiciels de son époque. Nous assistons à de stupides combats de coqs avec Tumblr qui ne peut pas récupérer la liste de vos contacts sur Twitter, ou Facebook qui refuse que les photos d’Instagram s’affichent sur Twitter, tout cela parce que des entreprises géantes suivent chacune leur propre programme de développement au lieu de collaborer pour être utiles aux utilisateurs. Et nous nous coltinons une génération de patrons qui sont incités à créer des produits toujours plus bornés et hostiles au Web, tout cela pour permettre à un petit nombre de nantis de devenir toujours plus riches, au lieu de laisser les gens se créer de nouveaux possibles innovantes au dessus du Web lui-même.

Je ne m’inquiète pas, nous allons corriger tout cela. L’industrie technologique, comme toutes les industries, suit des cycles, et le pendule est en train de revenir vers les philosophies globales et émancipatrices sur lesquelles le Web social s’est bâti au début. Mais nous allons devoir affronter un gros défi, ré-éduquer un milliard d’utilisateurs pour leur apprendre ce qu’est le Web, comme nous l’avons fait pendant des années il y a dix ans quand tout le monde a quitté AOL, leur apprendre qu’il y a bien plus à expérimenter sur Internet que ce qu’ils connaissent.

Ce n’est pas ici la polémique habituelle à base de : « ces réseaux verrouillés sont mauvais ». Je sais que Facebook, Twitter, Pinterest, LinkedIn et tous les autres sont de super-sites, qui apportent beaucoup à leurs utilisateurs. D’un point de vue purement logiciel, ce sont de magnifiques réussites. Mais ils sont basés sur quelques hypothèses qui ne sont pas forcément exactes. La première idée fausse d’où découlent beaucoup de leurs erreurs est que donner aux utilisateurs de la flexibilité et du contrôle crée forcément une expérience utilisateur complexe qui empêche leur croissance. La seconde hypothèse erronée, plus grave encore, est de penser qu’exercer un contrôle total sur les utilisateurs est le meilleur moyen de maximiser les profits et la rentabilité de leur réseau.

La première étape pour les détromper, c’est que les gens qui sont en train de créer la prochaine génération d’applications sociales apprennent un peu d’histoire, pour savoir de quoi ils parlent, qu’il s’agisse du modèle économique de Twitter, des fonctions sociales de Google ou de n’importe quoi d’autre. Nous devons savoir ce qui a été essayé et a échoué, quelles bonnes idées étaient tout simplement en avance sur leur temps, et quelles occasions ont été gâchées par la génération actuelle de réseaux sociaux dominants.

Qu’est-ce que j’oublie ? Qu’avons-nous perdu d’autre sur le Web social ?