L'AUTRE VOIE À SUIVRE

Septembre 2001

(Cet article explique pourquoi une grande partie de la prochaine génération de logiciels pourra être basée sur des serveurs, 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 donnée chez BBN Labs.)

À l'été 1995, mon ami Robert Morris et moi avons décidé de lancer une startup. La campagne de relations publiques précédant l'introduction en bourse de Netscape était alors en plein essor, et la presse parlait beaucoup de commerce en ligne. À l'époque, il y avait peut-être trente magasins en ligne 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 un.

Pendant la première semaine environ, nous avions l'intention d'en faire une application de bureau ordinaire. Puis un jour, nous avons eu l'idée de faire fonctionner le logiciel sur notre serveur Web, en utilisant le navigateur comme interface. Nous avons essayé de réécrire le logiciel pour qu'il fonctionne sur le Web, et il était clair que c'était la voie à suivre. Si nous écrivions notre logiciel pour qu'il fonctionne 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, en tant que Yahoo Store, ce logiciel est le créateur de boutiques en ligne le plus populaire, avec environ 14 000 utilisateurs.

Lorsque nous avons lancé Viaweb, presque personne ne comprenait ce que nous voulions dire lorsque nous disions que le logiciel fonctionnait sur le serveur. Ce n'est qu'après le lancement de Hotmail un an plus tard que les gens ont commencé à comprendre. Maintenant, tout le monde sait qu'il s'agit d'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évitable nécessité de déplacer certaines choses hors du bureau. Si les logiciels se déplacent hors du bureau et sur les serveurs, cela signifiera un monde très différent pour les développeurs. Cet article décrit les choses surprenantes que nous avons vues, en tant que premiers visiteurs de ce nouveau monde. Dans la mesure où les logiciels se déplacent sur les serveurs, ce que je décris ici est l'avenir.

La prochaine étape ?

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

Les ordinateurs sont dans cette phase maintenant. Lorsque vous possédez un ordinateur de bureau, vous finissez par apprendre beaucoup plus de choses que vous ne le souhaitiez sur ce qui se passe à l'intérieur. Mais plus de la moitié des foyers américains en possèdent un. Ma mère a un ordinateur qu'elle utilise pour ses courriels et pour tenir ses comptes. Il y a environ un an, elle a été alarmée de recevoir une lettre d'Apple, lui offrant une réduction sur une nouvelle version du système d'exploitation. Il y a quelque chose qui ne va pas quand une femme de soixante-cinq ans qui veut utiliser un ordinateur pour ses courriels et ses comptes doit penser à installer de nouveaux systèmes d'exploitation. Les utilisateurs ordinaires ne devraient même pas connaître les mots "système d'exploitation", et encore moins "pilote de périphérique" ou "correctif".

Il existe maintenant une autre façon de fournir des logiciels qui permettra aux utilisateurs d'éviter 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 à autre chose qu'aux applications qu'ils utilisent. Tout ce qui est désordonné et changeant sera stocké sur un serveur quelque part, entretenu par le type de personnes qui sont bonnes dans 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 qu'il 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 surtout en fonction de l'apparence du boîtier. Vous paierez plus pour les services Internet que pour le matériel, comme vous le faites maintenant avec les téléphones. [1]

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

Le gain pour les utilisateurs

Près de chez moi, il y a une voiture avec un autocollant 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 gagnent, ce sera parce qu'ils sont plus pratiques. Et il semble que ce sera le cas, tant pour les utilisateurs que pour les développeurs.

Pour utiliser une application purement Web, 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 début de la fin, ici, a été le courrier électronique Web. Des millions de personnes se rendent compte maintenant que vous devriez avoir accès à vos messages électroniques où que vous soyez. Et si vous pouvez voir vos courriels, 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 assis sur un bureau lointain ?

L'idée même de "votre ordinateur" disparaît, et est remplacée par "vos données". Vous devriez pouvoir accéder à vos données depuis n'importe quel ordinateur. Ou plutôt, 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 conserver vos données sur eux : quelque chose que vous transportez avec vous peut être perdu ou volé. Laisser votre PDA 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 les logiciels purement Web, ni vos données ni les applications ne sont conservées sur le client. Vous n'avez donc rien à installer pour l'utiliser. Et lorsqu'il n'y a pas d'installation, vous n'avez pas à vous soucier que l'installation se passe mal. Il ne peut pas y avoir d'incompatibilités entre l'application et votre système d'exploitation, car le logiciel ne s'exécute pas sur votre système d'exploitation.

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

Après avoir essayé la démo, s'inscrire au service ne devrait pas nécessiter plus que de remplir un bref formulaire (plus il est bref, mieux c'est). Et ce devrait être le dernier travail que l'utilisateur a à faire. Avec les logiciels Web, vous devriez obtenir de nouvelles versions sans payer de supplément, ou sans faire aucun travail, ou même sans le savoir.

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

Avec les applications Web, tout le monde utilise la même version, et les bogues peuvent être corrigés dès qu'ils sont découverts. Les logiciels Web devraient donc avoir beaucoup moins de bogues que les logiciels de bureau. Chez Viaweb, je doute que nous ayons jamais eu dix bogues connus à un moment donné. 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 gain évident pour les applications collaboratives, mais je parie que les utilisateurs commenceront à vouloir cela dans la plupart des applications une fois qu'ils se rendront compte que c'est possible. Il sera souvent utile de laisser deux personnes modifier le même document, par exemple. Viaweb permettait à plusieurs utilisateurs de modifier un site simultanément, plus parce que c'était la bonne façon d'écrire le logiciel que parce que nous nous attendions à ce que les utilisateurs le veuillent, mais il s'est avéré que beaucoup le voulaient.

Lorsque vous utilisez une application Web, vos données seront plus sûres. Les pannes de disque ne seront pas une chose du passé, mais les utilisateurs n'en entendront plus parler. Elles se produiront au sein des fermes de serveurs. Et les entreprises qui proposent des applications Web effectueront réellement des sauvegardes - non seulement parce qu'elles auront de vrais administrateurs système qui s'inquiètent de ces choses, mais aussi parce qu'un ASP qui perd les données des gens sera dans de gros, gros ennuis. Lorsque les gens perdent leurs propres données dans une panne de disque, ils ne peuvent pas être si en colère, car ils n'ont que eux-mêmes à blâmer. Lorsqu'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 risques de faire fonctionner des virus, et aucune donnée locale à 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 trouveriez un désir énorme et presque inexploité pour des logiciels répondant à cette description. Déchaîné, cela pourrait être une force puissante.

Ville de code

