OSCON Europe 2006

Article publié dans Linux Magazine 92, mars 2007.

Copyright © 2006 - Philippe Bruhat

[+ del.icio.us] [+ Developers Zone] [+ Bookmarks.fr] [Digg this] [+ My Yahoo!]

Chapeau

Du 18 au 21 septembre 2006 s'est tenue à Bruxelles la deuxième édition Européenne d'OSCON. OSCON, pour Open Source CONference est une conférence annuelle organisée par O'Reilly Media aux États-Unis depuis 1997, et en Europe depuis 2005. La convention était hébergée au Plaza Hotel, un des luxueux hôtels au nord de la ville.

La conférence avant la conférence

Avant même le début de cette conférence (professionnelle s'il en est), une autre conférence avait lieu : EuroFOO (FOO signifiant ici Friends Of O'Reilly). C'est une conférence informelle, sur invitation seulement, où Tim O'Reilly invite tout un tas de gens intelligents et à la pointe de l'innovation (les alpha geeks, comme il les surnomme parfois), pour essayer de voir dans quelle direction la technologie avance.

Plusieurs des invités d'EuroFOO Camp participaient également à OSCON, comme on a pu le voir aux nombreux T-shirts orange décorés du logo de l'événement.

Présentation

Comme le montre l'emploi du temps de la conférence (accessible à l'adresse http://conferences.oreillynet.com/euos2006/grid/), il n'y avait pas de quoi chômer : des présentations de 9h à 17h40, en parallèle dans 5 salles pendant les 3 jours, des expositions après 19h, sans parler des couloirs pleins de monde en train d'échanger sur tous les sujets possibles.

Cette année, le thème de la conférence est Opening Innovation.

Jour 0 - Les tutoriels

Le lundi est consacré aux séances de tutoriels ; mais avec quatre tutoriels en parallèle pendant chaque demi-journée, il était évidemment impossible d'assister à tout ! Il en sera d'ailleurs de même pour toute la durée de la conférence. Ce compte-rendu va donc vous donner une vue partielle de la conférence, et essayer de rendre l'ambiance et la diversité des sujets abordés.

Ruby on Rails - Marcel Molina

Les tutoriels commencent dès 8h30 du matin, avec Jabber Boot Camp, par Peter Saint-André et Ralph Meijer, Start-ups 2.0, par Marc Hedlund, Data Warehousing with MySQL, par John Paul Ashenfelter et Ruby on Rails par Marcel Molina.

N'ayant pas vraiment de connaissance de RoR (Ruby on Rails), mais n'arrêtant pas d'en entendre parler, j'ai voulu voir ce qu'il en était.

Marcel Molina sait de quoi il parle, puisqu'il fait partie de 37signals, la boîte qui a publié Ruby on Rails (inspiré de leur logiciel maison BaseCamp). Ruby on Rails est un framework web très à la mode en ce moment.

Comme l'a fait remarquer Piers Cawley, tout le bruit actuel autour de Ruby on Rails, c'est un peu « a bunch of Java programmers finally discovering how cool Perl is » (un tas de programmeurs Java qui découvrent finalement à quel point Perl est cool).

Marcel rappelle le principe du MVC (Model-View-Controler, issu de SmallTalk, sur lequel est basé RoR), et montre par l'exemple les deux principes de RoR : DRY (Don't Repeat Yourself) et « Convention over Configuration ».

Ainsi avec ActiveRecord, l'ORM de RoR (Object Relational Mapper, un ensemble de classes qui gèrent la persistance des données dans une base de données en évitant au programmeur de devoir toucher à la base de données), il n'y a besoin de définir les attributs de la classe qu'en un seul endroit. Ces attributs seront également les noms des colonnes dans la table qui portera le même nom que la classe. On le voit, les rubyistes eux aussi pensent que la paresse est une vertu.

RoR insiste également beaucoup sur les tests et la documentation, en créant en particulier tous les fichiers et le cadre nécessaire pour ceux-ci. Bon, c'est quand même à vous de les écrire à la fin...

