L'AUTRE ROUTE DEVANT

Septembre 2001

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

À l'été 1995, mon ami Robert Morris et moi avons décidé de créer une startup. La campagne de relations publiques menée en vue de l'introduction en bourse de Netscape battait son plein à l'époque, et on parlait beaucoup dans la presse du commerce en ligne. À l'époque, il y avait peut-être trente véritables magasins sur le Web, tous faits à la main. S'il devait y avoir beaucoup de magasins en ligne, il fallait un logiciel pour les créer, donc nous avons décidé de nous en charger.

Pour la première semaine environ, nous avions l'intention de faire de cette application un logiciel 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 que c'était la voie à suivre. Si nous écrivions notre logiciel pour qu'il fonctionne sur le serveur, ce serait beaucoup plus facile pour les utilisateurs et pour nous.

Cela s'est avéré être un bon plan. Maintenant, en tant que Yahoo Store, ce logiciel est le constructeur de magasins en ligne le plus populaire, avec environ 14 000 utilisateurs.

Lorsque nous avons commencé Viaweb, presque personne ne comprenait ce que nous voulions dire lorsque nous disions que le logiciel fonctionnait sur le serveur. Ce n'est qu'un an plus tard, avec le lancement de Hotmail, que les gens ont commencé à saisir l'idée. Maintenant, tout le monde sait que c'est une approche valide. Il existe maintenant un nom pour ce que nous étions : un Fournisseur de Services d'Applications, ou ASP.

Je pense qu'une grande partie de la prochaine génération de logiciels sera écrite selon ce modèle. Même Microsoft, qui a le plus à perdre, semble voir l'inévitabilité de transférer certaines choses hors du bureau. Si le logiciel passe du bureau aux 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ù le logiciel passe sur des serveurs, ce que je décris ici est l'avenir.

La prochaine chose ?

Lorsque nous regardons en arrière sur l'ère des logiciels de bureau, je pense que nous nous émerveillerons des inconvénients auxquels les gens se sont habitué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, vous deviez être expert en voitures pour posséder une voiture. Mais les voitures étaient un tel succès que beaucoup de gens qui n'étaient pas experts en voitures voulaient aussi en avoir une.

Les ordinateurs en sont maintenant à cette phase. Lorsque vous possédez un ordinateur de bureau, vous finissez par apprendre beaucoup plus que ce que vous vouliez savoir sur ce qui se passe à l'intérieur. Mais plus de la moitié des ménages américains en possèdent un. Ma mère a un ordinateur qu'elle utilise pour ses 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 proposant une réduction sur une nouvelle version du système d'exploitation. Il y a quelque chose de mal quand 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", encore moins "pilote de périphérique" ou "patch".

Il existe maintenant une autre manière de livrer des logiciels qui épargnera aux utilisateurs de devenir des administrateurs système. Les applications basées sur le Web sont des programmes qui fonctionnent 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 le logiciel de bureau.

Avec le logiciel basé sur le Web, la plupart des utilisateurs n'auront à penser à rien d'autre qu'aux applications qu'ils utilisent. Tout le bazar, les choses changeantes seront hébergées sur un serveur quelque part, maintenues par des personnes qui sont douées pour ce genre de choses. Ainsi, vous n'aurez en général même pas besoin d'un ordinateur, à proprement parler, pour utiliser le logiciel. Tout ce dont vous aurez besoin sera de quelque chose avec un clavier, un écran et un navigateur Web. Peut-être qu'il aura accès à Internet sans fil. Peut-être que ce sera 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 de l'appareil. 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 atteigne le serveur et revienne, donc les utilisateurs de logiciels très interactifs, comme Photoshop, voudront toujours effectuer les calculs sur le bureau. Mais si vous regardez le type de choses pour lesquelles la plupart des gens utilisent des ordinateurs, une latence d'un dixième de seconde ne poserait pas de 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 bénéfice 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 l'inconvénient". La plupart des gens, la plupart du temps, choisiront l'option qui nécessite le moins de travail. Si le logiciel basé sur le Web gagne, ce sera parce qu'il est plus pratique. Et il semble que ce sera le cas, à la fois pour les utilisateurs et pour les développeurs.

Pour utiliser une application uniquement basée sur le Web, tout ce dont vous avez besoin est un navigateur connecté à Internet. Vous pouvez donc utiliser une application basée sur le 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.

Le début du changement a été l'e-mail basé sur le Web. Des millions de personnes réalisent maintenant que vous devriez avoir accès aux messages électroniques peu importe où vous êtes. 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 se trouvant sur un bureau éloigné ?

L'idée même de "votre ordinateur" disparaît au profit de "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 garder vos données sur eux : quelque chose que vous transportez peut être perdu ou volé. Laisser votre PDA dans un taxi, c'est comme une défaillance de disque, sauf que vos données sont remises à quelqu'un d'autre au lieu d'être vaporisées.

Avec des logiciels purement basés sur le Web, ni vos données ni les applications ne sont conservées sur le client. Vous n'avez donc pas besoin d'installer quoi que ce soit pour l'utiliser. Et lorsqu'il n'y a pas d'installation, vous ne devez pas vous soucier des problèmes d'installation. Il ne peut pas y avoir d'incompatibilités entre l'application et votre système d'exploitation, car le logiciel ne fonctionne pas sur votre système d'exploitation.

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

Après avoir essayé la démo, s'inscrire au service ne devrait nécessiter rien d'autre que de remplir un formulaire bref (plus c'est bref, mieux c'est). Et cela devrait être le dernier travail que l'utilisateur a à faire. Avec un logiciel basé sur le Web, vous devriez recevoir de nouvelles versions sans payer de supplément, ou faire du travail, ou même savoir qu'elles existent.

Les mises à jour ne seront pas les grands chocs qu'elles sont actuellement. Avec le temps, les applications deviendront silencieusement plus puissantes. Cela demandera un certain effort de la part des développeurs. Ils devront concevoir le logiciel de manière à pouvoir être mis à jour sans confondre les utilisateurs. C'est un nouveau problème, mais il existe des moyens de le résoudre.

Avec des applications basées sur le Web, tout le monde utilise la même version, et les bogues peuvent être corrigés dès qu'ils sont découverts. Ainsi, le logiciel basé sur le Web devrait avoir beaucoup moins de bogues que le logiciel de bureau. Chez Viaweb, je doute que nous ayons jamais eu dix bogues connus à un moment donné. C'est de plusieurs ordres de grandeur mieux que le logiciel de bureau.

Les applications basées sur le 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 permettre à deux personnes de modifier le même document, par exemple. Viaweb permettait à plusieurs utilisateurs de modifier un site simultanément, non pas parce que nous nous attendions à ce que les utilisateurs le veuillent, mais parce que c'était la bonne façon d'écrire le logiciel, mais il s'est avéré que beaucoup le faisaient.

Lorsque vous utilisez une application basée sur le Web, vos données seront plus sécurisées. Les défaillances de disque ne seront pas des choses du passé, mais les utilisateurs n'en entendront plus parler. Elles se produiront dans des fermes de serveurs. Et les entreprises proposant des applications basées sur le Web effectueront réellement des sauvegardes – non seulement parce qu'elles ont de véritables administrateurs système s'occupant de ces choses, mais parce qu'un ASP qui perd les données des gens sera dans de gros, gros problèmes. Lorsque les gens perdent leurs propres données lors d'un défaillance de disque, ils ne peuvent pas se mettre vraiment 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, le logiciel basé sur le Web devrait être moins vulnérable 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 localement à endommager. Et un programme qui attaquerait les serveurs eux-mêmes devrait les trouver très bien défendus. [2]