Pour les développeurs, la différence la plus visible 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 c'est comme concevoir une ville plutôt qu'un bâtiment : en plus des bâtiments, il faut des routes, des panneaux de signalisation, des services publics, des policiers et des pompiers, et des plans pour la croissance et les différents types de catastrophes.

Chez Viaweb, les logiciels comprenaient des applications assez importantes avec lesquelles les utilisateurs communiquaient directement, des programmes que ces programmes utilisaient, des programmes qui s'exécutaient en permanence en arrière-plan à la recherche de problèmes, des programmes qui essayaient de redémarrer les choses si elles tombaient en panne, des programmes qui s'exécutaient occasionnellement pour compiler des statistiques ou construire des index pour les recherches, des programmes que nous exécutions explicitement pour collecter les ressources ou pour déplacer ou restaurer des données, des programmes qui se faisaient passer pour des utilisateurs (pour mesurer les performances ou exposer les bogues), des programmes pour diagnostiquer les problèmes de réseau, des programmes pour faire des sauvegardes, des interfaces vers des services externes, des logiciels qui pilotaient une impressionnante collection de cadrans affichant des statistiques de serveur en temps réel (un succès auprès des visiteurs, mais indispensable pour nous aussi), des modifications (y compris des corrections de bogues) apportées à des 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 les magasins vers de nouveaux serveurs à travers le pays, sans les arrêter, après que nous ayons été rachetés par Yahoo. Des programmes nous ont envoyé des messages, des télécopies et des courriels aux utilisateurs, ont effectué des transactions avec des processeurs de cartes de crédit, et ont communiqué entre eux par le biais de sockets, de pipes, de requêtes http, de ssh, de paquets udp, de mémoire partagée et de 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 des utilitaires inutiles que les gens pourraient utiliser pour pénétrer dans vos serveurs.

Cela ne s'arrêtait pas aux logiciels. Nous avons passé beaucoup de temps à réfléchir aux configurations des 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 devions réfléchir à la question de savoir si notre FAI en amont avait des connexions assez rapides à toutes les backbones. Nous avons eu des relations sérieuses avec les fournisseurs de RAID.

Mais le matériel n'est pas seulement quelque chose dont il faut s'inquiéter. 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. Si vous administrez les serveurs, vous pouvez en une seule étape permettre à tous vos utilisateurs d'envoyer des messages aux personnes, ou d'envoyer des télécopies, ou d'envoyer des commandes par téléphone, ou de traiter des cartes de crédit, etc., simplement en installant le matériel correspondant. 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 un moyen de nous distinguer de nos concurrents qui (soit parce qu'ils vendaient des logiciels de bureau, soit parce qu'ils revendaient des applications Web par le biais de FAI) n'avaient pas de contrôle direct sur le matériel.

Parce que le logiciel d'une application Web sera une collection de programmes plutôt qu'un seul binaire, il peut être écrit dans n'importe quel nombre de langages différents. Lorsque vous écrivez des logiciels 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) sont devenus 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 les logiciels basés sur des serveurs, vous pouvez utiliser n'importe quel langage que vous voulez. [3] Aujourd'hui, beaucoup des meilleurs hackers utilisent des langages très éloignés de C et C++ : Perl, Python, et même Lisp.

Avec les logiciels basés sur 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 convient le mieux à chaque tâche. Et lorsque vous avez des concurrents, "vous pouvez" signifie "vous devez" (nous y reviendrons plus tard), car si vous ne profitez pas de cette possibilité, vos concurrents le feront.

La plupart de nos concurrents utilisaient C et C++, et cela rendait leurs logiciels visiblement inférieurs car (entre autres choses), ils n'avaient aucun moyen de contourner l'absence d'état des scripts CGI. Si vous deviez changer quelque chose, tous les changements devaient se faire sur une seule page, avec un bouton Mise à jour en bas. Comme je l'ai écrit ailleurs, en utilisant Lisp, que beaucoup de gens considèrent toujours 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 le secteur des logiciels de bureau, faire une version est un énorme traumatisme, au cours duquel toute l'entreprise transpire et se démène pour sortir un seul et unique morceau de code géant. Des comparaisons évidentes s'imposent, tant pour le processus que pour le produit qui en résulte.

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

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

Lorsque vous ne publiez qu'une seule nouvelle version par an, vous avez tendance à gérer 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 d'assurance qualité intervient et commence à les compter, et les programmeurs travaillent sur la liste, en les corrigeant. Ils n'arrivent généralement pas au bout de la liste, et en fait, personne ne sait où est la fin. C'est comme pêcher des gravats dans un étang. Vous ne savez jamais vraiment ce qui se passe à l'intérieur du logiciel. Au mieux, vous vous retrouvez avec une sorte de correction statistique.

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

Les logiciels de bureau engendrent un certain fatalisme à l'égard des bogues. Vous savez que vous expédiez quelque chose qui est bourré de bogues, et vous avez même mis en place des mécanismes pour compenser cela (par exemple, des versions correctives). 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 l'a fait plus tôt cette année. Ils se sentaient sous pression pour sortir 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 sorti 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 à sortir un logiciel avant qu'il ne fonctionne, et vous pouvez le sortir dès qu'il fonctionne.

Le vétéran de l'industrie pourrait penser que c'est une bonne idée de dire que vous n'avez jamais à publier de logiciel avant qu'il ne fonctionne, mais que se passe-t-il lorsque vous avez promis de livrer une nouvelle version de votre logiciel à une certaine date ? Avec les logiciels Web, vous ne feriez pas une telle promesse, car il n'y a pas de versions. Votre logiciel change progressivement et en permanence. Certaines modifications peuvent être plus importantes que d'autres, mais l'idée de versions ne s'applique tout simplement pas naturellement aux logiciels Web.

Si quelqu'un se souvient de Viaweb, cela peut paraître étrange, car nous annoncions toujours de nouvelles versions. Cela était fait entièrement à des fins de relations publiques. Nous avons appris que la presse spécialisée pense en termes de numéros de version. Ils vous donneront une couverture importante pour une version majeure, ce qui signifie un nouveau premier chiffre dans le numéro de version, et généralement un paragraphe au plus pour une version mineure, ce qui signifie un nouveau chiffre après la virgule décimale.

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

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

Bugs

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

Les logiciels Web sont utilisés 24 heures sur 24, donc tout ce que vous faites est immédiatement mis à l'épreuve. Les bogues 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 bogues sont moins nombreux et transitoires. Lorsque vous publiez des logiciels progressivement, vous avez beaucoup moins de bogues au départ. Et lorsque vous pouvez reproduire les erreurs et publier des modifications instantanément, vous pouvez trouver et corriger la plupart des bogues dès qu'ils apparaissent. Nous n'avons jamais eu assez de bogues en même temps pour nous soucier d'un système de suivi des bogues formel.

