Why OpenDoc failed, and then failed 3 more times?
A recurring questions that surfaces around the Future of Coding Community is what happened to OpenDoc? why did it fail?
This post is a summary of reasons found around the web, then I will explore other implementations similar to OpenDoc to see if there is a general pattern.
Bias warning: I pick the quotes and the emphasis, read the sources in full to form your own conclusion and let me know!
OpenDoc
To start, here's a brief description of what OpenDoc was:
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.
Let's find out the reasons:
OpenDoc post by Greg Maletic
A consortium, lots of money and the main driver being competing against Microsoft:
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 hardware wasn't there:
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.
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.
...
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.
No "Business Model":
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.
A solution looking for a problem:
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.
"Why didn't it catch on? 7 theories I've come across" by Geoffrey Litt
UX quality. If every component is developed by an independent company, who is responsible for unifying it into a nice holistic experience rather than a mishmash?
Modality. Different parts of your document operate with different behaviors.
Performance. Huge memory overhead from the complexity
Exporting. Hard to export a "whole document" into a different format if it's made of a bunch of different parts.
Lack of broad utility. How common are "compound documents" really? Beyond the classic example of "word doc with images and videos embedded"
Data format compatibility. If two components both edit spreadsheets but use different data formats, what do you do?
Historical accident. Turf wars between Microsoft and everyone else, Steve Jobs ruthlessly prioritizing at Apple, execution failures, etc.
chris rabl's take inspired by Macinography 10: OpenDoc and Apple's Development Doldrums
There wasn't a centrally distribution channel for "parts"
Despite OpenDoc discouraging vendor lock-in for file formats, many vendors still insisted on locking down the file formats they used or making them incompatible with other vendors' products
Lack of buy-in from the developer community: cumbersome C-based API and obtuse SDKs dissuaded developers from buying into the hype, plus it would have required them to re-think how their application worked in the first place (what would Photoshop look like as an OpenDoc app?)
Very little dogfooding: even some of the big partners like IBM and Novell did a really bad job implementing OpenDoc in their product suites
Scott Holdaway Interview
Hard to adapt existing software:
OpenDoc made all these assumptions about how things were coded, which were kind of reasonable for an object-oriented program, which ClarisWorks was not. We told management that it just wasn't going to work trying to put OpenDoc support into ClarisWorks, especially not without doing a lot of rewriting first. And they said, well, too bad, do it anyway.
Bad Execution:
It was a good idea, it was certainly poorly done, but it still could have worked in a different codebase. They had like up to 100 people-engineers, testing, and support and all that-working on OpenDoc. That's too many people. Anytime you have that many people starting something like that, it's usually poorly done. They had too many compromises in their design, or just lack of foresight. Integrating it into ClarisWorks was certainly a huge problem. It was not made to be integrated into existing programs like, say, OLE was.
Oral History of Larry Tesler Part 3 of 3 (Transcript)
Big project, solution looking for a problem:
But they also had ActiveX. And that’s the thing, even a little more so than OLE, that OpenDoc was aiming it for. And it was a bad idea from the beginning. And I kind of sensed something was wrong but it wasn’t until we started playing it out and realizing how big a project it was and how little we had thought about the benefits and what you would actually do with it. And people tried to address it in various ways.
Doing it for the wrong reasons:
But we were doing it because Microsoft was doing it and we needed to have something better.
If we believe that it was all Steve Job's fault for stopping its development early, because the hardware wasn't there or because of bad execution then if someone tried something similar again then it should succeed right?
I went looking for other attempts at the same idea of "[Document] Component based software", here are the main contenders and some reasons why they are not the way we do things right now.
They are not 100% document based, but since they are more focused/pragmatic at least they should have succeeded being used as a better way to reuse components across applications.
ActiveX
ActiveX lived longer and was used in multiple places, so why was it deprecated?
Complexity:
Even after simplification, users still required controls to implement about six core interfaces. In response to this complexity, Microsoft produced wizards, ATL base classes, macros and C++ language extensions to make it simpler to write controls.
Unified model, platform fragmentation:
Such controls, in practice, ran only on Windows, and separate controls were required for each supported platform
Security and lack of portability:
Critics of ActiveX were quick to point out security issues and lack of portability
...
The ActiveX security model relied almost entirely on identifying trusted component developers using a code signing technology
...
Identified code would then run inside the web browser with full permissions, meaning that any bug in the code was a potential security issue; this contrasts with the sandboxing already used in Java at the time.
A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…
HTML 5 replaces most use cases:
The need for ActiveX controls has been significantly reduced by HTML5-era capabilities, which also produces interoperable code across browsers.
The Open Source Alternatives: KParts & Bonobo
If the problem was the business model but the technology was really powerful then it should not be a problem for up-and-coming open source desktop environments with a user base consisting mostly on power users and developers that would benefit from code reuse.
The major desktop environments, Gnome and KDE, had/have something similar to OpenDoc.
An interesting fact is that Gnome used to be an acronym: GNU Network Object Model Environment, the Object Model idea was in the name itself.
I didn't notice until now that the name KParts seems to come from OpenDoc's Parts concept.
Usenix: KDE Application Integration Technologies:
A KPart is a dynamically loadable module which provides an embeddable document or control view including associated menu and toolbar actions. A broker returns KPart objects for certain data or service types to the requesting application. KParts are for example used for embedding an image viewer into the web browser or for embedding a spread sheet object into the word processor.
Example uses of KParts:
Konqueror uses the Okular part to display documents
Konqueror uses the Dragon Player part to play multimedia
Kontact embeds kdepim applications
Kate and other editors use the katepart editor component
Several applications use the Konsole KPart to embed a terminal
How will CORBA be used in GNOME, or, what is Bonobo?
Bonobo is a set of interfaces for providing application embedding and in-place activation which are being defined. The Bonobo interfaces and interactions are modeled after the OLE2 and OpenDoc interfaces.
...
Reusable controls: Another set of Bonobo interfaces deal with reusable controls. This is similar to Sun's JavaBeans and Microsoft Active-X.
Available components are:
Gnumeric spreadsheet
ggv PostScript viewer
Xpdf PDF viewer
gill SVG viewer
History of Gnome: Episode 1.3: Land of the bonobos:
Nautilus used Bonobo to componentise functionality outside the file management view, like the web rendering, or the audio playback and music album view.
...
This was the heyday of the component era of GNOME, and while its promises of shiny new functionality were attractive to both platform and application developers, the end result was by and large one of untapped potential. Componentisation requires a large initial effort in designing the architecture of an application, and it’s really hard to introduce after the fact without laying waste to working code.
...
As an initial roadblock it poorly fits with the “scratch your own itch” approach of free and open source software. Additionally it requires not just a higher level of discipline in the component design and engineering, it also depends on comprehensive and extensive documentation, something that has always been the Achille’s Heel of many an open source project.
History of Gnome: Episode 1.5: End of the road
Sun’s usability engineer Calum Benson presented the results of the first round of user testing on GNOME 1.4, and while the results were encouraging in some areas, they laid bare the limits of the current design approach of a mish-mash of components. If GNOME wanted to be usable by professionals, not curating the offering of the desktop was not a sustainable option any more.
...
The consistency, or lack thereof, of the environment was one of the issues that the testing immediately identified: identical functionality was labelled differently depending on the component; settings like the fonts to be used by the desktop were split across various places; duplication of functionality, mostly for the sake of duplication, was rampant. Case in point: the GNOME panel shipped with not one, not two, but five different clock applets—including, of course, the binary clock
...
Additionally, all those clocks, like all the panel applets, could be added and removed by sheer accident, clicking around on the desktop. The panel itself could simply go away, and there was no way to revert to a working state without nuking the settings for the user.
KParts seems to still be around, you can see a list of actively developed KParts on KDE's GitHub account, Bonobo was replaced by DBus which is a Message-oriented abstraction not related to OpenDoc concepts as far as I know.
What about Web Components?
From MDN: Web Components:
Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps.
Web Components have been around for a while and developers seem to be split in two camps regarding how useful it is.
We will see with time if it becomes the main way to do web applications and a new attempt at OpenDoc, this time on the web.
Conclusion
Still not sure which were the main reasons, but many of them aren't shared by later attempts:
More RAM was available during the ActiveX days and is available today for KParts
-
KParts and Bonobo don't require a business model and benefit from reuse
Unlike OpenDoc/ActiveX there's no competition between Apple/Microsoft and developers
Execution on ActiveX/KParts didn't seem to be a problem
Lived long enough and learned from OpenDoc failure
Weren't developed by a consortium
Were well integrated into the underlying environment
Had use cases from day one
No vendor lock-in
Some had good distribution channels (Package Managers)
At least KParts and WebComponents seem to have a good developer experience
The conclusion is that there's no conclusion, the case is still open, what do you think?