ACCIDENTAL EMPIRES

CHAPTER EIGHT

SOFTWARE ENVY

Mitch Kapor, the father of Lotus 1-2-3, showed up one day at my house but wouldn’t come inside. “You have a cat in there, don’t you?” he asked.

Not one cat but two, I confessed. I am a sinner.

Mitch is allergic to cats. I mean really allergic, with an industrial-strength asthmatic reaction. “It’s only happened a couple of times,” he explained, “but both times I thought I was going to die.”

People have said they are dying to see me, but Kapor really means it.

At this point we were still standing in the front yard, next to Kapor’s blue rental car. The guy had just flown cross-country in a Canadair Challenger business jet that costs $3,000 per hour to run, and he was driving a $28.95-per-day compact from Avis. I would have at least popped for a T-Bird.

We were still standing in the front yard because Mitch Kapor needed to use the bathroom, and his mind was churning out a risk/reward calculation, deciding whether to chance contact with the fierce Lisa and Jeri, our kitty sisters.

“They are generally sleeping on the clean laundry about this time,” I assured him.[PS1]

He decided to take a chance and go for it.

“You won’t regret it,” I called after him.

Actually, I think Mitch Kapor has quite a few regrets. Success has placed a heavy burden on Mitch Kapor.

Mitch is a guy who was in the right place at the right time and saw clearly what had to be done to get very, very rich in record time. Sure enough, the Brooklyn-born former grad student, recreational drug user, disc jockey, Transcendental Meditation teacher, mental ward counselor, and so-so computer programmer today has a $6 million house on 22 acres in Brookline, Massachusetts, the $12 million jet, and probably the world’s foremost collection of vintage Hawaiian shirts. So why isn’t he happy?

I think Mitch Kapor isn’t happy because he feels like an imposter.

This imposter thing is a big problem for America, with effects that go far beyond Mitch Kapor. Imposters are people who feel that they haven’t earned their success, haven’t paid their dues—that it was all too easy. It isn’t enough to be smart, we’re taught. We have to be smart, and hard working, and long suffering. We’re supposed to be aggressive and successful, but our success is not supposed to come at the expense of anyone else. Impossible, right?

We got away from this idea for a while in the 1980s, when Michael Milken and Donald Trump made it okay to be successful on brains and balls alone, but look what’s happened to them. The tide has turned against the easy bucks, even if those bucks are the product of high intelligence craftily applied, as in the case of Kapor and most of the other computer millionaires. We’re in a resurgence of what I call the guilt system, which can be traced back through our educational institutions all the way to the medieval guild system[PS2] .

The guild system, with its apprentices, journeymen, and masters, was designed from the start to screen out people, not encourage them. It took six years of apprenticeship to become a journeyman blacksmith. Should it really take six years for a reasonably intelligent person to learn how to forge iron? Of course not. The long apprenticeship period was designed to keep newcomers out of the trade while at the same time rewarding those at the top of the profession by giving them a stream of young helpers who worked practically for free.

This concept of dues paying and restraint of trade continues in our education system today, where the route to a degree is typically cluttered with requirements and restrictions that have little or nothing to do with what it was we came to study. We grant instant celebrity to the New Kids on the Block but support an educational system that takes an average of eight years to issue each Ph.D.

The trick is to not put up with the bullshit of the guild system. That’s what Bill Gates did, or he would have stayed at Harvard and become a near-great mathematician. That’s what Kapor did, too, in coming up with 1-2-3, but now he’s lost his nerve and is paying an emotional price. Doe-eyed Mitch Kapor has scruples, and he’s needlessly suffering for them.

We’re all imposters in a way—I sure am—but poor Mitch feels guilty about it. He knows that it’s not brilliance, just cleverness, that’s the foundation of his fortune. What’s wrong with that? He knows that timing and good luck played a much larger part in the success of 1-2-3 than did technical innovation. He knows that without Dan Bricklin and VisiCalc, 1-2-3 and theKapor house and the Kapor jet and the Kapor shirt collection would never have happened.

“Relax and enjoy it,” I say, but Mitch Kapor won’t relax. Instead, he crisscrosses the country in his jet, trying to convince himself and the world that 1-2-3 ^was not a fluke and that he can[PS3]  do it all again. He’s also trying to convince universities that they ought to promote a new career path called software designer, which is the name he has devised for his proto-technical function. A software designer is a smart person who thinks a lot about software but isn’t a very good programmer. If Kapor is successful in this educational campaign, his career path will be legitimized and be made guilt free but at the cost of others having to pay dues, not knowing that they shouldn’t really have to.

 

