L'AUTRE ROUTE À VENIR

Septembre 2001

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

À l'été 1995, mon ami Robert Morris et moi avons décidé de démarrer une startup. La campagne de relations publiques précédant l'introduction en bourse de Netscape battait alors son plein, et il y avait beaucoup de discussions dans la presse sur le commerce en ligne. À l'époque, il y avait peut-être une trentaine de véritables magasins sur le Web, tous faits à la main. S'il devait y avoir beaucoup de magasins en ligne, il faudrait un logiciel pour les créer, nous avons donc décidé d'en écrire.

Pendant la première semaine ou deux, 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 bonne voie. 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. Maintenant, sous le nom de Yahoo Store, ce logiciel est le plus populaire pour la création de boutiques en ligne, avec environ 14 000 utilisateurs.

Quand nous avons démarré Viaweb, presque personne ne comprenait ce que nous voulions dire quand nous disions que le logiciel s'exécutait sur le serveur. Ce n'est qu'un an plus tard, avec le lancement de Hotmail, que les gens ont commencé à comprendre. Maintenant, tout le monde sait que c'est une approche valable. Il y a un nom maintenant 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 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 passent du bureau aux serveurs, ce sera un monde très différent pour les développeurs. Cet article décrit les choses surprenantes que nous avons vues, en tant que quelques-uns des premiers visiteurs de ce nouveau monde. Dans la mesure où les logiciels passent sur les serveurs, ce que je décris ici est l'avenir.

La prochaine chose ?

Quand nous regarderons en arrière sur l'ère des logiciels de bureau, je pense que nous serons émerveillés par les inconvénients que les gens ont acceptés, tout comme nous le sommes maintenant par ce que les premiers propriétaires de voitures ont dû supporter. Pendant les vingt ou trente premières années, il fallait être un expert automobile pour posséder une voiture. Mais les voitures étaient tellement un progrès que beaucoup de gens qui n'étaient pas des experts automobiles voulaient en avoir aussi.

Les ordinateurs en sont à cette phase maintenant. Quand vous possédez un ordinateur de bureau, vous finissez par en apprendre beaucoup plus que vous ne le vouliez 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 le courrier électronique et la comptabilité. Il y a environ un an, elle a été alarmée de recevoir une lettre d'Apple, lui offrant une remise 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 le courrier électronique et la comptabilité 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 épargnera 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 Web, la plupart des utilisateurs n'auront pas à penser à quoi que ce soit d'autre que les applications qu'ils utilisent. Tout le côté sale et changeant sera assis sur un serveur quelque part, entretenu par le genre de personnes qui sont bonnes à ce genre de choses. Et donc vous n'aurez pas besoin d'un ordinateur, en soi, pour utiliser des logiciels. Tout ce dont vous aurez besoin sera quelque chose avec un clavier, un écran et un navigateur Web. Peut-être qu'il aura un accès Internet sans fil. Peut-être que ce sera aussi votre téléphone portable. Quoi que ce 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 maintenant 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 que les calculs se fassent sur le bureau. Mais si vous regardez le genre de choses que la plupart des gens utilisent les ordinateurs, un délai de 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 gain 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 demande le moins d'efforts. Si les logiciels Web l'emportent, ce sera parce qu'ils sont plus pratiques. Et il semble que ce sera le cas, pour les utilisateurs et 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.

Le mince bout du coin ici a été le courrier électronique Web. Des millions de personnes réalisent maintenant que vous devriez avoir accès à vos messages électroniques où que vous soyez. Et si vous pouvez voir votre courrier électronique, 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 quelque part sur un bureau lointain ?

L'idée même de "votre ordinateur" disparaît, remplacée par "vos données". Vous devriez pouvoir accéder à vos données depuis n'importe quel ordinateur. Ou plutôt, depuis n'importe quel client, et un client n'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 peuvent 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 avec vous peut être perdu ou volé. Laisser votre assistant numérique dans un taxi, c'est comme une panne 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. Donc vous n'avez rien à installer pour l'utiliser. Et quand il n'y a pas d'installation, vous n'avez pas à vous soucier de l'installation qui 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.

