De Andere Weg Vooruit

September 2001

(Dit artikel legt uit waarom veel van de volgende generatie software server-gebaseerd zal zijn, wat dat betekent voor programmeurs, en waarom dit nieuwe soort software een grote kans is voor startups. Het is gebaseerd op een lezing bij BBN Labs.)

In de zomer van 1995 besloten mijn vriend Robert Morris en ik een startup te beginnen. De PR-campagne rond de IPO van Netscape was toen in volle gang, en er was veel publiciteit over online handel. Destijds waren er misschien dertig echte winkels op het Web, allemaal met de hand gemaakt. Als er veel online winkels zouden komen, zou er software nodig zijn om ze te maken, dus besloten we die te schrijven.

De eerste week of zo waren we van plan dit een gewone desktopapplicatie te maken. Toen kregen we op een dag het idee om de software op onze webserver te laten draaien, met de browser als interface. We probeerden de software te herschrijven om via het web te werken, en het was duidelijk dat dit de juiste weg was. Als we onze software op de server zouden laten draaien, zou dat veel gemakkelijker zijn voor de gebruikers en ook voor ons.

Dit bleek een goed plan te zijn. Nu, als Yahoo Store, is deze software de meest populaire online winkelbouwer, met ongeveer 14.000 gebruikers.

Toen we Viaweb begonnen, begreep bijna niemand wat we bedoelden toen we zeiden dat de software op de server draaide. Pas toen Hotmail een jaar later werd gelanceerd, begonnen mensen het te snappen. Nu weet iedereen dat dit een geldige aanpak is. Er is nu een naam voor wat we waren: een Application Service Provider, of ASP.

Ik denk dat veel van de volgende generatie software volgens dit model zal worden geschreven. Zelfs Microsoft, die het meeste te verliezen heeft, lijkt de onvermijdelijkheid te zien van het verplaatsen van sommige dingen van de desktop. Als software van de desktop naar servers verhuist, betekent dit een heel andere wereld voor ontwikkelaars. Dit artikel beschrijft de verrassende dingen die we zagen, als een van de eerste bezoekers van deze nieuwe wereld. Voor zover software naar servers verhuist, is wat ik hier beschrijf de toekomst.

Het volgende?

Als we terugkijken op het tijdperk van desktopsoftware, denk ik dat we ons zullen verbazen over de ongemakken die mensen hebben getolereerd, net zoals we ons nu verbazen over wat vroege autobezitters hebben getolereerd. De eerste twintig of dertig jaar moest je een auto-expert zijn om een auto te bezitten. Maar auto's waren zo'n grote winst dat veel mensen die geen auto-experts waren, ze ook wilden hebben.

Computers bevinden zich nu in deze fase. Als je een desktopcomputer bezit, leer je veel meer dan je wilde weten over wat erin gebeurt. Maar meer dan de helft van de huishoudens in de VS bezit er een. Mijn moeder heeft een computer die ze gebruikt voor e-mail en voor het bijhouden van rekeningen. Ongeveer een jaar geleden was ze geschokt toen ze een brief van Apple ontving, waarin haar een korting werd aangeboden op een nieuwe versie van het besturingssysteem. Er is iets mis als een zestigjarige vrouw die een computer wil gebruiken voor e-mail en rekeningen moet nadenken over het installeren van nieuwe besturingssystemen. Gewone gebruikers zouden niet eens de woorden "besturingssysteem" moeten kennen, laat staan "stuurprogramma" of "patch".

Er is nu een andere manier om software te leveren die gebruikers zal behoeden voor het worden van systeembeheerders. Webgebaseerde applicaties zijn programma's die op webservers draaien en webpagina's als gebruikersinterface gebruiken. Voor de gemiddelde gebruiker zal dit nieuwe soort software gemakkelijker, goedkoper, mobieler, betrouwbaarder en vaak krachtiger zijn dan desktopsoftware.

Met webgebaseerde software hoeven de meeste gebruikers nergens aan te denken, behalve aan de applicaties die ze gebruiken. Al het rommelige, veranderlijke spul zal ergens op een server staan, onderhouden door het soort mensen dat daar goed in is. En dus heb je doorgaans geen computer nodig, per se, om software te gebruiken. Alles wat je nodig hebt, is iets met een toetsenbord, een scherm en een webbrowser. Misschien heeft het draadloze internettoegang. Misschien is het ook je mobiele telefoon. Wat het ook is, het zal consumentenelektronica zijn: iets dat ongeveer $ 200 kost, en dat mensen voornamelijk kiezen op basis van hoe de behuizing eruitziet. Je betaalt meer voor internetdiensten dan voor de hardware, net zoals je nu doet met telefoons. [1]

Het duurt ongeveer een tiende van een seconde om een klik naar de server en terug te krijgen, dus gebruikers van zwaar interactieve software, zoals Photoshop, zullen nog steeds de berekeningen op de desktop willen laten plaatsvinden. Maar als je kijkt naar het soort dingen waar de meeste mensen computers voor gebruiken, zou een vertraging van een tiende van een seconde geen probleem zijn. Mijn moeder heeft niet echt een desktopcomputer nodig, en er zijn veel mensen zoals zij.

De winst voor gebruikers

In de buurt van mijn huis staat een auto met een bumpersticker waarop staat "liever dood dan ongemak". De meeste mensen, de meeste tijd, zullen de keuze maken die het minste werk vereist. Als webgebaseerde software wint, zal dat zijn omdat het gemakkelijker is. En het lijkt erop dat het dat zal zijn, zowel voor gebruikers als voor ontwikkelaars.

Om een puur webgebaseerde applicatie te gebruiken, heb je alleen een browser nodig die verbonden is met internet. Je kunt dus overal een webgebaseerde applicatie gebruiken. Wanneer je software op je desktopcomputer installeert, kun je die alleen op die computer gebruiken. Nog erger, je bestanden zitten vast op die computer. Het ongemak van dit model wordt steeds duidelijker naarmate mensen wennen aan netwerken.

Het dunne uiteinde van de wig hier was webgebaseerde e-mail. Miljoenen mensen realiseren zich nu dat je toegang moet hebben tot e-mailberichten, waar je ook bent. En als je je e-mail kunt zien, waarom dan niet je agenda? Als je een document met je collega's kunt bespreken, waarom kun je het dan niet bewerken? Waarom zou een deel van je gegevens vastzitten op een computer die op een verre bureau staat?

Het hele idee van "jouw computer" verdwijnt, en wordt vervangen door "jouw gegevens". Je zou toegang moeten hebben tot je gegevens vanaf elke computer. Of beter gezegd, elke client, en een client hoeft geen computer te zijn.

Clients mogen geen gegevens opslaan; ze moeten als telefoons zijn. Sterker nog, ze kunnen telefoons worden, of vice versa. En naarmate clients kleiner worden, heb je nog een reden om je gegevens er niet op te bewaren: iets dat je bij je draagt, kan verloren gaan of gestolen worden. Je PDA in een taxi achterlaten is als een schijfcrash, behalve dat je gegevens aan iemand anders worden overhandigd in plaats van te worden verdampt.

Met puur webgebaseerde software worden noch je gegevens, noch de applicaties op de client bewaard. Je hoeft dus niets te installeren om het te gebruiken. En als er geen installatie is, hoef je je geen zorgen te maken dat de installatie misgaat. Er kunnen geen incompatibiliteiten zijn tussen de applicatie en je besturingssysteem, omdat de software niet op je besturingssysteem draait.

Omdat het geen installatie nodig heeft, zal het gemakkelijk en gebruikelijk zijn om webgebaseerde software te proberen voordat je het "koopt". Je zou moeten verwachten elke webgebaseerde applicatie gratis te kunnen proefrijden, gewoon door naar de site te gaan waar deze wordt aangeboden. Bij Viaweb was onze hele site als een grote pijl die gebruikers naar de proefrit wees.

Na het proberen van de demo, moet het aanmelden voor de service niets meer vereisen dan het invullen van een kort formulier (hoe korter, hoe beter). En dat zou het laatste werk moeten zijn dat de gebruiker hoeft te doen. Met webgebaseerde software zou je nieuwe releases moeten krijgen zonder extra te betalen, of zonder werk te verrichten, of mogelijk zelfs zonder het te weten.

Upgrades zullen niet de grote schokken zijn die ze nu zijn. Na verloop van tijd zullen applicaties stilzwijgend krachtiger worden. Dit zal enige inspanning van de kant van de ontwikkelaars vergen. Ze zullen software moeten ontwerpen zodat deze kan worden bijgewerkt zonder de gebruikers te verwarren. Dat is een nieuw probleem, maar er zijn manieren om het op te lossen.

Met webgebaseerde applicaties gebruikt iedereen dezelfde versie, en bugs kunnen worden opgelost zodra ze worden ontdekt. Webgebaseerde software zou dus veel minder bugs moeten hebben dan desktopsoftware. Bij Viaweb hadden we waarschijnlijk nooit tien bekende bugs tegelijk. Dat is ordes van grootte beter dan desktopsoftware.

Webgebaseerde applicaties kunnen door meerdere mensen tegelijk worden gebruikt. Dit is een duidelijke winst voor collaboratieve applicaties, maar ik wed dat gebruikers dit in de meeste applicaties zullen willen zodra ze zich realiseren dat het mogelijk is. Het zal vaak nuttig zijn om twee mensen hetzelfde document te laten bewerken, bijvoorbeeld. Viaweb liet meerdere gebruikers tegelijkertijd een site bewerken, meer omdat dat de juiste manier was om de software te schrijven dan omdat we verwachtten dat gebruikers dat wilden, maar het bleek dat velen dat wel wilden.