**********

 

“Good artists copy,” said Pablo Picasso. “Great artists steal.”

I like this quotation for a lot of reasons, but mainly I like it because the person who told it to me was Steve Jobs, co-founder of Apple Computer, virtual inventor of the personal computer business as it exists today, and a died-in-the-wool sociopath. Sometimes it takes a guy like Steve to tell things like they really are. And the way things really are in the computer business is that there is a whole lot of copying going on. The truly great ideas are sucked up quickly by competitors, and then spit back on the market in new products that are basically the old products with slight variations added to improve performance and keep within the bounds of legality. Sometimes the difference between one computer or software program and the next seems like the difference between positions 63 and 64 in the Kama Sutra, where 64 is the same as 63 but with pinkies extended.

The reason for this copying is that there just aren’t very many really great ideas in the computer business—ideas good enough and sweeping enough to build entire new market segments around. Large or small, computers all work pretty much the same way—not much room for earth-shaking changes there. On the software side, there are programs that simulate physical[PS4]  systems, or programs that manipulate numbers (spreadsheets), text and graphics (word processors and drawing programs), or raw data (databases). And that’s about the extent of our genius so far in horizontal applications—programs expected to appeal to nearly every computer user.

These apparent limits on the range of creativity mean that Dan Bricklin invented the first spreadsheet, but you and I didn’t, and we never can. Despite our massive intelligence and good looks, the best that we can hope to do is invent the next spreadsheet or maybe the best spreadsheet, at least until our product, too, is surpassed. With rare exceptions, what computer software and hardware engineers are doing every day is reinventing things. Reinventing isn’t easy, either, but it can still be very profitable.

The key to profitable reinvention lies in understanding the relationship between computer hardware and software. We know that computers have to exist before programmers will write software specifically for them. We also know that people usually buy computers to run a single compelling software application. Now we add in longevity—the fact that computers die young but software lives on, nearly forever. It’s always been this way. Books crumble over time, but the words contained in those books—the software—survive as long as readers are still buying and publishers are still printing new editions. Computers don’t crumble—in fact, they don’t even wear out—but the physical boxes are made obsolete by newer generations of hardware long before the programs and data inside have lost their value.

What software does lose in the transition from one hardware generation to the next is an intimate relationship with that hardware. Writing VisiCalc for the Apple II, Bob Frankston had the Apple hardware clearly in mind at all times and optimized his work to run on that machine by writing in assembly language— the internal language of the Apple II’s MOStek 6502 microprocessor—rather than in some higher-level language like BASIC or[PS5]  FORTRAN. When VisiCalc was later translated to run on other types of computers, it lost some of that early intimacy, and performance suffered.

But even if intimacy is lost, software hangs on because it is so hard to produce and so expensive to change.

Moore’s Law says that the number of transistors that can be built on a given area of silicon doubles every eighteen months, which means that a new generation of faster computer hardware appears every eighteen months too. Cringely’s Law (I just thought this up) says that people who actually rely on computers in their work won’t tolerate being more than one hardware generation behind the leading edge. So everyone who can afford to buys a new computer when their present computer is three years old. But do all these users get totally new software every time they buy a new computer to run it on? Not usually, because the training costs of learning to use a new application are often higher than the cost of the new computer to run it on.

Once the accounting firm Ernst & Young, with its 30,000 personal computers, standardizes on an application, it takes an act of God or the IRS to change software.

Software is more complex than hardware, though most of us don’t see it that way. It seems as if it should be harder to build computers, with their hundreds or thousands of electrical connections, than to write software, where it’s a matter of just saying to the program that a connection exists, right? But that isn’t so. After all, it’s easier to print books than it is to write them.

Try typing on a computer keyboard. What’s happening in there that makes the letters appear on the screen? Type the words “Cringely’s mom wears army boots” while running a spreadsheet program, then using a word processor, then a different word processor, then a database. The internal workings of each program will handle the words differently—sometimes radically differently—from the others, yet all run on the same hardware and all yield the same army boots.

