L'Autre Voie à Venir | Essais de Paul Graham

Septembre 2001

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

À l'été 1995, mon ami Robert Morris et moi avons décidé de lancer une startup. La campagne de relations publiques précédant l'introduction en bourse de Netscape battait son plein alors, et il était beaucoup question de commerce en ligne dans la presse. À l'époque, il y avait peut-être une trentaine de boutiques réelles sur le Web, 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 écrire.

Durant la première semaine environ, nous avions l'intention d'en faire 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 était clair que c'était la voie à suivre. Si nous écrivions notre logiciel pour qu'il s'exécute sur le serveur, ce serait beaucoup plus facile 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 boutiques 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 affirmions que le logiciel s'exécutait sur le serveur. Ce n'est qu'après le lancement de Hotmail un an plus tard que les gens ont commencé à comprendre. Maintenant, tout le monde sait que c'est une approche valide. Il y a maintenant un nom pour ce que nous étions : un Fournisseur de Services Applicatifs, ou ASP.

Je pense qu'une grande partie de la prochaine génération de logiciels sera écrite sur ce modèle. Même Microsoft, qui a le plus à perdre, semble voir l'inévitabilité de déplacer certaines choses du bureau. Si les logiciels quittent le bureau pour les 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 se déplacent vers les serveurs, ce que je décris ici est l'avenir.

La Prochaine Étape ?

Lorsque nous repenserons à l'ère des logiciels de bureau, je pense que nous nous émerveillerons des inconvénients que les gens ont supportés, tout comme nous nous émerveillons maintenant de ce que les premiers propriétaires de voitures ont supporté. Pendant les vingt ou trente premières années, il fallait être un expert automobile pour posséder une voiture. Mais les voitures étaient un tel avantage que beaucoup de gens qui n'étaient pas des experts automobiles voulaient en avoir aussi.

Les ordinateurs sont dans cette phase maintenant. Lorsque vous possédez un ordinateur de bureau, vous finissez par en apprendre beaucoup plus que vous ne le souhaitiez sur ce qui se passe à l'intérieur. Mais plus de la moitié des foyers aux États-Unis en possèdent un. Ma mère a un ordinateur qu'elle utilise pour les e-mails et pour tenir ses comptes. Il y a environ un an, elle a été alarmée de recevoir une lettre d'Apple, lui offrant une réduction sur une nouvelle version du système d'exploitation. Il y a quelque chose qui ne va pas quand une femme de soixante-cinq ans qui veut utiliser un ordinateur pour les e-mails et les 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", encore moins "pilote de périphérique" ou "correctif".

Il existe maintenant une autre façon de livrer des logiciels qui évitera aux utilisateurs de devenir des 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 facile, 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 à penser à rien d'autre qu'aux applications qu'ils utilisent. Tout le désordre, les choses changeantes seront sur un serveur quelque part, maintenues par le genre de personnes qui sont douées pour ce genre de choses. Et donc, vous n'aurez pas besoin d'un ordinateur, en soi, pour utiliser un logiciel. Tout ce dont vous aurez besoin sera quelque chose avec un clavier, un écran et un navigateur Web. Peut-être aura-t-il un accès Internet sans fil. Peut-être sera-ce aussi votre téléphone portable. Quoi qu'il en soit, ce sera de l'é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 vous le faites actuellement avec les téléphones. [1]

Il faudra environ un dixième de seconde pour qu'un clic arrive au serveur et revienne, donc les utilisateurs de logiciels très interactifs, comme Photoshop, voudront toujours que les calculs se fassent sur le bureau. Mais si vous regardez le genre de choses pour lesquelles la plupart des gens utilisent des ordinateurs, une latence d'un dixième de seconde 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.

Le Gain pour les Utilisateurs

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

Pour utiliser une application purement Web, tout ce dont vous avez besoin est 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 piégé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.

La pointe de l'iceberg ici était l'e-mail basé sur le Web. Des millions de personnes réalisent maintenant qu'elles devraient avoir accès à leurs messages e-mail, peu importe où elles se trouvent. Et si vous pouvez voir 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 piégées sur un ordinateur posé sur un bureau lointain ?

Toute l'idée de "votre ordinateur" est en train de disparaître, remplacée par "vos données". Vous devriez pouvoir accéder à vos données depuis n'importe quel ordinateur. Ou plutôt, n'importe quel client, et un client n'a pas besoin d'être un ordinateur.

Les clients ne devraient pas stocker de données ; ils devraient être comme des téléphones. En fait, ils pourraient devenir des téléphones, ou vice versa. Et à mesure que les clients deviennent plus petits, vous avez une autre raison de ne pas y conserver vos données : quelque chose que vous transportez avec vous peut être perdu ou volé. Laisser votre PDA dans un taxi, c'est comme un plantage de disque, sauf que vos données sont remises à quelqu'un d'autre au lieu d'être vaporisées.

Avec un logiciel purement 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 quand il n'y a pas d'installation, vous n'avez pas à vous soucier que l'installation se passe mal. Il ne peut pas y avoir d'incompatibilités entre l'application et votre système d'exploitation, car le logiciel ne s'exécute pas sur votre système d'exploitation.

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

Après avoir essayé la démo, l'inscription au service ne devrait nécessiter rien de plus que le remplissage d'un bref formulaire (le plus bref sera le mieux). Et ce devrait être le dernier travail que l'utilisateur ait à faire. Avec les logiciels basés sur le Web, vous devriez obtenir de nouvelles versions sans payer de supplément, ni faire aucun travail, ni même éventuellement le savoir.

Les mises à jour ne seront pas les grands chocs qu'elles sont maintenant. Au fil du temps, les applications gagneront discrètement en puissance. Cela demandera un certain effort de la part des développeurs. Ils devront concevoir des logiciels de manière à ce qu'ils puissent être mis à jour sans dérouter les utilisateurs. C'est un nouveau problème, 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 basés sur le Web devraient donc avoir beaucoup moins de bugs que les logiciels de bureau. Chez Viaweb, je doute que nous ayons jamais eu plus de dix bugs connus à la fois. C'est des ordres de grandeur meilleurs 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 réaliseront que c'est possible. Il sera souvent utile de laisser deux personnes modifier le même document, par exemple. Viaweb permettait à plusieurs utilisateurs de modifier 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 veuillent, mais il s'est avéré que beaucoup le faisaient.

Lorsque vous utilisez une application Web, vos données seront plus sûres. Les plantages de disque ne seront pas une chose du passé, mais les utilisateurs n'en entendront plus parler. Ils se produiront au sein des fermes de serveurs. Et les entreprises proposant des applications Web feront réellement des sauvegardes – non seulement parce qu'elles auront de vrais administrateurs système qui s'en soucieront, mais parce qu'un FSA qui perd les données des gens aura de très, très gros problèmes. Lorsque les gens perdent leurs propres données lors d'un plantage de disque, ils ne peuvent pas être si en colère, car ils n'ont qu'eux-mêmes à blâmer. Lorsqu'une entreprise perd leurs données pour eux, ils seront beaucoup 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 chances d'exécuter des virus, et aucune donnée localement à endommager. Et un programme qui attaquerait les serveurs eux-mêmes les trouverait très bien défendus. [2]

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

Ville de Code

Pour les développeurs, la différence la plus frappante entre les logiciels basés sur le Web et les logiciels de bureau est qu'une application Web n'est pas une pièce de code unique. Ce sera une collection de programmes de différents types plutôt qu'un gros binaire unique. Et donc, concevoir un logiciel basé sur le Web, c'est comme concevoir une ville plutôt qu'un bâtiment : en plus des bâtiments, vous avez besoin de routes, de panneaux de signalisation, de services publics, de services de police et d'incendie, et de plans pour la croissance et divers types de catastrophes.

