dorianmarie.com | Paul Graham | Legal | Terms | Privacy

L’autre Voie à Suivre

Chapitre 5

À l’été 1995, mon ami Robert Morris et moi avons décidé de démarrer une start-up. La campagne de relations publiques qui a conduit à l’introduction en bourse de Netscape battait son plein à l’époque, et la presse a beaucoup parlé du commerce en ligne. À l’époque, il y avait peut-être trente magasins réels sur le Web, tous fabriqués à la main. S’il devait y avoir beaucoup de magasins en ligne, il faudrait des logiciels pour les fabriquer, alors nous avons décidé d’en écrire.

Pour 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 à prendre. Si nous écrivions notre logiciel pour l’exécuter 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 boutique en ligne le plus populaire, avec plus de 20 000 utilisateurs.

Lorsque nous avons lancé Viaweb, personne ou presque ne comprenait ce que nous voulions dire lorsque nous disions que le logiciel fonctionnait sur le serveur.. Ce n’est que lorsque Hotmail a été lancé un an plus tard que les gens ont commencé à comprendre. Maintenant, tout le monde sait que c’est une approche valable. Il y a maintenant un nom pour ce que nous étions : un fournisseur de services d’application, 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 le logiciel passe du bureau aux serveurs, cela signifiera un monde très différent pour les développeurs. Cet essai décrit les choses surprenantes que nous avons vues, comme certains des premiers visiteurs de ce nouveau monde. À la mesure dans laquelle le logiciel passe sur les serveurs, ce que je décris ici est l’avenir.

La prochaine chose ?

Lorsque nous revenons sur l’ère des logiciels de bureau, je pense que nous allons nous émerveiller des inconvénients que les gens en ont à supporter, tout comme nous nous émerveillons maintenant de ce que les premiers propriétaires de voitures ont à supporter. Pendant les vingt ou trente premières années, il a dû être un expert automobile pour posséder une voiture. Mais les voitures ont été une si grande victoire que beaucoup de gens qui n’étaient pas des experts en voitures voulaient les avoir aussi.

Les ordinateurs sont maintenant dans cette phase. Lorsque vous possédez un ordinateur de bureau, vous finissez par apprendre beaucoup plus que ce que vous vouliez savoir sur ce qui se passe à l’intérieur. Mais plus de la moitié des ménages aux États-Unis en possèdent un. Ma mère a un ordinateur qu’elle utilise pour le courrier électronique et pour tenir des comptes. Il y a quelques années, elle a été alarmée d’avoir reçu une lettre d’Apple, lui offrant un décompte 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 les comptes doit penser à installer de nouveaux systèmes d’exploitation. Les utilisateurs ordinaires ne devraient même pas connaître les mots “système d’exploitation”, et encore moins “pilote d’appareil” ou “patch”.

Il existe maintenant un autre moyen de fournir des logiciels qui éviteront aux utilisateurs de devenir administrateurs système. Les applications Web sont des programmes qui s’exécutent sur des serveurs Web et utilisent les pages Web comme interface utilisateur. Pour l’utilisateur moyen, ce nouveau type de logiciel sera plus facile, moins cher, plus mobile, plus fiable et souvent plus puissant que les logiciels de bureau.

Avec les logiciels basés sur le Web, la plupart des utilisateurs n’auront pas à penser à quoi que ce soit, sauf aux applications qu’ils utilisent. Toutes les choses désordonnées et changeantes seront assises sur un serveur quelque part, entretenues par le genre de personnes qui sont bonnes dans ce genre de choses. Et donc, vous n’aurez généralement pas besoin d’un ordinateur, en soi, pour utiliser un logiciel. Tout ce dont vous aurez besoin sera quelque chose avec un clavier, un écran et un navigateur Web. Peut-être aura-t-il un accès Internet sans fil. Peut-être que ce sera aussi votre téléphone portable. Quoi qu’il en soit, ce sera de l’électronique grand public : quelque chose qui coûte environ 200 $, et que les gens choisissent principalement en fonction de l’apparence de l’affaire. 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 un clic pour accéder au serveur et revenir, de sorte que les utilisateurs de logiciels fortement interactifs, comme Photoshop, voudront toujours que les calculs se déroulent sur le bureau. Mais si vous regardez le genre de choses pour lesquelles la plupart des gens utilisent les ordinateurs, 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.

La victoire pour les utilisateurs

Près de chez moi, il y a une voiture avec un autocollant de pare-chocs qui indique « la mort avant le désagrément ». La plupart des gens, la plupart du temps, prendront n’importe quel choix qui nécessite le moins de travail. Si le logiciel basé sur le Web gagne, ce sera parce que c’est plus pratique. Et il semble que ce sera le cas, pour les utilisateurs et les développeurs à la fois.

Pour utiliser une application purement basée sur le 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.

L’extrémité amincie du coin ici était le courrier électronique basé sur le Web. Des millions de gens se rendent maintenant compte que vous devriez avoir accès aux messages électroniques, où que vous soyez. Et si vous pouvez voir votre e-mail, pourquoi pas votre calendrier ? Si vous pouvez discuter d’un document avec vos collègues, pourquoi ne pouvez-vous pas le modifier ? Pourquoi l’une de vos données devrait-elle être piégée sur un ordinateur assis sur un bureau éloigné ? Toute l’idée de “votre ordinateur” disparaît et est remplacée par “vos données”. Vous devriez être en mesure d’obtenir vos données à partir de 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 en tant que clients de plus en plus petit, vous avez une autre raison de ne pas garder vos données dessus : quelque chose que vous transportez avec vous peut être perdu ou volé. Laisser votre PDA dans un taxi est comme un accident de disque dur, sauf que vos données sont remises à quelqu’un d’autre au lieu d’être évaporées.

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

Parce qu’il n’a pas besoin d’installation, il sera facile et courant d’essayer un logiciel Web avant de l’acheter. Vous devriez vous attendre à pouvoir tester n’importe quelle application Web gratuitement, simplement en vous rendant sur le site où elle est proposée. Chez Viaweb, l’ensemble de notre site était comme une grosse flèche pointant les utilisateurs vers l’essai routier.

Après avoir essayé la démo, l’inscription au service ne devrait nécessiter rien de plus que de remplir un bref formulaire. Et cela devrait être le dernier travail que l’utilisateur doit faire. Avec les logiciels basés sur le Web, vous devriez obtenir de nouvelles versions sans payer de supplément, ni faire de travail, ni peut-être même le savoir.

Les mises à jour ne seront pas les grands chocs qu’elles sont maintenant. Au fil du temps, les applications deviendront progressivement de plus en plus puissantes. Cela demandera un certain effort de la part des développeurs. Ils devront concevoir le logiciel afin qu’il puisse être mis à jour sans confondre les utilisateurs. C’est un nouveau problème, mais il y a des moyens de le résoudre. Avec les applications Web, tout le monde utilise la même version, et les bugs peuvent être corrigés dès qu’ils sont découverts. Les logiciels Web devraient donc avoir beaucoup moins de bugs que les logiciels de bureau. Chez Viaweb, je doute que nous ayons jamais eu dix bugs connus à un moment donné. C’est des ordres de grandeur meilleurs que les logiciels de bureau.

Les applications Web peuvent être utilisées par plusieurs personnes en même temps. C’est une victoire évidente pour les applications collaboratives, mais je parie que les utilisateurs commenceront à le vouloir 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 a permis à plusieurs utilisateurs de modifier un site simultanément, d’autant plus 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 l’ont fait.

Lorsque vous utilisez une application Web, vos données seront plus en sécurité. Les plantages de disque ne seront pas une chose du passé, mais les utilisateurs n’en entendront plus parler. Ils se produiront au sein des fermes de serveurs. Et les entreprises offrant des applications Web feront en fait des sauvegardes - non seulement parce qu’elles auront de vrais administrateurs système qui s’inquiètent de telles choses, mais aussi parce qu’un ASP qui perd les données des gens aura de gros problèmes. Lorsque les gens perdent leurs propres données lors d’un plantage de disque, ils ne peuvent pas se mettre en colère, parce qu’ils n’ont qu’eux-mêmes à être en colère. Lorsqu’une entreprise perd leurs données pour eux, ils seront beaucoup plus furieux.