Wanneer je een webgebaseerde applicatie gebruikt, zullen je gegevens veiliger zijn. Schijfcraches zullen niet tot het verleden behoren, maar gebruikers zullen er niet meer over horen. Ze zullen plaatsvinden binnen server farms. En bedrijven die webgebaseerde applicaties aanbieden, zullen daadwerkelijk back-ups maken - niet alleen omdat ze echte systeembeheerders hebben die zich zorgen maken over dergelijke dingen, maar omdat een ASP die de gegevens van mensen verliest, in grote, grote problemen zal komen. Wanneer mensen hun eigen gegevens verliezen bij een schijfcrash, kunnen ze niet zo boos worden, omdat ze alleen zichzelf de schuld kunnen geven. Wanneer een bedrijf hun gegevens voor hen verliest, zullen ze veel bozer worden.

Ten slotte zou webgebaseerde software minder kwetsbaar moeten zijn voor virussen. Als de client niets anders draait dan een browser, is er minder kans op het uitvoeren van virussen, en geen lokale gegevens om te beschadigen. En een programma dat de servers zelf aanvalt, zou ze zeer goed verdedigd vinden. [2]

Voor gebruikers zal webgebaseerde software minder stressvol zijn. Ik denk dat als je in de gemiddelde Windows-gebruiker zou kijken, je een enorme en grotendeels onbenutte wens zou vinden naar software die aan die beschrijving voldoet. Ontketend, zou het een krachtige kracht kunnen zijn.

Stad van Code

Voor ontwikkelaars is het meest opvallende verschil tussen webgebaseerde en desktopsoftware dat een webgebaseerde applicatie geen enkel stuk code is. Het zal een verzameling programma's van verschillende typen zijn in plaats van een enkele grote binaire. En dus is het ontwerpen van webgebaseerde software als het ontwerpen van een stad in plaats van een gebouw: naast gebouwen heb je wegen, straatnaamborden, nutsvoorzieningen, politie- en brandweerdiensten, en plannen voor zowel groei als diverse soorten rampen nodig.

Bij Viaweb omvatte software redelijk grote applicaties waarmee gebruikers direct communiceerden, programma's die die programma's gebruikten, programma's die constant op de achtergrond draaiden en op zoek waren naar problemen, programma's die probeerden dingen opnieuw te starten als ze kapot gingen, programma's die af en toe draaiden om statistieken te compileren of indexen voor zoekopdrachten te bouwen, programma's die we expliciet draaiden om bronnen op te ruimen of gegevens te verplaatsen of te herstellen, programma's die zich voordeden als gebruikers (om prestaties te meten of bugs bloot te leggen), programma's voor het diagnosticeren van netwerkproblemen, programma's voor het maken van back-ups, interfaces met externe services, software die een indrukwekkende verzameling meters aanstuurde die real-time serverstatistieken weergeefden (een hit bij bezoekers, maar ook onmisbaar voor ons), aanpassingen (inclusief bugfixes) aan open-source software, en een groot aantal configuratiebestanden en instellingen. Trevor Blackwell schreef een spectaculair programma voor het verplaatsen van winkels naar nieuwe servers door het hele land, zonder ze af te sluiten, nadat we door Yahoo waren gekocht. Programma's paginering ons, stuurden faxen en e-mails naar gebruikers, voerden transacties uit met creditcardprocessors en communiceerden met elkaar via sockets, pipes, http-verzoeken, ssh, udp-pakketten, gedeeld geheugen en bestanden. Sommige van Viaweb bestonden zelfs uit de afwezigheid van programma's, aangezien een van de sleutels tot Unix-beveiliging is om geen onnodige hulpprogramma's te draaien die mensen zouden kunnen gebruiken om in uw servers in te breken.

Het eindigde niet met software. We besteedden veel tijd aan het nadenken over serverconfiguraties. We bouwden de servers zelf, uit componenten - deels om geld te besparen, en deels om precies te krijgen wat we wilden. We moesten nadenken over de vraag of onze upstream ISP snelle genoeg verbindingen had met alle backbones. We hebben gedate RAID-leveranciers.

Maar hardware is niet alleen iets om je zorgen over te maken. Wanneer je het controleert, kun je meer doen voor gebruikers. Met een desktopapplicatie kun je bepaalde minimale hardware specificeren, maar je kunt er geen extra bij doen. Als je de servers beheert, kun je in één stap al je gebruikers in staat stellen om mensen te pagineren, of faxen te sturen, of commando's per telefoon te sturen, of creditcards te verwerken, enz., gewoon door de relevante hardware te installeren. We zochten altijd naar nieuwe manieren om functies met hardware toe te voegen, niet alleen omdat het gebruikers beviel, maar ook als een manier om ons te onderscheiden van concurrenten die (hetzij omdat ze desktopsoftware verkochten, of webgebaseerde applicaties via ISP's doorverkochten) geen directe controle over de hardware hadden.

Omdat de software in een webgebaseerde applicatie een verzameling programma's zal zijn in plaats van een enkele binaire, kan deze in een willekeurig aantal verschillende talen worden geschreven. Wanneer je desktopsoftware schrijft, word je praktisch gedwongen om de applicatie in dezelfde taal te schrijven als het onderliggende besturingssysteem - wat C en C++ betekent. En dus werden deze talen (vooral onder niet-technische mensen zoals managers en VC's) beschouwd als de talen voor "serieuze" softwareontwikkeling. Maar dat was slechts een artefact van de manier waarop desktopsoftware moest worden geleverd. Voor servergebaseerde software kun je elke gewenste taal gebruiken. [3] Vandaag de dag gebruiken veel van de top hackers talen die ver verwijderd zijn van C en C++: Perl, Python, en zelfs Lisp.

Met servergebaseerde software kan niemand je vertellen welke taal je moet gebruiken, omdat je het hele systeem beheert, tot aan de hardware toe. Verschillende talen zijn goed voor verschillende taken. Je kunt degene gebruiken die het beste is voor elk. En als je concurrenten hebt, betekent "kunnen" "moeten" (we komen hier later op terug), want als je niet profiteert van deze mogelijkheid, zullen je concurrenten dat wel doen.

De meeste van onze concurrenten gebruikten C en C++, en dit maakte hun software zichtbaar inferieur omdat ze (onder andere) geen manier hadden om de statelessness van CGI-scripts te omzeilen. Als je iets zou veranderen, moesten alle wijzigingen op één pagina plaatsvinden, met een Update-knop onderaan. Zoals ik elders heb geschreven, konden we door Lisp te gebruiken, dat veel mensen nog steeds als een onderzoekstaal beschouwen, de Viaweb-editor meer laten functioneren als desktopsoftware.

Releases

Een van de belangrijkste veranderingen in deze nieuwe wereld is de manier waarop je releases doet. In de desktopsoftware-business is het doen van een release een enorm trauma, waarbij het hele bedrijf zweet en zich inspant om een enkel, gigantisch stuk code uit te brengen. Duidelijke vergelijkingen dringen zich op, zowel met het proces als met het resulterende product.

Met servergebaseerde software kun je wijzigingen aanbrengen bijna zoals je zou doen in een programma dat je voor jezelf schrijft. Je brengt software uit als een reeks incrementele wijzigingen in plaats van een incidentele grote explosie. Een typisch desktopsoftwarebedrijf doet misschien één of twee releases per jaar. Bij Viaweb deden we vaak drie tot vijf releases per dag.

Wanneer je overschakelt op dit nieuwe model, realiseer je je hoeveel softwareontwikkeling wordt beïnvloed door de manier waarop deze wordt uitgebracht. Veel van de vervelendste problemen die je ziet in de desktopsoftware-business zijn te wijten aan de catastrofale aard van releases.

Als je maar één nieuwe versie per jaar uitbrengt, heb je de neiging om bugs groothandels aan te pakken. Enige tijd voor de releasedatum stel je een nieuwe versie samen waarin de helft van de code is uitgescheurd en vervangen, wat talloze bugs introduceert. Vervolgens stapt een team van QA-mensen binnen en begint ze te tellen, en de programmeurs werken de lijst af en lossen ze op. Ze komen over het algemeen niet aan het einde van de lijst, en inderdaad, niemand weet waar het einde is. Het is als het vissen van puin uit een vijver. Je weet nooit echt wat er in de software gebeurt. In het beste geval eindig je met een soort statistische correctheid.

Met servergebaseerde software is het grootste deel van de verandering klein en incrementeel. Dat alleen al is minder waarschijnlijk om bugs te introduceren. Het betekent ook dat je weet wat je het meest zorgvuldig moet testen als je software gaat uitbrengen: het laatste dat je hebt veranderd. Je krijgt een veel stevigere grip op de code. Als algemene regel weet je wat erin gebeurt. Je hebt de broncode niet uit je hoofd geleerd, natuurlijk, maar als je de bron leest, doe je het als een piloot die het instrumentenpaneel scant, niet als een detective die een mysterie probeert te ontrafelen.

Desktopsoftware kweekt een zekere fatalisme over bugs. Je weet dat je iets verzendt dat vol zit met bugs, en je hebt zelfs mechanismen opgezet om dit te compenseren (bijv. patch releases). Dus waarom zou je je zorgen maken over een paar meer? Al snel breng je hele functies uit waarvan je weet dat ze kapot zijn. Apple deed dit eerder dit jaar. Ze voelden de druk om hun nieuwe OS uit te brengen, waarvan de releasedatum al vier keer was uitgesteld, maar sommige software (ondersteuning voor cd's en dvd's) was nog niet klaar. De oplossing? Ze brachten het OS uit zonder de onvoltooide delen, en gebruikers moesten ze later installeren.

Met webgebaseerde software hoef je nooit software uit te brengen voordat deze werkt, en je kunt deze uitbrengen zodra deze werkt.

De industrie-veteraan denkt misschien: het is een mooi klinkend idee om te zeggen dat je nooit software hoeft uit te brengen voordat deze werkt, maar wat gebeurt er als je hebt beloofd een nieuwe versie van je software te leveren op een bepaalde datum? Met webgebaseerde software zou je zo'n belofte niet doen, omdat er geen versies zijn. Je software verandert geleidelijk en continu. Sommige wijzigingen kunnen groter zijn dan andere, maar het idee van versies past gewoon niet natuurlijk bij webgebaseerde software.