Chez Viaweb, le logiciel comprenait des applications assez volumineuses avec lesquelles les utilisateurs interagissaient directement, des programmes que ces programmes utilisaient, des programmes qui tournaient constamment en arrière-plan à la recherche de problèmes, des programmes qui tentaient de redémarrer les choses si elles tombaient en panne, des programmes qui s'exécutaient occasionnellement pour compiler des statistiques ou construire des index pour les recherches, des programmes que nous exécutions explicitement pour collecter les ressources inutilisées ou pour déplacer ou restaurer des données, des programmes qui se faisaient passer pour des utilisateurs (pour mesurer les performances ou exposer les bugs), des programmes pour diagnostiquer les problèmes réseau, des programmes pour faire des sauvegardes, des interfaces vers des services externes, 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 boutiques vers de nouveaux serveurs à travers le pays, sans les arrêter, après que nous ayons été achetés par Yahoo. Les programmes nous ont alertés, ont envoyé des fax et des e-mails aux utilisateurs, ont effectué des transactions avec des processeurs de cartes de crédit, et ont communiqué entre eux via des sockets, des pipes, des requêtes http, ssh, des paquets udp, de la mémoire partagée et des fichiers. Une partie de Viaweb consistait même en l'absence de programmes, car l'une des clés de la sécurité Unix est de ne pas exécuter d'utilitaires inutiles que les gens pourraient utiliser pour s'introduire dans vos serveurs.

Cela ne s'est pas arrêté au logiciel. Nous avons passé beaucoup de temps à réfléchir aux configurations de serveur. 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 devions nous demander si notre FAI en amont avait des connexions suffisamment rapides vers tous les backbones. Nous avons évalué en série des fournisseurs de RAID.