Pour les utilisateurs, le logiciel basé sur le Web sera moins stressant. Je pense que si vous regardiez à l'intérieur d'un utilisateur moyen de Windows, vous trouveriez un énorme désir à peu près inexploité pour un logiciel répondant à cette description. Libéré, cela pourrait être une force puissante.

Ville de Code

Pour les développeurs, la différence la plus marquante entre le logiciel basé sur le Web et le logiciel de bureau est qu'une application basée sur le Web n'est pas un seul morceau de code. Ce sera une collection de programmes de différents types plutôt qu'un seul gros binaire. Ainsi, concevoir un logiciel basé sur le Web 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 départements de police et de pompiers, et de plans de croissance et de divers types de désastres.

Chez Viaweb, le logiciel comprenait des applications assez volumineuses avec lesquelles les utilisateurs interagissaient directement, des programmes utilisés par ces programmes, 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 cassaient, des programmes qui s'exécutaient occasionnellement pour compiler des statistiques ou créer des index pour les recherches, des programmes que nous exécutons explicitement pour collecter des ressources ou déplacer ou restaurer des données, des programmes qui faisaient semblant d'être des utilisateurs (pour mesurer les performances ou exposer des bogues), des programmes pour diagnostiquer les problèmes de réseau, des programmes pour effectuer des sauvegardes, des interfaces vers des services externes, un logiciel qui pilotait une impressionnante collection de cadrans affichant des statistiques de serveur en temps réel (un succès avec les visiteurs, mais indispensable pour nous aussi), des modifications (y compris des corrections de bogues) 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 arrêter, après que nous ayons été achetés par Yahoo. Les programmes nous envoyaient des pages, 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, 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'outils inutiles que les gens pourraient utiliser pour pénétrer vos serveurs.

Cela ne s'est pas arrêté aux logiciels. Nous avons passé beaucoup de temps à réfléchir aux configurations des serveurs. Nous avons construit nous-mêmes les serveurs, à 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 fournisseur ISP avait des connexions suffisamment rapides vers tous les réseaux. Nous avons eu des rendez-vous successifs avec des fournisseurs RAID.

Mais le matériel n'est pas seulement une source d'inquiétude. 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 d'autres. Si vous administrez les serveurs, vous pouvez en une étape permettre à tous vos utilisateurs d'envoyer des pages, ou des fax, ou de passer des commandes par téléphone, ou de traiter des cartes de crédit, etc., simplement en installant le matériel pertinent. Nous avions toujours cherché de nouvelles façons d'ajouter des fonctionnalités avec le hardware, non seulement parce que cela plaisait aux utilisateurs, mais aussi comme moyen de nous distinguer des concurrents qui (soit parce qu'ils vendaient des logiciels de bureau, soit qu'ils revendaient des applications basées sur le Web par le biais d'ISP) 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 un nombre quelconque 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, ce qui signifie C et C++. Et donc ces langages (en particulier parmi les personnes non techniques comme les gestionnaires et les VC) en sont venus à être considérés comme les langages pour le développement de logiciels "sérieux". Mais ce n'était qu'un artefact de la façon dont les logiciels de bureau devaient être livrés. Pour le logiciel basé sur des serveurs, vous pouvez utiliser n'importe quel langage que vous souhaitez. [3] Aujourd'hui, beaucoup des meilleurs hackers utilisent des langages très éloignés du C et du C++ : Perl, Python, et même Lisp.

Avec le logiciel basé sur des serveurs, personne ne peut vous dire quel langage utiliser, car vous contrôlez tout le 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 chacune. Et quand vous avez des concurrents, "vous pouvez" signifie "vous devez" (nous y reviendrons plus tard), car si vous ne tirez pas parti de cette possibilité, vos concurrents le feront.

La plupart de nos concurrents utilisaient C et C++, et cela rendait leur logiciel visiblement inférieur car (entre autres), ils n'avaient aucune solution pour contourner l'absence d'état des scripts CGI. Si vous deviez changer quelque chose, tous les changements devaient se faire sur une seule page, avec un bouton de mise à 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 pouvions 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 réalisez des versions. Dans le secteur des logiciels de bureau, faire une version est un gros traumatisme, où toute l'entreprise transpire et s'efforce de produire un seul gros morceau de code. Des comparaisons évidentes s'imposent, tant par rapport au processus qu'au produit résultant.

Avec le logiciel basé sur des serveurs, vous pouvez apporter des modifications presque comme vous le feriez dans un programme que vous écrivez pour vous-même. Vous publiez le logiciel sous forme de séries de modifications incrémentales plutôt qu'une grande explosion occasionnelle. Une entreprise de logiciels de bureau typique pourrait faire une ou deux versions par an. Chez Viaweb, nous effectuions souvent de trois à cinq versions par jour.

Lorsque vous passez à ce nouveau modèle, vous réalisez à quel point le développement de logiciels est affecté par sa façon de sortir. De nombreux problèmes désagréables que vous voyez dans le secteur des logiciels de bureau sont dus à la nature catastrophique des versions.

Lorsque vous publiez une seule nouvelle version par an, vous êtes en général amené à traiter des bogues en gros. Un certain temps avant la date de publication, vous assemblez une nouvelle version dans laquelle la moitié du code a été arrachée et remplacée, introduisant d'innombrables bogues. Ensuite, une équipe d'assurance qualité entre en jeu et commence à les compter, et les programmeurs travaillent sur la liste pour les corriger. Ils n'arrivent généralement pas à la fin de la liste, et en effet, personne n'est sûr de où se trouve la fin. C'est comme si vous pêchiez des débris d'un étang. Vous ne savez jamais vraiment ce qui se passe à l'intérieur du logiciel. Au mieux, vous finissez avec un genre de correction statistique.

Avec le logiciel basé sur des serveurs, la plupart des changements sont petits et incrémentaux. Cela, en soi, est moins susceptible d'introduire des bogues. Cela signifie également que vous savez quoi tester le plus soigneusement lorsque vous êtes sur le point de publier un logiciel : la dernière chose que vous avez modifiée. Vous finissez par avoir une prise beaucoup plus ferme sur le code. En règle générale, vous savez ce qui se passe à l'intérieur. Vous n'avez bien sûr pas le code source mémorisé, mais lorsque vous lisez le source, vous le faites comme un pilote qui scrute le tableau de bord, et non comme un détective essayant de résoudre un mystère.

Le logiciel de bureau engendre un certain fatalisme à propos des bogues. Vous savez que vous expédiez quelque chose chargé de bogues, et vous avez même mis en place des mécanismes pour compenser cela (par exemple, des sorties de patch). Alors pourquoi s'inquiéter d'un peu plus ? Bientôt, vous publiez même des fonctionnalités entières que vous savez être cassées. Apple a fait cela plus tôt cette année. Ils se sont sentis sous pression pour publier leur nouveau système d'exploitation, dont la date de sortie avait déjà été reportée quatre fois, mais une partie du logiciel (le support des CD et DVD) n'était pas prête. La solution ? Ils ont publié le système d'exploitation sans les parties inachevées, et les utilisateurs devront les installer plus tard.

Avec un logiciel basé sur le Web, vous n'avez jamais à publier le logiciel avant qu'il ne fonctionne, et vous pouvez le publier dès qu'il fonctionne.

Le vétéran de l'industrie pourrait penser qu'il s'agit d'une belle idée de dire que vous n'avez jamais à publier du 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 le logiciel basé 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 au logiciel basé sur le Web.