Il présente enfin le système de « migrations » d'ActiveRecord. C'est un système qui permet de mettre à jour les modifications de sa base de données sans s'arracher les cheveux. Le principe est qu'ActiveRecord va écrire pour vous les scripts de migration (d'où le nom) de la base de données au fur et à mesure de l'évolution de votre base de code. On définit les modifications de la base d'une façon abstraite, et le SQL nécessaire pour faire évoluer le schéma de la base est généré par Ruby, pour le moteur de base de données cible.

Damian Conway - The 7 Principles of Better API Design

L'après-midi propose quatre nouveaux tutoriels : The 7 Principles of Better API Design par Damian Conway, Building Better Ajax Applications par Alex Russell, un Workshop on Open Source Licensing for Businesses par Martin von Haller Groenbaek et Building Passionate Users par Kathy Sierra.

Damian Conway est l'un des meilleurs présentateurs de la communauté Perl, je n'ai donc pas manqué son tutoriel.

Les 7 principes sont les suivants (et il les illustre tous avec des modules qu'il a écrits) :

Damian Conway
Damian Conway
Photo James Duncan Davidson/O'Reilly Media
  1. Do one thing really well

    Un module devrait ne faire qu'une chose, mais très bien.

    Perl6::say exporte seulement la fonction say(), qui fonctionne comme en Perl 6 (en rajoutant un \n au bout).

  2. Design by coding

    Écrire le code qui va utiliser le module que l'on est en train de concevoir est une très bonne manière d'améliorer sa conception. Le développement piloté par les test (TDD, Test Driven Development) est une manière d'y arriver, les scripts de test utilisant la librairie qu'ils doivent tester. Demander à ses futurs utilisateurs de proposer l'interface qui leur plairait en est une autre.

    Regexp::Common a ainsi l'interface d'un hash, parce que c'est la plus logique pour les utilisateurs du module.

  3. Evolve by substraction

    L'évolution de l'interface se fait en déplaçant la complexité vers les fonctions de bas niveau, donc en soustrayant de la complexité des interfaces de haut niveau (celles que voit l'utilisateur).

    IO::Prompt n'exporte qu'une seule fonction, dont le comportement (qui peut être assez complexe) est entièrement guidé par les options d'appel de cette fonction.

  4. Declarative beats imperative

    Il est préférable d'avoir une interface déclarative, c'est-à-dire où l'utilisateur décrit ce qu'il veut faire, plutôt qu'impérative, où il décrit comment le faire.

    Getopt::Euclid utilise la documentation du programme pour écrire l'analyseur d'options de ligne de commande.

  5. Preserve the metadata

    On ne devrait jamais devoir répéter deux fois la même chose à un programme. S'il apprend quelque chose à un moment donné, il devrait conserver cette information pour plus tard.

    Config::Std conserve les commentaires des fichiers de configuration qu'il lit pour pouvoir les laisser en place lors de la mise à jour du fichier.

  6. Leverage the familiar

    L'interface la plus simple est celle que les utilisateurs connaissent déjà.

    Log::StdLog permet d'utiliser l'interface de print() pour gérer divers niveaux de log.

  7. The best code is no code at all

    Le simple fait d'écrire le use devrait suffire à invoquer la magie du module.

    Object::Dumper permet de faire un print() d'un objet complexe et de voir non pas son adresse, mais un dump de l'objet.

La présentation a beaucoup influencé mes deux voisins... Aaron Crane a écrit la première version de Acme::InsultingErrors, qui ajoute la chaîne ", you idiot" (avec une liste de synonymes digne d'Acme::MetaSyntactic) à la fin des messages d'erreur et avertissements, tandis que Jouke Visser a modifié son dernier module, OA, pour qu'il utilise Perl6::Export::Attrs au lieu de Perl6::Export, comme Damian le recommande désormais.

Jour 1 - Bienvenue !

La véritable Open Source Convention commence ce mardi avec les keynotes, pendant lesquelles nous verrons se succéder :

Scene setting and Introduction - Nathan Torkington, Allison Randal et Nikolaj Nyholm

En fait, seuls Nat et Allison nous accueillent : Nikolaj Nyholm, le troisième program chair est absent pour cause de naissance de son fils.

Nat nous explique le business model d'O'Reilly : en fait, O'Reilly vend des « mouvements populaires ». Selon ce business model, il s'agit d'identifier ces mouvements, de trouver ce dont les gens ont besoin en rapport avec ces mouvements et de leur vendre.

Les gens ont besoin d'apprendre, de se documenter, de se rencontrer. Les livres et les conférences ne sont que des effets secondaires de la popularité de ces mouvements, grâce auxquels la société O'Reilly fait de l'argent.

L'Open Source fait partie de ces « mouvements populaires ». Il existe d'autres mouvements qui s'appuient sur les mêmes principes.

En plus du logiciel, on peut « open sourcer » la culture, l'industrie, la démocratie, l'économie. Ainsi Creative Commons « open source » la culture, les makers (les bidouilleurs inspirés de MAKE Magazine) « open sourcent » les objets, TheyWorkForYou.com « open sourcent » la démocratie.

Au-delà du logiciel, de la culture, de l'industrie, le but de cette conférence est savoir ce que nous pouvons chacun apprendre les uns des autres.

Open Source 2.0 - Tim O'Reilly

Si le titre donnait l'impression d'une variation sur le buzzword à la mode lancé par Tim O'Reilly lui-même (le web 2.0), ce n'est pas le cas : Tim présente ici ses inquiétudes et ses prédictions pour l'avenir.

Il rappelle ce que fait O'Reilly : changer le monde en diffusant le savoir des innovateurs. Avec les bloggeurs du « radar » O'Reilly, ils essayent de détecter ce qui change.

Sa présentation comporte plusieurs grands points :

  1. Le web 2.0, c'est une architecture de participation, au-delà du développement logiciel
    Tim O'Reilly
    Tim O'Reilly
    Photo James Duncan Davidson/O'Reilly Media

    Un projet open source s'appuie sur une architecture de participation. Cependant, un projet comme Wikipedia, qui ne concerne pas un logiciel mais le savoir, a la même architecture.

    Le web 2.0, ce sont des systèmes qui exploitent les effets de réseau pour s'améliorer avec le nombre de leurs utilisateurs. Idéalement, cela se fait par une architecture dans laquelle les gens construisent le système en s'occupant simplement de leur propres centres d'intérêt.

    Le web 2.0, ce sont donc des logiciels dont les utilisateurs sont des composants. Il utilise les mêmes leviers que les projets open source, mais il y a aussi de nombreux défis. En particulier le fait que le logiciel n'a plus besoin d'être diffusé : on utilise le web.

    Ce qui fait que :

  2. Les licences open source sont obsolètes

    Google peut typiquement utiliser n'importe quel logiciel ou licence, mais ils ne donnent jamais du logiciel en retour, seulement du service.

    Pour Richard Stallman, il n'y a pas de problème tant que l'ordinateur qui fait marcher le logiciel n'est pas celui de l'utilisateur.

    Selon Tim, il faut réinventer l'Open Source pour un monde dans lequel le logiciel est exécuté et pas diffusé, où les applications s'appuient sur de gigantesques bases de données plus que sur du code et où ces applications sont mises à jour en permanence.

    Sa question est donc : quelles sont les licences adaptées pour les web services ? Que serait un web service Open (Source) ?

    Il est intéressant de constater que les services propriétaires donnent le framework. Ainsi, Basecamp (http://www.basecamphq.com/) est l'application produite par 37signals (http://www.37signals.com/). Le framework utilisé pour produire le site est Ruby On Rails, qu'ils ont rendu disponible avec une licence Open Source.

    Dabble DB (http://dabbledb.com/) s'appuie sur Seaside (http://www.seaside.st/), un framework en SmallTalk, lui aussi disponible avec une licence libre.

    En résumé, les applications propriétaires donnent des API ouvertes, et les services propriétaires donnent des frameworks ouverts.

  3. La compétition n'est pas symétrique

    Craigslist (http://www.craigslist.org/) n'a que 18 employés, et c'est pourtant l'un des sites les plus visités sur le web.

  4. L'hébergement est un avantage

    Ainsi que l'a dit Debra Chrapaty, vice-présidente de Windows Live Operations : « In the future, being on someones's platform will mean being hosted on their infrastructure. » (Dans l'avenir, utiliser la plate-forme de quelqu'un signifiera être hébergé sur leur infrastructure).

    Le mouvement Open Source sera donc confronté à un problème d'infrastructure.

    Il faudra donc s'intéresser de plus près aux outils qui facilitent la gestion d'infrastructures de grandes dimensions : Nagios (une solution de monitoring, http://nagios.org/), memcached (un cache mémoire distribué, http://www.danga.com/memcached/), Hadoop (un système de fichiers distribué en Java, http://lucene.apache.org/hadoop/), OpenID (un système d'authentification ouvert, décentralisé et gratuit, http://openid.net/).

  5. Qui possède les données ?

    Si vous ne pouvez pas déplacer vos données, c'est qu'elles ne sont pas à vous.

    Il renvoie en particulier aux sites de http://movemydata.org/ http://microformats.org/ et bien sûr http://creativecommons.org/.

Ainsi, nous ne savons pas encore :

En guise de conclusion, Tim cite Ray Kurzweil : I'm an inventor, and I started looking at long-term trends because an invention has to make sense in the world in which it was finished, not the world in which it started. (Je suis un inventeur, et j'ai commencé à m'intéresser aux tendances à long terme parce qu'une invention doit avoir une signification dans le monde où elle sera terminée, pas dans le monde où elle a été commencée.)

Attention, Please! Who Are We? - Tor Nørretranders

Tor Nørretranders
Tor Nørretranders
Photo James Duncan Davidson/O'Reilly Media

Tor commence sa keynote en parlant du jeu de l'ultimatum. Étant donné une somme d'argent et deux joueurs, le premier joueur propose un partage. Si le second l'accepte, le partage est fait selon les exigences du premier, sinon personne ne reçoit d'argent.

À partir de cet exemple de coopération forcée, Tor explique que c'est la coopération qui nous fait « briller ». D'autres expériences montrent que ce n'est pas le cas de la coopération avec un ordinateur. Nous avons donc besoin d'êtres humains pour coopérer. La question serait donc « pourquoi les êtres humains veulent-ils coopérer entre eux  ? ».

Il commence par mentionner Darwin, et résume sa théorie de l'évolution à « la vie, c'est un problème de survie ». Pour l'anecdote, Tor rappelle que Darwin était exaspéré par les paons. Qu'un animal se rende aussi voyant (pour ses prédateurs) ne rentre pas du tout dans la théorie de l'évolution vue comme « la survie du plus adapté » !

Attirer l'attention peut vous procurer des rapport sexuels, mais c'est aussi dangereux (au moins pour le paon). Selon la théorie qu'explique Tor, si le paon a une ornementation aussi voyante, ce serait en vertu du principe du handicap : pour montrer qu'on est riche, on gaspille ; pour montrer qu'on est fort, on prend des risques.

Les êtres humains montrent qu'ils ont de vastes ressources en faisant montre d'altruisme, en étant généreux, en prenant des risques. Le business model serait : oser prendre des risques et partager nos richesses attire l'attention, ce qui a pour retombées le sexe, le travail et la reconnaissance. Le sexe serait à l'origine de tout ce qui est noble !

Tor Nørretranders est probablement l'intervenant qui a eu le plus de succès. Suite à cette keynote, il a d'ailleurs donné une autre présentation (hors programme) qui fait fait salle plus que comble, avec des auditeurs assis par terre sur plusieurs rangs.

Le livre de Tor Nørretranders et Jonathan Sydenham The Generous Man: How Helping Others Is the Sexiest Thing You Can Do, n'a pas été traduit en français d'après mes recherches.

Les premières sessions

J'ai manqué les sessions suivantes, trop occupé par mes retrouvailles avec quelques membres de la communauté Perl et par une interview de Tim O'Reilly réalisée conjointement avec un journaliste du magazine IT Professional.

Si j'y avais assisté, j'aurais pu vous parler de Drupal, des microformats, de Google code, d'évangélisation Open Source, etc. (voir l'emploi du temps)

J'ai tout de même pu assister à la fin de la session Gender in Open-Source, par Bernard Krieger. Il présentait ses conclusions sur une étude basée sur un sondage concernant le rôle des femmes dans les projets Open Source. Hélas, les questions posées dans le sondage, sa propre analyse et même sa manière de gérer l'échange avec le public très féminisé (des femmes qui étaient très conscientes de leur position dans la communauté) montraient combien il était lui-même englué dans ses propres stéréotypes et préjugés. Pour rattraper, je vous donne quelques sites sur le sujet :

Je vous renvoie également à l'article Développeuses en liberté d'Isabelle Collet dans ce même numéro.

Open Data AWOL - Steve Coast

L'après-midi commence avec une nouvelle série de keynotes.

Steve Coast, d'OpenStreetMap (http://www.openstreetmap.org/) expose le problème du manque de données libres, pour tout ce qui va des données géographiques jusqu'aux annuaires téléphoniques.

Avec l'avènement du Web 2.0, ceci pose de plus en plus de problèmes aux petites sociétés qui se montent, car elles ne disposent pas des données utilisables librement pour leurs sites.

Journalism via Computer Programming - Adrian Holovaty

Cette seconde keynote présente l'idée de journalisme assisté par ordinateur. Il s'agit de reprendre les données brutes utilisées par les journalistes traditionnels, et de les rendre disponibles pour tous. Cela permet des utilisations variées et créatives, comme :

Imaginez les feeds RSS que cela rend possible !

Bref, l'idée est de récupérer les données brutes, et de faire des trucs cools avec. Si l'Open Source c'est de rendre le code disponible, alors l'Open Journalism, c'est de rendre les données disponibles. Dans les deux cas, on facilite la compréhension par la transparence et on encourage les travaux dérivés.

Quelques sessions de l'après-midi

Parmi les nombreuses sessions de l'après-midi, Google était assez représenté avec The Google Data API, par Frank Mantek, Rolling Your Own Google Maps, par Scott Davis et une session Google and Open Source dans la salle dédiée aux sponsors.

Dans An Economic Interpretation of the Evolution of the Free/Open Source Software, Lorenzo Benussi présente l'enchaînement des différentes époques du développement de la communauté FLOSS. En partant du New thinking de Vanevar Bush (1945), et du projet MAC (Mathematics and Computation) du MIT, en passant par Unix, l'ordinateur personnel, le projet GNU pour arriver à Linux, il montre l'importance de la communication comme moteur et comme moyen du développement du Free/Libre/Open Source Software.

Dans Making It Work: How to Build a Successful Open Source Project, Louis Suarez-Potts présente comme réussir son projet Open Source. Fort de son expérience personnelle avec OpenOffice.org, il aborde de nombreuses questions, dont la différence entre les projets « organiques » (qui grossissent à partir du travail de quelques développeurs) et les projets sponsorisés (par des entreprises) ; le problème de la licence et du copyright (on peut toujours changer la licence, mais il faut bien s'assurer du copyright, sinon chaque contributeur conserve le copyright des bouts de code auxquels il a contribué) ; l'intérêt de créer une gratification immédiate (par exemple avec un wiki) ; le besoin de transparence sur les procédures de revue, d'acceptation ou de rejet du code des contributeurs ; le besoin de communication, de marketing, de promotion ; la nécessité de créer une communauté.

Selon lui, pour réussir son projet Open Source, il faut :

Il conclut en expliquant ce que fait OOo désormais : faciliter les contributions, utiliser les extensions (comme FireFox), avoir des développeurs régionaux, communiquer en direction des entreprises, des écoles, des gouvernements, des individus.

Au final, le but est de permettre à tout le monde de contribuer à OpenOffice.org, par des tests, du code, de nouvelles extensions, des traductions, du graphisme, de la documentation, du soutien enthousiaste (ou en payant une bière aux développeurs).

La journée se termine dans le hall d'exposition, où les sponsors accueillent les participants autour de rafraîchissements pour faire la démonstration de leurs produits et de leur savoir-faire.

Jour 2

La journée commence par une nouvelle sessions de keynotes :

La présentation JavaScript: It's Happening All Over Again! de James A. Duncan et Mark Fowler était sponsorisée par Zimki, une boîte qui vend du service basé sur JavaScript côté serveur. On est dans une logique de plate-forme, comme décrite par Tim O'Reilly au début de ce compte-rendu. Mark et James étant des piliers de la communauté Perl, la salle est pleine de hackers Perl, bien que le sujet soit 100% JavaScript !

Le Drawbot de Bre Pettis
Le Drawbot de Bre Pettis
Photo James Duncan Davidson/O'Reilly Media

Après les dernières présentations, ont lieu les BOF sessions. Je me retrouve donc dans une grande salle avec 5 ou 6 autres personnes pour parler d'Act (http://act.mongueurs.net/), le logiciel de gestion de conférences utilisé depuis près de 3 ans par la communauté Perl européenne. Des utilisateurs (ou développeurs ?) de Pentabarf (http://pentabarf.org/) sont également présents. La liste de fonctionnalités souhaitée se trouve encore augmentée...

La soirée sera occupée par la MAKE Fest où nous verrons les makers invités présenter leur travaux. Parmi les plus intéressants, on peut citer un robot qui dessine au feutre d'après une image en noir et blanc, ou un PC transformé en machine à faire le café.

Jour 3 - C'est déjà fini !

On commence avec les dernières keynotes de cette année :

New Innovation Models, Policy-making and Lobbying - Florian Mueller

Florian Mueller est le fondateur de NoSoftwarePatents.com (http://www.nosoftwarepatents.com/. Il explique qu'un nouveau combat est en cours : les nouveaux modèles d'innovation créent de nouvelles difficultés. En vrac, on peut citer : les brevets logiciels, les nouvelles règles du copyright, le fair use, le DRM, la responsabilité des auteurs de logiciels, des modérateurs de forum, des webmasters.

Il expose aussi quelques réussites du lobbying auprès du parlement européen.

Architecting Babel - Robert "r0ml" Lefkowitz

r0ml vient parler de localisation (au sens de traduction d'application). Il rappelle que la langue la plus parlée au monde est le chinois, et que 90% des gens ne parlent pas anglais.

Avoir le code source d'un logiciel, c'est bien, mais encore faut-il avoir des identificateurs et des commentaires compréhensibles. En fait, pour aller plus loin dans la localisation (et donc l'accès aux logiciels), il explique qu'il ne faut pas se contenter de traduire les applications, il faut aussi traduire le code source : les identificateurs, les commentaires, les mots-clés.

Il réveille les horribles souvenirs des développeurs qui ont eu à manipuler les versions d'Excel dont le langage de macro était traduit (et évidemment incompatible entre deux versions d'Excel dans des langues différentes).

Cette keynote a certainement touché un point sensible, si on en juge par la quantité d'interventions du public.

La dernière demi-journée

Ayant détecté un trou dans l'emploi du temps, des perleurs tuyautés par Nat Torkington ont réussi à récupérer une salle pour une scéance de lightning talks. J'ai eu l'occasion de découvrir un format que je ne connaissait pas, le twenty twenty : il s'agit d'un enchaînement de 20 diapositives de 20 secondes chacune. L'avantage est de libérer le présentateur de son portable.

Piers Cawley explique comment se faire prendre en photo, j'expose les photos compromettantes de YAPC Europe 2005, Dennis Kaarsemaker présente upstart (un remplaçant d'init, voir http://upstart.ubuntu.com/), Suw Charman présente l'Open Rights Group (un genre d'EFF avec moins d'avocats, http://www.openrightsgroup.org/), Ewan Spence nous parle de podcasting (il a d'ailleurs enregistré les lightning talks), Russ Nelson présente un clavier bluetooth adapté à la forme de la main (et utilisable d'une seule main), Damian Conway nous parle de 101 choses qu'il aime dans Perl 6 (101 diapos en 5 minutes !), Gervase Markham parle du phishing et Jesse Vincent (qui a rédigé ses diapos pendant les présentations précédentes) parle de Jifty.

Pour une session improvisée, ce fut plutôt réussi.

Je retrouve ensuite le cours normal de la conférence, et assiste à une présentation plus longue de Damian Conway (The Conway Channel 2006), où présente d'une manière toujours aussi éblouissante deux des modules qu'il a créés cette année : List::Maker (ou comment abuser de <> pour forcer une syntaxe Perl 6 sur Perl 5) et Contextual::Return (qui permet d'écrire des fonctions qui renvoient des valeurs différentes en fonction du contexte dans lequel elles sont employées).

La dernière présentation à laquelle j'ai assisté est celle de Brad Neuberg, qui parle de Douglas Engelbart's HyperScope: Taking Web Collaboration to the Next Level Using Ajax and Dojo.

Douglas Engelbart a inventé beaucoup de choses : la souris, l'hypertexte, l'email, les systèmes fenêtrés. Brad résume cela par cette phrase : « Edison a conçu (designed) la première moitié du XXe siècle, et Engelbart la seconde moitié.

Comment le laboratoire de Stanford où il travaillait a-t-il été aussi prolifique ? Grâce à l'augmentation. Cette idée est présentée dans un article publié par Engelbart en 1962 : Augmenting human intellect.

L'augmentation dans ce cas, ce n'est pas une amélioration à la Matrix, c'est une évolution accélérée. Il s'agit d'accélérer le processus d'amélioration. L'homme a disposé de plusieurs outils pour exercer sa pensée : le langage (depuis 40 000 ans ?), l'écriture (depuis 3 500 à 6 000 ans) et depuis les années 50, l'ordinateur.

Ce ne sont que des outils, et on les maîtrise mieux avec une formation, de l'entraînement et une méthodologie. (S'il n'y a pas de formation, c'est qu'elle est implicite.) L'idée d'Engelbart était de cibler les capacités principales de l'humain et de les améliorer encore.

L'outil pour y arriver était HyperScope. Le projet de Brad Neuberg est une mise à disposition d'HyperScope sur le web, grâce à une application en JavaScript disponibles sur http://hyperscope.org/.

Après le déjeuner, la conférence se termine sur une dernière keynote, par Mark Shuttleworth, fondateur d'Ubuntu, qui présente les obstacles qui attendent l'Open Source.

Bilan

Tim O'Reilly définit le business model de sa société comme étant de « diffuser le savoir des innovateurs à travers ses livres, services en ligne, magazines et conférences ». À en juger par le nombre et la diversité des conférences dans lesquelles O'Reilly Media est impliquée pour 2007, c'est clairement un marché sur lequel la société s'investit de plus en plus : de 4 conférences annuelles entre 2001 et 2004, on passe à 6 en 2005, 7 en 2006 et O'Reilly liste déjà 11 conférences sur http://conferences.oreillynet.com/ pour 2007.

Les sujets vont d'ailleurs bien au delà de l'informatique :

En attendant, si la tendance d'OSCON Europe à descendre vers le sud continue (Amsterdam en 2005, Bruxelles en 2006), on peut raisonnablement espérer voir OSCON Europe à Paris en 2007. :-)

[IE7, par Dean Edwards] [Validation du HTML] [Validation du CSS]