Als iemand zich Viaweb herinnert, klinkt dit misschien vreemd, omdat we altijd nieuwe versies aankondigden. Dit werd volledig gedaan voor PR-doeleinden. De vakpers, zo leerden we, denkt in versienummers. Ze geven je grote dekking voor een grote release, wat een nieuw eerste cijfer op het versienummer betekent, en over het algemeen hooguit een paragraaf voor een puntrelease, wat een nieuw cijfer na de decimale punt betekent.

Sommige van onze concurrenten boden desktopsoftware aan en hadden feitelijk versienummers. En voor deze releases, het enkele feit waarvan ons leek te bewijzen dat ze achterlijk waren, kregen ze allerlei publiciteit. We wilden niet achterblijven, dus begonnen we ook versienummers aan onze software te geven. Wanneer we wat publiciteit wilden, maakten we een lijst van alle functies die we hadden toegevoegd sinds de laatste "release", plakten we een nieuw versienummer op de software en gaven we een persbericht uit waarin stond dat de nieuwe versie onmiddellijk beschikbaar was. Verrassend genoeg heeft niemand ons ooit op de bon geslingerd.

Tegen de tijd dat we werden gekocht, hadden we dit drie keer gedaan, dus we waren op Versie 4. Versie 4.1 als ik me goed herinner. Nadat Viaweb Yahoo Store werd, was er geen wanhopige behoefte meer aan publiciteit, dus hoewel de software bleef evolueren, werd het hele idee van versienummers stilzwijgend gedropt.

Bugs

Het andere grote technische voordeel van webgebaseerde software is dat je de meeste bugs kunt reproduceren. Je hebt de gegevens van de gebruikers daar op je schijf. Als iemand je software breekt, hoef je niet te raden wat er aan de hand is, zoals bij desktopsoftware: je zou de fout moeten kunnen reproduceren terwijl ze aan de telefoon zijn. Je weet het misschien al, als je code hebt ingebouwd om fouten op te merken in je applicatie.

Webgebaseerde software wordt de klok rond gebruikt, dus alles wat je doet, wordt onmiddellijk door de mangel gehaald. Bugs duiken snel op.

Softwarebedrijven worden soms beschuldigd van het laten debuggen van hun software door de gebruikers. En dat is precies wat ik bepleit. Voor webgebaseerde software is dat eigenlijk een goed plan, omdat de bugs minder zijn en voorbijgaand. Wanneer je software geleidelijk uitbrengt, krijg je sowieso veel minder bugs. En wanneer je fouten kunt reproduceren en wijzigingen onmiddellijk kunt uitbrengen, kun je de meeste bugs vinden en oplossen zodra ze verschijnen. We hadden nooit genoeg bugs tegelijk om ons bezig te houden met een formeel bug-tracking systeem.

Je moet wijzigingen testen voordat je ze uitbrengt, natuurlijk, dus er zouden geen grote bugs mogen worden uitgebracht. Die paar die onvermijdelijk door de mazen glippen, zullen grensgevallen betreffen en alleen de paar gebruikers beïnvloeden die ze tegenkomen voordat iemand belt om te klagen. Zolang je bugs meteen oplost, zijn de netto-effecten, voor de gemiddelde gebruiker, veel minder bugs. Ik betwijfel of de gemiddelde Viaweb-gebruiker ooit een bug heeft gezien.

Het oplossen van verse bugs is gemakkelijker dan het oplossen van oude. Het is meestal vrij snel om een bug te vinden in code die je net hebt geschreven. Wanneer het opduikt, weet je vaak wat er mis is voordat je zelfs naar de bron kijkt, omdat je er al onbewust mee bezig was. Het oplossen van een bug in iets dat je zes maanden geleden hebt geschreven (het gemiddelde geval als je één keer per jaar uitbrengt) is veel meer werk. En omdat je de code minder goed begrijpt, zul je deze waarschijnlijk op een lelijke manier oplossen, of zelfs meer bugs introduceren. [4]

Wanneer je bugs vroegtijdig vangt, krijg je ook minder samengestelde bugs. Samengestelde bugs zijn twee afzonderlijke bugs die elkaar beïnvloeden: je struikelt op de trap, en als je naar de trapleuning grijpt, komt deze los in je hand. In software is dit soort bug het moeilijkst te vinden, en heeft ook de ergste gevolgen. [5] De traditionele "alles breken en dan de bugs eruit filteren" aanpak levert inherent veel samengestelde bugs op. En software die in een reeks kleine wijzigingen wordt uitgebracht, neigt daar inherent niet toe. De vloeren worden voortdurend schoongeveegd van losse voorwerpen die later ergens in kunnen blijven haken.

Het helpt als je een techniek gebruikt die functioneel programmeren heet. Functioneel programmeren betekent het vermijden van neveneffecten. Het is iets dat je vaker ziet in onderzoeksartikelen dan in commerciële software, maar voor webgebaseerde applicaties blijkt het echt nuttig te zijn. Het is moeilijk om volledige programma's als puur functionele code te schrijven, maar je kunt er aanzienlijke delen van maken. Het maakt die delen van je software gemakkelijker te testen, omdat ze geen staat hebben, en dat is erg handig in een situatie waarin je voortdurend kleine aanpassingen maakt en test. Ik schreef een groot deel van de editor van Viaweb in deze stijl, en we maakten onze scripttaal, RTML, een puur functionele taal.

Mensen uit de desktopsoftware-business zullen dit moeilijk geloven, maar bij Viaweb werden bugs bijna een spel. Aangezien de meeste uitgebrachte bugs grensgevallen betroffen, waren de gebruikers die ze tegenkwamen waarschijnlijk geavanceerde gebruikers, die de grenzen opzochten. Geavanceerde gebruikers zijn vergevingsgezinder voor bugs, vooral omdat je ze waarschijnlijk hebt geïntroduceerd tijdens het toevoegen van een functie waar ze om vroegen. Sterker nog, omdat bugs zeldzaam waren en je geavanceerde dingen moest doen om ze te zien, waren geavanceerde gebruikers vaak trots om er een te vangen. Ze belden de ondersteuning met een geest van triomf dan van woede, alsof ze punten hadden gescoord op ons.

Ondersteuning

Wanneer je fouten kunt reproduceren, verandert dit je aanpak van klantenservice. Bij de meeste softwarebedrijven wordt ondersteuning aangeboden als een manier om klanten zich beter te laten voelen. Ze bellen je ofwel over een bekende bug, of ze doen gewoon iets verkeerd en jij moet uitzoeken wat. In beide gevallen is er niet veel dat je van hen kunt leren. En dus heb je de neiging om supportgesprekken te zien als een last die je zo veel mogelijk van je ontwikkelaars wilt isoleren.

Dit was niet hoe dingen werkten bij Viaweb. Bij Viaweb was ondersteuning gratis, omdat we van klanten wilden horen. Als iemand een probleem had, wilden we het meteen weten, zodat we de fout konden reproduceren en een oplossing konden uitbrengen.

Dus bij Viaweb stonden de ontwikkelaars altijd in nauw contact met de ondersteuning. De klantenservice medewerkers stonden ongeveer tien meter van de programmeurs vandaan, en wisten dat ze alles konden onderbreken met een melding van een echte bug. We verlieten een bestuursvergadering om een ernstige bug op te lossen.

Onze aanpak van ondersteuning maakte iedereen gelukkiger. De klanten waren verheugd. Stel je voor hoe het zou voelen om een supportlijn te bellen en behandeld te worden als iemand die belangrijk nieuws brengt. De klantenservice medewerkers vonden het leuk omdat ze de gebruikers konden helpen, in plaats van scripts voor te lezen. En de programmeurs vonden het leuk omdat ze bugs konden reproduceren in plaats van alleen vage rapporten uit tweede hand te horen.

Ons beleid om bugs on-the-fly op te lossen, veranderde de relatie tussen klantenservice medewerkers en hackers. Bij de meeste softwarebedrijven zijn supportmedewerkers onderbetaalde menselijke schilden, en hackers zijn kleine kopieën van God de Vader, scheppers van de wereld. Wat de procedure voor het melden van bugs ook is, het is waarschijnlijk eenrichtingsverkeer: supportmedewerkers die over bugs horen, vullen een formulier in dat uiteindelijk (mogelijk via QA) aan programmeurs wordt doorgegeven, die het op hun takenlijst zetten. Het was heel anders bij Viaweb. Binnen een minuut nadat ze van een bug van een klant hadden gehoord, konden de supportmedewerkers naast een programmeur staan die hoorde zeggen "Shit, je hebt gelijk, het is een bug." Het verheugde de supportmedewerkers om dat "je hebt gelijk" van de hackers te horen. Ze brachten ons bugs met dezelfde verwachtingsvolle blik als een kat die je een muis brengt die hij net heeft gedood. Het maakte hen ook voorzichtiger bij het beoordelen van de ernst van een bug, omdat hun eer nu op het spel stond.

Nadat we door Yahoo waren gekocht, werden de klantenservice medewerkers ver weg van de programmeurs verplaatst. Pas toen realiseerden we ons dat ze effectief QA en tot op zekere hoogte ook marketing waren. Naast het vangen van bugs, waren ze de bewaarders van de kennis van vagere, bug-achtige dingen, zoals functies die gebruikers verwarden. [6] Ze waren ook een soort proxy focusgroep; we konden hen vragen welke van de twee nieuwe functies gebruikers meer wilden, en ze hadden altijd gelijk.

Morale

Het direct kunnen uitbrengen van software is een grote motivator. Vaak als ik naar mijn werk liep, dacht ik aan een wijziging die ik aan de software wilde aanbrengen, en deed ik het die dag. Dit werkte ook voor grotere functies. Zelfs als iets twee weken zou duren om te schrijven (weinig projecten duurden langer), wist ik dat ik het effect in de software kon zien zodra het klaar was.

