Origins of Lotus Notes

Many thanks to Ray Ozzie for his invaluable contributions to this account.

Lotus got its start in 1981. Over its life from 1981 to 1995, the company launched dozens of products, but in the end only two mattered: the Lotus 1-2-3 spreadsheet, which legitimized the personal computer an indispensable business tool, and Lotus Notes, which pioneered the market for enterprise collaboration software.

1-2-3 was conceived in 1982, following on preliminary work begun the previous year. Released to the market in January 1983, it was a hit from day one and remained the number one productivity tool through the 80’s. Revenues in the first year topped $53 million, which was an astounding start, and we had a great run for many years. Microsoft Excel succeeded 1-2-3 as Windows replaced DOS as the dominant PC operating system in the early 1990’s and Microsoft Office took over.

Ray began his work on Lotus Notes in 1984 while I was still CEO, but the product was only finally released in 1990, three years after my departure, in large part because Microsoft Windows on which Notes depended had a very long gestation period and was only finally usable then.

By 1995 Notes had grown to the point that IBM acquired Lotus as a whole for $3.5 billion, not only for Notes itself but for all of the drag-along business it created for IBM in additional hardware, software, and services.

The creation of Lotus 1-2-3 was fundamentally a two person project, a collaboration between me and Jonathan Sachs. I was the designer and product manager and Jon was the technical architect and software developer. He let me dictate the features and user interface, and I left him alone to write all of the code. Quite a few other people ultimately played significant roles in completing and launching the product, and their stories deserve and will receive their own treatment.

Lotus Notes, as a much more ambitious and complex project, required a larger team but it also started and remained small for some time while ultimately growing quite large. As soon as the Notes project kicked off Ray brought in his collaborators Tim Halvorsen and Len Kawell. The team grew to five soon thereafter, then a dozen by shipment, and hundreds over time.


“The foundation for the ideas that Notes is based on began when I went to college at the University of Illinois on a computer system used for computer-based education called PLATO.

“This system connected over a thousand concurrent users using a centralized mainframe cluster. One of the very interesting and successful things that was developed on the system was a simple but effective conferencing and mail system known as Notes. The basis for many of the ideas in what we know as Lotus Notes came from that PLATO program and how it facilitated communications and collaboration among PLATO’s passionate user community.

“Having had exposure to this system, but having my heart in the emerging PC industry, I really wanted to reproduce some of the successful aspects of the PLATO Notes environment using PC’s connected by networks. Of course, in 1982 when I began to toy with the ideas, it was very hard to get a PC connected to a network; I was mostly thinking in the future.”

Ray and Jon knew each other from the time when both worked at Data General, a leading minicomputer manufacturer of the era. In fact, Jon had already tried to hire Ray for Lotus once before, in 1982 when Ray had been working at Software Arts on VisiCalc, but Ray turned him down. He’d found that his heart really wasn’t in spreadsheets. Instead, he wanted next to do a startup to create a PC-based, LAN-based, work-centric adaptation of Notes.

What’s more, I’m sure Lotus looked very risky at the time. While I was disappointed especially because Jon thought so highly of Ray’s talent, I could sympathize with Ray’s reluctance to make a switch. Lotus was located in a dark and dank basement on Franklin Street in Central Square in Cambridge. We had just shipped “Executive Briefing System”, an Apple II-based forerunner to Powerpoint, but its modest revenue was in no way able to support the company. We were betting the future on what would become 1-2-3, which at that time was still in the middle of development, and it was obvious to no one, myself included, that it actually posed a threat to the original and market-leading spreadsheet, Visicalc, developed by Software Arts.

This second time, in the spring of 1983, I made Ray an offer he couldn’t refuse. If he’d come to Lotus to help implement version 2 of Lotus 1-2-3, I’d help make sure he got the resources he needed to get his project off the ground. I thought Lotus might well want to fund it, and if not, I now had lots of friends in the venture capital industry owing to Lotus’ meteoric rise.

You could call me the Godfather of Lotus Notes.

Version 2 of 1-2-3 turned out to be Lotus Symphony. The team moved out of Lotus’ Cambridge office to Littleton near where Ray lived. Ray, John, and two young engineers, Barry Spencer and Matt Stern, started working there by late summer 1983. They wanted to be free of interruptions and to be able to concentrate with undivided attention on the code.   Being 30 miles away from headquarters afforded protection for the team from other developers and executives alike trying to drag them into the issues of the day.

