September 2001

*(This article explains why much of the next generation of software may 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 to start a startup.

The PR campaign leading up to Netscape's IPO was running full blast then, and there was a lot of talk in the press about online commerce.

At the time there might have been thirty actual stores on the Web, all made by hand.

If there were going to be a lot of online stores, there would need to be software for making them, 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 the software run on our Web server, using the browser as an interface.

We tried rewriting the software to work over the 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 easier for the users and for us as well.

This turned out to be a good plan.

Now, as Yahoo Store, this software is the most popular online store builder, with about 14,000 users.

When we started Viaweb, hardly anyone understood what we meant when we said that the software ran on the server.

It was not until Hotmail was launched a year later that people started to get it.

Now everyone knows that this is a valid approach.

There is a name now for what we were: an Application Service Provider, or ASP.

I think that a lot of the next generation of software will be written on this model.

Even Microsoft, who have the most to lose, seem to see the inevitablity of moving some things off the desktop.

If software moves off the desktop and onto servers, it will mean a very different world for developers.

This article describes the surprising things we saw, as some of the first visitors to this new world.

To the extent software does move onto servers, what I'm describing here is the future.

In the summer of 1995, Robert Morris and I decided to start a startup. Netscape's IPO had everyone talking about online commerce, and there might have been thirty actual stores on the Web, all made by hand. If there were going to be a lot, there'd need to be software for making them, so we decided to write some.

For the first week we intended an ordinary desktop application. Then we had the idea of running it on our Web server, using the browser as an interface. It was clearly the way to go: easier for the users and for us. Now, as Yahoo Store, it's the most popular online store builder, with about 14,000 users.

When we started Viaweb, hardly anyone understood software that ran on the server. It wasn't until Hotmail launched a year later that people got it. Now there's even a name for what we were, an Application Service Provider, and I think a lot of the next generation of software will be written this way.

If software moves off the desktop and onto servers, it will mean a very different world for developers. This article describes the surprising things we saw as some of the first visitors to that world—which, to the extent software does move onto servers, is the future.

In 1995 Robert Morris and I set out to write software for building online stores, and almost by accident ran it on our Web server instead of the desktop. That became Yahoo Store, and that model is where the next generation of software is headed.

The Next Thing?

When we look back on the desktop software era, I think we'll marvel at the inconveniences people put up with, just as we marvel now at what early car owners put up with.

For the first twenty or thirty years, you had to be a car expert to own a car.

But cars were such a big win that lots of people who weren't car experts wanted to have 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's happening inside it.

But more than half the households in the US own one.

My mother has a computer that she uses for email and for keeping accounts.

About a year ago she was alarmed to receive a letter from Apple, offering her a discount on a new version of the operating system.

There's something wrong when a sixty-five year old woman who wants to use a computer for email and accounts has to think about installing new operating systems. Ordinary users shouldn't even know the words "operating system," much less "device driver" or "patch."

There is now another way to deliver software that will save users from becoming system administrators.

Web-based applications are programs that run on Web servers and use Web pages as the user interface.

For the average user this new kind of software will be easier, cheaper, more mobile, more reliable, and often more powerful than desktop software.

With Web-based software, most users won't have to think about anything except the applications they use.

All the messy, changing stuff will be sitting on a server somewhere, maintained by the kind of people who are good at that kind of thing.

And so you won't ordinarily need a computer, per se, to use software.

All you'll need will be something with a keyboard, a screen, and a Web browser.

Maybe it will have wireless Internet access.

Maybe it will also be your cell phone.

Whatever it is, it will be consumer electronics: something that costs about $200, and that people choose mostly based on how the case looks.

You'll pay more for Internet services than 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 the server and back, so users of heavily interactive software, like Photoshop, will still want to have the computations happening on the desktop.

But if you look at the kind of things most people use computers for, a tenth of a second latency would not be a problem.

My mother doesn't really need a desktop computer, and there are a lot of people like her.

We'll someday marvel at the inconveniences of the desktop era, just as we marvel at what early car owners put up with: for the first twenty or thirty years, you had to be a car expert to own one. But cars were such a big win that lots of non-experts wanted them anyway.

Computers are in that phase now: own a desktop and you learn far more than you wanted to about what's inside it. My mother uses hers for email and accounts, and was alarmed to get a letter from Apple offering a discount on a new operating system. Ordinary users shouldn't even know the words "operating system," much less "device driver" or "patch."

There's now another way to deliver software that saves users from becoming system administrators. Web-based applications run on Web servers and use Web pages as the interface, and for the average user they'll be easier, cheaper, more mobile, more reliable, and often more powerful than desktop software.

The messy, changing stuff sits on a server, maintained by people good at that, so you won't really need a computer—just something with a keyboard, a screen, and a browser. Whatever it is, it'll be consumer electronics: about $200, chosen mostly on how the case looks. You'll pay more for the Internet service than the hardware, as you do now with telephones.

Owning a desktop computer today is like owning a car in its first decades: you have to be an expert just to use it. Web-based applications can deliver software without forcing ordinary users to become system administrators.

The Win for Users

Near my house there is a car with a bumper sticker that reads "death before inconvenience."

Most people, most of the time, will take whatever choice requires least work.

If Web-based software wins, it will be because it's more convenient.

And it looks as if it will be, for users and developers both.

To use a purely Web-based application, all you need is a browser connected to the Internet.

So you can use a Web-based application anywhere.

When you install software on your desktop computer, you can only use it on that computer.

Worse still, your files are trapped on that computer.

The inconvenience of this model becomes more and more evident as people get used to networks.

The thin end of the wedge here was Web-based email.

Millions of people now realize that you should have access to email messages no matter where you are.

And if you can see your email, why not your calendar?

If you can discuss a document with your colleagues, why can't you edit it?

Why should any of your data be trapped on some computer sitting on a faraway desk?

The whole idea of "your computer" is going away, and being replaced with "your data." You should be able to get at your data from any computer.

Or rather, any client, and a client doesn't have to be a computer.

Clients shouldn't store data; they should be like telephones.

In fact they may become telephones, or vice versa.

And as clients get smaller, you have another reason not to keep your data on them: something you carry around with you can be lost or stolen.

Leaving your PDA in a taxi is like a disk crash, except that your data is handed to someone else instead of being vaporized.

With purely Web-based software, neither your data nor the applications are kept on the client.

So you don't have to install anything to use it.

And when there's no installation, you don't have to worry about installation going wrong.

There can't be incompatibilities between the application and your operating system, because the software doesn't run on your operating system.

Because it needs no installation, it will be easy, and common, to try Web-based software before you "buy" it.

You should expect to be able to test-drive any Web-based application for free, just by going to the site where it's offered.

At Viaweb our whole site was like a big arrow pointing users to the test drive.

After trying the demo, signing up for the service should require nothing 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-based software, you should get new releases without paying extra, or doing any work, or possibly even knowing about it.

Upgrades won't be the big shocks they are now.

Over time applications will quietly grow more powerful.

This will take some effort on the part of the developers.

They will have to design software so that it can be updated without confusing the users.

That's a new problem, but there are ways to solve it.

With Web-based applications, everyone uses the same version, and bugs can be fixed as soon as they're discovered.

So Web-based software should have far fewer bugs than desktop software.

At Viaweb, I doubt we ever had ten known bugs at any one time.

That's orders of magnitude better than desktop software.

Web-based applications can be used by several people at the same time.

This is an obvious win for collaborative applications, but I bet users will start to want this in most applications once they realize it's possible.

It will often be useful to let two people edit the same document, for example.

Viaweb let multiple users edit a site simultaneously, more because that was the right way to write the software than because we expected users to want to, but it 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 hear about them anymore.

They'll happen within server farms. And companies offering Web-based applications will actually do backups-- not only because they'll have real system administrators worrying about such things, but because an ASP that does lose people's data will be in big, big trouble.

When people lose their own data in a disk crash, they can't get that mad, because they only have themselves 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 less chance of running viruses, and no data locally to damage.

And a program that attacked the servers themselves should find them very well defended. [2]

For users, Web-based software will be less stressful. I think if you looked inside the average Windows user you'd find a huge and pretty much untapped desire for software meeting that description.

Unleashed, it could be a powerful force.

Near my house there's a car with a bumper sticker reading "death before inconvenience." Most people, most of the time, take whatever choice requires least work. If Web-based software wins, it'll be because it's more convenient—and it looks as if it will be.

To use a purely Web-based application, all you need is a browser, so you can use it anywhere; install software on your desktop and your files are trapped there. The thin end of the wedge was Web-based email: millions realized you should reach your messages wherever you are. And if you can see your email, why not your calendar? If you can discuss a document with colleagues, why can't you edit it?

The whole idea of "your computer" is going away, replaced with "your data," which you should reach from any client—and a client doesn't have to be a computer. Clients shouldn't store data; they should be like telephones. And as they shrink, leaving your PDA in a taxi is like a disk crash, except your data is handed to someone else instead of vaporized.

With purely Web-based software, neither your data nor the applications live on the client, so there's nothing to install—and nothing about installation can go wrong. There can't even be incompatibilities with your operating system, because the software doesn't run on it.

You should be able to test-drive any application for free by visiting the site, and after the demo, signing up should be the last work the user does. You then get new releases without paying extra, doing any work, or even knowing about it. Upgrades won't be the big shocks they are now; applications will quietly grow more powerful.

Everyone uses the same version, and bugs are fixed the moment they're found, so Web-based software should have far fewer—at Viaweb I doubt we ever had ten known bugs at once. And several people can use it at once: an obvious win for collaborative software, but I bet users will want it almost everywhere once they see it's possible.

Your data is also safer. Disk crashes won't vanish, but they'll happen inside server farms, and ASPs will actually do backups—mostly because one that loses people's data is in big, big trouble. People who lose their own data can't get that mad; when a company loses it for them, they get a lot madder.

Finally, it should be less vulnerable to viruses: a client running nothing but a browser has little to infect. For users, Web-based software will be less stressful. Inside the average Windows user is a huge, untapped desire for that. Unleashed, it could be a powerful force.

People take whatever requires least work, and Web-based software wins on convenience: your data follows you anywhere, nothing to install, free test drives, automatic upgrades, fewer bugs, real collaboration, and safer data.

City of Code

To developers, the most conspicuous difference between Web-based and desktop software is that a Web-based application is not a single piece of code.

It will be a collection of programs of different types rather than a single big binary.

And so designing Web-based software is like desiging a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters.

At Viaweb, software included fairly big applications that users talked to directly, programs that those programs used, programs that ran constantly in the background looking for problems, programs that tried to restart things if they broke, programs that ran occasionally to compile statistics or build indexes for searches, programs we ran explicitly to garbage-collect resources or to move or restore data, programs that pretended to be users (to measure performance or expose bugs), programs for diagnosing network troubles, programs for doing backups, interfaces to outside services, software that drove an impressive collection of dials displaying real-time server statistics (a hit with visitors, but indispensable for us too), modifications (including bug fixes) to open-source software, and a great many configuration files and settings.

Trevor Blackwell wrote a spectacular program for moving stores to new servers across the country, without shutting them down, after we were bought by Yahoo.

Programs paged us, sent faxes and email to users, conducted transactions with credit card processors, and talked to one another through sockets, pipes, http requests, ssh, udp packets, shared memory, and files.

Some of Viaweb even consisted of the absence of programs, since one of the keys to Unix security is not to run unnecessary utilities that people might use to break into your servers.

It did not end with software.

We spent a lot of time thinking about server configurations.

We built the servers ourselves, from components-- partly to save money, and partly to get exactly what we wanted.

We had to think about whether our upstream ISP had fast enough connections to all the backbones.

We serially dated RAID suppliers.

But hardware is not just something to worry about.

When you control it you can do more for users.

With a desktop application, you can specify certain minimum hardware, but you can't add more.

If you administer the servers, you can in one step enable all your users to page people, or send faxes, or send commands by phone, or process credit cards, etc, just by installing the relevant hardware.

We always looked for new ways to add features with hardware, not just because it pleased users, but also as a way to distinguish ourselves from competitors who (either because they sold desktop software, or resold Web-based applications through ISPs) didn't have direct control over the hardware.

Because the software in a Web-based application will be a collection of programs rather than a single binary, it can be written in any number of different languages.

When you're writing desktop software, you're practically forced to write the application in the same language as the underlying operating system-- meaning C and C++.

And so these languages (especially among nontechnical people like managers and VCs) got to be considered as the languages for "serious" software development.

But that was just an artifact of the way desktop software had to be delivered.

For server-based software you can use any language you want. [3] Today a lot of the top hackers 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 to use, because you control the whole system, right down to the hardware.

Different languages are good for different tasks.

You can use whichever is best for each.

And when you have competitors, "you can" means "you must" (we'll return to this later), because if you don't take advantage of this possibility, your competitors will.

Most of our competitors used C and C++, and this made their software visibly inferior because (among other things), they had no way around the statelessness of CGI scripts.

If you were going to change something, all the changes had to happen on one page, with an Update button at the bottom.

As I've written elsewhere, by using Lisp [blocked], which many people still consider a research language, we could make the Viaweb editor behave more like desktop software.

To developers, the most conspicuous difference is that a Web-based application is not a single piece of code but a collection of programs of different types. So designing it is like designing a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for growth and disasters.

At Viaweb the software included big applications users talked to, watchdogs that restarted broken things, programs that compiled statistics or pretended to be users to expose bugs, dials of real-time server stats, plus fixes to open-source software and countless config files. Some of Viaweb even consisted of the absence of programs, since a key to Unix security is not running utilities people could use to break in.

And hardware isn't just something to worry about—when you control it you can do more. With a desktop application you can specify minimum hardware but can't add more; administer the servers and you can in one step let all your users page people or process credit cards, just by installing it. It also distinguished us from competitors who didn't control theirs.

Because the software is a collection of programs, it can be written in any number of languages. With desktop software you're practically forced into the language of the operating system—C and C++—which is how those came to seem the languages for "serious" development. For server-based software you can use any language, and the top hackers now use Perl, Python, even Lisp.

Most competitors used C and C++, which made their software visibly inferior: they had no way around the statelessness of CGI scripts, so every change happened on one page with an Update button. By using Lisp [blocked], which many still consider a research language, we could make the Viaweb editor behave more like desktop software.

A Web-based application isn't one binary but a collection of programs, so designing it is like designing a city rather than a building. Because you control the system down to the hardware, you can add features with hardware and use whatever language is best.

Releases

One of the most important changes in this new world is the way you do releases.

In the desktop software business, doing a release is a huge trauma, in which the whole company sweats and strains to push out a single, giant piece of code.

Obvious comparisons suggest themselves, both to the process and the resulting product.

With server-based software, you can make changes almost as you would in a program you were writing for yourself.

You release software as a series of incremental changes instead of an occasional big explosion.

A typical desktop software company might do one or two releases a year.

At Viaweb we often did three to five releases a day.

When you switch to this new model, you realize how much software development is affected by the way it is released.

Many of the nastiest problems you see in the desktop software business are due to catastrophic nature of releases.

When you release only one new version a year, you tend to deal with bugs wholesale.

Some time before the release date you assemble a new version in which half the code has been torn out and replaced, introducing countless bugs.

Then a squad of QA people step in and start counting them, and the programmers work down the list, fixing them.

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 of a 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 and incremental.

That in itself is less likely to introduce bugs.

It also means you know what to test most carefully when you're about to release software: the last thing you changed.

You end up with a much firmer grip on the code.

As a general rule, you do know what'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 pilot scanning the instrument panel, not like a detective trying to unravel some mystery.

Desktop software breeds a certain fatalism about bugs.

You know that you're shipping something loaded with bugs, and you've even set up mechanisms to compensate for it (e.g. patch releases).

So why worry about a few more?

Soon you're releasing whole features you know are broken. Apple did this earlier this year.

They felt under pressure to release their new OS, whose release date had already slipped four times, but some of the software (support for CDs and DVDs) wasn't ready.

The solution?

They released the OS without the unfinished parts, and users will have to install them later.

With Web-based software, you never have to release software before it works, and you can release it as soon as it does work.

The industry veteran may be thinking, it's a fine-sounding idea to say that you never have to release software before it works, but what happens when you've promised to deliver a new version of your software by a certain date?

With Web-based software, you wouldn't make such a promise, because there are no versions.

Your software changes gradually and continuously.

Some changes might be bigger than others, but the idea of versions just doesn't naturally fit onto Web-based software.

If anyone remembers Viaweb this might sound odd, because we were always announcing new versions.

This was done entirely for PR purposes.

The trade press, we learned, thinks in version numbers.

They will give you major coverage for a major release, meaning a new first digit on the version number, and generally a paragraph at most for a point release, meaning a new digit after the decimal point.

Some of our competitors were offering desktop software and actually had version numbers.

And for these releases, the mere fact of which seemed to us evidence of their backwardness, they would get all kinds of publicity.

We didn't want to miss out, so we started giving version numbers to our software too.

When we wanted some publicity, we'd make a list of all the features we'd added since the last "release," stick a new version number on the software, and issue a press release saying that the new version was available immediately.

Amazingly, no one ever called us on it.

By the time we were bought, we had done this three times, so we were on Version 4.

Version 4.1 if I remember correctly.

After Viaweb became Yahoo Store, there was no longer such a desperate need for publicity, so although the software continued to evolve, the whole idea of version numbers was quietly dropped.

One of the most important changes is how you do releases. In the desktop business a release is a huge trauma, the whole company straining to push out one giant piece of code. With server-based software you make changes as you would in a program you wrote for yourself: a series of incremental changes instead of an occasional big explosion. A typical desktop company does one or two a year; at Viaweb we often did three to five a day.

Many of the desktop business's nastiest problems come from the catastrophic nature of releases. When you release once a year you deal with bugs wholesale: you assemble a version with half the code torn out and replaced, introducing countless bugs, then QA people count them while programmers work down a list they never finish. It's like fishing rubble out of a pond. At best you end up with a statistical sort of correctness.

With server-based software most change is small and incremental, less likely to introduce bugs, and it tells you what to test before a release: the last thing you changed. You don't have the source memorized, but when you read it you do it like a pilot scanning the instrument panel, not like a detective unraveling a mystery.

Desktop software breeds a fatalism about bugs. You're shipping something loaded with them, you've built patch releases to compensate, so why worry about a few more? Soon you're releasing whole features you know are broken. Apple did this this year: under pressure to ship an OS whose date had slipped four times, they shipped without the unfinished parts and made users install them later.

With Web-based software, you never have to release software before it works, and you can release it as soon as it does work.

Yet we were always announcing new versions—purely for PR. The trade press thinks in version numbers, so when we wanted attention we'd list the features added since the last "release," stick on a number, and issue a press release. Amazingly, no one ever called us on it. By the time we were bought we were on Version 4; after Viaweb became Yahoo Store the whole idea was quietly dropped.

In desktop software a release is a giant trauma; with server-based software you ship a series of small incremental changes—we did three to five a day. You never have to release before it works, and there are no versions, only continuous evolution.

Bugs

The other major technical advantage of Web-based software is that you can reproduce most bugs.

You have the users' data right there on your disk.

If someone breaks your software, you don't have to try to guess what's going on, as you would with desktop software: you should be able to reproduce the error while they're on the phone with you.

You might even know about it already, if you have code for noticing errors built into your application.

Web-based software gets used round the clock, so everything you do is immediately put through the wringer.

Bugs turn up quickly.

Software companies are sometimes accused of letting the users debug their software.

And that is just what I'm advocating.

For Web-based software it's actually a good plan, because the bugs are fewer and transient.

When you release software gradually you get far fewer bugs to start with.

And when you can reproduce errors and release changes instantly, you can find and fix most bugs as soon as they appear.

We never had enough bugs at any one time to bother with a formal bug-tracking system.

You should test changes before you release them, of course, so no major bugs should get released.

Those few that inevitably slip through will involve borderline cases and will only affect the few users that encounter them before someone calls in to complain.

As long as you fix bugs right away, the net effect, for the average user, is far fewer bugs.

I doubt the average Viaweb user ever saw a bug.

Fixing fresh bugs is easier than fixing old ones.

It's usually fairly quick to find a bug in code you just wrote.

When it turns up you often know what's wrong before you even look at the source, because you were already worrying about it subconsciously.

Fixing a bug in something you wrote six months ago (the average case if you release once a year) is a lot more work.

And since you don't understand the code as well, you're more likely to fix it in an ugly 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 going downstairs, and when you reach for the handrail it comes off in your 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 inherently yields a lot of compound bugs.

And software that's released in a series of small changes inherently tends not to.

The floors are constantly being swept clean of any loose objects that might later get stuck in something.

It helps if you use a technique called functional programming.

Functional programming means avoiding side-effects.

It's something you're more likely to see in research papers than commercial software, but for Web-based applications it turns out to be really useful.

It's hard to write entire programs as purely functional code, but you can write substantial chunks this way.

It makes those parts of your software easier to test, because they have no state, and that is very convenient in a situation where you are constantly making and testing small modifications.

I wrote much of 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 to credit, but at Viaweb bugs became almost a game.

Since most released bugs involved borderline cases, the users who encountered them were likely to be advanced users, pushing the envelope.

Advanced users are more forgiving about bugs, especially since you probably introduced them in the course of adding some feature they were asking for.

In fact, because bugs were rare and you had to be doing sophisticated things to see them, advanced users were often proud to catch one.

They would call support in a spirit more of triumph than anger, as if they had scored points off us.

Support

When you can reproduce errors, it changes your approach to customer support.

At most software companies, support is offered as a way to make customers feel better.

They're either calling you about a known bug, or they're just doing something wrong and you have to figure out what.

In either case there's not much you can learn from them.

And so you tend to view support calls as a pain in the ass that you want to isolate from your developers as much as possible.

This was not how things worked at Viaweb.

At Viaweb, support was free, because we wanted to hear from customers.

If someone had a problem, we wanted to know about it right away so that we could reproduce the error and release a fix.

So at Viaweb the developers were always in close contact with support.

The customer support people were about thirty feet away from the programmers, and knew that they could always interrupt anything with a report of a genuine bug.

We would leave a board meeting to fix a serious bug.

Our approach to support made everyone happier.

The customers were delighted.

Just imagine how it would feel to call a support line and be treated as someone bringing important news.

The customer support people liked it because it meant they could help the users, instead of reading scripts to them.

And the programmers liked it because they could reproduce bugs instead of just hearing vague second-hand reports about them.

Our policy of fixing bugs on the fly changed the relationship between customer support people and hackers.

At most software companies, support people are underpaid human shields, and hackers are little copies of God the Father, creators of the world.

Whatever the procedure for reporting bugs, it is likely to be one-directional: support people who hear about bugs fill out some form that eventually gets passed on (possibly via QA) to programmers, who put it on their list of things to do.

It was very different at Viaweb.

Within a minute of hearing about a bug from a customer, the support people could be standing next to a programmer hearing him say "Shit, you're right, it's a bug." It delighted the support people to hear that "you're right" from the hackers.

They used to bring us bugs with the same expectant air as a cat bringing you a mouse it has just killed.

It also made them more careful in judging the seriousness of a bug, because now their honor was on the line.

After we were bought by Yahoo, the customer support people were moved far away from the programmers.

It was only then that we realized that they were effectively QA and to some extent marketing as well.

In addition to catching bugs, they were the keepers of the knowledge of vaguer, buglike things, like features that confused users. [6] They were also a kind of proxy focus group; we could ask them which of two new features users wanted more, and they were always right.

The other major advantage is that you can reproduce most bugs. The users' data is right there on your disk. If someone breaks your software you don't have to guess—you can reproduce the error while they're on the phone, and may know about it already if you've built in code for noticing errors.

Web-based software is used round the clock, so bugs turn up fast. Companies are accused of letting users debug their software, and that's just what I advocate: gradual release means far fewer bugs to start with, and reproducing errors and shipping fixes instantly means you catch most as they appear. We never had enough to bother with a bug-tracking system.

You test before releasing, so no major bug escapes; the few that slip through involve borderline cases. And fixing fresh bugs is easier than fixing old ones: a bug in code you just wrote is quick to find, because you were worrying about it subconsciously, while one from six months ago is more work and likelier to get fixed in an ugly way.

Catch bugs early and you also get fewer compound bugs—two separate bugs that interact: you trip going downstairs, and the handrail comes off in your hand. These are the hardest to find and have the worst consequences. The "break everything and filter out the bugs" approach yields a lot of them; small changes don't. The floors are constantly swept clean of loose objects that might later get stuck in something.

Functional programming helps—avoiding side-effects. You see it more in research papers than commercial software, but it's really useful here: stateless code is easy to test, which matters when you're constantly testing small changes. I wrote much of Viaweb's editor this way, and made our scripting language, RTML, purely functional.

People from the desktop business find this hard to credit, but at Viaweb bugs became almost a game. The users who hit them were advanced ones pushing the envelope, and they're forgiving, especially since you usually introduced the bug while adding a feature they asked for. Because bugs were rare, advanced users were often proud to catch one, and would call support in a spirit more of triumph than anger.

Being able to reproduce errors changes support. At most companies support exists to make customers feel better, so you treat its calls as a pain to isolate from developers. Not at Viaweb. Support was free, because we wanted to hear from customers: a problem meant we could reproduce it and ship a fix. The support people sat thirty feet from the programmers and could interrupt anything with a genuine bug. We would leave a board meeting to fix a serious one.

This made everyone happier: customers were delighted to be treated as someone bringing important news, support liked helping users instead of reading scripts, and programmers liked reproducing bugs instead of hearing vague second-hand reports.

At most companies support people are underpaid human shields and hackers are little copies of God the Father. At Viaweb, within a minute of a report the support person could be standing next to a programmer hearing "Shit, you're right, it's a bug." They used to bring us bugs with the same expectant air as a cat bringing you a mouse it has just killed. After Yahoo moved them far away, we realized they'd been QA and a proxy focus group too.

Because users' data sits on your disk, you can reproduce most bugs, and gradual release means there are few to begin with—at Viaweb bugs became almost a game. Reproducing errors also transforms support into a source of bug reports developers actually want.

Morale

Being able to release software immediately is a big motivator.

Often as I was walking to work I would think of some change I wanted to make to the software, and do it that day.

This worked for bigger features as well.

Even if something was going to take two weeks to write (few projects took longer), I knew I could see the effect in the software as soon as it was done.

If I'd had to wait a year for the next release, I would have shelved most of these ideas, for a while at least. The thing about ideas, though, is that they lead to more ideas.

Have you ever noticed that when you sit down to write something, half the ideas that end up in it are ones you thought of while writing it?

The same thing happens with software.

Working to implement one idea gives you more ideas.

So shelving an idea costs you not only that delay in implementing it, but also all the ideas that implementing it would have led to.

In fact, shelving an idea probably even inhibits new ideas: as you start to think of some new feature, you catch sight of the shelf and think "but I already have a lot of new things I want to do for the next release."

What big companies do instead of implementing features is plan them.

At Viaweb we sometimes ran into trouble on this account.

Investors and analysts would ask us what we had planned for the future.

The truthful answer would have been, we didn't have any plans.

We had general ideas about things we wanted to improve, but if we knew how we would have done it already.

What were we going to do in the next six months?

Whatever looked like the biggest win.

I don't know if I ever dared give this answer, but that was the 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 definite owner.

But when you owned something you really owned it: no one except the owner of a piece of software had to approve (or even know about) a release.

There was no protection against breakage except the fear of looking like an idiot to one's peers, and that was more than enough.

I may have given the impression that we just blithely plowed forward writing code.

We did go fast, but we thought very carefully before we released software onto those servers.

And paying attention is more important to reliability than moving slowly.

Because he pays close attention, a Navy pilot can land a 40,000 lb. aircraft at 140 miles per hour on a pitching carrier deck, at night, more safely than the average teenager can cut 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 programmers than it would for a big company of mediocre ones, where bad ideas are caught by committees instead of the people that had them.

Brooks in Reverse

Fortunately, Web-based software does require fewer programmers.

I once worked for a medium-sized desktop software company that had over 100 people working in engineering as a whole.

Only 13 of these were in product development.

All the rest were working on releases, 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 under pressure to hire more, because we wanted to get bought, and we knew that buyers would have a hard time paying a high price for a company with only three programmers. (Solution: we hired more, but created new projects for them.)

When you can write software with fewer programmers, it saves you more than money.

As Fred Brooks pointed out in The Mythical Man-Month, adding people to a project tends to slow it down.

The number of possible connections between developers grows exponentially with the size of the group.

The larger the group, the more time they'll spend in meetings negotiating how their software will work together, and the more bugs they'll get from unforeseen interactions.

Fortunately, this process also works in reverse: as groups get smaller, software development gets exponentially more efficient.

I can't remember the programmers at Viaweb ever having an actual meeting.

We never had more to say at any one time than we could say as we were walking to lunch.

If there is a downside here, it is that all the programmers have to be to some degree system administrators as well.

When you're hosting software, someone has to be watching the servers, and in practice the only people who can do this properly are the ones who wrote the software.

At Viaweb our system had so many components and changed so frequently that there was no definite border between software and infrastructure.

Arbitrarily declaring such a border would have constrained our design choices.

And so although we were constantly hoping that one day ("in a couple months") everything would be stable enough that we could hire someone whose job was just to worry about the servers, it never happened.

I don't think it could be any other way, as long as you're still actively developing the product.

Web-based software is never going to be something you write, check in, and go home.

It's a live thing, running on your servers right now.

A bad bug might not just crash one user's process; it could crash them all.

If a bug in your code corrupts some data on disk, you have to fix it.

And so on.

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 an eye on things you've changed recently.

You don't release code late at night and then go home.

Being able to release immediately is a big motivator. Walking to work I'd think of some change and make it that day. It worked for bigger features too: even one that took two weeks, I knew I'd see the effect as soon as it was done.

If I'd had to wait a year, I'd have shelved most of these ideas. But ideas lead to more ideas. Have you noticed that half the ideas in something you write are ones you thought of while writing it? The same happens with software. So shelving an idea costs you not just the delay but all the ideas it would have led to—and probably inhibits new ones, since you catch sight of the shelf and think "but I already have a lot for the next release."

What big companies do instead of implementing features is plan them. Investors would ask what we had planned, and the truthful answer was: nothing. We had general ideas, but if we knew how to do them we'd have done them already. What would we do in the next six months? Whatever looked like the biggest win. Plans are just another word for ideas on the shelf.

Most code had one definite owner, and the only protection against breakage was the fear of looking like an idiot to your peers—which was enough, because paying attention matters more to reliability than moving slowly. Because he pays close attention, a Navy pilot can land a 40,000 lb. aircraft at 140 miles per hour on a pitching carrier deck, at night, more safely than the average teenager can cut a bagel. This works far better for a small team than for a big company of mediocre ones.

Fortunately, Web-based software requires fewer programmers, because there are no releases and ports to staff—Viaweb was written by just three people. As Fred Brooks pointed out in The Mythical Man-Month, adding people to a project tends to slow it down: the connections between developers grow exponentially with the group. This works in reverse too—as groups shrink, development gets exponentially more efficient. I can't remember the Viaweb programmers ever having an actual meeting.

The downside is that all the programmers have to be system administrators too, because only the people who wrote the software can watch the servers properly. We kept hoping that one day everything would be stable enough to hire someone just to worry about the servers. It never happened.

Web-based software is never something you write, check in, and go home—it's a live thing running on your servers right now, where a bad bug might crash not one user's process but all of them. After the first year you don't watch every minute, but you keep an eye on what you've changed recently. You don't release code late at night and then go home.

Being able to ship immediately is a huge motivator, because ideas lead to more ideas and shelving one costs you all of them—plans are just ideas on the shelf. And small groups develop software exponentially more efficiently: Brooks's law in reverse.

Watching Users

With server-based software, you're in closer touch with your code.

You can also be in closer touch with your users.

Intuit is famous for introducing themselves to customers at retail stores and asking to follow them home.

If you've ever watched someone use your software for the first time, you know what surprises must have awaited them.

Software should do what users think it will.

But you can't have any idea what users will be thinking, believe me, until you watch them.

And server-based software gives you unprecedented information about their behavior.

You're not limited to small, artificial focus groups.

You can see every click made by every user.

You have to consider carefully what you're going to look at, because you don't want to violate users' privacy, but even the most general statistical sampling can be very useful.

When you have the users on your server, you don't have to rely on benchmarks, for example.

Benchmarks are simulated users.

With server-based software, you can watch actual users.

To decide what to optimize, just log into a server and see what's consuming all the CPU.

And you know when to stop optimizing too: we eventually got the Viaweb editor to the point where it was memory-bound rather than CPU-bound, and since there was nothing we could do to decrease the size of users' data (well, nothing easy), we knew we might as well stop there.

Efficiency matters for server-based software, because you're paying for the hardware.

The number of users you can support per server is the divisor of your capital cost, so if you can make your software very efficient you can undersell competitors and still make a profit.

At Viaweb we got the capital cost per user down to about $5.

It would be less now, probably less than the cost of sending them the first month's bill.

Hardware is free now, if your software is reasonably efficient.

Watching users can guide you in design as well as optimization.

Viaweb had a scripting language called RTML that let advanced users define their own page styles.

We found that RTML became a kind of suggestion box, because users only used it when the predefined page styles couldn't do what they wanted.

Originally the editor put button bars across the page, for example, but after a number of users used RTML to put buttons down the left side, we made that an option (in fact the default) in the predefined page styles.

Finally, by watching users you can often tell when they're in trouble.

And since the customer is always right, that's a sign of something you need to fix.

At Viaweb the key to getting users was the online test drive.

It was not just a series of slides built by marketing people.

In our test drive, users actually used the software.

It took about five minutes, and at the end of it they had built a real, working store.

The test drive was the way we got nearly all our new users.

I think it will be the same for most Web-based applications.

If users can get through a test drive successfully, they'll like the product.

If they get confused or bored, they won't.

So anything we could do to get more people through the test drive would increase our growth rate.

I studied click trails of people taking the test drive and found that at a certain step they would get confused and click on the browser's Back button. (If you try writing Web-based applications, you'll find that the Back button becomes one of your most interesting philosophical problems.) So I added a message at that point, telling users that they were nearly finished, and reminding them not to click on the Back button.

Another great thing about Web-based software is that you get instant feedback from changes: the number of people completing the test drive rose immediately from 60% to 90%.

And since the number of new users was a function of the number of completed test drives, our revenue growth increased by 50%, just from that change.

With server-based software you're in closer touch with your code, and with your users. Intuit is famous for following customers home from retail stores. If you've ever watched someone use your software for the first time, you know what surprises awaited them.

Software should do what users think it will, but you can't know what they're thinking until you watch them—and server-based software gives you unprecedented information. You're not limited to small, artificial focus groups; you can see every click made by every user. You have to be careful what you look at, to avoid violating privacy, but even general statistical sampling is very useful.

Efficiency matters because you're paying for the hardware. The number of users per server divides your capital cost, so efficient software lets you undersell competitors and still profit. At Viaweb we got it down to about $5 per user. Hardware is free now, if your software is reasonably efficient.

Watching users guides design too. RTML became a kind of suggestion box, because users only reached for it when the predefined page styles couldn't do what they wanted. The editor originally put button bars across the page, but after enough users used RTML to put buttons down the left side, we made that the default.

By watching users you can tell when they're in trouble—and since the customer is always right, that's a sign of something to fix. The key to getting users was the online test drive. It wasn't a marketing slideshow; users actually used the software, and in about five minutes built a real, working store.

The test drive got us nearly all our new users, and if users get through it they like the product. Studying click trails, I found people got confused at a certain step and hit the Back button. (You'll find the Back button becomes one of your most interesting philosophical problems.) I added a message there, and completions jumped from 60% to 90%—and revenue growth rose 50% from that one change.

Server-based software lets you watch every click of every actual user instead of relying on focus groups and benchmarks. That guides optimization and design, and the online test drive—where one tweak raised completion from 60% to 90%—was how we got nearly all our users.

Money

In the early 1990s I read an article in which someone said that software was a subscription business.

At first this seemed a very cynical statement.

But later I realized that it reflects reality: software development is an ongoing process.

I think it's cleaner if you openly charge subscription fees, instead of forcing people to keep buying and installing new versions so that they'll keep paying you.

And fortunately, subscriptions are the natural way to bill for Web-based applications.

Hosting applications is an area where companies will play a role that is not likely to be filled by freeware.

Hosting applications is a lot of stress, and has real expenses.

No one is going to want to 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 a recurring revenue stream.

Because your software evolves gradually, you don't have to worry that a new model will flop; there never need be a new model, per se, and if you do something to the software that users hate, you'll know right away.

You have no trouble with uncollectable bills; if someone won't pay you can just turn off the service.

And there is no possibility of piracy.

That last "advantage" may turn out to be a problem.

Some amount of piracy is to the advantage of software companies.

If some user really would not have bought your software at any price, you haven't lost anything if he uses a pirated copy.

In fact you gain, because he 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 price discrimination, which means charging each customer as much as they can afford. [8] Software is particularly suitable for price discrimination, because the marginal cost is close to zero.

This is 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 can safely be charged more.

Piracy is effectively the lowest tier of price discrimination.

I think that software companies understand this 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 desktop software, because it's easy to buy.

You might think that people decide to buy something, and then buy it, as two separate steps.

That's what I thought before Viaweb, to the extent I thought about the question at all.

In fact the second step can propagate back into the first: if something is hard to buy, people will change their mind about whether they wanted it.

And vice versa: you'll sell more of something when it's easy to buy.

I buy more books because Amazon exists.

Web-based software is just about the easiest thing in the world to buy, especially if you have just done an online demo.

Users should not have to do much more than enter a credit card number. (Make them do more at your peril.)

Sometimes Web-based software is offered through ISPs acting as resellers.

This is a bad idea.

You have to be administering the servers, because you need to be constantly improving both hardware and software.

If you give up direct control of the servers, you give 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 were excited about this huge potential channel, and didn't realize that it would ruin the product they hoped to sell through it.

Selling Web-based software through ISPs is like selling sushi through vending machines.

Customers

Who will the customers be?

At Viaweb they were initially individuals and smaller companies, and I think this will be the rule with Web-based applications.

These are the users who are ready to try new things, partly because they're more flexible, and partly because they want the lower costs of new technology.

Web-based applications will often be the best thing for big companies too (though they'll be slow to realize it).

The best intranet is the Internet.

If a company uses true Web-based applications, the software 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: if access is easier for employees, it will be for bad guys too.

Some larger merchants were reluctant to use Viaweb because they thought customers' credit card information would be safer on their own servers.

It was not easy to make this point diplomatically, but in fact the data was almost certainly safer in our hands than theirs.

Who can hire better people to manage security, a technology startup whose whole business is running servers, or a clothing retailer?

Not only did we have better people worrying about security, we worried more about it.

If someone broke into the clothing retailer's servers, it would affect at most one merchant, could probably be hushed up, and in the worst case might get one person fired.

If someone broke into ours, it could affect thousands of merchants, would probably end up as news on CNet, and could put us out of business.

If you want to keep your money safe, do you keep it under your mattress at home, or put it in a bank?

This argument applies to every aspect of server administration: not just security, but uptime, bandwidth, load management, backups, etc. Our existence depended on doing these things right.

Server problems were the big 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 extent outsourcing IT.

Drastic as it sounds, I think this is generally a good idea.

Companies are likely to get better service this way than they would from in-house system administrators.

System administrators can become cranky and unresponsive because they're not directly exposed to competitive pressure: a salesman has to deal with customers, and a developer has to deal with competitors' software, but a system administrator, like an old bachelor, has few external forces to keep him in line. [10] At Viaweb we had external forces in plenty to keep us in line.

The people calling us 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 for big companies too.

They will be the last to realize it, however, just as they were with desktop computers.

And partly for the same reason: it will be worth a lot of money to convince big companies that they need something more expensive.

There is always a tendency for rich customers to buy expensive solutions, even when cheap solutions are better, because the people offering expensive solutions can spend more to sell them.

At Viaweb we were always up against this.

We lost several high-end merchants to Web consulting firms who convinced them they'd be better off if they paid half a million dollars for a custom-made online store on their own server.

They were, as a rule, not better off, as more than one discovered when Christmas shopping season came around and loads rose on their server.

Viaweb was a lot more sophisticated than what most of these merchants got, but we couldn't afford to tell them.

At $300 a month, we couldn't afford to send a team of well-dressed and authoritative-sounding people to make presentations to customers.

A large part of what big companies pay extra for is the cost of selling expensive things to them. (If the Defense Department pays a thousand dollars for toilet seats, it's partly because it costs a lot to sell toilet seats for a thousand dollars.)

And this is one reason intranet software will continue to thrive, even though it is probably a bad idea.

It's simply more expensive.

There is nothing you can do about this conundrum, so the best plan is to go for the smaller customers first. The rest will come in time.

In the early 1990s I read that software was a subscription business. It seemed cynical, but it reflects reality: development is an ongoing process, so it's cleaner to charge subscription fees openly—the natural way to bill for Web-based applications—than to force people to keep buying new versions. Hosting them is a role companies will play, not freeware: it's a lot of stress and has real expenses.

For companies, Web-based applications are an ideal source of revenue. Instead of a blank slate each quarter, you have a recurring stream. Because the software evolves gradually, you never worry that a new model will flop, and if you do something users hate you know right away. There are no uncollectable bills—just turn off the service—and no piracy.

That last "advantage" may be a problem, because some piracy helps: a user who wouldn't have bought at any price costs you nothing as a pirate, and may help make your software the standard. It's effectively the lowest tier of price discrimination, which is why companies turn a blind eye to some of it.

Web-based software sells well because it's easy to buy. You'd think deciding to buy and buying are separate steps, but the second propagates back into the first: if something is hard to buy, people change their mind about wanting it. I buy more books because Amazon exists. Web-based software is about the easiest thing in the world to buy—users shouldn't have to do much more than enter a credit card number.

Sometimes it's offered through ISPs as resellers. This is a bad idea: you have to administer the servers, because you're constantly improving hardware and software, and giving up control means giving up most of the advantages. Selling Web-based software through ISPs is like selling sushi through vending machines.

Who will the customers be? At Viaweb they were initially individuals and smaller companies, and that's the rule—they're flexible and want lower costs. But Web-based applications will often be best for big companies too, though they'll be slow to see it. The best intranet is the Internet: the software works better, the servers are better administered, and employees can reach the system from anywhere.

The argument against usually hinges on security: easier access for employees means easier access for bad guys. Some merchants thought credit card data was safer on their own servers, but it was almost certainly safer in ours. Who can hire better security people, a startup whose whole business is running servers, or a clothing retailer? And we worried more: a break-in at the retailer affects one merchant; a break-in at ours could affect thousands and put us out of business.

If you want to keep your money safe, do you keep it under your mattress or put it in a bank? This applies to every aspect of server administration—uptime, bandwidth, load, backups. Server problems were the big no-no for us, like a salmonella outbreak for a food processor.

A big company using Web-based applications is to that extent outsourcing IT, which is generally a good idea. In-house administrators can become cranky and unresponsive because they aren't exposed to competitive pressure: a system administrator, like an old bachelor, has few external forces to keep him in line.

Big companies will be the last to realize this, just as with desktop computers, and partly for the same reason: it's worth a lot of money to convince them they need something more expensive. Rich customers tend to buy expensive solutions even when cheap ones are better, because sellers of expensive solutions can spend more to sell them. We lost several high-end merchants to consulting firms that sold them half-million-dollar custom stores—which weren't better off, as more than one discovered when Christmas loads rose.

A large part of what big companies pay extra for is the cost of selling expensive things to them. (If the Defense Department pays a thousand dollars for a toilet seat, it's partly because it costs a lot to sell one for that.) So intranet software will keep thriving even though it's probably a bad idea. The best plan is to go for the smaller customers first; the rest will come in time.

Subscriptions are the natural way to bill for Web-based software, and it sells well because it's easy to buy. Big companies, who pay extra largely for the cost of being sold to, will be the last to see that outsourcing IT to an ASP is safer and better.

Son of Server

Running software on the server is nothing new.

In fact it's the old model: mainframe applications are all server-based.

If server-based software is such a good idea, why did it lose last time?

Why did desktop computers eclipse mainframes?

At first desktop computers didn't look like much of a threat.

The first users were all hackers-- or hobbyists, as they were called then.

They liked microcomputers because they were cheap.

For the first time, you could have your own computer.

The phrase "personal computer" is part of the language now, but when it was first used it had a deliberately audacious sound, like the phrase "personal satellite" would today.

Why did desktop computers take over?

I think it was because they had better software.

And I think the reason microcomputer software was better was that it could be written by small companies.

I don't think many people realize how fragile and tentative startups are in the earliest stage.

Many startups begin almost by accident-- as a couple guys, either with day jobs or in school, writing a prototype of something that might, if it looks promising, turn into a company.

At this larval stage, any significant obstacle will stop the startup dead in its tracks.

Writing mainframe software required too much commitment up front.

Development machines were expensive, and because the customers would be big companies, you'd need an impressive-looking sales force to sell it to them.

Starting a startup to write mainframe software would be a much more serious undertaking than just hacking something together on your Apple II in the evenings.

And so you didn't get a lot of startups writing mainframe applications.

The arrival of desktop computers inspired a lot of new software, because writing applications for them seemed an attainable goal to larval startups.

Development was cheap, and the customers would be individual people that you could reach through computer stores or even by mail-order.

The application that pushed desktop computers out into the mainstream was VisiCalc, the first spreadsheet.

It was written by two guys working in an attic, and yet did things no mainframe software could do. [11] VisiCalc was such an advance, in its time, that people bought Apple IIs just to run it.

And this was the beginning of a trend: desktop computers won because startups wrote software for them.

It looks as if server-based software will be good this time around, because startups will write it.

Computers are so cheap now that you can get started, as we did, using a desktop computer as a server.

Inexpensive processors have eaten the workstation market (you rarely even hear the word now) and are most of the way through the server market; Yahoo's servers, which deal with loads as high as any on the Internet, all have the same inexpensive Intel processors that you have in your desktop machine.

And once you've written the software, all you need to sell it is a Web site.

Nearly all our users came direct to our site through word of mouth and references in the press. [12]

Viaweb was a typical larval startup.

We were terrified of starting a company, and for the first few months comforted ourselves by treating the whole thing as an experiment that we might call off at any moment.

Fortunately, there were few obstacles except technical ones.

While we were writing the software, our Web server was the same desktop machine we used for development, connected to the outside world by a dialup line.

Our only expenses in that phase were food and rent.

There is all the more reason for startups to write Web-based software now, because writing desktop software has become a lot less fun.

If you want to write desktop software now you do it on Microsoft's terms, calling their APIs and working around their buggy OS.

And if you manage to write something that takes off, you may find that you 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 want to use.

That means it has to be inexpensive and well-designed.

The Mac was popular with hackers when it first came out, and a lot of 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 at writing software tend to be running Linux or FreeBSD now.

I don't think we would have started a startup to write desktop software, because desktop software has to run on Windows, and before we 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.

Running software on the server is nothing new—it's the old model; mainframe applications are all server-based. So if it's such a good idea, why did it lose last time? Why did desktop computers eclipse mainframes?

Why did desktop computers take over? I think because they had better software—and microcomputer software was better because it could be written by small companies.

People don't realize how fragile startups are at the earliest stage. Many begin almost by accident, a couple of guys writing a prototype that might become a company, and at this larval stage any significant obstacle stops them dead. Writing mainframe software required too much commitment up front: expensive machines, and an impressive sales force because the customers were big companies. So you didn't get many startups writing it.

Desktop computers inspired a lot of new software, because writing for them seemed attainable: development was cheap, and customers were individuals reachable through stores or mail-order. The application that pushed desktops mainstream was VisiCalc, the first spreadsheet, written by two guys in an attic—it did things no mainframe software could, and people bought Apple IIs just to run it. Desktop computers won because startups wrote software for them.

Server-based software will be good this time, because startups will write it. Computers are so cheap you can start, as we did, using a desktop machine as a server. Inexpensive processors ate the workstation market and most of the server market: Yahoo's servers run the same cheap Intel processors as your desktop. And once the software is written, all you need to sell it is a Web site.

Viaweb was a typical larval startup. We were terrified of starting a company, and comforted ourselves by treating it as an experiment we might call off at any moment. While writing the software, our Web server was the same desktop machine we developed on, on a dialup line. Our only expenses then were food and rent.

There's all the more reason to write Web-based software now, because writing desktop software has become a lot less fun: you do it on Microsoft's terms, working around their buggy OS—and if you write something that takes off, you may find you were merely doing market research for Microsoft.

I don't think we'd have started a startup to write desktop software, because that means running on Windows, and first we'd have to use it. The Web let us do an end-run around Windows and deliver software running on Unix straight to users through the browser. That's a liberating prospect, a lot like the arrival of PCs twenty-five years ago.

Server-based software is the old mainframe model—so why did desktops win last time? Because startups could afford to write desktop software but not mainframe software, and startups wrote the better programs, like VisiCalc. This time startups will write the server software.

Microsoft

Back when desktop computers arrived, IBM was the giant that everyone was afraid of.

It's hard to imagine now, but I remember the feeling very well.

Now the frightening giant is Microsoft, and I don't think they are as blind to the threat facing them as IBM was.

After all, Microsoft deliberately built their business in IBM's blind spot.

I mentioned earlier that my mother doesn't really need a desktop computer.

Most users probably don't.

That's a problem for Microsoft, and they know it.

If applications run on remote servers, no one needs Windows.

What will Microsoft do?

Will they be able to use their control of the desktop to prevent, or constrain, this new generation of software?

My guess is that Microsoft will develop some kind of server/desktop hybrid, where the operating system works together with servers they control.

At a minimum, files will be centrally available for users who want that.

I don't expect Microsoft to go all the way to the extreme of doing the computations on the server, with only a browser for a client, if they can avoid it.

If you only need a browser for a client, you don't need Microsoft on the client, and if Microsoft doesn't control the client, they can't push users towards their server-based applications.

I think Microsoft will have a hard time keeping the genie in the bottle.

There will be too many different types of clients for them to control them all.

And if Microsoft's applications only work with some clients, competitors will be able to trump them by offering applications that work from any client. [14]

In a world of Web-based applications, there is no automatic place for Microsoft.

They may succeed in making themselves a place, but I don't think they'll dominate this new world as they did the world of desktop applications.

It's not so much that a competitor will trip them up as that they will trip over themselves.

With the rise of Web-based software, they will be facing not just technical problems but their own wishful thinking.

What they need to do is cannibalize their existing business, and I can't see them facing that.

The same single-mindedness that has brought them this far will now be working against them.

IBM was in exactly the same situation, and they could not master it.

IBM made a late and half-hearted entry into the microcomputer business because they were ambivalent about threatening their cash cow, mainframe computing.

Microsoft will likewise be hampered by wanting to save the desktop.

A cash cow can be a damned heavy monkey 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 be a good long period of cheerful chaos, just as there was in the early days of microcomputers.

That was a good time for startups.

Lots of small companies flourished, and did it by making cool things.

Back when desktop computers arrived, IBM was the giant everyone feared. The frightening giant now is Microsoft, and I don't think they're as blind to the threat as IBM was—after all, they built their business in IBM's blind spot.

Most users probably don't really need a desktop computer, and that's a problem Microsoft knows about: if applications run on remote servers, no one needs Windows. Can they use their control of the desktop to prevent or constrain this new generation of software?

My guess is they'll build a server/desktop hybrid, where the operating system works with servers they control. I don't expect them to go all the way to computations on the server with only a browser for a client: if you only need a browser, you don't need Microsoft on the client, and then they can't push you toward their server applications.

But they'll have a hard time keeping the genie in the bottle. There will be too many kinds of clients to control them all, and if their applications only work with some, competitors can trump them by offering applications that work from any client.

In a world of Web-based applications there is no automatic place for Microsoft. They may make themselves one, but I don't think they'll dominate it as they did desktop applications.

It's not that a competitor will trip them up so much as that they'll trip over themselves. What they need to do is cannibalize their existing business, and I can't see them facing that. IBM was in exactly this situation: it made a late, half-hearted entry into microcomputers because it was ambivalent about threatening its mainframe cash cow. Microsoft will likewise be hampered by wanting to save the desktop. A cash cow can be a damned heavy monkey on your back.

I'm not saying no one will dominate server-based applications—someone probably will. But there will be a good long period of cheerful chaos, just as in the early days of microcomputers. That was a good time for startups: lots of small companies flourished by making cool things.

The frightening giant is now Microsoft, and they know remote servers threaten Windows. They'll likely build a server/desktop hybrid rather than cede the client, but they'll trip over their own unwillingness to cannibalize the desktop—just as IBM couldn't threaten its mainframe cash cow.

Startups but More So

The classic startup is fast and informal, with few people and little money.

Those few people work very hard, and technology magnifies the effect of the decisions they make.

If they win, they win big.

In a startup writing Web-based applications, everything you associate with startups is taken to an extreme.

You can write and launch a product with even fewer people and even less money.

You have to be even faster, and you can get away with being more informal.

You can literally launch your product as three guys sitting in the living 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 horn rimmed glasses and narrow black neckties, industriously writing ten lines of code a day on IBM coding forms. In 1980, it was a team of eight to ten people wearing jeans to the office and typing into vt100s.

Now it's a couple of guys sitting in a living room with laptops. (And jeans turn out not to be the last word in informality.)

Startups are stressful, and this, unfortunately, is also taken to an extreme with Web-based applications.

Many software companies, especially at the beginning, have periods where the developers slept under their desks and so on.

The alarming thing about Web-based software is that there is nothing to prevent this becoming the default.

The stories about sleeping under desks usually end: then at last we shipped it and we all went home and slept for a week.

Web-based software never ships.

You can work 16-hour days for as long as you want to.

And because you can, and your competitors can, you tend to be forced to.

You can, so you must. It's Parkinson's Law running in reverse.

The worst thing is not the hours but the responsibility.

Programmers and system administrators traditionally each have their own separate worries.

Programmers have to worry about bugs, and system administrators have to worry about infrastructure.

Programmers may spend a long day up to their elbows in source code, but at some point they get to go home and forget about it.

System administrators never quite leave the job behind, but when they do get paged at 4: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 the sharply defined limits that ordinarily make the job bearable.

At Viaweb we spent the first six months just writing software.

We worked the usual long hours of an early startup.

In a desktop software company, this would have been the part where we were working hard, but it felt like a vacation compared to the next phase, when we took users onto our server.

The second biggest benefit of selling Viaweb to Yahoo (after the money) was to be able to dump ultimate responsibility for the whole thing onto the shoulders of a big company.

Desktop software forces users to become system administrators.

Web-based software forces programmers to.

There is less stress in total, but more for the programmers.

That's not necessarily bad news.

If you're a startup competing with a big company, it's good news. [15] Web-based applications offer a straightforward way to outwork your competitors.

No startup asks for more.

Just Good Enough

One thing that might deter you from writing Web-based applications is 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 to HTML and HTTP.

What matters, though, is that Web pages are just good enough.

There is a parallel here with the first microcomputers.

The processors in those machines weren't actually intended to be the CPUs of computers.

They were designed to be used in things like traffic lights.

But guys like Ed Roberts, who designed the Altair, realized that they were just good enough.

You could combine one of these chips with some memory (256 bytes in the first Altair), and front panel switches, and you'd have a working computer.

Being able to have your own computer was so exciting that there were plenty of people who wanted to buy them, however limited.

Web pages weren't designed to be a UI for applications, but they're just good enough.

And for a significant number of users, software that you can use from any browser will be enough of a win in itself to outweigh any awkwardness in the UI.

Maybe you can't write the best-looking spreadsheet using HTML, but you can write a spreadsheet that several people can use simultaneously from different locations without special client software, or that can incorporate live data feeds, or that can page you when certain conditions are triggered.

More importantly, you can write new kinds of applications that don't even have names yet.

VisiCalc was not merely a microcomputer version of a mainframe application, after all-- it was a new type of 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 sure that's a bad idea.

It would be very convenient if you could assume that everyone would install your client-- so convenient that you could easily convince yourself that they all would-- but if they don't, you're hosed.

Because Web-based software assumes nothing about the client, it will work anywhere the Web works.

That's a big advantage already, and the advantage will grow as new Web devices proliferate.

Users will like you because your software just works, and your life will be easier because you won't have to tweak it for every new client. [16]

I feel like I've watched the evolution of the Web as closely as anyone, 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 involve connecting the desktop to servers.

Unless AOL fights back, they will either be pushed aside or turned into a pipe between Microsoft client and server software.

If Microsoft and AOL get into a client war, the only thing sure to work on both will be browsing the Web, meaning Web-based applications will be the only kind that work everywhere.

How will it all play out?

I don't know.

And you don't have to know if you bet on Web-based applications.

No one can break that without breaking browsing.

The Web may not be the only way to deliver software, but it's one that works now and will continue to work for a long time.

Web-based applications are cheap to develop, and easy for even the smallest startup to deliver.

They're a lot of work, and of a particularly stressful kind, but that only makes the odds better for startups.

The classic startup is fast and informal, with few people and little money; if they win, they win big. In a Web-based startup everything you associate with startups is taken to an extreme: fewer people, less money, faster, more informal. You can literally launch as three guys in a living room with a server collocated at an ISP. We did.

Startups are stressful, and this too is taken to an extreme. The sleeping-under-desks stories usually end "then at last we shipped it and went home and slept for a week." Web-based software never ships. You can work 16-hour days as long as you want—and because you can, and your competitors can, you tend to be forced to. You can, so you must. It's Parkinson's Law running in reverse.

The worst thing isn't the hours but the responsibility. Programmers fret about bugs but eventually go home and forget; administrators never quite leave it behind but, paged at 4:00 AM, don't usually have to do anything complicated. With Web-based applications these combine: the programmers become system administrators, without the sharply defined limits that ordinarily make the job bearable.

We spent Viaweb's first six months just writing software, which in a desktop company would have been the hard part—but it felt like a vacation compared to the next phase, when we took users onto our server. Desktop software forces users to become system administrators; Web-based software forces programmers to. There's less stress in total, but more for the programmers—which, if you're competing with a big company, is good news.

One thing that might deter you is the lameness of Web pages as a UI. That's a problem, I admit; there were a few things we'd have really liked to add to HTML and HTTP. What matters, though, is that Web pages are just good enough.

There's a parallel with the first microcomputers. Their processors weren't meant to be CPUs—they were designed for things like traffic lights. But guys like Ed Roberts, who designed the Altair, realized they were just good enough: combine one with some memory and switches and you had a working computer, and being able to have your own was so exciting that plenty wanted them, however limited.

Web pages weren't designed as a UI for applications, but they're just good enough. You may not write the best-looking spreadsheet in HTML, but you can write one several people use simultaneously, or that incorporates live feeds, or pages you when conditions trigger. More importantly, you can write new kinds of applications that don't even have names yet. VisiCalc wasn't a microcomputer version of a mainframe application—it was a new type.

Server-based applications don't have to be Web-based, but assuming everyone will install some other client is a bad idea: convince yourself they all will, and if they don't, you're hosed. Web-based software assumes nothing about the client, so it works anywhere the Web works, and that advantage will grow as new Web devices proliferate.

You don't have to know how it all plays out if you bet on Web-based applications: no one can break that without breaking browsing. They're cheap to develop and easy for the smallest startup to deliver—a lot of work, of a particularly stressful kind, but that only makes the odds better for startups.

In a Web-based startup, everything about startups is taken to an extreme—fewer people, less money, more speed, but also more stress, because the software never ships. And though Web pages are a lame UI, like the first microcomputers' chips, they're just good enough.

Why Not?

E. B. White was amused to learn from a farmer friend that many electrified fences don't have any current running through them.

The cows apparently learn to stay away from them, and after that you don't need the current.

"Rise up, cows!" he wrote, "Take your liberty 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 is that you don't know anything about business.

The other is that you're afraid of competition.

Neither of these fences have any current in them.

There are only two things you have to know about business: build something users love, and make more than you spend.

If you get these two right, you'll be ahead of most startups.

You can figure out the rest as you go.

You may not at first make more than you spend, but as long as the gap is closing fast enough you'll be ok.

If you start out underfunded, it will at least encourage a habit of frugality.

The less you spend, the easier it is to make more than you spend.

Fortunately, it can be very cheap to launch a Web-based application.

We launched on under $10,000, and it would be even cheaper today.

We had to spend thousands on a server, and thousands more to get SSL. (The only company selling SSL software at the time was Netscape.)

Now you can rent a much more powerful server, with SSL included, for less than we paid for bandwidth alone.

You could launch a Web-based application 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 to use yourself.

Get a version 1.0 out fast, then continue to improve the software, listening closely to the users as you do.

The customer is always right, but different customers are right about different things; the least sophisticated users show you what you need to simplify and clarify, and the most sophisticated tell you what features 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 limit users' choices.

Don't get complacent if your competitors' software is lame; the standard to compare your software to is what it could be, not what your current competitors happen to have.

Use your software yourself, all the time.

Viaweb was supposed to be an online store builder, but we used it to make our own site too.

Don't listen to marketing people or designers or product managers just because of their job titles.

If they have good ideas, use them, but it's up to you to decide; software has to be designed by hackers who understand design, not designers who know a little about software.

If you can't design software as well as implement it, don't start a startup.

Now let's talk about competition.

What you're afraid of is not presumably groups of hackers like you, but actual companies, with offices 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 rent office space or hire sales people than it is for a company of any size to get software written.

I've been on both sides, and I know.

When Viaweb was bought by Yahoo, I suddenly found myself working for a big company, and it was like trying to run through waist-deep water.

I don't mean to disparage Yahoo.

They had some good hackers, and the top management were real butt-kickers.

For a big company, they were exceptional.

But they were still only about a tenth as productive as a small startup.

No big company can do much better than that.

What's scary about Microsoft is that a company so big can develop software at all.

They're like a mountain that can walk.

Don't be intimidated.

You can do as much that Microsoft can't as they can do that you can't.

And no one can stop you.

You don't have to ask anyone's permission to develop Web-based applications.

You don't have to do licensing deals, or get shelf space in retail stores, or grovel to have your application bundled with the OS.

You can deliver software right to the browser, and no one can get between you and potential users without preventing them from browsing the Web.

You may not believe it, but I promise you, Microsoft is scared of you.

The complacent middle managers may not be, but Bill is, because he was you once, back in 1975, the last time a new way of delivering software appeared.

E. B. White was amused to learn from a farmer that many electrified fences don't have any current running through them. The cows learn to stay away, and after that you don't need the current. "Rise up, cows!" he wrote, "Take your liberty while despots snore!"

If you're a hacker who's thought of starting a startup, two things are probably keeping you from it. One is that you don't know anything about business. The other is that you're afraid of competition. Neither of these fences has any current in it.

There are only two things you have to know about business: build something users love, and make more than you spend. Get these two right and you'll be ahead of most startups. You can figure out the rest as you go.

Fortunately it can be very cheap to launch a Web-based application. We launched on under $10,000; now you can rent a more powerful server, SSL included, for less than the cost of a fancy office chair.

As for building something users love: start with something clean and simple you'd want to use yourself, get a 1.0 out fast, then keep improving it, listening closely. The customer is always right, but about different things—the least sophisticated users show you what to simplify, the most sophisticated what to add. The best thing software can be is easy, but the way is to get the defaults right, not to limit choices. Software has to be designed by hackers who understand design.

Now, competition. What you fear isn't hackers like you but actual companies, with offices and salesmen, right? They're more afraid of you than you are of them, and they're right: it's far easier for a couple of hackers to rent office space or hire salespeople than for a company of any size to get software written. When Yahoo bought Viaweb and I found myself working for a big company, it was like trying to run through waist-deep water.

Yahoo had good hackers and butt-kicking management, exceptional for a big company. But they were still only about a tenth as productive as a small startup, and no big company does much better. What's scary about Microsoft is that a company so big can develop software at all. They're like a mountain that can walk.

Don't be intimidated. You can do as much that Microsoft can't as they can do that you can't, and no one can stop you. You don't have to ask permission, do licensing deals, get shelf space, or grovel to be bundled with the OS. You can deliver software right to the browser, and no one can get between you and your users without preventing them from browsing the Web.

You may not believe it, but I promise you, Microsoft is scared of you. The complacent middle managers may not be, but Bill is, because he was you once, back in 1975, the last time a new way of delivering software appeared.

The two fences keeping hackers from starting a startup—ignorance of business and fear of competition—have no current in them. You only need to build something users love and make more than you spend, and big companies are more afraid of you than you are of them.

Notes

[1] Realizing that much of the money is in the services, companies building lightweight clients have usually tried to combine the hardware with an online service. This approach has not worked well, partly because you need two different kinds of companies to build consumer electronics and to run an online service, and partly because users hate the idea. Giving away the razor and making money on the blades may work for Gillette, but a razor is much smaller commitment than a Web terminal. Cell phone handset makers are satisfied to sell hardware without trying to capture the service revenue as well. That should probably be the model for Internet clients too. If someone just sold a nice-looking little box with a Web browser that you could use to connect through any ISP, every technophobe in the country would buy one.

[2] Security always depends more on not screwing up than any design decision, but the nature of server-based software will make developers pay more attention to not screwing up. Compromising a server could cause such damage that ASPs (that want to stay in business) are likely to be careful about security.

[3] In 1995, when we started Viaweb, Java applets were supposed to be the technology everyone was going to use to develop server-based applications. Applets seemed to us an old-fashioned idea. Download programs to run on the client? Simpler just to go all the way and run the programs on the server. We wasted little time on applets, but countless other startups must have been lured into this tar pit. Few can have escaped alive, or Microsoft could not have gotten away with dropping Java in the most recent version of Explorer.

[4] This point is due to Trevor Blackwell, who adds "the cost of writing software goes up more than linearly with its size. Perhaps this is mainly due to fixing old bugs, and the cost can be more linear if all bugs are found quickly."

[5] The hardest kind of bug to find may be a variant of compound bug where one bug happens to compensate for another. When you fix one bug, the other becomes visible. But it will seem as if the fix is at fault, since that was the last thing you changed.

[6] Within Viaweb we once had a contest to describe the worst thing about our software. Two customer support people tied for first prize with entries I still shiver to recall. We fixed both problems immediately.

[7] Robert Morris wrote the ordering system, which shoppers used to place orders. Trevor Blackwell wrote the image generator and the manager, which merchants used to retrieve orders, view statistics, and configure domain names etc. I wrote the editor, which merchants used to build their sites. The ordering system and image generator were written in C and C++, the manager mostly in Perl, and the editor in Lisp [blocked].

[8] Price discrimination is so pervasive (how often have you heard a retailer claim that their buying power meant lower prices for you?) that I was surprised to find it was outlawed in the U.S. by the Robinson-Patman Act of 1936. This law does not appear to be vigorously enforced.

[9] In No Logo, Naomi Klein says that clothing brands favored by "urban youth" do not try too hard to prevent shoplifting because in 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 exposed to competitive pressure, because outsourcing it will thereby expose it to competitive pressure.

[11] The two guys were Dan Bricklin and Bob Frankston. Dan wrote a prototype in Basic in a couple days, then over the course of the next year they worked together (mostly at night) to make a more powerful version written in 6502 machine language. Dan was at Harvard Business School at the time and Bob nominally had a day job 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 painfully long time for word of mouth to get going, and we did not start to get a lot of press coverage until we hired a PR firm (admittedly the best in the business) for $16,000 per month. However, it was true 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 a swarm of cheap component suppliers on Apple hardware. It did not help, either, that suits took over during a critical period.

[14] One thing that would help Web-based applications, and help keep the next generation of software from being overshadowed by Microsoft, would be a good open-source browser. Mozilla is open-source but seems to have suffered from having been corporate software for so long. A small, fast browser that was actively maintained would be a great thing in itself, and would probably also encourage companies to build little Web appliances.

Among other things, a proper open-source browser would cause HTTP and HTML to continue to evolve (as e.g. Perl has).

It would help Web-based applications greatly to be able to distinguish between selecting a link and following it; all you'd need to do this would be a trivial enhancement of HTTP, to allow multiple urls in a request. Cascading menus would also be good.

If you want to change the world, write a new Mosaic.

Think it's too late?

In 1998 a lot of people thought it was too late to launch a new search engine, but Google proved them wrong.

There is always room for something new if the current options suck enough.

Make sure it works on all the free OSes first-- new things start with their users.

[15] Trevor Blackwell, who probably knows more about this from personal experience than anyone, writes:

"I would go farther in saying that because server-based software is so hard on the programmers, it causes a fundamental economic shift away from large companies.

It requires the kind of intensity and dedication from programmers that they will only be willing to provide when it's their own company.

Software companies can hire skilled people to work in a not-too-demanding environment, and can hire unskilled people to endure hardships, but they can't hire highly skilled people to bust their asses.

Since capital is no longer needed, big companies have little to bring to the table."

[16] In the original version of this essay, I advised avoiding Javascript. That was a good plan in 2001, but Javascript now works.

In 1995 Java applets were supposed to be how everyone developed server-based applications. They seemed old-fashioned to us—download programs to run on the client, when it's simpler to run them on the server? Countless startups were lured into this tar pit, and few escaped alive.

The hardest bug to find may be a compound bug where one bug compensates for another: fix one and the other becomes visible, but it seems your fix is at fault, since that was the last thing you changed.

Price discrimination is so pervasive that I was surprised to find it was outlawed in the U.S. by the Robinson-Patman Act of 1936—a law that doesn't appear to be vigorously enforced.

The two guys behind VisiCalc were Dan Bricklin and Bob Frankston. Dan wrote a prototype in Basic in a couple of days, then over the next year they built a more powerful version in 6502 machine language, mostly at night. "There was no great risk in doing a business," Bob wrote. "If it failed it failed. No big deal."

A good open-source browser would help keep the next generation of software from being overshadowed by Microsoft. A small, fast, actively maintained one would be great in itself, would keep HTTP and HTML evolving, and could distinguish between selecting a link and following it.

If you want to change the world, write a new Mosaic. Think it's too late? In 1998 a lot of people thought it was too late to launch a new search engine, but Google proved them wrong. There is always room for something new if the current options suck enough.

Trevor Blackwell goes farther: because server-based software is so hard on programmers, it causes an economic shift away from large companies. It demands intensity programmers will only provide when it's their own company. Companies can hire skilled people for an easy environment, or unskilled people to endure hardship, but not highly skilled people to bust their asses. Since capital is no longer needed, big companies have little to bring to the table.

Footnotes on lightweight clients, the Java-applet tar pit, compound bugs, price discrimination, VisiCalc's origins, and a call for a good open-source browser—write a new Mosaic, since there's always room when the current options suck enough.

Thanks to Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson, and Dan Giffin for reading drafts of this paper; to Dan Bricklin and Bob Frankston for information about VisiCalc; and again to Ken Anderson for inviting me to speak at BBN.

Some Technical Details [blocked]

Microsoft finally agrees

Gates Email [blocked]

Thanks to Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson, and Dan Giffin for reading drafts; to Dan Bricklin and Bob Frankston for information about VisiCalc; and again to Ken Anderson for inviting me to speak at BBN.

Thanks to the readers of drafts, to Dan Bricklin and Bob Frankston for VisiCalc details, and to Ken Anderson for the invitation to speak at BBN.