Als ik een jaar op de volgende release had moeten wachten, zou ik de meeste van deze ideeën hebben opgeborgen, althans voorlopig. Het ding met ideeën is echter dat ze tot meer ideeën leiden. Heb je ooit gemerkt dat als je gaat zitten om iets te schrijven, de helft van de ideeën die erin terechtkomen, ideeën zijn die je tijdens het schrijven hebt bedacht? Hetzelfde gebeurt met software. Werken aan het implementeren van één idee geeft je meer ideeën. Dus het opbergen van een idee kost je niet alleen die vertraging bij de implementatie ervan, maar ook alle ideeën die de implementatie ervan zou hebben opgeleverd. Sterker nog, het opbergen van een idee remt waarschijnlijk zelfs nieuwe ideeën af: als je begint na te denken over een nieuwe functie, vang je een glimp op van de plank en denk je "maar ik heb al veel nieuwe dingen die ik wil doen voor de volgende release."

Wat grote bedrijven doen in plaats van functies te implementeren, is ze plannen. Bij Viaweb liepen we hier soms tegenaan. Investeerders en analisten vroegen ons wat we voor de toekomst hadden gepland. Het eerlijke antwoord zou zijn geweest: we hadden geen plannen. We hadden algemene ideeën over dingen die we wilden verbeteren, maar als we het wisten, zouden we het al hebben gedaan. Wat zouden we de komende zes maanden doen? Wat er ook het grootste voordeel leek. Ik weet niet of ik dit antwoord ooit heb durven geven, maar dat was de waarheid. Plannen zijn slechts een ander woord voor ideeën op de plank. Als we goede ideeën bedachten, implementeerden we ze.

Bij Viaweb, net als bij veel softwarebedrijven, had de meeste code één duidelijke eigenaar. Maar als je iets bezat, bezat je het echt: niemand behalve de eigenaar van een stuk software hoefde een release goed te keuren (of zelfs maar te weten). Er was geen bescherming tegen breuken behalve de angst om er als een idioot uit te zien voor je collega's, en dat was meer dan genoeg. Ik heb misschien de indruk gewekt dat we gewoon onbezonnen code schreven. We gingen snel, maar we dachten heel goed na voordat we software op die servers uitbrachten. En aandacht besteden is belangrijker voor betrouwbaarheid dan langzaam bewegen. Omdat hij nauwlettend aandacht besteedt, kan een Navy-piloot een vliegtuig van 40.000 pond landen met 140 mijl per uur op een dekkend vliegdekschip, 's nachts, veiliger dan de gemiddelde tiener een bagel kan snijden.

Deze manier van software schrijven is natuurlijk een tweesnijdend zwaard. Het werkt veel beter voor een klein team van goede, vertrouwde programmeurs dan voor een groot bedrijf van middelmatige, waar slechte ideeën door commissies worden opgevangen in plaats van door de mensen die ze hadden.

Brooks omgekeerd

Gelukkig vereist webgebaseerde software minder programmeurs. Ik werkte ooit voor een middelgroot desktopsoftwarebedrijf dat meer dan 100 mensen in engineering had. Slechts 13 daarvan waren betrokken bij productontwikkeling. Al de rest werkte aan releases, ports, enzovoort. Met webgebaseerde software heb je (hooguit) alleen die 13 mensen nodig, omdat er geen releases, ports, enzovoort zijn.

Viaweb werd door slechts drie mensen geschreven. [7] Ik stond altijd onder druk om meer mensen aan te nemen, omdat we wilden worden gekocht, en we wisten dat kopers het moeilijk zouden hebben om een hoge prijs te betalen voor een bedrijf met slechts drie programmeurs. (Oplossing: we namen meer aan, maar creëerden nieuwe projecten voor hen.)

Als je software met minder programmeurs kunt schrijven, bespaart dat je meer dan geld. Zoals Fred Brooks opmerkte in The Mythical Man-Month, voegt het toevoegen van mensen aan een project de neiging toe om het te vertragen. Het aantal mogelijke verbindingen tussen ontwikkelaars groeit exponentieel met de grootte van de groep. Hoe groter de groep, hoe meer tijd ze zullen besteden aan vergaderingen over hoe hun software zal samenwerken, en hoe meer bugs ze zullen krijgen door onvoorziene interacties. Gelukkig werkt dit proces ook omgekeerd: naarmate groepen kleiner worden, wordt softwareontwikkeling exponentieel efficiënter. Ik kan me niet herinneren dat de programmeurs bij Viaweb ooit een echte vergadering hebben gehad. We hadden nooit meer te zeggen op enig moment dan we konden zeggen terwijl we naar de lunch liepen.

Als er een nadeel is, is het dat alle programmeurs tot op zekere hoogte ook systeembeheerders moeten zijn. Wanneer je software host, moet iemand de servers in de gaten houden, en in de praktijk zijn de enige mensen die dit goed kunnen doen, degenen die de software hebben geschreven. Bij Viaweb had ons systeem zoveel componenten en veranderde het zo vaak dat er geen duidelijke grens was tussen software en infrastructuur. Het willekeurig vaststellen van zo'n grens zou onze ontwerpkeuzes hebben beperkt. En dus, hoewel we constant hoopten dat op een dag ("over een paar maanden") alles stabiel genoeg zou zijn dat we iemand konden aannemen wiens taak het was om zich alleen met de servers bezig te houden, is het nooit gebeurd.

Ik denk niet dat het anders kan, zolang je het product nog actief ontwikkelt. Webgebaseerde software zal nooit iets zijn dat je schrijft, incheckt en naar huis gaat. Het is een levend ding, dat nu op je servers draait. Een ernstige bug kan niet alleen het proces van één gebruiker crashen; het kan ze allemaal crashen. Als een bug in je code gegevens op de schijf corrumpeert, moet je het oplossen. Enzovoort. We ontdekten dat je de servers niet elke minuut hoeft te bewaken (na het eerste jaar of zo), maar je wilt zeker de dingen die je onlangs hebt veranderd in de gaten houden. Je brengt geen code laat op de avond uit en gaat dan naar huis.

Gebruikers observeren

Met servergebaseerde software ben je dichter bij je code. Je kunt ook dichter bij je gebruikers zijn. Intuit is beroemd om zichzelf voor te stellen aan klanten in winkels en hen te vragen ze naar huis te volgen. Als je ooit iemand hebt zien gebruiken je software voor de eerste keer, weet je welke verrassingen hen te wachten stonden.

Software moet doen wat gebruikers denken dat het zal doen. Maar je kunt geen idee hebben van wat gebruikers zullen denken, geloof me, totdat je ze observeert. En servergebaseerde software geeft je ongekende informatie over hun gedrag. Je bent niet beperkt tot kleine, kunstmatige focusgroepen. Je kunt elke klik van elke gebruiker zien. Je moet zorgvuldig overwegen wat je gaat bekijken, omdat je de privacy van gebruikers niet wilt schenden, maar zelfs de meest algemene statistische steekproeven kunnen zeer nuttig zijn.

Als je de gebruikers op je server hebt, hoef je je bijvoorbeeld niet te verlaten op benchmarks. Benchmarks zijn gesimuleerde gebruikers. Met servergebaseerde software kun je echte gebruikers observeren. Om te beslissen wat je moet optimaliseren, log je gewoon in op een server en kijk je wat alle CPU verbruikt. En je weet ook wanneer je moet stoppen met optimaliseren: we kregen de Viaweb-editor uiteindelijk zo ver dat deze geheugen-gebonden was in plaats van CPU-gebonden, en aangezien er niets was dat we konden doen om de grootte van de gebruikersgegevens te verkleinen (nou ja, niets gemakkelijks), wisten we dat we er net zo goed konden stoppen.

Efficiëntie is belangrijk voor servergebaseerde software, omdat je betaalt voor de hardware. Het aantal gebruikers dat je per server kunt ondersteunen, is de deler van je kapitaalkosten, dus als je je software erg efficiënt kunt maken, kun je concurrenten onderbieden en toch winst maken. Bij Viaweb kregen we de kapitaalkosten per gebruiker naar ongeveer $ 5. Het zou nu minder zijn, waarschijnlijk minder dan de kosten van het verzenden van de eerste maandfactuur. Hardware is nu gratis, als je software redelijk efficiënt is.

Het observeren van gebruikers kan je begeleiden bij ontwerp en optimalisatie. Viaweb had een scripttaal genaamd RTML waarmee geavanceerde gebruikers hun eigen paginastijlen konden definiëren. We ontdekten dat RTML een soort suggestiedoos werd, omdat gebruikers het alleen gebruikten wanneer de vooraf gedefinieerde paginastijlen niet konden doen wat ze wilden. Oorspronkelijk plaatste de editor knoppenbalken over de pagina, bijvoorbeeld, maar nadat een aantal gebruikers RTML hadden gebruikt om knoppen aan de linkerkant te plaatsen zijde, maakten we dat een optie (eigenlijk de standaard) in de vooraf gedefinieerde paginastijlen.

Ten slotte kun je door gebruikers te observeren vaak zien wanneer ze in de problemen zitten. En aangezien de klant altijd gelijk heeft, is dat een teken van iets dat je moet oplossen. Bij Viaweb was de sleutel tot het krijgen van gebruikers de online proefrit. Het was niet zomaar een reeks dia's gemaakt door marketingmensen. In onze proefrit gebruikten gebruikers daadwerkelijk de software. Het duurde ongeveer vijf minuten, en aan het einde hadden ze een echte, werkende winkel gebouwd.

De proefrit was de manier waarop we bijna al onze nieuwe gebruikers kregen. Ik denk dat het voor de meeste webgebaseerde applicaties hetzelfde zal zijn. Als gebruikers succesvol door een proefrit kunnen komen, zullen ze het product leuk vinden. Als ze verward of verveeld raken, zullen ze dat niet doen. Dus alles wat we konden doen om meer mensen door de proefrit te krijgen, zou onze groeipercentage verhogen.

