September 2001(This article explains why much of the next generation of softwaremay be server-based, what that will mean for programmers,and why this new kind of software is a great opportunity for startups.It's derived from a talk at BBN Labs.)In the summer of 1995, my friend Robert Morris and I decided tostart a startup. The PR campaign leading up to Netscape's IPO wasrunning full blast then, and there was a lot of talk in the pressabout online commerce. At the time there might have been thirtyactual stores on the Web, all made by hand. If there were goingto be a lot of online stores, there would need to be software for makingthem, so we decided to write some.For the first week or so we intended to make this an ordinary desktop application. Then one day we had the idea of making thesoftware run on our Web server, using the browser as aninterface. We tried rewriting the software to work overthe Web, and it was clear that this was the way to go.If we wrote our software to run on the server, it would be a lot easierfor the users and for us as well.This turned out to be a good plan. Now, as Yahoo Store, thissoftware is the most popular online store builder, withabout 14,000 users.When we started Viaweb, hardly anyone understood what we meant whenwe said that the software ran on the server. It was not untilHotmail was launched a year later that people started to get it.Now everyone knows that this is a valid approach. There isa name now for what we were: an Application Service Provider,or ASP.I think that a lot of the next generation of software will bewritten on this model. Even Microsoft, who have the most tolose, seem to see the inevitablity of moving some things offthe desktop. If software movesoff the desktop and onto servers, it will mean a very differentworld for developers. This article describes the surprisingthings we saw, as some of the first visitors to this new world.To the extent software does move ontoservers, what I'm describing here is the future.The Next Thing?When we look back on the desktop software era, I think we'll marvelat the inconveniences people put up with, just as we marvel now atwhat early car owners put up with. For the first twenty or thirtyyears, you had to be a car expert to own a car. But cars were sucha big win that lots of people who weren't car experts wanted tohave them as well.Computers are in this phase now. When you own a desktop computer,you end up learning a lot more than you wanted to know about what'shappening inside it. But more than half the households in the USown one. My mother has a computer that she uses for email and forkeeping accounts. About a year ago she was alarmed to receive aletter from Apple, offering her a discount on a new version of theoperating system. There's something wrong when a sixty-five yearold woman who wants to use a computer for email and accounts hasto think about installing new operating systems. Ordinary usersshouldn't even know the words "operating system," much less "devicedriver" or "patch."There is now another way to deliver software that will save usersfrom becoming system administrators. Web-based applications areprograms that run on Web servers and use Web pages as the userinterface. For the average user this new kind of software will beeasier, cheaper, more mobile, more reliable, and often more powerfulthan desktop software.With Web-based software, most users won't have to think aboutanything except the applications they use. All the messy, changingstuff will be sitting on a server somewhere, maintained by the kindof people who are good at that kind of thing. And so you won'tordinarily need a computer, per se, to use software. All you'llneed will be something with a keyboard, a screen, and a Web browser.Maybe it will have wireless Internet access. Maybe it will alsobe your cell phone. Whatever it is, it will be consumer electronics:something that costs about $200, and that people choose mostlybased on how the case looks. You'll pay more for Internet servicesthan you do for the hardware, just as you do now with telephones. [1]It will take about a tenth of a second for a click to get to theserver and back, so users of heavily interactive software, likePhotoshop, will still want to have the computations happening onthe desktop. But if you look at the kind of things most peopleuse computers for, a tenth of a second latency would not be aproblem. My mother doesn't really need a desktop computer, andthere are a lot of people like her.The Win for UsersNear my house there is a car with a bumper sticker that reads "deathbefore inconvenience." Most people, most of the time, will takewhatever choice requires least work. If Web-based software wins,it will be because it's more convenient. And it looks as if itwill be, for users and developers both.To use a purely Web-based application, all you need is a browserconnected to the Internet. So you can use a Web-based applicationanywhere. When you install software on your desktop computer, youcan only use it on that computer. Worse still, your files aretrapped on that computer. The inconvenience of this model becomesmore and more evident as people get used to networks.The thin end of the wedge here was Web-based email. Millions ofpeople now realize that you should have access to email messagesno matter where you are. And if you can see your email, why notyour calendar? If you can discuss a document with your colleagues,why can't you edit it? Why should any of your data be trapped onsome computer sitting on a faraway desk?The whole idea of "your computer" is going away, and being replacedwith "your data." You should be able to get at your data from anycomputer. Or rather, any client, and a client doesn't have to bea computer.Clients shouldn't store data; they should be like telephones. Infact they may become telephones, or vice versa. And as clientsget smaller, you have another reason not to keep your data on them:something you carry around with you can be lost or stolen. Leavingyour PDA in a taxi is like a disk crash, except that your data ishanded to someone else instead of being vaporized.With purely Web-based software, neither your data nor the applicationsare kept on the client. So you don't have to install anything touse it. And when there's no installation, you don't have to worryabout installation going wrong. There can't be incompatibilitiesbetween the application and your operating system, because thesoftware doesn't run on your operating system.Because it needs no installation, it will be easy, and common, totry Web-based software before you "buy" it. You should expect tobe able to test-drive any Web-based application for free, just bygoing to the site where it's offered. At Viaweb our whole sitewas like a big arrow pointing users to the test drive.After trying the demo, signing up for the service should requirenothing more than filling out a brief form (the briefer the better).And that should be the last work the user has to do. With Web-basedsoftware, you should get new releases without paying extra, ordoing any work, or possibly even knowing about it.Upgrades won't be the big shocks they are now. Over time applicationswill quietly grow more powerful. This will take some effort onthe part of the developers. They will have to design software sothat it can be updated without confusing the users. That's a newproblem, but there are ways to solve it.With Web-based applications, everyone uses the same version, andbugs can be fixed as soon as they're discovered. So Web-basedsoftware should have far fewer bugs than desktop software. AtViaweb, I doubt we ever had ten known bugs at any one time. That'sorders of magnitude better than desktop software.Web-based applications can be used by several people at the sametime. This is an obvious win for collaborative applications, butI bet users will start to want this in most applications once theyrealize it's possible. It will often be useful to let two peopleedit the same document, for example. Viaweb let multiple usersedit a site simultaneously, more because that was the right way towrite the software than because we expected users to want to, butit turned out that many did.When you use a Web-based application, your data will be safer.Disk crashes won't be a thing of the past, but users won't hearabout them anymore. They'll happen within server farms. Andcompanies offering Web-based applications will actually do backups--not only because they'll have real system administrators worryingabout such things, but because an ASP that does lose people's datawill be in big, big trouble. When people lose their own data ina disk crash, they can't get that mad, because they only havethemselves to be mad at. When a company loses their data for them,they'll get a lot madder.Finally, Web-based software should be less vulnerable to viruses.If the client doesn't run anything except a browser, there's lesschance of running viruses, and no data locally to damage. And aprogram that attacked the servers themselves should find them verywell defended. [2]For users, Web-based software will be less stressful. I think ifyou looked inside the average Windows user you'd find a huge andpretty much untapped desire for software meeting that description.Unleashed, it could be a powerful force.City of CodeTo developers, the most conspicuous difference between Web-basedand desktop software is that a Web-based application is not a singlepiece of code. It will be a collection of programs of differenttypes rather than a single big binary. And so designing Web-basedsoftware is like desiging a city rather than a building: as wellas buildings you need roads, street signs, utilities, police andfire departments, and plans for both growth and various kinds ofdisasters.At Viaweb, software included fairly big applications that userstalked to directly, programs that those programs used, programsthat ran constantly in the background looking for problems, programsthat tried to restart things if they broke, programs that ranoccasionally to compile statistics or build indexes for searches,programs we ran explicitly to garbage-collect resources or to moveor restore data, programs that pretended to be users (to measureperformance or expose bugs), programs for diagnosing networktroubles, programs for doing backups, interfaces to outside services,software that drove an impressive collection of dials displayingreal-time server statistics (a hit with visitors, but indispensablefor us too), modifications (including bug fixes) to open-sourcesoftware, and a great many configuration files and settings. TrevorBlackwell wrote a spectacular program for moving stores to newservers across the country, without shutting them down, after wewere bought by Yahoo. Programs paged us, sent faxes and email tousers, conducted transactions with credit card processors, andtalked to one another through sockets, pipes, http requests, ssh,udp packets, shared memory, and files. Some of Viaweb even consistedof the absence of programs, since one of the keys to Unix securityis not to run unnecessary utilities that people might use to breakinto your servers.It did not end with software. We spent a lot of time thinkingabout server configurations. We built the servers ourselves, fromcomponents-- partly to save money, and partly to get exactly whatwe wanted. We had to think about whether our upstream ISP had fastenough connections to all the backbones. We serially datedRAID suppliers.But hardware is not just something to worry about. When you controlit you can do more for users. With a desktop application, you canspecify certain minimum hardware, but you can't add more. If youadminister the servers, you can in one step enable all your usersto page people, or send faxes, or send commands by phone, or processcredit cards, etc, just by installing the relevant hardware. Wealways looked for new ways to add features with hardware, not justbecause it pleased users, but also as a way to distinguish ourselvesfrom competitors who (either because they sold desktop software,or resold Web-based applications through ISPs) didn't have directcontrol over the hardware.Because the software in a Web-based application will be a collectionof programs rather than a single binary, it can be written in anynumber of different languages. When you're writing desktop software,you're practically forced to write the application in the samelanguage as the underlying operating system-- meaning C and C++.And so these languages (especially among nontechnical people likemanagers and VCs) got to be considered as the languages for "serious"software development. But that was just an artifact of the waydesktop software had to be delivered. For server-based softwareyou can use any language you want. [3] Today a lot of the tophackers are using languages far removed from C and C++: Perl,Python, and even Lisp.With server-based software, no one can tell you what language touse, because you control the whole system, right down to thehardware. Different languages are good for different tasks. Youcan use whichever is best for each. And when you have competitors,"you can" means "you must" (we'll return to this later), becauseif you don't take advantage of this possibility, your competitorswill.Most of our competitors used C and C++, and this made their softwarevisibly inferior because (among other things), they had no wayaround the statelessness of CGI scripts. If you were going tochange something, all the changes had to happen on one page, withan Update button at the bottom. As I've written elsewhere, byusing Lisp, which many people still consider a research language,we could make the Viaweb editor behave more like desktop software.ReleasesOne of the most important changes in this new world is the way youdo releases. In the desktop software business, doing a release isa huge trauma, in which the whole company sweats and strains topush out a single, giant piece of code. Obvious comparisons suggestthemselves, both to the process and the resulting product.With server-based software, you can make changes almost as youwould in a program you were writing for yourself. You releasesoftware as a series of incremental changes instead of an occasionalbig explosion. A typical desktop software company might do one ortwo releases a year. At Viaweb we often did three to five releasesa day.When you switch to this new model, you realize how much softwaredevelopment is affected by the way it is released. Many of thenastiest problems you see in the desktop software business are dueto catastrophic nature of releases.When you release only one new version a year, you tend to deal withbugs wholesale. Some time before the release date you assemble anew version in which half the code has been torn out and replaced,introducing countless bugs. Then a squad of QA people step in andstart counting them, and the programmers work down the list, fixingthem. They do not generally get to the end of the list, and indeed,no one is sure where the end is. It's like fishing rubble out ofa pond. You never really know what's happening inside the software.At best you end up with a statistical sort of correctness.With server-based software, most of the change is small andincremental. That in itself is less likely to introduce bugs. Italso means you know what to test most carefully when you're aboutto release software: the last thing you changed. You end up witha much firmer grip on the code. As a general rule, you do knowwhat's happening inside it. You don't have the source code memorized,of course, but when you read the source you do it like a pilotscanning the instrument panel, not like a detective trying tounravel some mystery.Desktop software breeds a certain fatalism about bugs. You knowthat you're shipping something loaded with bugs, and you've evenset up mechanisms to compensate for it (e.g. patch releases). Sowhy worry about a few more? Soon you're releasing whole featuresyou know are broken. Apple did this earlier this year. They feltunder pressure to release their new OS, whose release date hadalready slipped four times, but some of the software (support forCDs and DVDs) wasn't ready. The solution? They released the OSwithout the unfinished parts, and users will have to install themlater.With Web-based software, you never have to release software beforeit works, and you can release it as soon as it does work.The industry veteran may be thinking, it's a fine-sounding idea tosay that you never have to release software before it works, butwhat happens when you've promised to deliver a new version of yoursoftware by a certain date? With Web-based software, you wouldn'tmake such a promise, because there are no versions. Your softwarechanges gradually and continuously. Some changes might be biggerthan others, but the idea of versions just doesn't naturally fitonto Web-based software.If anyone remembers Viaweb this might sound odd, because we werealways announcing new versions. This was done entirely for PRpurposes. The trade press, we learned, thinks in version numbers.They will give you major coverage for a major release, meaning anew first digit on the version number, and generally a paragraphat most for a point release, meaning a new digit after the decimalpoint.Some of our competitors were offering desktop software and actuallyhad version numbers. And for these releases, the mere fact ofwhich seemed to us evidence of their backwardness, they would getall kinds of publicity. We didn't want to miss out, so we startedgiving version numbers to our software too. When we wanted somepublicity, we'd make a list of all the features we'd added sincethe last "release," stick a new version number on the software,and issue a press release saying that the new version was availableimmediately. Amazingly, no one ever called us on it.By the time we were bought, we had done this three times, so wewere on Version 4. Version 4.1 if I remember correctly. AfterViaweb became Yahoo Store, there was no longer such a desperateneed for publicity, so although the software continued to evolve,the whole idea of version numbers was quietly dropped.BugsThe other major technical advantage of Web-based software is thatyou can reproduce most bugs. You have the users' data right thereon your disk. If someone breaks your software, you don't have totry to guess what's going on, as you would with desktop software:you should be able to reproduce the error while they're on thephone with you. You might even know about it already, if you havecode for noticing errors built into your application.Web-based software gets used round the clock, so everything you dois immediately put through the wringer. Bugs turn up quickly.Software companies are sometimes accused of letting the users debugtheir software. And that is just what I'm advocating. For Web-basedsoftware it's actually a good plan, because the bugs are fewer andtransient. When you release software gradually you get far fewerbugs to start with. And when you can reproduce errors and releasechanges instantly, you can find and fix most bugs as soon as theyappear. We never had enough bugs at any one time to bother witha formal bug-tracking system.You should test changes before you release them, of course, so nomajor bugs should get released. Those few that inevitably slipthrough will involve borderline cases and will only affect the fewusers that encounter them before someone calls in to complain. Aslong as you fix bugs right away, the net effect, for the averageuser, is far fewer bugs. I doubt the average Viaweb user ever sawa bug.Fixing fresh bugs is easier than fixing old ones. It's usuallyfairly quick to find a bug in code you just wrote. When it turnsup you often know what's wrong before you even look at the source,because you were already worrying about it subconsciously. Fixinga bug in something you wrote six months ago (the average case ifyou release once a year) is a lot more work. And since you don'tunderstand the code as well, you're more likely to fix it in anugly way, or even introduce more bugs. [4]When you catch bugs early, you also get fewer compound bugs.Compound bugs are two separate bugs that interact: you trip goingdownstairs, and when you reach for the handrail it comes off inyour hand. In software this kind of bug is the hardest to find,and also tends to have the worst consequences. [5] The traditional"break everything and then filter out the bugs" approach inherentlyyields a lot of compound bugs. And software that's released in aseries of small changes inherently tends not to. The floors areconstantly being swept clean of any loose objects that might laterget stuck in something.It helps if you use a technique called functional programming.Functional programming means avoiding side-effects. It's somethingyou're more likely to see in research papers than commercialsoftware, but for Web-based applications it turns out to be reallyuseful. It's hard to write entire programs as purely functionalcode, but you can write substantial chunks this way. It makesthose parts of your software easier to test, because they have nostate, and that is very convenient in a situation where you areconstantly making and testing small modifications. I wrote muchof Viaweb's editor in this style, and we made our scripting language,RTML, a purely functional language.People from the desktop software business will find this hard tocredit, but at Viaweb bugs became almost a game. Since most releasedbugs involved borderline cases, the users who encountered them werelikely to be advanced users, pushing the envelope. Advanced usersare more forgiving about bugs, especially since you probablyintroduced them in the course of adding some feature they wereasking for. In fact, because bugs were rare and you had to bedoing sophisticated things to see them, advanced users were oftenproud to catch one. They would call support in a spirit more oftriumph than anger, as if they had scored points off us.SupportWhen you can reproduce errors, it changes your approach to customersupport. At most software companies, support is offered as a wayto make customers feel better. They're either calling you abouta known bug, or they're just doing something wrong and you have tofigure out what. In either case there's not much you can learnfrom them. And so you tend to view support calls as a pain in theass that you want to isolate from your developers as much aspossible.This was not how things worked at Viaweb. At Viaweb, support wasfree, because we wanted to hear from customers. If someone had aproblem, we wanted to know about it right away so that we couldreproduce the error and release a fix.So at Viaweb the developers were always in close contact withsupport. The customer support people were about thirty feet awayfrom the programmers, and knew that they could always interruptanything with a report of a genuine bug. We would leave a boardmeeting to fix a serious bug.Our approach to support made everyone happier. The customers weredelighted. Just imagine how it would feel to call a support lineand be treated as someone bringing important news. The customersupport people liked it because it meant they could help the users,instead of reading scripts to them. And the programmers liked itbecause they could reproduce bugs instead of just hearing vaguesecond-hand reports about them.Our policy of fixing bugs on the fly changed the relationshipbetween customer support people and hackers. At most softwarecompanies, support people are underpaid human shields, and hackersare little copies of God the Father, creators of the world. Whateverthe procedure for reporting bugs, it is likely to be one-directional:support people who hear about bugs fill out some form that eventuallygets passed on (possibly via QA) to programmers, who put it ontheir list of things to do. It was very different at Viaweb.Within a minute of hearing about a bug from a customer, the supportpeople could be standing next to a programmer hearing him say "Shit,you're right, it's a bug." It delighted the support people to hearthat "you're right" from the hackers. They used to bring us bugswith the same expectant air as a cat bringing you a mouse it hasjust killed. It also made them more careful in judging theseriousness of a bug, because now their honor was on the line.After we were bought by Yahoo, the customer support people weremoved far away from the programmers. It was only then that werealized that they were effectively QA and to some extent marketingas well. In addition to catching bugs, they were the keepers ofthe knowledge of vaguer, buglike things, like features that confusedusers. [6] They were also a kind of proxy focus group; we couldask them which of two new features users wanted more, and they werealways right.MoraleBeing able to release software immediately is a big motivator.Often as I was walking to work I would think of some change I wantedto make to the software, and do it that day. This worked for biggerfeatures as well. Even if something was going to take two weeksto write (few projects took longer), I knew I could see the effectin the software as soon as it was done.If I'd had to wait a year for the next release, I would have shelvedmost of these ideas, for a while at least. The thing about ideas,though, is that they lead to more ideas. Have you ever noticedthat when you sit down to write something, half the ideas that endup in it are ones you thought of while writing it? The same thinghappens with software. Working to implement one idea gives youmore ideas. So shelving an idea costs you not only that delay inimplementing it, but also all the ideas that implementing it wouldhave led to. In fact, shelving an idea probably even inhibits newideas: as you start to think of some new feature, you catch sightof the shelf and think "but I already have a lot of new things Iwant to do for the next release."What big companies do instead of implementing features is planthem. At Viaweb we sometimes ran into trouble on this account.Investors and analysts would ask us what we had planned for thefuture. The truthful answer would have been, we didn't have anyplans. We had general ideas about things we wanted to improve,but if we knew how we would have done it already. What were wegoing to do in the next six months? Whatever looked like the biggestwin. I don't know if I ever dared give this answer, but that wasthe truth. Plans are just another word for ideas on the shelf.When we thought of good ideas, we implemented them.At Viaweb, as at many software companies, most code had one definiteowner. But when you owned something you really owned it: no oneexcept the owner of a piece of software had to approve (or evenknow about) a release. There was no protection against breakageexcept the fear of looking like an idiot to one's peers, and thatwas more than enough. I may have given the impression that we justblithely plowed forward writing code. We did go fast, but wethought very carefully before we released software onto thoseservers. And paying attention is more important to reliabilitythan moving slowly. Because he pays close attention, a Navy pilotcan land a 40,000 lb. aircraft at 140 miles per hour on a pitchingcarrier deck, at night, more safely than the average teenager cancut a bagel.This way of writing software is a double-edged sword of course.It works a lot better for a small team of good, trusted programmersthan it would for a big company of mediocre ones, where bad ideasare caught by committees instead of the people that had them.Brooks in ReverseFortunately, Web-based software does require fewer programmers.I once worked for a medium-sized desktop software company that hadover 100 people working in engineering as a whole. Only 13 ofthese were in product development. All the rest were working onreleases, ports, and so on. With Web-based software, all you need(at most) are the 13 people, because there are no releases, ports,and so on.Viaweb was written by just three people. [7] I was always underpressure to hire more, because we wanted to get bought, and we knewthat buyers would have a hard time paying a high price for a companywith only three programmers. (Solution: we hired more, but creatednew projects for them.)When you can write software with fewer programmers, it saves youmore than money. As Fred Brooks pointed out in The MythicalMan-Month, adding people to a project tends to slow it down. Thenumber of possible connections between developers grows exponentiallywith the size of the group. The larger the group, the more timethey'll spend in meetings negotiating how their software will worktogether, and the more bugs they'll get from unforeseen interactions.Fortunately, this process also works in reverse: as groups getsmaller, software development gets exponentially more efficient.I can't remember the programmers at Viaweb ever having an actualmeeting. We never had more to say at any one time than we couldsay as we were walking to lunch.If there is a downside here, it is that all the programmers haveto be to some degree system administrators as well. When you'rehosting software, someone has to be watching the servers, and inpractice the only people who can do this properly are the ones whowrote the software. At Viaweb our system had so many componentsand changed so frequently that there was no definite border betweensoftware and infrastructure. Arbitrarily declaring such a borderwould have constrained our design choices. And so although we wereconstantly hoping that one day ("in a couple months") everythingwould be stable enough that we could hire someone whose job wasjust to worry about the servers, it never happened.I don't think it could be any other way, as long as you're stillactively developing the product. Web-based software is never goingto be something you write, check in, and go home. It's a livething, running on your servers right now. A bad bug might not justcrash one user's process; it could crash them all. If a bug inyour code corrupts some data on disk, you have to fix it. And soon. We found that you don't have to watch the servers every minute(after the first year or so), but you definitely want to keep aneye on things you've changed recently. You don't release code lateat night and then go home.Watching UsersWith server-based software, you're in closer touch with your code.You can also be in closer touch with your users. Intuit is famousfor introducing themselves to customers at retail stores and askingto follow them home. If you've ever watched someone use yoursoftware for the first time, you know what surprises must haveawaited them.Software should do what users think it will. But you can't haveany idea what users will be thinking, believe me, until you watchthem. And server-based software gives you unprecedented informationabout their behavior. You're not limited to small, artificialfocus groups. You can see every click made by every user. Youhave to consider carefully what you're going to look at, becauseyou don't want to violate users' privacy, but even the most generalstatistical sampling can be very useful.When you have the users on your server, you don't have to rely onbenchmarks, for example. Benchmarks are simulated users. Withserver-based software, you can watch actual users. To decide whatto optimize, just log into a server and see what's consuming allthe CPU. And you know when to stop optimizing too: we eventuallygot the Viaweb editor to the point where it was memory-bound ratherthan CPU-bound, and since there was nothing we could do to decreasethe size of users' data (well, nothing easy), we knew we might aswell stop there.Efficiency matters for server-based software, because you're payingfor the hardware. The number of users you can support per serveris the divisor of your capital cost, so if you can make your softwarevery efficient you can undersell competitors and still make aprofit. At Viaweb we got the capital cost per user down to about$5. It would be less now, probably less than the cost of sendingthem the first month's bill. Hardware is free now, if your softwareis reasonably efficient.Watching users can guide you in design as well as optimization.Viaweb had a scripting language called RTML that let advanced usersdefine their own page styles. We found that RTML became a kind ofsuggestion box, because users only used it when the predefined pagestyles couldn't do what they wanted. Originally the editor putbutton bars across the page, for example, but after a number ofusers used RTML to put buttons down the left side, we made that anoption (in fact the default) in the predefined page styles.Finally, by watching users you can often tell when they're introuble. And since the customer is always right, that's a sign ofsomething you need to fix. At Viaweb the key to getting users wasthe online test drive. It was not just a series of slides builtby marketing people. In our test drive, users actually used thesoftware. It took about five minutes, and at the end of it theyhad built a real, working store.The test drive was the way we got nearly all our new users. Ithink it will be the same for most Web-based applications. Ifusers can get through a test drive successfully, they'll like theproduct. If they get confused or bored, they won't. So anythingwe could do to get more people through the test drive would increaseour growth rate.I studied click trails of people taking the test drive and foundthat at a certain step they would get confused and click on thebrowser's Back button. (If you try writing Web-based applications,you'll find that the Back button becomes one of your most interestingphilosophical problems.) So I added a message at that point, tellingusers that they were nearly finished, and reminding them not toclick on the Back button. Another great thing about Web-basedsoftware is that you get instant feedback from changes: the numberof people completing the test drive rose immediately from 60% to90%. And since the number of new users was a function of the numberof completed test drives, our revenue growth increased by 50%, justfrom that change.MoneyIn the early 1990s I read an article in which someone said thatsoftware was a subscription business. At first this seemed a verycynical statement. But later I realized that it reflects reality:software development is an ongoing process. I think it's cleanerif you openly charge subscription fees, instead of forcing peopleto keep buying and installing new versions so that they'll keeppaying you. And fortunately, subscriptions are the natural way tobill for Web-based applications.Hosting applications is an area where companies will play a rolethat is not likely to be filled by freeware. Hosting applicationsis a lot of stress, and has real expenses. No one is going to wantto do it for free.For companies, Web-based applications are an ideal source of revenue.Instead of starting each quarter with a blank slate, you have arecurring revenue stream. Because your software evolves gradually,you don't have to worry that a new model will flop; there neverneed be a new model, per se, and if you do something to the softwarethat users hate, you'll know right away. You have no trouble withuncollectable bills; if someone won't pay you can just turn offthe service. And there is no possibility of piracy.That last "advantage" may turn out to be a problem. Some amountof piracy is to the advantage of software companies. If some userreally would not have bought your software at any price, you haven'tlost anything if he uses a pirated copy. In fact you gain, becausehe is one more user helping to make your software the standard--or who might buy a copy later, when he graduates from high school.When they can, companies like to do something called pricediscrimination, which means charging each customer as much as theycan afford. [8] Software is particularly suitable for pricediscrimination, because the marginal cost is close to zero. Thisis why some software costs more to run on Suns than on Intel boxes:a company that uses Suns is not interested in saving money and cansafely be charged more. Piracy is effectively the lowest tier ofprice discrimination. I think that software companies understandthis and deliberately turn a blind eye to some kinds of piracy. [9] With server-based software they are going to have to come up with some other solution.Web-based software sells well, especially in comparison to desktopsoftware, because it's easy to buy. You might think that peopledecide to buy something, and then buy it, as two separate steps.That's what I thought before Viaweb, to the extent I thought aboutthe question at all. In fact the second step can propagate backinto the first: if something is hard to buy, people will changetheir mind about whether they wanted it. And vice versa: you'llsell more of something when it's easy to buy. I buy more booksbecause Amazon exists. Web-based software is just about the easiestthing in the world to buy, especially if you have just done anonline demo. Users should not have to do much more than enter acredit card number. (Make them do more at your peril.)Sometimes Web-based software is offered through ISPs acting asresellers. This is a bad idea. You have to be administering theservers, because you need to be constantly improving both hardwareand software. If you give up direct control of the servers, yougive up most of the advantages of developing Web-based applications.Several of our competitors shot themselves in the foot this way--usually, I think, because they were overrun by suits who wereexcited about this huge potential channel, and didn't realize thatit would ruin the product they hoped to sell through it. SellingWeb-based software through ISPs is like selling sushi throughvending machines.CustomersWho will the customers be? At Viaweb they were initially individualsand smaller companies, and I think this will be the rule withWeb-based applications. These are the users who are ready to trynew things, partly because they're more flexible, and partly becausethey want the lower costs of new technology.Web-based applications will often be the best thing for big companiestoo (though they'll be slow to realize it). The best intranet isthe Internet. If a company uses true Web-based applications, thesoftware will work better, the servers will be better administered,and employees will have access to the system from anywhere.The argument against this approach usually hinges on security: ifaccess is easier for employees, it will be for bad guys too. Somelarger merchants were reluctant to use Viaweb because they thoughtcustomers' credit card information would be safer on their ownservers. It was not easy to make this point diplomatically, butin fact the data was almost certainly safer in our hands thantheirs. Who can hire better people to manage security, a technologystartup whose whole business is running servers, or a clothingretailer? Not only did we have better people worrying aboutsecurity, we worried more about it. If someone broke into theclothing retailer's servers, it would affect at most one merchant,could probably be hushed up, and in the worst case might get oneperson fired. If someone broke into ours, it could affect thousandsof merchants, would probably end up as news on CNet, and could putus out of business.If you want to keep your money safe, do you keep it under yourmattress at home, or put it in a bank? This argument applies toevery aspect of server administration: not just security, butuptime, bandwidth, load management, backups, etc. Our existencedepended on doing these things right. Server problems were thebig no-no for us, like a dangerous toy would be for a toy maker,or a salmonella outbreak for a food processor.A big company that uses Web-based applications is to that extentoutsourcing IT. Drastic as it sounds, I think this is generallya good idea. Companies are likely to get better service this waythan they would from in-house system administrators. Systemadministrators can become cranky and unresponsive because they'renot directly exposed to competitive pressure: a salesman has todeal with customers, and a developer has to deal with competitors'software, but a system administrator, like an old bachelor, hasfew external forces to keep him in line. [10] At Viaweb we hadexternal forces in plenty to keep us in line. The people callingus were customers, not just co-workers. If a server got wedged,we jumped; just thinking about it gives me a jolt of adrenaline,years later.So Web-based applications will ordinarily be the right answer forbig companies too. They will be the last to realize it, however,just as they were with desktop computers. And partly for the samereason: it will be worth a lot of money to convince big companiesthat they need something more expensive.There is always a tendency for rich customers to buy expensivesolutions, even when cheap solutions are better, because the peopleoffering expensive solutions can spend more to sell them. At Viawebwe were always up against this. We lost several high-end merchantsto Web consulting firms who convinced them they'd be better off ifthey paid half a million dollars for a custom-made online store ontheir own server. They were, as a rule, not better off, as morethan one discovered when Christmas shopping season came around andloads rose on their server. Viaweb was a lot more sophisticatedthan what most of these merchants got, but we couldn't afford totell them. At $300 a month, we couldn't afford to send a team ofwell-dressed and authoritative-sounding people to make presentationsto customers.A large part of what big companies pay extra for is the cost ofselling expensive things to them. (If the Defense Department paysa thousand dollars for toilet seats, it's partly because it costsa lot to sell toilet seats for a thousand dollars.) And this isone reason intranet software will continue to thrive, even thoughit is probably a bad idea. It's simply more expensive. There isnothing you can do about this conundrum, so the best plan is to gofor the smaller customers first. The rest will come in time.Son of ServerRunning software on the server is nothing new. In fact it's theold model: mainframe applications are all server-based. Ifserver-based software is such a good idea, why did it lose lasttime? Why did desktop computers eclipse mainframes?At first desktop computers didn't look like much of a threat. Thefirst users were all hackers-- or hobbyists, as they were calledthen. They liked microcomputers because they were cheap. For thefirst time, you could have your own computer. The phrase "personalcomputer" is part of the language now, but when it was first usedit had a deliberately audacious sound, like the phrase "personalsatellite" would today.Why did desktop computers take over? I think it was because theyhad better software. And I think the reason microcomputer softwarewas better was that it could be written by small companies.I don't think many people realize how fragile and tentative startupsare in the earliest stage. Many startups begin almost by accident--as a couple guys, either with day jobs or in school, writing aprototype of something that might, if it looks promising, turn intoa company. At this larval stage, any significant obstacle will stopthe startup dead in its tracks. Writing mainframe software requiredtoo much commitment up front. Development machines were expensive,and because the customers would be big companies, you'd need animpressive-looking sales force to sell it to them. Starting astartup to write mainframe software would be a much more seriousundertaking than just hacking something together on your Apple IIin the evenings. And so you didn't get a lot of startups writingmainframe applications.The arrival of desktop computers inspired a lot of new software,because writing applications for them seemed an attainable goal tolarval startups. Development was cheap, and the customers wouldbe individual people that you could reach through computer storesor even by mail-order.The application that pushed desktop computers out into the mainstreamwas VisiCalc, the first spreadsheet. It was written by two guysworking in an attic, and yet did things no mainframe software coulddo. [11] VisiCalc was such an advance, in its time, that peoplebought Apple IIs just to run it. And this was the beginning of atrend: desktop computers won because startups wrote software forthem.It looks as if server-based software will be good this time around,because startups will write it. Computers are so cheap now thatyou can get started, as we did, using a desktop computer as aserver. Inexpensive processors have eaten the workstation market(you rarely even hear the word now) and are most of the way throughthe server market; Yahoo's servers, which deal with loads as highas any on the Internet, all have the same inexpensive Intel processorsthat you have in your desktop machine. And once you've writtenthe software, all you need to sell it is a Web site. Nearly allour users came direct to our site through word of mouth and referencesin the press. [12]Viaweb was a typical larval startup. We were terrified of startinga company, and for the first few months comforted ourselves bytreating the whole thing as an experiment that we might call offat any moment. Fortunately, there were few obstacles excepttechnical ones. While we were writing the software, our Web serverwas the same desktop machine we used for development, connected tothe outside world by a dialup line. Our only expenses in thatphase were food and rent.There is all the more reason for startups to write Web-based softwarenow, because writing desktop software has become a lot less fun.If you want to write desktop software now you do it on Microsoft'sterms, calling their APIs and working around their buggy OS. Andif you manage to write something that takes off, you may find thatyou were merely doing market research for Microsoft.If a company wants to make a platform that startups will build on,they have to make it something that hackers themselves will wantto use. That means it has to be inexpensive and well-designed.The Mac was popular with hackers when it first came out, and a lotof them wrote software for it. [13] You see this less with Windows,because hackers don't use it. The kind of people who are good atwriting software tend to be running Linux or FreeBSD now.I don't think we would have started a startup to write desktopsoftware, because desktop software has to run on Windows, and beforewe could write software for Windows we'd have to use it. The Web let us do an end-run around Windows, and deliver software running on Unix direct to users through the browser. That is a liberating prospect, a lot like the arrival of PCs twenty-five years ago.MicrosoftBack when desktop computers arrived, IBM was the giant that everyonewas afraid of. It's hard to imagine now, but I remember the feelingvery well. Now the frightening giant is Microsoft, and I don'tthink they are as blind to the threat facing them as IBM was.After all, Microsoft deliberately built their business in IBM'sblind spot.I mentioned earlier that my mother doesn't really need a desktopcomputer. Most users probably don't. That's a problem for Microsoft,and they know it. If applications run on remote servers, no oneneeds Windows. What will Microsoft do? Will they be able to usetheir control of the desktop to prevent, or constrain, this newgeneration of software?My guess is that Microsoft will develop some kind of server/desktophybrid, where the operating system works together with servers theycontrol. At a minimum, files will be centrally available for userswho want that. I don't expect Microsoft to go all the way to theextreme of doing the computations on the server, with only a browserfor a client, if they can avoid it. If you only need a browser fora client, you don't need Microsoft on the client, and if Microsoftdoesn't control the client, they can't push users towards theirserver-based applications.I think Microsoft will have a hard time keeping the genie in thebottle. There will be too many different types of clients for themto control them all. And if Microsoft's applications only workwith some clients, competitors will be able to trump them by offeringapplications that work from any client. [14]In a world of Web-based applications, there is no automatic placefor Microsoft. They may succeed in making themselves a place, butI don't think they'll dominate this new world as they did the worldof desktop applications.It's not so much that a competitor will trip them up as that theywill trip over themselves. With the rise of Web-based software,they will be facing not just technical problems but their ownwishful thinking. What they need to do is cannibalize their existingbusiness, and I can't see them facing that. The same single-mindednessthat has brought them this far will now be working against them.IBM was in exactly the same situation, and they could not masterit. IBM made a late and half-hearted entry into the microcomputerbusiness because they were ambivalent about threatening their cashcow, mainframe computing. Microsoft will likewise be hampered bywanting to save the desktop. A cash cow can be a damned heavymonkey on your back.I'm not saying that no one will dominate server-based applications.Someone probably will eventually. But I think that there will bea good long period of cheerful chaos, just as there was in theearly days of microcomputers. That was a good time for startups.Lots of small companies flourished, and did it by making coolthings.Startups but More SoThe classic startup is fast and informal, with few people and littlemoney. Those few people work very hard, and technology magnifiesthe effect of the decisions they make. If they win, they win big.In a startup writing Web-based applications, everything you associatewith startups is taken to an extreme. You can write and launch aproduct with even fewer people and even less money. You have tobe even faster, and you can get away with being more informal.You can literally launch your product as three guys sitting in theliving room of an apartment, and a server collocated at an ISP.We did.Over time the teams have gotten smaller, faster, and more informal.In 1960, software development meant a roomful of men with hornrimmed glasses and narrow black neckties, industriously writingten lines of code a day on IBM coding forms. In 1980, it was ateam of eight to ten people wearing jeans to the office and typinginto vt100s. Now it's a couple of guys sitting in a living roomwith laptops. (And jeans turn out not to be the last word ininformality.)Startups are stressful, and this, unfortunately, is also taken toan extreme with Web-based applications. Many software companies, especially at the beginning, have periodswhere the developers slept under their desks and so on. The alarmingthing about Web-based software is that there is nothing to preventthis becoming the default. The stories about sleeping under desksusually end: then at last we shipped it and we all went home andslept for a week. Web-based software never ships. You can work16-hour days for as long as you want to. And because you can, andyour competitors can, you tend to be forced to. You can, so youmust. It's Parkinson's Law running in reverse.The worst thing is not the hours but the responsibility. Programmersand system administrators traditionally each have their own separateworries. Programmers have to worry about bugs, and systemadministrators have to worry about infrastructure. Programmersmay spend a long day up to their elbows in source code, but at somepoint they get to go home and forget about it. System administratorsnever quite leave the job behind, but when they do get paged at4:00 AM, they don't usually have to do anything very complicated.With Web-based applications, these two kinds of stress get combined.The programmers become system administrators, but without thesharply defined limits that ordinarily make the job bearable.At Viaweb we spent the first six months just writing software. Weworked the usual long hours of an early startup. In a desktopsoftware company, this would have been the part where we wereworking hard, but it felt like a vacation compared to the nextphase, when we took users onto our server. The second biggestbenefit of selling Viaweb to Yahoo (after the money) was to be ableto dump ultimate responsibility for the whole thing onto theshoulders of a big company.Desktop software forces users to become system administrators.Web-based software forces programmers to. There is less stress intotal, but more for the programmers. That's not necessarily badnews. If you're a startup competing with a big company, it's goodnews. [15] Web-based applications offer a straightforward way tooutwork your competitors. No startup asks for more.Just Good EnoughOne thing that might deter you from writing Web-based applicationsis the lameness of Web pages as a UI. That is a problem, I admit.There were a few things we would have really liked to add toHTML and HTTP. What matters, though, is that Web pages are justgood enough.There is a parallel here with the first microcomputers. Theprocessors in those machines weren't actually intended to be theCPUs of computers. They were designed to be used in things liketraffic lights. But guys like Ed Roberts, who designed the Altair,realized that they were just good enough. You could combine oneof these chips with some memory (256 bytes in the first Altair),and front panel switches, and you'd have a working computer. Beingable to have your own computer was so exciting that there wereplenty of people who wanted to buy them, however limited.Web pages weren't designed to be a UI for applications, but they'rejust good enough. And for a significant number of users, softwarethat you can use from any browser will be enough of a win in itselfto outweigh any awkwardness in the UI. Maybe you can't write thebest-looking spreadsheet using HTML, but you can write a spreadsheetthat several people can use simultaneously from different locationswithout special client software, or that can incorporate live datafeeds, or that can page you when certain conditions are triggered.More importantly, you can write new kinds of applications thatdon't even have names yet. VisiCalc was not merely a microcomputerversion of a mainframe application, after all-- it was a new typeof application.Of course, server-based applications don't have to be Web-based.You could have some other kind of client. But I'm pretty surethat's a bad idea. It would be very convenient if you could assumethat everyone would install your client-- so convenient that youcould easily convince yourself that they all would-- but if theydon't, you're hosed. Because Web-based software assumes nothingabout the client, it will work anywhere the Web works. That's abig advantage already, and the advantage will grow as new Webdevices proliferate. Users will like you because your softwarejust works, and your life will be easier because you won't have totweak it for every new client. [16]I feel like I've watched the evolution of the Web as closely asanyone, and I can't predict what's going to happen with clients.Convergence is probably coming, but where? I can't pick a winner.One thing I can predict is conflict between AOL and Microsoft.Whatever Microsoft's .NET turns out to be, it will probably involveconnecting the desktop to servers. Unless AOL fights back, theywill either be pushed aside or turned into a pipe between Microsoftclient and server software. If Microsoft and AOL get into a clientwar, the only thing sure to work on both will be browsing the Web,meaning Web-based applications will be the only kind that workeverywhere.How will it all play out? I don't know. And you don't have toknow if you bet on Web-based applications. No one can break thatwithout breaking browsing. The Web may not be the only way todeliver software, but it's one that works now and will continue towork for a long time. Web-based applications are cheap to develop,and easy for even the smallest startup to deliver. They're a lotof work, and of a particularly stressful kind, but that only makesthe odds better for startups.Why Not?E. B. White was amused to learn from a farmer friend that manyelectrified fences don't have any current running through them.The cows apparently learn to stay away from them, and after thatyou don't need the current. "Rise up, cows!" he wrote, "Take yourliberty while despots snore!"If you're a hacker who has thought of one day starting a startup,there are probably two things keeping you from doing it. One isthat you don't know anything about business. The other is thatyou're afraid of competition. Neither of these fences have anycurrent in them.There are only two things you have to know about business: buildsomething users love, and make more than you spend. If you getthese two right, you'll be ahead of most startups. You can figureout the rest as you go.You may not at first make more than you spend, but as long as thegap is closing fast enough you'll be ok. If you start out underfunded,it will at least encourage a habit of frugality. The less youspend, the easier it is to make more than you spend. Fortunately,it can be very cheap to launch a Web-based application. We launchedon under $10,000, and it would be even cheaper today. We had tospend thousands on a server, and thousands more to get SSL. (Theonly company selling SSL software at the time was Netscape.) Nowyou can rent a much more powerful server, with SSL included, forless than we paid for bandwidth alone. You could launch a Web-basedapplication now for less than the cost of a fancy office chair.As for building something users love, here are some general tips.Start by making something clean and simple that you would want touse yourself. Get a version 1.0 out fast, then continue to improvethe software, listening closely to the users as you do. The customeris always right, but different customers are right about differentthings; the least sophisticated users show you what you need tosimplify and clarify, and the most sophisticated tell you whatfeatures you need to add. The best thing software can be is easy,but the way to do this is to get the defaults right, not to limitusers' choices. Don't get complacent if your competitors' softwareis lame; the standard to compare your software to is what it couldbe, not what your current competitors happen to have. Use yoursoftware yourself, all the time. Viaweb was supposed to be anonline store builder, but we used it to make our own site too.Don't listen to marketing people or designers or product managersjust because of their job titles. If they have good ideas, usethem, but it's up to you to decide; software has to be designed byhackers who understand design, not designers who know a littleabout software. If you can't design software as well as implementit, don't start a startup.Now let's talk about competition. What you're afraid of is notpresumably groups of hackers like you, but actual companies, withoffices and business plans and salesmen and so on, right? Well,they are more afraid of you than you are of them, and they're right.It's a lot easier for a couple of hackers to figure out how to rentoffice space or hire sales people than it is for a company of anysize to get software written. I've been on both sides, and I know.When Viaweb was bought by Yahoo, I suddenly found myself workingfor a big company, and it was like trying to run through waist-deepwater.I don't mean to disparage Yahoo. They had some good hackers, andthe top management were real butt-kickers. For a big company, theywere exceptional. But they were still only about a tenth asproductive as a small startup. No big company can do much betterthan that. What's scary about Microsoft is that a company sobig can develop software at all. They're like a mountain thatcan walk.Don't be intimidated. You can do as much that Microsoft can't asthey can do that you can't. And no one can stop you. You don'thave to ask anyone's permission to develop Web-based applications.You don't have to do licensing deals, or get shelf space in retailstores, or grovel to have your application bundled with the OS.You can deliver software right to the browser, and no one can getbetween you and potential users without preventing them from browsingthe Web.You may not believe it, but I promise you, Microsoft is scared ofyou. The complacent middle managers may not be, but Bill is,because he was you once, back in 1975, the last time a new way ofdelivering software appeared.Notes[1] Realizing that much of the money is in the services, companiesbuilding lightweight clients have usually tried to combine thehardware with an online service. This approach has not workedwell, partly because you need two different kinds of companies tobuild consumer electronics and to run an online service, and partlybecause users hate the idea. Giving away the razor and makingmoney on the blades may work for Gillette, but a razor is muchsmaller commitment than a Web terminal. Cell phone handset makersare satisfied to sell hardware without trying to capture the servicerevenue as well. That should probably be the model for Internetclients too. If someone just sold a nice-looking little box witha Web browser that you could use to connect through any ISP, everytechnophobe in the country would buy one.[2] Security always depends more on not screwing up than any designdecision, but the nature of server-based software will make developerspay more attention to not screwing up. Compromising a server couldcause such damage that ASPs (that want to stay in business) arelikely to be careful about security.[3] In 1995, when we started Viaweb, Java applets were supposed tobe the technology everyone was going to use to develop server-basedapplications. Applets seemed to us an old-fashioned idea. Downloadprograms to run on the client? Simpler just to go all the way andrun the programs on the server. We wasted little timeon applets, but countless other startups must have been lured intothis tar pit. Few can have escaped alive, or Microsoft could nothave gotten away with dropping Java in the most recent version ofExplorer.[4] This point is due to Trevor Blackwell, who adds "the cost ofwriting software goes up more than linearly with its size. Perhapsthis is mainly due to fixing old bugs, and the cost can be morelinear if all bugs are found quickly."[5] The hardest kind of bug to find may be a variant of compoundbug where one bug happens to compensate for another. When you fixone bug, the other becomes visible. But it will seem as if thefix is at fault, since that was the last thing you changed.[6] Within Viaweb we once had a contest to describe the worst thingabout our software. Two customer support people tied for firstprize with entries I still shiver to recall. We fixed both problemsimmediately.[7] Robert Morris wrote the ordering system, which shoppers usedto place orders. Trevor Blackwell wrote the image generator andthe manager, which merchants used to retrieve orders, view statistics,and configure domain names etc. I wrote the editor, which merchantsused to build their sites. The ordering system and image generatorwere written in C and C++, the manager mostly in Perl, and the editorin Lisp.[8] Price discrimination is so pervasive (how often have you hearda retailer claim that their buying power meant lower prices foryou?) that I was surprised to find it was outlawed in the U.S. bythe Robinson-Patman Act of 1936. This law does not appear to bevigorously enforced.[9] In No Logo, Naomi Klein says that clothing brands favored by"urban youth" do not try too hard to prevent shoplifting becausein their target market the shoplifters are also the fashion leaders.[10] Companies often wonder what to outsource and what not to.One possible answer: outsource any job that's not directly exposedto competitive pressure, because outsourcing it will thereby exposeit to competitive pressure.[11] The two guys were Dan Bricklin and Bob Frankston. Dan wrotea prototype in Basic in a couple days, then over the course of thenext year they worked together (mostly at night) to make a morepowerful version written in 6502 machine language. Dan was atHarvard Business School at the time and Bob nominally had a dayjob writing software. "There was no great risk in doing a business,"Bob wrote, "If it failed it failed. No big deal."[12] It's not quite as easy as I make it sound. It took a painfullylong time for word of mouth to get going, and we did not start toget a lot of press coverage until we hired a PR firm (admittedlythe best in the business) for $16,000 per month. However, it wastrue that the only significant channel was our own Web site.[13] If the Mac was so great, why did it lose? Cost, again.Microsoft concentrated on the software business, and unleashed aswarm of cheap component suppliers on Apple hardware. It did nothelp, either, that suits took over during a critical period.[14] One thing that would help Web-based applications, and helpkeep the next generation of software from being overshadowed byMicrosoft, would be a good open-source browser. Mozilla isopen-source but seems to have suffered from having been corporatesoftware for so long. A small, fast browser that was activelymaintained would be a great thing in itself, and would probablyalso encourage companies to build little Web appliances.Among other things, a proper open-source browser would cause HTTPand HTML to continue to evolve (as e.g. Perl has). It would helpWeb-based applications greatly to be able to distinguish betweenselecting a link and following it; all you'd need to do this wouldbe a trivial enhancement of HTTP, to allow multiple urls in arequest. Cascading menus would also be good.If you want to change the world, write a new Mosaic. Think it'stoo late? In 1998 a lot of people thought it was too late to launcha new search engine, but Google proved them wrong. There is alwaysroom for something new if the current options suck enough. Makesure it works on all the free OSes first-- new things start withtheir users.[15] Trevor Blackwell, who probably knows more about this frompersonal experience than anyone, writes:"I would go farther in saying that because server-based softwareis so hard on the programmers, it causes a fundamental economicshift away from large companies. It requires the kind of intensityand dedication from programmers that they will only be willing toprovide when it's their own company. Software companies can hireskilled people to work in a not-too-demanding environment, and canhire unskilled people to endure hardships, but they can't hirehighly skilled people to bust their asses. Since capital is nolonger needed, big companies have little to bring to the table."[16] In the original version of this essay, I advised avoidingJavascript. That was a good plan in 2001, but Javascript now works.Thanks to Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson,and Dan Giffin for reading drafts of this paper; to Dan Bricklin andBob Frankston for information about VisiCalc; and again to Ken Andersonfor inviting me to speak at BBN.
