L'AUTRE ROUTE À SUIVRE

Septembre 2001

(Cet article explique pourquoi une grande partie de la prochaine génération de logiciels pourrait être basée sur un serveur, ce que cela signifiera pour les programmeurs et pourquoi ce nouveau type de logiciel est une excellente opportunité pour les startups. Il est tiré d'une conférence à BBN Labs.)

À l'été 1995, mon ami Robert Morris et moi avons décidé de créer une start-up. La campagne de communication qui précédait l'introduction en bourse de Netscape battait son plein et la presse parlait beaucoup du commerce en ligne. À l'époque, il y avait peut-être trente boutiques en ligne, toutes faites à la main. S'il devait y avoir beaucoup de boutiques en ligne, il faudrait des logiciels pour les créer, alors nous avons décidé d'en créer.

Pendant la première semaine, nous avions prévu de faire de ce logiciel une application de bureau ordinaire. Puis un jour, nous avons eu l'idée de faire fonctionner le logiciel sur notre serveur Web, en utilisant le navigateur comme interface. Nous avons essayé de réécrire le logiciel pour qu'il fonctionne sur le Web, et il est apparu clairement que c'était la voie à suivre. Si nous écrivions notre logiciel pour qu'il fonctionne sur le serveur, ce serait beaucoup plus simple pour les utilisateurs et pour nous aussi.

Cela s'est avéré être un bon plan. Aujourd'hui, sous le nom de Yahoo Store , ce logiciel est le créateur de boutique en ligne le plus populaire, avec environ 14 000 utilisateurs.

Lorsque nous avons lancé Viaweb, presque personne ne comprenait ce que nous voulions dire lorsque nous disions que le logiciel fonctionnait sur le serveur. Ce n'est qu'avec le lancement de Hotmail, un an plus tard, que les gens ont commencé à comprendre. Aujourd'hui, tout le monde sait que cette approche est valable. Nous avons maintenant un nom pour ce que nous étions : un fournisseur de services d'application, ou ASP.

Je pense que la plupart des logiciels de la prochaine génération seront écrits sur ce modèle. Même Microsoft, qui a le plus à perdre, semble voir l'inévitabilité de déplacer certaines choses du bureau vers les serveurs. Si les logiciels quittent le bureau pour s'installer sur des serveurs, cela signifiera un monde très différent pour les développeurs. Cet article décrit les choses surprenantes que nous avons vues, en tant que premiers visiteurs de ce nouveau monde. Dans la mesure où les logiciels migrent vers les serveurs, ce que je décris ici est l'avenir.

La prochaine étape ?

Quand nous repenserons à l'ère des logiciels de bureau, je pense que nous nous émerveillerons des désagréments que les gens ont dû supporter, tout comme nous nous émerveillons aujourd'hui de ce que les premiers propriétaires de voitures ont dû supporter. Pendant les vingt ou trente premières années, il fallait être un expert en voitures pour posséder une voiture. Mais les voitures ont été un tel succès que beaucoup de gens qui n'étaient pas des experts en voitures voulaient aussi en avoir une.

Les ordinateurs sont dans cette phase aujourd'hui. Quand on possède un ordinateur de bureau, on finit par en apprendre beaucoup plus que l'on ne le souhaitait sur ce qui se passe à l'intérieur. Mais plus de la moitié des ménages aux États-Unis en possèdent un. Ma mère possède un ordinateur qu'elle utilise pour ses e-mails et pour tenir ses comptes. Il y a environ un an, elle a reçu avec inquiétude une lettre d'Apple lui proposant une remise sur une nouvelle version du système d'exploitation. Il y a quelque chose qui cloche lorsqu'une femme de soixante-cinq ans qui veut utiliser un ordinateur pour ses e-mails et ses comptes doit penser à installer de nouveaux systèmes d'exploitation. Les utilisateurs ordinaires ne devraient même pas connaître les mots « système d'exploitation », et encore moins « pilote de périphérique » ou « correctif ».

Il existe désormais une autre façon de proposer des logiciels qui éviteront aux utilisateurs de devoir devenir administrateurs système. Les applications Web sont des programmes qui s'exécutent sur des serveurs Web et utilisent des pages Web comme interface utilisateur. Pour l'utilisateur moyen, ce nouveau type de logiciel sera plus simple, moins cher, plus mobile, plus fiable et souvent plus puissant que les logiciels de bureau.

Avec les logiciels basés sur le Web, la plupart des utilisateurs n'auront plus à penser à rien d'autre qu'aux applications qu'ils utilisent. Tous les éléments désordonnés et changeants seront stockés sur un serveur quelque part, maintenu par des personnes qui sont douées pour ce genre de choses. Vous n'aurez donc généralement pas besoin d'un ordinateur en soi pour utiliser un logiciel. Tout ce dont vous aurez besoin sera un appareil doté d'un clavier, d'un écran et d'un navigateur Web. Peut-être qu'il disposera d'un accès Internet sans fil. Peut-être aussi de votre téléphone portable. Quoi qu'il en soit, ce sera un appareil électronique grand public : quelque chose qui coûte environ 200 $ et que les gens choisissent principalement en fonction de l'apparence du boîtier. Vous paierez plus pour les services Internet que pour le matériel, tout comme c'est le cas aujourd'hui pour les téléphones. [1]

Il faut environ un dixième de seconde pour qu'un clic arrive au serveur et en revienne, donc les utilisateurs de logiciels très interactifs, comme Photoshop, voudront toujours que les calculs se déroulent sur le bureau. Mais si vous regardez le genre de choses pour lesquelles la plupart des gens utilisent les ordinateurs, un dixième de seconde de latence ne serait pas un problème. Ma mère n'a pas vraiment besoin d'un ordinateur de bureau, et il y a beaucoup de gens comme elle.

La victoire pour les utilisateurs

Près de chez moi, il y a une voiture avec un autocollant sur le pare-chocs qui dit « la mort avant les inconvénients ». La plupart des gens, la plupart du temps, choisiront le choix qui demande le moins de travail. Si les logiciels basés sur le Web l'emportent, ce sera parce qu'ils sont plus pratiques. Et il semble que ce sera le cas, tant pour les utilisateurs que pour les développeurs.

Pour utiliser une application purement Web, il suffit d'avoir un navigateur connecté à Internet. Vous pouvez donc utiliser une application Web n'importe où. Lorsque vous installez un logiciel sur votre ordinateur de bureau, vous ne pouvez l'utiliser que sur cet ordinateur. Pire encore, vos fichiers sont bloqués sur cet ordinateur. L'inconvénient de ce modèle devient de plus en plus évident à mesure que les gens s'habituent aux réseaux.

Le problème, c'est que le courrier électronique est basé sur le Web. Des millions de personnes ont désormais compris qu'elles doivent pouvoir accéder à leurs messages électroniques où qu'elles se trouvent. Et si vous pouvez consulter vos e-mails, pourquoi pas votre calendrier ? Si vous pouvez discuter d'un document avec vos collègues, pourquoi ne pouvez-vous pas le modifier ? Pourquoi vos données devraient-elles être stockées sur un ordinateur installé sur un bureau éloigné ?

L'idée même de « votre ordinateur » disparaît et est remplacée par « vos données ». Vous devriez pouvoir accéder à vos données depuis n'importe quel ordinateur. Ou plutôt, depuis n'importe quel client, et un client n'est pas forcément un ordinateur.

Les clients ne devraient pas stocker de données ; ils devraient être comme des téléphones. En fait, ils peuvent devenir des téléphones, ou vice versa. Et comme le nombre de clients diminue, vous avez une autre raison de ne pas conserver vos données sur eux : quelque chose que vous transportez avec vous peut être perdu ou volé. Laisser votre PDA dans un taxi est comme une panne de disque dur, sauf que vos données sont transmises à quelqu'un d'autre au lieu d'être vaporisées.

Avec un logiciel purement basé sur le Web, ni vos données ni les applications ne sont conservées sur le client. Vous n'avez donc rien à installer pour l'utiliser. Et lorsqu'il n'y a pas d'installation, vous n'avez pas à vous inquiéter d'une éventuelle erreur d'installation. Il ne peut y avoir d'incompatibilité entre l'application et votre système d'exploitation, car le logiciel ne s'exécute pas sur votre système d'exploitation.

Comme il ne nécessite aucune installation, il sera facile et courant d'essayer un logiciel Web avant de l'« acheter ». Vous pouvez vous attendre à pouvoir tester gratuitement n'importe quelle application Web, simplement en vous rendant sur le site où elle est proposée. Chez Viaweb, notre site tout entier était comme une grande flèche pointant les utilisateurs vers la version d'essai.

Après avoir essayé la démo, l'inscription au service ne devrait nécessiter rien de plus que de remplir un bref formulaire (plus il est bref, mieux c'est). Et ce devrait être la dernière tâche que l'utilisateur doit effectuer. Avec un logiciel basé sur le Web, vous devriez obtenir les nouvelles versions sans payer de supplément, sans effectuer de travail, ni même sans en avoir connaissance.

Les mises à jour ne seront plus aussi bouleversantes qu'elles le sont aujourd'hui. Au fil du temps, les applications deviendront de plus en plus performantes. Cela demandera des efforts de la part des développeurs. Ils devront concevoir des logiciels de manière à ce qu'ils puissent être mis à jour sans perturber les utilisateurs. C'est un problème nouveau, mais il existe des moyens de le résoudre.

Avec les applications Web, tout le monde utilise la même version et les bugs peuvent être corrigés dès qu'ils sont découverts. Les logiciels Web devraient donc comporter beaucoup moins de bugs que les logiciels de bureau. Chez Viaweb, je doute que nous ayons jamais eu dix bugs connus à un moment donné. C'est bien mieux que les logiciels de bureau.

Les applications Web peuvent être utilisées par plusieurs personnes en même temps. C'est un avantage évident pour les applications collaboratives, mais je parie que les utilisateurs commenceront à vouloir cela dans la plupart des applications une fois qu'ils se rendront compte que c'est possible. Il sera souvent utile de permettre à deux personnes d'éditer le même document, par exemple. Viaweb a permis à plusieurs utilisateurs d'éditer un site simultanément, plus parce que c'était la bonne façon d'écrire le logiciel que parce que nous nous attendions à ce que les utilisateurs le souhaitent, mais il s'est avéré que beaucoup l'ont fait.