Comme il ne nécessite pas d'installation, il sera facile et courant d'essayer des logiciels basés sur le Web avant de les "acheter". Vous devriez vous attendre à pouvoir faire un essai gratuit de toute application Web, en allant simplement sur le site où elle est proposée. Chez Viaweb, tout notre site ressemblait à 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 de remplir un bref formulaire (plus bref sera 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, sans faire aucun travail, ou même sans le savoir.

Les mises à niveau ne seront pas les chocs importants qu'elles sont maintenant. Avec le temps, les applications gagneront en puissance de manière discrète. Cela demandera des efforts de la part des développeurs. Ils devront concevoir des logiciels pour qu'ils puissent être mis à jour sans perturber 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 bogues peuvent être corrigés dès qu'ils sont découverts. Donc les logiciels Web devraient avoir beaucoup moins de bogues que les logiciels de bureau. Chez Viaweb, je doute que nous ayons jamais eu dix bogues connus en même temps. C'est des ordres de grandeur mieux que les logiciels de bureau.

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

Lorsque vous utilisez une application Web, vos données seront plus en sécurité. Les pannes de disque ne seront plus chose du passé, mais les utilisateurs n'en entendront plus parler. Elles se produiront au sein de fermes de serveurs. Et les entreprises proposant des applications Web feront réellement des sauvegardes - non seulement parce qu'elles auront de vrais administrateurs système qui s'occuperont de ces choses, mais parce qu'un fournisseur de services applicatifs qui perdrait les données des gens serait dans de très, très gros problèmes. Quand les gens perdent leurs propres données à cause d'une panne de disque, ils ne peuvent pas être très en colère, car ils n'ont que eux-mêmes à blâmer. Quand une entreprise perd leurs données pour eux, ils seront beaucoup plus en colère.

Enfin, les logiciels 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 risque d'exécuter des virus, et pas de données locales à endommager. Et un programme qui attaquerait les serveurs eux-mêmes devrait les trouver très bien défendus. [2]

Pour les utilisateurs, les logiciels Web seront moins stressants. Je pense que si vous regardiez à l'intérieur de l'utilisateur Windows moyen, vous y trouveriez un désir énorme et pratiquement inexploité pour des logiciels correspondant à cette description. Libéré, cela pourrait être une force puissante.

Ville de Code

Pour les développeurs, la différence la plus frappante entre les logiciels Web et les logiciels de bureau est qu'une application 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. Et donc concevoir des logiciels 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 services de police et de pompiers, et de plans pour la croissance et différents types de catastrophes.

Chez Viaweb, le logiciel comprenait des applications assez importantes avec lesquelles les utilisateurs communiquaient directement, des programmes que ces programmes utilisaient, des programmes qui tournaient constamment en arrière-plan pour détecter les problèmes, des programmes qui essayaient de redémarrer les choses en cas de 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 ramasser les ressources ou déplacer ou restaurer des données, des programmes qui prétendaient être des utilisateurs (pour mesurer les performances ou exposer les bogues), des programmes pour diagnostiquer les problèmes de réseau, des programmes pour faire des sauvegardes, des interfaces vers des services extérieurs, un logiciel qui pilotait une impressionnante collection de cadrans affichant des statistiques de serveurs en temps réel (un succès auprès des visiteurs, mais indispensable pour nous aussi), des modifications (y compris des correctifs de bogues) de logiciels open source, et beaucoup 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 fermer, après que nous ayons été rachetés par Yahoo. Des 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'utilitaires inutiles que les gens pourraient utiliser pour s'introduire dans vos serveurs.

Cela ne s'arrêtait pas au logiciel. Nous avons passé beaucoup de temps à réfléchir aux configurations de serveurs. Nous avons construit les serveurs nous-mêmes, à partir de composants - en partie pour économiser de l'argent, et en partie pour obtenir exactement ce que nous voulions. Nous avons dû réfléchir à la question de savoir si notre fournisseur d'accès Internet amont avait des connexions suffisamment rapides vers tous les backbones. Nous avons daté les fournisseurs de RAID en série.

Mais le matériel n'est pas seulement quelque chose à se soucier. Quand vous le contrôlez, vous pouvez faire plus pour les utilisateurs. Avec une application de bureau, vous pouvez spécifier certains matériels minimaux, mais vous ne pouvez pas en ajouter davantage. Si vous administrez les serveurs, vous pouvez en une seule étape permettre à tous vos utilisateurs d'appeler des personnes, d'envoyer des fax, d'envoyer des commandes par téléphone ou de traiter des cartes de crédit, etc., simplement en installant le matériel approprié. Nous avons toujours cherché de nouvelles façons d'ajouter des fonctionnalités avec du matériel, non seulement parce que cela plaisait aux utilisateurs, mais aussi comme moyen de nous démarquer de la concurrence qui (soit parce qu'ils vendaient des logiciels de bureau, soit parce qu'ils revendaient des applications Web via des FAI) n'avaient pas de contrôle direct sur le matériel.

Parce que le logiciel d'une application Web sera un ensemble 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 la même langue que le système d'exploitation sous-jacent, c'est-à-dire 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 langues pour le "sérieux" développement de logiciels. Mais ce n'était qu'un artefact de la manière dont les logiciels de bureau devaient être livrés. Pour les logiciels 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 serveur, personne ne peut vous dire quelle langue 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 convient le mieux à chacune. Et quand 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++, et cela rendait leur logiciel visiblement inférieur car (entre autres choses), ils n'avaient aucun moyen de contourner le caractère sans é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 pouvions faire en sorte que l'éditeur Viaweb se comporte plus 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 l'entreprise de logiciels de bureau, faire une version est un énorme traumatisme, où toute l'entreprise sue et s'efforce de pousser un seul et unique morceau de code géant. Des comparaisons évidentes s'imposent, à la fois pour le processus et pour le produit final.

Avec les logiciels serveur, vous pouvez apporter des changements presque comme vous le feriez dans un programme que vous écririez pour vous-même. Vous publiez des logiciels sous forme de changements progressifs au lieu d'une explosion ponctuelle occasionnelle. Une entreprise typique de logiciels de bureau pourrait faire une ou deux versions par an. Chez Viaweb, nous en faisions souvent trois à cinq par jour.

Lorsque vous passez à ce nouveau modèle, vous réalisez à quel point le développement de logiciels est affecté par la façon dont ils sont publiés. Bon nombre des problèmes les plus désagréables que vous voyez dans l'entreprise de logiciels de bureau sont dus à la nature catastrophique des versions.

Lorsque vous ne publiez qu'une nouvelle version par an, vous avez tendance à traiter les bogues 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 bogues. Ensuite, une équipe de personnes chargées des tests entre en jeu et commence à les compter, et les programmeurs travaillent sur la liste, les corrigeant. Ils n'arrivent généralement pas à la fin 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 finissez par une sorte de correction statistique.

Avec les logiciels serveur, la plupart des changements sont petits et progressifs. Cela en soi est moins susceptible d'introduire des bogues. Cela signifie également que vous savez quoi tester le plus attentivement lorsque vous êtes sur le point de publier un logiciel : la dernière chose que vous avez changée. Vous finissez par avoir une emprise beaucoup plus ferme sur le 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 le lisez, vous le faites comme un pilote qui scrute 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 à propos des bogues. Vous savez que vous expédier quelque chose rempli de bogues, et vous avez même mis en place des mécanismes pour y remédier (par exemple, les versions correctrices). Alors pourquoi s'inquiéter de quelques-uns de plus ? Bientôt, vous publiez des fonctionnalités entières que vous savez être cassées. Apple a fait cela plus tôt cette année. Ils se sentaient sous pression pour publier leur nouveau système d'exploitation, dont la date de sortie avait déjà été repoussée quatre fois, mais une partie du logiciel (la prise en charge des CD et des 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 les logiciels Web, vous n'avez jamais à publier un logiciel avant qu'il ne fonctionne, et vous pouvez le publier dès qu'il fonctionne.

Le vétéran de l'industrie peut penser que c'est une belle idée de dire que vous n'avez jamais à publier un logiciel avant qu'il ne fonctionne, mais que se passe-t-il lorsque vous vous êtes engagé à livrer une nouvelle version de votre logiciel à une date donnée ? Avec les logiciels Web, vous ne feriez pas une telle promesse, car il n'y a pas de versions. Votre logiciel évolue progressivement et en continu. Certains changements peuvent être plus importants que d'autres, mais l'idée de versions ne s'adapte tout simplement pas naturellement aux logiciels Web.

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

Certains de nos concurrents offraient des logiciels de bureau et avaient même des numéros de version. Et pour ces versions, le simple fait d'en avoir semblait pour nous être la preuve de leur retard, et ils en tiraient toutes sortes de publicité. Nous ne voulions pas passer à côté, alors nous avons commencé à donner des numéros de version à nos propres logiciels. Quand nous voulions un peu de publicité, nous faisions une liste de toutes les fonctionnalités que nous avions ajoutées depuis la "version" précédente, nous collions un nouveau numéro de version sur le logiciel, et nous publiions un communiqué de presse annonçant que la nouvelle version était immédiatement disponible. Étonnamment, personne ne nous a jamais appelés sur ce sujet.

Quand nous avons été rachetés, nous avions fait cela trois fois, donc nous en étions à la version 4. La version 4.1 si je me souviens bien. Après que Viaweb soit devenu Yahoo Store, il n'y avait plus un besoin si désespéré de publicité, donc bien que le logiciel ait continué à évoluer, toute cette histoire de numéros de version a été discrètement abandonnée.

Bugs

L'autre avantage technique majeur des logiciels web est que vous pouvez reproduire la plupart des bugs. Vous avez les données des utilisateurs directement sur votre disque. Si quelqu'un casse votre logiciel, vous n'avez pas à essayer de deviner ce qui se passe, comme vous le feriez avec un logiciel de bureau : vous devriez pouvoir reproduire l'erreur pendant 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.

Les logiciels web sont utilisés 24h/24, donc tout ce que vous faites est immédiatement soumis à rude épreuve. 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 web, c'est en fait un bon plan, car les bugs sont moins nombreux et plus éphémères. Lorsque vous publiez des mises à jour progressivement, vous avez beaucoup moins de bugs dès le départ. Et quand vous pouvez reproduire les erreurs et publier des correctifs instantanément, vous pouvez trouver et corriger la plupart des bugs dès qu'ils apparaissent. Nous n'avons jamais eu assez de bugs à un moment donné pour nous embêter avec un système de suivi des bugs formel.

Vous devriez bien sûr tester les changements avant de les publier, afin qu'aucun bug majeur ne soit publié. Ceux qui passent malgré tout ne concerneront que des cas limites et n'affecteront que les quelques utilisateurs qui les rencontreront avant que quelqu'un n'appelle pour s'en plaindre. Tant que vous corrigez les bugs rapidement, l'effet net, pour l'utilisateur moyen, est beaucoup moins de bugs. Je doute que le moyen Viaweb ait jamais vu un bug.

Corriger des bugs récents est plus facile que de corriger des anciens. Il est généralement assez rapide de trouver un bug dans du 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, 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 publiez une fois par an) est beaucoup plus de travail. Et comme vous ne comprenez pas le code aussi bien, vous êtes plus susceptible de le corriger de manière bancale, ou même d'introduire d'autres bugs. [4]