Si quelqu'un se souvient de Viaweb, cela pourrait sembler étrange, car nous annonçons toujours de nouvelles versions. Cela a été fait entièrement pour des raisons de relations publiques. La presse spécialisée, nous avons appris, pense en termes de numéros de version. Ils vous accordent une grande couverture pour une grande sortie, ce qui signifie un nouveau premier chiffre du numéro de version, et généralement un paragraphe au plus pour une sortie point, ce qui signifie un nouveau chiffre après le point décimal.

Certains de nos concurrents proposaient des logiciels de bureau et avaient effectivement des numéros de version. Et pour ces versions, le simple fait qui nous semblait une preuve de leur retard, ils obtiennent toutes sortes de publicités. Nous ne voulions pas manquer ça, donc nous avons commencé à donner des numéros de version à notre logiciel aussi. Lorsque nous voulions de la publicité, nous dressions 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 réprimandés pour cela.

Au moment où nous avons été achetés, nous avions fait cela trois fois, donc nous étions à 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 tel besoin désespéré de publicité, donc bien que le logiciel continue d'évoluer, l'idée des numéros de version a été abandonnée sans bruit.

Bogues

L'autre grand avantage technique du logiciel basé sur le Web est que vous pouvez reproduire la plupart des bogues. Vous avez les données des utilisateurs juste là sur votre disque. Si quelqu'un casse votre logiciel, vous n'avez pas à essayer de deviner ce qui se passe, comme cela serait le cas avec un logiciel de bureau : vous devriez pouvoir reproduire l'erreur pendant qu'ils sont au téléphone avec vous. Vous pourriez même déjà être au courant, si vous avez un code pour détecter les erreurs intégré dans votre application.

Le logiciel basé sur le Web est utilisé 24h/24, donc tout ce que vous faites est immédiatement soumis à des tests. Les bogues apparaissent rapidement.

Les entreprises de logiciels sont parfois accusées de laisser les utilisateurs déboguer leur logiciel. Et c'est justement ce que je préconise. Pour le logiciel basé sur le Web, c'est en fait un bon plan, car les bogues sont moins fréquents et éphémères. Lorsque vous publiez du logiciel progressivement, vous obtenez beaucoup moins de bogues pour commencer. Et lorsque vous pouvez reproduire des erreurs et publier des changements instantanément, vous pouvez trouver et corriger la plupart des bogues dès qu'ils apparaissent. Nous n'avons jamais eu suffisamment de bogues à un moment donné pour nous soucier d'un système de suivi des bogues formel.

Vous devriez tester les changements avant de les publier, bien sûr, donc pas de bogues majeurs ne devraient être publiés. Ceux qui glissent inévitablement impliqueront des cas limites et n'affecteront que les quelques utilisateurs qui les rencontrent avant que quelqu'un appelle pour se plaindre. Tant que vous corrigez les bogues tout de suite, l'effet net, pour l'utilisateur moyen, est d'avoir beaucoup moins de bogues. Je doute que l'utilisateur moyen de Viaweb ait vu un bogue.

Corriger des bogues récents est plus facile que de corriger de vieux bogues. Il est généralement assez rapide de trouver un bogue 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 le code source, car vous vous en préoccupiez déjà de manière subconsciente. Corriger un bogue dans quelque chose que vous avez écrit il y a six mois (le cas moyen si vous publiez une fois par an) représente 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 bogues. [4]

Lorsque vous repérez des bogues tôt, vous obtenez également moins de bogues composés. Les bogues composés sont deux bogues séparés qui interagissent : vous trébuchez en descendant des escaliers, et lorsque vous attrapez la rampe, elle se détache dans votre main. Dans le logiciel, ce type de bogue est le plus difficile à trouver, et a aussi tendance à avoir les pires conséquences. [5] L'approche traditionnelle de "tout casser puis filtrer les bogues" engendre intrinsèquement beaucoup de bogues composés. Et le logiciel publié sous forme de petites modifications tend naturellement à ne pas le faire. Les surfaces sont constamment nettoyées de tout objet lâche qui pourrait plus tard être coincé dans quelque chose.

Cela aide si vous utilisez une technique appelée programmation fonctionnelle. La programmation fonctionnelle signifie éviter les effets secondaires. C'est quelque chose que vous êtes plus susceptibles de voir dans des articles de recherche que dans des logiciels commerciaux, mais pour les applications basées sur le 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 considérables 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 apportez et testez constamment de petites modifications. J'ai écrit une grande partie de l'éditeur de Viaweb dans ce style, et nous avons fait notre langage de script, RTML, un langage purement fonctionnel.

Les personnes venant du secteur des logiciels de bureau auront du mal à y croire, mais chez Viaweb, les bogues devenaient presque un jeu. Étant donné que la plupart des bogues publiés impliquaient des cas limites, les utilisateurs qui les rencontraient étaient susceptibles d'être des utilisateurs avancés, poussant à l'extrême. Les utilisateurs avancés sont plus indulgents à l'égard des bogues, en particulier parce que vous les avez probablement introduits dans le cadre de l'ajout d'une fonctionnalité qu'ils demandaient. En fait, parce que les bogues étaient rares et que vous deviez 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 des erreurs, cela change votre approche du support client. Dans la plupart des entreprises de logiciels, le support est proposé comme un moyen de faire sentir aux clients qu'ils se sentent mieux. Ils appellent soit à propos d'un bogue connu, soit ils font juste quelque chose de mal et vous devez découvrir quoi. Dans les deux cas, il n'y a pas grand-chose à apprendre d'eux. Et donc, vous avez tendance à considérer les appels de support comme une douleur au derrière dont vous voulez isoler vos développeurs autant que possible.

Ce n'était pas comme cela que cela fonctionnait 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 tout de suite afin de pouvoir reproduire l'erreur et publier une correction.

Ainsi, chez Viaweb, les développeurs étaient toujours en contact étroit avec le support. Les personnes du support client se trouvaient à environ trente pieds des programmeurs, et savaient qu'elles pouvaient toujours interrompre n'importe quoi avec un rapport de bogue authentique. Nous quittions une réunion de bureau pour corriger un bogue sérieux.

Notre approche du support a rendu tout le monde plus heureux. Les clients étaient ravis. Imaginez comment ça se sentirait d'appeler une ligne de support et d'être traité comme quelqu'un apportant des nouvelles importantes. Les personnes du support client aimaient cela parce que cela signifiait qu'elles pouvaient aider les utilisateurs, au lieu de leur lire des scripts. Et les programmeurs aimaient cela parce qu'ils pouvaient reproduire des bogues au lieu d'entendre simplement des rapports vagues d'eux.

Notre politique de correction des bogues en temps réel a changé la relation entre le personnel 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. Quel que soit le processus de signalement des bogues, il est probablement unidirectionnel : les personnes du support qui entendent parler des bogues remplissent un formulaire qui finit par être transmis (possiblement via QA) aux programmeurs, qui le mettent sur leur liste de choses à faire. C'était très différent chez Viaweb. Dans la minute suivant l'annonce d'un bogue par un client, les personnes du support pouvaient se trouver à côté d'un programmeur l'entendant dire "Merde, tu as raison, c'est un bogue." Cela réjouissait les personnes du support de recevoir d'un hacker un "tu as raison". Ils nous apportaient des bogues avec la même attente qu'un chat vous apporte une souris qu'il vient de tuer. Cela les rendait également plus prudents dans la détermination de la gravité d'un bogue, car maintenant leur honneur était en jeu.

