Ben Thompson has a member-only post on Stratechery that is worth a read if you’re one of his subscribers. Steve Jobs and OpenDoc, Fluid Framework, Microsoft Lists.
An article on The Verge and quotes from Microsoft’s Jared Spataro about Fluid reminded Thompson of OpenDoc and he begins his own thoughts on Fluid with a bit of history on Steve Jobs decision to kill OpenDoc in 1997. Thompson suggests the reason was that a combination of Microsoft’s dominant marketshare, and
that the application model was simply a much better approach for the personal computer era. Given the lack of computing power and lack of connectivity, it made much more sense to have compatible documents made by common applications than to try and create common documents with compatible components — at least with the level of complexity implicit in OpenDoc.
Thanks to Thompson for giving me an excuse to indulge in a little history of my own, which largely supports his view. Below is what I shared with him. The history is fun, but the new Fluid Framework is also worth a closer look.
———————-
Fluid also reminded me of the competing OpenDoc and OLE approaches in the early 90s. To supplement your history…
At the first Documation conference in February 2004 1994 I moderated a session that included Apple Chief Scientist Larry Tesler, and Tony Williams, Microsoft Software Architect and Co-creator of COM. I had asked each of them to discuss requirements for and their approaches to building a “compound document architecture”. OpenDoc was naturally appealing to me (and many of my subscribers) at the time, but Tony made a strong case for OLE. Tony’s argument for OLE was technical but he also addressed the issue from a business point of view, and argued that OpenDoc was too much of a radical change for both developers and end users. While this was more of an issue for Microsoft with their large developer community and installed base, OpenDoc was radical, and I expect that was the reason OpenDoc languished at Apple and for Jobs’ ultimate rejection.
Below is an excerpt from my report about the session. The complete report and conference program and be found at the link above.
Technology Trends — Document Computing
On Wednesday the general session was divided into two sections. One covered new technologies being developed to enhance document computing and document management. The other presented senior managers from large corporations who described their own document management needs.
Your editor opened the technology session by describing three components of current document management systems, each of which presage future developments. Objects — whether in terms of object-oriented databases, object-oriented programming, or multimedia document component “information objects” — play a big role in making systems more flexible and capable of dealing with complexity. Building an architecture to manage and share distributed objects, and to link and assemble them into document form are requirements of many enterprise-wide document management solutions. Finally, the document metaphor is increasingly seen as the most effective and friendly way to interface not only with document management systems, but with information in general.
Today, these capabilities are built either at the application level, or as “middleware”. For many reasons (e.g., application interoperability, performance, and ease of application development), it would help instead to have support for these capabilities at the operating environment level.
Previous attempts at compound document architectures to provide such an environment have failed. But this is clearly something we need, and eventually will get. Whoever defines and builds such an architecture will be in a powerful position to dominate the IT market. We can expect fierce battles among the platform and architecture vendors to control this architecture . The two leading candidates today are Microsoft’s OLE, and the Component Integration Lab consortium’s OpenDoc (based on Apple technology).
Larry Tessler from Apple described the “Information Tidal Wave” (his alternative to “superhighway”) coming with the growth of electronic multimedia documents, and with the rapid building of electronic document repositories. IS managers will face severe new problems arising from the need to manage these repositories. Larry positioned OpenDoc as a core technology for supporting the management and assembly of these new kinds of documents.
Microsoft’s Tony Williams focused on user requirements for a compound document architecture. Compound documents should be thought of as “compound views” of information, and documents are just one form of information, and thus need to be handled as part of an information architecture. Information architectures in turn need to be able to manage many different types of multimedia data for both document and data applications.
A standard “containment model” is needed, Williams said, to allow applications to share and organize information objects. Previous attempts at standard compound document architectures, e.g., ODA (Office, or Open Document Architecture) failed because they attempted to define a too restrictive representation. Such systems also need to handle ad hoc information (for example, that created with a personal information manager) as well as structured documents.
Tony emphasized the need to protect both user investments in information and developer investments in applications. While a compound document architecture environment is a requirement of any new operating environment, there must be an evolutionary path provided — a compound document architecture that forces a radical change too quickly will not gain acceptance. Tony positioned OLE as the technology that meets these requirements.
When asked, both Tony and Larry Tessler claimed that OpenDoc and OLE should work together and described generally — each in terms of the architecture they were promoting — how that could happen. However, this is definitely an area where there needs to be continued and aggressive vigilance on the part of corporate users to ensure that operating environment interoperability results. It would certainly not be wise — at least not yet — to assume that one of these approaches will become dominant.
