Tout cela dépend des plates-formes

Bien que fervent partisan de l'approche Open Source en ce qui concerne les développements de logiciels, je reconnais volontiers que cette approche ne profitera pas toujours aux parties en présence. Elle exige des efforts, et les retours sur investissement ne sont jamais garantis. Une analyse correcte passe par la détermination des objectifs à long terme de l'entreprise et de ses points forts du moment.

Commençons par un examen des "Application Programming Interfaces" (API) [1] des plates-formes et des conventions. Pour les besoins de cet essai, je m'attarderai sur les API (telles que celle du serveur Apache pour la mise au point de modules), les protocoles régissant l'activité en ligne (par exemple HTTP), et les « conventions » érigées par les développeurs de systèmes d'exploitation (telles que la façon dont Linux organise son système de fichiers, ou encore dont les serveurs NT sont administrés) et désignerai tout cela par le terme « plate-forme ».

Win32, la collection de fonctions fournies et définies par Microsoft pour tous les développeurs d'applications MS-Windows 95 et NT, est une plate-forme. Si vous désirez développer une application destinée à des utilisateurs de MS-Windows, vous devez utiliser cette API. Si vous essayez, comme IBM le fit une fois avec OS/2, d'écrire un système d'exploitation qui puisse faire fonctionner des programmes mis au point pour Microsoft Windows, vous devez intégrer l'API Win32 dans son intégralité, afin d'être en mesure de l'exploiter.

De la même manière la Common Gateway Interface (ou CGI) est une plate-forme. Les spécifications CGI permettent aux développeurs d'un serveur Web d'écrire des scripts et des programmes qui fonctionneront avec n'importe quel serveur Web. CGI est beaucoup plus simple que Win32 et bien sûr permet beaucoup moins, mais son existence était importante pour le marché des serveurs Web parce qu'il permet aux développeurs d'applications d'écrire un code portable, des programmes qui fonctionnent avec n'importe quel serveur Web. Une différence capitale entre CGI et Win32, outre leurs niveaux de complexité, est que nulle entité ne possède les spécifications de CGI, donc que tous les principaux serveurs Web la proposaient afin de pouvoir exécuter n'importe quel script CGI. C'est seulement après plusieurs années d'utilisation qu'il fut envisagé de définir la spécification CGI par un document d'Appel à commentaires (RFC) publié par l'Internet Engineering Task Force[2].

Une plate-forme est ce qui définit de façon précise un quelconque morceau de logiciel, que ce soit un navigateur comme Netscape ou bien un serveur Web comme Apache. Les plates-formes permettent de construire ou d'utiliser un morceau de logiciel par-dessus un autre, et elles ne sont pas seulement essentielles pour l'Internet, où des plates-formes usuelles comme HTTP et TCP/IP facilitent vraiment la progression très rapide de l'Internet, mais sont aussi en train de devenir de plus en plus déterminantes lors de la phase de conception d'un environnement informatique, dans le cas d'un serveur comme dans celui d'une machine réservée à l'utilisateur.

Dans le cadre du projet Apache, nous avons eu la chance de développer d'emblée une API interne qui nous permette de distinguer d'une part les fonctionnalités centrales du serveur (chargé de gérer les connexions TCP, la coordination des sous-processus, et la gestion des requêtes HTTP de base), et, d'autre part, presque toutes les fonctionnalités de haut niveau comme le login, les modules CGI, les requêtes SSI (serveur side include), la configuration des paramètres de sécurité, etc. La richesse de cette API nous a aussi permis de mettre en place d'autres fonctionnalités importantes telles que mod_perl (un module d'Apache qui transforme le serveur Web en interpréteur Perl) et le mod_jserv (qui met en place l'API pour applets Java) afin de séparer les groupes de développeurs actifs. Le noyau du groupe de développement ne redouta donc pas de devoir non seulement maintenir et améliorer le cœur du serveur mais aussi construire un « monstre » destiné à servir et recueillir les fruits de ces efforts intensifs.

Il existe des entreprises construites sur le modèle des plates-formes logicielles propriétaires. Elles peuvent tarifer tout usage de cette plate-forme sur la base d'une installation classique du logiciel, sur celle d'un paiement par utilisation, ou peut-être encore selon un autre modèle. Un copyright protège certaines d'entre elles, d'autres sont rendues opaques par l'absence de description rédigée pour le client ; d'autres encore évoluent si vite, parfois pour des raisons autres que techniques, que ceux qui tentent de les développer ne parviennent pas à suivre la cadence et semblent « à la traîne » sur le plan technique même si le problème ne relève pas de la programmation.

Un tel modèle commercial, bénéfique même à court terme pour l'entreprise qui possède la plate-forme, agit contre les intérêts de toutes les autres sociétés et ralentit le progrès technique. Des concurrents demeureront incapables de profiter de leurs compétences ou tarifs très étudiés parce qu'ils n'ont pas accès à la plate-forme. D'un autre point de vue, le consommateur peut être dépendant d'une plate-forme et, lorsque les prix augmentent, se trouver forcé de décider entre payer un peu plus sur le court terme pour la plate-forme ou bien dépenser beaucoup d'argent afin d'adopter une plate-forme plus viable.