Woz designed and built the Apple I all by himself in a couple of months of spare time. Even the prototype IBM PC was slapped together by half a dozen engineers in less than thirty days. Software is harder because it takes the hardware only as a starting point and can branch off in one or many directions, each involving levels of complexity far beyond that of the original machine that just happens to hold the program. Computers are house scaled, while software is building scaled.

The more complex an application is, the longer it will stay in use. It shouldn’t be that way, but it is. By the time a program grows to a million lines of code, it’s too complex to change because no one person can understand it all. That’s why there are mainframe computer programs still running that are more than 30 years old.

In software, there are lots of different ways of solving the same problem. VisiCalc, the original spreadsheet, came up with the idea of cells that had row and column addresses. Right from the start, the screen was filled with these empty cells, and without the cells and their addresses, no work could be done. The second spreadsheet program to come along was called T/Maker and was written by Peter Roizen. T/Maker did not use cells at all and started with a blank screen. If you wanted to total three rows of numbers in T/Maker, you put three plus signs down the left-hand side of the screen as you entered the numbers and then put an equal sign at the bottom to indicate that was the place to show a total. T/Maker also included the ability to put blocks of text in the spreadsheet, and it could even run text vertically as well as horizontally. VisiCalc had nothing like that.

A later spreadsheet, called Framework and written by Robert Carr, replaced cells with what Carr called frames. There were different kinds of frames in Framework, with different properties —like row-oriented frames and column-oriented frames, for example. Put some row-oriented frames inside a single column-oriented frame, and you had a spreadsheet. That spreadsheet could then be put as a nested layer inside another spreadsheet also built of frames. Mix and match your frames differently, and you had a database or a word processor, all without a cell in sight.

If VisiCalc was an apple, then T/Maker was an orange, and Framework was a rutabaga, yet all three programs could run on identical hardware, and all could produce similar output although through very different means. That’s what I mean by software being more complex than hardware.

Having gone through the agony of developing an application or operating system, then, software developers have a great incentive to greet the next generation of hardware by translating the present software—”porting” it—to the new environment rather than starting over and developing a whole new version that takes complete advantage of the new hardware features.

It’s at this intersection of old software and new hardware that the opportunity exists for new applications to take command of the market, offering extra features, combined with higher performance made possible by the fact that the new program was written from scratch for the new computer. This is one of the reasons that WordStar, which once ruled the market for CP/M word processing programs, is only a minor player in today’s MS-DOS world, eclipsed by WordPerfect, a word processing package that was originally designed to run on Data General minicomputers but was completely rewritten for the IBM PC platform.

In both hardware and software, successful reinvention takes place along the edges of established markets. It’s usually not enough just to make another computer or program like all the others; the new product has to be superior in at least one respect. Reinvented products have to be cheaper, or more powerful, or smaller, or have more features than the more established products with which they are intended to compete. These are all examples of edges. Offer a product that is in no way cheaper, faster, or more versatile—that skirts no edges—and buyers will see no reason to switch from the current best-seller.

Even the IBM PC skirted the edges by offering both a 16-bit processor and the IBM nameplate, which were two clear points of differentiation.

Once IBM’s Personal Computer was established as the top-selling microcomputer in America, it not only followed a market edge, it created one. Small, quick-moving companies saw that they had a few months to make enduring places for themselves purely by being the first to build hardware and software add-ons for the IBM PC. The most ambitious of these companies bet their futures on IBM’s success. A hardware company from Cleveland called Tecmar Inc. camped staffers overnight on the doorstep of the Sears Business Center in Chicago to buy the first two IBM PCs ever sold. Within hours, the two PCs were back in Ohio, yielding up their technical secrets to Tecmar’s logic analyzers.

And on the software side, Lotus Development Corp. in Cambridge, Massachusetts, bet nearly $4 million on IBM and on the idea that Lotus 1-2-3 would become the compelling application that would sell the new PC. A spreadsheet program, 1-2-3 became the single most successful computer application of all.

Mitch Kapor had a vision, a moment of astounding insight when it became obvious to him how and why he should write a spreadsheet program like 1-2-3. Vision is a popular word in the computer business and one that has never been fully defined—until now. Just what the heck does it mean to have such a vision?

George Bush called it the “vision thing.” Vision—high-tech executives seem to bathe in it or at least want us to think that they do. They are “technical visionaries,” having their “technical visions” so often, and with such blinding insight, that it’s probably not safe for them to drive by themselves on the freeway. The truth is that technical vision is not such a big deal.