Ik bestudeerde klikpaden van mensen die de proefrit deden en ontdekte dat ze bij een bepaalde stap verward raakten en op de Terug-knop van de browser klikten. (Als je webgebaseerde applicaties probeert te schrijven, zul je merken dat de Terug-knop een van je meest interessante filosofische problemen wordt.) Dus voegde ik een bericht toe op dat punt, waarin ik de gebruikers vertelde dat ze bijna klaar waren, en hen eraan herinnerde de Terug-knop niet te gebruiken. Nog een geweldig ding aan webgebaseerde software is dat je onmiddellijke feedback krijgt van wijzigingen: het aantal mensen dat de proefrit voltooide, steeg onmiddellijk van 60% naar 90%. En aangezien het aantal nieuwe gebruikers een functie was van het aantal voltooide proefritten, steeg onze omzetgroei met 50%, alleen al door die wijziging.

Geld

Begin jaren negentig las ik een artikel waarin iemand zei dat software een abonnementsbedrijf was. In eerste instantie leek dit een zeer cynische uitspraak. Maar later realiseerde ik me dat het de realiteit weerspiegelt: softwareontwikkeling is een doorlopend proces. Ik denk dat het schoner is als je openlijk abonnementskosten in rekening brengt, in plaats van mensen te dwingen nieuwe versies te blijven kopen en installeren, zodat ze je blijven betalen. En gelukkig zijn abonnementen de natuurlijke manier om te factureren voor webgebaseerde applicaties.

Het hosten van applicaties is een gebied waar bedrijven een rol zullen spelen die waarschijnlijk niet door freeware zal worden vervuld. Het hosten van applicaties is veel stress, en heeft echte kosten. Niemand zal het gratis willen doen.

Voor bedrijven zijn webgebaseerde applicaties een ideale inkomstenbron. In plaats van elk kwartaal met een blanco lei te beginnen, heb je een terugkerende inkomstenstroom. Omdat je software geleidelijk evolueert, hoef je je geen zorgen te maken dat een nieuw model zal floppen; er hoeft nooit een nieuw model te zijn, per se, en als je iets aan de software doet dat gebruikers haten, weet je het meteen. Je hebt geen problemen met oninbare rekeningen; als iemand je niet betaalt, kun je de service gewoon uitschakelen. En er is geen mogelijkheid van piraterij.

Dat laatste "voordeel" kan een probleem blijken te zijn. Een zekere mate van piraterij is een voordeel voor softwarebedrijven. Als een gebruiker je software tegen geen enkele prijs zou hebben gekocht, heb je niets verloren als hij een gekopieerde versie gebruikt. Sterker nog, je wint, omdat hij een gebruiker is die helpt je software de standaard te maken - of die later een kopie zou kunnen kopen, wanneer hij van de middelbare school afstudeert.

Wanneer ze kunnen, doen bedrijven graag iets dat prijsdiscriminatie heet, wat betekent dat elke klant zoveel mogelijk wordt aangerekend als hij kan betalen. [8] Software is bijzonder geschikt voor prijsdiscriminatie, omdat de marginale kosten nul benaderen. Dit is waarom sommige software meer kost om op Suns te draaien dan op Intel-boxen: een bedrijf dat Suns gebruikt, is niet geïnteresseerd in geld besparen en kan veilig meer worden aangerekend. Piraterij is effectief de laagste vorm van prijsdiscriminatie. Ik denk dat softwarebedrijven dit begrijpen en opzettelijk een oogje dichtknijpen voor sommige soorten piraterij. [9] Met servergebaseerde software zullen ze een andere oplossing moeten bedenken.

Webgebaseerde software verkoopt goed, vooral in vergelijking met desktopsoftware, omdat het gemakkelijk te kopen is. Je zou denken dat mensen besluiten iets te kopen, en het dan kopen, als twee aparte stappen. Dat dacht ik vóór Viaweb, voor zover ik over de kwestie nadacht. In feite kan de tweede stap zich terugpropageren naar de eerste: als iets moeilijk te kopen is, zullen mensen van gedachten veranderen over of ze het wilden. En vice versa: je verkoopt meer van iets als het gemakkelijk te kopen is. Ik koop meer boeken omdat Amazon bestaat. Webgebaseerde software is gewoon bijna het gemakkelijkste ter wereld om te kopen, vooral als je net een online demo hebt gedaan. Gebruikers hoeven niet veel meer te doen dan een creditcardnummer invoeren. (Laat ze meer doen op eigen risico.)

Soms wordt webgebaseerde software aangeboden via ISP's die als wederverkopers optreden. Dit is een slecht idee. Je moet de servers beheren, omdat je voortdurend zowel hardware als software moet verbeteren. Als je de directe controle over de servers opgeeft, geef je de meeste voordelen van het ontwikkelen van webgebaseerde applicaties op.

Verschillende van onze concurrenten schoten zichzelf in de voet op deze manier - meestal, denk ik, omdat ze werden overweldigd door pakken die enthousiast waren over dit enorme potentiële kanaal, en niet beseften dat het het product dat ze via dat kanaal hoopten te verkopen, zou verpesten. Webgebaseerde software verkopen via ISP's is als sushi verkopen via automaten.

Klanten

Wie zullen de klanten zijn? Bij Viaweb waren het aanvankelijk individuen en kleinere bedrijven, en ik denk dat dit de regel zal zijn bij webgebaseerde applicaties. Dit zijn de gebruikers die klaar zijn om nieuwe dingen te proberen, deels omdat ze flexibeler zijn, en deels omdat ze de lagere kosten van nieuwe technologie willen.

Webgebaseerde applicaties zullen vaak het beste zijn voor grote bedrijven (hoewel ze dat langzaam zullen realiseren). Het beste intranet is het internet. Als een bedrijf echte webgebaseerde applicaties gebruikt, zal de software beter werken, de servers beter worden beheerd, en werknemers hebben overal toegang tot het systeem.

Het argument tegen deze aanpak draait meestal om beveiliging: als de toegang gemakkelijker is voor werknemers, zal het dat ook zijn voor slechteriken. Sommige grotere handelaren waren terughoudend om Viaweb te gebruiken omdat ze dachten dat de creditcardgegevens van klanten veiliger zouden zijn op hun eigen servers. Het was niet gemakkelijk om dit punt diplomatiek te maken, maar in feite waren de gegevens bijna zeker veiliger in onze handen dan in die van hen. Wie kan betere mensen inhuren om beveiliging te beheren, een technologie-startup waarvan het hele bedrijf servers draait, of een kledingretailer? Niet alleen hadden we betere mensen die zich zorgen maakten over beveiliging, we maakten ons er meer zorgen over. Als iemand in de servers van de kledingretailer zou inbreken, zou dit hooguit één handelaar beïnvloeden, waarschijnlijk in de doofpot kon worden gestopt, en in het ergste geval kon één persoon worden ontslagen. Als iemand in de onze zou inbreken, zou het duizenden handelaren kunnen beïnvloeden, waarschijnlijk nieuws op CNet zou worden, en ons uit het bedrijf zou kunnen zetten.

Als je je geld veilig wilt houden, bewaar je het dan onder je matras thuis, of stop je het in een bank? Dit argument is van toepassing op elk aspect van serverbeheer: niet alleen beveiliging, maar ook uptime, bandbreedte, load management, back-ups, enz. Ons bestaan hing af van het correct uitvoeren van deze dingen. Serverproblemen waren het grote no-no voor ons, zoals een gevaarlijk speelgoed voor een speelgoedmaker, of een salmonella-uitbraak voor een voedselverwerker.

Een groot bedrijf dat webgebaseerde applicaties gebruikt, besteedt daardoor IT uit. Hoe drastisch het ook klinkt, ik denk dat dit over het algemeen een goed idee is. Bedrijven krijgen waarschijnlijk betere service op deze manier dan ze zouden krijgen van interne systeembeheerders. Systeembeheerders kunnen humeurig en onresponsief worden omdat ze niet direct worden blootgesteld aan concurrentiedruk: een verkoper moet omgaan met klanten, en een ontwikkelaar moet omgaan met de software van concurrenten, maar een systeembeheerder, als een oude vrijgezel, heeft weinig externe krachten om hem in het gareel te houden. [10] Bij Viaweb hadden we volop externe krachten om ons in het gareel te houden. De mensen die ons belden waren klanten, niet alleen collega's. Als een server vastliep, sprongen we; alleen al de gedachte eraan geeft me jaren later nog een adrenalinekick.

Dus webgebaseerde applicaties zullen over het algemeen ook voor grote bedrijven de juiste oplossing zijn. Ze zullen de laatsten zijn die het realiseren, net zoals ze dat waren met desktopcomputers. En deels om dezelfde reden: het zal veel geld waard zijn om grote bedrijven ervan te overtuigen dat ze iets duurdere nodig hebben.

Er is altijd een neiging voor rijke klanten om dure oplossingen te kopen, zelfs wanneer goedkopere oplossingen beter zijn, omdat de mensen die dure oplossingen aanbieden meer kunnen uitgeven om ze te verkopen. Bij Viaweb vochten we hier altijd tegen. We verloren verschillende high-end handelaren aan webconsultancybureaus die hen ervan overtuigden dat ze beter af zouden zijn als ze een half miljoen dollar betaalden voor een op maat gemaakte online winkel op hun eigen server. Ze waren, als regel, niet beter af, zoals meer dan één ontdekte toen het kerstinkopenseizoen aanbrak en de belasting op hun server steeg. Viaweb was veel geavanceerder dan wat de meeste van deze handelaren kregen, maar we konden het ons niet veroorloven om het hen te vertellen. Voor $ 300 per maand konden we ons geen team van goed geklede en gezaghebbend klinkende mensen veroorloven om presentaties te geven aan klanten.

Een groot deel van wat grote bedrijven extra betalen, is de kosten van het verkopen van dure dingen aan hen. (Als het Ministerie van Defensie duizend dollar betaalt voor toiletbrillen, is dat deels omdat het veel kost om toiletbrillen voor duizend dollar te verkopen.) En dit is een reden waarom intranetsoftware zal blijven floreren, ook al is het waarschijnlijk een slecht idee. Het is gewoon duurder. Er is niets dat je aan dit dilemma kunt doen, dus het beste plan is om eerst voor de kleinere klanten te gaan. De rest zal op tijd komen.

Zoon van Server

