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 tech talk about OpenDoc, and this much shorter 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.
Greg Maletic 
As a Mac developer back in the days of OpenDoc, one issue with adoption was that the programming model was such a radical departure from classic Macintosh development. Not just the programming language (C++ was still pretty new), but the way you had to develop things.
That said, OpenDoc still seemed a compelling technology. In 1997, when it was killed, I made a prediction that in 20 years, OpenDoc would be the way we developed software. (Of course, it wouldn’t be OpenDoc, and certainly not called OpenDoc, but it would work like OpenDoc)
It’s been 9 years, so we still have 11 to go, but I fear I’ve been wrong all these years, since I’ve yet to see the level of componentization I expected. It may just be that the Software leaders have too much invested in the existing paradigm.
As for the other failed technologies, I wasted far too much of my life on PowerTalk (aka AOCE). This was an amazing idea with an absolutely terrible implementation and even worse documentation. Pieces of similar technologies exist (like JMS), but none with the end-user perspective.
I worked in the Advanced Technology Group at Apple in the summer of 1995, and I actually built one of the only functioning OpenDoc parts. I use the term functioning loosely, since the development environment and frameworks were so twitchy nothing was really production quality.
I agree with your comment on the OpenDoc UI folks fighting old battles, and trying to move to a document-centric interface. Very theoretical gain, and it was too subtle for users to appreciate, even assuming it was correct.
The difference between components and services gets pretty subtle, once everything can communicate and exchange data. With XML, SOAP, AJAX, etc. today, people are building highly component-based software, but definitely not in the model that OLE & OpenDoc would have had us.
This post really takes me back – I remember the how fanatical the CyberDog fans were at the time!
In 1994, I went to an IBM developer’s conference and saw OpenDoc for the first time. I was stunned by its utility.
While I couldn’t see, at the time, how it would be really useful for consumers, I was mesmerized by the power and potential for line of business applications. The idea that you could just drag together different OpenDoc objects to create an entirely new business application was an epiphany.
For example, take your accounting application and just drag in a different company’s costing object and another’s salesforce automation object and have them seamlessly communicate, was a systems implementation dream come true. And here we are ~20 years later and there isn’t ANYTHING CLOSE to that future IBM/Apple implicitly promised and I envisioned.
What is really sad is that the overhead needed by the OpenDoc environment would have been a moot point if it was released as little as 10 years later (though perhaps it would have bloated up through poorer programming practices, it’s amazing how programming on underpowered computers improves your app’s computing efficiency). I’m out of work right now, but still dream of kind of functionality.
Another area the concept could be used is in an “OpenDoc-like” online game. Imagine hundreds of vendors creating game apps (maybe even as simple as a weapon) that could be dragged into the game to give you that weapon’s functionality (at least as much as the particular game would allow (a laser sword that would do specified damage on particular objects (e.g. walls, doors, monsters) in both sci-fi and fantasy games, but do it differently, based on what is allowed by the rules of the world)). the same “weapon-app” could use OpenDoc’s interface to work on totally unrelated games. This would allow for truly organic worlds. You could create a new weapons by dragging, say, a new battery pack onto an existing laser gun that would increase its damage an life span. While that world may eventually “devolve” into chaos through cumulative damage, it would be a blast while it lasted. Then again, perhaps different planets/dimensions would eventually become uninhabitable and have to be abandoned, only to have “nature” later bring it back, similar, but evolutionarily different.
Oh, so much potential, but (very apparently) was way, Way, WAY before it’s time!
In the meantime, I’m (not so) patiently waiting…
Cyberdog was terrific, although that had little to do with it being comprised of OpenDoc parts, at least in use. Oh, being OpenDoc parts meant that you could do wacky things like create a document containing multiple resizable views of live web pages plus your email in-box, which made for a great demo (and it was cool how the web pages would scale in their entirety), but ultimately CyberDog was just a really slick set of Internet tools — email, web browser, FTP. Plus it was fun to use. Then again, probably no apps I have ever used are as completely fun to use as the current suite of iApps, so if OpenDoc had to die (and it did) in order to enable apps such as iWeb, Keynote and Pages etc. to appear, so be it. No one cries for the Mac user.
One thing that isn’t mentioned here is the Bento (?) file format, which supported versioning, and displaying component data in a way that degraded nicely if the viewer’s computer didn’t have a suitable component (an example – hypothetical probably because nothing was ever quite finished – was that a document with a 3D model embedded in it would still display a simple picture on a computer without a 3d viewer). I guess the application independent document format lives on somewhat in XML.
The guy who wrote the specification for Bento left Apple shortly after OpenDoc was canned, and I think he started writing a open sequal called IronDoc. I wonder what he moved on to eventually?
I was probably one of the few people in New Zealand who owned a copy of Wav (the word processor). Ironically, I tried to import my thesis into it, only to discover it couldn’t do more than about 10 pages, which seemed scarily reminiscent of the 10 pages or so the original MacWrite could store in memory on a origina 128k Mac. I would sit around embedding clocks into documents, waiting for someone to make another commercial part for me to buy. I finally threw out the CD just a month ago when moving house…
Ah, Bento ….
Bento is the container format for Avid’s “open” media format for interchange (OMFI).
So it’s been in continuous use since 1994 (by people making loads of money), and still ships with an Apple product (Final Cut Pro).
I know it didn’t happen in this order, but trying to comprehend OMFI earlier this century, Bento just looked like the final layer of obfuscation Avid put on to make the open format comprehensible only to them.
By the way, the initial link to OpenDoc points nowhere… Where you trying to link to the Wikipedia:
Wikipedia: OpenDoc
Thanks, Juan. Link fixed.
Bento was the child of David McCusker, whose address book format for Netscape is described here on this page: http://bjf.id.au/cgi-bin/blosxom.cgi/software/20050429-mork.html
The administration interface for AppleShareIP 6 was an OpenDoc application. The new document-centric paradigm for the interface manifested itself in an application that tended to crash frequently and that ignored making things easy for the user (drag-and-drop between users and groups was very broken for the first releases).
It’s great to hear of OpenDoc; I was an enthusiastic user. I used Cyberdog a few months ago, because Mail handling a particular enclosure. The Dog did it perfectly.
I bought every openDoc part I could find.
but then, I still use my Newton.
@Bill Coleman
Speaking as a non-developer, it seems to me that OS X has done a pretty good job of chopping functional bits out into the OS that developers can then use like building blocks. As someone whose job is based around the written word, I can tell you that I appreciate the standard and high-quality text editing and typography tools that are built right into the OS. Option-escape word completion from within a browser is just great. From what I understand, the Core APIs and so forth are a developer’s dream.
It’s the developers, though, not the users who assemble the building blocks. Users aren’t coders and we prefer problems to be solved magically for us. Does anyone really use Automater?
Good to see that you’re still kicking, Greg! My experience with OpenDoc started in 1993. The Center for Research in Math and Science Education in San Diego had an NSF grant to develop physics simulators for use in high school physics classes. They needed an inexpensive text editor in which to write the curriculum. I described a wonderful new technology in development at Apple that would allow them to run their simulators in situ (within the editor). Not long afterward, an acquaintance introduced me to Physicon Ltd of Moscow, Russia and I incorporated MetaMind Software to develop the text editor shell, called Dock’Em. Physicon wrote 5 physics simulators under OpenDoc; I wrote a 6th (Force and Motion). We started selling in August 1994 and as everyone knows, Jobs cancelled OpenDoc in March 1995. OpenDoc still works in OS 9.2.2 under Panther on the PowerPC. I use them still in my high school Physics classes.
I developed and taught Apple Developer University’s OpenDoc seminar.
I saw OpenDoc a bit differently.
(1) It never worked very well
(2) Writing simple components wasn’t too bad, but writing a component that could embed other components was next to impossible.
(3) ODF came too late in the game and, while in some ways was needed, also made “parts” too big and slow to work on then current machines.
(4) Debugging was a nightmare. SOM was a nightmare.
Some pieces of OpenDoc were well thought out, but others were never thought out at all. Apple used to tell everyone how you could have a ‘spell checker’ part, for example, even though there was no way to do a functional (non-visual) part.
The sad thing is that OpenDoc would be almost trivial in Cocoa and Mac OS X what with bundles for document files (simple i/o instead of Bento), introspective GUI elements, standard encoding and decoding of objects, background threads, and Quartz for graphics.
2 Gigs of memory and 2GHz machines wouldn’t have hurt either.
CyberDog was great, but I was never sure if OpenDoc really helped it at all.
OpenDoc was not canceled by Jobs in 1995. Jobs hadn’t returned to Apple at that time. The demise of OpenDoc more or less came when Apple laid off virtually the entire team in March 1997.
David McCusker did not write the Bento spec. He certainly was the engineer working on it and he was developing an urgently needed successor to Bento that came too late to make a difference. I believe the Bento spec was written by Jed Harris, but I’m not completely certain.
In the ten years since the end of the project, I’ve been aware of two “reinventions” of OpenDoc, independently, as far as I’m aware. One of these was at Adobe. Both concerned complex documents with component-like objects that operated on some content within the document. Neither came to anything. Maybe someday.
In the days of OpenDoc, I was a support person for Macs at the campus I work at. (I was also did some minor apps for NeXTSTEP on the side).
OpenDoc was an interesting idea, but despite all the fervent evangelism I heard for it, I was never convinced that the design had a real solution for different users having many different components, written by different people, with a variety of version-skew problems. Sure, the user could choose between 10 different versions of “the graph component”, but how would that actually work in the real world? Consider a campus setting, with different people choosing different components, and inevitably running different versions of the components they did have in common, and yet having to share documents across all those computers. To me, OpenDoc seemed like it would be one huge nightmare. Yes, I heard all the propaganda about how great it would be, but the proponents never showed how version-skew problems would magically disappear with “components” compared to “applications”. And OpenDoc promised it would deliver lots and lots of components, so it needed to have a real solution to those version-skew issues.
It also seemed extremely obvious to me that one of the main attractions of OpenDoc (as far as the proponents were concerned) was that it would allow developers to break the stranglehold of Microsoft Office. That’s a great idea — assuming you can get Microsoft to buy into it. But why would Microsoft *ever* build an OpenDoc version of MS-Office? And if MS-Office was never going to use these OpenDoc components, and MS-Office already had a stranglehold on the “office app suite” market, then OpenDoc could never hope to break that stranglehold.
Also, as a programmer, it seemed to me that C++ was a really bad language to be designing something this flexible. C++ is a plausible choice if you’re trying to code for speed, but not if you’re trying to code for mix-and-match components across multiple versions and written by many different developers.
So it seemed to me that the ‘Services’ model of NextSTEP (and now MacOS 10) provided some of the nice “small component” flexibility that OpenDoc wanted to deliver, but did so in a much more manageable manner. Yes, it is much less ambitious, but that’s why it is easier to implement a reliable result.
I saw OpenDoc for the first time on WWDC ’94 and was surprised how fragile it was – one click on the wrong spot and it would crash.
However I think the concept was great and at the time I imagined collections of components replacing the monolithic applications from Microsoft, Quark & Adobe.
Maybe they saw that, too – I still suspect that it was killed for political reasons along the lines of one or two critical application developers hinting that their next version might be Windows-only. (In fact there were innuendos to that effect around that time.)
Also I have not heard any other explanation that holds water. Because it was picking up in terms of popularity and support in the time before it was pulled and I clearly remember quite some very surprised (and angry) reactions, so it was clearly not dormant.
That the project was canned because the consortium did not manage to resolve the technical problems around the file specifications, as a guy from upper management told me recently, I find somewhat hard to believe.
Anyway, with Cocoa underneath it should all be much easier to implement, and in principle by anyone as I seem to remember that the specification was open… :-)
It’s call HTML 5, CSS 3 and JS. Very complex, multimedia documents can be created within an open environment.
I believe OpenDoc would only work if most of the components (all the core ones) were OpenSource so everyone would be able to use them.
The only other way for it to work may be if each component had a viewer that was free, but this would be more complicated.
Something like OpenDoc could happen within the OpenOffice project. Does anyone know enough about ODF to know whether it would support this?
@ Tim Locke:
No, the components don’t necessarily need to be open as long as the (component) file formats are. The idea being that however complex a document may be, it is still made from basic building blocks, like text, images, movies, drawings, sounds, etc.
In an OpenDoc document, you could separately access each of these building blocks with a piece of software of your own choice for viewing or/and editing. That’s precisely the threat it presents to monolithic applications.
I don’t know enough about ODF to answer your question, but there’s a thought…
Hi Greg! Love your style and your talent. Please check out my website, it was created to promote a two-sided poster I produced for the San Luis Obispo Railroad Museum. I am working on several projects that you might be able to help me with. Project One is a visual book about Disneyland rail history in Frontierland. See “Rainbow Ridge” on my website for the prototype book cover.
Separate from my book effort is a Disneyland poster project I am doing just for fun (it’s something to put on my wall). I wanted to have a poster for each of the 12 attractions I worked at Disneyland but there were no posters for the Adventureland and Frontierland shooting galleries. Ditto for the old Fantasyland Theater which ran Disney cartoons. I have started some work on these poster ideas but I am a designer, not an artist. I will be happy to share my design elements if you would like to art direct some new posters. The finished posters would be your property. Or we can talk about another deal. At this point I want to establish some kind of creative relationship with a very talented guy, I am sure your art can help with one or more of my book projects.
Joe Burns
San Luis Obispo, Ca. 805 546-1011
How would you compare Google’s recently announced Wave with OpenDoc?
There is one thing, that is even more “OpenDoc-ish” than Wave..Google’s mobile OS, Android. Application can publish “intents” that get intercepted by third party software which actually executes them. It is great feature that gives Android a lot of flexibility and I think it position it well in the “battle” against iPhone.
We are trying to make an OpenDoc open source remake here:
http://sourceforge.net/p/docshell/discussion/
Bento really needs a lot of work.
If anybody want to contribute, with code or ideas, please post on the forum.
Regards
Seems like we’re at a time where something like OpenDoc could make a comeback.
reasons:
– software has gotten a lot cheaper
– software now seems to be focussed on atomic bits of functionality vs whole “suites”
– on iOS at least we have a universal object model build on Obj-C, so it’s a lot less painful to share code/parts/views/whathaveyou