Quand vous attrapez les bugs tôt, vous avez aussi moins de bugs composés. Les bugs composés sont deux bugs séparés qui interagissent : vous trébuchez dans les escaliers, et quand vous tendez la main pour la rampe, elle se détache. Dans les logiciels, ce type de bug est le plus difficile à trouver, et a aussi tendance à avoir les pires conséquences. [5] L'approche traditionnelle "tout casser et ensuite filtrer les bugs" produit intrinsèquement beaucoup de bugs composés. Et les logiciels publiés par petites modifications successives ont intrinsèquement tendance à en avoir moins. Les sols sont constamment débarrassés de tous les objets lâches qui pourraient plus tard se coincer dans quelque chose.

Il est utile d'utiliser une technique appelée programmation fonctionnelle. La programmation fonctionnelle signifie éviter les effets de bord. C'est quelque chose qu'on voit plus souvent 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 parties substantielles 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 constamment de petites modifications et les testez. 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 monde des logiciels de bureau auront du mal à le croire, mais chez Viaweb, les bugs étaient presque devenus un jeu. Comme la plupart des bugs publiés concernaient des cas limites, les utilisateurs qui les rencontraient étaient probablement des utilisateurs avancés, repoussant les limites. Les utilisateurs avancés sont plus indulgents envers les bugs, surtout puisque vous les avez probablement introduits en ajoutant une fonctionnalité qu'ils demandaient. En fait, comme les bugs étaient rares et qu'il fallait faire des choses sophistiquées pour en voir, les utilisateurs avancés étaient souvent fiers d'en avoir attrapé un. Ils appelaient le support dans un esprit plus de triomphe que de colère, comme s'ils nous avaient marqué des points.

Support

Quand 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 faire se sentir mieux les clients. Ils appellent soit pour un bug connu, soit ils font juste quelque chose de mal et vous devez deviner ce que c'est. 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 plaie que vous voulez isoler de vos développeurs autant que possible.

Ce n'était pas comme ça que ça se passait chez Viaweb. Chez Viaweb, le support était gratuit, car nous voulions avoir des nouvelles des clients. Si quelqu'un avait un problème, nous voulions en être informés immédiatement afin de pouvoir reproduire l'erreur et publier un correctif.

Donc chez Viaweb, les développeurs étaient toujours en étroite communication avec le support. Les gens du support client étaient à une trentaine de mètres des programmeurs, et savaient qu'ils pouvaient toujours interrompre n'importe quoi pour signaler un vrai bug. Nous aurions quitté une réunion du conseil d'administration pour corriger un bug grave.

Notre approche du support a rendu tout le monde plus heureux. Les clients étaient ravis. Imaginez un peu ce que ça fait d'appeler une ligne d'assistance et d'être traité comme quelqu'un qui apporte une nouvelle importante. Les gens du support client aimaient ça parce que ça leur permettait d'aider les utilisateurs, au lieu de leur lire des scripts. Et les programmeurs aimaient ça parce qu'ils pouvaient reproduire les bugs au lieu de n'entendre que des rapports vagues et de deuxième main à leur sujet.

Notre politique de correction des bugs en temps réel a changé la relation entre le personnel du service clientèle et les hackers. Dans la plupart des entreprises de logiciels, le personnel du service clientèle est sous-payé et sert de bouclier humain, tandis que les hackers sont de petites copies du Père tout-puissant, créateurs du monde. Quelle que soit la procédure de signalement des bugs, elle est susceptible d'être unidirectionnelle : le personnel du service clientèle qui entend parler de bugs remplit un formulaire qui finit par être transmis (éventuellement via le service qualité) aux programmeurs, qui le mettent sur leur liste de choses à faire. C'était très différent chez Viaweb.

Dans la minute qui suivait la réception d'un bug signalé par un client, le personnel du service clientèle pouvait se tenir aux côtés d'un programmeur en l'entendant dire "Merde, tu as raison, c'est un bug." Cela ravissait le personnel du service clientèle d'entendre ce "tu as raison" de la part des hackers. Ils nous apportaient les bugs avec le même air impatient qu'un chat vous apportant une souris qu'il vient de tuer. Cela les a également rendus plus prudents dans l'évaluation de la gravité d'un bug, car maintenant leur honneur était en jeu.

Après que nous ayons été rachetés par Yahoo, le personnel du service clientèle a été éloigné des programmeurs. Ce n'est qu'à ce moment-là que nous nous sommes rendu compte qu'ils étaient en fait le service qualité et, dans une certaine mesure, le marketing également. En plus de détecter les bugs, ils étaient les dépositaires des connaissances sur des choses plus vagues, ressemblant à des bugs, comme les fonctionnalités qui déroutaient les utilisateurs. [6] Ils étaient aussi une sorte de groupe témoin proxy ; nous pouvions leur demander laquelle de deux nouvelles fonctionnalités les utilisateurs voulaient le plus, et ils avaient toujours raison.