Lorsque vous utilisez une application Web, vos données seront plus en sécurité. Les pannes de disque ne seront plus un problème du passé, mais les utilisateurs n'en entendront plus parler. Elles se produiront au sein de fermes de serveurs. Et les entreprises proposant des applications Web effectueront effectivement des sauvegardes, non seulement parce qu'elles auront de vrais administrateurs système qui se soucieront de ce genre de choses, mais aussi parce qu'un ASP qui perdrait les données des utilisateurs se retrouverait dans une situation très difficile. Lorsque les utilisateurs perdent leurs propres données lors d'une panne de disque, ils ne peuvent pas se mettre en colère, car ils ne peuvent s'en prendre qu'à eux-mêmes. Lorsqu'une entreprise perdra ses données à leur place, ils seront encore plus en colère.

Enfin, les logiciels basés sur le Web devraient être moins vulnérables aux virus. Si le client n'exécute rien d'autre qu'un navigateur, il y a moins de risques d'exécuter des virus et aucune donnée locale ne risque d'être endommagée. Et un programme qui attaquerait les serveurs eux-mêmes devrait les trouver très bien défendus. [2]

Pour les utilisateurs, les logiciels basés sur le Web seront moins stressants. Je pense que si vous regardez à l'intérieur de l'utilisateur Windows moyen, vous découvrirez un désir énorme et pratiquement inexploité de logiciels répondant à cette description. Libéré, ce désir pourrait devenir une force puissante.

Ville de Code

Pour les développeurs, la différence la plus évidente entre un logiciel Web et un logiciel de bureau est qu'une application Web n'est pas un simple morceau de code. Il s'agit d'un ensemble de programmes de différents types plutôt que d'un seul gros fichier binaire. Concevoir un logiciel Web revient donc à concevoir une ville plutôt qu'un bâtiment : en plus des bâtiments, il faut des routes, des panneaux de signalisation, des services publics, des services de police et d'incendie, et des plans pour la croissance et divers types de catastrophes.

Chez Viaweb, les logiciels comprenaient des applications assez volumineuses avec lesquelles les utilisateurs parlaient directement, des programmes que ces programmes utilisaient, des programmes qui tournaient constamment en arrière-plan pour rechercher des problèmes, des programmes qui essayaient de redémarrer les choses en cas de panne, des programmes qui tournaient occasionnellement pour compiler des statistiques ou créer des index pour les recherches, des programmes que nous exécutions explicitement pour récupérer les ressources ou pour déplacer ou restaurer des données, des programmes qui prétendaient être des utilisateurs (pour mesurer les performances ou révéler des bugs), des programmes pour diagnostiquer les problèmes de réseau, des programmes pour faire des sauvegardes, des interfaces avec des services extérieurs, des logiciels qui pilotaient une impressionnante collection de cadrans affichant des statistiques de serveur en temps réel (un succès auprès des visiteurs, mais indispensable pour nous aussi), des modifications (y compris des corrections de bugs) de logiciels open source, et un grand nombre de fichiers de configuration et de paramètres. Trevor Blackwell a écrit un programme spectaculaire pour déplacer des magasins vers de nouveaux serveurs à travers le pays, sans les fermer, après notre rachat par Yahoo. Les programmes nous téléphonaient, envoyaient des fax et des e-mails aux utilisateurs, effectuaient des transactions avec des processeurs de cartes de crédit et communiquaient entre eux via des sockets, des pipes, des requêtes http, ssh, des paquets udp, une mémoire partagée et des fichiers. Certains éléments de Viaweb consistaient même en l'absence de programmes, car l'une des clés de la sécurité d'Unix est de ne pas exécuter d'utilitaires inutiles que les gens pourraient utiliser pour pénétrer dans vos serveurs.

Cela ne s'est pas arrêté aux logiciels. Nous avons passé beaucoup de temps à réfléchir aux configurations de serveurs. Nous avons construit les serveurs nous-mêmes, à partir de composants, en partie pour économiser de l'argent, et en partie pour obtenir exactement ce que nous voulions. Nous avons dû réfléchir à la question de savoir si notre FAI en amont avait des connexions suffisamment rapides à tous les backbones. Nous avons régulièrement contacté les fournisseurs RAID.

Mais le matériel n'est pas seulement un sujet de préoccupation. Lorsque vous le contrôlez, vous pouvez faire plus pour les utilisateurs. Avec une application de bureau, vous pouvez spécifier un minimum de matériel, mais vous ne pouvez pas en ajouter davantage. Si vous administrez les serveurs, vous pouvez en une seule étape permettre à tous vos utilisateurs de contacter des personnes, d'envoyer des fax, d'envoyer des commandes par téléphone, de traiter des cartes de crédit, etc., simplement en installant le matériel approprié. Nous avons toujours cherché de nouvelles façons d'ajouter des fonctionnalités avec le matériel, non seulement parce que cela plaisait aux utilisateurs, mais aussi pour nous distinguer de nos concurrents qui (soit parce qu'ils vendaient des logiciels de bureau, soit parce qu'ils revendaient des applications Web via des FAI) n'avaient pas de contrôle direct sur le matériel.

Comme le logiciel d'une application Web est un ensemble de programmes plutôt qu'un binaire unique, il peut être écrit dans un certain nombre de langages différents. Lorsque vous écrivez un logiciel de bureau, vous êtes pratiquement obligé d'écrire l'application dans le même langage que le système d'exploitation sous-jacent, c'est-à-dire C et C++. Ces langages (en particulier parmi les personnes non techniques comme les managers et les VCs) ont donc été considérés comme les langages du développement logiciel « sérieux ». Mais ce n'était qu'un artefact de la manière dont les logiciels de bureau devaient être livrés. Pour les logiciels basés sur serveur, vous pouvez utiliser le langage que vous voulez. [3] Aujourd'hui, de nombreux hackers de haut niveau utilisent des langages très éloignés du C et du C++ : Perl, Python et même Lisp.

Avec les logiciels basés sur un serveur, personne ne peut vous dire quelle langue utiliser, car vous contrôlez l'ensemble du système, jusqu'au matériel. Différents langages conviennent à différentes tâches. Vous pouvez utiliser celui qui convient le mieux à chacune d'elles. Et lorsque vous avez des concurrents, « vous pouvez » signifie « vous devez » (nous y reviendrons plus tard), car si vous ne profitez pas de cette possibilité, vos concurrents le feront.

La plupart de nos concurrents utilisaient C et C++, ce qui rendait leurs logiciels visiblement inférieurs car (entre autres choses), ils n'avaient aucun moyen de contourner l'absence d'état des scripts CGI. Si vous deviez modifier quelque chose, tous les changements devaient se produire sur une seule page, avec un bouton Mettre à jour en bas. Comme je l'ai écrit ailleurs, en utilisant Lisp , que beaucoup de gens considèrent encore comme un langage de recherche, nous pourrions faire en sorte que l'éditeur Viaweb se comporte davantage comme un logiciel de bureau.

Communiqués de presse

L’un des changements les plus importants dans ce nouveau monde est la façon dont on publie les versions. Dans le secteur des logiciels de bureau, publier une version est un véritable traumatisme, dans lequel toute l’entreprise s’efforce de produire un seul et même morceau de code géant. Des comparaisons évidentes s’imposent, tant pour le processus que pour le produit final.

Avec un logiciel basé sur un serveur, vous pouvez effectuer des modifications presque comme vous le feriez dans un programme que vous écririez pour vous-même. Vous publiez un logiciel sous forme d'une série de modifications incrémentielles au lieu d'une grande explosion occasionnelle. Une société de logiciels de bureau typique peut faire une ou deux versions par an. Chez Viaweb, nous faisons souvent trois à cinq versions par jour.

Lorsque vous passez à ce nouveau modèle, vous réalisez à quel point le développement logiciel est affecté par la manière dont il est publié. La plupart des problèmes les plus graves que vous rencontrez dans le secteur des logiciels de bureau sont dus à la nature catastrophique des versions.

Lorsque vous ne sortez qu'une seule nouvelle version par an, vous avez tendance à traiter les bugs en bloc. Quelque temps avant la date de sortie, vous assemblez une nouvelle version dans laquelle la moitié du code a été supprimée et remplacée, introduisant d'innombrables bugs. Ensuite, une équipe de QA intervient et commence à les compter, tandis que les programmeurs parcourent la liste pour les corriger. Ils n'arrivent généralement pas à la fin de la liste, et en fait, personne ne sait vraiment où se trouve la fin. C'est comme pêcher des gravats dans un étang. Vous ne savez jamais vraiment ce qui se passe à l'intérieur du logiciel. Au mieux, vous vous retrouvez avec une sorte de correction statistique.

Avec les logiciels basés sur serveur, la plupart des changements sont petits et progressifs. Cela en soi est moins susceptible d'introduire des bugs. Cela signifie également que vous savez ce qu'il faut tester avec le plus de soin lorsque vous êtes sur le point de publier un logiciel : la dernière chose que vous avez modifiée. Vous finissez par avoir une bien meilleure maîtrise du code. En règle générale, vous savez ce qui se passe à l'intérieur. Vous n'avez pas le code source mémorisé, bien sûr, mais lorsque vous lisez le code source, vous le faites comme un pilote qui scrute le tableau de bord, pas comme un détective essayant de percer un mystère.

Les logiciels de bureau engendrent un certain fatalisme à l'égard des bugs. Vous savez que vous livrez quelque chose qui contient de nombreux bugs, et vous avez même mis en place des mécanismes pour compenser cela (par exemple, des correctifs). Alors pourquoi vous soucier de quelques bugs supplémentaires ? Bientôt, vous publierez des fonctionnalités entières dont vous savez qu'elles ne fonctionnent pas. Apple l'a fait plus tôt cette année. L'entreprise s'est sentie obligée de sortir son nouveau système d'exploitation, dont la date de sortie avait déjà été décalée de quatre fois, mais certains logiciels (prise en charge des CD et des DVD) n'étaient pas prêts. La solution ? Ils ont sorti le système d'exploitation sans les parties inachevées, et les utilisateurs devront les installer plus tard.

Avec les logiciels basés sur le Web, vous n’avez jamais besoin de publier un logiciel avant qu’il ne fonctionne, et vous pouvez le publier dès qu’il fonctionne.