Enfin, les logiciels basés sur le Web devraient être moins vulnérables aux virus. Si le client n’exécute rien d’autre qu’un navigateur, il y a moins de chances d’exécuter des virus et aucune donnée localement à endommager. Et un programme qui a attaqué les serveurs eux-mêmes devrait les trouver bien défendus 2.

Pour les utilisateurs, les logiciels basés sur le web seront moins stressants. Je pense que chez l’utilisateur moyen de Windows, vous trouveriez un énorme et pratiquement inexploité désir pour des logiciels répondant à cette description. Libéré, il pourrait s’agir d’une force puissante. La Cité du Code

Pour les développeurs, la différence la plus notable entre les logiciels Web et les logiciels de bureau est qu’une application Web n’est pas un seul morceau de code. Il s’agit d’une collection de programmes de différents types plutôt que d’un seul grand binaire. Et donc, concevoir des logiciels basés sur le Web, c’est comme concevoir une ville plutôt qu’un bâtiment : ainsi que des bâtiments, vous avez besoin de routes, de panneaux de signalisation, de services publics, de police et de services d’incendie, et de plans pour la croissance et divers types de catastrophes.

Chez Viaweb, les logiciels incluent des applications assez importantes auxquelles les utilisateurs parlaient directement, des programmes cccccbcdhkglhfluddlnkbhrcdvvncrcbkbgflefjbvi que d’autres programmes utilsaient, des programmes qui s’exerçaient constamment en arrière-plan à la recherche de problèmes, des programmes qui essayaient de dé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 avons couru explicitement vers des ressources de collecte de déchets ou pour déplacer ou restaurer des données, des programmes qui prétendaient être des utilisateurs (pour mesurer les performances ou exposer des bugs), des programmes pour diagnostiquer les problèmes de réseau, des programmes pour faire des sauvegardes, des interfaces avec des services. Trevor Blackwell a écrit un programme spectaculaire pour déplacer les magasins vers de nouveaux serveurs à travers le pays, sans les fermer, après que nous ayons été achetés par Yahoo. Les programmes nous ont téléphonés, ont envoyé des fax et des courriels aux utilisateurs, ont effectué des transactions avec des fournisseurs de cartes de crédit et se sont entretenus par le biais de sockets, de tuyaux, de requêtes HTTP, de SSH, de paquets UDP, de mémoire partagée et de fichiers. Certains de Viaweb consistaient même en l’absence de programmes, puisque 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’est pas terminé avec le logiciel. 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 avons dû nous demander si notre FAI en amont avait des connexions assez rapides à toutes les dorsales. Nous avons daté en série les fournisseurs de RAID.