Moral

Pouvoir publier un logiciel immédiatement est un grand facteur de motivation. Souvent, en me rendant au travail, je pensais à un changement que je voulais apporter au logiciel, et je le faisais ce jour-là. Cela fonctionnait aussi pour les fonctionnalités plus importantes. Même si quelque chose devait prendre deux semaines à écrire (peu de projets prenaient plus longtemps), je savais que je pouvais en voir l'effet dans le logiciel dès qu'il serait terminé.

Si j'avais dû attendre un an pour la prochaine version, j'aurais remisé la plupart de ces idées, au moins pendant un certain temps. Mais le truc avec les idées, c'est qu'elles en engendrent d'autres. Avez-vous déjà remarqué que lorsque vous vous asseyez pour écrire quelque chose, la moitié des idées qui finissent par s'y trouver sont celles auxquelles vous avez pensé en écrivant ? La même chose se produit avec les logiciels. Travailler pour mettre en œuvre une idée vous en donne d'autres. Donc, remettre une idée à plus tard vous fait perdre non seulement ce retard dans sa mise en œuvre, mais aussi toutes les idées que sa mise en œuvre aurait engendrées. En fait, remettre une idée à plus tard inhibe probablement même de nouvelles idées : lorsque vous commencez à penser à une nouvelle fonctionnalité, vous apercevez l'étagère et vous vous dites "mais j'ai déjà beaucoup de nouvelles choses que je veux faire pour la prochaine version".

Ce que font les grandes entreprises à la place de mettre en œuvre des fonctionnalités, c'est de les planifier. Chez Viaweb, nous avons parfois eu des problèmes à ce sujet. Les investisseurs et les analystes nous demandaient ce que nous avions prévu pour l'avenir. La réponse honnête aurait été que nous n'avions pas de plans. Nous avions des idées générales sur les choses que nous voulions améliorer, mais si nous les avions su, nous l'aurions déjà fait. Que ferions-nous dans les six prochains mois ? Tout ce qui semblait être la plus grosse victoire. Je ne sais pas si j'ai osé donner cette réponse, mais c'était la vérité. Les plans ne sont qu'un autre mot pour dire des idées sur l'étagère. Quand 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 bien défini. Mais quand vous possédiez quelque chose, vous le possédiez vraiment : personne d'autre que le propriétaire d'un morceau de logiciel n'avait besoin d'approuver (ou même de savoir) une publication. Il n'y avait pas d'autre protection contre les dommages que la peur de paraître idiot aux yeux de ses pairs, et c'était plus que suffisant. J'ai peut-être donné l'impression que nous avancions sans réfléchir en écrivant du code. Nous allions vite, mais nous réfléchissions très attentivement avant de publier un logiciel sur ces serveurs. Et prêter 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 livres à 140 miles à l'heure sur le pont d'un porte-avions qui tangue, la nuit, plus sûrement que l'adolescent moyen ne peut couper une bagel.

Cette façon de développer des logiciels est une épée à double tranchant, bien sûr. Elle fonctionne beaucoup mieux pour une petite équipe de bons programmeurs de confiance que pour une grande entreprise de médiocres, où les mauvaises idées sont arrêtées par des comités plutôt que par les personnes qui les ont eues.

Brooks à l'envers

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

Viaweb a été écrit par seulement trois personnes. [7] J'ai toujours été sous pression pour embaucher davantage, car nous voulions être racheté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é davantage, mais nous avons créé de nouveaux projets pour eux.)

Quand vous pouvez écrire des logiciels 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 gens à un projet a tendance à le ralentir. Le nombre de connexions possibles entre les développeurs augmente de manière exponentielle avec la taille du groupe. Plus le groupe est grand, plus ils passeront de temps en réunions à négocier la façon dont leurs logiciels fonctionneront ensemble, et plus ils auront de bugs dus à des interactions imprévues. Heureusement, ce processus fonctionne aussi à l'envers : plus les groupes sont petits, plus le développement de logiciels devient exponentiellement plus efficace. Je ne me souviens pas que les programmeurs de Viaweb aient jamais eu de réunion officielle. Nous n'avions jamais plus à dire à un moment donné que ce que nous pouvions dire en allant déjeuner.

Si le revers de la médaille 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 comportait tellement de composants et changeait si fréquemment qu'il n'y avait pas de frontière nette 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 un couple de mois") tout serait suffisamment stable pour que nous puissions embaucher quelqu'un dont le travail serait simplement de s'occuper des serveurs, cela ne s'est jamais produit.

Je ne pense pas que cela puisse être autrement, tant que vous continuez à développer activement le produit. Les logiciels Web ne seront jamais quelque chose que vous écrivez, validez et rentrez chez vous. C'est une chose vivante, qui tourne sur vos serveurs en ce moment même. Un bogue grave pourrait ne pas seulement faire planter le processus d'un utilisateur ; il pourrait les faire tous planter. Si un bogue 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 toutes les minutes (après la première année ou à peu près), mais vous voulez définitivement garder un œil sur les choses que vous avez récemment modifiées. Vous ne publiez pas de code tard le soir et ne rentrez pas chez vous.

Observation des utilisateurs

Avec un logiciel hébergé sur serveur, 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 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 les attendaient.

Un logiciel doit faire ce que les utilisateurs pensent qu'il fera. Mais vous ne pouvez pas avoir la moindre idée de ce à quoi les utilisateurs penseront, croyez-moi, jusqu'à ce que vous les observiez. Et les logiciels hébergés sur serveur vous donnent des informations sans précédent sur leur comportement. Vous n'êtes pas limités à de petits groupes de discussion artificiels. Vous pouvez voir chaque clic fait par chaque utilisateur. Vous devez réfléchir 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.

Quand 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 hébergés sur serveur, vous pouvez observer de vrais utilisateurs. Pour décider de ce qu'il faut optimiser, il suffit de vous connecter à un serveur et de voir ce qui consomme tout le processeur. Et vous savez quand arrêter d'optimiser : nous avons finalement réussi à amener l'éditeur Viaweb au point où il était limité par la mémoire plutôt que par le processeur, et comme il n'y avait rien que nous puissions faire pour diminuer la taille des données des utilisateurs (eh bien, rien de facile), nous savions que nous pouvions aussi bien nous arrêter là.

L'efficacité compte pour les logiciels hébergés sur serveur, car vous payez pour le matériel. Le nombre d'utilisateurs que vous pouvez prendre en charge par serveur est le diviseur de votre coût en capital, donc si vous pouvez rendre votre logiciel très efficace, vous pouvez sous-vendre vos concurrents tout en réalisant encore des bénéfices. Chez Viaweb, nous avons fait baisser le coût en capital par utilisateur à environ 5 $. Ce serait moins maintenant, probablement moins que le coût d'envoi de la première facture mensuelle. Le matériel est gratuit maintenant, si votre logiciel est raisonnablement efficace.