Les vétérans du secteur se disent peut-être que c'est une bonne idée de dire qu'il n'est jamais nécessaire de publier un logiciel avant qu'il ne fonctionne, mais que se passe-t-il lorsque vous avez promis de livrer une nouvelle version de votre logiciel à une certaine date ? Avec un logiciel basé sur le Web, vous ne feriez pas une telle promesse, car il n'existe pas de versions. Votre logiciel évolue progressivement et en permanence. Certains changements peuvent être plus importants que d'autres, mais l'idée de versions ne s'applique pas naturellement aux logiciels basés sur le Web.

Si quelqu'un se souvient de Viaweb, cela peut paraître étrange, car nous annoncions toujours de nouvelles versions. Cela a été fait uniquement à des fins de relations publiques. La presse spécialisée, nous l'avons appris, pense en termes de numéros de version. Ils vous donneront une couverture majeure pour une version majeure, ce qui signifie un nouveau premier chiffre sur le numéro de version, et généralement un paragraphe au plus pour une version intermédiaire, ce qui signifie un nouveau chiffre après la virgule.

Certains de nos concurrents proposaient des logiciels de bureau et comportaient des numéros de version. Et pour ces versions, dont le simple fait nous semblait être la preuve de leur retard, ils bénéficiaient de toute sorte de publicité. Nous ne voulions pas passer à côté de cette opportunité, alors nous avons commencé à attribuer des numéros de version à nos logiciels également. Lorsque nous voulions faire de la publicité, nous faisions une liste de toutes les fonctionnalités que nous avions ajoutées depuis la dernière « version », nous collions un nouveau numéro de version sur le logiciel et nous publiions un communiqué de presse annonçant que la nouvelle version était disponible immédiatement. Étonnamment, personne ne nous a jamais contactés à ce sujet.

Au moment de notre rachat, nous avions déjà fait cela trois fois, nous en étions donc à la version 4. Version 4.1 si je me souviens bien. Après que Viaweb soit devenu Yahoo Store, le besoin de publicité n'était plus aussi urgent, donc même si le logiciel a continué à évoluer, l'idée même des numéros de version a été discrètement abandonnée.

Insectes

L'autre avantage technique majeur des logiciels basés sur le Web est que vous pouvez reproduire la plupart des bugs. Vous disposez des données des utilisateurs directement sur votre disque. Si quelqu'un perturbe votre logiciel, vous n'avez pas à essayer de deviner ce qui se passe, comme vous le feriez avec un logiciel de bureau : vous devriez pouvoir reproduire l'erreur pendant que la personne est en communication téléphonique avec vous. Vous le savez peut-être déjà, si vous avez un code permettant de détecter les erreurs intégré à votre application.

Les logiciels basés sur le Web sont utilisés 24 heures sur 24, ce qui signifie que tout ce que vous faites est immédiatement mis à rude épreuve. Les bugs apparaissent rapidement.

On accuse parfois les éditeurs de logiciels de laisser les utilisateurs déboguer leurs logiciels. Et c'est exactement ce que je préconise. Pour les logiciels basés sur le Web, c'est en fait une bonne idée, car les bugs sont moins nombreux et transitoires. Lorsque vous publiez un logiciel progressivement, vous obtenez beaucoup moins de bugs au début. Et lorsque vous pouvez reproduire les erreurs et publier les modifications instantanément, vous pouvez trouver et corriger la plupart des bugs dès qu'ils apparaissent. Nous n'avons jamais eu suffisamment de bugs à un moment donné pour nous soucier d'un système formel de suivi des bugs.

Bien entendu, vous devez tester les modifications avant de les publier, afin de ne pas publier de bugs majeurs. Les quelques bugs qui passent inévitablement entre les mailles du filet concerneront des cas limites et n'affecteront que les quelques utilisateurs qui les rencontrent avant que quelqu'un ne vous appelle pour se plaindre. Tant que vous corrigez les bugs immédiatement, l'effet net, pour l'utilisateur moyen, est beaucoup moins de bugs. Je doute que l'utilisateur moyen de Viaweb ait jamais vu un bug.

Il est plus facile de corriger les bugs récents que les anciens. Il est généralement assez rapide de trouver un bug dans le code que vous venez d'écrire. Lorsqu'il apparaît, vous savez souvent ce qui ne va pas avant même de regarder la source, car vous vous en souciez déjà inconsciemment. Corriger un bug dans quelque chose que vous avez écrit il y a six mois (le cas moyen si vous publiez une fois par an) demande beaucoup plus de travail. Et comme vous ne comprenez pas aussi bien le code, vous êtes plus susceptible de le corriger de manière peu esthétique, voire d'introduire plus de bugs. [4]

Lorsque vous détectez les bugs tôt, vous obtenez également moins de bugs complexes. Les bugs complexes sont deux bugs distincts qui interagissent : vous trébuchez en descendant les escaliers et lorsque vous essayez d'attraper la rampe, elle vous tombe dans la main. Dans les logiciels, ce type de bug est le plus difficile à trouver et a également tendance à avoir les pires conséquences. [5] L'approche traditionnelle consistant à « tout casser puis à filtrer les bugs » génère intrinsèquement beaucoup de bugs complexes. Et les logiciels publiés en une série de petits changements ont tendance à ne pas le faire. Les sols sont constamment balayés pour éliminer tous les objets qui pourraient se coincer plus tard dans quelque chose.

Il est utile d'utiliser une technique appelée programmation fonctionnelle. La programmation fonctionnelle consiste à éviter les effets secondaires. C'est quelque chose que vous avez plus de chances de voir dans les articles de recherche que dans les logiciels commerciaux, mais pour les applications Web, cela s'avère vraiment utile. Il est difficile d'écrire des programmes entiers sous forme de code purement fonctionnel, mais vous pouvez écrire des morceaux substantiels de cette façon. Cela rend ces parties de votre logiciel plus faciles à tester, car elles n'ont pas d'état, ce qui est très pratique dans une situation où vous effectuez et testez constamment de petites modifications. J'ai écrit une grande partie de l'éditeur de Viaweb dans ce style, et nous avons fait de notre langage de script, RTML , un langage purement fonctionnel.

Les gens du secteur des logiciels de bureau trouveront cela difficile à croire, mais chez Viaweb, les bugs sont devenus presque un jeu. Comme la plupart des bugs publiés concernaient des cas limites, les utilisateurs qui les rencontraient étaient probablement des utilisateurs avancés, repoussant les limites. Les utilisateurs avancés sont plus indulgents avec les bugs, d'autant plus que vous les avez probablement introduits au cours de l'ajout d'une fonctionnalité qu'ils demandaient. En fait, comme les bugs étaient rares et qu'il fallait faire des choses sophistiquées pour les voir, les utilisateurs avancés étaient souvent fiers d'en attraper un. Ils appelaient le support dans un esprit plus de triomphe que de colère, comme s'ils avaient marqué des points sur nous.

Soutien

Lorsque vous pouvez reproduire les erreurs, cela change votre approche du support client. Dans la plupart des éditeurs de logiciels, le support est proposé comme un moyen de rassurer les clients. Soit ils vous appellent à propos d'un bug connu, soit ils font simplement quelque chose de mal et vous devez comprendre de quoi il s'agit. Dans les deux cas, vous n'avez pas grand-chose à apprendre d'eux. Vous avez donc tendance à considérer les appels au support comme une douleur que vous souhaitez isoler autant que possible de vos développeurs.

Ce n'était pas ainsi que les choses fonctionnaient chez Viaweb. Chez Viaweb, le support était gratuit, car nous voulions connaître l'avis des clients. Si quelqu'un avait un problème, nous voulions le savoir immédiatement afin de pouvoir reproduire l'erreur et proposer un correctif.

Chez Viaweb, les développeurs étaient toujours en contact étroit avec le support. Les personnes du support client se trouvaient à une dizaine de mètres des programmeurs et savaient qu'elles pouvaient toujours interrompre le travail en signalant un bug réel. Nous quittions une réunion du conseil d'administration pour corriger un bug grave.

Notre approche du support a rendu tout le monde plus heureux. Les clients étaient ravis. Imaginez ce que cela ferait d'appeler une ligne d'assistance et d'être traité comme quelqu'un qui apporte des nouvelles importantes. Les personnes du support client ont apprécié cela parce que cela signifiait qu'elles pouvaient aider les utilisateurs, au lieu de leur lire des scripts. Et les programmeurs ont apprécié cela parce qu'ils pouvaient reproduire les bugs au lieu de simplement entendre des rapports vagues de seconde main à leur sujet.