Het draaien van software op de server is niets nieuws. Sterker nog, het is het oude model: mainframe-applicaties zijn allemaal servergebaseerd. Als servergebaseerde software zo'n goed idee is, waarom heeft het de vorige keer verloren? Waarom hebben desktopcomputers mainframes verdrongen?

In eerste instantie leken desktopcomputers geen grote bedreiging. De eerste gebruikers waren allemaal hackers - of hobbyisten, zoals ze toen werden genoemd. Ze hielden van microcomputers omdat ze goedkoop waren. Voor het eerst kon je je eigen computer hebben. De term "persoonlijke computer" is nu onderdeel van de taal, maar toen het voor het eerst werd gebruikt, had het een opzettelijk gedurfde klank, zoals de term "persoonlijke satelliet" vandaag zou hebben.

Waarom namen desktopcomputers het over? Ik denk dat het kwam omdat ze betere software hadden. En ik denk dat de reden dat microcomputer software beter was, was dat het door kleine bedrijven kon worden geschreven.

Ik denk niet dat veel mensen beseffen hoe fragiel en voorlopig startups in de vroegste fase zijn. Veel startups beginnen bijna per ongeluk - als een paar jongens, hetzij met een baan, hetzij op school, die een prototype schrijven van iets dat, als het veelbelovend lijkt, een bedrijf kan worden. In dit larvale stadium zal elke significante hindernis de startup onmiddellijk stoppen. Het schrijven van mainframe-software vereiste te veel toewijding vooraf. Ontwikkelmachines waren duur, en omdat de klanten grote bedrijven zouden zijn, had je een indrukwekkende verkoopafdeling nodig om het aan hen te verkopen. Het starten van een startup om mainframe-software te schrijven zou een veel serieuzere onderneming zijn dan zomaar iets in elkaar hacken op je Apple II in de avonden. En dus kreeg je niet veel startups die mainframe-applicaties schreven.

De komst van desktopcomputers inspireerde veel nieuwe software, omdat het schrijven van applicaties ervoor leek een haalbaar doel voor larvale startups. Ontwikkeling was goedkoop, en de klanten zouden individuele mensen zijn die je via computerwinkels of zelfs per post kon bereiken.

De applicatie die desktopcomputers naar de mainstream duwde, was VisiCalc, de eerste spreadsheet. Het werd geschreven door twee jongens die op een zolder werkten, en deed toch dingen die geen enkele mainframe-software kon doen. [11] VisiCalc was in zijn tijd zo'n vooruitgang dat mensen Apple II's kochten alleen om het te draaien. En dit was het begin van een trend: desktopcomputers wonnen omdat startups er software voor schreven.

Het lijkt erop dat servergebaseerde software deze keer goed zal zijn, omdat startups het zullen schrijven. Computers zijn nu zo goedkoop dat je kunt beginnen, zoals wij deden, met een desktopcomputer als server. Goedkope processors hebben de workstationmarkt opgegeten (je hoort het woord nu zelden) en zijn voor het grootste deel van de servermarkt; de servers van Yahoo, die belastingen verwerken die zo hoog zijn als welke dan ook op internet, hebben allemaal dezelfde goedkope Intel-processors die je in je desktopmachine hebt. En zodra je de software hebt geschreven, heb je alleen nog een website nodig om deze te verkopen. Bijna al onze gebruikers kwamen rechtstreeks naar onze site via mond-tot-mondreclame en vermeldingen in de pers. [12]

Viaweb was een typische larvale startup. We waren doodsbang om een bedrijf te starten, en de eerste paar maanden troostten we onszelf door het hele ding te behandelen als een experiment dat we op elk moment konden stopzetten. Gelukkig waren er weinig obstakels behalve technische. Terwijl we de software schreven, was onze webserver dezelfde desktopmachine die we voor ontwikkeling gebruikten, verbonden met de buitenwereld via een inbelverbinding. Onze enige kosten in die fase waren eten en huur.

Er is des te meer reden voor startups om nu webgebaseerde software te schrijven, omdat het schrijven van desktopsoftware veel minder leuk is geworden. Als je nu desktopsoftware wilt schrijven, doe je dat op de voorwaarden van Microsoft, hun API's aanroepen en rond hun buggy OS werken. En als het je lukt iets te schrijven dat aanslaat, ontdek je misschien dat je alleen maar marktonderzoek voor Microsoft deed.

Als een bedrijf een platform wil maken waarop startups kunnen bouwen, moeten ze het iets maken dat hackers zelf willen gebruiken. Dat betekent dat het goedkoop en goed ontworpen moet zijn. De Mac was populair bij hackers toen het voor het eerst uitkwam, en velen van hen schreven er software voor. [13] Je ziet dit minder bij Windows, omdat hackers het niet gebruiken. Het soort mensen dat goed is in het schrijven van software, draait nu waarschijnlijk Linux of FreeBSD.

Ik denk niet dat we een startup zouden zijn begonnen om desktopsoftware te schrijven, omdat desktopsoftware op Windows moet draaien, en voordat we software voor Windows konden schrijven, zouden we het moeten gebruiken. Het web stelde ons in staat om een eindloop rond Windows te doen, en software die op Unix draait rechtstreeks aan gebruikers te leveren via de browser. Dat is een bevrijdend vooruitzicht, veel zoals de komst van pc's vijfentwintig jaar geleden.

Microsoft

Toen desktopcomputers arriveerden, was IBM de reus waar iedereen bang voor was. Het is nu moeilijk voor te stellen, maar ik herinner me het gevoel heel goed. Nu is de angstaanjagende reus Microsoft, en ik denk niet dat ze zo blind zijn voor de dreiging die hen bedreigt als IBM was. Tenslotte heeft Microsoft hun bedrijf bewust opgebouwd in de blinde vlek van IBM.

Ik heb eerder vermeld dat mijn moeder geen desktopcomputer nodig heeft. De meeste gebruikers waarschijnlijk niet. Dat is een probleem voor Microsoft, en ze weten het. Als applicaties op externe servers draaien, heeft niemand Windows nodig. Wat zal Microsoft doen? Zullen ze hun controle over de desktop kunnen gebruiken om deze nieuwe generatie software te voorkomen of te beperken?

Mijn gok is dat Microsoft een soort server/desktop-hybride zal ontwikkelen, waarbij het besturingssysteem samenwerkt met servers die zij controleren. In ieder geval zullen bestanden centraal beschikbaar zijn voor gebruikers die dat willen. Ik verwacht niet dat Microsoft helemaal tot het uiterste gaat om de berekeningen op de server te doen, met alleen een browser als client, als ze het kunnen vermijden. Als je alleen een browser als client nodig hebt, heb je Microsoft niet nodig op de client, en als Microsoft de client niet controleert, kunnen ze gebruikers niet naar hun servergebaseerde applicaties pushen.

Ik denk dat Microsoft het moeilijk zal hebben om de geest in de fles te houden. Er zullen te veel verschillende soorten clients zijn om ze allemaal te controleren. En als de applicaties van Microsoft alleen met bepaalde clients werken, zullen concurrenten hen kunnen overtreffen door applicaties aan te bieden die vanaf elke client werken. [14]

In een wereld van webgebaseerde applicaties is er geen automatische plaats voor Microsoft. Ze slagen er misschien in zichzelf een plaats te verwerven, maar ik denk niet dat ze deze nieuwe wereld zullen domineren zoals ze de wereld van desktopapplicaties deden.

Het is niet zozeer dat een concurrent hen zal struikelen, maar dat ze over zichzelf zullen struikelen. Met de opkomst van webgebaseerde software zullen ze niet alleen technische problemen tegenkomen, maar ook hun eigen wishful thinking. Wat ze moeten doen, is hun bestaande bedrijf kannibaliseren, en ik zie ze dat niet doen. Dezelfde eensgezindheid die hen tot nu toe heeft gebracht, zal nu tegen hen werken. IBM bevond zich in precies dezelfde situatie, en ze konden het niet beheersen. IBM maakte een late en halfslachtige entree in de microcomputer-business omdat ze ambivalent waren over het bedreigen van hun cash cow, mainframe computing. Microsoft zal op dezelfde manier worden gehinderd door het willen redden van de desktop. Een cash cow kan een verdomd zware aap op je rug zijn.

Ik zeg niet dat niemand servergebaseerde applicaties zal domineren. Iemand zal het waarschijnlijk uiteindelijk doen. Maar ik denk dat er een lange periode van vrolijke chaos zal zijn, net zoals er was in de beginjaren van microcomputers. Dat was een goede tijd voor startups. Veel kleine bedrijven bloeiden, en deden dat door coole dingen te maken.

Startups maar dan meer

De klassieke startup is snel en informeel, met weinig mensen en weinig geld. Die paar mensen werken heel hard, en technologie vergroot het effect van de beslissingen die ze nemen. Als ze winnen, winnen ze groots.

In een startup die webgebaseerde applicaties schrijft, wordt alles wat je associeert met startups tot het uiterste gedreven. Je kunt een product lanceren met nog minder mensen en nog minder geld. Je moet nog sneller zijn, en je kunt wegkomen met informeler zijn. Je kunt letterlijk je product lanceren als drie jongens die in de woonkamer van een appartement zitten, en een server die bij een ISP is ondergebracht. Wij deden dat.

Na verloop van tijd zijn de teams kleiner, sneller en informeler geworden. In 1960 betekende softwareontwikkeling een kamer vol mannen met hoornen brillen en smalle zwarte stropdassen, die ijverig tien regels code per dag schreven op IBM-codeformulieren. In 1980 was het een team van acht tot tien mensen die spijkerbroeken naar kantoor droegen en in vt100's typten. Nu zijn het een paar jongens die in een woonkamer zitten met laptops. (En spijkerbroeken blijken niet het laatste woord in informaliteit te zijn.)