Mais le matériel n'est pas seulement une source de soucis. Lorsque vous le contrôlez, vous pouvez faire plus pour les utilisateurs. Avec une application de bureau, vous pouvez spécifier un certain matériel minimum, mais vous ne pouvez pas en ajouter davantage. Si vous administrez les serveurs, vous pouvez en une seule étape permettre à tous vos utilisateurs d'alerter des personnes, ou d'envoyer des fax, ou d'envoyer des commandes par téléphone, ou de traiter des cartes de crédit, etc., simplement en installant le matériel pertinent. 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 comme un moyen de nous distinguer de nos concurrents qui (soit parce qu'ils vendaient des logiciels de bureau, soit revendaient des applications Web via des FAI) n'avaient pas de contrôle direct sur le matériel.

Parce que le logiciel dans une application Web sera une collection de programmes plutôt qu'un seul binaire, il peut être écrit dans n'importe quel nombre de langages différents. Lorsque vous écrivez un logiciel de bureau, vous êtes pratiquement forcé d'écrire l'application dans le même langage que le système d'exploitation sous-jacent – c'est-à-dire C et C++. Et ainsi ces langages (surtout parmi les personnes non techniques comme les managers et les VC) ont été considérés comme les langages pour le 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 n'importe quel langage que vous voulez. [3] Aujourd'hui, beaucoup des meilleurs hackers utilisent des langages très éloignés de C et C++ : Perl, Python, et même Lisp.

Avec les logiciels basés sur serveur, personne ne peut vous dire quel langage utiliser, car vous contrôlez l'ensemble du système, jusqu'au matériel. Différents langages sont bons pour différentes tâches. Vous pouvez utiliser celui qui est le meilleur pour chaque tâche. 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 changer 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 avons pu faire en sorte que l'éditeur Viaweb se comporte davantage comme un logiciel de bureau.

Versions

L'un des changements les plus importants dans ce nouveau monde est la façon dont vous faites les versions. Dans le secteur des logiciels de bureau, faire une version est un énorme traumatisme, où toute l'entreprise sue et se démène pour sortir une seule et gigantesque pièce de code. Des comparaisons évidentes s'imposent, tant pour le processus que pour le produit résultant.

Avec les logiciels basés sur serveur, vous pouvez apporter des modifications presque comme vous le feriez dans un programme que vous écririez pour vous-même. Vous livrez le logiciel comme une série de changements incrémentiels au lieu d'une grande explosion occasionnelle. Une entreprise de logiciels de bureau typique pourrait faire une ou deux versions par an. Chez Viaweb, nous faisions 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 façon dont il est livré. Beaucoup des problèmes les plus désagréables que vous rencontrez dans le secteur des logiciels de bureau sont dus à la nature catastrophique des versions.

Lorsque vous ne livrez qu'une seule nouvelle version par an, vous avez tendance à traiter les bugs en gros. Quelque temps avant la date de sortie, vous assemblez une nouvelle version dans laquelle la moitié du code a été arrachée et remplacée, introduisant d'innombrables bugs. Ensuite, une équipe de personnes de l'assurance qualité (QA) intervient et commence à les compter, et les programmeurs travaillent sur la liste, les corrigeant. Ils n'arrivent généralement pas au bout de la liste, et en fait, personne ne sait où se trouve la fin. C'est comme pêcher des débris dans un étang. Vous ne savez jamais vraiment ce qui se passe à l'intérieur du logiciel. Au mieux, vous obtenez une sorte de correction statistique.

Avec les logiciels basés sur serveur, la plupart des changements sont petits et incrémentiels. Cela en soi est moins susceptible d'introduire des bugs. Cela signifie également que vous savez ce qu'il faut tester le plus attentivement lorsque vous êtes sur le point de livrer un logiciel : la dernière chose que vous avez modifiée. Vous obtenez 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 scannant le tableau de bord, pas comme un détective essayant de démêler un mystère.

Les logiciels de bureau engendrent un certain fatalisme concernant les bugs. Vous savez que vous livrez quelque chose rempli de bugs, et vous avez même mis en place des mécanismes pour compenser cela (par exemple, les versions de correctifs). Alors pourquoi s'inquiéter de quelques-uns de plus ? Bientôt, vous livrez des fonctionnalités entières que vous savez défectueuses. Apple l'a fait plus tôt cette année. Ils se sentaient sous pression de livrer leur nouvel OS, dont la date de sortie avait déjà été repoussée quatre fois, mais une partie du logiciel (le support pour les CD et DVD) n'était pas prête. La solution ? Ils ont livré l'OS 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 à livrer un logiciel avant qu'il ne fonctionne, et vous pouvez le livrer dès qu'il fonctionne.

Le vétéran de l'industrie pense peut-être que c'est une belle idée de dire que vous n'avez jamais à livrer 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 les logiciels basés sur le Web, vous ne feriez pas une telle promesse, car il n'y a pas de versions. Votre logiciel change progressivement et continuellement. Certains changements peuvent être plus importants que d'autres, mais l'idée de versions ne s'adapte tout simplement pas naturellement aux logiciels basés sur le Web.

Si quelqu'un se souvient de Viaweb, cela peut sembler étrange, car nous annoncions toujours de nouvelles versions. Cela était fait entièrement à des fins de relations publiques. La presse spécialisée, avons-nous appris, pense en numéros de version. Ils vous donneront une couverture majeure pour une version majeure, c'est-à-dire un nouveau premier chiffre sur le numéro de version, et généralement un paragraphe au maximum pour une version ponctuelle, c'est-à-dire un nouveau chiffre après la virgule.

Certains de nos concurrents proposaient des logiciels de bureau et avaient effectivement des numéros de version. Et pour ces versions, le simple fait de leur existence nous semblait une preuve de leur retard, ils obtenaient toutes sortes de publicité. Nous ne voulions pas manquer cela, alors nous avons commencé à donner des numéros de version à nos logiciels aussi. Lorsque nous voulions de la publicité, nous faisions une liste de toutes les fonctionnalités que nous avions ajoutées depuis la dernière "version", collions un nouveau numéro de version sur le logiciel, et émettions un communiqué de presse disant que la nouvelle version était disponible immédiatement. Étonnamment, personne ne nous a jamais interpellés à ce sujet.

Au moment où nous avons été achetés, nous avions fait cela trois fois, nous étions donc à la Version 4. Version 4.1 si je me souviens bien. Après que Viaweb soit devenu Yahoo Store, il n'y avait plus un besoin aussi désespéré de publicité, alors bien que le logiciel ait continué à évoluer, toute l'idée des numéros de version a été discrètement abandonnée.

Bugs

L'autre avantage technique majeur des logiciels basés sur le Web est que vous pouvez reproduire la plupart des bugs. Vous avez les données des utilisateurs directement sur votre disque. Si quelqu'un fait planter votre logiciel, vous n'avez pas à essayer de deviner ce qui se passe, comme vous le feriez avec un logiciel de bureau : vous devriez être capable de reproduire l'erreur pendant qu'ils sont au téléphone avec vous. Vous pourriez même le savoir déjà, si vous avez du code de détection d'erreurs intégré à votre application.

Les logiciels basés sur le Web sont utilisés 24 heures sur 24, donc tout ce que vous faites est immédiatement passé au crible. Les bugs apparaissent rapidement.

Les entreprises de logiciels sont parfois accusées 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 un bon plan, car les bugs sont moins nombreux et transitoires. Lorsque vous livrez des logiciels progressivement, vous avez beaucoup moins de bugs au départ. Et lorsque vous pouvez reproduire les erreurs et livrer les changements instantanément, vous pouvez trouver et corriger la plupart des bugs dès qu'ils apparaissent. Nous n'avons jamais eu suffisamment de bugs à la fois pour nous soucier d'un système formel de suivi des bugs.

Vous devriez bien sûr tester les changements avant de les livrer, de sorte qu'aucun bug majeur ne devrait être livré. Les quelques-uns qui inévitablement s'échappent impliqueront des cas limites et n'affecteront que les quelques utilisateurs qui les rencontreront avant que quelqu'un n'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.

Corriger les bugs frais est plus facile que de corriger les anciens. Il est généralement assez rapide de trouver un bug dans le code que vous venez d'écrire. Quand il apparaît, vous savez souvent ce qui ne va pas avant même de regarder le code source, car vous vous en inquiétiez déjà inconsciemment. Corriger un bug dans quelque chose que vous avez écrit il y a six mois (le cas moyen si vous livrez 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 maladroite, ou même d'introduire plus de bugs. [4]

Lorsque vous détectez les bugs tôt, vous avez également moins de bugs composés. Les bugs composés sont deux bugs distincts qui interagissent : vous trébuchez en descendant les escaliers, et lorsque vous cherchez la main courante, elle vous reste 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 "tout casser puis filtrer les bugs" produit intrinsèquement beaucoup de bugs composés. Et les logiciels qui sont livrés en une série de petits changements ont intrinsèquement tendance à ne pas le faire. Les sols sont constamment balayés de tout objet lâche qui pourrait plus tard se coincer dans quelque chose.

Cela aide si vous utilisez une technique appelée programmation fonctionnelle. La programmation fonctionnelle signifie éviter les effets de bord. C'est quelque chose que vous êtes plus susceptible 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 en code purement fonctionnel, mais vous pouvez écrire des morceaux substantiels de cette manière. Cela rend ces parties de votre logiciel plus faciles à tester, car elles n'ont pas d'état, et c'est très pratique dans une situation où vous faites 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. Étant donné que la plupart des bugs livrés impliquaient des cas limites, les utilisateurs qui les rencontraient étaient susceptibles d'être des utilisateurs avancés, repoussant les limites. Les utilisateurs avancés sont plus indulgents envers les bugs, d'autant plus que vous les avez probablement introduits en ajoutant une fonctionnalité qu'ils demandaient. En fait, parce que 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 contre nous.

Support

Lorsque vous pouvez reproduire les erreurs, cela change votre approche du support client. Dans la plupart des entreprises de logiciels, le support est offert 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 quoi. Dans les deux cas, vous ne pouvez pas apprendre grand-chose d'eux. Et donc vous avez tendance à considérer les appels de support comme une corvée que vous voulez isoler de vos développeurs autant que possible.

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

Ainsi, chez Viaweb, les développeurs étaient toujours en contact étroit avec le support. Les personnes du support client étaient à une dizaine de mètres des programmeurs, et savaient qu'elles pouvaient toujours interrompre n'importe quoi avec un rapport de bug authentique. Nous quittions une réunion du conseil d'administration pour corriger un bug sérieux.

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 apportant des nouvelles importantes. Les personnes du support client aimaient cela car cela signifiait qu'elles pouvaient aider les utilisateurs, au lieu de leur lire des scripts. Et les programmeurs aimaient cela car 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 entreprises 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 susceptible d'être unidirectionnelle : les personnes du support qui entendent parler des bugs remplissent un formulaire qui est finalement transmis (éventuellement via l'AQ) aux programmeurs, qui le mettent sur leur liste de choses à faire. C'était très différent chez Viaweb. Moins d'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 l'entendant dire "Merde, vous avez raison, c'est un bug." Cela ravissait les personnes du support d'entendre ce "vous avez raison" de la part des hackers. Elles nous apportaient des bugs avec le même air d'attente qu'un chat vous apportant une souris qu'il vient de tuer. Cela les rendait également plus prudentes dans l'évaluation de la gravité d'un bug, car leur honneur était désormais en jeu.

Après que nous ayons été achetés par Yahoo, les personnes du support client ont été éloignées des programmeurs. Ce n'est qu'alors que nous avons réalisé qu'elles étaient effectivement l'AQ et dans une certaine mesure le marketing également. En plus de détecter les bugs, elles étaient les gardiennes de la connaissance de choses plus vagues, ressemblant à des bugs, comme les fonctionnalités qui confondaient les utilisateurs. [6] Elles étaient également une sorte de groupe de discussion par procuration ; nous pouvions leur demander laquelle de deux nouvelles fonctionnalités les utilisateurs voulaient le plus, et elles avaient toujours raison.

Moral

Pouvoir livrer un logiciel immédiatement est une grande motivation. Souvent, en marchant pour aller au travail, je pensais à un changement que je voulais apporter au logiciel, et je le faisais ce jour-là. Cela fonctionnait aussi pour des fonctionnalités plus importantes. Même si quelque chose devait prendre deux semaines à écrire (peu de projets prenaient plus de temps), je savais que je pouvais voir l'effet dans le logiciel dès que c'était fait.

Si j'avais dû attendre un an pour la prochaine version, j'aurais mis de côté la plupart de ces idées, au moins pour un certain temps. Le problème avec les idées, cependant, c'est qu'elles mènent à plus d'idées. Avez-vous déjà remarqué que lorsque vous vous asseyez pour écrire quelque chose, la moitié des idées qui y figurent sont celles que vous avez eues en l'écrivant ? La même chose se produit avec les logiciels. Travailler à la mise en œuvre d'une idée vous donne plus d'idées. Ainsi, mettre une idée de côté vous coûte non seulement ce délai dans sa mise en œuvre, mais aussi toutes les idées que sa mise en œuvre aurait générées. En fait, mettre une idée de côté inhibe probablement même les nouvelles idées : lorsque vous commencez à penser à une nouvelle fonctionnalité, vous apercevez l'étagère et pensez "mais j'ai déjà beaucoup de nouvelles choses que je veux faire pour la prochaine version".

Ce que les grandes entreprises font au lieu d'implémenter des fonctionnalités, c'est les planifier. Chez Viaweb, nous avons parfois eu des problèmes à cet égard. 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 pas de plans. Nous avions des idées générales sur les choses que nous voulions améliorer, mais si nous savions comment, nous l'aurions déjà fait. Qu'allions-nous faire dans les six prochains mois ? Ce qui semblait être le plus grand gain. 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 mises de côté. Lorsque nous avions de bonnes idées, nous les implémentions.

Chez Viaweb, comme dans de nombreuses entreprises de logiciels, la plupart du code avait un propriétaire défini. Mais lorsque vous possédiez quelque chose, vous le possédiez vraiment : personne d'autre que le propriétaire d'une pièce de logiciel n'avait à approuver (ni même à connaître) une version. Il n'y avait aucune protection contre les pannes, sauf la peur de passer pour un idiot auprès de ses pairs, et c'était plus que suffisant. J'ai peut-être donné l'impression que nous avancions allègrement en écrivant du code. Nous allions vite, mais nous réfléchissions très attentivement avant de déployer des logiciels sur ces serveurs. Et l'attention est plus importante pour la fiabilité que la lenteur. Parce qu'il est très attentif, un pilote de la Marine peut faire atterrir un avion de 40 000 livres à 140 miles par heure sur le pont d'un porte-avions qui tangue, la nuit, plus sûrement que l'adolescent moyen ne peut couper un bagel.

Cette façon d'écrire des logiciels est une arme à double tranchant, bien sûr. Elle fonctionne beaucoup mieux pour une petite équipe de bons programmeurs de confiance que pour une grande entreprise de programmeurs médiocres, où les mauvaises idées sont interceptées par des comités au lieu des personnes qui les ont eues.

Brooks à l'Envers

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

Viaweb a été écrit par seulement trois personnes. [7] J'étais toujours sous pression pour en embaucher davantage, 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 en avons embauché davantage, mais leur avons créé de nouveaux projets.)

Lorsque vous pouvez écrire un logiciel avec moins de programmeurs, cela vous fait économiser plus que de l'argent. Comme Fred Brooks l'a souligné dans Le Mythe du Mois-Homme, ajouter des personnes à un projet a tendance à le ralentir. Le nombre de connexions possibles entre les développeurs croît de manière exponentielle avec la taille du groupe. Plus le groupe est grand, plus ils passeront de temps en réunions à négocier comment leurs logiciels fonctionneront ensemble, et plus ils auront de bugs dus à des interactions imprévues. Heureusement, ce processus fonctionne aussi à l'envers : à mesure que les groupes deviennent plus petits, le développement logiciel devient exponentiellement plus efficace. Je ne me souviens pas que les programmeurs de Viaweb aient jamais eu une véritable réunion. Nous n'avons jamais eu plus à dire à la fois que ce que nous pouvions dire en marchant pour le déjeuner.

S'il y a un inconvénient ici, c'est que tous les programmeurs doivent être, dans une certaine mesure, des administrateurs système également. 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 avait tellement de composants et changeait si fréquemment qu'il n'y avait pas de frontière définie entre le logiciel et l'infrastructure. Déclarer arbitrairement une telle frontière aurait contraint nos choix de conception. Et donc, bien que nous espérions constamment qu'un jour ("dans quelques mois") tout serait suffisamment stable pour que nous puissions embaucher quelqu'un dont le travail serait juste de s'occuper des serveurs, cela n'est jamais arrivé.

Je ne pense pas qu'il puisse en être autrement, tant que vous développez encore activement le produit. Le logiciel basé sur le Web ne sera jamais quelque chose que vous écrivez, que vous validez, et que vous rentrez chez vous. C'est une chose vivante, qui tourne sur vos serveurs en ce moment même. Un bug grave pourrait non seulement planter le processus d'un utilisateur ; il pourrait tous les planter. Si un bug dans votre code corrompt des 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 chaque minute (après la première année environ), mais vous voulez absolument garder un œil sur les choses que vous avez récemment modifiées. Vous ne déployez pas de code tard le soir pour ensuite rentrer chez vous.

Surveiller les Utilisateurs

Avec les logiciels basés sur serveur, vous êtes plus en contact avec votre code. Vous pouvez également être plus en contact avec vos utilisateurs. Intuit est célèbre pour s'être présenté aux clients dans les magasins de détail et leur avoir demandé de les suivre chez eux. Si vous avez déjà regardé quelqu'un utiliser votre logiciel pour la première fois, vous savez quelles surprises devaient les attendre.

Le logiciel devrait faire ce que les utilisateurs pensent qu'il fera. Mais vous ne pouvez pas avoir la moindre idée de ce que les utilisateurs penseront, croyez-moi, avant de les observer. 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 examiner attentivement 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 les utilisateurs sur votre serveur, vous n'avez pas besoin de vous fier aux benchmarks, par exemple. Les benchmarks sont des utilisateurs simulés. Avec les logiciels basés sur serveur, vous pouvez observer des utilisateurs réels. Pour décider quoi optimiser, connectez-vous simplement à un serveur et voyez ce qui consomme tout le CPU. Et vous savez quand arrêter d'optimiser aussi : nous avons finalement amené l'éditeur Viaweb au point où il était limité par la mémoire plutôt que par le CPU, et comme nous ne pouvions rien faire pour diminuer la taille des données des utilisateurs (enfin, rien de facile), nous savions que nous pouvions aussi bien nous arrêter là.

L'efficacité compte pour les logiciels basés sur serveur, car vous payez le matériel. Le nombre d'utilisateurs que vous pouvez supporter par serveur est le diviseur de votre coût en capital, donc si vous pouvez rendre votre logiciel très efficace, vous pouvez vendre moins cher que vos concurrents tout en réalisant un profit. Chez Viaweb, nous avons réduit le coût en capital par utilisateur à environ 5 $. Ce serait moins maintenant, probablement moins que le coût de l'envoi de 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 l'optimisation. Viaweb avait 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 est 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 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, vous pouvez souvent savoir quand ils sont en difficulté. Et comme le client a toujours raison, c'est un signe de quelque chose que vous devez corriger. Chez Viaweb, la clé pour attirer les utilisateurs était l'essai en ligne. Ce n'était pas seulement une série de diapositives créées par des gens du marketing. Dans notre essai, les utilisateurs utilisaient réellement le logiciel. Cela prenait environ cinq minutes, et à la fin, ils avaient construit une véritable boutique fonctionnelle.

L'essai était la façon dont nous avons obtenu presque tous nos nouveaux utilisateurs. Je pense qu'il en sera de même pour la plupart des applications Web. Si les utilisateurs peuvent réussir un essai, ils aimeront le produit. S'ils sont confus ou s'ennuient, ils ne l'aimeront pas. Donc, tout ce que nous pouvions faire pour que plus de gens réussissent l'essai augmenterait notre taux de croissance.

J'ai étudié les traces de clics des personnes qui faisaient l'essai et j'ai constaté qu'à une certaine étape, elles devenaient confuses 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 moment-là, disant aux utilisateurs qu'ils avaient presque terminé, et leur rappelant de ne pas cliquer sur le bouton Retour. Une autre grande chose à propos des logiciels basés sur le Web est que vous obtenez un retour instantané des changements : le nombre de personnes terminant l'essai est passé immédiatement de 60 % à 90 %. Et comme le nombre de nouveaux utilisateurs était fonction du nombre d'essais terminés, notre croissance des revenus a augmenté de 50 %, juste grâce à ce changement.

Argent

Au début des années 1990, j'ai lu un article dans lequel quelqu'un disait que le logiciel était une entreprise par abonnement. Au début, cela semblait une déclaration très cynique. Mais plus tard, j'ai réalisé que cela reflète la réalité : le développement logiciel est un processus continu. Je pense que c'est plus propre si vous facturez ouvertement des frais d'abonnement, au lieu de forcer les gens à continuer d'acheter et d'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 où 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 de réelles dépenses. 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 ardoise vierge, vous avez un flux de revenus récurrents. Parce que votre logiciel évolue progressivement, vous n'avez pas à craindre qu'un nouveau modèle échoue ; il n'y a jamais besoin d'un nouveau modèle, en soi, et si vous faites quelque chose au logiciel que les utilisateurs détestent, vous le saurez immédiatement. Vous n'avez aucun problème avec les factures irrécouvrables ; si quelqu'un ne paie pas, vous pouvez simplement couper le service. Et il n'y a aucune possibilité de piratage.

Ce dernier "avantage" pourrait s'avérer être un problème. Une certaine quantité de piratage est à l'avantage des entreprises de logiciels. Si un utilisateur n'aurait vraiment pas acheté votre logiciel à n'importe quel prix, vous n'avez rien perdu s'il utilise une copie piratée. En fait, vous gagnez, car il est un utilisateur de plus aidant à faire de votre logiciel la norme – ou qui pourrait acheter une copie plus tard, lorsqu'il aura terminé le lycée.

Quand elles le peuvent, les entreprises aiment faire ce qu'on appelle la discrimination par les prix, ce qui signifie facturer à chaque client autant qu'il peut se permettre. [8] Le logiciel est particulièrement adapté à la discrimination par les prix, car le coût marginal est proche de zéro. C'est pourquoi certains logiciels coûtent plus cher à exécuter sur des Suns que sur des boîtiers Intel : une entreprise qui utilise des Suns n'est pas intéressée par l'économie d'argent et peut être facturée plus cher en toute sécurité. Le piratage est effectivement le niveau le plus bas de la discrimination par les prix. Je pense que les entreprises de logiciels comprennent cela et ferment délibérément les yeux sur certains types de piratage. [9] Avec les logiciels basés sur serveur, elles devront trouver une autre solution.

Les logiciels basés sur le Web se vendent bien, surtout par rapport aux logiciels de bureau, car ils sont faciles à acheter. Vous pourriez 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'y pensais. En fait, la deuxième étape peut se propager en retour dans la première : si quelque chose est difficile à acheter, les gens changeront d'avis sur le fait qu'ils le voulaient. Et vice versa : vous vendrez plus de quelque chose quand il est facile à acheter. J'achète plus de livres parce qu'Amazon existe. Le logiciel basé sur le Web est à peu près la chose la plus facile au monde à acheter, surtout si vous venez de faire une démo en ligne. Les utilisateurs ne devraient pas avoir à faire beaucoup plus que d'entrer un numéro de carte de crédit. (Faites-leur faire plus à vos risques et périls.)

Parfois, les logiciels basés sur le Web sont offerts par des FAI agissant comme revendeurs. C'est une mauvaise idée. Vous devez administrer les serveurs, car vous devez constamment améliorer le matériel et le logiciel. 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 – généralement, je pense, parce qu'ils ont été envahis par des cadres qui étaient enthousiasmés par cet énorme canal potentiel, et ne réalisaient pas que cela ruinerait le produit qu'ils espéraient vendre par ce biais. Vendre des logiciels basés sur le Web via des FAI, c'est comme vendre des sushis via des distributeurs automatiques.

Clients

Qui seront les clients ? Chez Viaweb, il s'agissait initialement d'individus et de petites entreprises, et je pense que ce sera la règle avec les applications Web. Ce sont les 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 seront souvent la meilleure chose pour les grandes entreprises aussi (bien qu'elles mettront du temps à le réaliser). Le meilleur intranet est l'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 personnes malveillantes. Certains grands commerçants étaient réticents à utiliser Viaweb car ils pensaient que les informations de carte de crédit des clients seraient plus sûres sur leurs propres serveurs. Il n'était pas facile de faire valoir ce point diplomatiquement, mais en fait, les données étaient presque certainement plus sûres entre nos mains qu'entre les leurs. Qui peut embaucher de meilleures personnes pour gérer la sécurité, une startup technologique dont toute l'activité est de gérer des serveurs, ou un détaillant de vêtements ? Non seulement nous avions de meilleures personnes qui se souciaient de la sécurité, mais nous nous en soucions davantage. Si quelqu'un s'introduisait dans les serveurs du détaillant de vêtements, cela affecterait au maximum un commerçant, pourrait probablement être passé sous silence, et dans le pire des cas, pourrait faire licencier une personne. Si quelqu'un s'introduisait dans les nôtres, cela pourrait affecter des milliers de commerçants, finirait probablement comme une nouvelle 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 mettez-vous à la banque ? Cet argument s'applique à chaque aspect de l'administration des serveurs : non seulement la sécurité, mais 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 le grand interdit pour nous, comme un jouet dangereux le serait pour un fabricant de jouets, ou une épidémie de salmonelle pour un transformateur alimentaire.

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 façon qu'elles ne le feraient avec 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 les clients, et un développeur doit traiter avec les logiciels des concurrents, mais un administrateur système, comme un vieux célibataire, a peu de forces externes pour le maintenir en ligne. [10] Chez Viaweb, nous avions beaucoup de forces externes pour nous maintenir en ligne. Les personnes qui nous appelaient étaient des clients, pas seulement des collègues. Si un serveur se bloquait, nous sautions ; le simple fait d'y penser me donne une décharge d'adrénaline, des années plus tard.

Ainsi, les applications Web seront généralement la bonne réponse pour les grandes entreprises aussi. Elles seront cependant les dernières à le réaliser, tout comme elles l'ont été avec les ordinateurs de bureau. Et en partie pour la même raison : il vaudra beaucoup d'argent de convaincre les grandes entreprises qu'elles ont besoin de quelque chose de plus cher.

Il y a toujours une tendance pour les clients riches à acheter des solutions coûteuses, même lorsque les solutions bon marché sont meilleures, parce que les personnes offrant des solutions coûteuses peuvent dépenser plus pour les vendre. Chez Viaweb, nous étions toujours confrontés à cela. Nous avons perdu plusieurs commerçants haut de gamme au profit de cabinets 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. Ils n'étaient, en règle générale, pas mieux lotis, comme plus d'un l'a découvert lorsque la saison des achats de Noël est arrivée et que les charges ont augmenté sur leur serveur. Viaweb était beaucoup plus sophistiqué que ce que la plupart de ces commerçants obtenaient, 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 à l'air autoritaire pour faire des présentations aux clients.

Une grande partie de ce que les grandes entreprises paient en plus est le coût de la vente de choses coûteuses. (Si le Département de la Défense paie mille dollars pour des sièges de toilettes, c'est en partie parce que cela coûte cher de vendre des sièges de toilettes pour 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. C'est simplement plus cher. Il n'y a rien que vous puissiez faire face à ce dilemme, donc le meilleur plan est de cibler d'abord les petits clients. Le reste viendra avec le temps.

Fils de Serveur

Exécuter des logiciels sur le serveur n'a rien de nouveau. En fait, c'est l'ancien modèle : les applications mainframe sont toutes basées sur serveur. Si les logiciels basés sur 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 être une grande menace. Les premiers utilisateurs étaient tous des hackers – ou des amateurs, comme on les appelait alors. Ils aimaient les micro-ordinateurs parce qu'ils étaient bon marché. Pour la première fois, vous pouviez avoir votre propre ordinateur. L'expression "ordinateur personnel" fait maintenant partie du langage courant, mais lorsqu'elle a été utilisée pour la première fois, elle avait un son délibérément audacieux, comme l'expression "satellite personnel" le ferait aujourd'hui.

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 de micro-ordinateurs étaient meilleurs était qu'ils pouvaient être écrits par de petites entreprises.

Je ne pense pas que beaucoup de gens réalisent à quel point les startups sont fragiles et hésitantes à leurs premiers stades. De nombreuses startups commencent presque par accident – comme quelques gars, soit avec des emplois à temps plein, soit à l'école, écrivant un prototype de quelque chose qui pourrait, si cela semble prometteur, se transformer en entreprise. À ce stade larvaire, tout obstacle significatif arrêtera net la startup. Écrire des logiciels mainframe exigeait trop d'engagement initial. Les machines de développement étaient chères, et comme les clients seraient de grandes entreprises, vous auriez besoin d'une force de vente impressionnante pour les leur vendre. Lancer une startup pour écrire des logiciels mainframe serait une entreprise beaucoup plus sérieuse que de simplement bricoler quelque chose sur votre Apple II le soir. Et donc, il n'y a pas eu beaucoup de startups qui ont écrit des applications mainframe.

L'arrivée des ordinateurs de bureau a inspiré beaucoup de nouveaux logiciels, car écrire des applications pour eux semblait un objectif atteignable pour les startups larvaires. Le développement était bon marché, et les clients seraient des individus que vous pourriez atteindre via les magasins d'informatique ou même par correspondance.

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

Il semble que les logiciels basés sur serveur seront bons cette fois-ci, car les startups les écriront. Les ordinateurs sont si bon marché maintenant 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 le mot maintenant) et ont largement progressé sur le marché des serveurs ; les serveurs de Yahoo, qui gèrent des charges aussi élevées que n'importe quelle autre sur Internet, ont tous les mêmes processeurs Intel bon marché que vous avez dans votre machine 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 startup larvaire typique. Nous étions terrifiés à l'idée de créer une entreprise, et pendant les premiers mois, nous nous sommes réconfortés en traitant le tout comme une expérience que nous pourrions annuler à tout moment. Heureusement, il y avait peu d'obstacles sauf 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 dans cette phase étaient la nourriture et le loyer.

Il y a d'autant plus de raisons pour les startups d'écrire des logiciels basés sur le Web maintenant, car écrire des logiciels de bureau est devenu beaucoup moins amusant. Si vous voulez écrire des logiciels de bureau maintenant, vous le faites selon les conditions de Microsoft, en appelant leurs API et en contournant leur OS buggé. Et si vous parvenez à écrire quelque chose qui décolle, vous pourriez découvrir que vous ne faisiez que de la recherche de marché pour Microsoft.

Si une entreprise veut créer une plateforme sur laquelle les startups vont construire, elle doit en faire quelque chose que les hackers eux-mêmes voudront utiliser. 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] Vous voyez cela moins avec Windows, car les hackers ne l'utilisent pas. Le genre de personnes qui sont douées pour écrire des logiciels ont tendance à exécuter Linux ou FreeBSD maintenant.

Je ne pense pas que nous aurions lancé une startup pour écrire des logiciels de bureau, car les logiciels de bureau doivent fonctionner sur Windows, et avant de pouvoir écrire des logiciels pour Windows, nous devrions l'utiliser. Le Web nous a permis de contourner Windows et de livrer des logiciels fonctionnant sur Unix directement aux utilisateurs via le navigateur. C'est une perspective libératrice, un peu comme 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 que tout le monde craignait. C'est difficile à imaginer maintenant, mais je me souviens très bien de ce sentiment. Maintenant, le géant effrayant est Microsoft, et je ne pense pas qu'ils soient aussi aveugles à la menace qui les guette qu'IBM l'était. 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 probablement non. 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 ? Pourront-ils utiliser leur contrôle du bureau pour empêcher, ou contraindre, cette nouvelle génération de logiciels ?

Mon hypothèse est que Microsoft développera une sorte d'hybride serveur/bureau, où le système d'exploitation fonctionnera avec les serveurs qu'ils contrôlent. 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'à l'extrême de faire les calculs sur le serveur, avec seulement un navigateur comme client, s'ils peuvent l'éviter. Si vous n'avez besoin que d'un navigateur comme client, vous n'avez pas besoin de Microsoft sur le client, et si Microsoft ne contrôle pas le client, ils ne peuvent pas pousser les utilisateurs vers leurs applications basées sur 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 offrant des applications qui fonctionnent depuis n'importe quel client. [14]

Dans un monde d'applications Web, il n'y a pas de place automatique pour Microsoft. Ils peuvent réussir à se faire une place, mais je ne pense pas qu'ils domineront ce nouveau monde comme ils l'ont fait dans le monde des applications de bureau.

Ce n'est pas tant qu'un concurrent les fera trébucher qu'ils trébucheront sur 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 vœux pieux. Ce qu'ils doivent faire, c'est cannibaliser leur activité existante, et je ne les vois pas y faire face. La même détermination qui les a menés si loin travaillera maintenant contre eux. IBM était exactement dans la même situation, et ils n'ont pas pu la maîtriser. IBM a fait une entrée tardive et peu enthousiaste dans le secteur des micro-ordinateurs parce qu'ils étaient ambivalents quant à menacer leur vache à lait, l'informatique mainframe. Microsoft sera de même entravé par le désir de sauver le bureau. Une vache à lait peut être un singe sacrément lourd sur le dos.

Je ne dis pas que personne ne dominera les applications basées sur serveur. Quelqu'un le fera probablement un jour. Mais je pense qu'il y aura une longue période de joyeux chaos, tout comme il y en a eu aux débuts des micro-ordinateurs. C'était une bonne période pour les startups. Beaucoup de petites entreprises ont prospéré, et l'ont fait en créant des choses cool.

Startups, mais Plus Encore

La startup classique est rapide et informelle, avec peu de personnes et peu d'argent. Ces quelques personnes travaillent très dur, et la technologie magnifie l'effet des décisions qu'elles prennent. Si elles gagnent, elles gagnent gros.

Dans une startup qui écrit des applications basées sur le Web, tout ce que vous associez aux startups 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 permettre d'être plus informel. Vous pouvez littéralement lancer votre produit en tant que 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 logiciel signifiait une pièce remplie d'hommes aux lunettes à monture en corne et aux cravates noires étroites, écrivant assidûment dix lignes de code par jour sur des formulaires de codage IBM. En 1980, c'était une équipe de huit à dix personnes portant des jeans au bureau et tapant sur des vt100. Maintenant, c'est un couple de gars assis dans un salon avec des ordinateurs portables. (Et les jeans ne sont pas le dernier mot en matière d'informalité.)

Les startups sont stressantes, et cela, malheureusement, est également poussé à l'extrême avec les applications Web. De nombreuses entreprises de logiciels, surtout au début, ont des périodes où les développeurs dormaient sous leurs bureaux et ainsi de suite. La chose alarmante avec les logiciels basés sur le Web est que rien n'empêche que cela devienne la norme. Les histoires de dormir sous les bureaux se terminent généralement par : puis enfin nous l'avons livré et nous sommes tous rentrés chez nous et avons dormi pendant une semaine. Le logiciel basé sur le Web n'est jamais "livré". 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 à y être forcé. Vous pouvez, donc vous devez. C'est la Loi de Parkinson fonctionnant à l'envers.

Le pire n'est pas les heures, mais la responsabilité. Les programmeurs et les administrateurs système ont traditionnellement chacun leurs propres soucis distincts. 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 jusqu'aux coudes dans le code source, mais à un moment donné, ils peuvent rentrer chez eux et l'oublier. Les administrateurs système ne quittent jamais vraiment leur travail, mais lorsqu'ils sont alertés à 4h00 du matin, ils n'ont généralement pas à faire quelque chose de très compliqué. Avec les applications basées sur le Web, ces deux types de stress se combinent. Les programmeurs deviennent des administrateurs système, mais sans les limites clairement définies qui rendent normalement le travail supportable.

Chez Viaweb, nous avons passé les six premiers mois à écrire du logiciel. Nous avons travaillé les longues heures habituelles d'une jeune startup. Dans une entreprise de logiciels de bureau, cela aurait été la partie où nous travaillions dur, mais cela ressemblait à des vacances par rapport à la phase suivante, lorsque nous avons accueilli des utilisateurs sur notre serveur. Le deuxième plus grand avantage de la vente de Viaweb à Yahoo (après l'argent) était de pouvoir décharger la responsabilité ultime de l'ensemble sur les épaules d'une grande entreprise.

Les logiciels de bureau forcent les utilisateurs à devenir des administrateurs système. Les logiciels basés sur le Web forcent les programmeurs à le faire. Il y a moins de stress au total, mais plus pour les programmeurs. Ce n'est pas nécessairement une mauvaise nouvelle. Si vous êtes une startup en concurrence avec une grande entreprise, c'est une bonne nouvelle. [15] Les applications Web offrent un moyen simple de surpasser vos concurrents. Aucune startup n'en demande plus.

Juste Assez Bon

Une chose qui pourrait vous dissuader d'écrire des applications Web est la faiblesse des pages Web en tant qu'interface utilisateur. C'est un problème, je l'admets. Il y avait quelques choses que nous aurions vraiment aimé ajouter à HTML et HTTP. Ce qui compte, cependant, c'est que les pages Web sont juste assez bonnes.

Il y a un parallèle ici avec les premiers micro-ordinateurs. Les processeurs de ces machines n'étaient pas réellement destinés à être les CPU d'ordinateurs. Ils ont été 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 réalisé qu'ils étaient juste assez bons. Vous pouviez combiner l'une de ces puces avec de la mémoire (256 octets dans le premier Altair), et des interrupteurs de panneau avant, et vous auriez un ordinateur fonctionnel. Pouvoir avoir son propre ordinateur était si excitant qu'il y avait beaucoup de gens qui voulaient les acheter, aussi limités soient-ils.

Les pages Web n'ont pas été conçues pour être une interface utilisateur pour les applications, mais elles sont juste assez bonnes. Et pour un nombre significatif d'utilisateurs, un logiciel que vous pouvez utiliser depuis n'importe quel navigateur sera un gain suffisant en soi pour l'emporter sur toute maladresse de l'interface utilisateur. Peut-être ne pouvez-vous pas écrire le plus beau tableur en utilisant HTML, mais vous pouvez écrire un tableur que plusieurs personnes peuvent utiliser simultanément depuis différents endroits sans logiciel client spécial, ou qui peut incorporer des flux de données en direct, ou qui peut vous alerter 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 serveur n'ont pas besoin d'être basées sur le Web. Vous pourriez avoir un autre type de client. Mais je suis à peu près sûr que c'est une mauvaise idée. Il serait très pratique de pouvoir supposer que tout le monde installerait votre client – si pratique que vous pourriez facilement vous convaincre qu'ils le feraient tous – mais s'ils ne le font pas, vous êtes fichu. Parce que le logiciel basé sur le Web ne suppose rien du client, il fonctionnera partout où le Web fonctionne. C'est déjà un grand avantage, et l'avantage grandira à mesure que de nouveaux appareils Web proliféreront. Les utilisateurs vous aimeront parce que votre logiciel fonctionne tout simplement, et votre vie sera plus facile parce que vous n'aurez pas à l'ajuster pour chaque nouveau client. [16]

J'ai l'impression d'avoir observé l'évolution du Web d'aussi près que quiconque, et je ne peux pas prédire ce qui va se passer avec les clients. La convergence est probablement à venir, mais où ? Je ne peux pas choisir un gagnant. Une chose que je peux prédire est un conflit entre AOL et Microsoft. Quoi que soit le .NET de Microsoft, il impliquera probablement la connexion du bureau aux serveurs. À moins qu'AOL ne riposte, ils seront soit mis de côté, soit transformés en un tuyau entre les logiciels client et serveur de Microsoft. Si Microsoft et AOL entrent en guerre des clients, la seule chose sûre de fonctionner sur les deux sera la navigation sur le Web, ce qui signifie que les applications Web seront le seul type qui fonctionne partout.

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

Pourquoi Pas ?

E. B. White a été amusé d'apprendre d'un ami fermier que de nombreuses clôtures électriques n'ont pas de courant qui les traverse. Les vaches apprennent apparemment à rester à l'écart, et après cela, vous n'avez plus besoin du courant. "Levez-vous, vaches ! Prenez votre liberté pendant que les despotes ronflent !"

Si vous êtes un hacker qui a un jour pensé à lancer une startup, il y a probablement deux choses qui vous en empêchent. L'une est que vous ne connaissez rien aux affaires. L'autre est que vous avez peur de la concurrence. Aucune de ces clôtures n'a de courant.

Il n'y a que deux choses que vous devez savoir sur les affaires : construire quelque chose que les utilisateurs aiment, et gagner plus que vous ne dépensez. Si vous réussissez ces deux choses, vous serez en avance sur la plupart des startups. Vous pourrez découvrir le reste au fur et à mesure.

Vous ne gagnerez peut-être pas au début plus que vous ne dépensez, mais tant que l'écart se réduit assez vite, tout ira bien. Si vous commencez sous-financé, 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é avec moins de 10 000 $, et ce serait encore moins cher aujourd'hui. Nous avons dû dépenser des milliers pour un serveur, et des milliers de plus pour obtenir le SSL. (La seule entreprise vendant des logiciels SSL à l'époque était Netscape.) Maintenant, 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 maintenant pour moins que le coût d'une chaise de bureau sophistiquée.

Quant à construire quelque chose que les utilisateurs aiment, voici quelques conseils généraux. Commencez par faire quelque chose de propre et simple que vous voudriez utiliser vous-même. Sortez une version 1.0 rapidement, puis continuez à améliorer le logiciel, en écoutant attentivement les utilisateurs au fur et à mesure. 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 facile, mais la façon de le faire est d'obtenir les bons réglages par défaut, et non de limiter les choix des utilisateurs. Ne soyez pas complaisant si le logiciel de vos concurrents est nul ; la norme à laquelle comparer votre logiciel est ce qu'il pourrait être, et non ce que vos concurrents actuels ont. Utilisez votre logiciel vous-même, tout le temps. Viaweb était censé être un créateur de boutiques en ligne, mais nous l'avons aussi utilisé pour créer notre propre site. N'écoutez pas les personnes du marketing, les designers ou les chefs de produit juste à cause de leurs titres de poste. S'ils ont de bonnes idées, utilisez-les, mais c'est à vous de décider ; le logiciel doit être conçu par des hackers qui comprennent le design, pas par des designers qui connaissent un peu le logiciel. Si vous ne pouvez pas concevoir un logiciel aussi bien que l'implémenter, ne lancez pas de startup.

Parlons maintenant de la concurrence. Ce dont vous avez peur n'est probablement pas des groupes de hackers comme vous, mais de vraies entreprises, avec des bureaux, des plans d'affaires et des vendeurs, n'est-ce pas ? Eh bien, elles ont plus peur de vous que vous d'elles, et elles ont raison. Il est beaucoup plus facile pour quelques hackers de trouver comment louer des bureaux ou embaucher des vendeurs que pour une entreprise de n'importe quelle taille de faire écrire des logiciels. J'ai été des deux côtés, et je le sais. Lorsque Viaweb a été achetée par Yahoo, je me suis soudainement 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 haute direction était de vrais fonceurs. Pour une grande entreprise, ils étaient exceptionnels. Mais ils n'étaient encore qu'environ un dixième aussi productifs qu'une petite startup. Aucune grande entreprise ne peut faire beaucoup mieux que cela. Ce qui est effrayant chez Microsoft, c'est qu'une entreprise si grande puisse développer des logiciels du tout. Ils sont comme une montagne qui peut marcher.

Ne vous laissez pas intimider. Vous pouvez faire autant de choses que Microsoft ne peut pas faire que ce qu'ils peuvent faire que vous ne pouvez pas. Et personne ne peut vous arrêter. Vous n'avez pas à demander la permission de quiconque pour développer des applications Web. Vous n'avez pas à faire d'accords de licence, ni à obtenir de l'espace en rayon dans les magasins de détail, ni à ramper pour que votre application soit livrée avec l'OS. Vous pouvez livrer des logiciels directement au navigateur, et personne ne peut s'interposer entre vous et les utilisateurs potentiels sans les empêcher de naviguer sur le Web.

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

Notes

[1] Réalisant qu'une grande partie de l'argent se trouve dans les services, les entreprises construisant 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érents pour construire de l'électronique grand public et pour gérer un service en ligne, et en partie parce que les utilisateurs détestent l'idée. Donner le rasoir et gagner de l'argent sur les lames peut fonctionner pour Gillette, mais un rasoir est un engagement beaucoup plus petit qu'un terminal Web. Les fabricants de combinés de téléphones portables se contentent de vendre du matériel sans essayer de capter également les revenus des services. Cela devrait probablement être le modèle pour les clients Internet aussi. 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 une.

[2] La sécurité dépend toujours plus de ne pas faire d'erreurs que de toute décision de conception, mais la nature des logiciels basés sur serveur incitera les développeurs à être plus attentifs à ne pas faire d'erreurs. Compromettre un serveur pourrait causer de tels dommages que les FSA (qui veulent rester en activité) sont susceptibles d'être 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 serveur. Les applets nous semblaient une idée démodée. Télécharger des programmes à exécuter sur le client ? Plus simple d'aller jusqu'au bout et d'exécuter les programmes sur le serveur. Nous avons perdu peu de temps sur les applets, mais d'innombrables autres startups ont dû être attirées dans ce bourbier. Peu d'entre elles ont dû en sortir vivantes, sinon Microsoft n'aurait pas pu se permettre d'abandonner Java dans la version la plus récente d'Explorer.

[4] Ce point est dû à Trevor Blackwell, qui ajoute "le coût d'écriture de logiciels augmente plus que linéairement avec leur taille. C'est peut-être principalement dû à la correction d'anciens bugs, et le coût peut être plus linéaire si tous les bugs sont trouvés rapidement."

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

[6] Au sein de Viaweb, nous avons un jour organisé un concours pour décrire la pire chose à propos de notre logiciel. Deux personnes du support client ont été à égalité pour le premier prix avec des entrées dont je frissonne encore en me souvenant. Nous avons corrigé les deux problèmes immédiatement.

[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 marchands utilisaient pour récupérer les commandes, consulter les statistiques et configurer les noms de domaine, etc. J'ai écrit l'éditeur, que les marchands utilisaient pour construire 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 omniprésente (combien de fois avez-vous entendu un détaillant affirmer que son pouvoir d'achat signifiait des prix plus bas pour vous ?) que j'ai été surpris de découvrir qu'elle était illégale aux États-Unis en vertu du Robinson-Patman Act de 1936. Cette loi ne semble pas être vigoureusement appliquée.

[9] Dans No Logo, Naomi Klein dit que les marques de vêtements favorisées par la "jeunesse urbaine" n'essaient pas trop d'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 quoi externaliser et quoi ne pas externaliser. Une réponse possible : externalisez tout travail qui n'est pas directement exposé à la pression concurrentielle, car l'externalisation l'exposera ainsi à la pression concurrentielle.

[11] Les deux gars é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 emploi à temps plein en tant que développeur de logiciels. "Il n'y avait pas de grand risque à créer une entreprise", a écrit Bob, "Si ça échouait, ça échouait. Pas grave."

[12] Ce n'est pas aussi facile que je le dis. Il a fallu un temps douloureusement long pour que le bouche-à-oreille se mette en place, et nous n'avons pas commencé à obtenir beaucoup de couverture médiatique avant d'avoir embauché une agence de relations publiques (certes la meilleure du secteur) pour 16 000 $ par mois. Cependant, il était vrai 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 secteur des logiciels et a déchaîné une nuée de fournisseurs de composants bon marché sur le matériel Apple. Cela n'a pas aidé non plus que des cadres aient pris le contrôle pendant une période critique.

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

Entre autres choses, un navigateur open-source approprié ferait en sorte que HTTP et HTML continuent d'évoluer (comme Perl, par exemple). Cela aiderait grandement les applications Web à pouvoir distinguer entre la sélection d'un lien et son suivi ; tout ce dont vous auriez besoin pour cela serait une amélioration triviale de HTTP, pour permettre plusieurs URL dans une requête. Les menus en cascade seraient également bons.

Si vous voulez changer le monde, écrivez un nouveau Mosaic. 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 nulles. Assurez-vous qu'il fonctionne d'abord sur tous les OS gratuits – les nouvelles choses commencent avec leurs utilisateurs.

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

"J'irais plus loin en disant que parce que les logiciels basés sur serveur sont si durs pour les programmeurs, cela provoque un changement économique fondamental loin des grandes entreprises. Cela exige le genre d'intensité et de dévouement de la part des programmeurs qu'ils ne seront prêts à fournir que lorsque c'est leur propre entreprise. Les entreprises de logiciels peuvent embaucher des personnes qualifiées pour travailler dans un environnement peu exigeant, et peuvent embaucher des personnes non qualifiées pour endurer des difficultés, mais elles ne peuvent pas embaucher des personnes hautement qualifiées pour se casser le cul. Puisque le capital n'est plus nécessaire, les grandes entreprises ont peu à apporter."

[16] Dans la version originale de cet essai, je conseillais d'éviter Javascript. C'était un bon plan en 2001, mais Javascript fonctionne maintenant.

Remerciements à Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson et Dan Giffin pour la lecture des ébauches de cet article ; à Dan Bricklin et Bob Frankston pour les informations sur VisiCalc ; et encore à Ken Anderson pour m'avoir invité à prendre la parole aux BBN.

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