Vous devriez bien sûr tester les modifications avant de les publier, afin qu'aucun bogue majeur ne soit publié. Les quelques-uns qui passent inévitablement à travers les mailles du filet impliqueront des cas limites et n'affecteront que les quelques utilisateurs qui les rencontrent avant que quelqu'un ne se plaigne. Tant que vous corrigez les bogues immédiatement, l'effet net, pour l'utilisateur moyen, est beaucoup moins de bogues. Je doute que l'utilisateur moyen de Viaweb ait jamais vu un bogue.

Corriger les bogues récents est plus facile que de corriger les anciens. Il est généralement assez rapide de trouver un bogue dans du code que vous venez d'écrire. Lorsque vous le trouvez, vous savez souvent ce qui ne va pas avant même de regarder la source, car vous vous en inquiétiez déjà inconsciemment. 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) est beaucoup plus de travail. Et comme vous ne comprenez pas aussi bien le code, vous êtes plus susceptible de le corriger d'une manière laide, ou même d'introduire plus de bogues. [4]

Lorsque vous détectez les bogues tôt, vous avez également moins de bogues composés. Les bogues composés sont deux bogues distincts qui interagissent : vous trébuchez en descendant les escaliers, et lorsque vous vous agrippez à la main courante, elle se détache dans votre main. Dans les logiciels, ce type de bogue est le plus difficile à trouver, et il a aussi tendance à avoir les pires conséquences. [5] L'approche traditionnelle "casser tout et ensuite filtrer les bogues" produit inévitablement beaucoup de bogues composés. Et les logiciels qui sont publiés dans une série de petites modifications ont tendance à ne pas en avoir. Les planchers sont constamment balayés pour enlever 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 secondaires. C'est quelque chose que vous êtes plus susceptible de voir dans les articles de recherche que dans les logiciels commerciaux, mais pour les applications Web, il s'avère être vraiment utile. Il est difficile d'écrire des programmes entiers en code purement fonctionnel, mais vous pouvez écrire des morceaux substantiels de cette façon. Cela rend ces parties de votre logiciel plus faciles à tester, car elles n'ont pas d'état, et c'est très pratique dans une situation où vous faites et testez constamment de petites modifications. J'ai écrit une grande partie de l'éditeur de Viaweb dans ce style, et nous avons fait de notre langage de script, RTML, un langage purement fonctionnel.

Les gens du secteur des logiciels de bureau auront du mal à le croire, mais chez Viaweb, les bogues sont devenus presque un jeu. Comme la plupart des bogues publiés impliquaient des cas limites, les utilisateurs qui les rencontraient étaient susceptibles d'être des utilisateurs avancés, repoussant les limites. Les utilisateurs avancés sont plus indulgents envers les bogues, surtout si vous les avez introduits en ajoutant une fonctionnalité qu'ils demandaient. En fait, parce que les bogues étaient rares et qu'il fallait faire des choses sophistiquées pour les voir, les utilisateurs avancés étaient souvent fiers d'en attraper un. Ils appelaient le support dans un esprit plus de triomphe que de colère, comme s'ils avaient marqué des points contre nous.

Support

Lorsque vous pouvez reproduire les erreurs, cela change votre approche du support client. Dans la plupart des entreprises de logiciels, le support est offert comme un moyen de faire en sorte que les clients se sentent mieux. Ils vous appellent soit pour un bogue connu, soit parce qu'ils font simplement quelque chose de mal et que vous devez comprendre ce qui se passe. Dans les deux cas, vous ne pouvez pas apprendre grand-chose d'eux. Et donc, vous avez tendance à considérer les appels de support comme une douleur dans le cul que vous voulez isoler de vos développeurs autant que possible.

Ce n'est pas comme ça que les choses fonctionnaient 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 le savoir tout de suite afin de pouvoir reproduire l'erreur et publier une correction.

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

Notre approche du support a rendu tout le monde plus heureux. Les clients étaient ravis. Imaginez ce que vous ressentiriez en appelant une ligne de support et en étant traité comme quelqu'un qui apporte des nouvelles importantes. Les personnes du support client aimaient ça parce que cela signifiait qu'elles pouvaient aider les utilisateurs, au lieu de leur lire des scripts. Et les programmeurs aimaient ça parce qu'ils pouvaient reproduire les bogues au lieu de simplement entendre des rapports vagues de seconde main à leur sujet.

Notre politique de correction des bogues à la volée a changé la relation entre les personnes du support client et les hackers. Dans la plupart des entreprises de logiciels, les personnes du support sont des boucliers humains sous-payés, et les hackers sont de petites copies de Dieu le Père, créateurs du monde. Quelle que soit la procédure de signalement des bogues, elle est susceptible d'être unidirectionnelle : les personnes du support qui entendent parler de bogues remplissent un formulaire qui est finalement transmis (peut-être via l'AQ) aux programmeurs, qui le mettent sur leur liste de choses à faire. C'était très différent chez Viaweb. En l'espace d'une minute après avoir entendu parler d'un bogue d'un client, les personnes du support pouvaient être debout à côté d'un programmeur en train de l'entendre dire "Merde, tu as raison, c'est un bogue". Les personnes du support étaient ravies d'entendre "tu as raison" de la part des hackers. Ils nous apportaient des bogues avec le même air d'attente qu'un chat qui vous apporte une souris qu'il vient de tuer. Cela les rendait également plus prudents dans l'évaluation de la gravité d'un bogue, car leur honneur était désormais en jeu.

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

Moral

Pouvoir publier des logiciels immédiatement est une grande motivation. Souvent, en allant 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 de temps), 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, pendant un certain temps au moins. Le problème 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 y figurer sont des idées que vous avez eues pendant que vous l'écriviez ? La même chose se produit avec les logiciels. Travailler à mettre en œuvre une idée vous en donne d'autres. Donc, mettre une idée de côté vous coûte 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, mettre une idée de côté inhibe probablement même les nouvelles idées : lorsque vous commencez à penser à une nouvelle fonctionnalité, vous apercevez l'étagère et vous 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 de les planifier. Chez Viaweb, nous rencontrions parfois 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 aucun plan. Nous avions des idées générales sur les choses que nous voulions améliorer, mais si nous avions su comment le faire, nous l'aurions déjà fait. Que devions-nous faire dans les six prochains mois ? Tout ce qui ressemblait à la plus grande victoire. Je ne sais pas si j'ai jamais osé donner cette réponse, mais c'était la vérité. Les plans ne sont qu'un autre mot pour les idées sur l'étagère. Lorsque nous avions de bonnes idées, nous les mettions en œuvre.