Notre politique de correction des bugs à la volée a changé la relation entre les personnes du support client et les hackers. Dans la plupart des sociétés de logiciels, les personnes du support sont des boucliers humains sous-payés et les hackers sont de petites copies de Dieu le Père, créateurs du monde. Quelle que soit la procédure de signalement des bugs, elle est probablement unidirectionnelle : les personnes du support qui entendent parler de bugs remplissent un formulaire qui est finalement transmis (éventuellement via l'assurance qualité) aux programmeurs, qui l'inscrivent sur leur liste de choses à faire. C'était très différent chez Viaweb. Une minute après avoir entendu parler d'un bug par un client, les personnes du support pouvaient se tenir à côté d'un programmeur et l'entendre dire "Merde, vous avez raison, c'est un bug". Cela faisait plaisir aux personnes du support d'entendre ce "vous avez raison" de la part des hackers. Ils nous rapportaient autrefois les bugs avec le même air d'attente qu'un chat vous apporte la souris qu'il vient de tuer. Cela les rendait également plus prudents dans l'évaluation de la gravité d'un bug, car maintenant leur honneur était en jeu.

Après notre rachat par Yahoo, les équipes du support client ont été éloignées des programmeurs. C'est seulement à ce moment-là que nous avons réalisé qu'elles étaient en fait des responsables de l'assurance qualité et, dans une certaine mesure, du marketing. En plus de détecter les bugs, elles étaient les gardiennes de la connaissance de choses plus vagues, comme les fonctionnalités qui déroutaient les utilisateurs. [6] Elles constituaient également une sorte de groupe de discussion par procuration ; nous pouvions leur demander laquelle des deux nouvelles fonctionnalités les utilisateurs souhaitaient le plus, et elles avaient toujours raison.

Moral

Le fait de pouvoir publier un logiciel immédiatement est une grande source de motivation. Souvent, en me rendant au travail, je pensais à un changement que je voulais apporter au logiciel et je le faisais le jour même. Cela fonctionnait également pour les fonctionnalités plus importantes. Même si quelque chose devait prendre deux semaines à écrire (peu de projets ont pris plus de temps), je savais que je pourrais voir l'effet sur le logiciel dès qu'il serait terminé.

Si j'avais dû attendre un an avant la sortie de la prochaine version, j'aurais mis de côté la plupart de ces idées, du moins pendant un certain temps. Mais le truc avec les idées, c'est qu'elles mènent à d'autres idées. Avez-vous déjà remarqué que lorsque vous vous asseyez pour écrire quelque chose, la moitié des idées qui finissent par y apparaître sont celles auxquelles vous avez pensé pendant que vous l'écriviez ? La même chose se produit avec les logiciels. Travailler à la mise en œuvre d'une idée vous donne plus d'idées. Donc mettre de côté une idée vous coûte non seulement ce retard dans sa mise en œuvre, mais aussi toutes les idées que sa mise en œuvre aurait amenées. En fait, mettre de côté une idée freine probablement même les nouvelles idées : lorsque vous commencez à penser à une nouvelle fonctionnalité, vous apercevez l'étagère et vous pensez « mais j'ai déjà beaucoup de nouvelles choses que je veux faire pour la prochaine version ».

Au lieu de mettre en œuvre des fonctionnalités, les grandes entreprises les planifient. Chez Viaweb, nous avons parfois rencontré des difficultés à ce sujet. Les investisseurs et les analystes nous demandaient ce que nous avions prévu pour l'avenir. La réponse honnête aurait été que nous n'avions aucun plan. Nous avions des idées générales sur les choses que nous voulions améliorer, mais si nous avions su comment nous l'aurions déjà fait. Qu'allions-nous faire dans les six prochains mois ? Ce qui semblait être la plus grande victoire. Je ne sais pas si j'ai jamais osé donner cette réponse, mais c'était la vérité. Les plans ne sont qu'un autre mot pour les idées sur l'étagère. Lorsque nous avons eu de bonnes idées, nous les avons mises en œuvre.

Chez Viaweb, comme dans de nombreuses sociétés de logiciels, la plupart des codes avaient un propriétaire bien défini. Mais quand vous possédiez quelque chose, vous le possédiez vraiment : personne, à part le propriétaire d'un logiciel, n'était obligé d'approuver (ou même d'être au courant) une publication. Il n'y avait aucune protection contre les pannes, à part la peur de passer pour un idiot aux yeux de ses pairs, et c'était plus que suffisant. J'ai peut-être donné l'impression que nous nous lancions allègrement dans l'écriture du code. Nous allions vite, mais nous réfléchissions très soigneusement avant de publier des logiciels sur ces serveurs. Et il est plus important d'être attentif pour la fiabilité que d'avancer lentement. Parce qu'il est très attentif, un pilote de la Navy peut faire atterrir un avion de 18 tonnes à 225 km/h sur le pont d'un porte-avions en pleine tangage, la nuit, avec plus de sécurité qu'un adolescent moyen ne peut couper un bagel.

Cette façon de concevoir un logiciel est évidemment à double tranchant. Elle fonctionne bien mieux pour une petite équipe de programmeurs compétents et de confiance que pour une grande entreprise composée de programmeurs médiocres, où les mauvaises idées sont repérées par des comités plutôt que par les personnes qui les ont émises.

Brooks à l'envers

Heureusement, les logiciels basés sur le Web nécessitent moins de programmeurs. J'ai travaillé une fois pour une entreprise de logiciels de bureau de taille moyenne qui comptait plus de 100 personnes travaillant dans l'ingénierie au total. Seulement 13 d'entre elles travaillaient au développement de produits. Tous les autres travaillaient sur les versions, les ports, etc. Avec les logiciels basés sur le Web, tout ce dont vous avez besoin (au maximum) sont les 13 personnes, car il n'y a pas de versions, de ports, etc.

Viaweb a été écrit par seulement trois personnes. [7] J'étais toujours sous pression pour embaucher plus de personnes, car nous voulions être achetés et nous savions que les acheteurs auraient du mal à payer un prix élevé pour une entreprise avec seulement trois programmeurs. (Solution : nous avons embauché plus de personnes, mais avons créé de nouveaux projets pour eux.)

Lorsque vous pouvez écrire des logiciels avec moins de programmeurs, vous économisez plus que de l'argent. Comme l'a souligné Fred Brooks dans The Mythical Man-Month, ajouter des personnes à un projet tend à le ralentir. Le nombre de connexions possibles entre développeurs augmente de manière exponentielle avec la taille du groupe. Plus le groupe est grand, plus les développeurs passent de temps en réunion à négocier la manière dont leurs logiciels fonctionneront ensemble, et plus ils rencontrent de bugs dus à des interactions imprévues. Heureusement, ce processus fonctionne aussi dans l'autre sens : à mesure que les groupes se réduisent, le développement de logiciels devient exponentiellement plus efficace. Je ne me souviens pas que les programmeurs de Viaweb aient jamais eu de réunion réelle. Nous n'avions jamais plus à dire à un moment donné que ce que nous pouvions dire en marchant pour déjeuner.

Si cette approche présente un inconvénient, c'est que tous les programmeurs doivent être, dans une certaine mesure, également administrateurs système. Lorsque vous hébergez un logiciel, quelqu'un doit surveiller les serveurs et, en pratique, les seules personnes qui peuvent le faire correctement sont celles qui ont écrit le logiciel. Chez Viaweb, notre système comportait tellement de composants et changeait si fréquemment qu'il n'y avait aucune frontière définie entre le logiciel et l'infrastructure. Déclarer arbitrairement une telle frontière aurait limité nos choix de conception. Ainsi, même si nous espérions constamment qu'un jour (« dans quelques mois ») tout serait suffisamment stable pour que nous puissions embaucher quelqu'un dont le travail consisterait uniquement à s'occuper des serveurs, cela n'est jamais arrivé.

Je ne pense pas que cela puisse être autrement, tant que vous continuez à développer activement le produit. Un logiciel basé sur le Web ne sera jamais quelque chose que vous écrivez, enregistrez et rentrez chez vous. C'est un truc vivant, qui tourne sur vos serveurs en ce moment même. Un mauvais bug ne peut pas seulement faire planter le processus d'un utilisateur ; il peut les faire planter tous. Si un bug dans votre code corrompt certaines données sur le disque, vous devez le corriger. Et ainsi de suite. Nous avons constaté que vous n'avez pas besoin de surveiller les serveurs toutes les minutes (après la première année environ), mais vous devez absolument garder un œil sur les choses que vous avez modifiées récemment. Vous ne publiez pas de code tard le soir et vous rentrez ensuite chez vous.

Utilisateurs surveillés

Avec un logiciel basé sur un serveur, vous êtes plus proche de votre code. Vous pouvez également être plus proche de vos utilisateurs. Intuit est célèbre pour se présenter aux clients dans les magasins de détail et leur demander de les suivre chez eux. Si vous avez déjà vu quelqu'un utiliser votre logiciel pour la première fois, vous savez quelles surprises ont dû l'attendre.

Les logiciels doivent faire ce que les utilisateurs pensent qu'ils feront. Mais croyez-moi, vous ne pouvez pas avoir une idée de ce que les utilisateurs vont penser tant que vous ne les avez pas observés. Et les logiciels basés sur serveur vous donnent des informations sans précédent sur leur comportement. Vous n'êtes pas limité à de petits groupes de discussion artificiels. Vous pouvez voir chaque clic effectué par chaque utilisateur. Vous devez réfléchir soigneusement à ce que vous allez regarder, car vous ne voulez pas violer la vie privée des utilisateurs, mais même l'échantillonnage statistique le plus général peut être très utile.

Lorsque vous avez des utilisateurs sur votre serveur, vous n'avez pas besoin de vous fier aux tests de performance, par exemple. Les tests de performance sont des simulations d'utilisateurs. Avec un logiciel basé sur un serveur, vous pouvez observer les utilisateurs réels. Pour décider ce qu'il faut optimiser, connectez-vous simplement à un serveur et voyez ce qui consomme tout le CPU. Et vous savez aussi quand arrêter d'optimiser : nous avons finalement amené l'éditeur Viaweb au point où il était limité à la mémoire plutôt qu'au CPU, et comme nous ne pouvions rien faire pour réduire la taille des données des utilisateurs (enfin, rien de facile), nous savions que nous pouvions tout aussi bien nous arrêter là.

L'efficacité est importante pour les logiciels basés sur serveur, car vous payez pour le matériel. Le nombre d'utilisateurs que vous pouvez prendre en charge par serveur est le diviseur de votre coût d'investissement, donc si vous pouvez rendre votre logiciel très efficace, vous pouvez vendre moins cher que vos concurrents et quand même faire un bénéfice. Chez Viaweb, nous avons réduit le coût d'investissement par utilisateur à environ 5 $. Il serait moins élevé aujourd'hui, probablement moins que le coût de leur envoyer la facture du premier mois. Le matériel est gratuit maintenant, si votre logiciel est raisonnablement efficace.

Observer les utilisateurs peut vous guider dans la conception ainsi que dans l'optimisation. Viaweb disposait d'un langage de script appelé RTML qui permettait aux utilisateurs avancés de définir leurs propres styles de page. Nous avons constaté que RTML était devenu une sorte de boîte à suggestions, car les utilisateurs ne l'utilisaient que lorsque les styles de page prédéfinis ne pouvaient pas faire ce qu'ils voulaient. À l'origine, l'éditeur plaçait des barres de boutons sur toute la page, par exemple, mais après qu'un certain nombre d'utilisateurs aient utilisé RTML pour placer des boutons sur le côté gauche, nous en avons fait une option (en fait la valeur par défaut) dans les styles de page prédéfinis.

Enfin, en observant les utilisateurs, on peut souvent savoir quand ils sont en difficulté. Et comme le client a toujours raison, c'est le signe qu'il faut régler quelque chose. Chez Viaweb, la clé pour attirer les utilisateurs a été le test en ligne. Il ne s'agissait pas simplement d'une série de diapositives créées par des responsables marketing. Lors de notre test, les utilisateurs ont réellement utilisé le logiciel. Cela a pris environ cinq minutes et, à la fin, ils avaient créé une véritable boutique en ligne.

La phase de test a été le moyen par lequel nous avons réussi à attirer la plupart de nos nouveaux utilisateurs. Je pense que ce sera la même chose pour la plupart des applications Web. Si les utilisateurs réussissent la phase de test, ils apprécieront le produit. S'ils sont désorientés ou s'ennuient, ils ne l'apprécieront pas. Tout ce que nous pourrions faire pour inciter davantage de personnes à passer la phase de test augmenterait donc notre taux de croissance.