Dan Bricklin’s figuring out the spreadsheet, that’s a big deal, but it doesn’t fit the usual definition of technical vision, which is the ability to foresee potential in the work of others. Sure, some engineer working in the bowels of IBM may think he’s come up with something terrific, but it takes having his boss’s boss’s boss’s boss think so, too, and say so at some industry pow-wow before we’re into the territory of vision. Dan Bricklin’s inventing the spreadsheet was a bloody miracle, but Mitch Kapor’s squinting at the IBM PC and figuring out that it would soon be the dominant microcomputer hardware platform—that’s vision.

There, the secret’s out: vision is only seeing neat stuff and recognizing its market potential. It’s reading in the newspaper that a new highway is going to be built and then quickly putting up a gas station or a fast food joint on what is now a stretch of country road but will soon be a freeway exit.

Most of the so-called visionaries don’t program and don’t design computers—or at least they haven’t done so for many years. The advantages these people have are that they are listened to by others and, because they are listened to by others, all the real technical people who want the world to know about the neat stuff they are working on seek out these visionaries and give them demonstrations. Potential visions are popping out at these folks all the time. All they have to do is sort through the visions and apply some common sense.

Common sense told Mitch Kapor that IBM would succeed in the personal computer business but that even IBM would require a compelling application—a spreadsheet written from scratch to take advantage of the PC platform—to take off in the market. Kapor, who had a pretty fair idea of what was coming down the tube from most of the major software companies, was amazed that nobody seemed to be working on such a native-mode PC  spreadsheet, leaving the field clear for him. Deciding to do 1-2-3 was a “no brainer.”

When IBM introduced its computer, there were already two spreadsheet programs that could run on it—VisiCalc and Multiplan—both ported from other platforms. Either program could have been the compelling application that IBM’s Don Estridge knew he would need to make the PC successful. But neither VisiCalc nor Multiplan had the performance, the oomph, required to kick IBM PC sales into second gear, though Estridge didn’t know that.

The PC sure looked successful. In the four months that it was available at the end of 1981, IBM sold about 50,000 personal computers, while Apple sold only 135,000 computers for the entire calendar year. By early 1982, the PC was outselling Apple two-to-one, primarily by attracting first-time buyers who were impressed by the IBM name rather than by a compelling application.

At the end of 1981, there were 2 million microcomputers in America. Today there are more than 45 million IBM-compatible PCs alone, with another 10 million to 12 million sold each year. It’s this latter level of success, where sales of 50,000 units would go almost unnoticed, that requires a compelling application. That application—Lotus 1-2-3—didn’t appear until January 26, 1983.

Dan Bricklin made a big mistake when he didn’t try to get a patent on the spreadsheet. After several software patent cases had gone unsuccessfully as far as the U.S. Supreme Court, the general thinking when VisiCalc appeared in 1979 was that software could not be patented, only copyrighted. Like the words of a book, the individual characters of code could be protected by a copyright, and even the specific commands could be protected, but what couldn’t be protected by a copyright was the literal function performed by the program. There is no way that a copyright could protect the idea of a spreadsheet. Protecting the idea would have required a patent.

Ideas are strange stuff. Sure, you could draw up a better mousetrap and get a patent on that, as long as the Patent Office saw the trap design as “new, useful, and unobvious.” A spreadsheet, though, had no physical manifestation other than a particular rhythm of flashing electrons inside a microprocessor. It was that specific rhythm, rather than the actual spreadsheet function it performed, that could be covered by a copyright. Where the patent law seemed to give way was in its apparent failure to accept the idea of a spreadsheet as a virtual machine. VisiCalc was performing work there in the computer, just as a mechanical machine would. It was doing things that could have been accomplished, though far more laboriously, by cams, gears, and sprockets.

In fact, had Dan Bricklin drawn up an idea for a mechanical spreadsheet machine, it would have been patentable, and the patent would have protected not only that particular use for gears and sprockets but also the underlying idea of the spreadsheet. Such a patent would have even protected that idea as it might later be implemented in a computer program. That’s not what Dan Bricklin did, of course, because he was told that software couldn’t be patented. So he got a copyright instead, and the difference to Bricklin between one piece of legal paper and the other was only a matter of several hundred million dollars.