Les ordinateurs et l'automatisation sont devenus si interdépendants et si essentiels pour l'entreprise qu'un responsable sensé ne doit pas confier à un seul fournisseur l'essentiel de son environnement. La possibilité de choisir un intervenant ne signifie pas seulement bénéficier du libre arbitre si certaines options sont trop coûteuses, et le coût d'un changement de plate-forme revêt à ce titre une importance capitale. Il peut être réduit si le logiciel n'est pas lié à la plate-forme. Les consommateurs gagnent donc à toujours exiger que le logiciel déployé soit adossé à une plate-forme non propriétaire.

C'est difficile à concevoir parce que les courbes rendant compte de l'offre et de la demande n'ont de sens que tant que les produits à vendre ont un coût facilement évaluable. Par exemple lorsque la fabrication de dix exemplaires d'un produit est à peu près dix fois plus onéreuse que celle d'un seul. Personne n'aurait pu prévoir l'extraordinaire économie d'échelle dont profitent les éditeurs de logiciels commerciaux, l'absence de corrélation directe entre l'effort requis pour produire un logiciel et le nombre de personnes qui peuvent l'acheter et l'utiliser.

Une personne ou un groupe qui produit des logiciels libres et qui crée un protocole fondamental ou une API est, à long terme, plus important pour la santé de cette plate-forme que deux ou trois créations indépendantes mais non libres. Pourquoi cela ? Parce qu'un concurrent peut acheter le produit commercial afin de le retirer du marché, réduisant à néant l'indépendance conférée aux utilisateurs par l'ouverture du logiciel. Cela peut aussi servir en tant que cadre académique ou référentiel de comparaison des réalisations et des comportements.

Des organisations, par exemple l'IETF ou le W3C, constituent un forum de développement de standards ouverts, et œuvrent de façon quasi parfaite. Elles publient des documents généralement appréciés exposant comment les composants de l'Internet doivent interagir mais ne peuvent garantir le succès à long terme d'un standard donné, ni donc de sa pénétration. Ces organisations ne disposent d'aucun moyen d'imposer à leurs membres de créer des logiciels adossés aux protocoles ainsi définis. Le seul recours, parfois, consiste à fonder un groupe de travail capable de démontrer la supériorité de l'approche préconisée.

Par exemple, en décembre 1996, AOL a modifié de façon apparemment négligeable son serveur mandataire (proxy), utilisé par ses clients afin d'accéder au Web. Cette « mise à jour » relevait d'une arrière-pensée politique : lorsqu'un utilisateur accédait à un site utilisant un serveur Apache 1.2, à l'époque tout récent et conforme aux spécifications du nouveau protocole HTTP/1.1, on lui souhaitait la bienvenue grâce à ce message précis :

VERSION WEB NON SUPPORTÉE

L'adresse Internet que vous avez demandée n'est pas accessible via AOL. Le site Web demandé est en cause, et non AOL. Le détenteur de ce site utilise un langage HTTP non pris en charge. Si ce message apparaît fréquemment, vous pouvez changer les préférences graphiques pour l'Internet en COMPRESSÉ dans le menu : PRÉFÉRENCES.

Le noyau des développeurs Apache, alarmé, s'est réuni pour analyser la situation. Ils posèrent une question à l'équipe des techniciens d'AOL qui répondit :

Les nouveaux serveurs Web HTTP/1.1 répondent sous forme HTTP/1.1 à des demandes HTTP/1.0 alors qu'ils ne devraient générer que des réponses HTTP/1.0. Nous voulons briser au plus tôt cette vague de comportements incorrects devenant un standard de fait. Nous espérons que les auteurs de ces serveurs Web modifieront leurs logiciels afin qu'il ne génèrent des réponses HTTP/1.1 qu'aux demandes de même nature.

Malheureusement, les ingénieurs d'AOL avaient l'impression erronée que les réponses HTTP/1.1 n'étaient pas compatibles avec les clients HTTP/1.0 ou les mandataires. Ils le sont pourtant. HTTP a été conçu de sorte que la compatibilité ascendante de toutes les révisions mineures d'une version (par exemple la version 1) reste assurée. Mais les spécifications pour HTTP/1.1 sont tellement complexes que sans une lecture complète et détaillée, on aurait pu croire que ce n'était pas le cas, et plus particulièrement avec les documents HTTP/1.1 disponibles à la fin de 1996.

Nous, développeurs d'Apache, devions donc décider soit de faire marche arrière (donner des réponses HTTP/1.0 à des demandes HTTP/1.0), soit de respecter les conventions. Roy Fielding, notre « gardien du HTTP », fut en mesure de nous montrer clairement combien le comportement du logiciel à ce moment était correct et bénéfique ; il y aurait des cas où des clients HTTP/1.0 voudraient migrer vers une conversation HTTP/1.1 en découvrant que ce serveur la prend en charge. Il était aussi important d'indiquer aux mandataires qu'une première requête 1.0 vers un serveur pouvait être suivie d'un échange en 1.1.