Startups zijn stressvol, en dit wordt helaas ook tot het uiterste gedreven met webgebaseerde applicaties. Veel softwarebedrijven, vooral in het begin, hebben periodes waarin de ontwikkelaars onder hun bureaus sliepen, enzovoort. Het alarmerende aan webgebaseerde software is dat er niets is om te voorkomen dat dit de standaard wordt. De verhalen over slapen onder bureaus eindigen meestal: toen hebben we het eindelijk verzonden en gingen we allemaal naar huis en sliepen we een week. Webgebaseerde software wordt nooit verzonden. Je kunt 16-urige dagen werken zolang je wilt. En omdat je het kunt, en je concurrenten het kunnen, word je gedwongen om het te doen. Je kunt het, dus je moet het. Het is Parkinson's Law die achteruit draait.

Het ergste zijn niet de uren, maar de verantwoordelijkheid. Programmeurs en systeembeheerders hebben traditioneel elk hun eigen aparte zorgen. Programmeurs moeten zich zorgen maken over bugs, en systeembeheerders moeten zich zorgen maken over infrastructuur. Programmeurs kunnen een lange dag doorbrengen met hun ellebogen in de broncode, maar op een gegeven moment kunnen ze naar huis gaan en het vergeten. Systeembeheerders verlaten de baan nooit helemaal, maar wanneer ze om 4:00 uur 's ochtends worden gepagineerd, hoeven ze meestal niets heel ingewikkelds te doen. Met webgebaseerde applicaties worden deze twee soorten stress gecombineerd. De programmeurs worden systeembeheerders, maar zonder de scherp gedefinieerde grenzen die de baan normaal draaglijk maken.

Bij Viaweb brachten we de eerste zes maanden door met het schrijven van software. We werkten de gebruikelijke lange uren van een vroege startup. In een desktopsoftwarebedrijf zou dit het deel zijn geweest waar we hard werkten, maar het voelde als een vakantie vergeleken met de volgende fase, toen we gebruikers op onze server namen. Het op een na grootste voordeel van het verkopen van Viaweb aan Yahoo (na het geld) was de mogelijkheid om de ultieme verantwoordelijkheid voor het geheel te dumpen op de schouders van een groot bedrijf.

Desktopsoftware dwingt gebruikers om systeembeheerders te worden. Webgebaseerde software dwingt programmeurs dat ook. Er is minder stress in totaal, maar meer voor de programmeurs. Dat is niet noodzakelijk slecht nieuws. Als je een startup bent die concurreert met een groot bedrijf, is het goed nieuws. [15] Webgebaseerde applicaties bieden een directe manier om je concurrenten te overtreffen. Geen enkele startup vraagt meer.

Net Goed Genoeg

Eén ding dat je ervan kan weerhouden om webgebaseerde applicaties te schrijven, is de zwakte van webpagina's als UI. Dat is een probleem, geef ik toe. Er waren een paar dingen die we echt hadden willen toevoegen aan HTML en HTTP. Wat echter belangrijk is, is dat webpagina's gewoon goed genoeg zijn.

Hier is een parallel met de eerste microcomputers. De processors in die machines waren niet echt bedoeld om de CPU's van computers te zijn. Ze waren ontworpen om te worden gebruikt in dingen als verkeerslichten. Maar jongens zoals Ed Roberts, die de Altair ontwierp, realiseerden zich dat ze gewoon goed genoeg waren. Je kon een van deze chips combineren met wat geheugen (256 bytes in de eerste Altair), en front-panel schakelaars, en je had een werkende computer. Het feit dat je je eigen computer kon hebben was zo opwindend dat er genoeg mensen waren die ze wilden kopen, hoe beperkt ook.

Webpagina's zijn niet ontworpen als UI voor applicaties, maar ze zijn gewoon goed genoeg. En voor een aanzienlijk aantal gebruikers zal software die je vanuit elke browser kunt gebruiken, op zichzelf al genoeg winst zijn om elke onhandigheid in de UI te compenseren. Misschien kun je geen spreadsheet maken met de mooiste vormgeving met HTML, maar je kunt wel een spreadsheet maken dat meerdere mensen tegelijkertijd vanaf verschillende locaties kunnen gebruiken zonder speciale clientsoftware, of dat live datafeeds kan bevatten, of dat je kan pagineren wanneer bepaalde voorwaarden worden geactiveerd. Belangrijker nog, je kunt nieuwe soorten applicaties schrijven die nog geen namen hebben. VisiCalc was tenslotte niet zomaar een microcomputerversie van een mainframe-applicatie - het was een nieuw type applicatie.

Natuurlijk hoeven servergebaseerde applicaties niet webgebaseerd te zijn. Je zou een ander soort client kunnen hebben. Maar ik ben er vrij zeker van dat dit een slecht idee is. Het zou erg handig zijn als je kon aannemen dat iedereen je client zou installeren - zo handig dat je jezelf gemakkelijk kon overtuigen dat ze dat allemaal zouden doen - maar als ze dat niet doen, ben je de pineut. Omdat webgebaseerde software niets aanneemt over de client, zal het overal werken waar het web werkt. Dat is al een groot voordeel, en het voordeel zal groeien naarmate nieuwe webapparaten zich verspreiden. Gebruikers zullen je leuk vinden omdat je software gewoon werkt, en je leven zal gemakkelijker zijn omdat je het niet voor elke nieuwe client hoeft aan te passen. [16]

Ik heb het gevoel dat ik de evolutie van het web zo nauwkeurig heb gevolgd als wie dan ook, en ik kan niet voorspellen wat er met clients gaat gebeuren. Convergentie komt er waarschijnlijk aan, maar waarheen? Ik kan geen winnaar aanwijzen. Eén ding dat ik wel kan voorspellen, is conflict tussen AOL en Microsoft. Wat Microsoft's .NET ook zal blijken te zijn, het zal waarschijnlijk het verbinden van de desktop met servers omvatten. Tenzij AOL terugvecht, zullen ze ofwel opzij worden geschoven of worden omgezet in een pijplijn tussen Microsoft client- en serversoftware. Als Microsoft en AOL in een clientoorlog terechtkomen, zal het enige dat zeker op beide werkt, het browsen van het web zijn, wat betekent dat webgebaseerde applicaties de enige zijn die overal werken.

Hoe zal het allemaal uitpakken? Ik weet het niet. En je hoeft het niet te weten als je wedt op webgebaseerde applicaties. Niemand kan dat breken zonder browsen te breken. Het web is misschien niet de enige manier om software te leveren, maar het is een manier die nu werkt en nog lang zal werken. Webgebaseerde applicaties zijn goedkoop te ontwikkelen, en gemakkelijk te leveren, zelfs voor de kleinste startup. Ze zijn veel werk, en van een bijzonder stressvol soort, maar dat maakt de kansen voor startups alleen maar beter.

Waarom niet?

E. B. White vond het amusant om van een boerenvriend te horen dat veel geëlektrificeerde hekken geen stroom doorlaten. De koeien blijven er blijkbaar bij uit de buurt, en daarna heb je de stroom niet meer nodig. "Sta op, koeien!" schreef hij, "Neem je vrijheid terwijl despoten snurken!"

Als je een hacker bent die ooit heeft gedacht aan het starten van een startup, zijn er waarschijnlijk twee dingen die je ervan weerhouden. Eén is dat je niets van zaken weet. De andere is dat je bang bent voor concurrentie. Geen van deze hekken heeft stroom.

Er zijn maar twee dingen die je over zaken moet weten: bouw iets waar gebruikers van houden, en verdien meer dan je uitgeeft. Als je deze twee goed krijgt, sta je voor op de meeste startups. De rest kun je onderweg uitzoeken.

Misschien verdien je in het begin niet meer dan je uitgeeft, maar zolang de kloof snel genoeg kleiner wordt, komt het goed. Als je ondergefinancierd begint, zal het in ieder geval een gewoonte van zuinigheid aanmoedigen. Hoe minder je uitgeeft, hoe gemakkelijker het is om meer uit te geven dan je uitgeeft. Gelukkig kan het zeer goedkoop zijn om een webgebaseerde applicatie te lanceren. We lanceerden voor minder dan $ 10.000, en het zou vandaag nog goedkoper zijn. We moesten duizenden uitgeven aan een server, en nog eens duizenden om SSL te krijgen. (Het enige bedrijf dat destijds SSL-software verkocht, was Netscape.) Nu kun je een veel krachtigere server huren, met inbegrip van SSL, voor minder dan we alleen al voor bandbreedte betaalden. Je zou nu een webgebaseerde applicatie kunnen lanceren voor minder dan de kosten van een chique bureaustoel.

Wat betreft het bouwen van iets waar gebruikers van houden, hier zijn enkele algemene tips. Begin met het maken van iets schoons en eenvoudigs dat je zelf zou willen gebruiken. Breng snel een versie 1.0 uit, verbeter de software daarna continu, luister goed naar de gebruikers terwijl je dat doet. De klant heeft altijd gelijk, maar verschillende klanten hebben gelijk over verschillende dingen; de minst geavanceerde gebruikers laten je zien wat je moet vereenvoudigen en verduidelijken, en de meest geavanceerde vertellen je welke functies je moet toevoegen. Het beste wat software kan zijn, is gemakkelijk, maar de manier om dit te doen is door de standaardinstellingen goed te krijgen, niet door de keuzes van gebruikers te beperken. Wees niet zelfgenoegzaam als de software van je concurrenten slecht is; de standaard waarmee je je software moet vergelijken, is wat het zou kunnen zijn, niet wat je huidige concurrenten toevallig hebben. Gebruik je software zelf, de hele tijd. Viaweb moest een online winkelbouwer zijn, maar we gebruikten het ook om onze eigen site te maken. Luister niet naar marketingmensen of ontwerpers of productmanagers alleen vanwege hun functietitels. Als ze goede ideeën hebben, gebruik ze, maar het is aan jou om te beslissen; software moet worden ontworpen door hackers die ontwerp begrijpen, niet door ontwerpers die een beetje van software weten. Als je software niet zo goed kunt ontwerpen als implementeren, begin dan geen startup.