On May 26, 1981, after seven years of legal struggle, S. Pal Asija, a programmer and patent lawyer, received the first software patent for SwiftAnswer, a data retrieval program that was never heard from again and whose only historical function was to prove that all of the experts were wrong; software could be patented. Asija showed that when the Supreme Court had ruled against previous software patent efforts, it wasn’t saying that software was unpatentable but that those particular programs weren’t patentable. By then it was too late for Dan Bricklin. By the time VisiCalc appeared for the IBM PC, Bricklin and Frankston’s spreadsheet was already available for most of the top-selling microcomputers. The IBM PC version of VisiCalc was, in fact, a port of a port, having been translated from a version for the Radio Shack TRS-80 computer, which had been translated originally from the Apple II. VisiCalc was already two years old and a little tired. Here was the IBM PC, with up to 640K of memory available to hold programs and extra features, yet still VisiCalc ran in 64K, with the same old feature set you could get on an Apple II or on a “Trash-80.” It was no longer compelling to the new users coming into the market. They wanted something new.

Part of the reason VisiCalc was available on so many microcomputers was that Dan Fylstra’s company, which had been called Personal Software but by this time was called VisiCorp, wanted out of its contract with Dan Bricklin’s company, Software Arts. VisiCorp had outgrown Fylstra’s back bedroom in Massachusetts and was ensconced in fancier digs out in California, where the action was. But in the midst of all that Silicon Valley action, VisiCorp was hemorrhaging under its deal with Software Arts, which still paid Bricklin and Frankston a 37.5 percent royalty on each copy of VisiCalc sold. VisiCalc sales at one point reached a peak of 30,000 copies per month, and the agreement required VisiCorp to pay Software Arts nearly $12 million in 1983 alone—far more than either side had ever expected.

Fylstra wanted a new deal that would cost his company less, but he had little power to force a change. A deal was a deal, and hackers like Bricklin and Frankston, whose professional lives were based on understanding and following the strict rules of programming, were not inclined to give up their advantage cheaply. The only coercion entitled VisiCorp under the contract, in fact, was its right to demand that Software Arts port VisiCalc to as many different computers as Fylstra liked. So Fylstra made Bricklin port VisiCalc to every microcomputer.

It was clear to both VisiCorp and Software Arts that the 37.5 percent royalty was too high. Today the usual royalty is around 15 percent. Fylstra wanted to own VisiCalc outright, but in two years of negotiations, the two sides never came to terms.

VisiCorp had published other products under the same onerous royalty schedule. One of those products was VisiPlot/Visi-Trend, written by Mitch Kapor and Eric Rosenfield. VisiPlot/ VisiTrend was an add-on to VisiCalc; it could import data from VisiCalc and other programs and then plot the data on graphs and apply statistical tests to determine trends from the data. It was a good program for stock market analysis.

VisiPlot/VisiTrend was derived from an earlier Kapor program written during one of his many stints of graduate work, this time at the Sloan School of Management at MIT. Kapor’s friend Rosenfield was doing his thesis in statistics using an econometric modeling language called TROLL. To help Rosenfield cut his bill for time on the MIT computer system, Kapor wrote a program he called Tiny TROLL, a microcomputer subset of TROLL. Tiny TROLL was later rewritten to read VisiCalc files, which turned the program into VisiPlot/VisiTrend.

VisiCorp, despite its excessive royalty schedule, was still the most successful microcomputer software company of its time. For its most successful companies, the software business is a license to print money. After the costs of writing applications are covered, profit margins run around 90 percent. VisiPlot/VisiTrend, for example, was a $249.95 product, which was sold to distributors for 60 percent off, or $99.98. Kapor’s royalty was 37.5 percent of that, or $37.49 per copy. VisiCorp kept $62.49, out of which the company paid for manufacturing the floppy disks and manuals (probably around $15) and marketing (perhaps $25), still leaving a profit of $22.49. Kapor and Rosenfield earned about $500,000 in royalties for VisiPlot/Visilrend in 1981 and 1982, which was a lot of money for a product originally intended to save money on the Sloan School time-sharing system but less than a tenth of what Dan Bricklin and Bob Frankston were earning for VisiCalc, VisiCorp’s real cash cow. This earnings disparity was not lost on Mitch Kapor.

Kapor learned the software business at VisiCorp. He moved to California for five months to work for Fylstra as a product manager, helping to select and market new products. He saw what was both good and bad about the company and also saw the money that could be made with a compelling application like VisiCalc.