L'observation des utilisateurs peut vous guider dans la conception aussi bien 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 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 en travers de la page, par exemple, mais après qu'un certain nombre d'utilisateurs aient utilisé RTML pour placer les boutons sur le côté gauche, nous avons fait de cela une option (en fait la par défaut) dans les styles de page prédéfinis.

Enfin, en observant les utilisateurs, vous pouvez souvent dire quand ils rencontrent des problèmes. Et puisque le client a toujours raison, c'est un signe de quelque chose que vous devez corriger. Chez Viaweb, la clé pour attirer de nouveaux utilisateurs était l'essai en ligne. Ce n'était pas seulement une série de diapositives conçues 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 vraie boutique en ligne.

L'essai était le moyen par lequel nous obtenions presque tous nos nouveaux utilisateurs. Je pense que ce sera la même chose pour la plupart des applications Web. Si les utilisateurs peuvent passer l'essai avec succès, ils aimeront le produit. S'ils se sentent perdus ou ennuyés, ils n'aimeront pas. Donc tout ce que nous pouvions faire pour faire passer plus de gens par l'essai augmenterait notre taux de croissance.

J'ai étudié les pistes de clics des gens qui passaient l'essai et j'ai constaté qu'à une certaine étape, ils se sentaient confus et cliquaient sur le bouton Retour du navigateur. (Si vous essayez d'écrire des applications Web, vous constaterez que le bouton Retour devient l'un de vos problèmes philosophiques les plus intéressants.) J'ai donc ajouté un message à ce stade, indiquant aux utilisateurs qu'ils étaient presque arrivés et leur rappelant de ne pas cliquer sur le bouton Retour. Un autre excellent aspect des logiciels 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%, rien que 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 activité d'abonnement. Au début, cela m'a semblé 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 propre 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 les applications hébergées sur le Web.

L'hébergement d'applications est un domaine où les entreprises joueront un rôle qui ne sera probablement pas rempli par les logiciels gratuits. L'hébergement d'applications est très stressant et a de véritables coûts. Personne ne voudra le faire gratuitement.

Pour les entreprises, les applications Web sont une source de revenus idéale. Au lieu de repartir à zéro chaque trimestre, vous disposez d'un flux de revenus récurrents. Comme votre logiciel évolue progressivement, vous n'avez pas à craindre qu'un nouveau modèle soit un échec ; il n'y a pas vraiment besoin de nouveau modèle, et si vous faites quelque chose au logiciel que les utilisateurs détestent, vous le saurez tout de suite. Vous n'avez pas de problème de factures irrécouvrables ; si quelqu'un ne veut pas vous payer, vous pouvez simplement couper le service. Et il n'y a aucun risque de piratage.

Cet "avantage" peut s'avérer être un problème. Une certaine forme 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 en tirez un bénéfice, car il est un utilisateur de plus qui contribue à faire de votre logiciel un standard - ou qui pourrait acheter une copie plus tard, quand il aura terminé ses études.

Quand elles le peuvent, les entreprises aiment pratiquer ce qu'on appelle la discrimination par les prix, c'est-à-dire facturer à chaque client le maximum qu'il peut se permettre. [8] Le logiciel se prête particulièrement bien à la discrimination par les prix, car le coût marginal est proche de zéro. C'est pourquoi certains logiciels coûtent plus cher sur des stations Sun que sur des machines Intel : une entreprise qui utilise des Sun n'est pas intéressée par les économies et peut se voir facturer plus. Le piratage est en fait 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 serveur, elles vont devoir trouver une autre solution.

Les logiciels 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 réfléchissais. 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 le fait de le vouloir. Et vice versa : vous vendrez plus d'un produit s'il est facile à acheter. J'achète plus de livres parce qu'Amazon existe. Les logiciels Web sont à peu près la chose la plus facile à acheter au monde, surtout si vous venez de faire une démonstration en ligne. Les utilisateurs ne devraient pas avoir à faire beaucoup plus qu'entrer un numéro de carte de crédit. (Faites-les faire plus à vos risques et périls.)

Parfois, les logiciels Web sont proposés par l'intermédiaire de fournisseurs d'accès Internet 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és une balle dans le pied de cette façon - généralement, je pense, parce qu'ils ont été submergés par des costumes qui étaient enthousiasmés par ce canal potentiel énorme, et ne se sont pas rendu compte que cela ruinerait le produit qu'ils espéraient vendre à travers lui. Vendre des logiciels Web par l'intermédiaire de fournisseurs d'accès Internet, c'est comme vendre du sushi dans 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 faibles des nouvelles technologies.

Les applications Web seront souvent la meilleure chose pour les grandes entreprises aussi (bien qu'elles mettront du temps à s'en rendre compte). Le meilleur intranet, c'est Internet. Si une entreprise utilise de véritables applications Web, le logiciel fonctionnera mieux, les serveurs seront mieux administrés, et les employés auront accès au système depuis 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 mauvaises personnes. Certains gros commerçants hésitaient à utiliser Viaweb parce qu'ils pensaient que les informations sur les cartes de crédit des clients seraient plus en sécurité sur leurs propres serveurs. Ce n'était pas facile à dire de manière diplomatique, mais en fait les données étaient presque certainement plus en sécurité entre nos mains que les leurs. Qui peut embaucher de meilleures personnes pour gérer la sécurité, une start-up technologique dont tout le métier est d'exploiter des serveurs, ou un détaillant de vêtements ? Non seulement nous avions de meilleures personnes qui se préoccupaient de la sécurité, mais nous nous en préoccupions davantage. Si quelqu'un s'introduisait dans les serveurs du détaillant de vêtements, cela n'affecterait qu'un seul commerçant, 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 à la une de CNet, et pourrait nous faire couler.

Si vous voulez garder votre argent en sécurité, le gardez-vous sous votre matelas à la maison, ou le placez-vous dans une banque ? Cet argument s'applique à tous les aspects de l'administration des serveurs : non seulement la sécurité, mais aussi le temps de fonctionnement, la bande passante, la gestion de la charge, les sauvegardes, etc. Notre existence dépendait du bon fonctionnement de ces éléments. Les problèmes de serveur étaient le gros tabou 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 une certaine mesure l'informatique. Aussi radicale que cela puisse paraître, je pense que c'est généralement une bonne idée. Les entreprises sont susceptibles d'obtenir un meilleur service de cette manière que si elles s'appuyaient sur des administrateurs système internes. Les administrateurs système peuvent devenir irritables et peu réactifs car ils ne sont pas directement exposés à la pression concurrentielle : un commercial doit faire face aux clients, et un développeur doit faire face aux logiciels de la concurrence, mais un administrateur système, comme un vieux célibataire, a peu de forces extérieures pour le tenir en ligne. [10] Chez Viaweb, nous avions amplement de forces extérieures pour nous tenir en ligne. Les gens qui nous appelaient étaient des clients, pas seulement des collègues. Si un serveur se bloquait, nous réagissions ; rien que d'y penser me donne encore un coup d'adrénaline, des années plus tard.