Après que nous ayons été achetés par Yahoo, les personnes du support client ont été éloignées des programmeurs. C'est seulement alors que nous avons réalisé qu'elles étaient effectivement un poste d'assurance qualité et dans une certaine mesure de marketing également. En plus de repérer les bogues, elles étaient les gardiens de la connaissance des choses vagues, de type bogue, comme des fonctionnalités qui déroutaient les utilisateurs. [6] Elles étaient également une sorte de groupe de discussion proxy ; nous pouvions leur demander laquelle de deux nouvelles fonctionnalités les utilisateurs voulaient le plus, et elles avaient toujours raison.

Moral

La capacité à publier des logiciels immédiatement est un grand motivateur. Souvent, alors que je marchais vers le travail, je pensais à un changement que je voulais apporter au logiciel, et je le faisais ce jour-là. Cela fonctionnait pour les plus grandes fonctionnalités aussi. Même si quelque chose allait prendre deux semaines à écrire (peu de projets prenaient plus longtemps), je savais que je pouvais voir l'effet dans le logiciel dès qu'il était terminé.

Si j'avais dû attendre un an pour la prochaine version, j'aurais mis de côté la plupart de ces idées, pour un certain temps du moins. Le problème avec les idées, cependant, 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 s'y retrouvent sont celles que vous avez pensées en l'écrivant ? La même chose se produit avec le logiciel. Travailler à la mise en œuvre d'une idée vous donne plus d'idées. Alors mettre une idée de côté vous coûte non seulement ce retard dans sa mise en œuvre, mais également toutes les idées que sa mise en œuvre aurait entraînées. En fait, mettre une idée de côté inhibe probablement même de nouvelles idées : alors que 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 de mettre en œuvre des fonctionnalités, c'est les planifier. Chez Viaweb, nous avons parfois rencontré des problèmes à cause de cela. Les investisseurs et les analystes nous demandaient ce que nous avions prévu pour l'avenir. La réponse honnête aurait été de dire que nous n'avions aucun plan. Nous avions des idées générales sur des choses que nous voulions améliorer, mais si nous savions comment, nous l'aurions déjà fait. Que devions-nous faire dans les six mois à venir ? Tout 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 désigner des idées mises de côté. Lorsque nous pensions à de bonnes idées, nous les mettions en œuvre.

Chez Viaweb, comme dans de nombreuses entreprises de logiciels, la plupart du code avait un propriétaire défini. Mais lorsque vous possédez quelque chose, vous le possédez vraiment : personne, sauf le propriétaire d'un logiciel, n'a à approuver (ou même à connaître) une publication. Il n'y avait aucune protection contre une rupture autre que la peur de passer pour un idiot devant ses pairs, et cela suffisait largement. J'ai peut-être donné l'impression que nous avancions tranquillement dans l'écriture du code. Nous allions vite, mais nous réfléchissions très soigneusement avant de publier le logiciel sur ces serveurs. Et faire attention est plus important pour la fiabilité que d'avancer lentement. Parce qu'il fait attention, un pilote de la Marine peut poser un avion de 40 000 lb à 140 milles à l'heure sur un pont de porte-avions en mouvement, de nuit, plus sûrement qu'un adolescent moyen peut couper un bagel.

Cette manière d'écrire des logiciels est bien sûr une arme à double tranchant. Elle fonctionne beaucoup mieux pour une petite équipe de bons programmeurs dignes de confiance que pour une grande entreprise de programmeurs médiocres, où les mauvaises idées sont détectées par des comités plutôt que par les personnes qui les ont eues.

Brooks à l'envers

Heureusement, le logiciel basé sur le Web nécessite moins de programmeurs. Un jour, j'ai travaillé pour une entreprise de logiciels de bureau de taille moyenne qui avait plus de 100 personnes travaillant dans l'ingénierie au total. Seulement 13 d'entre elles étaient dans le développement de produits. Tous les autres travaillaient sur des versions, des ports, etc. Avec le logiciel basé sur le Web, tout ce dont vous avez besoin (au maximum) ce 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, 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, mais avons créé de nouveaux projets pour eux.)

Lorsque vous pouvez écrire du logiciel avec moins de programmeurs, cela vous fait économiser plus que de l'argent. Comme Fred Brooks l'a fait remarquer dans The Mythical Man-Month, ajouter des personnes à un projet a tendance à le ralentir. Le nombre de connexions possibles entre développeurs croît exponentiellement avec la taille du groupe. Plus le groupe est grand, plus ils passeront de temps en réunions à négocier comment leur logiciel fonctionnera ensemble, et plus ils assisteront à des bogues dus à des interactions imprévues. Heureusement, ce processus fonctionne également à l'envers : à 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 véritable réunion. Nous n'avions jamais plus à dire à un moment donné que ce que nous pouvions dire en marchant vers le déjeuner.

S'il y a un inconvénient ici, c'est que tous les programmeurs doivent être à un certain degré des administrateurs système également. Lorsque vous hébergez des logiciels, quelqu'un doit surveiller les serveurs, et en pratique, les seules personnes capables de le faire correctement sont celles qui ont écrit le logiciel. Chez Viaweb, notre système avait tellement de composants et changeait si souvent qu'il n'y avait pas de limite nette entre logiciel et infrastructure. Déclarer arbitrairement une telle limite aurait restreint nos choix de conception. Ainsi, bien que nous espérions constamment qu'un jour ("dans quelques mois") tout serait suffisamment stable pour que nous puissions engager quelqu'un dont le job serait de s'inquiéter des serveurs, cela ne s'est jamais produit.

Je ne pense pas que cela pourrait être autrement, tant que vous êtes encore en train de développer activement le produit. Le logiciel basé sur le Web ne sera jamais quelque chose que vous écrivez, que vous vérifiez et puis rentrez chez vous. C'est une chose vivante, fonctionnant sur vos serveurs en ce moment. Un mauvais bogue peut non seulement planter le processus d'un utilisateur, il peut tous les faire planter. Si un bogue dans votre code corrompt certaines données sur le disque, vous devez le corriger. Et ainsi de suite. Nous avons découvert qu'il n'était pas nécessaire de surveiller les serveurs chaque minute (après la première année ou deux), mais vous voulez certainement garder un œil sur les choses que vous avez récemment modifiées. Vous ne publiez pas du code tard dans la nuit puis rentrez chez vous.

Surveiller les utilisateurs

Avec un logiciel basé sur des serveurs, vous êtes en contact plus étroit avec votre code. Vous pouvez également être en contact plus étroit avec vos utilisateurs. Intuit est célèbre pour se présenter aux clients dans les magasins de vente au détail et leur demander 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 doivent les attendre.

Le logiciel doit 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, tant que vous ne les regardez pas. Et le logiciel basé sur le Web vous donne 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 examiner, 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 à vous fier à des indicateurs de performance, par exemple. Les indicateurs de performance sont des utilisateurs simulés. Avec le logiciel basé sur le Web, vous pouvez observer les utilisateurs réels. Pour décider quoi optimiser, connectez-vous simplement à un serveur et voyez ce qui consomme toute la CPU. Et vous savez aussi quand arrêter d'optimiser : nous avons finalement amené l'éditeur Viaweb au point où c'était la mémoire qui était le frein plutôt que la CPU, et comme il n'y avait rien que nous puissions faire pour réduire la taille des données des utilisateurs (enfin, rien de facile), nous savions que nous devions nous arrêter là.

L'efficacité compte pour le logiciel basé sur le Web, car vous payez pour le matériel. Le nombre d'utilisateurs que vous pouvez supporter par serveur est le diviseur de votre coût d'investissement, donc si vous pouvez rendre votre logiciel très efficace, vous pouvez sous-vendre vos concurrents et dégager un profit. Chez Viaweb, nous avions réduit le coût d'investissement par utilisateur à environ 5 $. Ce serait moins maintenant, probablement moins que le coût de l'envoi de leur première facture. Le matériel est maintenant gratuit, si votre logiciel est raisonnablement efficace.