Laten we het nu over concurrentie hebben. Waar je bang voor bent, zijn vermoedelijk niet groepen hackers zoals jij, maar daadwerkelijke bedrijven, met kantoren en businessplannen en verkopers en zo, toch? Nou, ze zijn meer bang voor jou dan jij voor hen, en ze hebben gelijk. Het is veel gemakkelijker voor een paar hackers om uit te zoeken hoe ze kantoorruimte kunnen huren of verkopers kunnen inhuren dan voor een bedrijf van enige omvang om software geschreven te krijgen. Ik heb aan beide kanten gestaan, en ik weet het. Toen Viaweb door Yahoo werd gekocht, bevond ik me plotseling werkzaam voor een groot bedrijf, en het was alsof ik door kniediep water probeerde te rennen.

Ik wil Yahoo niet kleineren. Ze hadden een paar goede hackers, en het topmanagement waren echte doorpakkers. Voor een groot bedrijf waren ze uitzonderlijk. Maar ze waren nog steeds maar ongeveer een tiende zo productief als een kleine startup. Geen enkel groot bedrijf kan veel beter doen dan dat. Wat angstaanjagend is aan Microsoft, is dat zo'n groot bedrijf überhaupt software kan ontwikkelen. Ze zijn als een berg die kan lopen.

Laat je niet intimideren. Je kunt net zoveel doen wat Microsoft niet kan, als zij kunnen wat jij niet kunt. En niemand kan je tegenhouden. Je hoeft niemand toestemming te vragen om webgebaseerde applicaties te ontwikkelen. Je hoeft geen licentieovereenkomsten te sluiten, of winkelruimte te krijgen in winkels, of te smeken om je applicatie gebundeld te krijgen met het OS. Je kunt software rechtstreeks naar de browser leveren, en niemand kan tussen jou en potentiële gebruikers komen zonder hen te beletten het web te browsen.

Je gelooft het misschien niet, maar ik beloof je, Microsoft is bang voor je. De zelfgenoegzame middenmanagers misschien niet, maar Bill wel, omdat hij jou ooit was, in 1975, de laatste keer dat een nieuwe manier van software leveren verscheen.

Noten

[1] Realiserend dat veel van het geld in de diensten zit, hebben bedrijven die lichtgewicht clients bouwen meestal geprobeerd de hardware te combineren met een online service. Deze aanpak heeft niet goed gewerkt, deels omdat je twee verschillende soorten bedrijven nodig hebt om consumentenelektronica te bouwen en een online service te draaien, en deels omdat gebruikers een hekel hebben aan het idee. Het weggeven van het scheermes en geld verdienen aan de mesjes werkt misschien voor Gillette, maar een scheermes is een veel kleinere toewijding dan een webterminal. Mobiele telefoonfabrikanten zijn tevreden met het verkopen van hardware zonder ook de service-inkomsten te willen vastleggen. Dat zou waarschijnlijk het model moeten zijn voor internetclients. Als iemand gewoon een mooi uitziend doosje met een webbrowser verkocht dat je kon gebruiken om verbinding te maken via elke ISP, zou elke technofoob in het land er een kopen.

[2] Beveiliging hangt altijd meer af van niet falen dan van enige ontwerpbeslissing, maar de aard van servergebaseerde software zal ontwikkelaars ertoe aanzetten om meer aandacht te besteden aan niet falen. Het compromitteren van een server kan zoveel schade veroorzaken dat ASP's (die in zaken willen blijven) waarschijnlijk voorzichtig zullen zijn met beveiliging.

[3] In 1995, toen we Viaweb begonnen, werden Java-applets verondersteld de technologie te zijn die iedereen zou gebruiken om servergebaseerde applicaties te ontwikkelen. Applets leken ons een ouderwets idee. Programma's downloaden om op de client te draaien? Simpeler om helemaal te gaan en de programma's op de server te draaien. We hebben weinig tijd verspild aan applets, maar talloze andere startups moeten in deze teerput zijn gelokt. Weinigen kunnen levend zijn ontsnapt, of Microsoft had niet weg kunnen komen met het droppen van Java in de meest recente versie van Explorer.

[4] Dit punt is te danken aan Trevor Blackwell, die toevoegt "de kosten van het schrijven van software gaan meer dan lineair omhoog met zijn grootte. Misschien komt dit voornamelijk door het oplossen van oude bugs, en de kosten kunnen lineair zijn als alle bugs snel worden gevonden."

[5] Het moeilijkste soort bug om te vinden kan een variant zijn van de samengestelde bug waarbij één bug een andere compenseert. Wanneer je één bug oplost, wordt de andere zichtbaar. Maar het zal lijken alsof de oplossing de schuldige is, aangezien dat het laatste was dat je hebt veranderd.

[6] Binnen Viaweb hadden we ooit een wedstrijd om het slechtste aan onze software te beschrijven. Twee klantenservice medewerkers eindigden gelijk voor de eerste prijs met inzendingen die ik nog steeds rillend herinner. We hebben beide problemen onmiddellijk opgelost.

[7] Robert Morris schreef het bestelsysteem, dat shoppers gebruikten om bestellingen te plaatsen. Trevor Blackwell schreef de beeldgenerator en de manager, die handelaren gebruikten om bestellingen op te halen, statistieken te bekijken en domeinnamen te configureren, enz. Ik schreef de editor, die handelaren gebruikten om hun sites te bouwen. Het bestelsysteem en de beeldgenerator waren geschreven in C en C++, de manager grotendeels in Perl, en de editor in Lisp.

[8] Prijsdiscriminatie is zo wijdverbreid (hoe vaak heb je een retailer horen beweren dat hun koopkracht lagere prijzen voor jou betekende?) dat ik verrast was te ontdekken dat het in de VS verboden was door de Robinson-Patman Act van 1936. Deze wet lijkt niet krachtig te worden gehandhaafd.

[9] In No Logo zegt Naomi Klein dat kledingmerken die populair zijn bij "stedelijke jeugd" winkeldiefstal niet te hard proberen te voorkomen, omdat in hun doelgroep de winkeldieven ook de modeleiders zijn.

[10] Bedrijven vragen zich vaak af wat ze moeten uitbesteden en wat niet. Een mogelijke antwoord: besteed elke baan uit die niet direct wordt blootgesteld aan concurrentiedruk, omdat het uitbesteden ervan die baan daardoor blootstelt aan concurrentiedruk.

[11] De twee jongens waren Dan Bricklin en Bob Frankston. Dan schreef een prototype in Basic in een paar dagen, en vervolgens gedurende het volgende jaar werkten ze samen (voornamelijk 's nachts) om een krachtigere versie te maken, geschreven in 6502 machinecode. Dan zat destijds op de Harvard Business School en Bob had nominaal een dagtaak met het schrijven van software. "Er was geen groot risico aan het starten van een bedrijf," schreef Bob, "Als het mislukte, mislukte het. Geen big deal."

[12] Het is niet zo gemakkelijk als ik het laat klinken. Het duurde pijnlijk lang voordat mond-tot-mondreclame op gang kwam, en we kregen pas veel persdekking nadat we een PR-bureau (toegegeven, het beste in de branche) voor $ 16.000 per maand hadden ingehuurd. Het was echter waar dat het enige significante kanaal onze eigen website was.

[13] Als de Mac zo geweldig was, waarom verloor hij dan? Kosten, opnieuw. Microsoft concentreerde zich op de softwarebusiness en ontketende een zwerm goedkope componentleveranciers op Apple-hardware. Het hielp ook niet dat pakken het overnamen tijdens een kritieke periode.

[14] Eén ding dat webgebaseerde applicaties zou helpen, en de volgende generatie software zou helpen voorkomen dat deze door Microsoft wordt overschaduwd, zou een goede open-source browser zijn. Mozilla is open-source, maar lijkt te hebben geleden omdat het zo lang bedrijfssoftware was. Een kleine, snelle browser die actief werd onderhouden, zou op zichzelf al geweldig zijn, en zou waarschijnlijk ook bedrijven aanmoedigen om kleine webapparaten te bouwen.

Onder andere zou een fatsoenlijke open-source browser ervoor zorgen dat HTTP en HTML blijven evolueren (zoals bijvoorbeeld Perl). Het zou webgebaseerde applicaties enorm helpen om onderscheid te kunnen maken tussen het selecteren van een link en het volgen ervan; alles wat je daarvoor nodig hebt, is een triviale verbetering van HTTP, om meerdere URL's in een verzoek toe te staan. Cascaderende menu's zouden ook goed zijn.

Als je de wereld wilt veranderen, schrijf dan een nieuwe Mosaic. Denk je dat het te laat is? In 1998 dachten veel mensen dat het te laat was om een nieuwe zoekmachine te lanceren, maar Google bewees ze ongelijk. Er is altijd ruimte voor iets nieuws als de huidige opties slecht genoeg zijn. Zorg ervoor dat het eerst werkt op alle gratis besturingssystemen - nieuwe dingen beginnen met hun gebruikers.

[15] Trevor Blackwell, die hier waarschijnlijk meer persoonlijke ervaring mee heeft dan wie dan ook, schrijft:

"Ik zou verder gaan met te zeggen dat omdat servergebaseerde software zo zwaar is voor programmeurs, het een fundamentele economische verschuiving weg van grote bedrijven veroorzaakt. Het vereist de intensiteit en toewijding van programmeurs die ze alleen zullen willen bieden als het hun eigen bedrijf is. Softwarebedrijven kunnen bekwame mensen inhuren om te werken in een niet al te veeleisende omgeving, en kunnen ongeschoolde mensen inhuren om ontberingen te doorstaan, maar ze kunnen niet zeer bekwame mensen inhuren om hun reet te breken. Aangezien kapitaal niet langer nodig is, hebben grote bedrijven weinig te bieden."

[16] In de oorspronkelijke versie van dit essay raadde ik af om Javascript te gebruiken. Dat was een goed plan in 2001, maar Javascript werkt nu.

Dank aan Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson en Dan Giffin voor het lezen van concepten van dit artikel; aan Dan Bricklin en Bob Frankston voor informatie over VisiCalc; en nogmaals aan Ken Anderson voor het uitnodigen om te spreken bij BBN.

Je vindt dit essay en 14 andere in Hackers & Painters.