Donc, les applications Web seront généralement la bonne réponse pour les grandes entreprises aussi. Elles seront les dernières à s'en rendre compte, cependant, tout comme elles l'ont été avec les ordinateurs de bureau. Et en partie pour la même raison : cela en vaudra la peine 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 d'acheter des solutions coûteuses, même lorsque des solutions bon marché sont meilleures, car les gens offrant des solutions chères peuvent dépenser davantage pour les vendre. Chez Viaweb, nous étions toujours confrontés à cela. Nous avons perdu plusieurs marchands haut de gamme auprès 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. En règle générale, ils n'étaient 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 marchands ont obtenu, 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 à la 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 d'articles coûteux à leur intention. (Si le ministère de la Défense paie mille dollars pour des sièges de toilette, c'est en partie parce qu'il en coûte beaucoup pour vendre des sièges de toilette à mille dollars.) Et c'est une des raisons pour lesquelles les logiciels intranet continueront à 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 à ce sujet, donc le mieux est de viser d'abord les petits clients. Le reste viendra avec le temps.

Fils de serveur

L'exécution de logiciels sur le serveur n'est pas une nouveauté. En fait, c'est l'ancien modèle : les applications de type mainframe sont toutes basées sur le serveur. Si les logiciels basés sur le 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 passionnés, 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 quand 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'est parce qu'ils avaient de meilleurs logiciels. Et je pense que la raison pour laquelle les logiciels pour micro-ordinateurs étaient meilleurs, c'est 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 incertaines dans leurs premiers stades. De nombreuses startups commencent presque par accident - comme un couple de gars, soit avec un emploi à temps partiel, soit à l'école, écrivant un prototype de quelque chose qui pourrait, s'il semble prometteur, se transformer en une entreprise. À ce stade larvaire, tout obstacle important arrêtera net la startup. Écrire des logiciels pour mainframe nécessitait 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. Démarrer une startup pour écrire des logiciels pour mainframe serait une entreprise beaucoup plus sérieuse que de simplement bricoler quelque chose sur votre Apple II le soir. Et donc, vous n'avez pas eu beaucoup de startups écrivant des applications pour mainframe.

L'arrivée des ordinateurs de bureau a inspiré de nombreux nouveaux logiciels, car l'écriture d'applications pour eux semblait un objectif atteignable pour les startups à l'état larvaire. Le développement était bon marché et les clients seraient des particuliers que vous pourriez atteindre par le biais de magasins d'informatique ou même par correspondance.

L'application qui a poussé les ordinateurs de bureau sur le marché grand public était VisiCalc, la première feuille de calcul. Elle a été écrite par deux gars travaillant dans un grenier, et pourtant faisait des choses que les logiciels pour mainframe ne pouvaient pas faire. [11] VisiCalc était une telle avancée, à l'é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 le serveur seront bons cette fois-ci, car les startups les écriront. Les ordinateurs sont tellement bon marché maintenant que vous pouvez vous lancer, comme nous l'avons fait, en utilisant un ordinateur de bureau comme serveur. Les processeurs bon marché ont mangé le marché des stations de travail (on entend à peine le mot maintenant) et sont en passe de traverser le marché des serveurs ; les serveurs de Yahoo, qui gèrent 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 ordinateur de bureau. Et une fois que vous avez écrit le logiciel, tout ce dont vous avez besoin pour le vendre est un site Web. Presque tous nos utilisateurs sont venus directement sur notre site par le bouche-à-oreille et les références dans la presse. [12]

Viaweb était une startup larvaire typique. Nous avions peur de démarrer une entreprise et, pendant les premiers mois, nous nous réconfortions en considérant le tout comme une expérience que nous pourrions arrêter à tout moment. Heureusement, il y avait peu d'obstacles en dehors des obstacles techniques. Pendant que nous écrivions le logiciel, notre serveur Web était le même ordinateur de bureau que nous utilisions pour le développement, connecté au monde extérieur par une ligne de composition. 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, car l'écriture de logiciels de bureau est devenue beaucoup moins amusante. 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 système d'exploitation bogué. Et si vous réussissez à écrire quelque chose qui prend de l'ampleur, 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 voudront construire, elle doit en faire quelque chose que les hackers eux-mêmes voudront utiliser. Cela signifie que cela doit être peu coûteux et bien conçu. Le Mac était populaire auprès des hackers à ses débuts, et beaucoup d'entre eux ont écrit des logiciels pour lui. [13] On voit moins cela avec Windows, car les hackers ne l'utilisent pas. Le type de personnes qui sont douées pour écrire des logiciels ont tendance à utiliser Linux ou FreeBSD maintenant.

Je ne pense pas que nous aurions créé une startup pour écrire des logiciels de bureau, car les logiciels de bureau doivent fonctionner sous 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 dur à 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 que l'était IBM. Après tout, Microsoft a délibérément construit son entreprise dans l'angle mort d'IBM.

J'ai mentionné plus tôt que ma mère n'a pas vraiment besoin d'un ordinateur de bureau. La plupart des utilisateurs probablement pas non plus. 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 ? Seront-ils en mesure d'utiliser leur contrôle du bureau pour empêcher, ou limiter, cette nouvelle génération de logiciels ?

Mon pari est que Microsoft développera une sorte d'hybride serveur/bureau, où le système d'exploitation fonctionne en collaboration 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 le serveur.

Je pense que Microsoft aura du mal à garder le génie dans la bouteille. Il y aura trop de types différents de clients 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 à partir de 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 avec le monde des applications de bureau.

Ce n'est pas tant qu'un concurrent les fera trébucher, mais plutôt qu'ils trébucheront sur eux-mêmes. Avec l'essor des logiciels Web, ils seront confrontés non seulement à des problèmes techniques, mais aussi à leurs propres illusions. Ce qu'ils doivent faire, c'est cannibaliser leur activité existante, et je ne peux pas les voir faire face à cela. La même détermination qui les a menés jusque-là travaillera maintenant contre eux. IBM se trouvait 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 sur le marché des micro-ordinateurs parce qu'ils étaient ambivalents sur la menace pour leur vache à lait, l'informatique de type mainframe. Microsoft sera de même entravé par le désir de sauver le bureau. Une vache à lait peut être un sacré gros singe sur le dos.

