Résumé

  • Apache est d’abord né d’un travail d’entretien déjà entrepris séparément par des webmestres sur NCSA httpd 1.3. Une liste de diffusion, un espace partagé et des essais sur leurs propres serveurs ont transformé ces correctifs en version commune.
  • En 1995, NCSA n’a pas disparu : son équipe a repris le développement et échangé des corrections avec Apache, tandis que le groupe Apache passait de l’assemblage de correctifs à l’architecture modulaire Shambhala.

Des réparations locales, une version partageable

Au début de 1995, NCSA httpd était très répandu sur le Web, mais son développement avait ralenti après le départ de Rob McCool de NCSA, au milieu de 1994. Les exploitants n’attendaient pas tous qu’un fournisseur reprenne le travail. Plusieurs webmestres avaient déjà écrit leurs propres extensions et corrigé des défauts. Le problème était devenu pratique : comment savoir ce qui avait changé, le comparer à la version de base et transmettre une combinaison que d’autres puissent tester ?

L’histoire officielle du projet situe la première coordination dans des échanges privés par courrier électronique. Brian Behlendorf et Cliff Skolnick ont ensuite organisé une liste, un espace d’information partagé et des comptes de développement sur une machine de la région de la baie de San Francisco. HotWired a fourni la bande passante. À la fin de février, huit contributeurs formaient le noyau du groupe Apache. Ces ressources ne rendaient pas les serveurs identiques. Elles donnaient aux personnes qui les exploitaient un lieu et un support communs pour examiner leurs changements.

Le groupe a gardé NCSA httpd 1.3 comme base, rassemblé des corrections publiées et des améliorations jugées utiles, puis testé l’ensemble sur les serveurs des contributeurs. Apache 0.6.2 a été publié en avril 1995. Dans son annonce du 27 avril, Randy Terbush présentait le logiciel comme un serveur public fondé sur des correctifs de NCSA 1.3. Il citait notamment la négociation de contenu, plusieurs noms de domaine, des réponses d’erreur personnalisées, l’envoi de fichiers « en l’état », une meilleure conformité aux spécifications et l’authentification DBM.

Cette annonce contemporaine nommait aussi des utilisateurs précoces — HotWired, le MIT AI Lab, Organic, Hyperreal et d’autres — ainsi que plusieurs systèmes Unix sur lesquels le serveur avait été essayé. Elle précisait qu’il s’agissait d’une version bêta et qu’elle contenait probablement encore des bogues. La publication commune ne supprimait donc pas le risque d’exploitation : elle rendait une combinaison de changements assez visible pour que d’autres puissent l’évaluer.

NCSA poursuivait sa propre route

On raconte parfois Apache comme le successeur apparu après l’abandon complet de NCSA. La chronologie du projet est plus nuancée. Le récit rétrospectif d’Apache indique que NCSA a relancé son développement pendant la même période. Brandon Long et Beth Frank, de l’équipe serveur de NCSA, ont rejoint la liste en mars comme membres honoraires afin que les deux projets puissent échanger idées et corrections. Une discussion Usenet d’octobre 1995 évoque également une branche NCSA en développement et des fonctions reprises d’Apache.

Les projets se disputaient des installations, mais leur relation technique n’était pas une séparation nette. Pour un opérateur, la question immédiate était plutôt de savoir quelle version fonctionnait sur sa machine, quels changements elle apportait et s’il pouvait revenir en arrière. Un correctif pouvait être examiné sans mise à niveau générale. Une version rendait le changement reproductible. La décision de l’installer restait locale.

Ce modèle avait ses limites. La combinaison de correctifs provenant de serveurs différents pouvait créer des incompatibilités. Il fallait vérifier davantage de plateformes, documenter les changements et répondre à un nombre croissant d’utilisateurs. Le projet reconnaît lui-même que 0.6.2 avait rencontré un succès rapide, mais que la base de code devait être remaniée. Le logiciel libre n’abolissait pas le coût de maintenance : il permettait de répartir le travail, puis rendait nécessaire une meilleure coordination.

Le correctif commun devient une architecture

En mai et juin, le groupe développait les fonctions de la série 0.7, comme les processus enfants précréés, tout en soutenant les utilisateurs. Robert Thau concevait parallèlement Shambhala : une architecture modulaire avec une API, une allocation mémoire par pools et un modèle adaptatif de processus précréés. Le groupe a adopté cette base en juillet. Apache 0.8.8 est arrivé en août ; après des essais bêta, des portages et une nouvelle documentation, Apache 1.0 a été publié le 1er décembre 1995.

Le passage est important. Au départ, le travail partagé portait sur les modifications à assembler autour d’un serveur existant. Shambhala changeait la structure dans laquelle les modifications futures pouvaient prendre place. Les modules faisaient de l’extensibilité une propriété du serveur, au lieu de laisser chaque nouveau besoin se résoudre uniquement par une nouvelle série de différences.

Une telle architecture redistribue aussi les contraintes. Des frontières modulaires peuvent isoler certaines extensions et réduire les perturbations du cœur ; elles exigent en retour des interfaces compréhensibles, des tests de compatibilité et une responsabilité durable. Le passage à une architecture n’a pas rendu l’entretien automatique. Il a déplacé une partie du problème vers les API, les modules et les contrats de compatibilité. Les exploitants continuaient à décider quelle version faire tourner, tandis que NCSA maintenait sa propre lignée.

L’adoption se lit dans les machines

Les éléments les plus nets sur l’ampleur d’Apache apparaissent en 1996. Le billet de Mike Prettejohn pour l’enquête Netcraft d’août compare 18 957 hôtes répondants en août 1995 à 342 081 un an plus tard. Dans l’échantillon de 1996, Apache représente 35 %, devant NCSA à 18 %. Netcraft avertit que l’augmentation reflète à la fois la croissance du Web et une meilleure capacité à découvrir des sites. Ces résultats portent sur des hôtes répondants classés par logiciel serveur : ils ne comptent ni entreprises uniques, ni personnes, ni visites, et ne démontrent pas à eux seuls la cause du succès.

Ils montrent néanmoins une étape que le seul récit de la publication ne peut établir : des opérateurs choisissaient Apache à grande échelle. La séquence fut concrète — une base connue, des différences comparables, des essais locaux, une version commune, puis un serveur repensé. Sa légitimité venait de changements que l’on pouvait faire tourner et vérifier. Les annonces et la structure collective rendaient l’adoption possible, mais ne la remplaçaient pas.

Sources et limites

Le récit du projet Apache est rétrospectif. L’annonce d’avril 1995 et le relevé Netcraft de 1996 sont contemporains. Les archives originales de la liste de développement et des journaux d’installation n’ont pas été retrouvés pour cette enquête. Les chiffres de Netcraft restent donc un échantillon borné et ne prouvent pas que le mode de maintenance d’Apache a, seul, transformé le marché.

Sources citées