Chez Viaweb, comme dans de nombreuses entreprises de logiciels, la plupart des codes avaient un propriétaire défini. Mais lorsque vous possédiez quelque chose, vous le possédiez vraiment : personne d'autre que le propriétaire d'un morceau de logiciel n'avait à approuver (ou même à connaître) une version. Il n'y avait aucune protection contre les pannes, à l'exception de la peur de passer pour un idiot aux yeux de ses pairs, et c'était plus que suffisant. J'ai peut-être donné l'impression que nous avancions joyeusement en écrivant du code. Nous allions vite, mais nous réfléchissions très attentivement avant de publier des logiciels sur ces serveurs. Et faire attention est plus important pour la fiabilité que d'aller lentement. Parce qu'il fait très attention, un pilote de la marine peut faire atterrir un avion de 40 000 lb à 140 miles par heure sur un pont de porte-avions qui tangue, la nuit, plus en sécurité qu'un adolescent moyen peut couper un bagel.

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

Brooks à l'envers

Heureusement, les logiciels 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 travaillant dans l'ingénierie dans son ensemble. Seuls 13 d'entre eux étaient en développement de produits. Tous les autres travaillaient sur les versions, les ports, etc. Avec les logiciels Web, vous n'avez besoin (au maximum) que des 13 personnes, car il n'y a pas de versions, de ports, etc.

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

Lorsque vous pouvez écrire des logiciels avec moins de programmeurs, vous économisez plus que de l'argent. Comme Fred Brooks l'a souligné dans Le mythe du mois-homme, ajouter des personnes à un projet a tendance à le ralentir. Le nombre de connexions possibles entre les développeurs augmente exponentiellement avec la taille du groupe. Plus le groupe est grand, plus ils passeront de temps en réunion à négocier la façon dont leurs logiciels fonctionneront ensemble, et plus ils auront de bogues provenant d'interactions imprévues. Heureusement, ce processus fonctionne aussi à l'envers : lorsque les groupes deviennent plus petits, le développement de logiciels devient exponentiellement plus efficace. Je ne me souviens pas que les programmeurs de Viaweb aient jamais eu une vraie réunion. Nous n'avions jamais plus à dire à un moment donné que ce que nous pouvions dire en allant déjeuner.

S'il y a un inconvénient ici, c'est que tous les programmeurs doivent être dans une certaine mesure des administrateurs système aussi. Lorsque vous hébergez des logiciels, quelqu'un doit surveiller les serveurs, et dans la pratique, les seules personnes qui peuvent le faire correctement sont celles qui ont écrit le logiciel. Chez Viaweb, notre système avait tellement de composants et changeait si fréquemment qu'il n'y avait pas de frontière définie entre les logiciels et l'infrastructure. Déclarer arbitrairement une telle frontière aurait limité nos choix de conception. Et donc, même si nous espérions constamment qu'un jour ("dans quelques mois") tout serait suffisamment stable pour que nous puissions embaucher quelqu'un dont le travail serait uniquement de s'inquiéter des serveurs, cela ne s'est jamais produit.

Je ne pense pas que cela puisse être autrement, tant que vous développez activement le produit. Les logiciels Web ne seront jamais quelque chose que vous écrivez, que vous enregistrez et que vous rentrez chez vous. C'est une chose vivante, qui tourne sur vos serveurs en ce moment. Un mauvais bogue pourrait ne pas seulement planter le processus d'un utilisateur ; il pourrait les planter tous. 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 deux), mais vous voulez absolument garder un œil sur les choses que vous avez modifiées récemment. Vous ne publiez pas de code tard dans la nuit et vous ne rentrez pas chez vous.

Observer les utilisateurs

Avec les logiciels basés 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 s'être présenté aux clients dans les magasins de détail et leur avoir demandé de les suivre à la maison. Si vous avez déjà vu quelqu'un utiliser votre logiciel pour la première fois, vous savez quelles surprises les attendaient.

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

Lorsque vous avez les utilisateurs sur votre serveur, vous n'avez pas besoin de vous fier aux benchmarks, par exemple. Les benchmarks sont des utilisateurs simulés. Avec les logiciels basés sur des serveurs, vous pouvez observer des utilisateurs réels. Pour décider quoi optimiser, il suffit de vous connecter à un serveur et de voir ce qui consomme tout le CPU. Et vous savez aussi quand arrêter d'optimiser : nous avons fini par amener l'éditeur de Viaweb au point où il était limité par la mémoire plutôt que par le CPU, et comme il n'y avait rien que nous pouvions faire pour réduire la taille des données des utilisateurs (enfin, rien de facile), nous savions que nous pouvions aussi bien nous arrêter là.

L'efficacité est importante pour les logiciels basés sur des serveurs, 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 vendre moins cher que vos concurrents et toujours faire des bénéfices. Chez Viaweb, nous avons réduit le coût en capital par utilisateur à environ 5 $. Ce serait moins maintenant, probablement moins que le coût de l'envoi de leur première facture mensuelle. Le matériel est gratuit maintenant, si votre logiciel est raisonnablement efficace.

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

Enfin, en observant les utilisateurs, vous pouvez souvent dire quand ils sont en difficulté. Et comme le client a toujours raison, c'est le signe de quelque chose que vous devez corriger. Chez Viaweb, la clé pour obtenir des utilisateurs était l'essai en ligne. Ce n'était pas juste une série de diapositives construites par des personnes du marketing. Dans notre essai, les utilisateurs utilisaient réellement le logiciel. Cela prenait environ cinq minutes, et à la fin, ils avaient construit un magasin réel et fonctionnel.

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

J'ai étudié les traces de clics des personnes effectuant l'essai routier et j'ai constaté qu'à une certaine étape, elles étaient confuses et cliquaient sur le bouton Retour du navigateur. (Si vous essayez d'écrire des applications Web, vous constaterez que le bouton Retour devient l'un de vos problèmes philosophiques les plus intéressants.) J'ai donc ajouté un message à ce moment-là, indiquant aux utilisateurs qu'ils étaient presque terminés et leur rappelant de ne pas cliquer sur le bouton Retour. Une autre excellente chose à propos des logiciels Web est que vous obtenez un retour d'information instantané des changements : le nombre de personnes terminant l'essai routier est passé immédiatement de 60 % à 90 %. Et comme le nombre de nouveaux utilisateurs était fonction du nombre d'essais routiers terminés, notre croissance des revenus a augmenté de 50 %, simplement grâce à ce changement.

Argent

Au début des années 1990, j'ai lu un article dans lequel quelqu'un disait que les logiciels étaient une entreprise d'abonnement. Au début, cela semblait une déclaration très cynique. Mais plus tard, j'ai réalisé que cela reflète la réalité : le développement de logiciels est un processus continu. Je pense que c'est plus propre si vous facturez ouvertement des frais d'abonnement, au lieu de forcer les gens à continuer d'acheter et d'installer de nouvelles versions afin qu'ils continuent à vous payer. Et heureusement, les abonnements sont la façon naturelle de facturer les applications Web.

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

