OpenDoc

by Greg Maletic

Back in 1995, my first job at Apple was as a Product Marketing Manager for OpenDoc.

“OpenDoc” was a terrible name for an interesting technology. Instead of requiring developers to write huge applications that had to do many things (for instance, any credible word processor needs not just editing features but spell checking, tables, embeddable photos, etc.) the OpenDoc concept was that developers could just write the one piece they were best at, then let end-users mix and match all of the little pieces of functionality together as they wished.

It wasn’t an original idea; in fact, it’s exactly the same sort of thing that had been in Microsoft Office for years, allowing users to embed Excel spreadsheets inside of Word documents. But Microsoft controlled that technology, and for some reason, someone felt the need for an open alternative that other software vendors could embrace. Hence was born OpenDoc, both the technology and the consortium, consisting primarily of Apple, IBM, and WordPerfect, all companies that didn’t like Microsoft very much. All poured loads of money into the initiative. (The only software project at Apple that was bigger than OpenDoc was Copland.) It’s almost difficult now trying to recall why this technology was considered so fundamental to these companies’ strategies, but you have to remember that this was before the web took off, and what was important to everyone was the application layer…not the Internet.

The atomic unit of OpenDoc functionality was called a “part.” A part could be any useful bit of functionality–say a spreadsheet or a text editor–and users could drag and drop these parts into documents to combine code from multiple developers. With this model it was thought that we (the OpenDoc consortium and its adherents) could break Microsoft’s near-monopoly in the office suite market by opening it up to the small software vendors that had been shut out for years. (If you’ve got a little time on your hands and you’re one of those folks that likes arcane bits of Apple history, you can check out this twenty-five minute OpenDoc marketing video.)

Beyond developing the technology as a sort of “gift” to Mac developers (whether they perceived it as a gift is a separate discussion), there was a thought floating around the halls of Apple that, hey, we’re plunging a ton of money into OpenDoc, there must be some way we can leverage it in the operating system. The OpenDoc team was really into this idea, not just because it made them feel good that somebody was using their code, but because it meant that OpenDoc would be a required installation in future Mac OS releases. (Having your technology pre-installed with the OS is a big deal for third-party developers, because if it isn’t already on the system they’re not as keen on adopting it. Of course, the OS group resists adding new things because of increased complexity and memory footprint–more on this later.) For the reasons just outlined, the OS team’s excitement around OpenDoc was…more muted. And it was my assigned task to get that OS team to adopt OpenDoc in a big way.

Despite what the title “Product Marketing Manager” may imply, no one worked for me. As a product manager at Apple, your job was to go around to the various development arms of your assigned technology–engineering, quality assurance, human interface–and make sure they were doing things in a way that was conducive to making your technology appealing to customers. At gatherings when different product groups got together (say, the weekly Copland team meetings), you were the flag-bearer for your technology. That I was under-qualified for this task should have been obvious to me at the time, but it wasn’t. Though I was plenty technical enough to talk with Apple engineers, I lacked the confidence to really engage them head-on. Most importantly, I didn’t have the strategic insight that would have let me realize that maybe Apple wasn’t doing the right thing by pursuing OpenDoc so aggressively.

The Copland team was wary of OpenDoc. I looked at those people as bad guys at the time, but in reality they were right to be afraid. It’s hard to remember now, but back in 1996 memory (as in RAM) was a big issue. The average Mac had about 2 megabytes of memory. OpenDoc wouldn’t run on a machine with less than 4 megs, and realistically, 8 megs was probably what you wanted. That wasn’t the only issue. The OpenDoc human interface team had taken it upon themselves to correct the perceived flaws of the Mac as a modal, application-centric user experience, and instead adopted a document-centric model for OpenDoc apps. This played itself out in many ways, some not-so-important (the “File” menu became the “Document” menu, and the “Quit” command disappeared), others more so. It was a noble and interesting idea, but in retrospect it was a reach, not important to the real goals of OpenDoc, and it scared a lot of people including the developers we were trying to woo.

OpenDoc didn’t succeed. (I guess I have an affinity for stillborn technologies.) It didn’t create a new economy around tiny bits of application code, and the document-centric model was never allowed to bloom as we had hoped, to the point where it would differentiate the Mac user experience. The tragedy of this is that OpenDoc had many of Apple’s best engineers, and they–and many of our third-party developers–truly loved the technology and put their all into it. It didn’t matter. Everyone’s interest drifted to the web, and most of the folks working on OpenDoc went to Sun to work on Java; after my marketing team of six people dwindled down to just me, I left to start a Java tools company with a friend. There are lots of reasons for OpenDoc’s failure, but ultimately it comes down to the fundamental question of why Apple was developing this technology when no-one in the company really wanted it. The OS group had mixed feelings, but ultimately didn’t care. Most folks at Claris, Apple’s application group, didn’t want it at all, seeing it as an enabler for competition to Claris’s office suite product, ClarisWorks.

One of the smarter people in product marketing at the time was Vito Salvaggio, in charge of Copland product marketing. I remember giving a presentation to him one time, describing a core set of parts–text editing, image viewing, etc.–that would form a base set of functionality that developers could count on being bundled with the OS. I’m paraphrasing here, but I remember him asking, “who’s going to use the text editor when it has so little functionality?” In response, I quoted the Apple dictum that was ubiquitous at the time: we couldn’t have the text editor do more, because then it would be a full-featured text editor that would compete with our developers. (We had so few developers supporting the Mac as it was…how could we afford to put them out of business?) Yet Vito–and I can’t overstate how radical this was at the time–didn’t buy this reasoning. “Microsoft competes against their developers,” he told me. “They’re successful. Their developers are successful. And they’re kicking our asses. Why shouldn’t we be competing against our developers?” And it dawned on me: he was right. And he wasn’t just right, he was so right that it just completely slapped me in the face that everything we had been doing was wrong. Apple was so worried about stepping on its developers’ toes that it resisted any attempts to add useful functionality to Mac OS. It wasn’t the kind of company that could succesfully develop a technology like OpenDoc. That’s when I knew that OpenDoc would fail.

There aren’t any stats I’m aware of that conclude how many Macs have been purchased because of iPhoto, iMovie, and the like, but I can tell you that when I recommend the purchase of a Mac to someone, they’re the reason I do it. For the first time since MacWrite and MacPaint, the Mac actually does something out of the box.

Unless you have application groups who want to create functionality to run on your OS, it’s one hundred times harder to figure out what you’re supposed to be doing with your OS. Without those application groups telling us they needed–or didn’t need–OpenDoc, we were flying blind. (Witness the pathetic track record of other Mac OS technologies at the time to realize just how dead-on the phrase “flying blind” is: Copland, QuickDraw GX, QuickDraw 3D, Apple Guide, PowerTalk, CyberDog. All abject failures, despite their technical prowess.) This isn’t a problem that exists at Microsoft (at least, it certainly isn’t evident.) The Office group needed a component architecture, so they wrote one. They needed it integrated into the OS to support things like Publish/Subscribe, etc., and to leverage it into Explorer…it happened. The OS gets exactly the technology it needs because the application groups know exactly what they want. No one has to guess.

There’s no shortage of reasons why Steve Jobs has made Apple a success, but this is certainly one of the more important ones: he isn’t afraid of stomping on Mac developers in pursuit of what he believes the Macintosh should be. They may complain, but in all honesty, they’re better for it. And so is the Mac community.