Je ne dis pas que personne ne dominera les applications basées sur le 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 dans les premiers jours des micro-ordinateurs. C'était une bonne époque pour les startups. De nombreuses petites entreprises ont prospéré, et l'ont fait en créant des choses cool.

Des 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. S'ils gagnent, ils gagnent gros.

Dans une startup écrivant des applications 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 comme trois gars assis dans le salon d'un appartement, et un serveur colocalisé chez un FAI. C'est ce que nous avons fait.

Au fil du temps, les équipes sont devenues de plus en plus petites, rapides et informelles. En 1960, le développement de logiciels signifiait une salle remplie d'hommes avec des lunettes à monture d'écaille et des cravates noires étroites, écrivant avec application 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 se révèlent ne 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 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. Le côté alarmant des logiciels 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 : enfin, nous l'avons expédié et nous sommes tous rentrés chez nous pour dormir pendant une semaine. Les logiciels Web ne sont jamais expédiés. Vous pouvez travailler 16 heures par jour aussi longtemps que vous le voulez. Et parce que vous le pouvez, et que vos concurrents le peuvent aussi, vous avez tendance à être forcés de le faire. Vous pouvez, donc vous devez. C'est la loi de Parkinson à l'envers.

Le pire n'est pas les heures, mais la responsabilité. Les programmeurs et les administrateurs système ont traditionnellement leurs propres soucis séparés. 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 moment donné, ils peuvent rentrer chez eux et l'oublier. Les administrateurs système ne laissent jamais vraiment le travail derrière eux, mais quand ils se font appeler à 4h00 du matin, ils n'ont généralement pas grand-chose de compliqué à faire. Avec les applications 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 simplement du logiciel. Nous avons travaillé les longues heures habituelles d'une startup naissante. Dans une entreprise de logiciels de bureau, cette partie aurait été celle 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) a été de pouvoir transférer la responsabilité ultime de l'ensemble sur les épaules d'une grande entreprise.

Les logiciels de bureau obligent les utilisateurs à devenir des administrateurs système. Les logiciels Web obligent les programmeurs à le devenir. 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 travailler plus que vos concurrents. Aucune startup ne demande plus.

Juste assez bon

Une chose qui pourrait vous dissuader d'écrire des applications Web est la médiocrité des pages Web en tant qu'interface utilisateur. C'est un problème, je l'admets. Il y avait quelques trucs qu'on aurait vraiment aimé ajouter à HTML et HTTP. Mais ce qui compte, c'est que les pages Web sont juste assez bonnes.

Il y a un parallèle ici avec les premiers microordinateurs. Les processeurs de ces machines n'étaient pas vraiment destinés à être les unités centrales des ordinateurs. Ils étaient conçus pour être utilisés dans des choses comme les feux de circulation. Mais des gars comme Ed Roberts, qui a conçu l'Altair, se sont rendu compte qu'ils étaient tout juste assez bons. Vous pouviez combiner l'un de ces puces avec un peu de mémoire (256 octets dans le premier Altair), et des commutateurs de panneau avant, et vous auriez un ordinateur fonctionnel. Le fait de pouvoir avoir son propre ordinateur était tellement 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 tout juste assez bonnes. Et pour un nombre important d'utilisateurs, un logiciel que vous pouvez utiliser à partir de n'importe quel navigateur sera suffisamment avantageux en soi pour compenser toute maladresse dans l'interface utilisateur. Peut-être que vous ne pouvez pas écrire la meilleure feuille de calcul en utilisant HTML, mais vous pouvez écrire une feuille de calcul que plusieurs personnes peuvent utiliser simultanément à partir d'endroits différents sans logiciel client spécial, ou qui peut incorporer des flux de données en direct, ou qui peut vous appeler lorsque certaines conditions sont déclenchées. Plus important encore, vous pouvez écrire de nouveaux types d'applications qui n'ont même pas encore de nom. VisiCalc n'était pas seulement une version microordinateur d'une application de gros système, après tout - c'était un nouveau type d'application.

Bien sûr, les applications basées sur le serveur n'ont pas besoin d'être Web. Vous pourriez avoir un autre type de client. Mais je suis assez sûr que c'est une mauvaise idée. Il serait très pratique si vous pouviez supposer que tout le monde installerait votre client - tellement pratique que vous pourriez facilement vous convaincre qu'ils le feraient tous - mais s'ils ne le font pas, vous êtes dans la panade. Parce que les logiciels Web-based 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 se multiplieront. Les utilisateurs vous aimeront parce que votre logiciel fonctionne simplement, et votre vie sera plus facile parce que vous n'aurez pas à le retoucher pour chaque nouveau client. [16]

J'ai l'impression d'avoir suivi l'évolution du Web de aussi près que quiconque, et je ne peux pas prédire ce qui va se passer avec les clients. La convergence arrive probablement, 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 devienne le .NET de Microsoft, il impliquera probablement de connecter le bureau aux serveurs. À moins qu'AOL ne riposte, ils seront soit mis de côté, soit transformés en un tuyau entre le logiciel client et serveur de Microsoft. Si Microsoft et AOL se lancent dans une 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-based seront les seules à fonctionner 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 misez sur les applications Web-based. Personne ne peut les casser sans casser la navigation. Le Web peut ne pas être le seul moyen de livrer des logiciels, mais c'est un qui fonctionne maintenant et continuera à fonctionner pendant longtemps. Les applications Web-based sont peu coûteuses à développer et faciles à livrer même pour la plus petite startup. C'est un travail important, 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 agriculteur que de nombreuses clôtures électrifiées n'ont pas de courant qui les traverse. Les vaches semblent apprendre à s'en éloigner, 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 à créer 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 : créer quelque chose que les utilisateurs adorent et gagner plus que vous ne dépensez. Si vous obtenez ces deux éléments, vous serez en avance sur la plupart des startups. Vous pouvez découvrir le reste en chemin.