Pour les entreprises, les applications Web sont une source de revenus idéale. Au lieu de commencer chaque trimestre avec une page blanche, vous avez un flux de revenus récurrent. Parce que votre logiciel évolue progressivement, vous n'avez pas à vous soucier qu'un nouveau modèle échoue ; il n'y a jamais besoin d'un nouveau modèle, en soi, et si vous faites quelque chose au logiciel que les utilisateurs détestent, vous le saurez tout de suite. Vous n'avez aucun problème avec les factures impayables ; si quelqu'un ne veut pas vous payer, vous pouvez simplement désactiver le service. Et il n'y a aucune possibilité de piratage.

Ce dernier « avantage » pourrait s'avérer être un problème. Un certain niveau de piratage est à l'avantage des éditeurs 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 est un utilisateur de plus qui contribue à faire de votre logiciel la norme, ou qui pourrait acheter une copie plus tard, lorsqu'il aura terminé ses études secondaires.

Lorsque cela est possible, les entreprises aiment faire quelque chose appelé discrimination par les prix, ce qui signifie facturer à chaque client le prix qu'il peut se permettre. [8] Les logiciels sont particulièrement adaptés à la discrimination par les prix, car le coût marginal est proche de zéro. C'est pourquoi certains logiciels coûtent plus cher à exécuter sur des serveurs Sun que sur des serveurs Intel : une entreprise qui utilise des serveurs Sun n'est pas intéressée à économiser de l'argent et peut être facturée plus cher en toute sécurité. Le piratage est en fait le niveau le plus bas de la discrimination par les prix. Je pense que les éditeurs de logiciels le comprennent et ferment délibérément les yeux sur certains types de piratage. [9] Avec les logiciels basés sur des serveurs, ils vont devoir trouver une autre solution.

Les logiciels 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ù je réfléchissais à la question. En fait, la deuxième étape peut se propager à la première : si quelque chose est difficile à acheter, les gens changeront d'avis sur le fait qu'ils le voulaient. 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 Web sont à peu près la chose la plus facile au monde à acheter, surtout si vous venez de faire une démonstration en ligne. Les utilisateurs ne devraient pas avoir à faire beaucoup plus que de saisir un numéro de carte de crédit. (Faites-les faire plus à vos risques et périls.)

Parfois, les logiciels Web sont proposés par le biais de FAI agissant en tant que revendeurs. C'est une mauvaise idée. Vous devez administrer les serveurs, car vous devez constamment améliorer le matériel et les logiciels. Si vous abandonnez le contrôle direct des serveurs, vous abandonnez 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 étaient submergés par des costumes qui étaient enthousiastes à propos de ce canal potentiel énorme, et n'ont pas réalisé que cela ruinerait le produit qu'ils espéraient vendre par son intermédiaire. Vendre des logiciels 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 particuliers et des petites entreprises, et je pense que ce sera la règle avec les applications Web. Ce sont les utilisateurs qui sont prêts à essayer de nouvelles choses, en partie parce qu'ils sont plus flexibles, et en partie parce qu'ils veulent les coûts plus bas des nouvelles technologies.

Les applications Web seront souvent la meilleure chose pour les grandes entreprises aussi (même si elles seront lentes à s'en rendre compte). Le meilleur intranet est Internet. Si une entreprise utilise de vraies applications Web, les logiciels fonctionneront 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 méchants. Certains grands commerçants hésitaient à 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 de faire valoir ce point diplomatiquement, 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 start-up technologique dont toute l'activité est de faire fonctionner des serveurs, ou un détaillant de vêtements ? Non seulement nous avions de meilleures personnes qui s'inquiétaient de la sécurité, mais nous nous en soucions davantage. Si quelqu'un s'introduisait dans les serveurs du détaillant de vêtements, cela affecterait au plus un commerçant, pourrait probablement être étouffé et, dans le pire des cas, pourrait entraîner le licenciement d'une personne. Si quelqu'un s'introduisait dans les nôtres, cela pourrait affecter des milliers de commerçants, se retrouverait probablement dans les nouvelles sur CNet et pourrait nous mettre en faillite.

Si vous voulez garder votre argent en sécurité, le gardez-vous sous votre matelas à la maison, ou le mettez-vous dans une banque ? Cet argument s'applique à tous les aspects de l'administration des serveurs : pas seulement la sécurité, mais aussi la disponibilité, la bande passante, la gestion de la charge, les sauvegardes, etc. Notre existence dépendait de la bonne exécution de ces tâches. Les problèmes de serveur étaient le grand nono 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 les TI. Aussi drastique que cela puisse paraître, je pense que c'est généralement une bonne idée. Les entreprises sont susceptibles d'obtenir un meilleur service de cette façon que des administrateurs système internes. Les administrateurs système peuvent devenir grincheux et peu réactifs parce qu'ils ne sont pas directement exposés à la pression concurrentielle : un vendeur doit traiter avec les clients, et un développeur doit traiter avec les logiciels des concurrents, mais un administrateur système, comme un vieux célibataire, a peu de forces externes pour le maintenir en ligne. [10] Chez Viaweb, nous avions beaucoup de forces externes pour nous maintenir en ligne. Les personnes qui nous appelaient étaient des clients, pas seulement des collègues. Si un serveur se bloquait, nous sautions ; rien que d'y penser me donne une poussée 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 : il vaudra beaucoup d'argent pour 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 qui offrent des solutions coûteuses peuvent dépenser plus pour les vendre. Chez Viaweb, nous étions toujours confrontés à cela. Nous avons perdu plusieurs commerçants haut de gamme au profit de sociétés de conseil Web qui les ont convaincus qu'ils seraient mieux servis s'ils payaient un demi-million de dollars pour une boutique en ligne personnalisée sur leur propre serveur. En règle générale, ils n'étaient pas mieux servis, comme plus d'un l'a découvert lorsque la saison des achats de Noël est arrivée et que les charges ont augmenté sur leur serveur. Viaweb était beaucoup plus sophistiqué que ce que la plupart de ces commerçants 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 autoritaires 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 à celles-ci. (Si le ministère de la Défense paie mille dollars pour des sièges de toilettes, c'est en partie parce qu'il coûte cher de vendre des sièges de toilettes pour mille dollars.) Et c'est l'une des raisons pour lesquelles les logiciels intranet continueront de prospérer, même si c'est probablement une mauvaise idée. C'est tout simplement plus cher. Il n'y a rien que vous puissiez faire à propos de ce dilemme, donc le meilleur plan est d'aller d'abord pour les plus petits clients. Les autres viendront avec le temps.

Fils du serveur

Exécuter des logiciels sur le serveur n'est pas nouveau. En fait, c'est l'ancien modèle : les applications de 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 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 pirates informatiques, ou des amateurs, comme on les appelait à l'époque. Ils aimaient les micro-ordinateurs parce qu'ils étaient bon marché. Pour la première fois, vous pouviez avoir votre propre ordinateur. L'expression « ordinateur personnel » fait partie du langage maintenant, mais lorsqu'elle a été utilisée pour la première fois, elle avait un son délibérément audacieux, comme l'expression « satellite personnel » le ferait aujourd'hui.

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

Je ne pense pas que beaucoup de gens se rendent compte de la fragilité et de la précarité des start-ups au tout début. De nombreuses start-ups commencent presque par accident, comme deux gars, soit avec un emploi du jour, soit à l'école, qui écrivent un prototype de quelque chose qui pourrait, s'il semble prometteur, se transformer en une entreprise. À ce stade larvaire, tout obstacle important arrêtera la start-up net. Écrire des logiciels de mainframe nécessitait 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. Lancer une start-up pour écrire des logiciels de mainframe serait une entreprise beaucoup plus sérieuse que de simplement pirater quelque chose sur votre Apple II le soir. Et donc, vous n'avez pas eu beaucoup de start-ups qui écrivaient des applications de mainframe.

L'arrivée des ordinateurs de bureau a inspiré beaucoup de nouveaux logiciels, car écrire des applications pour eux semblait être un objectif atteignable pour les start-ups larvaires. Le développement était bon marché, et les clients seraient des particuliers que vous pouviez atteindre par le biais de magasins d'informatique ou même par correspondance.

L'application qui a propulsé les ordinateurs de bureau dans le courant dominant était VisiCalc, la première feuille de calcul. Il a été écrit par deux gars travaillant dans un grenier, et pourtant, il faisait des choses qu'aucun logiciel de mainframe ne pouvait faire. [11] VisiCalc était une telle avancée, à son époque, que les gens achetaient des Apple II juste pour l'exécuter. Et c'était le début d'une tendance : les ordinateurs de bureau ont gagné parce que les start-ups ont écrit des logiciels pour eux.

Il semble que les logiciels basés sur des serveurs seront bons cette fois-ci, parce que les start-ups les écriront. Les ordinateurs sont tellement bon marché maintenant que vous pouvez commencer, comme nous l'avons fait, en utilisant un ordinateur de bureau comme serveur. Les processeurs peu coûteux ont dévoré le marché des stations de travail (vous n'entendez même plus le mot maintenant) et sont en passe de conquérir le marché des serveurs ; les serveurs de Yahoo, qui gèrent des charges aussi élevées que celles de n'importe quel serveur sur Internet, ont tous les mêmes processeurs Intel peu coûteux 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 par des références dans la presse. [12]