Mais le matériel n’est pas seulement quelque chose dont il y a à craindre. Lorsque vous le contrôlez, vous pouvez en faire plus pour les utilisateurs. Avec une application de bureau, vous pouvez spécifier un certain matériel minimum, mais vous ne pouvez pas en ajouter d’autres. Si vous administrez les serveurs, vous pouvez en une seule étape permettre à tous vos utilisateurs de contacter des personnes, ou d’envoyer des fax, ou d’envoyer des commandes par téléphone, ou de traiter des cartes de crédit, etc., simplement en installant le matériel 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 un moyen de nous distinguer des concurrents qui (soit parce qu’ils vendaient des logiciels de bureau, soit parce qu’ils revendaient des applications Web par l’intermédiaire 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 langues différentes. Lorsque vous écrivez un logiciel haut de gamme, vous êtes pratiquement obligé d’écrire l’application dans le même langage que le système d’exploitation sous-jacent, c’est-à-dire C et C++. Et donc ces langages (en particulier chez les personnes non technologiques comme les gestionnaires et les investisseurs de capital-risque) ont dû être considérés comme les langages pour le développement de logiciels « sérieux ». Mais ce n’était qu’un artefact de la façon dont les logiciels de bureau devaient être livrés. Pour les logiciels basés sur serveur, vous pouvez utiliser n’importe quel langage que vous voulez 3. Aujourd’hui, beaucoup des meilleurs pirates utilisent des langages loin de C et C++ : Perl, Python et même Lisp.

Avec les logiciels sur serveur, personne ne peut vous dire quelle langue utiliser, car vous contrôlez l’ensemble du système, jusqu’au matériel. Différentes langues sont bonnes pour différentes tâches. Vous pouvez utiliser ce qui est le mieux pour chacune. Et lorsque vous avez des concurrents, “vous pouvez” signifie “vous devez” (nous y reviendrons plus tard), car si vous ne profitez pas de cette possibilité, vos concurrents le feront. La plupart de nos concurrents utilisaient C et C++, ce qui rendait leur logiciel visiblement inférieur parce que (entre autres choses), ils n’avaient aucun moyen de contourner l’apatridie des scripts CGI. Si vous deviez changer quelque chose, tous les changements devaient se produire sur une seule page, avec un bouton de mise à jour en bas. Comme je l’explique dans le chapitre 12, en utilisant Lisp, que beaucoup de gens considèrent encore comme un langage de recherche, nous pourrions faire en sorte que l’éditeur Viaweb se comporte davantage comme un logiciel de bureau.

Sorties

L’un des changements les plus importants dans ce nouveau monde est la façon dont vous faites les sorties. Dans le secteur des logiciels de bureau, faire une version est un énorme traumatisme, dans lequel toute l’entreprise transpire et s’efforce de pousser un seul morceau de code géant. Des comparaisons évidentes se suggèrent, à la fois pour le processus et pour le produit qui en résulte.

Avec un logiciel sur serveur, vous pouvez apporter des modifications presque comme vous le feriez dans un programme que vous écriviez pour vous-même. Vous publiez un logiciel sous la forme d’une série de changements incrémentiels au lieu d’une grande explosion occasionnelle. Une société de logiciels de bureau typique pourrait faire une ou deux versions par an. Chez Viaweb, nous faisions souvent trois à cinq sorties par jour.

Lorsque vous passez à ce nouveau modèle, vous vous rendez compte à quel point le développement logiciel est affecté par la façon dont il est publié. Bon nombre 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 à faire face à des bugs en gros. Quelque temps avant la date de sortie, vous assemblez une nouvelle version dans laquelle la moitié du code a été arrachée et remplacée, introduisant d’innombrables bugs. Ensuite, une équipe de personnes chargées de l’assurance qualité intervient et commence à les compter, et les programmeurs travaillent sur la liste, les corrigeant. Ils n’amènent généralement pas à la fin de la liste, et en effet, personne ne sait où se trouve la fin. C’est comme pêcher des décombres dans un étang. On ne sait jamais vraiment ce qui se passe à l’intérieur du logiciel. Au mieux, vous vous retrouvez avec une sorte d’exactitude statistique.

Avec les logiciels basés sur serveur, la majeure partie du changement est faible et incrémentielle. Cela en soi est moins susceptible d’introduire des bugs. Cela signifie également que vous savez quoi tester le plus soigneusement lorsque vous êtes sur le point de publier un logiciel : la dernière chose que vous avez changée. Vous vous retrouvez avec 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 lisez la source, vous le faites comme un pilote scannant le tableau de bord, pas comme un détective essayant de résoudre un mystère.

Les logiciels de bureau engendrent un certain fatalisme à propos des bugs. Vous savez que vous expédiez quelque chose chargé de bugs, et vous avez même mis en place des mécanismes pour le compenser (par exemple, les versions de correctifs). Alors pourquoi s’inquiéter d’un peu plus ? Bientôt, vous publiez des fonctionnalités complètes dont vous savez qu’elles sont cassées. Apple l’a fait il y a quelques années. Ils se sont sentis sous pression pour sortir leur nouveau système d’exploitation, dont la date de sortie avait déjà glissé quatre fois, mais une partie du logiciel (prise en charge de CD et DVD) n’était pas prête. La solution ? Ils ont sorti le système d’exploitation sans les pièces inachevées, et les utilisateurs ont dû l’ installer plus tard.

Avec les logiciels Web, vous n’avez jamais à publier de logiciel avant qu’il ne fonctionne, et vous pouvez le libérer dès qu’il fonctionne.

Le vétéran de l’industrie pense peut-être : 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 un logiciel basé sur le Web, vous ne feriez pas une telle promesse, car il n’y a pas de versions. Votre logiciel change progressivement et continuellement. Certains changements peuvent être plus importants que d’autres, mais l’idée de versions ne s’adapte naturellement aux logiciels basés sur le Web. Si quelqu’un se souvient de Viaweb, cela peut sembler bizarre, parce que nous annoncions toujours de nouvelles versions. Cela a été fait entièrement à des fins de relations publiques. La presse professionnelle, nous l’avons appris, pense en chiffres de version. Ils vous donneront une couverture majeure pour une version majeure, c’est-à-dire un nouveau premier chiffre sur le numéro de version, et généralement un paragraphe tout au plus pour une version ponctuelle, c’est-à-dire un nouveau chiffre après le point décimal.

Certains de nos concurrents proposaient des logiciels de bureau et avaient en fait des numéros de version. Et pour ces communiqués, dont le simple fait nous semblait la preuve de leur retard, ils obtiendraient toutes sortes de publicités. Nous ne voulions pas manquer, 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”, en collant un nouveau numéro de version sur le logiciel et en publiant un communiqué de presse disant que la nouvelle version était disponible immédiatement. Étonnamment, personne ne nous a jamais appelé.

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

Bugs

L’autre avantage technique majeur des logiciels basés sur le Web est que vous pouvez reproduire la plupart des bugs. Vous avez les données des utilisateurs sur votre disque. Si quelqu’un casse votre logiciel, vous n’avez pas besoin d’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’il est au téléphone avec vous. Vous le savez peut-être déjà, si vous avez un code pour remarquer les erreurs intégrées à votre application.

Les logiciels Web sont utilisés 24 heures sur 24, de sorte que tout ce que vous faites est immédiatement passé par l’essoreuse. Les bugs se lèvent rapidement.

Les sociétés de logiciels sont parfois accusées de laisser les utilisateurs débuguer leurs logiciels. Et c’est exactement ce que je préconise. Pour les logiciels basés sur le Web, c’est en fait un bon plan, car les bugs sont moins nombreux et transitoires. Lorsque vous publiez progressivement un logiciel, vous obtenez beaucoup moins de bugs pour commencer. Et lorsque vous pouvez reproduire les erreurs et publier des modifications 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 soucier d’un système formel de suivi des bugs.

Vous devriez tester les modifications avant de les publier, bien sûr, de sorte qu’aucun bug majeur ne soit publié. Les quelques personnes qui s’échappent inévitablement impliqueront des cas limites et n’affecteront que les quelques utilisateurs qui les rencontrent avant que quelqu’un n’appelle pour se plaindre. Tant que vous corrigez les bugs tout de suite, l’effet net, pour l’utilisateur moyen, est de beaucoup moins de bugs. Je doute que l’utilisateur moyen de Viaweb ait jamais vu un bug.

Il est plus facile de réparer de nouveaux bugs que d’anciens. Il est généralement assez rapide de trouver un bug dans le code que vous venez d’écrire. Quand il s’avère, vous savez souvent ce qui ne va pas avant même de regarder la source, parce que 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 non plus le code, vous êtes plus susceptible de le corriger d’une manière laide, ou même d’introduire plus de bugs 4.

Lorsque vous attrapez des bugs tôt, vous obtenez également moins de bugs composés. Les bugs composés sont deux bugs séparés qui interagissent : vous descendez en bas, et lorsque vous atteignez la main courante, elle se détache dans votre main. Dans les logiciels, ce type de bug est le plus difficile à trouver, et a également tendance à avoir les pires conséquences 5. L’approche traditionnelle “tout casser, puis filtrer les bugs” donne intrinsèquement beaucoup de bugs composés. Et les logiciels publiés dans une série de petits changements ont intrinsèquement tendance à ne pas le faire. Les sols sont constamment balayés pour enlever tout objet qui pourrait se coincer dans quelque chose.

Cela aide si vous utilisez une technique appelée “programmation fonctionnelle”. La programmation fonctionnelle signifie éviter les effets secondaires. C’est quelque chose que vous êtes plus susceptible de voir dans les documents 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 tant que 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 trouveront cela difficile à créditer, mais chez Viaweb, les bugs sont devenus presque un jeu. Étant donné que la plupart des bugs publiés concernaient des cas limites, les utilisateurs qui les rencontraient étaient susceptibles d’être des utilisateurs avancés, repoussant les limites. Les utilisateurs avertis par la publicité sont plus indulgents à propos des bugs, d’autant plus que vous les avez probablement introduits au cours de l’ajout d’une fonctionnalité qu’ils demandaient. En fait, parce que les bugs étaient rares et que vous deviez faire des choses sophistiquées pour les voir, les utilisateurs avancés étaient souvent fiers d’en attraper un. Ils appelleraient le soutien dans un esprit plus de triomphe que de colère, comme s’ils nous avaient marqué des points.

Support

Lorsque vous pouvez reproduire des erreurs, cela change votre approche du support client. Dans la plupart des entreprises de logiciels, une assistance est offerte comme un moyen de faire en sorte que les clients se sentent mieux. Soit ils vous appellent à propos d’un bug connu, soit ils font juste quelque chose de mal et vous devez comprendre quoi. Dans les deux cas, il n’y a pas grand-chose que vous puissiez apprendre d’eux. Vous avez donc tendance à considérer les appels à l’assistance comme une “douleur dans le cul (pain in the ass)” que vous voulez isoler de vos développeurs autant que possible.

Ce n’était pas comme ça que les choses fonctionnaient chez Viaweb. Chez Viaweb, l’assistance était gratuite, parce que 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 un correctif.

Ainsi, chez Viaweb, les développeurs étaient toujours en contact étroit avec le support. Les gens du support client étaient à environ 10 mètres des programmeurs, et savaient qu’ils pouvaient toujours interrompre n’importe quoi avec un rapport d’un véritable bug. Nous quittons une réunion du conseil d’administration pour corriger un grave bug.

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

Notre politique de correction des bugs à la volée a changé la relation entre les personnes du support client et les hackers. Dans la plupart des entreprises de logiciels, les personnes de soutien 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, il est probable qu’elle soit à sens unique : aider les personnes qui entendent parler de bugs en remplissant un formulaire qui est finalement transmis (éventuellement via l’assurance qualité) aux programmeurs, qui le mettent sur leur liste de choses à faire. C’était différent chez Viaweb. Dans la minute de l’annonce d’un bug de la part d’un client, les personnes du support pouvaient se tenir à côté d’un programmeur et l’entendre dire “Merde, tu as raison, c’est un bug”. Cela a ravi les gens de soutien d’entendre que “vous avez raison” de la part des hackers. Ils nous apportaient des bugs avec le même air expectant qu’un chat qui vous apportait une souris qu’il vient de tuer. Cela les a également rendus plus prudents dans le jugement de la gravité d’un bug, parce que maintenant leur honneur était en jeu.

Après que nous ayons été achetés par Yahoo, les gens du support client ont été éloignés des programmeurs. Ce n’est qu’à ce moment-là que nous avons réalisé qu’il s’agissait effectivement d’une assurance qualité et, dans une certaine mesure, d’un certain marketing. En plus d’attraper des bugs, ils étaient les gardiens de la connaissance de choses plus vagues et de type bug, comme des fonctionnalités qui confondaient les utilisateurs 6. Ils constituaient également une sorte de groupe de discussion par procuration ; nous pouvions leur demander laquelle de deux nouvelles fonctionnalités les utilisateurs souhaitaient le plus, et ils avaient toujours raison.

Morale

Être capable de publier un logiciel immédiatement est une grande source de motivation. Souvent, alors que je me rendais au travail à pied, je pensais à un changement que je voulais apporter au logiciel, et je le faisais ce jour-là. Cela a également fonctionné pour de plus grandes fonctionnalités. Même si quelque chose allait prendre deux semaines à écrire (les 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 sortie, j’aurais mis de côté la plupart de ces idées, au moins pendant un certain temps. La chose à propos des idées, cependant, c’est qu’elles mènent à plus d’idées. Avez-vous déjà remarqué que lorsque vous vous asseyez pour écrire quelque chose, la moitié des idées qui s’y terminent sont celles auxquelles vous avez pensé en écrivant ? Il en va de même pour les logiciels. Travailler à la mise en œuvre d’une idée vous donne plus d’idées. La mise en suspens d’une idée vous coûte donc non seulement ce retard dans sa mise en œuvre, mais aussi toutes les idées que sa mise en œuvre aurait permis. En fait, la mise en suspens d’une idée inhibe probablement même les 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 pour la prochaine version”.

Ce que font les grandes entreprises au lieu de mettre en œuvre des fonctionnalités, c’est de les planifier. Chez Viaweb, nous avons parfois eu des problèmes sur ce compte. Les investisseurs et les analystes nous demandaient ce que nous avions prévu pour l’avenir. La réponse véridique 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 savions comment nous l’aurions déjà fait. Qu’allions-nous faire au cours des six prochains mois ? Tout cela semblait être la plus grande victoire. Je ne sais pas si j’ai jamais osé donner cette réponse, mais c’était la vérité. Les plans ne sont qu’un autre mot pour les idées sur l’étagère. Lorsque nous avons pensé à de bonnes idées, nous les avons mises en œuvre.

Chez Viaweb, comme dans de nombreuses sociétés de logiciels, la plupart des codes avaient un propriétaire défini. Mais lorsque vous possédiez quelque chose, vous le possédiez vraiment : personne, à l’exception du propriétaire d’un logiciel, n’avait à approuver (ou même à connaître) une version. Il n’y avait pas de protection contre la casse, sauf la peur de ressembler à un idiot à ses pairs, et c’était plus que suffisant. J’ai peut-être donné l’impression que nous venions d’avancer l’écriture de code. Nous sommes allés vite, mais nous avons réfléchi très attentivement avant de publier des logiciels sur ces serveurs. Et faire attention est plus important pour la fiabilité que d’avancer lentement. Parce qu’il fait très attention, un pilote de la Marine peut faire atterrir un avion de 40 000 lb à 140 miles à l’heure sur un pont de porte-avions, la nuit, plus en toute sécurité que l’adolescent moyen ne peut couper un bagel.

Cette façon d’écrire des logiciels est une épée à 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 prises par les comités au lieu des personnes qui les ont eues.

Le Ruisseau à l’envers

Heureusement, les logiciels basés sur le Web nécessitent moins de programmeurs. J’ai déjà travaillé pour une société 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 cours de développement de produits. Tous les autres travaillaient sur les versions, les ports, et ainsi de suite. Avec les logiciels basés sur le Web, tout ce dont vous avez besoin (au plus) sont les 13 personnes, car il n’y a pas de versions, de ports, et ainsi de suite.

Viaweb a été écrit par seulement trois personnes 7. J’étais toujours sous pression pour embaucher plus, parce que nous voulions nous faire acheter, et nous savions que les acheteurs auraient du mal à payer un prix élevé pour une entreprise avec seulement trois programmeurs. (Solution : nous en avons embauché plus, mais nous avons créé de nouveaux projets pour eux.)

Lorsque vous pouvez écrire des logiciels avec moins de programmeurs, cela vous permet d’économiser plus que de l’argent. Comme Fred Brooks l’a souligné dans The Mythical Man-Month, l’ajout de personnes à un projet a tendance à le ralentir. Le nombre de connexions possibles entre les développeurs augmente de façon exponentielle avec la taille du groupe 8. Plus le groupe est grand, plus ils passeront de temps dans des réunions à négocier la façon dont leur logiciel fonctionnera ensemble, et plus ils obtiendront de bugs à partir d’interactions imprévues. Heureusement, ce processus fonctionne également à l’envers : à mesure que 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 véritable réunion. Nous n’avons jamais eu plus à dire à un moment donné que ce que nous pouvions dire alors que nous allions déjeuner.

S’il y a un inconvénient ici, c’est que tous les programmeurs doivent également être, dans une certaine mesure, des administrateurs système. Lorsque vous hébergez un logiciel, 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 précise entre le logiciel et l’infrastructure. La déclaration arbitraire d’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 était juste 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 toujours activement le produit. Les logiciels basés sur le Web ne sont jamais quelque chose que vous écrivez, que vous enregistrez et que vous rentrez chez vous. C’est une chose en direct, qui fonctionne sur vos serveurs en ce moment. Un mauvais bug ne pourrait pas simplement faire planter le processus d’un utilisateur ; il pourrait tous les faire planter. Si un bug dans votre code corrompt certaines données sur le disque, vous devez le corriger. Et ainsi de suite. Nous avons constaté que vous n’avez pas besoin de regarder les serveurs toutes les minutes (après la première année environ), mais vous voulez certainement garder un œil sur les choses que vous avez changées récemment. Vous ne relâchez pas le code tard dans la nuit, puis vous rentrez chez vous.

Observer les utilisateurs

Avec les logiciels sur serveur, vous êtes en contact é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 à la maison. Si vous avez déjà vu quelqu’un utiliser votre logiciel pour la première fois, vous savez quelles surprises l’attendaient.

Les logiciels devraient faire ce que les utilisateurs pensent qu’il fera. Mais vous ne pouvez avoir aucune idée de ce que les utilisateurs penseront, croyez-moi, jusqu’à ce que vous les regardiez. Et les logiciels basés sur serveur vous donnent des informations sans précédent sur leur comportement. Vous n’êtes pas limité à de petits groupes de discussion artificiels. Vous pouvez voir chaque clic effectué par chaque utilisateur. Vous devez examiner attentivement ce que vous allez examiner, car vous ne voulez pas violer la vie privée des utilisateurs, mais même l’échantillonnage statistique le plus général peut être très utile.

Lorsque vous avez les utilisateurs sur votre serveur, vous n’avez pas à vous fier aux points de repère, par exemple. Les points de repère sont des utilisateurs simulés. Avec un logiciel basé sur serveur, vous pouvez regarder les utilisateurs réels. Pour décider ce qu’il faut optimiser, il suffit de se connecter à un serveur et de voir ce qui consomme tout le CPU. Et vous savez quand arrêter d’optimiser aussi : nous avons finalement amené l’éditeur Viaweb au point où il était lié à la mémoire plutôt qu’au CPU, et comme nous ne pouvions rien faire pour réduire la taille des données des utilisateurs (enfin, rien de facile), nous savions que nous pouvions aussi bien nous arrêter là.

L’efficacité est importante pour les logiciels basés sur serveur, car vous payez pour le matériel. Le nombre d’utilisateurs que vous pouvez prendre en charge par serveur est le diviseur de votre coût en capital, donc si vous pouvez rendre votre logiciel très efficace, vous pouvez sous-estimer vos concurrents tout en faisant un profit. Chez Viaweb, nous avons réduit le coût en capital par utilisateur à environ 5 $. Ce serait moins maintenant, probablement moins que le coût de leur envoyer la facture du premier mois. Le matériel est gratuit maintenant, si votre logiciel est raisonnablement efficace.

Observer les utilisateurs peut vous guider dans la conception ainsi que dans l’optimisation. Viaweb avait un langage de script appelé RTML qui permettait aux utilisateurs avancés de définir leurs propres styles de page. Nous avons découvert que RTML est devenu une sorte de boîte de suggestion, parce que 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 a mis des barres de boutons sur la page, par exemple, mais après qu’un certain nombre d’utilisateurs ont utilisé RTML pour mettre des boutons sur le côté gauche, nous en avons fait la valeur par défaut dans les styles de page prédéfinis.

Enfin, en observant les utilisateurs, vous pouvez souvent savoir quand ils ont des ennuis. Et puisque le client a toujours raison, c’est un signe de quelque chose que vous devez réparer. Chez Viaweb, la clé pour obtenir des utilisateurs était le test en ligne. Il ne s’agissait pas seulement d’une série de diapositives construites par des gens du marketing. Lors de notre test, les utilisateurs ont effectivement utilisé le logiciel. Cela a pris environ cinq minutes, et à la fin, ils avaient construit un vrai magasin qui fonctionnait.

Le test a été 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 test, ils aimeront le produit. S’ils sont confus ou s’ennuient, ils ne le feront pas. Donc, tout ce que nous pourrions faire pour amener plus de gens à passer le test augmenterait notre taux de croissance.

J’ai étudié les pistes de clics des personnes qui font le test et j’ai constaté qu’à une certaine étape, elles se confondaient et cliquaient sur le bouton Retour du navigateur. (Si vous essayez d’écrire des applications Web, vous constaterez que le bouton Retour devient l’un de vos problèmes philosophiques les plus intéressants.) J’ai donc ajouté un message à ce moment-là, disant aux utilisateurs qu’ils avaient presque terminé et leur rappelant de ne pas cliquer sur le bouton Retour. Une autre bonne chose à propos des logiciels basés sur le Web est que vous obtenez une rétroaction instantanée des changements : le nombre de personnes qui terminent le test est immédiatement passé de 60 % à 90 %. Et comme le nombre de nouveaux utilisateurs était fonction du nombre d’essais terminés, notre croissance des revenus a augmenté de 50 %, juste à cause de ce changement.

L’Argent

Au début des années 1990, j’ai lu un article qui décrivait les logiciels comme 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 logiciel est un processus continu. Je pense que c’est plus propre si vous facturez ouvertement des frais d’abonnement, au lieu de forcer les gens à continuer à acheter et à installer de nouvelles versions pour qu’ils continuent à vous payer. Et pour l’accord, les abonnements sont le moyen naturel de facturer les applications Web.

L’hébergement des applications est un domaine où les entreprises joueront un rôle qui n’est pas susceptible d’être rempli par des logiciels gratuits. L’hébergement d’applications est très stressant et comporte des dépenses réelles. Personne ne voudra le faire gratuitement.

Pour les entreprises, les applications Web sont une source de revenus idéale. Au lieu de commencer chaque trimestre avec une ardoise vierge, vous avez une source de revenus récurrents. Parce que votre logiciel évolue progressivement, vous n’avez pas à vous inquiéter 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 irrécouvrables ; si quelqu’un ne paie pas, vous pouvez simplement éteindre le service. Et il n’y a aucune possibilité de piratage.

Ce dernier « avantage » peut s’être révélé être un problème. Une certaine quantité de bidouillage est à l’avantage des entreprises de logiciels. Si un utilisateur n’avait jamais acheté votre logiciel à quelque prix que ce soit, vous n’avez rien perdu s’il utilise une copie hackée. En fait, vous gagnez, parce qu’il est un utilisateur de plus qui aide à faire de votre logiciel la norme - ou qui pourrait en acheter une copie plus tard, lorsqu’il obtiendra son diplôme d’études secondaires.

Lorsqu’elles le peuvent, les entreprises aiment faire ce qu’on appelle la discrimination des prix, ce qui signifie facturer à chaque client autant qu’elles le peuvent 9. Les logiciels sont particulièrement adaptés à la discrimination des prix, car le coût marginal est proche de zéro. C’est pourquoi certains logiciels coûtent plus cher pour fonctionner sur Suns que sur les boîtiers Intel : une entreprise qui utilise Suns n’est pas intéressée à économiser de l’argent et peut être facturée plus cher en toute sécurité. Le bidouillage est en fait le plus bas niveau de discrimination par les prix. Je pense que les éditeurs de logiciels comprennent cela et ferment délibérément les yeux sur certains types de bidouillage 10. Avec les logiciels basés sur le serveur, elles devront trouver une autre solution.

Les logiciels basés sur le Web se vendent bien, surtout par rapport aux logiciels de bureau, car il est facile à acheter. Vous pourriez penser que les gens décident d’acheter quelque chose, puis de l’acheter, en deux étapes distinctes. C’est ce que je pensais avant Viaweb, dans la mesure où j’ai pensé à 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 la question de savoir s’ils le voulaient. Et vice versa : vous vendrez plus de quelque chose quand il sera facile à acheter. J’achète plus de nouveaux livres parce qu’Amazon existe. Les logiciels basés sur le Web sont à peu près la chose la plus facile au monde à acheter, surtout si vous venez de faire une démo en ligne. Les utilisateurs ne devraient pas avoir à faire beaucoup plus que d’entrer un numéro de carte de crédit. (Faites-leur en faire plus à vos périls.)

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

Plusieurs de nos concurrents se sont tiré une balle dans le pied de cette façon - généralement, je pense, parce qu’ils étaient envahis par des costumes qui étaient enthousiasmés par cet énorme canal potentiel, et ne se rendaient pas compte que cela ruinerait le produit qu’ils espéraient vendre à travers lui. Vendre des logiciels sur le Web par l’intermédiaire de FAI, c’est comme vendre des sushis par l’intermédiaire 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 basées sur le Web. Ce sont les utilisateurs qui sont prêts à essayer de nouvelles choses, en partie parce qu’ils sont plus flexibles, et en partie parce qu’ils veulent les coûts inférieurs des nouvelles technologies.

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

L’argument contre cette approche repose généralement sur la sécurité : si l’accès est plus facile pour les employés, ce sera aussi pour les méchants. Certains grands commerçants étaient réticents à utiliser Viaweb parce qu’ils pensaient que les informations de carte de crédit des clients seraient plus sûres sur leurs propres serveurs. Il n’a pas été 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’entreprise gère 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 inquiétions davantage. Si quelqu’un s’infiltrait dans les serveurs du détaillant de vêtements, cela affecterait tout au plus un commerçant, pourrait probablement être étouffé et, dans le pire des cas, pourrait faire licencier une personne. Si quelqu’un s’est fait irruption dans le nôtre, cela pourrait affecter des milliers de commerçants, finirait probablement comme une nouvelle sur CNet, et pourrait nous mettre en faillite.

Si vous voulez garder votre argent en sécurité, le gardez-vous sous votre matelas à la maison ou le mettez-vous dans une banque ? Cet argument s’applique à tous les aspects de l’administration du serveur : pas seulement la sécurité, mais aussi le temps de disponibilité, la bande passante, la gestion de la charge, les sauvegardes, etc. Notre existence dépendait de bien faire ces choses. Les problèmes de serveur étaient un grand non pour nous, comme un jouet dangereux pour un fabricant de jouets, ou une épidémie de salmonelle pour un robot culinaire.

Une grande entreprise qui utilise des applications basées sur le Web est à cette ancienne externalisation de l’informatique. Bien 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 les administrateurs système internes. Les administratifs du système peuvent devenir grincheux et insensibles parce qu’ils ne sont pas directement exposés à la pression concurrentielle. Un vendeur doit traiter avec des 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 11. Chez Viaweb, nous avions beaucoup de forces externes pour nous maintenir en ligne. Les gens qui nous appelaient étaient des clients, pas seulement des collègues. Si un serveur était coincé, nous sautions. Le simple fait d’y penser me donne une poussée d’adrénaline, des années plus tard.

Ainsi, les applications Web seront généralement la bonne réponse pour les grandes entreprises aussi. Ils seront les derniers à s’en rendre compte, cependant, tout comme ils l’étaient avec les ordinateurs de bureau. Et en partie pour la même raison : cela 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 les solutions bon marché sont meilleures, parce que les personnes qui proposent des solutions coûteuses peuvent dépenser plus pour les vendre. Chez Viaweb, nous avons toujours été confrontés à cela. Nous avons perdu plusieurs commerçants haut de gamme au profit de sociétés de conseil en ligne qui les ont convaincus qu’ils seraient mieux lotis s’ils payaient un demi-million de dollars pour une boutique en ligne sur mesure sur leur propre serveur. Ils n’étaient, en règle générale, pas pariés, comme plus d’un a découvert lorsque la saison des achats de Noël est arrivée et que des 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 faisant autorité pour faire des présentations aux clients.

Parfois, nous avons joué avec l’idée d’un nouveau service appelé Viaweb Gold. Il aurait exactement les mêmes caractéristiques que notre service régulier, mais coûterait dix fois plus cher qu’il serait vendu en personne par un homme en costume. Nous n’avons jamais eu le temps d’offrir cette variante, mais je suis sûr que nous aurions pu y inscrire quelques commerçants.

Une grande partie de ce pour quoi les grandes entreprises paient en plus est le coût de leur vendre des choses chères. (Si le ministère de la Défense paie mille dollars pour des sièges de toilette, c’est en partie parce qu’il coûte cher de vendre des sièges de toilette pour mille dollars.) Et c’est l’une des raisons pour lesquelles les logiciels intranet continueront à 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 cette énigme, donc le meilleur plan est d’aller d’abord pour les plus petits clients. Le reste viendra à temps.

Fils du serveur

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

Au début, les ordinateurs de bureau ne ressemblaient pas à une grande menace. Les premiers utilisateurs étaient tous des hackers - ou des amateurs, comme on les appelait à l’époque. Ils aimaient les micro-ordinateurs parce qu’ils étaient bon marché. Pour la première fois, vous pourriez avoir votre propre ordinateur. L’expression “ordinateur personnel” fait maintenant partie de la langue, 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 relais ? Principalement parce qu’ils avaient de meilleurs logiciels. Et la raison pour laquelle le logiciel de micro-ordinateur était meilleur était qu’il pouvait être écrit par de petites entreprises. Je ne pense pas que beaucoup de gens se rendent compte à quel point les startups sont fragiles et provisoires à un stade précoce. De nombreuses startups commencent presque par accident - en tant que potes, que ce soit avec des emplois de jour ou à l’école, écrivant un prototype de quelque chose qui pourrait, s’il semble prometteur, se transformer en entreprise. À ce stade larvaire, tout obstacle important arrêtera la start-up morte sur ses rails. L’écriture d’un logiciel mainframe nécessitait trop d’engagement dès le départ. Les machines de développement étaient chères, et parce que les clients seraient de grandes entreprises, vous auriez besoin d’une force de vente impressionnante pour les leur vendre. Démarrer une start-up pour écrire un logiciel mainframe serait une entreprise beaucoup plus sérieuse que de simplement bidouiller quelque chose ensemble sur votre Apple II le soir. Et donc vous n’avez pas eu beaucoup de startups écrivant des applications mainframe.

L’arrivée des ordinateurs de bureau a inspiré beaucoup de nouveaux logiciels, car l’écriture d’applications pour eux semblait un objectif réalisable pour les startups au niveau larvaire. Le développement était bon marché, et les clients seraient des personnes individuelles que vous pouviez joindre par le biais de magasins d’informatique ou même par correspondance.

L’application qui a poussé les ordinateurs de bureau dans le grand public était VisiCalc, la première feuille de calcul. Il a été écrit par deux gars travaillant dans un grenier, et pourtant ont fait des choses qu’aucun logiciel mainframe ne pouvait faire 12. VisiCalc était un tel progrès, en son temps, que les gens ont acheté des Apple IIs juste pour l’exécuter. 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 sur serveur seront bons cette fois-ci, parce que les startups l’écriront. Les ordinateurs sont si bon marché maintenant que vous pouvez commencer, comme nous l’avons fait, à utiliser un ordinateur de bureau comme serveur. Les processeurs bon marché ont mangé le marché des stations de travail (vous entendez rarement le mot maintenant) et sont la plupart du chemin à travers le marché des serveurs ; les serveurs de Yahoo, qui traitent des charges aussi élevées que n’importe quelle autre sur Internet, ont tous les mêmes processeurs Intel 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 des références dans la presse 13.

Viaweb était une start-up larvaire typique. Nous étions terrifiés à l’époque de créer une entreprise, et pendant les premiers mois, nous nous sommes réconfortés en traitant le tout comme une expérience que nous pourrions nier à tout moment. Heureusement, il y avait 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 celle que nous utilisions pour le développement, connectée au monde extérieur par une ligne commutée. Nos seules dépenses à ce stade étaient la nourriture et le loyer.

Il y a d’autant plus de raisons pour les startups d’écrire des logiciels basés sur le Web maintenant, parce que 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 travaillant autour de leur système d’exploitation buggy. Et si vous parvenez à écrire quelque chose qui décolle, vous constaterez peut-être que vous faisiez simplement des études de marché pour Microsoft.

Si une entreprise veut créer une plate-forme sur laquelle les startups s’appuieront, elle doit en faire quelque chose que les pirates eux-mêmes voudront utiliser. Cela signifie qu’il doit être peu coûteux et bien conçu. Le Mac était populaire auprès des pirates informatiques lorsqu’il est sorti pour la première fois, et beaucoup d’entre eux ont écrit un logiciel pour lui 14. Vous le voyez moins avec Windows, parce que les hackers ne l’utilisent pas. Le genre de personnes qui sont douées pour écrire des logiciels ont tendance à utiliser Linux ou FreeBSD maintenant.

Je ne pense pas que nous aurions commencé une start-up pour écrire des logiciels de bureau, parce que les logiciels de bureau doivent fonctionner sur Windows, et avant que nous ne devions écrire des logiciels pour Windows, nous devions l’utiliser. Le Web nous permet de faire une fin de course autour de Windows et de fournir des logiciels fonctionnant sous Unix directement aux utilisateurs via le navigateur. C’est une perspective libératrice, un tel que l’arrivée des PC il y a vingt-cinq ans.

Microsoft

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

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

Je m’attends à ce que Microsoft développe une sorte d’hybride serveur/ordinateur de bureau, où le système d’exploitation fonctionne 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 pour un client, s’ils peuvent l’éviter. Si vous n’avez besoin que d’un navigateur pour un client, vous n’avez pas besoin de Microsoft sur le client, et si Microsoft ne contrôle pas le client, ils ne peuvent pas pousser les utilisateurs vers leurs applications sur serveur.

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

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

Ce n’est pas tant qu’un concurrent les fasse trébucher qu’ils se fassent trébucher eux-mêmes. Avec l’essor des logiciels basés sur le Web, ils seront confrontés non seulement à des problèmes techniques, mais aussi à leurs propres vœux pieux. Ce qu’ils doivent faire, c’est cannibaliser leur entreprise existante, et je ne peux pas les voir faire face à cela. La même détermination d’esprit qui les a amenés jusqu’ici va maintenant travailler contre eux. IBM était exactement dans la même situation, et ils ne pouvaient pas 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 mainframe. Microsoft sera également entravé par le fait de vouloir sauver le bureau. Une vache à lait peut être un lourd fardeau sur votre dos.

Je ne dis pas que personne ne dominera les applications basées sur le serveur. Quelqu’un finira probablement par le faire. Mais je pense qu’il y aura une bonne longue période de chaos joyeux, tout comme il y en avait dans les premiers jours des micro-ordinateurs. C’était un bon moment pour les startups. Beaucoup de petites entreprises ont prospéré, et l’ont fait en faisant des choses cool.

Les startups, mais plus encore

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

Dans une start-up qui écrit des applications Web, tout ce que vous associez aux startups 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 en tirer en étant plus informel. Vous pouvez littéralement lancer votre produit en tant que trois gars opérant depuis d’un appartement, avec un serveur placé chez un FAI. Nous l’avons fait.

Au fil du temps, les équipes sont devenues plus petites, plus rapides et plus informelles. En 1960, le développement de logiciels signifiait une salle pleine d’hommes avec des lunettes à monture en corne et d’ étroites cravates noires, écrivant de manière indurelignée dix lignes de code par jour sur des formulaires de codage IBM. En 1980, il s’agissait d’une équipe de huit à dix personnes portant un jean au bureau et tapant dans les VT100. Maintenant, il y a quelques gars assis dans un salon avec des ordinateurs portables. (Les jeans ne sont pas le dernier mot en matière d’informalité.)

Les startups sont stressantes, et cela, malheureusement, est également porté à l’extrême avec les applications Web. De nombreuses sociétés de logiciels, en particulier au début, ont des périodes où les développeurs dormaient sous leur bureau et ainsi de suite. Ce qui est alarmant à propos des logiciels basés sur le Web, c’est qu’il n’y a rien pour empêcher que cela devienne la valeur par défaut. Les histoires sur le fait de dormir sous les bureaux se terminent généralement : enfin, nous l’avons expédié, et nous sommes tous rentrés à la maison et avons dormi pendant une semaine. Les logiciels basés sur le Web ne sont jamais expédiés. Vous pouvez travailler 16 heures par jour aussi longtemps que vous le souhaitez. Et parce que vous le pouvez, et que vos concurrents le peuvent, vous avez tendance à être forcé de le faire. Vous 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 professionnels et les administrateurs système ont traditionnellement chacun leurs propres préoccupations. Les programmeurs s’inquiètent des bugs, et les administrateurs système s’inquiètent de l’infrastructure. Les programmeurs peuvent passer une longue journée à se plonger jusqu’aux coudes dans le code source, mais à un moment donné, ils peuvent rentrer chez eux et l’oublier. Les administrateurs du système ne laissent jamais tout à fait le travail derrière eux, mais lorsqu’ils sont téléphonés à 4 heures du matin, ils n’ont généralement pas à faire quoi que ce soit de très compliqué. Avec les applications Web, ces deux types de stress se combinent. Les programmeurs deviennent administrateurs système, mais sans les limites bien définies qui rendent habituellement le travail supportable.

Chez Viaweb, nous avons passé les six premiers mois à écrire des logiciels. Nous avons travaillé les longues heures habituelles d’une start-up précoce. Dans une entreprise de logiciels de bureau, cela aurait été la partie la plus difficile, mais on l’a ressenti comme des vacances par rapport à la phase suivante, lorsque nous avons emmené les utilisateurs sur notre serveur. Le deuxième plus grand avantage de la vente de Viaweb à Yahoo (après l’argent) a été de pouvoir rejeter 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 basés sur le 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 start-up en concurrence avec une grande entreprise, c’est une bonne nouvelle 16. Les applications Web offrent un moyen simple de surpasser vos concurrents. Aucune start-up n’en demande plus.

Juste assez bon

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

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

Les pages Web n’ont pas été conçues pour être une interface utilisateur pour les applications, mais elles sont juste assez bonnes. Et pour un nombre important d’utilisateurs, les logiciels que vous pouvez utiliser à partir de n’importe quel navigateur seront une victoire en soi pour l’emporter sur toute maladresse dans l’interface utilisateur. Peut-être que vous ne pouvez pas écrire la plus belle feuille de calcul 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 ajouter des flux de données en direct, ou qui peut vous 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 noms. VisiCalc n’était pas simplement une version micro-ordinateur d’une application mainframe, après tout, c’était un nouveau type d’application.

Électronique populaire, janvier 1975 (détail).

Bien sûr, les applications basées sur le serveur n’ont pas besoin d’être basées sur le Web. Vous pourriez avoir un autre type de client. Mais je suis à peu près sûr que c’est une mauvaise idée. Ce serait très pratique si vous pouviez supposer que tout le monde installe votre client - si pratique que vous pourriez facilement vous convaincre qu’ils le feraient tous. Mais s’ils ne le font pas, vous êtes démuni.

Parce que le logiciel basé sur le Web ne suppose rien du client, il fonctionnera partout où le Web fonctionne. C’est un grand avantage déjà prêt, et l’avantage augmentera à mesure que de nouveaux appareils web prolifèrent. Les utilisateurs vous aimeront parce que votre logiciel fonctionne tout simplement, et votre vie sera plus facile parce que vous n’aurez pas à le modifier pour chaque nouveau client 17.

J’ai l’impression d’avoir observé l’évolution du Web aussi étroitement que n’importe qui, et je ne peux pas prédire ce qui va se passer avec les clients. La convergence arrive probablement, mais où ?

Comment tout cela se passera-t-il ? Je ne sais pas. Et vous n’avez pas besoin de savoir si vous pariez sur des applications Web. Personne ne peut briser cela sans casser la navigation. Le Web n’est peut-être pas le seul moyen de fournir des logiciels, mais c’est un logiciel qui fonctionne maintenant et qui continuera à fonctionner pendant longtemps. Les applications Web sont bon marché à développer, et faciles à fournir même pour la plus petite start-up. C’est beaucoup de travail, et d’un genre particulièrement stressant, mais cela ne fait qu’améliorer les chances pour les startups.

Pourquoi pas

E. B. White s’est amusé à apprendre d’un ami agriculteur que de nombreuses clôtures électrifiées n’ont pas de courant qui les traverse. Les vaches apprennent apparemment à rester loin d’elles, et après cela, vous n’avez pas besoin du courant. « Levez-vous, les vaches ! » Il a écrit. « Prenez votre liberté pendant que les despotes ronflent ! »

Si vous êtes un hacker qui a pensé un jour démarrer une start-up, il y a probablement deux choses qui vous empêchent de le faire. La première est que vous ne savez rien sur les affaires. L’autre est que vous avez peur de la concurrence. Aucune de ces clôtures n’a de courant.

Il n’y a que deux choses que vous devez savoir sur les affaires : construire quelque chose que les utilisateurs aiment et faire plus que ce que vous dépensez. Si vous avez bien compris ces deux, vous aurez une longueur d’avance sur la plupart des startups. Vous pouvez comprendre le reste au fur et à mesure.

Vous ne gagnez peut-être pas au début plus que ce que vous dépensez, mais tant que l’écart se ferme assez rapidement, tout ira bien. Si vous commencez sous-financé, cela encouragera au moins une habitude de frugalité. Moins vous dépensez, plus il est facile de faire plus que vous ne dépensez. Heureusement, il peut être très bon marché de lancer une application Web. Nous avons lancé moins de 10 000 $, et ce serait encore moins cher aujourd’hui. Nous avons dû dépenser des milliers sur un serveur, et des milliers d’autres pour obtenir SSL. (La seule entreprise qui vendait des logiciels SSL à ce moment là était Netscape.) Maintenant, vous pouvez louer un serveur beaucoup plus puissant, avec SSL inclus, pour moins que ce que nous avons payé pour la seule bande passante. Vous pourriez lancer une application Web maintenant pour moins que le coût d’une chaise de bureau de luxe.

En ce qui concerne la construction de quelque chose que les utilisateurs aiment, voici quelques conseils généraux. Commencez par faire quelque chose de propre et de simple que vous voudriez utiliser vous-même. Obtenez une version 1.0 rapidement, puis continuez à améliorer le logiciel, en écoutant attentivement les utilisateurs comme vous le faites. Le client a toujours raison, mais différents clients ont raison sur des choses différentes ; les utilisateurs les moins sophistiqués vous montrent ce dont vous avez besoin pour simplifier et clarifier, et les plus sophistiqués vous disent quelles fonctionnalités vous devez ajouter. La meilleure chose que le logiciel puisse être est facile, mais la façon de le faire est d’obtenir les bonnes valeurs par défaut, et non de limiter les choix des utilisateurs. Ne soyez pas complaisant si le logiciel de vos concurrents est boiteux ; la norme à laquelle comparer votre logiciel est ce qu’il pourrait être, pas ce que vos concurrents actuels ont. Utilisez votre logiciel vous-même, tout le temps. Viaweb était censé être un créateur de boutique en ligne, mais nous l’avons également utilisé pour créer notre propre site. N’écoutez pas les gens du marketing, les concepteurs ou les chefs de produits simplement à cause de leurs titres de poste. S’ils ont de bonnes idées, utilisez-les, mais c’est à vous de décider ; le logiciel doit être conçu par des hackers qui comprennent le design, pas par des concepteurs qui en savent un peu plus sur le logiciel. Si vous ne pouvez pas concevoir un logiciel aussi bien que l’implémenter, ne démarrez pas une start-up.

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

Bill Gates, 1977.

Je ne veux pas dénigrer Yahoo. Ils avaient de bons hackers, et la haute direction était de vrais butt-kickers. Pour une grande compagnie, ils étaient exceptionnels. Mais ils n’étaient encore qu’environ un dixième aussi productifs qu’une petite start-up. Aucune grande entreprise ne peut faire beaucoup mieux que cela. Ce qui est effrayant à propos de Microsoft, c’est qu’une entreprise aussi grande peut développer des logiciels. Ils sont comme une montagne qui peut marcher.

Ne vous faites pas intimider. Vous pouvez faire autant que Microsoft ne peut pas faire et ce que vous ne pouvez pas faire et que Microsoft peut. 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 basées sur le Web. Vous n’avez pas besoin de faire des offres de licence, ou d’obtenir de l’espace sur les étagères dans les magasins de détail, ou de s’époumoner pour que votre application soit fournie avec le système d’exploitation. Vous pouvez fournir des logiciels directement au navigateur, et personne ne peut s’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 Gates l’est, parce qu’il était vous une fois, en 1975, la dernière fois qu’une nouvelle façon de livrer des logiciels est apparue.

  1. Réalisant que beaucoup d’argent est dans les services, les entreprises qui construisent des clients légers ont généralement essayé de combiner le matériel avec un service en ligne. Cette approche n’a pas bien fonctionné, en partie parce que vous avez besoin de deux types d’entreprises différentes pour construire des produits électroniques grand public et gérer un service en ligne, et en partie parce que les utilisateurs détestent l’idée. Donner la poignée et faire de l’argent sur les lames peut fonctionner pour Gillette, mais un rasoir est un engagement moins important qu’un terminal web.

    Les fabricants de téléphones portables sont satisfaits de vendre du matériel sans essayer de plafonner également les revenus du service. Cela devrait probablement aussi être le modèle pour les clients Internet. Si quelqu’un venait de vendre une jolie petite boîte avec un navigateur Web que vous pourriez utiliser pour vous connecter via n’importe quel FAI, chaque technophobe du parc en achèterait une. 

  2. La sécurité dépend toujours plus de la volonté de ne pas se tromper que de n’importe quelle décision de conception mais la nature des logiciels basés sur des serveurs incitera les développeurs à accorder plus d’attention au fait de ne pas se tromper. La compromission d’un serveur pourrait causer de tels dommages que les ASP (qui veulent rester en activité) sont susceptibles de faire attention à la 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 le serveur. Les applets nous semblaient une idée à l’ancienne. Télécharger des programmes à exécuter sur le client ? Plus simple, il suffit 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 cette fosse de goudron. Peu semblent s’en être échappés vivants. 

  4. Ce point est dû à Trevor Blackwell, qui ajoute : « Le coût des logiciels d’écriture augmente plus que linéairement avec sa taille. Peut-être est-ce principalement dû à la correction d’anciens bugs, et le coût peut être plus linéaire si tous les bugs sont trouvés rapidement. » 

  5. Le type de bugs le plus difficile à trouver peut être une variante du bogue composé où un bogue compense un autre. Lorsque vous corrigez un bug, l’autre devient visible. Mais il semblera que la solution soit en faute, puisque c’est la dernière chose que vous avez changée. 

  6. Au sein de Viaweb, nous avons déjà eu un concours pour décrire la pire chose à propos de notre logiciel. Deux personnes du support client sont à égalité pour le premier prix avec des entrées dont je frissonne encore de me rappeler. Nous avons résolu les deux problèmes immédiatement. 

  7. Robert Morris a écrit le système de commande, que les acheteurs utilisaient pour placer 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, 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 Common Lisp. 

  8. J’utilise « exponentiellement » au sens familier ici. Correctement, il devrait être « polynomialement ». 

  9. La discrimination par les prix est si répandue que j’ai été surpris de constater qu’elle a été interdite aux États-Unis par la loi Robinson-Patman de 1936. Cette loi ne semble pas être vigoureusement appliquée. 

  10. Dans No Logo, Naomi Klein dit que les marques de vêtements favorisées par les « jeunes urbains » n’essaient pas trop d’empêcher le vol à l’étalage parce que dans leur marché cible, les voleurs à l’étalage sont également les leaders de la mode. 

  11. Les entreprises se demandent souvent ce qu’elles doivent externaliser et ce qu’elles ne doivent pas faire. Une réponse possible : externaliser tout travail qui n’est pas directement exposé à la pression concurrentielle, car l’externalisation l’exposera ainsi à la pression concurrentielle. (Je veux dire « externaliser » dans le sens d’embaucher une autre entreprise pour le faire, et non dans le sens plus spécifique de l’embauche d’une entreprise étrangère.) 

  12. 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 (la plupart du temps la nuit) pour faire une version plus puissante écrite en langage machine 6502. Dan était à la Harvard Business School à l’époque et Bob avait nominalement un travail de jour pour écrire un logiciel. « Il n’y avait pas de grand risque à faire des affaires », m’a dit Bob. « S’il a échoué, il a échoué. Ce n’est pas grand-chose. » 

  13. Ce n’est pas aussi facile que je le fais paraître. Il a fallu beaucoup de temps pour que le bouche à oreille se mette en marche, et nous n’avons pas eu beaucoup de couverture médiatique jusqu’à ce que nous embauchions Schwartz Communications, probablement la meilleure entreprise de relations publiques de haute technologie de l’entreprise, pour 16 000 $/mois (plus quelques mandats). Cependant, il était vrai que le seul canal important était notre propre site web. 

  14. Si le Mac était si génial, pourquoi a-t-il perdu ? Coût, encore une fois. Microsoft s’est concentré sur le secteur des logiciels et a déclenché un essaim 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. (Et il n’a pas encore perdu. Si Apple devait transformer l’iPod en un téléphone portable avec un navigateur Web, Microsoft aurait de gros ennuis.) 

  15. Une chose qui aiderait les applications basées sur le Web, et aiderait à l’autre génération de logiciels d’être éclipsée par Microsoft, serait un bon navigateur open source. Un petit navigateur rapide serait une bonne chose en soi, et encouragerait les entreprises à construire de petits appareils Web.

    Mieux que ce soit, un bon navigateur open source pourrait faire évoluer HTTP et HTML (comme par ex. Perl a). Vous vous souvenez quand chaque version de Netscape ajoutait de nouvelles fonctionnalités au HTML ? Pourquoi cela a-t-il été arrêté ?

    Cela aiderait grandement les applications Web à faire la distinction entre la sélection d’un lien et son suivi ; tout ce dont vous auriez besoin pour le faire serait une amélioration triviale de HTTP, pour permettre plusieurs URL dans une demande. Les menus en cascade seraient également bons. Si vous voulez changer le monde, écrivez une nouvelle mosaïque. Vous pensez qu’il est trop tard ? En 1998, beaucoup de gens pensaient qu’il était trop tard pour lancer un nouveau moteur de recherche, mais Google leur a prouvé qu’ils avaient tort. Il y a toujours de la place pour quelque chose de nouveau si c’est beaucoup mieux. 

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

    « J’irais plus loin en disant que parce que les logiciels sur serveur sont si durs pour les programmeurs, cela provoque un changement économique fondamental par rapport aux grandes grandes grandes grandes. 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’agit de leur propre entreprise. Les entreprises de logiciels peuvent embaucher des personnes qualifiées pour travailler dans un environnement pas trop exigeant, et peuvent embaucher des personnes non qualifiées pour supporter des difficultés, mais elles ne peuvent pas embaucher des personnes hautement qualifiées pour se casser le cul. Étant donné que le capital n’est plus nécessaire, les grandes sociétés n’ont pas grand-chose à apporter à la table. » 

  17. Je n’utiliserais même pas Javascript, si j’étais vous ; Viaweb ne l’a pas fait. La plupart du Javascript que je vois sur le Web n’est pas nécessaire, et une grande partie se casse. Et quand vous commencez à pouvoir parcourir des pages Web réelles sur votre téléphone portable ou votre PDA (ou votre grille-pain), qui sait s’ils le tiendront même en charge ?