Bryght est née d'une idée simple : et si nous pouvions prendre un cadriciel puissant et complexe comme Drupal et le rendre accessible à tous... avec ou sans expertise technique? Cette idée était étroitement liée à notre conviction qu'un jour, les pages HTML statiques d'Internet seront remplacées par des pages dynamiques. Et pages dynamiques veut dire applications Web.
Nous avons vu cela se produire en bonne partie ces dernières années. À nos débuts, Drupal passait de la version 4.4 à la 4.5. Le multisite n'était qu'une lueur dans l'œil des gens, et le concept de profils d'installation n'existait pas encore. Bryght a travaillé sur le cœur de Drupal pour y intégrer d'emblée la capacité multisite : du jour au lendemain, c'était un bogue si un module ne fonctionnait pas dans un environnement multisite.
Drupal en tant que cadriciel était alors dans un tout autre état. Les développeurs tombaient constamment sur des cas où le code du cœur n'avait pas assez de « hooks et d'interfaces » pour tout remplacer proprement. Nous avons fini par bâtir autour de Drupal une série d'outils et de démons pour permettre l'hébergement de masse. Cet outil s'appelle HostMaster, et c'est la réponse de Bryght à l'hébergement de masse de Drupal. Il est construit autour de Python et de PostgreSQL, et intègre le concept de « profils d'installation » depuis environ deux ans. Au départ, nous rêvions peut-être de vendre des licences ou de tirer autrement de l'argent directement de ce code. Mais en réalité, ce concept est étranger à nos convictions en matière de logiciel libre : les bits n'ont pas d'importance. Nous avons finalement placé HostMaster sous licence GPL et l'avons rendu accessible à https://svn.bryght.com/hostmaster (oui, il faut encore demander un compte).
Mise à jour : J'ai dû republier ce billet et réécrire cette partie à la fin (ne demandez pas...). Cela a l'avantage de me permettre de renvoyer vers Marc Canter : on dira ce qu'on voudra de Marc, il pense en mode « réseau de réseaux » depuis des années et essaie de nous amener à rattraper sa réflexion.
Avance rapide jusqu'à la veille de 2007 : le concept de multisite et d'hébergement de masse est partout. Les gens de Wikia réfléchissent à l'hébergement de masse de Drupal, et il ne se passe pas une semaine sans que nous entendions parler d'autres projets qui envisagent diverses formes de sites multiples. Nous entrons dans l'ère des réseaux de réseaux.
Drupal est aujourd'hui beaucoup plus un cadriciel, et il est maintenant prêt à piloter lui-même ce type de réseau. Nous envisageons de réécrire certains de nos outils d'hébergement de masse directement sur Drupal. Oui, c'est à toi que je pense, D'Arcy Norman, et à ton Provisionator – sauf qu'au lieu de fonctionner dans un seul environnement d'hébergement mutualisé, nous pouvons envisager de maintenir des sites de façon distribuée : pensez XML-RPC et opérations entre sites, à partir d'une interface de type tableau de bord.
Bien sûr, la prochaine étape, ce sont les profils d'utilisateur partagés, les personas et l'identité. Drupal dispose de l'authentification distribuée, et nous avons bâti le partage de profils par-dessus il y a plus de deux ans, sous la forme des modules FOAF et SXIP, mais la norme émergente pour l'identité centrée sur l'utilisateur est OpenID, surtout avec la v2 qui inclut l'échange d'attributs issu du concept original de SXIP. Mais James Walker, auteur des deux modules précédents, ne s'est pas tourné les pouces : en s'appuyant sur le travail de Rowan Kerr, nous aurons bientôt une solution complète de serveur et de client OpenID, qui permettra facilement à Drupal d'être le pivot ou une feuille d'un réseau social distribué.
Les hooks et les interfaces sont primordiaux : la norme pour le volet identité, sans être parfaite, se consolide. RSS est un moyen de transport standard pour faire circuler des données semi-structurées. XML-RPC peut servir à multiplier par programmation les communications entre sites. XMPP émerge comme norme pour l'échange de messages en temps réel. Toutes les pièces se mettent en place.