Nous décidâmes de camper sur nos positions et de demander à AOL de corriger son logiciel. Nous suspections que la réponse HTTP/1.1 qui posait actuellement un problème à leur logiciel était causée par leur négligence en matière de qualité de la programmation plutôt que par un défaut du protocole. L'expertise étayait notre décision. Apache gérait alors 40% des serveurs Web de l'Internet, et la version 1.2 était déjà fort répandue. Ils devaient donc décider de corriger leurs erreurs de programmation ou bien de déclarer à leurs utilisateurs qu'au moins 20% des sites Web de l'Internet leur seraient interdits. Le 26 décembre, nous avons publié une page Web décrivant la dispute, et diffusé l'information pour justifier notre action, non seulement à nos propres utilisateurs, mais aussi à plusieurs journaux importants tels que C|Net et Wired.

AOL décida de corriger son programme. À peu près au même moment, nous avons annoncé la disponibilité d'une modification du code source d'Apache destinée aux gestionnaires de sites soucieux de contourner le problème d'AOL jusqu'à ce qu'il soit rectifié, une correction qui obligeait le logiciel à fournir une réponse en HTTP/1.0 aux requêtes issues d'AOL. Nous étions résolus à ce qu'elle reste une correction "non officielle", sans suite ni suivi, et qu'elle ne deviendrait pas la configuration par défaut de la distribution officielle.

Plusieurs autres éditeurs de produits HTTP (dont Netscape et Microsoft) proposèrent des logiciels non compatibles avec Apache. Dans la plupart de ces cas, l'éditeur devait choisir entre résoudre ses bogues ou se passer des sites qui deviendraient alors inaccessibles. Dans la plupart des cas il implémentait délibérément le protocole de façon incorrecte sur ses serveurs et ses clients. Son produit fonctionnait alors normalement en milieu homogène (serveurs et clients de même marque), mais au mieux imparfaitement avec un serveur ou un client d'un concurrent. Cela posait des problèmes plus délicats que celui d'AOL, car dans certains cas la majorité des utilisateurs ne rencontre pas de dysfonctionnement patent. Les conséquences à long terme de ces bogues (ou de bogues additionnels augmentant le problème) ne seront perceptibles que lorsqu'il sera trop tard.

Si aucun logiciel libre strictement conforme et très utilisé tel qu'Apache n'avait existé, les incompatibilités de ce genre auraient régulièrement augmenté et se seraient superposées, masquées par les mises en doute mutuelles et croisées ou des tours d'esprit Jedi (« Nous ne parvenons pas à reproduire le problème en laboratoire… »), où la réponse à « J'ai un problème quand je me connecte avec un navigateur X à un serveur Y » est, « Eh bien, utilisez le client Y et tout fonctionnera bien ». À la fin de ce processus, on aurait obtenu au moins deux Webs mondiaux — l'un construit avec le serveur Web X, l'autre avec Y, et chacun d'eux n'aurait servi que ses clients. Ce genre de sape du standard a connu plusieurs précédents historiques, tant cette politique (le « verrouillage ») se trouve ancrée dans la stratégie commerciale de nombreux éditeurs de logiciels.

Bien sûr, ceci aurait été désastreux pour tout le monde car cela aurait condamné tout utilisateur du protocole HTTP (les fournisseurs de contenu et de services, les développeurs de logiciels ...) à maintenir deux serveurs distincts. Certains consommateurs firent peut-être pression afin de contraindre les fournisseurs à s'accorder sur le plan technique mais le marché invitait fermement ces derniers à « innover, différencier, mener l'industrie, définir la plate-forme », et cela aurait pu leur interdire de définir conjointement les protocoles utilisés.

Nous avons en fait constaté un désastre de ce type avec la partie client de JavaScript. Les différents navigateurs Web, y compris les différentes versions bêta d'un même navigateur, présentaient de telles différences de comportement que les développeurs durent créer du code capable de détecter les différentes révisions afin de sélectionner une forme adéquate — ce qui augmenta les délais de réalisation des documents interactifs en JavaScript. Ce n'est que lorsque le W3C intervint et jeta les bases de DOM (Modèle Objet de Document) que l'on assista à une tentative sérieuse de créer un standard multipartite autour de JavaScript.

Certaines forces naturelles du monde économique actuel poussent à la déviation lorsqu'un logiciel propriétaire est adossé à une spécification. Elle peut naître de la plus petite incompréhension du document de spécification, et se résorbera d'autant moins facilement qu'elle sera corrigée tard.

J'affirme donc que construire ses services ou ses produits sur une plate-forme standard préserve la stabilité de votre activité économique. Le succès de l'Internet a montré non seulement combien les plates-formes communes facilitent la communication mais a aussi contraint les fournisseurs à penser davantage à comment ajouter de la valeur à l'information en transit plutôt qu'à vouloir tirer profit du réseau lui-même.