VisiCalc wasn’t the only program that VisiCorp wanted to buy outright in order to get out from under that 37.5 percent royalty. In 1982, Roy Folke, who worked for Fylstra, asked Kapor what it would take to buy VisiPlot/VisiTrend. Kapor first asked for $1 million—that magic number in the minds of most programmers, since it’s what they always seem to ask for. Then Kapor thought again, realizing that there were other mouths to feed from this sale, other programmers who had helped write the code and deserved to be compensated. The final price was $1.2 million, which sent Mitch Kapor home to Massachusetts with $600,000 after taxes. Only three years before, he had been living in a room in Marv Goldschmitt’s house, wondering what to do with his life, and playing with an Apple II he’d hocked his stereo to buy.

Kapor saw the prototype IBM PC when he was working at VisiCorp. He had a sense that the PC and its PC-DOS operating system would set new standards, creating new edges of opportunity. Back in Boston, he took half his money—$300,000—and bet it on this one-two punch of the IBM PC and PC-DOS. It was a gutsy move at the time because experts were divided about the prospects for success of both products. Some pundits saw real benefits to PC-DOS but nothing very special about IBM’s hardware.

Others thought IBM hardware would be successful, though probably with a more established operating system. Even IBM was hedging its bets by arranging for two other operating systems to support the PC—CP/M-86 and the UCSD p-System. But the only operating system that shipped at the same time as the PC, and the only operating system that had IBM’s name on it, was PC-DOS. That wasn’t lost on Mitch Kapor either.

When riding the edges of technology, there is always a question of how close to the edge to be. By choosing to support only the IBM PC under PC-DOS, Kapor was riding damned close to the edge. If both the computer and its operating system took off, Kapor would be rich beyond anyone’s dreams. If either product failed to become a standard, 1-2-3 would fail; half his fortune and two years of Kapor’s life would have been wasted. Trying to minimize this same risk, other companies adopted more conservative paths. In San Diego, Context Management Systems, for example, was planning an integrated application far more ambitious than Lotus 1-2-3, but just in case IBM and PC-DOS didn’t make it, Context MBA was written under the UCSD p-System.

That lowercase p stands for pseudo. Developed at the University of California at San Diego, the p-System was an operating system intended to work on a wide variety of microprocessors by creating a pseudomachine inside the computer. Rather than writing a program to run on a specific computer like an IBM PC, the idea was to write for this pseudocomputer that existed only in computer memory and ran identically in a number of different computers. The pseudomachine had the same user interface and command set on every computer, whether it was a PC or even a mainframe. While the user programmed the pseudomachine, the pseudomachine programmed the underlying hardware. At least that was the idea.

The p-System gave the same look and feel to several otherwise dissimilar computers, though at the expense of the added  pseudomachine translation layer, which made the p-System S-L-O-W—slow but safe, to the minds of the programmers writing Context MBA, who were convinced that portability would give them a competitive edge. It didn’t.

Context MBA had a giant spreadsheet, far more powerful than VisiCalc. The program also offered data management operations, graphics, and word processing, all within the big spreadsheet. Like Mitch Kapor and Lotus, Context had hopes for success beyond that of mere mortals.

Context MBA appeared six months before 1-2-3 and had more features than the Lotus product. For a while, this worried Kapor and his new partner, Jonathan Sachs, who even made some changes in 1-2-3 after looking at a copy of Context MBA. But their worries were unfounded because the painfully slow performance of Context MBA, with its extended spreadsheet metaphor and p-System overhead, killed both the product and the company. Lotus 1-2-3, on the other hand, was written from the start as a high-performance program optimized strictly for the IBM PC environment.

Sachs was the programmer for 1-2-3, while Kapor called himself the software designer. A software designer in the Mitch Kapor mold is someone who wears Hawaiian shirts and is intensely interested in the details of a program but not necessarily in the underlying algorithms or code. Kapor stopped being a programmer shortly after the time of Tiny TROLL. The roles of Kapor and Sachs in the development of 1-2-3 generally paralleled those of Dan Bricklin and Bob Frankston in the development of VisiCalc. The basis of 1-2-3 was a spreadsheet program for Data General minicomputers already written by Sachs, who had worked at Data General and before that at MIT. Kapor wanted to offer several functions in one program to make 1-2-3 stand out from its competitors, so they came up with the idea of adding graphics and a word processor to Sachs’s original spreadsheet. This way users could crunch their financial data, prepare graphs and diagrams illustrating the results, and package it all in a report prepared with the word processor. It was the word processor, which was being written by a third programmer, that became a bottleneck, holding up the whole project. Then Sachs played with an early copy of Context MBA and discovered that the word processing module of that product was responsible for much of its poor performance, so they decided to drop the word processor module in 1-2-3 and replace it with a simple database manager, which Sachs wrote, retaining the three modules needed to still call it 1-2-3, as planned.