Jon dropped out of the project, leaving Ray to lead the small team which successfully shipped nine months Symphony after inception, in July 1984. A couple of months before the release, the team moved back to Cambridge to Lotus’ First St. office, but the precedent had been set for the remote development model that would be used throughout the course of Lotus Notes.

I kept my promise, and, as his work on Symphony wound down, Ray imported the design documents he’d been working on since 1982 into the Symphony word processor and commenced updating them. This project he codenamed ECHO. He also borrowed an early Macintosh from the group working on Lotus’ efforts for the Mac in order to create graphical mockups of the ECHO applications.

For the next six months, Ray and I and the senior team at Lotus went back and forth about how to sequence the development and what to bring to market first.

Ray’s vision was always one of a connectivity-centric product, having been inspired by his early experiences with PLATO. He foresaw the world in which PC’s were no longer stand-alone devices but were networked together with PC-based servers in local area networks, and this architecture would supersede centralized systems with dumb terminals.

Lotus’ roots were in the world of stand-alone productivity applications like spreadsheets and word processors for personal computers that were intended for individual use. Paper still played a vital role. Important documents, whether spreadsheets or text were printed and shared by physically moving paper around the office or through the mail.

Lotus was a pioneer in personal productivity tools running on standalone PC’s. The idea of bringing to market new class of group-oriented productivity applications made perfect sense in the abstract, but there was considerable skepticism among senior managers at the company about whether enough PC’s would be LAN equipped any time soon. Networking for PC’s was in its infancy and back then there was a saying: “Next year will be the Year of the LAN… and always will be.”

After the launch of 1-2-3, Lotus never really had a coherent product strategy. We tried many, many different products aimed at business users and virtually all of them failed. I was much more interested in innovation per se than in understanding the needs of the market and modulating my enthusiasm for experimental products in favor of meeting customers where they were. Had I been more attuned to the real business opportunity instead of my own dreams then we would not have overlooked obvious opportunities, e.g., a PC-based word processor focused on the needs of business users. In this case too much imagination and not enough reality focus was not a good combination. Instead we took a gamble on a word processor aimed at the science and engineering segment, but there wasn’t really a there there.

As discussions about how to proceed with Ray’s project continued during the summer of 1984, considerable tension grew due to the risks inherent in pioneering this unusual new “networked groups” product category. In the end I couldn’t overlook the fact that the senior management who had joined Lotus to guide its expansion didn’t share my views.

In August of 1984 Ray proposed a compromise — a sequenced approach to develop stand-alone applications first and then add the network pieces to address these concerns.

“The original ECHO plan called for implementing the project “bottom-up”, that is, the networking software would be implemented first, followed by the productivity tools. By “inverting” the project, we would attempt to produce the productivity tools before the networking software.

“The strategy is as follows: First, produce a product that is extremely powerful and useful as a stand-alone product. This base product should also be useful on a stand-alone local area network (no gateways or remote user interfaces, etc.).   Then, after the product is successful, enhance its value further by implementing the remaining pieces of ECHO: the remote user interface front-end and the store-and-forward back-end.”

In this inverted approach, we would be able to bring products to market much more quickly. The scope of work to do just the applications was a lot less and the work would be much less complex.

Ray and I went back and forth to develop a spec which could gain the support of Lotus’ Product Review committee, and I assured him privately once we got past people’s objections, he’d have the opportunity to shape things. Though I was the CEO, I felt it was important to get buy in rather than issue decisions by fiat.

Ray refined the design document he was working on to give it more of a personal productivity spin. It had a number of concepts adapted from Ted Nelson’s pioneering work in hypertext as well. This document is the one that got past the committee in December 1984.

But in early 1985, after the project had been formally approved, and with my complete agreement, Ray and the Notes team abandoned the compromise and reverted back to the original vision of building from the bottom up, starting the network infrastructure all the way up to the user-facing applications. It lengthened the process and made the development far more complex but there were a couple of good reasons this was the right decision.

First, it was more true to Ray’s vision and passion. This was key, because bringing ambitious new products of any kind to market requires, among other things, a style of leadership that goes above and beyond the ordinary financially-driven imperatives of business. When you build what you most care about, it gives you the strength to persevere through the inevitable trials and obstacles which lie along the path to accomplishment. As an entrepreneur myself, I understood this at a gut level and found myself reluctant about trying to turn Ray’s attention to anything other than what he most centrally believed in. I know I didn’t like it when people did that to me.