Viaweb était une start-up larvaire typique. Nous étions terrifiés à l'idée de lancer une entreprise, et pendant les premiers mois, nous nous sommes réconfortés en traitant le tout comme une expérience que nous pourrions annuler à tout moment. Heureusement, il n'y avait que peu d'obstacles, à l'exception des obstacles 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 phase étaient la nourriture et le loyer.

Il y a d'autant plus de raisons pour les start-ups d'écrire des logiciels 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 aux conditions de Microsoft, en appelant ses API et en contournant son système d'exploitation buggé. Et si vous parvenez à écrire quelque chose qui décolle, vous constaterez peut-être que vous ne faisiez que de la recherche de marché pour Microsoft.

Si une entreprise veut créer une plateforme sur laquelle les start-ups construiront, elle doit en faire quelque chose que les pirates 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 pirates informatiques lorsqu'il est sorti, et beaucoup d'entre eux ont écrit des logiciels pour lui. [13] Vous voyez cela moins avec Windows, parce que les pirates ne l'utilisent pas. Le genre de personnes qui sont douées pour écrire des logiciels ont tendance à exécuter Linux ou FreeBSD maintenant.

Je ne pense pas que nous aurions lancé une start-up pour écrire des logiciels de bureau, parce que les logiciels de bureau doivent fonctionner sous Windows, et avant de pouvoir écrire des logiciels pour Windows, nous aurions dû l'utiliser. Le Web nous a permis de faire un tour de passe-passe autour de Windows, et de livrer des logiciels fonctionnant sous Unix directement aux utilisateurs par le biais du navigateur. C'est une perspective libératrice, un peu comme l'arrivée des PC il y a vingt-cinq ans.

Microsoft

À l'époque de l'arrivée des ordinateurs de bureau, IBM était le géant que tout le monde craignait. C'est difficile à imaginer maintenant, mais je me souviens très bien de ce sentiment. Maintenant, le géant effrayant est Microsoft, et je ne pense pas qu'ils soient aussi aveugles à la menace qui les guette qu'IBM ne l'était. Après tout, Microsoft a délibérément construit son entreprise dans l'angle mort d'IBM.

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

Je suppose que Microsoft développera une sorte d'hybride serveur/bureau, où le système d'exploitation fonctionne en collaboration avec des 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 pour client, s'ils peuvent l'éviter. Si vous n'avez besoin que d'un navigateur pour client, vous n'avez pas besoin de Microsoft sur le client, et si Microsoft ne contrôle pas le client, il ne peut pas pousser les utilisateurs vers ses applications basées sur 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 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 pourraient 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 eux qui 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 désirs. Ce qu'ils doivent faire, c'est cannibaliser leur activité existante, et je ne les vois pas faire face à cela. La même détermination qui les a menés jusqu'ici va maintenant travailler contre eux. IBM était dans exactement la même situation, et ils n'ont pas pu la maîtriser. IBM a fait une entrée tardive et timide dans le secteur des micro-ordinateurs parce qu'ils étaient ambivalents à l'idée de menacer leur vache à lait, l'informatique de mainframe. Microsoft sera de même entravé par le désir de sauver le bureau. Une vache à lait peut être un sacré singe lourd sur le dos.

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 joyeux chaos, comme il y en a eu aux premiers jours des micro-ordinateurs. C'était une bonne époque pour les start-ups. Beaucoup de petites entreprises ont prospéré, et l'ont fait en créant des choses cool.

Start-ups, mais plus encore

La start-up 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 start-up qui écrit des applications Web, tout ce que vous associez aux start-ups est porté à l'extrême. Vous pouvez écrire et lancer un produit avec encore moins de personnes et encore moins d'argent. Vous devez être encore plus rapide, et vous pouvez vous permettre d'être plus informel. Vous pouvez littéralement lancer votre produit en tant que trois gars assis dans le salon d'un appartement, et un serveur hébergé chez un FAI. Nous l'avons fait.

