Je vais dans un premier temps discuter de la partie plateforme technique et plus particulièrement du code. La plupart des succès du web 2.0 (flickr, facebook, basecamp, googlemaps) sont basés sur un mix toolkit et code propriétaire. Certes, elles fournissent des APIs qui permettent d'accéder aux données qu'elles détiennent et d'utiliser le service; mais elles ne permettent pas de modifier ce service par exemple. Le code dans ces cas n'est pas libre. On pourra rétorquer que yahoo, google, et autres, distribuent des toolkit sous des licences libres comme le Google Web Toolkit (GWT) et le Yahoo User Interface (YUI) Library. Oui c'est orienté RIA et donc plutôt côté client (YUI est une lib JavaScript, GWT en revanche est en Java donc côté serveur). C'est bien, mais ce sont des toolkits pas des applications complètes !

Pourquoi des applications web libres ?

A l'opposé prenons Dotclear ou Mediawiki. Ce sont des applications libres. Dans le cas de Dotclear c'est une application développée indépendamment d'un service, dans le cas de Mediawiki, c'est le moteur qui supporte le projet Wikipedia. Pour comprendre l'avenir des applications libres, il faut d'abord comprendre pourquoi elles existent. Bien sûr, ce sera difficile d'y répondre en quelques lignes, et je ne peux parler à la place des milliers de développeurs et contributeurs. Je pense que les applications libres comme toute application naissent pour répondre à un besoin. Là où elles sont différentes des applications propriétaires c'est dans l'intention de leurs auteurs. Créer une application libre c'est permettre à d'autres personnes de la comprendre, de la modifier et également de faire autre chose avec, puis de la redistribuer. Créer une application propriétaire c'est vouloir tirer un avantage concurrentiel de ses secrets industriels, de son code. Pour le revendre ou juste pour empêcher d'autres personnes de partager la même base par peur qu'elles ne fassent mieux.

L'ouverture est en partie ce qui rend une application pérenne. Si les mainteneurs d'une application libre ne peuvent plus s'en occuper, d'autres développeurs peuvent prendre la relève, et soit reprendre le projet, soit en faire un fork. Dans certains cas, les fork s'opèrent spontanément en réponse aux divergences dans le développement ou la stratégie à adopter. Si on regarde cela d'un point de vue économique, cela encourage la concurrence et l'innovation. C'est ce qui est fait du code et sa mise en oeuvre qui donne un avantage à un fournisseur de service. Cependant, les applications libres occupent peu le devant de la scène depuis quelques temps. Si la base est souvent du LAMP ou du J2EE libre, le code de l'application elle-même est propriétaire comme on l'a vu précédemment.

Dans ce sens, l'avenir des applications web libres, s'il ne semble pas en péril - je vois mal wordpress, dotclear ou mediawiki être abandonnés vu leur utilisation et les communautés qui gravitent autour - il parait en revanche un peu en retrait des applications propriétaires maison de start-up ou géants du web.

Pourquoi LAMP s'est imposé ?

PHP

En citant ces trois projets (qui me sont venus en tête sans réfléchir et sans intention particulière), on se rend rapidement compte d'une chose. Ils sont écrits en PHP. Pourquoi ? Qu'est-ce qui a fait le succès de PHP ? A présent, le langage intègre des constructions de langage moderne, mais pour ceux qui se souviennent de PHP3, c'était loin d'être la panacée ! Avant ça, on avait des cgi en Perl, voire en C et de l'asp.

Premier ingrédient du succès de PHP, il tournait sur de l'Apache (en module avec mod_php ou en cgi). C'était donc gratuit, libre et répandu. Deuxième ingrédient, c'était léger et rapide à installer. C'est sûrement un des points qui encouragea les hébergeurs et les FAI à proposer de l'hébergement gratuit ou pas cher de pages persos dynamique avec PHP. Troisième ingrédient, la syntaxe était proche du C et le langage simple. Ensuite la communauté qui s'est constituée autour du langage a apportée des libs qui ont rendu le développement encore plus facile et rapide.

L'hébergement

Remettons nous à la place d'un dévelopeur web de l'époque. Quelle est son premier problème avant même de penser à coder ? Trouver un hébergement. Il ne sert à rien d'écrire du code qu'on ne pourra pas exécuter quelque part. Il faut donc qu'il trouve un langage qui soit proposé dans des hébergements gratuits ou pas chers. Bon là on tombe dans le problème de l'oeuf et de la poule. Les hébergeurs se sont sûrement posés la question dans l'autre sens : comment fournir à mes clients un langage dynamique pour leurs pages persos ? Déjà pourquoi fournir de l'hébergement gratuit. Je ne sais si c'est totalement vrai, mais dans le cas de Free il semblerait que c'était pour peser plus dans les accords de peering. Ce qui est crédible. Je pense qu'il y avait quand même un peu plus derrière. C'est peut-être ce qui a convaincu les managers au final.

Les framework

Maintenant, les framework de développement web sont à la mode. On entends partout parler de Ruby on Rails, Django, Struts, Symfony. Les hébergements commencent à arrivés. On avait déjà le dédié pas cher (lost oasis - qui se souvient des openbrick ? ;) - puis dedibox) et les serveurs virtualisés. Cela permet de faire tourner autre chose que du PHP (avec parfois une configuration contraignante). Avec la généralisation de l'adsl (ça commence à remonter maintenant !), il est devenu facile d'héberger son site à la maison.

Disposer du code source. Pour qui ? Pourquoi ?

Pourquoi je parle de tout ça (un peu comme un ancien alors que je ne suis pas si vieux que ça ;) ) ? Parce que ce qui différencie fondamentalement une application web libre, d'une application web propriétaire, c'est la disponibilité du code. Pour une utilisation personnelle, il faut donc pouvoir "installer" ce code quelque part. Les nouvelles offres d'hébergement comme Media Temple, sont super intéressantes dans ce sens car elles permettent de proposer des environnements variés facilement et pas chers. Cela permet d'utiliser une application web libre pour ses besoins.

Et les entreprises ?

Bien sûr, les applications web sont utilisées en dehors des besoins persos. On retrouve les mêmes avantages que les autres types d'applications libres :

  • communauté : relecture du code par des tiers, contributions, support communautaire, réactivité
  • utilisation dans d'autres situations que celles prévues initialement (et donc ajout de fonctionnalités par exemple)
  • pérennité
  • transparence
  • gratuité

Certaines entreprises sont aussi très attachées aux valeurs éthiques du libre. Donc de ce point de vue là, l'avenir se présente plutôt bien.

Par contre que se passerait-il si des cabinets de conseil, et dans la continuité de l'externalisation, poussaient les entreprises à faire des mashup plutôt que d'utiliser des applications libres ? Cela me semble peut probable dans beaucoup de situations. Pour la simple raison que mashup implique données stockées un peu partout et sans maîtrise. Pour des données personnelles, si on l'accepte, ça peut passer. Pour des besoins professionnels, ça devient tendu !

To be continued...