Second, the compromise approach was a kind of kludge, driven partly by internal corporate politics and partly by me trying to find a place to land a new set of intuitions I had about “a spreadsheet for ideas”.

I was personally excited about evolving applications uses to produce and manage text (everything from simple list managers to complex word processors capable of producing a book-length manuscript) to deal with structured text. An outline is a simple example of structured text in which individual elements are organized into a hierarchy of items. I was starting to think about much more fluid and dynamic structures, as inspired by the pioneering work of Doug Englebart and Ted Nelson.

I saw Ray’s project as a potential vehicle for some of my own unrealized ideas. As CEO, I no longer had the time to work intensively on individual projects, which was a loss for me. This was going to be the best substitute I could think of.

But I came to understand that it made more sense to go into that as a stand-alone project rather than to try to graft it onto Ray’s project. Ultimately a different group in Lotus produced Lotus Agenda, about which more at another time.


Coming up with the architecture for Notes to make all this happen was an enormous challenge, as was the implementation of that architecture. At most only a few teams in the entire world had the skills to bring it off.

Because Ray was so early in developing these concepts, even the technical vocabulary used to describe the components of the system was not yet standardized.

Notes relied on what came to be known as a client-server architecture. The “remote user interface” referred to the Notes desktop client program on the end user’s computer. The “store-and-forward back end” meant the Notes Server.

The client and the server communicated over the Local Area Network. When the user first created new content, it would be stored on a database local to the user’s personal computer. When the computer was attached to the network (either via LAN or a dial-up modem), the data would be synchronized with a replica of the same database on a Notes server. There would be two identical instances of the same database.

All along, Ray intended that the PC-based servers themselves would communicate with one another by replicating their contents with one another across ordinary dial-up phone lines. This would enable teams within and across globally distributed organizations to be connected. This was a technical challenge of another order.

In today’s world, we assume that connected devices of any type (whether smart phones, tablets, laptops, smart watches or any of the multitude of devices known as the Internet of Things) are connected via the Internet to servers “in the cloud”.

While there is a great deal of complexity to the Internet in how packets of information find their way across the network from one end to the other, much of the complexity is hidden from end users and application developers because it is mostly encapsulated within the technical protocols of the layers of the Internet. It’s something that is simply there to use.

In the case of Notes there was no such underlying infrastructure to rely on. Part of the development challenge was to have to build it. It was like not only building a fleet of trucks and cars, but also the roads and bridges the vehicles were to travel on.

Connections between computers were both intermittent and slow. There was no wireless connectivity at all. There were no cable modems. In fact, there was no high-speed connectivity to homes at all. Ordinary telephone lines were slow, and special high-speed telephone lines were very expensive (hundred to thousands to tens of thousands of dollars per month).

So, in order to afford users the ability to access any kind of information, as there was no cloud to reach into, it was necessary to create locally stored copies.

As users created new content, it would at first be stored on a local server. Sets of changes would be bundled together on each local server and periodically forwarded over the network from server to server. Sometimes this was referred to as “store and forward”.

This logic of coordination to ensure that local and remote copies of information synchronized correctly and were as up-to-date as possible is quite complex. The flow of data was modeled in part on the UUCP and USENET protocols. In this fashion, ideas which originated in the computer science research community migrated their way into the commercial world.

While the Internet as we now know it was still a very long way off, UUCP (Unix-to-Unix Copy Program) was already well-established in the technical and academic communities as a way to connect distant computers. It was used to route email and distribute USENET (Users’ Network) newsgroups, an early realization of conferencing or bulletin board software. Ray was familiar with UUCP and USENET from the time he worked at Software Arts and it served as an inspiration for Notes’ replication capabilities.


“Relational databases, the mainstays of the business world organize data into a set of tables with a unique key identifying the data in each row. It is a highly efficient way of organizing huge volumes of regularly-structured data. But when the structure of the data is loose, unknown, rapidly changing, or highly distributed, the relational model is a poor fit.”

Recognizing there are many problems for which the relational model is a Procrustean bed and this a poor fit, in recent years there has been a movement to create more flexible high-performance databases. These are sometimes referred to as NoSQL databases and Notes is the ancestor of them all. Once again, Ray and the team were way ahead of their time.

In the next segment, I will write about the story of the unique business relationship that Ray and I formed to bring Notes to market.