Vous ne gagnerez peut-être pas immédiatement plus que vous ne dépensez, mais tant que l'écart se comble assez rapidement, vous serez ok. Si vous démarrez avec un sous-financement, 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 peu coûteux de lancer une application Web-based. Nous avons lancé avec moins de 10 000 $, et ce serait encore moins cher aujourd'hui. Nous avons dû dépenser des milliers de dollars pour un serveur et des milliers de plus pour obtenir le SSL. (La seule entreprise vendant des logiciels SSL à l'époque était Netscape.) Maintenant, vous pouvez louer un serveur beaucoup plus puissant, avec le SSL inclus, pour moins que ce que nous avons payé pour la bande passante seule. Vous pourriez lancer une application Web-based maintenant pour moins que le coût d'un fauteuil de bureau haut de gamme.

Pour ce qui est de créer quelque chose que les utilisateurs adorent, voici quelques conseils généraux. Commencez par faire quelque chose de propre et de 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 les 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, c'est facile, mais la façon d'y arriver est d'obtenir les paramètres par défaut corrects, pas de limiter les choix des utilisateurs. Ne vous complaisez pas si les logiciels de vos concurrents sont médiocres ; la norme à laquelle comparer votre logiciel est ce qu'il pourrait être, pas ce que vos concurrents actuels ont réussi à faire. Utilisez votre logiciel vous-même, tout le temps. Viaweb était censé être un constructeur de boutiques en ligne, mais nous l'avons utilisé pour créer notre propre site aussi. N'écoutez pas les gens du marketing, les designers ou les gestionnaires de produits juste à cause de leur titre. S'ils ont de bonnes idées, utilisez-les, mais c'est à vous de décider ; les logiciels doivent être conçus par des hackers qui comprennent la conception, pas par des concepteurs qui connaissent un peu les logiciels. Si vous ne pouvez pas concevoir des logiciels aussi bien que les mettre en œuvre, ne créez pas de startup.

Parlons maintenant de la concurrence. Ce dont vous avez peur, ce ne sont pas présumément des groupes de pirates informatiques comme vous, mais de véritables 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 n'avez peur d'elles, et elles ont raison. Il est beaucoup plus facile pour un couple de pirates informatiques de trouver comment louer des bureaux ou embaucher du personnel de vente que pour une entreprise de n'importe quelle taille d'obtenir un logiciel écrit. J'ai été des deux côtés, et je le sais.

Quand Viaweb a été acheté 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 pirates informatiques, et la haute direction étaient de véritables durs à cuire. Pour une grande entreprise, ils étaient exceptionnels. Mais ils n'étaient toujours qu'environ un dixième aussi productifs qu'une petite startup. Aucune grande entreprise ne peut faire beaucoup mieux que cela. Ce qui fait peur 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 que ce que Microsoft ne peut pas, comme ils peuvent faire ce que vous ne pouvez pas. Et personne ne peut vous arrêter. Vous n'avez pas à demander la permission à qui que ce soit pour développer des applications Web. Vous n'avez pas à faire de deals de licence, ou à obtenir de l'espace sur les étagères des magasins, ou à ramper pour que votre application soit incluse avec le système d'exploitation. Vous pouvez livrer des logiciels directement dans le navigateur, et personne ne peut s'interposer entre vous et les utilisateurs potentiels sans les empêcher de naviguer sur le Web.

Vous ne me croirez peut-être pas, mais je vous le promets, Microsoft a peur de vous. Les cadres moyens complaisants peuvent ne pas l'être, mais Bill l'est, parce qu'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 que beaucoup de l'argent est 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 que vous avez besoin de deux types d'entreprises différents pour construire des appareils électroniques grand public et pour exploiter un service en ligne, et en partie parce que les utilisateurs détestent l'idée. Donner le rasoir gratuitement 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 téléphones portables se contentent de vendre du matériel sans essayer de capturer les revenus des services. C'est probablement le modèle à suivre pour les clients Internet aussi. Si quelqu'un vendait juste une petite boîte bien jolie 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 se planter que de toute décision de conception, mais la nature des logiciels basés sur le serveur fera que les développeurs prêteront plus attention à ne pas se planter. Compromettre un serveur pourrait causer des dommages si importants que les fournisseurs de services applicatifs (qui veulent rester en activité) seront probablement prudents en matière de sécurité.

[3] En 1995, quand nous avons démarré Viaweb, les applets Java étaient censées être la technologie que tout le monde allait utiliser pour développer des applications basées sur le serveur. Les applets nous semblaient être une idée dépassée. Télécharger des programmes pour les 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 piège. Peu ont dû en réchapper, sans quoi Microsoft n'aurait pas pu se permettre de supprimer Java dans la dernière version d'Explorer.

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

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

[6] Au sein de Viaweb, nous avons eu une fois un concours pour décrire le pire aspect de notre logiciel. Deux personnes du service clientèle ont remporté le premier prix ex æquo avec des entrées dont je frissonne encore en me les rappelant. 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 les commandes, consulter les statistiques et configurer les 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 des 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 de la loi Robinson-Patman de 1936. Cette loi ne semble pas être appliquée avec vigueur.

[9] Dans No Logo, Naomi Klein dit que les marques de vêtements préférées des "jeunes urbains" ne font pas trop d'efforts pour empêcher le vol à l'étalage car, dans leur marché cible, les voleurs sont aussi les leaders de la mode.

[10] Les entreprises se demandent souvent ce qu'il faut sous-traiter et ce qu'il ne faut pas. Une réponse possible : sous-traitez tout travail qui n'est pas directement exposé à la pression concurrentielle, car le sous-traiter 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 (surtout la nuit) pour en faire une version plus puissante écrite en langage machine 6502. Dan était à l'école de commerce de Harvard à l'époque et Bob avait nominalement un emploi de jour à écrire des logiciels. "Il n'y avait pas de grand risque à faire une entreprise," a écrit Bob, "Si elle échouait, elle échouait. Pas de gros problème."

[12] Ce n'est pas tout à fait aussi facile que je le laisse entendre. Il a fallu un temps terriblement long pour que le bouche-à-oreille commence à fonctionner, et nous n'avons pas commencé à obtenir beaucoup de couverture médiatique avant d'avoir embauché une agence de relations publiques (sans aucun doute la meilleure du secteur) pour 16 000 dollars par mois. Cependant, il était vrai que le seul canal important é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'activité logicielle 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 les costumes aient pris le relais pendant une période critique.

[14] Une chose qui aiderait les applications Web et empêcherait 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 entretenu serait une excellente chose en soi et encouragerait probablement également les entreprises à construire de petits appareils Web.

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

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

[15] Trevor Blackwell, qui en sait probablement plus sur le sujet que quiconque grâce à son expérience personnelle, écrit :

"J'irais plus loin en disant que parce que les logiciels serveur sont si difficiles pour les programmeurs, cela entraîne un changement économique fondamental loin des grandes entreprises. Cela nécessite le genre d'intensité et de dévouement de la part des programmeurs qu'ils ne seront prêts à fournir que lorsqu'il s'agira de leur propre entreprise. Les sociétés de logiciels peuvent embaucher des personnes qualifiées pour travailler dans un environnement pas trop exigeant, et peuvent embaucher des personnes peu qualifiées pour endurer les difficultés, mais elles ne peuvent pas embaucher des personnes très qualifiées pour se casser le dos. Puisque le capital n'est plus nécessaire, les grandes entreprises ont peu à apporter à la table."

[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.

Merci à Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson et Dan Giffin d'avoir lu les brouillons de ce document ; à Dan Bricklin et Bob Frankston pour les informations sur VisiCalc ; et encore une fois à Ken Anderson pour m'avoir invité à m'exprimer à BBN.

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