J'ai étudié les clics des utilisateurs qui ont effectué la version d'essai et j'ai découvert qu'à une certaine étape, ils étaient désorientés et cliquaient sur le bouton Retour du navigateur. (Si vous essayez d'écrire des applications Web, vous constaterez que le bouton Retour devient l'un de vos problèmes philosophiques les plus intéressants.) J'ai donc ajouté un message à ce stade, indiquant aux utilisateurs qu'ils avaient presque terminé et leur rappelant de ne pas cliquer sur le bouton Retour. Un autre avantage des logiciels Web est que vous obtenez un retour instantané sur les modifications : le nombre de personnes ayant terminé la version d'essai est passé immédiatement de 60 % à 90 %. Et comme le nombre de nouveaux utilisateurs était fonction du nombre de versions d'essai terminées, notre croissance des revenus a augmenté de 50 %, rien qu'avec ce changement.

Argent

Au début des années 1990, j'ai lu un article dans lequel quelqu'un disait que les logiciels étaient un marché d'abonnement. Au début, cette déclaration m'a semblé très cynique. Mais plus tard, j'ai réalisé qu'elle reflétait la réalité : le développement de logiciels est un processus continu. Je pense qu'il est plus judicieux de facturer ouvertement des frais d'abonnement, plutôt que de forcer les gens à acheter et à installer de nouvelles versions pour qu'ils continuent à vous payer. Et heureusement, les abonnements sont le moyen naturel de facturer les applications Web.

L'hébergement d'applications est un domaine dans lequel les entreprises joueront un rôle qui ne sera probablement pas rempli par des logiciels gratuits. L'hébergement d'applications est très stressant et entraîne des dépenses réelles. Personne ne voudra le faire gratuitement.

Pour les entreprises, les applications Web sont une source de revenus idéale. Au lieu de commencer chaque trimestre avec une feuille blanche, vous disposez d'un flux de revenus récurrent. Comme votre logiciel évolue progressivement, vous n'avez pas à vous inquiéter de l'échec d'un nouveau modèle. Il n'est jamais nécessaire de créer un nouveau modèle, et si vous faites quelque chose au logiciel que les utilisateurs détestent, vous le saurez immédiatement. Vous n'avez pas de problèmes de factures irrécouvrables. Si quelqu'un ne paie pas, vous pouvez simplement désactiver le service. Et il n'y a aucun risque de piratage.

Ce dernier « avantage » peut se révéler problématique. Le piratage est parfois à l'avantage des éditeurs de logiciels. Si un utilisateur n'aurait pas acheté votre logiciel à n'importe quel prix, vous n'avez rien perdu s'il utilise une copie piratée. En fait, vous y gagnez, car il s'agit d'un utilisateur supplémentaire qui contribue à faire de votre logiciel la norme - ou qui pourrait en acheter une copie plus tard, lorsqu'il aura terminé ses études secondaires.

Quand elles le peuvent, les entreprises aiment pratiquer ce qu’on appelle la discrimination par les prix, c’est-à-dire facturer à chaque client le prix qu’il peut se permettre. [8] Les logiciels sont particulièrement adaptés à la discrimination par les prix, car leur coût marginal est proche de zéro. C’est pourquoi certains logiciels coûtent plus cher à exécuter sur des machines Sun que sur des machines Intel : une entreprise qui utilise des machines Sun n’a pas intérêt à faire des économies et peut se permettre de payer plus cher. Le piratage est en fait le niveau le plus bas de la discrimination par les prix. Je pense que les éditeurs de logiciels l’ont bien compris et ferment délibérément les yeux sur certains types de piratage. [9] Avec les logiciels basés sur des serveurs, ils vont devoir trouver une autre solution.

Les logiciels en ligne se vendent bien, surtout par rapport aux logiciels de bureau, parce qu'ils sont faciles à acheter. On pourrait penser que les gens décident d'acheter quelque chose, puis l'achètent, en deux étapes distinctes. C'est ce que je pensais avant Viaweb, dans la mesure où j'ai réfléchi à la question. En fait, la deuxième étape peut se propager à la première : si quelque chose est difficile à acheter, les gens changeront d'avis quant à savoir s'ils le voulaient ou non. Et vice versa : vous vendrez plus d'un produit s'il est facile à acheter. J'achète plus de livres parce qu'Amazon existe. Les logiciels en ligne sont à peu près la chose la plus simple au monde à acheter, surtout si vous venez de faire une démonstration en ligne. Les utilisateurs ne devraient pas avoir à faire beaucoup plus que de saisir un numéro de carte de crédit. (Les obliger à faire plus, c'est à vos risques et périls.)

Les logiciels Web sont parfois proposés par des FAI agissant en tant que revendeurs. C'est une mauvaise idée. Vous devez administrer les serveurs, car vous devez constamment améliorer le matériel et les logiciels. Si vous renoncez au contrôle direct des serveurs, vous renoncez à la plupart des avantages du développement d'applications Web.

Plusieurs de nos concurrents se sont tiré une balle dans le pied de cette façon, la plupart du temps, je pense, parce qu'ils ont été envahis par des hommes en costume qui étaient enthousiasmés par ce canal à fort potentiel et qui ne se rendaient pas compte que cela ruinerait le produit qu'ils espéraient vendre par ce biais. Vendre des logiciels basés sur le Web par l'intermédiaire de fournisseurs d'accès Internet, c'est comme vendre des sushis par l'intermédiaire de distributeurs automatiques.

Clients

Qui seront les clients ? Chez Viaweb, il s'agissait au départ de particuliers et de petites entreprises, et je pense que ce sera la règle avec les applications Web. Ce sont des utilisateurs qui sont prêts à essayer de nouvelles choses, en partie parce qu'ils sont plus flexibles, et en partie parce qu'ils veulent les coûts plus bas des nouvelles technologies.

Les applications Web sont souvent aussi la meilleure option pour les grandes entreprises (même si elles tardent à s'en rendre compte). Le meilleur intranet est Internet. Si une entreprise utilise de véritables applications Web, le logiciel fonctionnera mieux, les serveurs seront mieux administrés et les employés auront accès au système de n'importe où.

L’argument contre cette approche repose généralement sur la sécurité : si l’accès est plus facile pour les employés, il le sera aussi pour les malfaiteurs. Certains grands commerçants étaient réticents à utiliser Viaweb parce qu’ils pensaient que les informations de carte de crédit des clients seraient plus en sécurité sur leurs propres serveurs. Il n’était pas facile de faire valoir ce point de manière diplomatique, mais en fait, les données étaient presque certainement plus en sécurité entre nos mains que chez les leurs. Qui peut embaucher de meilleures personnes pour gérer la sécurité, une start-up technologique dont toute l’activité consiste à gérer des serveurs ou un détaillant de vêtements ? Non seulement nous avions de meilleures personnes pour nous soucier de la sécurité, mais nous nous en préoccupions davantage. Si quelqu’un s’introduisait dans les serveurs du détaillant de vêtements, cela n’affecterait qu’un seul commerçant au plus, pourrait probablement être étouffé et, dans le pire des cas, pourrait entraîner le licenciement d’une personne. Si quelqu’un s’introduisait dans les nôtres, cela pourrait affecter des milliers de commerçants, finirait probablement dans les nouvelles sur CNet et pourrait nous mettre en faillite.

Si vous voulez garder votre argent en sécurité, le gardez-vous sous votre matelas à la maison ou le déposez-vous dans une banque ? Cet argument s'applique à tous les aspects de l'administration d'un serveur : pas seulement la sécurité, mais aussi la disponibilité, la bande passante, la gestion de la charge, les sauvegardes, etc. Notre existence dépendait de la bonne exécution de ces tâches. Les problèmes de serveur étaient pour nous un grand non-non, comme un jouet dangereux pour un fabricant de jouets ou une épidémie de salmonelle pour un transformateur de produits alimentaires.

Une grande entreprise qui utilise des applications Web externalise dans cette mesure son informatique. Aussi drastique que cela puisse paraître, je pense que c'est généralement une bonne idée. Les entreprises sont susceptibles d'obtenir un meilleur service de cette manière que si elles faisaient appel à des administrateurs système internes. Les administrateurs système peuvent devenir grincheux et peu réactifs parce qu'ils ne sont pas directement exposés à la pression concurrentielle : un vendeur doit traiter avec des clients et un développeur avec des logiciels concurrents, mais un administrateur système, comme un vieux célibataire, n'a que peu de forces extérieures pour le maintenir dans le droit chemin. [10] Chez Viaweb, nous avions suffisamment de forces extérieures pour nous maintenir dans le droit chemin. Les personnes qui nous appelaient étaient des clients, pas seulement des collègues. Si un serveur se retrouvait coincé, nous sautions sur l'occasion ; le simple fait d'y penser me donne une poussée d'adrénaline, des années plus tard.

Les applications Web seront donc généralement la bonne solution pour les grandes entreprises aussi. Mais elles seront les dernières à s'en rendre compte, tout comme elles l'ont fait avec les ordinateurs de bureau. Et en partie pour la même raison : il faudra beaucoup d'argent pour convaincre les grandes entreprises qu'elles ont besoin de quelque chose de plus cher.

Les clients riches ont toujours tendance à acheter des solutions onéreuses, même lorsque les solutions bon marché sont meilleures, car les personnes qui proposent des solutions onéreuses peuvent dépenser plus pour les vendre. Chez Viaweb, nous avons toujours été confrontés à ce problème. Nous avons perdu plusieurs marchands haut de gamme au profit de sociétés de conseil Web qui les ont convaincus qu'ils seraient mieux lotis s'ils payaient un demi-million de dollars pour une boutique en ligne sur mesure sur leur propre serveur. En règle générale, ils n'étaient pas mieux lotis, comme plus d'un l'a découvert à l'approche de la saison des achats de Noël et lorsque les charges ont augmenté sur leur serveur. Viaweb était beaucoup plus sophistiqué que ce que la plupart de ces marchands avaient, mais nous ne pouvions pas nous permettre de le leur dire. À 300 $ par mois, nous ne pouvions pas nous permettre d'envoyer une équipe de personnes bien habillées et autoritaires faire des présentations aux clients.

Une grande partie des frais supplémentaires que paient les grandes entreprises est le prix qu'elles doivent payer pour leur vendre des produits coûteux. (Si le ministère de la Défense paie mille dollars pour des sièges de toilettes, c'est en partie parce que cela coûte cher de les vendre à mille dollars.) Et c'est l'une des raisons pour lesquelles les logiciels intranet continueront de prospérer, même si c'est probablement une mauvaise idée. Ils sont tout simplement plus chers. Vous ne pouvez rien faire pour résoudre ce problème, donc la meilleure solution est de vous adresser d'abord aux petits clients. Le reste viendra avec le temps.