Au fil du temps, les équipes sont devenues plus petites, plus rapides et plus informelles. En 1960, le développement logiciel signifiait une salle pleine d'hommes portant des lunettes à monture épaisse et des cravates noires étroites, écrivant industriellement 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 mecs assis dans un salon avec des ordinateurs portables. (Et il s'avère que les jeans ne sont pas le dernier mot en matière d'informalité.)

Les startups sont stressantes, et cela, malheureusement, est également poussé à l'extrême avec les applications Web. De nombreuses entreprises de logiciels, en particulier au début, connaissent des périodes où les développeurs dormaient sous leurs bureaux, etc. Ce qui est alarmant avec les logiciels Web, c'est qu'il n'y a rien pour empêcher que cela devienne la norme. Les histoires de sommeil 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 Web ne sont jamais expédiés. Vous pouvez travailler 16 heures par jour aussi longtemps que vous le souhaitez. Et parce que vous le pouvez, et que vos concurrents le peuvent, vous avez tendance à être obligé de le faire. Vous le pouvez, donc vous devez. C'est la loi de Parkinson qui fonctionne à l'envers.

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

Chez Viaweb, nous avons passé les six premiers mois à écrire des logiciels. Nous avons travaillé les longues heures habituelles d'une startup en démarrage. Dans une entreprise de logiciels de bureau, cela aurait été la partie où nous travaillions dur, mais cela ressemblait à des vacances par rapport à la phase suivante, lorsque nous avons accueilli des utilisateurs sur notre serveur. Le deuxième plus grand avantage de la vente de Viaweb à Yahoo (après l'argent) était de pouvoir se débarrasser de la responsabilité ultime de l'ensemble de l'opération 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 faire. Il y a moins de stress au total, mais plus pour les programmeurs. Ce n'est pas nécessairement une mauvaise nouvelle. Si vous êtes une startup en concurrence avec une grande entreprise, c'est une bonne nouvelle. [15] Les applications Web offrent un moyen simple de surpasser vos concurrents. Aucune startup ne demande plus que cela.

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 choses que nous aurions vraiment aimé ajouter à HTML et HTTP. Ce qui compte, cependant, c'est que les pages Web sont assez bonnes.

Il y a un parallèle ici avec les premiers micro-ordinateurs. Les processeurs de ces machines n'étaient pas réellement destinés à être les CPU des ordinateurs. Ils étaient conçus pour être utilisés dans des choses comme les feux de circulation. Mais des types comme Ed Roberts, qui a conçu l' Altair, se sont rendu compte qu'ils étaient assez bons. Vous pouviez combiner l'une de ces puces avec de la mémoire (256 octets dans le premier Altair), et des commutateurs de panneau avant, et vous aviez un ordinateur qui fonctionnait. 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 assez bonnes. Et pour un nombre important d'utilisateurs, les logiciels que vous pouvez utiliser depuis n'importe quel navigateur seront un gain suffisant en soi pour compenser toute gêne dans l'interface utilisateur. Vous ne pouvez peut-être pas écrire la feuille de calcul la plus belle en utilisant HTML, mais vous pouvez écrire une feuille de calcul que plusieurs personnes peuvent utiliser simultanément à partir de différents endroits sans logiciel client spécial, ou qui peut incorporer des flux de données en direct, ou qui peut vous envoyer une page 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. Après tout, VisiCalc n'était pas simplement une version micro-ordinateur d'une application de mainframe - c'était un nouveau type d'application.

Bien sûr, les applications basées sur serveur n'ont pas besoin d'être basées sur le Web. Vous pourriez avoir un autre type de client. Mais je suis presque sûr que c'est une mauvaise idée. Ce 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 foutu. Parce que les logiciels Web ne supposent rien sur le client, ils fonctionneront partout où le Web fonctionne. C'est déjà un gros avantage, et cet avantage va croître à 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 aussi attentivement 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 choisir un gagnant. Une chose que je peux prédire est le conflit entre AOL et Microsoft. Quoi que devienne .NET de Microsoft, il impliquera probablement la connexion du bureau aux serveurs. À moins qu'AOL ne riposte, ils seront soit mis de côté, soit transformés en un tuyau entre le client Microsoft et les logiciels serveur. Si Microsoft et AOL se lancent dans une guerre des clients, la seule chose qui fonctionnera sur les deux sera la navigation sur le Web, ce qui signifie que les applications Web 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 pariez sur les applications Web. Personne ne peut briser cela sans briser la navigation. Le Web n'est peut-être pas le seul moyen de fournir des logiciels, mais c'est celui qui fonctionne maintenant et qui continuera de fonctionner pendant longtemps. Les applications Web sont peu coûteuses à développer et faciles à fournir même pour la plus petite startup. C'est beaucoup de travail, et d'un type particulièrement stressant, mais cela ne fait qu'améliorer les chances pour les startups.

Pourquoi pas ?

E. B. White était amusé d'apprendre d'un ami fermier que de nombreuses clôtures électrifiées n'ont aucun courant qui les traverse. Les vaches apprennent apparemment à s'en tenir éloignées, et après cela, vous n'avez plus besoin du courant. "Levez-vous, vaches !" écrivit-il, "Prenez votre liberté pendant que les despotes ronflent !"