Surveiller les utilisateurs peut vous guider dans la conception ainsi que dans 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 devenait une sorte de boîte à idées, car les utilisateurs ne l'utilisaient que lorsque les styles de page pré-définis ne pouvaient pas répondre à leurs besoins. À 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 mettre des boutons sur le côté gauche, nous avons fait de cela une option (en fait le paramètre par défaut) dans les styles de pages pré-définis.

Enfin, en surveillant les utilisateurs, vous pouvez souvent dire quand ils sont dans le pétrin. Et puisque 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 le test en ligne. Ce n'était pas juste une série de diapositives élaborées par des spécialistes du marketing. Lors de notre test, les utilisateurs utilisaient réellement le logiciel. Cela prenait environ cinq minutes, et à la fin, ils avaient construit un véritable magasin fonctionnel.

Le test en ligne était la façon dont nous avons presque tous nos nouveaux utilisateurs. Je pense que ce sera la même chose pour la plupart des applications basées sur le Web. Si les utilisateurs peuvent passer un test en ligne avec succès, ils aimeront le produit. S'ils sont confus ou s'ennuient, ils ne l'aimeront pas. Donc, tout ce que nous pouvions faire pour faire passer plus de gens par le test en ligne augmenterait notre taux de croissance.

J'ai étudié les pistes de clic des personnes prenant le test de conduite et j'ai constaté qu'à un certain stade, elles se confondaient 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à, informant les utilisateurs qu'ils étaient presque terminés et leur rappelant de ne pas cliquer sur le bouton Retour. Une autre chose géniale à propos des logiciels basés sur le Web est que vous obtenez un retour instantané des changements : le nombre de personnes complétant le test de conduite est immédiatement passé de 60 % à 90 %. Et puisque le nombre de nouveaux utilisateurs dépendait du nombre de tests de conduite complété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 d'abonnement. Au départ, 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 de logiciels est un processus continu. Je pense qu'il est plus clair de facturer ouvertement des frais d'abonnement, plutôt que de forcer les gens à continuer à acheter et à installer de nouvelles versions pour qu'ils continuent à vous payer. Et heureusement, les abonnements sont le moyen naturel de facturer pour des applications basées sur le Web.

L'hébergement d'applications est un domaine où les entreprises joueront un rôle qui ne sera probablement pas comblé par des logiciels gratuits. L'hébergement d'applications est stressant et entraîne de réelles dépenses. Personne ne voudra le faire gratuitement.

Pour les entreprises, les applications basées sur le 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. Comme votre logiciel évolue progressivement, vous n'avez pas à vous soucier qu'un nouveau modèle échoue ; il n'est jamais nécessaire d'avoir un nouveau modèle, en soi, et si vous faites quelque chose au logiciel que les utilisateurs détestent, vous le saurez tout de suite. Vous n'avez aucun problème avec des factures irrécouvrables ; si quelqu'un ne paie pas, vous pouvez simplement couper le service. Et il n'y a aucune possibilité de piraterie.

Cet "avantage" final pourrait s'avérer être un problème. Une certaine quantité de piraterie est à l'avantage des sociétés de logiciels. Si un utilisateur n'aurait vraiment pas acheté votre logiciel à aucun prix, vous n'avez rien perdu s'il utilise une copie piratée. En fait, vous gagnez, car il s'agit d'un utilisateur de plus qui aide à faire de votre logiciel la norme -- ou qui pourrait acheter une copie plus tard, lorsqu'il obtiendra son diplôme de lycée.

Lorsque c'est possible, les entreprises aiment faire quelque chose appelé discrimination par les prix, ce qui signifie facturer à chaque client autant qu'il peut se le 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 à faire fonctionner sur des Suns que sur des machines 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é. La piraterie est effectivement le niveau le plus bas de discrimination par les prix. Je pense que les sociétés de logiciels comprennent cela et ferment délibérément les yeux sur certains types de piraterie. [9] Avec les logiciels basés sur des serveurs, elles devront trouver une autre solution.

Les logiciels basés sur le Web se vendent bien, en particulier par rapport aux logiciels de bureau, car il est facile de les acheter. Vous pourriez penser que les gens décident d'acheter quelque chose, puis l'achètent, comme deux étapes distinctes. C'est ce que je pensais avant Viaweb, dans la mesure où je pensais à la question. En fait, la deuxième étape peut se répercuter sur la première : si quelque chose est difficile à acheter, les gens changeront d'avis sur leur désir de l'avoir. Et vice versa : vous vendrez plus de quelque chose lorsqu'il est facile à acheter. J'achète plus de livres parce qu'Amazon existe. Les logiciels basés sur le Web sont presque les choses les plus faciles au monde à acheter, surtout si vous venez de faire une démo en ligne. Les utilisateurs ne devraient pas avoir à faire beaucoup plus que saisir 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 proposés par le biais de FAI agissant comme revendeurs. C'est une mauvaise idée. Vous devez administrer les serveurs, car vous devez constamment améliorer à la fois le matériel et le logiciel. Si vous abandonnez le contrôle direct des serveurs, vous abandonnez la plupart des avantages de développement d'applications basées sur le Web.

Plusieurs de nos concurrents se sont tiré une balle dans le pied de cette manière -- généralement, je pense, parce qu'ils étaient envahis par des costumes excités par ce vaste canal potentiel, et ne réalisaient pas que cela ruinerait le produit qu'ils espéraient vendre par son intermédiaire. Vendre des logiciels basés sur le Web par le biais de FAI, c'est comme vendre des sushis par le biais de distributeurs automatiques.

Clients

Qui seront les clients ? Chez Viaweb, ils étaient initialement des individus et des petites entreprises, et je pense que cela sera la règle avec les applications basées sur le 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 inférieurs de la nouvelle technologie.