Fils du serveur

L'exécution de logiciels sur un serveur n'a rien de nouveau. En fait, il s'agit d'un ancien modèle : les applications mainframe sont toutes basées sur un serveur. Si les logiciels basés sur un serveur sont une si bonne idée, pourquoi ont-ils perdu la dernière fois ? Pourquoi les ordinateurs de bureau ont-ils éclipsé les mainframes ?

Au début, les ordinateurs de bureau ne semblaient pas représenter une menace importante. Les premiers utilisateurs étaient tous des hackers, ou des amateurs, comme on les appelait à l'époque. Ils aimaient les micro-ordinateurs parce qu'ils étaient bon marché. Pour la première fois, on pouvait avoir son propre ordinateur. L'expression « ordinateur personnel » fait aujourd'hui partie du langage courant, mais à l'époque, elle avait une consonance délibérément audacieuse, comme l'est aujourd'hui l'expression « satellite personnel ».

Pourquoi les ordinateurs de bureau ont-ils pris le dessus ? Je pense que c'est parce qu'ils avaient de meilleurs logiciels. Et je pense que la raison pour laquelle les logiciels des micro-ordinateurs étaient meilleurs était qu'ils pouvaient être écrits par de petites entreprises.

Je ne pense pas que beaucoup de gens se rendent compte à quel point les startups sont fragiles et hésitantes au début. Beaucoup d’entre elles démarrent presque par accident – par l’intermédiaire de deux personnes, soit au travail, soit à l’école, qui écrivent un prototype de quelque chose qui pourrait, s’il semble prometteur, se transformer en entreprise. À ce stade larvaire, tout obstacle important arrêtera net la startup dans son élan. Écrire un logiciel mainframe exigeait trop d’engagement au départ. Les machines de développement étaient chères, et comme les clients étaient de grandes entreprises, il fallait une force de vente impressionnante pour les convaincre. Créer une startup pour écrire un logiciel mainframe était une entreprise bien plus sérieuse que de simplement bidouiller quelque chose sur votre Apple II le soir. Et donc, il n’y avait pas beaucoup de startups qui écrivaient des applications mainframe.

L'arrivée des ordinateurs de bureau a inspiré de nombreux nouveaux logiciels, car l'écriture d'applications pour ces derniers semblait un objectif atteignable pour les jeunes pousses. Le développement était peu coûteux et les clients étaient des personnes individuelles que l'on pouvait contacter par l'intermédiaire de magasins informatiques ou même par correspondance.

L'application qui a propulsé les ordinateurs de bureau au rang de produit grand public est VisiCalc , le premier tableur. Il a été écrit par deux gars qui travaillaient dans un grenier et qui pourtant permettait des choses qu'aucun logiciel de mainframe ne pouvait faire. [11] VisiCalc était une telle avancée, à l'époque, que les gens achetaient des Apple II juste pour l'utiliser. Et ce fut le début d'une tendance : les ordinateurs de bureau ont gagné parce que des startups ont écrit des logiciels pour eux.

Il semble que les logiciels basés sur serveur seront une bonne chose cette fois-ci, car ce sont les startups qui les écriront. Les ordinateurs sont si bon marché aujourd'hui que vous pouvez commencer, comme nous l'avons fait, en utilisant un ordinateur de bureau comme serveur. Les processeurs bon marché ont dévoré le marché des stations de travail (on entend rarement ce mot maintenant) et sont presque tous présents sur le marché des serveurs ; les serveurs de Yahoo, qui traitent des charges aussi élevées que n'importe quel autre sur Internet, ont tous les mêmes processeurs Intel bon marché que ceux que vous avez sur votre ordinateur de bureau. Et une fois que vous avez écrit le logiciel, tout ce dont vous avez besoin pour le vendre est un site Web. Presque tous nos utilisateurs sont venus directement sur notre site par le bouche à oreille et les références dans la presse. [12]

Viaweb était une start-up typique. Nous étions terrifiés à l’idée de créer une entreprise et, pendant les premiers mois, nous nous sommes rassurés en considérant le projet comme une expérience que nous pouvions interrompre à tout moment. Heureusement, les obstacles étaient peu nombreux, hormis les problèmes techniques. Pendant que nous écrivions le logiciel, notre serveur Web était la même machine de bureau que nous utilisions pour le développement, connectée au monde extérieur par une ligne commutée. Nos seules dépenses à cette époque étaient la nourriture et le loyer.

Les startups ont d'autant plus de raisons de développer des logiciels basés sur le Web qu'il est devenu beaucoup moins amusant de développer des logiciels pour ordinateurs de bureau. Si vous voulez développer des logiciels pour ordinateurs de bureau, vous le faites désormais selon les conditions de Microsoft, en appelant leurs API et en contournant leur système d'exploitation bogué. Et si vous parvenez à développer quelque chose qui décolle, vous découvrirez peut-être que vous ne faisiez que des études de marché pour Microsoft.

Si une entreprise veut créer une plateforme sur laquelle les startups pourront s'appuyer, elle doit la rendre accessible aux hackers eux-mêmes. Cela signifie qu'elle doit être peu coûteuse et bien conçue. Le Mac était populaire auprès des hackers à sa sortie, et beaucoup d'entre eux ont écrit des logiciels pour lui. [13] On voit moins cela avec Windows, car les hackers ne l'utilisent pas. Les personnes qui savent écrire des logiciels utilisent généralement Linux ou FreeBSD aujourd'hui.

Je ne pense pas que nous aurions créé une start-up pour écrire des logiciels de bureau, car ces derniers doivent fonctionner sous Windows, et avant de pouvoir écrire des logiciels pour Windows, nous aurions dû l'utiliser. Le Web nous a permis de contourner Windows et de fournir des logiciels fonctionnant sous Unix directement aux utilisateurs via le navigateur. C'est une perspective libératrice, très similaire à l'arrivée des PC il y a vingt-cinq ans.

Microsoft

À l'époque où les ordinateurs de bureau sont arrivés, IBM était le géant dont tout le monde avait peur. C'est difficile à imaginer aujourd'hui, mais je me souviens très bien de ce sentiment. Aujourd'hui, le géant qui fait peur, c'est Microsoft, et je ne pense pas qu'ils soient aussi aveugles à la menace qui pèse sur eux qu'IBM. Après tout, Microsoft a délibérément construit son entreprise dans l'angle mort d'IBM.

J'ai mentionné plus tôt que ma mère n'a pas vraiment besoin d'un ordinateur de bureau. La plupart des utilisateurs n'en ont probablement pas besoin. C'est un problème pour Microsoft, et ils le savent. Si les applications s'exécutent sur des serveurs distants, personne n'a besoin de Windows. Que fera Microsoft ? Pourra-t-il utiliser son contrôle sur le bureau pour empêcher ou limiter cette nouvelle génération de logiciels ?

Je pense que Microsoft va développer une sorte d'hybride serveur/bureau, où le système d'exploitation fonctionnera avec les serveurs qu'il contrôle. Au minimum, les fichiers seront disponibles de manière centralisée pour les utilisateurs qui le souhaitent. Je ne m'attends pas à ce que Microsoft aille jusqu'à effectuer les calculs sur le serveur, avec seulement un navigateur pour un client, s'il peut l'éviter. Si vous n'avez besoin que d'un navigateur pour un client, vous n'avez pas besoin de Microsoft sur le client, et si Microsoft ne contrôle pas le client, il ne peut pas pousser les utilisateurs vers ses applications basées sur le serveur.

Je pense que Microsoft aura du mal à garder le génie dans la bouteille. Il y aura trop de types de clients différents pour qu'ils puissent tous les contrôler. Et si les applications de Microsoft ne fonctionnent qu'avec certains clients, les concurrents pourront les surpasser en proposant des applications qui fonctionnent à partir de n'importe quel client. [14]

Dans un monde d'applications basées sur le Web, Microsoft n'a pas automatiquement sa place. Ils parviendront peut-être à se faire une place, mais je ne pense pas qu'ils domineront ce nouveau monde comme ils l'ont fait pour les applications de bureau.

Ce n'est pas tant qu'un concurrent les fera trébucher, mais plutôt qu'ils trébucheront eux-mêmes. Avec l'essor des logiciels basés sur le Web, ils seront confrontés non seulement à des problèmes techniques, mais aussi à leurs propres désirs. Ce qu'ils doivent faire, c'est cannibaliser leur activité actuelle, et je ne les vois pas faire face à cela. La même obstination qui les a menés jusqu'ici va maintenant jouer contre eux. IBM était exactement dans la même situation, et ils n'ont pas réussi à la maîtriser. IBM a fait une entrée tardive et hésitante dans le secteur des micro-ordinateurs parce qu'ils étaient ambivalents quant à la menace qu'ils faisaient peser sur leur vache à lait, l'informatique centrale. Microsoft sera également gêné par sa volonté de sauver le bureau. Une vache à lait peut être un sacré singe sur le dos.

Je ne dis pas que personne ne dominera les applications basées sur serveur. Quelqu'un finira probablement par le faire. Mais je pense qu'il y aura une longue période de chaos joyeux, comme ce fut le cas aux débuts des micro-ordinateurs. C'était une bonne époque pour les startups. De nombreuses petites entreprises ont prospéré, et elles l'ont fait en créant des choses cool.

Les startups, mais pas seulement

La start-up classique est une start-up rapide et informelle, avec peu de personnel et peu d’argent. Ces quelques personnes travaillent très dur et la technologie amplifie l’effet des décisions qu’elles prennent. Si elles gagnent, elles gagnent gros.

Dans une start-up qui écrit des applications Web, tout ce que vous associez aux start-ups est poussé à l’extrême. Vous pouvez écrire et lancer un produit avec encore moins de personnes et encore moins d’argent. Vous devez être encore plus rapide et vous pouvez vous en sortir en étant plus informel. Vous pouvez littéralement lancer votre produit avec trois gars assis dans le salon d’un appartement et un serveur colocalisé chez un FAI. Nous l’avons fait.