Si vous êtes un pirate qui a pensé à créer un jour une startup, il y a probablement deux choses qui vous empêchent de le faire. L'une est que vous ne vous y connaissez pas en 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 gagnez plus que vous ne dépensez. 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 gagnerez peut-être pas plus que vous ne dépensez au début, mais tant que l'écart se réduit suffisamment vite, vous irez bien. Si vous commencez sous-financé, cela encouragera au moins une habitude de frugalité. Moins vous dépensez, plus il est facile de gagner plus que vous ne dépensez. Heureusement, il peut être très peu coûteux de lancer une application Web. Nous avons lancé notre entreprise 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 dollars de plus pour obtenir un SSL. (La seule entreprise qui vendait 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 payions pour la bande passante seule. Vous pourriez lancer une application Web maintenant pour moins que le coût d'un fauteuil de bureau chic.

Quant à la création de quelque chose que les utilisateurs adorent, voici quelques conseils généraux. Commencez par créer quelque chose de propre et simple que vous aimeriez 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 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 que les logiciels puissent être est la simplicité, mais la façon d'y parvenir est de bien définir les valeurs par défaut, et non de limiter les choix des utilisateurs. Ne vous contentez pas de vous reposer sur vos lauriers si les logiciels de vos concurrents sont médiocres ; la norme à laquelle comparer votre logiciel est ce qu'il pourrait être, et non ce que vos concurrents actuels ont. Utilisez votre logiciel vous-même, tout le temps. Viaweb était censé être un générateur de boutiques en ligne, mais nous l'avons également utilisé pour créer notre propre site. N'écoutez pas les spécialistes du marketing, les designers ou les chefs de produit simplement à cause de leurs titres de poste. S'ils ont de bonnes idées, utilisez-les, mais c'est à vous de décider ; les logiciels doivent être conçus par des pirates qui comprennent le design, et non par des designers qui s'y connaissent un peu en logiciels. Si vous ne pouvez pas concevoir des logiciels aussi bien que les mettre en œuvre, ne lancez pas une startup.

Parlons maintenant de la concurrence. Ce que vous craignez, ce ne sont pas vraisemblablement des groupes de pirates comme vous, mais de vraies entreprises, avec des bureaux, des plans d'affaires, des commerciaux, etc., n'est-ce pas ? Eh bien, ils ont plus peur de vous que vous d'eux, et ils ont raison. Il est beaucoup plus facile pour un couple de pirates de trouver comment louer un bureau ou embaucher des commerciaux que pour une entreprise de quelque taille que ce soit de faire écrire des logiciels. J'ai été des deux côtés, et je sais. Lorsque Viaweb a été racheté 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, et les cadres supérieurs étaient de vrais bourreaux. Pour une grande entreprise, ils étaient exceptionnels. Mais ils n'étaient toujours que dix fois moins productifs qu'une petite startup. Aucune grande entreprise ne peut faire beaucoup mieux que cela. Ce qui est effrayant avec Microsoft, c'est qu'une entreprise aussi grande puisse développer des logiciels du tout. Ils sont comme une montagne qui peut marcher.

Ne vous laissez pas intimider. Vous pouvez faire autant de choses que Microsoft ne peut pas faire, tout comme ils peuvent faire des choses que vous ne pouvez pas faire. Et personne ne peut vous arrêter. Vous n'avez pas besoin de demander la permission à qui que ce soit pour développer des applications Web. Vous n'avez pas besoin de conclure des accords de licence, d'obtenir de l'espace en rayon dans les magasins de détail ou de vous prosterner pour que votre application soit intégrée au système d'exploitation. Vous pouvez fournir des logiciels directement au navigateur, et personne ne peut s'interposer entre vous et les utilisateurs potentiels sans les empêcher de naviguer sur le Web.

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

Remarques

[1] Se rendant compte qu'une grande partie de l'argent se trouve dans les services, les entreprises qui construisent des clients légers ont généralement essayé de combiner le matériel avec un service en ligne. Cette approche n'a pas bien fonctionné, en partie parce que vous avez besoin de deux types d'entreprises différentes pour construire de l'électronique grand public et pour gérer un service en ligne, et en partie parce que les utilisateurs détestent l'idée. Donner le rasoir et gagner de l'argent sur les lames peut fonctionner pour Gillette, mais un rasoir est un engagement beaucoup plus faible qu'un terminal Web. Les fabricants de téléphones portables sont satisfaits de vendre du matériel sans essayer de capturer également les revenus des services. Cela devrait probablement être le modèle pour les clients Internet également. Si quelqu'un vendait simplement une petite boîte bien conçue avec un navigateur Web que vous pourriez utiliser pour vous connecter via n'importe quel FAI, tous les technophobes du pays en achèteraient un.

[2] La sécurité dépend toujours plus de ne pas se tromper que de toute décision de conception, mais la nature des logiciels basés sur serveur incitera les développeurs à faire plus attention à ne pas se tromper. Compromis un serveur pourrait causer des dommages tels que les ASP (qui veulent rester en affaires) sont susceptibles d'être prudents en matière de sécurité.

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

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

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

[6] Au sein de Viaweb, nous avons un jour organisé un concours pour décrire le pire aspect de notre logiciel. Deux personnes du support client ont été ex aequo pour la première place avec des entrées dont je tremble encore de me souvenir. Nous avons corrigé les deux problèmes immédiatement.

[7] Robert Morris a écrit le système de commande, que les acheteurs utilisaient pour passer des commandes. Trevor Blackwell a écrit le générateur d'images et le gestionnaire, que les commerçants utilisaient pour récupérer les commandes, afficher 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 par les prix est si répandue (combien de fois avez-vous entendu un détaillant affirmer que son pouvoir d'achat lui permettait de vous proposer des prix plus bas ?) que j'ai été surpris de constater qu'elle était interdite aux États-Unis par la loi Robinson-Patman de 1936. Cette loi ne semble pas être appliquée avec vigueur.

[9] Dans No Logo, Naomi Klein affirme que les marques de vêtements privilégiées par les "jeunes urbains" ne s'efforcent pas trop d'empêcher le vol à l'étalage parce que dans leur marché cible, les voleurs à l'étalage sont aussi les leaders de la mode.

[10] Les entreprises se demandent souvent ce qu'il faut externaliser et ce qu'il ne faut pas externaliser. Une réponse possible : externaliser tout travail qui n'est pas directement exposé à la pression concurrentielle, car l'externalisation le rendra ainsi exposé à la pression concurrentielle.

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

[12] Ce n'est pas aussi facile que je le fais paraître. Il a fallu un temps douloureusement long pour que le bouche-à-oreille se mette en place, et nous n'avons commencé à obtenir une grande couverture médiatique qu'après avoir embauché un cabinet de relations publiques (admirablement le meilleur du secteur) pour 16 000 $ 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 le secteur des logiciels et a déchaîné une nuée de fournisseurs de composants bon marché sur le matériel Apple. Cela n'a pas aidé non plus que des costumes aient pris le contrôle pendant une période critique.

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

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

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 a prouvé qu'ils avaient tort. Il y a toujours de la place pour quelque chose de nouveau si les options actuelles sont suffisamment pourries. Assurez-vous qu'il fonctionne sur tous les systèmes d'exploitation gratuits en premier - les nouvelles choses commencent avec leurs utilisateurs.

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

"J'irais même plus loin en disant que parce que les logiciels serveur sont si difficiles pour les programmeurs, ils provoquent un changement économique fondamental qui s'éloigne des grandes entreprises. Cela exige le genre d'intensité et de dévouement de la part des programmeurs qu'ils ne seront prêts à fournir que lorsqu'il s'agit de leur propre entreprise. Les entreprises de logiciels peuvent embaucher des personnes qualifiées pour travailler dans un environnement peu exigeant, et peuvent embaucher des personnes non qualifiées pour endurer des difficultés, mais elles ne peuvent pas embaucher des personnes hautement qualifiées pour se défoncer. Puisque le capital n'est plus nécessaire, les grandes entreprises n'ont pas grand-chose à 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.

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

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