Les applications basées sur le Web seront souvent les meilleures également pour les grandes entreprises (même si elles mettront du temps à s'en rendre compte). Le meilleur intranet est Internet. Si une entreprise utilise de vraies applications basées sur le 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 sûres sur leurs propres serveurs. Il n'était pas facile d'exprimer ce point de manière diplomatique, mais en fait, les données étaient presque certainement plus sûres entre nos mains que les leurs. Qui peut embaucher de meilleures personnes pour gérer la sécurité, une startup technologique dont toute l'activité est l'exploitation de serveurs, ou un détaillant de vêtements ? Non seulement nous avions de meilleures personnes s'inquiétant de la sécurité, mais nous nous en préoccupions davantage. Si quelqu'un s'introduisait dans les serveurs d'un détaillant de vêtements, cela affecterait au maximum un commerçant, pourrait probablement être étouffé, 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, se retrouverait probablement dans les nouvelles sur CNet, et pourrait nous mettre hors de l'affaire.

Si vous voulez garder votre argent en sécurité, le gardez-vous sous votre matelas à la maison, ou le mettez-vous dans une banque ? Cet argument s'applique à chaque aspect de l'administration des serveurs : non seulement la sécurité, mais aussi la disponibilité, la bande passante, la gestion de la charge, les sauvegardes, etc. Notre existence dépendait de l'exécution correcte de ces tâches. Les problèmes de serveur étaient notre plus gros interdit, 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 basées sur le Web sous-traite dans une certaine mesure les TI. Aussi radical 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 de la part d'administrateurs système internes. Les administrateurs système peuvent devenir grincheux et peu réactifs parce qu'ils ne sont pas directement soumis à une pression concurrentielle : un vendeur doit traiter avec des clients, et un développeur doit gérer les logiciels de concurrents, mais un administrateur système, comme un vieux célibataire, a peu de forces extérieures pour le maintenir en ligne. [10] Chez Viaweb, nous avions plein de forces extérieures pour nous maintenir en ligne. Les personnes qui nous appelaient étaient des clients, pas seulement des collègues. Si un serveur était coincé, nous réagissions ; rien que d'y penser me donne un coup d'adrénaline, des années plus tard.

Ainsi, les applications basées sur le Web seront ordinairement la bonne réponse pour les grandes entreprises aussi. Ce seront les dernières à s'en rendre compte, cependant, tout comme elles l'étaient avec les ordinateurs de bureau. Et en partie pour la même raison : il sera très rentable 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 des solutions bon marché sont meilleures, parce que les personnes proposant des solutions chères peuvent dépenser plus pour les vendre. Chez Viaweb, nous avons toujours été confrontés à cela. Nous avons perdu plusieurs grands commerçants au profit de sociétés de conseil Web qui les ont convaincus qu'ils s'en sortiraient mieux s'ils payaient un demi-million de dollars pour un magasin en ligne sur leur propre serveur. En règle générale, ils ne s'en sortaient pas mieux, comme plus d'un l'a découvert lorsque la saison des achats de Noël est arrivée et que les charges sur leur serveur ont augmenté. Viaweb était beaucoup plus sophistiqué que ce que la plupart de ces commerçants ont obtenu, mais nous ne pouvions pas nous le permettre. À 300 $ par mois, nous ne pouvions pas nous permettre d'envoyer une équipe de personnes bien habillées et ayant une voix 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 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 vendre des sièges de toilettes pour mille dollars.) Et c'est une des raisons pour lesquelles le logiciel intranet continuera de prospérer, même si c'est probablement une mauvaise idée. C'est tout simplement plus cher. Il n'y a rien que vous puissiez faire à ce paradoxe, donc le meilleur plan est de cibler d'abord les petits clients. Le reste viendra en temps voulu.

Fils de Serveur

Faire fonctionner des logiciels sur le serveur n'est rien de nouveau. En fait, c'est l'ancien modèle : les applications mainframe sont toutes basées sur des serveurs. Si les logiciels basés sur des serveurs sont une si bonne idée, pourquoi ont-ils échoué la dernière fois ? Pourquoi les ordinateurs de bureau ont-ils éclipsé les mainframes ?

Au début, les ordinateurs de bureau ne semblaient pas beaucoup menacer. 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, 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 serait aujourd'hui.

Pourquoi les ordinateurs de bureau ont-ils pris le dessus ? Je pense que c'était parce qu'ils avaient de meilleurs logiciels. Et je pense que la raison pour laquelle le logiciel de micro-ordinateur était meilleur est qu'il pouvait être écrit par de petites entreprises.

Je ne pense pas que beaucoup de gens réalisent à quel point les startups sont fragiles et temporaires au tout début. De nombreuses startups commencent presque par accident -- comme un couple de gars, soit avec des emplois de jour ou à 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ête la startup sur-le-champ. Écrire des logiciels pour mainframe exigeait trop d'engagement au départ. Les machines de développement étaient coûteuses, et comme les clients seraient de grandes entreprises, vous auriez besoin d'une force de vente impressionnante pour leur vendre. Démarrer une startup pour écrire des logiciels de mainframe serait une entreprise beaucoup plus sérieuse que simplement assembler quelque chose sur votre Apple II le soir. Ainsi, vous n'obteniez pas beaucoup de startups écrivant 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 de jeunes startups. Le développement était peu coûteux, et les clients seraient des individus que vous pourriez atteindre par le biais de magasins d'informatique ou même par commande par correspondance.

L'application qui a propulsé les ordinateurs de bureau dans le courant principal était VisiCalc, le premier tableur. Elle a été écrite par deux gars travaillant dans un grenier, et pourtant elle faisait des choses que aucun logiciel de mainframe ne pouvait faire. [11] VisiCalc était un tel progrès, à son époque, que les gens achetaient des Apple II juste pour l'utiliser. Et c'était 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 des serveurs seront bons cette fois-ci, car les startups vont les écrire. Les ordinateurs sont si bon marché maintenant que vous pouvez vous lancer, comme nous l'avons fait, en utilisant un ordinateur de bureau comme serveur. Les processeurs peu coûteux ont émergé sur le marché des stations de travail (vous n'entendez même plus rarement le 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 où 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 grâce au bouche-à-oreille et aux références dans la presse. [12]

Viaweb était une startup typique en phase larvaire. Nous avions peur de commencer une entreprise, et pendant les premiers mois, nous nous rassurions en considérant 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 à cette étape é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 termes de Microsoft, appelant leurs API et contournant leur système d'exploitation bogué. Et si vous parvenez à écrire quelque chose qui décolle, vous pourriez découvrir que vous faisiez simplement de la recherche de marché pour Microsoft.

Si une entreprise veut créer une plateforme sur laquelle les startups pourront s'appuyer, elles doivent 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 lorsqu'il est sorti, et beaucoup d'entre eux ont écrit des logiciels pour lui. [13] Vous le voyez moins avec Windows, car les hackers ne l'utilisent pas. Les gens qui sont bons pour écrire des logiciels ont tendance à utiliser 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 que nous puissions écrire des logiciels pour Windows, nous devrions l'utiliser. Le Web nous a permis de contourner Windows et de fournir des logiciels fonctionnant sur Unix directement aux utilisateurs par le biais du navigateur. C'est une perspective libératrice, très semblable à l'arrivée des PC il y a vingt-cinq ans.

Microsoft

Lorsque les ordinateurs de bureau sont arrivés, IBM était le géant dont tout le monde avait peur. Il est difficile d'imaginer maintenant, mais je me rappelle 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 le point aveugle 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 plus. C'est un problème pour Microsoft, et ils le savent. Si les applications fonctionnent sur des serveurs distants, personne n'a besoin de Windows. Que fera Microsoft ? Pourront-ils utiliser leur contrôle sur le bureau pour empêcher ou contraindre cette nouvelle génération de logiciels ?

Mon avis est que Microsoft développera une sorte d'hybride serveur/bureau, où le système d'exploitation fonctionne avec les serveurs qu'ils contrôlent. Au minimum, les fichiers seront centralement disponibles 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 pour un client, s'ils peuvent 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, ils ne peuvent pas pousser les utilisateurs vers leurs applications basées sur des serveurs.

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 devancer en proposant des applications qui fonctionnent avec n'importe quel client. [14]

Dans un monde d'applications basées sur le 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 que c'est qu'ils trébucheront sur eux-mêmes. Avec la montée des logiciels basés sur le Web, ils seront confrontés non seulement à des problèmes techniques mais également à leur propre optimisme. Ce qu'ils doivent faire, c'est cannibaliser leur entreprise existante, et je ne peux pas les voir faire face à cela. La même obsession qui les a amenés jusqu'ici travaillera maintenant contre eux. IBM était dans une situation exactement similaire et n'a pas pu la maîtriser. IBM a fait une entrée tardive et tiède dans le secteur des micro-ordinateurs parce qu'ils étaient ambivalents à l'idée de menacer leur vache à lait, l'informatique mainframe. Microsoft sera également entravé par le désir de sauver le bureau. Une vache à lait peut être un bien lourd fardeau à porter.

Je ne dis pas que personne ne dominera les applications basées sur des serveurs. Quelqu'un le fera probablement un jour. Mais je pense qu'il y aura une longue période de chaos joyeux, tout comme il y en avait au début des micro-ordinateurs. C'était une bonne époque pour les startups. De nombreuses petites entreprises ont prospéré en créant des choses intéressantes.

Startups mais encore plus

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 amplifie l'effet des décisions qu'elles prennent. Si elles gagnent, elles gagnent gros.

Dans une startup écrivant 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 en sortir en étant plus informel. Vous pouvez littéralement lancer votre produit en tant que trois gars assis dans le salon d'un appartement, avec 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 signifiait une pièce remplie d'hommes portant des lunettes à monture en corne et des cravates noires étroites, écrivant industriquement 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, ce sont quelques gars assis dans un salon avec des ordinateurs portables. (Et les jeans ne s'avèrent pas être le dernier mot en matière d'informalité.)

Les startups sont stressantes, et cela, malheureusement, est également poussé à l'extrême avec les applications basées sur le Web. Beaucoup de sociétés de logiciels, notamment au début, ont connu des périodes où les développeurs dormaient sous leurs bureaux, etc. La chose inquiétante à propos des logiciels basés sur le Web, c'est qu'il n'y a rien pour empêcher cela de devenir la norme. Les histoires sur le fait de dormir sous les bureaux se terminent généralement ainsi : puis enfin, nous l'avons expédié et nous sommes tous rentrés chez nous et avons dormi 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 pouvez, et que vos concurrents peuvent, vous serez souvent contraint de le faire. Vous pouvez, donc vous devez. C'est la loi de Parkinson qui fonctionne à l'envers.

La pire chose n'est pas les heures, mais la responsabilité. Les programmeurs et les administrateurs système ont traditionnellement chacun leurs propres inquiétudes séparées. Les programmeurs doivent s'inquiéter des bogues, et les administrateurs système doivent s'inquiéter de l'infrastructure. Les programmeurs peuvent passer une longue journée jusqu'aux coudes dans le code source, mais à un certain moment, ils peuvent rentrer chez eux et l'oublier. Les administrateurs système ne laissent jamais tout à fait leur travail derrière eux, mais quand ils sont appelés à 4h00 du matin, ils n'ont généralement pas à faire quoi que ce soit 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 d'ordinaire le travail supportable.

Chez Viaweb, nous avons passé les six premiers mois à juste écrire du logiciel. Nous avons travaillé les heures habituelles d'une startup en début d'activité. 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 pris des utilisateurs sur notre serveur. Le deuxième plus grand avantage de vendre 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 administrateurs système. Les logiciels basés sur le Web obligent les programmeurs à le faire. Il y a moins de stress au total, mais plus de stress pour les programmeurs. Ce n'est pas forcément une mauvaise nouvelle. Si vous êtes une startup en concurrence avec une grande entreprise, c'est une bonne nouvelle. [15] Les applications basées sur le Web offrent un moyen simple de travailler plus dur que vos concurrents. Aucune startup ne demande plus.

Juste Assez Bon

Une chose qui pourrait vous décourager d'écrire des applications basées sur le Web est la banalité des pages Web en tant qu'interface utilisateur. C'est un problème, j'en conviens. 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 dans ces machines n'étaient pas vraiment destinés à être les CPU des ordinateurs. Ils étaient conçus pour être utilisés dans des choses comme les feux de circulation. 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 sur le 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 suffisamment avantageux en soi pour l'emporter sur toute awkwardness dans l'interface utilisateur. Peut-être que vous ne pouvez pas écrire le tableur le plus esthétique en utilisant HTML, mais vous pouvez écrire un tableur que plusieurs personnes peuvent utiliser simultanément depuis différents emplacements sans logiciel client spécial, ou qui peut incorporer des flux de données en direct, ou qui peut vous envoyer une alerte 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 seulement 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 des serveurs n'ont pas à ê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 se lieraient tous - mais s'ils ne le font pas, vous êtes foutu. Parce que 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 grandira à mesure que de nouveaux appareils Web prolifèrent. Les utilisateurs vous aimeront parce que votre logiciel fonctionne 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 suivi l'évolution du Web de près, et je ne peux pas prédire ce qui va arriver avec les clients. La convergence est probablement à venir, mais où ? Je ne peux pas désigner un gagnant. Une chose que je peux prédire, c'est un conflit entre AOL et Microsoft. Quoi que soit le .NET de Microsoft, cela impliquera probablement de connecter le bureau et les serveurs. À moins qu'AOL ne riposte, ils seront soit écartés, soit transformés en pipeline entre les logiciels clients et serveurs de Microsoft. Si Microsoft et AOL entrent dans une guerre des clients, la seule chose qui devrait fonctionner sur les deux sera la navigation sur le Web, ce qui signifie que les applications basées sur le Web seront le seul type qui fonctionnera 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 basées sur le Web. Personne ne peut casser cela sans casser la navigation. Le Web n'est peut-être pas le seul moyen de livrer des logiciels, mais c'est un moyen qui fonctionne maintenant et qui continuera à fonctionner pendant longtemps. Les applications basées sur le Web sont peu coûteuses à développer et faciles à livrer même pour la plus petite des startups. Elles demandent beaucoup de travail, et de nature particulièrement stressante, mais cela ne fait qu'améliorer les chances pour les startups.

Pourquoi Pas ?

E. B. White a été amusé d'apprendre d'un ami agriculteur que de nombreuses clôtures électrifiées ne contiennent aucune courant. Apparemment, les vaches apprennent à les éviter, et après cela, vous n'avez plus besoin du courant. "Levez-vous, vaches !" a-t-il écrit, "Prenez votre liberté pendant que les despotes ronflent !"

Si vous êtes un hacker qui a pensé un jour à lancer une startup, il y a probablement deux choses qui vous empêchent de le faire. L'une est que vous ne savez rien sur les 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 : construisez quelque chose que les utilisateurs adorent, et dépensez moins que ce que vous gagnez. Si vous réussissez ces deux points, vous serez en avance sur la plupart des startups. Vous pouvez comprendre le reste au fur et à mesure.

Vous ne ferez peut-être pas au début plus que ce que vous dépensez, mais tant que l'écart se rétrécit assez rapidement, vous serez d'accord. Si vous partez 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 basée sur le Web. Nous avons lancé pour moins de 10 000 $, et cela coûterait encore moins aujourd'hui. Nous devions dépenser des milliers pour un serveur, et des milliers de plus pour obtenir un 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é uniquement pour la bande passante. Vous pourriez lancer une application basée sur le Web maintenant pour moins que le coût d'une chaise de bureau élégante.

Quant à construire quelque chose que les utilisateurs adorent, voici quelques conseils généraux. Commencez par créer quelque chose de propre et simple que vous voudriez utiliser vous-même. Mettez rapidement une version 1.0 sur le marché, puis continuez à améliorer le logiciel, en écoutant attentivement les utilisateurs au fur et à mesure. Le client a toujours raison, mais des clients différents ont raison sur des choses différentes ; 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 manière d'y parvenir est de bien définir les valeurs par défaut, et non de limiter les choix des utilisateurs. Ne devenez pas complaisant si le logiciel de vos concurrents est nul ; la norme à laquelle comparer votre logiciel est ce qu'il pourrait être, pas ce que vos concurrents actuels ont. Utilisez vous-même votre logiciel, tout le temps. Viaweb devait être un constructeur de boutiques en ligne, mais nous l'avons également utilisé pour créer notre propre site. N'écoutez pas les spécialistes du marketing ni les designers ou les chefs de produit simplement à cause de leurs titres. 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, et non par des designers qui savent un peu sur le logiciel. Si vous ne pouvez pas concevoir des logiciels aussi bien que les implémenter, ne lancez pas de startup.

Parlons maintenant de la concurrence. Ce que vous craignez ne sont pas des groupes de hackers comme vous, mais de véritables entreprises, avec des bureaux et des plans d'affaires et des vendeurs et ainsi de suite, n'est-ce pas ? Eh bien, ils ont plus peur de vous que vous n'en avez d'eux, et ils ont raison. Il est beaucoup plus facile pour quelques hackers de comprendre comment louer un espace de bureau ou embaucher des vendeurs que pour une entreprise de toute taille d'écrire des logiciels. J'ai été des deux côtés, et je le sais. Lorsque Viaweb a été acheté par Yahoo, je me suis soudainement retrouvé à travailler pour une grande entreprise, et c'était comme essayer de courir à travers de l'eau jusqu'à la taille.

Je ne veux pas dénigrer Yahoo. Ils avaient de bons hackers, et la direction était de véritables fonceurs. Pour une grande entreprise, ils étaient exceptionnels. Mais ils n'étaient toujours productifs qu'à hauteur d'un dixième d'une petite startup. Aucune grande entreprise ne peut faire beaucoup mieux que cela. Ce qui est inquiétant avec Microsoft, c'est qu'une entreprise si grande peut développer des logiciels. Ils sont comme une montagne qui peut marcher.

Ne soyez pas intimidé. Vous pouvez faire autant 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 besoin de demander la permission à quiconque pour développer des applications basées sur le Web. Vous n'avez pas besoin de conclure des accords de licence, ou d'obtenir des espaces de rayonnage dans les magasins de détail, ou de vous abaisser pour avoir votre application intégrée au système d'exploitation. Vous pouvez livrer des logiciels directement dans le navigateur, et personne ne peut se mettre entre vous et des utilisateurs potentiels sans les empêcher de naviguer sur le Web.

Vous ne le croirez peut-être pas, mais je vous promets, Microsoft a peur de vous. Les managers moyens peuvent ne pas l'être, mais Bill, lui, l'est, car il était vous autrefois, en 1975, la dernière fois qu'une nouvelle manière de livrer des logiciels est apparue.

Notes

[1] Réalisant qu'une grande partie de l'argent provient des 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 que vous avez besoin de deux types d'entreprises différentes pour construire des électroniques grand public et pour diriger un service en ligne, et en partie parce que les utilisateurs détestent l'idée. Offrir le rasoir et gagner de l'argent sur les lames peut fonctionner pour Gillette, mais un rasoir représente un engagement beaucoup plus petit qu'un terminal Web. Les fabricants de téléphones portables sont satisfaits de vendre du matériel sans essayer de capturer les revenus de service également. Cela devrait probablement être le modèle pour les clients Internet aussi. Si quelqu'un vendait juste une jolie petite boîte avec un navigateur Web que vous pourriez utiliser pour vous connecter à travers n'importe quel FAI, chaque technophobe du pays achèterait une.

[2] La sécurité dépend toujours plus de ne pas merder que de toute décision de conception, mais la nature des logiciels basés sur des serveurs incitera les développeurs à faire davantage attention à ne pas merder. Compromettre un serveur pourrait causer tant de dommages que les ASP (qui veulent rester en affaires) sont susceptibles de faire attention à la sécurité.

[3] En 1995, lorsque nous avons commencé Viaweb, les applets Java étaient censées être la technologie que tout le monde allait utiliser pour développer des applications basées sur des serveurs. Les applets nous semblaient une idée démodée. Télécharger des programmes pour s'exécuter sur le client ? Il était plus simple d'y aller à fond 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 piège. Peu d'entre elles ont pu s'en sortir vivantes, ou Microsoft n'aurait pas pu se permettre de laisser tomber Java dans la version la plus récente d'Explorer.

[4] Ce point est dû à Trevor Blackwell, qui ajoute "le coût d'écriture du logiciel augmente plus que linéairement avec sa taille. Peut-être que cela est principalement dû à la correction de vieux bogues, et le coût peut être plus linéaire si tous les bogues sont rapidement trouvés."

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

[6] Au sein de Viaweb, nous avons une fois organisé un concours pour décrire la pire chose à propos de notre logiciel. Deux personnes du service client ont égalé le premier prix avec des soumissions auxquelles je reçois encore des frissons en repensant. Nous avons immédiatement corrigé 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 des commandes, consulter des statistiques et configurer des noms de domaine, etc. J'ai écrit l'éditeur, que les commerçants 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 (à quelle fréquence 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 constater qu'elle était illégale aux États-Unis par la loi Robinson-Patman 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 les "jeunes urbains" n'essaient pas trop d'empêcher le vol à l'étalage, car dans leur marché cible, les voleurs à l'étalage sont également les leaders de la mode.

[10] Les entreprises se demandent souvent que sous-traiter et que ne pas sous-traiter. Une réponse possible : sous-traiter tout travail qui n'est pas directement exposé à une pression concurrentielle, car le sous-traiter l'exposera dès lors à une 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 (surtout la nuit) pour créer une version plus puissante écrite en langage machine 6502. Dan était alors à la Harvard Business School et Bob avait nommément un emploi de jour à écrire des logiciels. "Il n'y avait pas de grand risque à monter une entreprise," a écrit Bob, "si ça échouait, ça échouait. Pas de gros problème."

[12] Ce n'est pas tout à fait aussi facile que je le fais sonner. Cela a pris un temps horriblement long pour que le bouche-à-oreille commence, et nous n'avons pas commencé à obtenir beaucoup de couverture médiatique jusqu'à ce que nous engagions une entreprise de relations publiques (il est vrai que c'était la meilleure dans le domaine) pour 16 000 $ par mois. Cependant, il était vrai que la seule voie significative é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 l'entreprise de logiciels et a lâché une série de fournisseurs de composants bon marché sur le matériel d'Apple. Cela n'a pas aidé non plus que des costumes aient pris le relais pendant une période critique.

[14] Une chose qui aiderait les applications basées sur le 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 petit navigateur rapide qui serait activement maintenu serait en soi une grande chose et encouragerait probablement également les entreprises à construire de petits appareils Web.

Entre autres choses, un véritable navigateur open-source ferait évoluer HTTP et HTML (comme par exemple Perl l'a fait). Il aiderait beaucoup les applications basées sur le Web à être capables de distinguer entre sélectionner un lien et le suivre ; tout ce dont vous auriez besoin pour cela serait une amélioration triviale d'HTTP, pour permettre plusieurs URLs dans une requête. Des menus déroulants seraient également bons.

Si vous voulez changer le monde, écrivez un nouvel 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é qu'ils avaient tort. Il y a toujours de la place pour quelque chose de nouveau si les options actuelles sont suffisamment merdiques. Assurez-vous d'abord que cela fonctionne sur tous les systèmes d'exploitation gratuits - les nouvelles choses commencent avec leurs utilisateurs.

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

"J'irais plus loin en disant qu'à cause du logiciel basé sur les serveurs étant si exigeant pour les programmeurs, cela cause un déplacement économique fondamental loin des grandes entreprises. Cela nécessite du genre d'intensité et de dévouement des programmeurs qu'ils ne seront disposés à fournir que lorsque c'est 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 endurer des épreuves, mais elles ne peuvent pas embaucher des personnes hautement qualifiées pour se faire casser le cul. Comme le capital n'est plus nécessaire, les grandes entreprises ont peu à apporter."

[16] Dans la version originale de cet essai, j'ai conseillé 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 avoir lu les brouillons de cet article ; à Dan Bricklin et Bob Frankston pour des informations sur VisiCalc ; et encore une fois à Ken Anderson de m'avoir invité à parler à BBN.

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