Unlike Context MBA, Lotus 1-2-3 was written entirely in 8088 assembly language, which made it very fast. The program beat the shit out of Multiplan and VisiCalc when it appeared. (Bill Gates, ever unrealistic when it came to assessing the performance of his own products, predicted that Microsoft’s Multiplan would be the death of 1-2-3.) The Lotus product worked only on the PC platform, taking advantage of every part of the hardware. And though the first IBM PCs came with only 16K of onboard memory, 1-2-3 required 256K to run—more than any other microcomputer program up to that time.

Given that Sachs was writing nearly all the 1-2-3 code under the nagging of Kapor, there has to be some question about where all the money was going. Beyond his own $300,000 investment, Kapor collected more than $3 million in venture capital —nearly ten times the amount it took to bring the Apple II computer to market.

The money went mainly for creating an organization to sell 1-2-3 and for rolling out the product. Even in 1983, there were thousands of microcomputer software products vying for shelf space in computer stores. Kapor and a team of consultants from McKinsey & Co. decided to avoid competitors entirely by selling 1-2-3 directly to large corporations. They ignored computer stores and computer publications, advertising instead in Time and Newsweek. They spent more than $1 million on mass market advertising for the January 1983 roll-out. Their bold objective was to sell up to $4 million worth of 1-2-3 in the first year. As the sellers of a financial planning package, it must have been embarrassing when they outstripped that first-year goal by 1,700 percent. In the first three months that 1-2-3 was on the market, IBM PC sales tripled. Big Blue had found its compelling application, and Mitch Kapor had found his gold mine.

Lotus sold $53 million worth of 1-2-3 in its first year. By 1984, the company had $157 million in sales and 700 employees. One of the McKinsey consultants, Jim Manzi, took over from Kapor that year as president, developing Lotus even further into a marketing-driven company centered around a sales force four times the size of Microsoft’s, selling direct to Fortune 1000 companies.

As Lotus grew and the thrill of the start-up turned into the drill of a major corporation, Kapor’s interests began to drift. To avoid the imposter label, Kapor felt that he had to follow spectacular success with spectacular success. If 1-2-3 was a big hit, just think how big the next product would be, and the next. A second product was brought out, Symphony, which added word processing and communications functions to 1-2-3. Despite $8 million in roll-out advertising, Symphony was not as big a success as 1-2-3. This had as much to do with the program’s “everything but the kitchen sink” total of 600 commands as it did with the $695 price. After Symphony, Lotus introduced Jazz, an integrated package for the Apple Macintosh that was a clear market failure. Lotus was still dependent on 1-2-3 for 80 percent of its royalties and Kapor was losing confidence.

Microsoft made a bid to buy Lotus in 1984. Bill Gates wanted that direct sales force, he wanted 1-2-3, and he wanted once again to be head of the largest microcomputer software  company, since the spectacular growth of Lotus had stolen that distinction from Microsoft. Kapor would become Microsoft’s third-largest stockholder.

“He seemed happy,” said Jon Shirley, who was then president of Microsoft. “We would have made him a ceremonial vice-chairman. Manzi was the one who didn’t like the plan.”

A merger agreement was reached in principle and then canceled when Manzi, who could see no role for himself in the technically oriented and strong-willed hierarchy of Microsoft, talked Kapor out of it.

Meanwhile, Software Arts and VisiCorp had beaten each other to a pulp in a flurry of lawsuits and countersuits. Meeting by accident on a flight to Atlanta in the spring of 1985, Kapor and Dan Bricklin made a deal to sell Software Arts to Lotus, after which VisiCalc was quickly put to death. Now there was no first spreadsheet, only the best one.

Four senior executives left Lotus in 1985, driven out by Manzi and his need to rebuild Lotus in his own image.

“I’m the nicest person I know,” said Manzi.

Then, in July 1986, finding that it was no longer easy and no longer fun, Mitch Kapor resigned suddenly as chairman of Lotus, the company that VisiCalc built.