Au fil du temps, les équipes sont devenues plus petites, plus rapides et plus informelles. En 1960, le développement de logiciels se résumait à une salle remplie d'hommes portant des lunettes à monture d'écaille et des cravates noires étroites, qui écrivaient avec assiduité dix lignes de code par jour sur des formulaires de codage IBM. En 1980, c'était une équipe de huit à dix personnes qui portaient des jeans au bureau et tapaient sur des vt100. Aujourd'hui, ce sont deux gars assis dans un salon avec des ordinateurs portables. (Et les jeans ne sont pas le summum de l'informalité.)

Les startups sont stressantes, et malheureusement, cela est aussi poussé à l'extrême avec les applications Web. De nombreuses sociétés de logiciels, surtout au début, connaissent des périodes où les développeurs dorment sous leur bureau, etc. Ce qui est alarmant avec les logiciels basés sur le Web, c'est que rien n'empêche que cela devienne la norme. Les histoires de personnes qui dorment sous leur bureau se terminent généralement ainsi : nous avons finalement expédié le produit et nous sommes tous rentrés chez nous pour dormir pendant une semaine. Les logiciels basés sur le Web ne sont jamais expédiés. Vous pouvez travailler 16 heures par jour aussi longtemps que vous le souhaitez. Et parce que vous le pouvez, et que vos concurrents le peuvent, vous avez tendance à être obligés de le faire. Vous pouvez, donc vous devez le faire. C'est la loi de Parkinson à l'envers.

Le pire n'est pas le nombre d'heures mais la responsabilité. Les programmeurs et les administrateurs système ont traditionnellement chacun leurs propres soucis. Les programmeurs doivent se soucier des bugs et les administrateurs système doivent se soucier de l'infrastructure. Les programmeurs peuvent passer une longue journée à travailler sur le code source, mais à un moment donné, ils peuvent rentrer chez eux et oublier tout ça. Les administrateurs système ne quittent jamais complètement leur travail, mais lorsqu'ils sont appelés à 4 heures du matin, ils n'ont généralement rien de très compliqué à faire. Avec les applications Web, ces deux types de stress se combinent. Les programmeurs deviennent administrateurs système, mais sans les limites clairement définies qui rendent généralement le travail supportable.

Chez Viaweb, nous avons passé les six premiers mois à écrire des logiciels. Nous avons travaillé les longues heures habituelles d’une jeune start-up. Dans une société de logiciels de bureau, c’était la partie où nous travaillions dur, mais cela ressemblait à des vacances comparé à la phase suivante, lorsque nous avons amené les utilisateurs sur notre serveur. Le deuxième plus grand avantage de vendre Viaweb à Yahoo (après l’argent) était de pouvoir transférer la responsabilité finale de l’ensemble sur les épaules d’une grande entreprise.

Les logiciels de bureau obligent les utilisateurs à devenir administrateurs système. Les logiciels basés sur le Web obligent les programmeurs à le faire. Le stress est moins important au total, mais plus important pour les programmeurs. Ce n'est pas forcément une mauvaise nouvelle. Si vous êtes une start-up en concurrence avec une grande entreprise, c'est une bonne nouvelle. [15] Les applications basées sur le Web offrent un moyen simple de surpasser vos concurrents. Aucune start-up n'en demande plus.

Juste assez bien

Une chose qui pourrait vous dissuader d'écrire des applications Web est la médiocrité des pages Web en tant qu'interface utilisateur. C'est un problème, je l'admets. Nous aurions vraiment aimé ajouter quelques éléments au HTML et au HTTP. Ce qui compte, cependant, c'est que les pages Web soient tout simplement suffisamment bonnes.

Il y a un parallèle à faire avec les premiers micro-ordinateurs. Les processeurs de ces machines n'étaient pas vraiment destinés à être les unités centrales des ordinateurs. Ils étaient conçus pour être utilisés dans des choses comme les feux de signalisation. Mais des gars comme Ed Roberts, qui a conçu l' Altair , ont compris qu'ils étaient tout simplement suffisants. On pouvait combiner l'une de ces puces avec de la mémoire (256 octets dans le premier Altair) et des commutateurs sur le panneau avant, et on avait un ordinateur fonctionnel. Pouvoir avoir son propre ordinateur était si excitant que beaucoup de gens voulaient en acheter, même si c'était limité.

Les pages Web n'ont pas été conçues pour servir d'interface utilisateur pour des applications, mais elles sont tout simplement suffisantes. Et pour un nombre significatif d'utilisateurs, un logiciel utilisable à partir de n'importe quel navigateur sera un avantage suffisant pour compenser toute gêne dans l'interface utilisateur. Vous ne pouvez peut-être pas écrire la plus belle feuille de calcul en HTML, mais vous pouvez écrire une feuille de calcul que plusieurs personnes peuvent utiliser simultanément à partir de différents emplacements sans logiciel client spécial, ou qui peut incorporer des flux de données en direct, ou qui peut vous appeler lorsque certaines conditions sont déclenchées. Plus important encore, vous pouvez écrire de nouveaux types d'applications qui n'ont même pas encore de nom. VisiCalc n'était pas simplement une version micro-ordinateur d'une application mainframe, après tout, c'était un nouveau type d'application.

Bien sûr, les applications basées sur un serveur ne sont pas forcément basées sur le Web. Vous pourriez avoir un autre type de client. Mais je suis presque sûr que c'est une mauvaise idée. Il serait très pratique de supposer que tout le monde installerait votre client – si pratique que vous pourriez facilement vous convaincre que tout le monde le ferait – mais si ce n'est pas le cas, vous êtes foutu. Comme les logiciels basés sur le Web ne supposent rien sur le client, ils fonctionneront partout où le Web fonctionne. C'est déjà un gros avantage, et cet avantage s'accroîtra à mesure que de nouveaux appareils Web proliféreront. Les utilisateurs vous apprécieront parce que votre logiciel fonctionne, tout simplement, et votre vie sera plus facile parce que vous n'aurez pas à le modifier pour chaque nouveau client. [16]

J'ai l'impression d'avoir suivi l'évolution du Web aussi attentivement que quiconque, et je ne peux pas prédire ce qui va se passer avec les clients. La convergence est probablement en cours, mais où ? Je ne peux pas choisir un vainqueur. Une chose que je peux prédire est un conflit entre AOL et Microsoft. Quelle que soit la forme que prendra le .NET de Microsoft, il s'agira probablement de connecter le bureau aux serveurs. À moins qu'AOL ne riposte, ils seront soit mis de côté, soit transformés en un canal entre les logiciels client et serveur de Microsoft. Si Microsoft et AOL se lancent dans une guerre des clients, la seule chose qui fonctionnera sur les deux sera la navigation sur le Web, ce qui signifie que les applications basées sur le Web seront les seules à fonctionner partout.

Comment tout cela va-t-il se passer ? Je ne sais pas. Et vous n'avez pas besoin de savoir si vous pariez sur les applications Web. Personne ne peut y mettre fin sans mettre en péril la navigation. Le Web n'est peut-être pas le seul moyen de fournir des logiciels, mais c'est un moyen qui fonctionne aujourd'hui et qui continuera de fonctionner pendant longtemps. Les applications Web sont peu coûteuses à développer et faciles à fournir, même pour la plus petite des startups. Elles demandent beaucoup de travail et sont particulièrement stressantes, mais cela ne fait qu'améliorer les chances des startups.

Pourquoi pas?

EB White a appris avec amusement par un ami agriculteur que de nombreuses clôtures électrifiées ne sont pas traversées par du courant. Les vaches apprennent apparemment à s'en tenir éloignées, et après cela, elles n'ont plus besoin de courant. « Debout, vaches ! » a-t-il écrit, « Prenez votre liberté pendant que les despotes ronflent ! »

Si vous êtes un hacker qui a pensé à créer un jour une start-up, il y a probablement deux choses qui vous empêchent de le faire. La première est que vous ne connaissez rien aux affaires. La deuxième est que vous avez peur de la concurrence. Aucune de ces barrières n'a de valeur.

Il n'y a que deux choses que vous devez savoir sur les affaires : créer quelque chose que les utilisateurs aiment et gagner plus que ce que vous dépensez. Si vous maîtrisez ces deux éléments, vous aurez une longueur d'avance sur la plupart des startups. Vous pourrez découvrir le reste au fur et à mesure.

Au début, vous ne gagnerez peut-être pas plus que vous ne dépenserez, mais tant que l'écart se réduira assez vite, tout ira bien. Si vous démarrez avec un budget insuffisant, cela encouragera au moins une habitude de frugalité. Moins vous dépensez, plus il est facile de gagner plus que vous ne dépensez. Heureusement, il peut être très bon marché de lancer une application Web. Nous avons lancé notre entreprise avec moins de 10 000 dollars, et ce serait encore moins cher aujourd'hui. Nous avons dû dépenser des milliers de dollars pour un serveur, et des milliers de plus pour obtenir SSL. (La seule société qui vendait des logiciels SSL à l'époque était Netscape.) Aujourd'hui, vous pouvez louer un serveur beaucoup plus puissant, avec SSL inclus, pour moins que ce que nous avons payé pour la bande passante seule. Vous pourriez lancer une application Web aujourd'hui pour moins que le prix d'une chaise de bureau de luxe.

Pour ce qui est de créer quelque chose que les utilisateurs aiment, voici quelques conseils généraux. Commencez par créer quelque chose de propre et de simple que vous voudriez utiliser vous-même. Sortez rapidement une version 1.0, puis continuez à améliorer le logiciel, en écoutant attentivement les utilisateurs. Le client a toujours raison, mais différents clients ont raison sur différentes choses ; les utilisateurs les moins sophistiqués vous montrent ce que vous devez simplifier et clarifier, et les plus sophistiqués vous disent quelles fonctionnalités vous devez ajouter. La meilleure chose qu'un logiciel puisse être est simple, mais la façon d'y parvenir est de bien définir les paramètres par défaut, et non de limiter les choix des utilisateurs. Ne soyez pas complaisant si le logiciel de vos concurrents est médiocre ; la norme à laquelle comparer votre logiciel est ce qu'il pourrait être, pas ce que vos concurrents actuels ont. Utilisez votre logiciel vous-même, tout le temps. Viaweb était censé être un créateur de boutique en ligne, mais nous l'avons également utilisé pour créer notre propre site. N'écoutez pas les responsables marketing, les concepteurs ou les chefs de produit simplement en raison de leur titre professionnel. S'ils ont de bonnes idées, utilisez-les, mais c'est à vous de décider ; Les logiciels doivent être conçus par des hackers qui comprennent le design, et non par des designers qui s'y connaissent un peu en logiciels. Si vous ne savez pas concevoir un logiciel et le mettre en œuvre, ne créez pas de startup.

Parlons maintenant de la concurrence. Ce dont vous avez peur, ce ne sont pas des groupes de hackers comme vous, mais des entreprises, avec des bureaux, des business plans, des commerciaux, etc., n'est-ce pas ? Eh bien, ils ont plus peur de vous que vous d'eux, et ils ont raison. Il est beaucoup plus facile pour quelques hackers de trouver comment louer des bureaux ou embaucher des commerciaux que pour une entreprise, quelle que soit sa taille, de faire écrire un logiciel. J'ai été des deux côtés, et je sais. Lorsque Viaweb a été racheté par Yahoo, je me suis soudain retrouvé à travailler pour une grande entreprise, et c'était comme essayer de courir dans de l'eau jusqu'à la taille.

Je ne veux pas dénigrer Yahoo. Ils avaient de bons hackers et la direction était vraiment très douée. Pour une grande entreprise, ils étaient exceptionnels. Mais ils n'étaient toujours qu'à un dixième de la productivité d'une petite start-up. Aucune grande entreprise ne peut faire mieux que ça. Ce qui est effrayant avec Microsoft, c'est qu'une entreprise aussi grande puisse développer des logiciels. C'est comme une montagne sur laquelle on peut marcher.

Ne vous laissez pas intimider. Vous pouvez faire autant de choses que Microsoft ne peut pas faire que vous ne pouvez pas faire. Et personne ne peut vous en empêcher. Vous n'avez pas besoin de demander la permission à qui que ce soit pour développer des applications Web. Vous n'avez pas besoin de conclure des accords de licence, ni d'obtenir de l'espace dans les magasins de détail, ni de ramper pour que votre application soit fournie avec le système d'exploitation. Vous pouvez fournir des logiciels directement au navigateur, et personne ne peut s'immiscer entre vous et les utilisateurs potentiels sans les empêcher de naviguer sur le Web.

Vous ne le croirez peut-être pas, mais je vous le promets, Microsoft a peur de vous. Les cadres intermédiaires complaisants ne le sont peut-être pas, mais Bill, lui, si, car il était comme vous une fois, en 1975, la dernière fois qu'une nouvelle façon de fournir des logiciels est apparue.

Remarques

[1] Conscientes qu’une grande partie de l’argent est dans les services, les entreprises qui construisent des clients légers ont généralement essayé de combiner le matériel avec un service en ligne . Cette approche n’a pas bien fonctionné, en partie parce qu’il faut deux types d’entreprises différentes pour fabriquer des produits électroniques grand public et pour gérer un service en ligne, et en partie parce que les utilisateurs détestent l’idée. Offrir le rasoir et gagner de l’argent avec les lames peut fonctionner pour Gillette, mais un rasoir représente un engagement bien moindre qu’un terminal Web. Les fabricants de téléphones portables se contentent de vendre du matériel sans essayer de capter également les revenus du service. Ce devrait probablement être le modèle pour les clients Internet également. Si quelqu’un vendait simplement une jolie petite boîte avec un navigateur Web que vous pourriez utiliser pour vous connecter via n’importe quel FAI, tous les technophobes du pays en achèteraient un.

[2] La sécurité dépend toujours plus de la capacité à ne pas faire d'erreurs que de toute décision de conception, mais la nature des logiciels basés sur serveur obligera les développeurs à prêter davantage attention à ne pas faire d'erreurs. La compromission d'un serveur pourrait causer de tels dommages que les ASP (qui veulent rester en activité) seront probablement plus prudents en matière de sécurité.

[3] En 1995, lorsque nous avons lancé Viaweb, les applets Java étaient censées être la technologie que tout le monde allait utiliser pour développer des applications basées sur un serveur. Les applets nous semblaient une idée démodée. Télécharger des programmes à exécuter sur le client ? Il était plus simple d'aller jusqu'au bout et d'exécuter les programmes sur le serveur. Nous n'avons pas perdu de temps sur les applets, mais d'innombrables autres startups ont dû être attirées dans ce gouffre. Peu d'entre elles auraient pu s'en sortir vivantes, ou Microsoft n'aurait pas pu s'en tirer en abandonnant Java dans la version la plus récente d'Explorer.

[4] Ce point est dû à Trevor Blackwell, qui ajoute : « Le coût d'écriture d'un logiciel augmente de manière plus que linéaire avec sa taille. Cela est peut-être principalement dû à la correction des anciens bugs, et le coût peut être plus linéaire si tous les bugs sont trouvés rapidement. »

[5] Le type de bogue le plus difficile à trouver peut être une variante de bogue composé où un bogue compense un autre. Lorsque vous corrigez un bogue, l'autre devient visible. Mais il semblera que le correctif soit en cause, puisque c'est la dernière chose que vous avez modifiée.

[6] Chez Viaweb, nous avons organisé un concours pour décrire le pire aspect de notre logiciel. Deux personnes du service client ont remporté le premier prix ex-aequo, avec des réponses dont je me souviens encore avec des frissons. Nous avons immédiatement résolu les deux problèmes.

[7] Robert Morris a écrit le système de commande que les acheteurs utilisaient pour passer des commandes. Trevor Blackwell a écrit le générateur d'images et le gestionnaire que les commerçants utilisaient pour récupérer les commandes, consulter les statistiques et configurer les noms de domaine, etc. J'ai écrit l'éditeur que les commerçants utilisaient pour créer leurs sites. Le système de commande et le générateur d'images ont été écrits en C et C++, le gestionnaire principalement en Perl et l'éditeur en Lisp .

[8] La discrimination par les prix est si répandue (combien de fois avez-vous entendu un détaillant prétendre que son pouvoir d’achat signifiait pour vous des prix plus bas ?) que j’ai été surpris d’apprendre qu’elle était interdite aux États-Unis par la loi Robinson-Patman de 1936. Cette loi ne semble pas être appliquée avec vigueur.

[9] Dans No Logo, Naomi Klein affirme que les marques de vêtements privilégiées par les « jeunes urbains » ne font pas trop d’efforts pour empêcher le vol à l’étalage car sur leur marché cible, les voleurs à l’étalage sont aussi les leaders de la mode.

[10] Les entreprises se demandent souvent ce qu'elles doivent ou non externaliser. Une réponse possible : externaliser tout travail qui n'est pas directement exposé à la pression concurrentielle, car l'externaliser l'exposerait ainsi à la pression concurrentielle.

[11] Les deux hommes étaient Dan Bricklin et Bob Frankston. Dan a écrit un prototype en Basic en quelques jours, puis au cours de l'année suivante, ils ont travaillé ensemble (principalement la nuit) pour créer une version plus puissante écrite en langage machine 6502. Dan était à la Harvard Business School à l'époque et Bob avait nominalement un travail de jour pour écrire des logiciels. "Il n'y avait pas de grand risque à faire des affaires", a écrit Bob, "si ça échouait, c'était un échec. Ce n'était pas grave."

[12] Ce n'est pas aussi simple que je le prétends. Il a fallu un temps terriblement long pour que le bouche-à-oreille se fasse entendre et nous n'avons commencé à bénéficier d'une couverture médiatique importante que lorsque nous avons engagé une agence de relations publiques (il faut reconnaître que c'est la meilleure du secteur) pour 16 000 $ par mois. Il est vrai cependant que le seul canal significatif était notre propre site Web.

[13] Si le Mac était si génial, pourquoi a-t-il perdu ? Le coût, encore une fois. Microsoft s'est concentré sur le marché des logiciels et a lancé une multitude de fournisseurs de composants bon marché sur le matériel Apple. Le fait que les costumes aient pris le dessus pendant une période critique n'a pas aidé non plus.

[14] Un bon navigateur open source pourrait aider les applications Web et empêcher la prochaine génération de logiciels d'être éclipsée par Microsoft. Mozilla est un logiciel open source mais semble avoir souffert d'avoir été un logiciel d'entreprise pendant si longtemps. Un petit navigateur rapide et activement maintenu serait une bonne chose en soi et encouragerait probablement aussi les entreprises à construire de petits appareils Web.

Entre autres choses, un navigateur open source approprié permettrait à HTTP et HTML de continuer à évoluer (comme l'a fait Perl par exemple). Cela aiderait grandement les applications Web à pouvoir faire la distinction entre la sélection d'un lien et son suivi ; tout ce qu'il faudrait faire serait une amélioration triviale de HTTP, pour autoriser plusieurs URL dans une requête. Les menus en cascade seraient également une bonne chose.

Si vous voulez changer le monde, écrivez une nouvelle mosaïque. Vous pensez qu'il est trop tard ? En 1998, beaucoup de gens pensaient qu'il était trop tard pour lancer un nouveau moteur de recherche, mais Google leur a prouvé le contraire. Il y a toujours de la place pour quelque chose de nouveau si les options actuelles sont suffisamment mauvaises. Assurez-vous d'abord que cela fonctionne sur tous les systèmes d'exploitation gratuits : les nouveautés commencent avec leurs utilisateurs.

[15] Trevor Blackwell, qui en sait probablement plus sur ce sujet par expérience personnelle que quiconque, écrit :

« J'irais même plus loin en disant que les logiciels basés sur serveur sont si difficiles pour les programmeurs qu'ils provoquent un changement économique fondamental qui éloigne les grandes entreprises. Ils exigent des programmeurs un niveau d'intensité et de dévouement qu'ils ne seront prêts à fournir que s'ils sont au sein de leur propre entreprise. Les sociétés de logiciels peuvent embaucher des personnes qualifiées pour travailler dans un environnement pas trop exigeant, et peuvent embaucher des personnes non qualifiées pour supporter les difficultés, mais elles ne peuvent pas embaucher des personnes hautement qualifiées pour se démener. Comme le capital n'est plus nécessaire, les grandes entreprises n'ont plus grand-chose à proposer. »

[16] Dans la version originale de cet essai, je conseillais d'éviter Javascript. C'était une bonne idée en 2001, mais Javascript fonctionne désormais.

Merci à Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson et Dan Giffin pour avoir lu les brouillons de cet article ; à Dan Bricklin et Bob Frankston pour les informations sur VisiCalc ; et encore à Ken Anderson pour m'avoir invité à parler au BBN.

Vous trouverez cet essai et 14 autres dans Hackers & Painters .