I think the big reason OpenDoc failed is because it was completely steamrolled by Microsoft OLE 2.
These are complicated enough APIs that a developer is typically going to only implement one.
To better understand, it helps to go back in time when this was going on.
This was the early 90's, and Microsoft Windows was the dominant OS. In addition, Microsoft Office was also becoming the dominant office software.
Microsoft put a lot of it's energy behind OLE 2. Office supported it. If you wanted your application to be certified for Windows 95, you needed to support OLE 2. OLE 2 was pushed at all the Microsoft Developer conferences. Every book and magazine about Windows development pushed OLE 2. Microsoft's Visual C++ MFC framework supported OLE 2, and in fact, their Scribble tutorial included a section on implementing OLE 2. Visual Basic supported OLE 2, and in fact their custom controls were OLE 2 objects.
Thus if you supported OLE 2, you had a ton of documentation, tooling, libraries, dev environments that supported it. You could get Windows 95 application certification. You would be able to embed Office documents in your application, or have Office embed your documents in Office. IIRC, Visio started out as an independent application that had great OLE 2 support and was eventually acquired by Microsoft. And you could tell that OLE 2 was a huge priority for Microsoft. In fact, the rumored next generation successor to Windows 95 and Windows NT, Cairo was supposed to be built on OLE 2 from the ground up. (Cairo never materialized).
On the other hand you had OpenDoc, which did not have nearly as big of a market. It was not the priority for any of the companies pushing it. Unlike with Microsoft Office and OLE 2, there wasn't a halo product that showed off the user benefits of OpenDoc. There wasn't nearly the documentation and tooling and libraries for OpenDoc.
Given all that, I don't consider it surprising that OpenDoc failed.
> I think the big reason OpenDoc failed is because it was completely steamrolled by Microsoft OLE 2.
I think the bigger reason may be this, from the original article:
> 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.
The trouble with composite documents is that it goes against the market's tendency to accrete power to the incumbent.
* If you're WRITING document software, the composite document model adds a bunch of development complexity for (mainly) the purpose of opening doors for your competitors to eat away at your lock in. From a marketing perspective, If I'm writing document software I'd probably much rather you use _my_ spreadsheet than whatever spreadsheet you want. From a support perspective, it's easier if I own the code on both sides of an embedding. From a development perspective, it's easier to add more differentiated features if I don't have to force everything through a common document embedding model, etc.
* If you're USING document prep software, the composite document model adds complexity to the way you install and buy software, the UX for the software, and then what you can do with the documents you create with your carefully curated software suite.
There are ways that all of this can be addressed from a technical perspective, but the end reality is that the costs are too high and the return too limited to be useful.
(As you point out, OLE2 has seen a lot of market acceptance, but a lot of that comes in the context of MS Office. Despite the availability of embedding technology within OLE2, The market didn't gravitate to hand-curated sets of best-of-breed office software. The market gravitated to MS Office with specific add ons for specific use cases. Even then, in settings where not everybody had those add on packages, there was a tendency to push documents to fit into whatever stock MS Office would support.)
> The market didn't gravitate to hand-curated sets of best-of-breed office software
By this time, in terms of software for Windows, the programs that came with Microsoft Office were best of breed (or else pretty close).
From In Search of Stupidity by Merril Chapman:
>The only problem with this theory was that the competition didn't have the best-of-breed products; Microsoft did. Though Quattro was always well rated by the press and usually beat Lotus 1-2-3 in head-to-head competitions, it almost invariably was an also-ran to the top-ranked product, Microsoft Excel. WordPerfect's botched release of its first Windows-based word processor had landed the one-time ruler of the category in third place. First and second places were usually fought over by Microsoft Word and Lotus's AmiPro. Microsoft PowerPoint and Lotus Freelance usually struggled for the business presentation graphics crown, but the spreadsheet and word-processing elements were the most important factors in a buyer's decision. Advantage: Microsoft.
>Both Borland and WordPerfect attempted to fight back with competing office suites assembled from each other's respective products (with SPC's faded Harvard Graphics thrown into the mix), but they were unsuccessful. Not surprisingly, the new suites lacked the integration of Microsoft Office, but more important, they were bundles of second- and third-class programs competing against top-ranked contenders. Lotus SmartSuite faced a similar problem. Lotus 1-2-3 for Windows never placed higher than second in competitive face-offs and usually came in third place (a shocking comedown for the one-time category leader). AmiPro sometimes outplaced Microsoft Word, but Lotus was, after all, the spreadsheet company. Freelance usually placed second to PowerPoint in reviews, and the suite's database, Approach, although a decent product, wasn't well known and brought little extra credibility to the package.
At the time it happened, I'd have been sympathetic to that phrasing. In the couple decades then, I'm grown much more sanguine about it.
The notion that users are being somehow kept hostage by not being able to pick and choose their own suite of document components is almost completely contrary to the history of consolidation within this industry and others. Picking a collection of best of breed software components is asking way, way, way too much of the vast majority of users, who mainly had a specific set of goals, one of the most important of which is to get on with the rest of life. About the best that can be achieved with this sort of software architecture is add on components that fill specific gaps in existing suites (and then likely get rolled into the suites themselves).
sorry, how that change our sympathy to the phrasing exactly?
The whole point of having users captive, is that you can offer the crappiest option and charge for it. And by charging for it you restrict who (and how) have access to it.
The tl;dr is that this architecture imposed costs on essentially everybody involved in software and offered benefits that were abstract at best. I didn't always see the costs, and I placed too much value on what I perceived to be the benefits.
I think the big reason OpenDoc failed is because it was completely steamrolled by Microsoft OLE 2
For that to be true, OpenDoc had to first be deployed and successful somewhere so OLE 2 could be said to have competed with it and to have won. Microsoft's office apps crushed Apple's office apps in the marketplace, etc. OLE 2 never really competed with OpenDoc, though, because no working (in any practical sense) OpenDoc anything ever shipped with MacOS. All the OLE 2 context seems pretty orthogonal, OpenDoc didn't even 'win' within the Apple platform.
> because no working (in any practical sense) OpenDoc anything ever shipped with MacOS
Well, beyond that -- almost no OpenDoc software shipped at all. The first significant release was Apple's CyberDog web browser in 1996, and the OpenDoc project was cancelled in 1997.
Mac OS never really embraced OpenDoc wholeheartedly, either. It wasn't included in the default install of Mac OS, so most users were never exposed to it.
In terms of dominant OS, I think Microsoft is no longer the dominant OS, even though it is the most used OS for laptops and desktops.
Back in the 1990's, Windows was the center of the developer universe. Think how mobile developers eagerly wait to see what Apple will do. It was even more so for developers in the 1990's. There were huge Windows dev conferences. There was a ton of excitement for a new release of Windows or a new version of Visual C++/Visual Basic/Visual Studio.
Now, although there are a lot of computers that run Windows, Windows is not the center of gravity for developers. A new iOS release or a new AWS service has far more impact on developers than any new Microsoft Windows feature.
Joel has a great writeup on this from some time back:
I work at AWS and even I admit that a new AWS feature doesn’t have as big of an impact as a Windows feature or an Office feature.
Andy Jassy, the CEO of AWS (and soon Amazon), has said repeatedly in public statements that only 4% of all enterprise IT spend is on any cloud provider.
Office is far more ubiquitous in the enterprise than AWS. Not to mention all of the home users who have Office 365 running on their computers and mobile devices.
I don't think that's what he's saying. Of course, Joe Small Business Owner is going to care more about new features in Outlook or Excel than about new features in AWS. But I don't think _developers, specifically_ are looking out for the new office extension APIs in the same way they're looking for e.g. improvements to EKS.
If only 4% of all enterprise spend is on any cloud provider and AWS has I believe 36% of the market, and on top of that AWS has 260 services (at least that’s the number of distinct IAM resource types), I would think there was a larger third party market for Office extensions and dark matter developers doing Office/Sharepoint automation than who cared about a new AWS feature.
There are a lot more people working at AWS dependent on MS office than MS people depending on an Amazon service…..
Arguably, the dominant OS nowadays is whatever your phone runs, plus whatever serves the websites you consume. Microsoft Office reigns unchallenged though.
> Microsoft owns nearly 90% of the office suite market, or email and authoring market, as Gartner calls it. Google holds onto just over 10%, but is gaining about 1% market share annually.
It didn't help that Apple was broke and Steve was more focused on keeping Apple alive than funding pie in the sky initiatives that may or may not work out - as Apple continued to bleed money.
A little of column A, a little of column B - in the end it didn't survive.
I was pretty young at the time, but I can't really remember much of a use for OLE outside of Visual Basic? (Which granted, was Big). Maybe databases also?
People used it so you could stick an Excel spreadsheet inside a Word document.
People also used it to attach attach Word/Excel/Powerpoint documents to emails as OLE objects, which would be stored in TNEF format. This worked fine within a local network when everyone was running Outlook and Exchange, but caused problems when people started sending emails out over the Internet (remember winmail.dat files?). More recent versions of Outlook+Exchange prefer to just use MIME.
But did OLE 2 succeed? I know this is the technology which allows you to embed a Word document in an Excel sheet in a PowerPoint presentation, but does this actually work across applications by independent vendors? And is it ever used?
Customer is actually doing as much work as experience in that beautifully apt & precise phrase.
For developers, the idea of being able to build and sell a little specialized widget of functionality—the best spellchecker ever made—had obvious appeal. It might even provide a truly outstanding experience for users. But where would you find a customer excited about assembling their own word processor out of a dozen independently purchased components?
One of the best pieces of advice I have been given is “design for people who aren’t you”. Turns out, the vast majority of people want something that “just works” and involves no configuration or in-depth understanding. That’s not a bad thing, either.
I mean spellcheck might actually make a lot of sense (if the hooks were appropriate). The interface is mostly set, but the word list and how you figure out if words in the document are correct have a lot of potential variation. Selling the product seems like a lot of work though. Maybe if you could add spell check in a language not included in the box, that would have at least a chance regionally.
But things that are maybe even more potentially useful like math formula editors get really hairy if you want to share documents. Then people viewing the customer's documents might need a special viewer or a licensed copy of the editor if they want to adjust things. It's a big mess.
Yeah given user's goal with a doc is to ... communicate or otherwise do a thing. Working WITH the doc, picking components, or picking among a bunch of document editors, thinking about document technology is not their goal.
in all fariness, B2B is a perfectly viable business model. If you don't or can't care about the UX, sell the hard work making the tech to some company that has those UX engineers to make that spell checker "just work". other companies are very happy to pay devs to put those components together (and serving a dev struggling with an API is likely easier than a user struggling with the UX).
Yeah I've 'fixed' things now and then and sat back and clicked some buttons and watched it work only to realize that really ... I was clicking the same buttons getting the same thing just like it was before and getting roughly the same output / experience.
I wasn't wrong, some stuff needed to get fixed and it was better, but the customer's experience really didn't get much better... not a lot changed.
I was thinking tech first and working towards the customer experience ... didn't have much to show for the effort when I put it all together.
I've also been really excited about a solution only to realize that my excitement was with the underlying technology rather than the customer experience.
I remember this feeling with early web apps. I was excited about being able to update one system rather than several desktops. For the customer, however, the overall UX was actually a slight step down because of the limitations of HTML and javascript.
There isn't anything specific to OpenDoc in there. The real question is "why did you kill this technology that I loved" and the answer could apply to any such case.
I had a real soft spot for OpenDoc, remembering seeing the demos at AppleExpo in the late 90's.
Yes you have to start with what people need and go from there. However, you can also start from what a niche of people need and go from there.
Honestly I think OpenDoc was way too ahead of its time to be groked by mainstream users. Currently we have various workbook online apps (like Observable) that are similar in spirit and super useful to those who know how to leverage them, but haven't yet crossed into the mainstream.
I can understand this. I've been enamored with good engineering many a time, and it has its place. Something that's well engineered often WANTS to be a good solution. But I also agree with the concept of starting with "where can I take the customer" rather "how can I present this awesome new technology".
Another variation on this concept was an article by Joel Spolsky in which he coined the term "Architecture Astronauts". He describes well the manner in which an architecture astronaut looks at something like Napster and generalizes to peer-to-peer messaging while missing the excitement of "search for song. find song.".
You see it time and again where a X clone shows up and you use it and realize ... the clone has no soul and none of the convince or emotion that what it tries to copy has. It copies the notes but can't put a song together.
I went to a big computer trade show at Jacob Javitz center in the 90s and got this same shirt.
On a side note, my memory of OpenDoc isn't as rosy as others. It was very slow and memory hog, when memory cost was astronomical. Use cases was too niche for ordinary users.
I've seen this video a few times now, and what's amazing about it is that Jobs freely admits he doesn't even really know what OpenDoc was really all about as he goes on this presentation. It's nicely presented, but frankly I think it was off target. I would be pissed if I was the questioner who initiated it (though the questioner was very rude)
As I see it, OpenDoc's entire purpose was to benefit the user, as it put the focus on the user's intent and document rather than on the applications used to assemble it. The person who would have struggled to see the benefit was the application publishing houses, not the user. So I think this is all a bit disingenuous. There was a clear user benefit to something like OpenDoc, and frankly I think the era where Jobs returns to Apple is in fact the turning point where Apple went from an end-user focused company ("the computer for the rest of us") to a lifestyle/luxury-branding company.
That obviously has given them far better financial success, but has it benefited the world like Jobs liked to pontificate?
Frankly, what it comes down to is this: OpenDoc had no home at Apple, because the return of Jobs was not just a management transplant from NeXT to Apple, but a tech one as well, and Jobs & Tevanian etc. wanted to replace/supplant MacOS with what they had developed at NeXT. Like the Newton and other tech, OpenDoc was something innovated at Apple during the years while he was exiled. So it had to go and be replaced with whatever the NeXTstep/OpenStep world would want instead.
There's an excellent comment on that YouTube video, which I thought was insightful:
"Watch Ramblings
9 months ago (edited)
This was actually a fairly disastrous response from Steve Jobs that really hurt the company. This was 1997, more than a decade before the iPhone, and the Apple Macintosh (the company's sole product) was in bad shape. The questioner here was referring to the fact that Apple had just pulled the plug on support for OpenDoc, a cross-platform software framework for creating complex documents. Many developers (such as the questioner) had devoted years to the OpenDoc technology and made a livelihood developing applications for it since 1992, and thought Jobs abruptly dropped the technology without good reason. The questioner was asking, dude, why did you pull it? Jobs' response was basically, tough shit, no answer. Developers learned that technologies that were sacred to Apple one year could be dropped the next without cause or warning, so many devs concluded the investment wasn't worth it and abandoned the Macintosh platform in droves. The market share for the Macintosh would drop by more than 50% over the next two years as the (few) remaining developers who were loyal to the Macintosh platform fled to the greener pastures of Windows. People look at this response with rose colored glasses because of what Apple would become many, many years later, but this was actually a very poor way to respond to a legit question (although posed angrily) from the type of developers that Apple really needed to keep happy."
I think Steve jobs was mainly looking at the cost vs potential profits of Opendoc. There was a lot of ongoing engineering money going into development, and the potential revenue streams seemed too niche for the amount of effort. From his perspective it was better to move the talent to more strategic projects that matched his 5-10 year vision. He wanted to pivot to chasing end users, not to expanding the existing developer base. In the long run it worked, with a lot of short term pain.
> As I see it, OpenDoc's entire purpose was to benefit the user, as it put the focus on the user's intent and document rather than on the applications used to assemble it.
That was the purpose, and I wish we had a real instance of that vision today but OpenDoc was never going to deliver.
> This was actually a fairly disastrous response from Steve Jobs that really hurt the company.
Not really. It was much better than lying, and appearing to support OpenDoc only to drop it later would have been far worse for the developers who would have invested been more into it and Apple.
As someone who worked on the predecessor to OpenDoc (Apple Document Framework) I think a key issue was that the HyperMedia underpinnings that motivated our work took
too long to happen and
depended on structured media less than we anticipated.
A world in a which a sea of interlinked richly structured documents existed would have likely been a world where the advantages of OpenDoc-like architectures would have mattered. As it was the WWW (when it happened some years after ADF and AppleScript were conceived) turned out to do just fine with loosely structured text and bitmap images.
Within the business app world (as other folks have noted) the incumbent players pretty much stuck with their monolithic architectures (to this day embedding structured media within web pages isn't well supported - how would you stick an Excel or Numbers spreadsheet in a page today?).
A more alarming trend has been the growing disinterest among the major players toward advancing the cause of end user authoring of structured media (e.g. anything besides video and throwaway picture taking). Perhaps the success of the computer as consumption enabler makes progress in this area uninteresting from a commercial perspective.
While I do industrial stuff now, I miss the days when authoring tools were seen as arenas for innovation - heaven knows there's a lot of room to make the likes of Word, OneNote, Visio etc more powerful and usable.
> 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.
Maybe I'm misreading this but this feels like a focus on the neat technology rather than what the user gets out of the technology. Sure, OpenDoc was cool component-based stuff, but if someone's 2MB Mac runs Word or MacWrite or whatever just fine, they aren't going to upgrade their hardware to run your OpenDoc-based word processor. Oh, but I could embed a QuickTime component in my text document? What does that even mean? When I print my document, I get to see a blurry postage-stamp sized video thumbnail in my document? Hoo boy!
Arguably the Web does everything OpenDoc was designed to do. And better. The idea wasn't necessarily horrible (rich documents filled with disparate components.), but the technology was a bad idea (C++ish sort of OOP stuff... dynamic languages like javascript are just way more natural for this sort of thing).
OpenDoc was never going to get widespread adoption, there's little attraction for developers.
MacOS Services offers a more lightweight means of adding capabilities across applications.
The LinkBack project http://linkbackproject.org is/was a better way for developers to integrate content from other applications into their own. A user can paste content from any LinkBack-enabled application into another and reopen that content later for editing with just a double-click. Changes will automatically appear in the original document again when you save.
I think a lot of applications that once supported it no longer do, as Apple's security enhancements have required some big changes in the implementation.
It doesn't help that the exact purpose of OpenDoc can't be explained. There's no clear killer app or purpose of it. It's a a platform for combining things on documents. For god knows what reason.
You might say "it's not for documents you fool". That's what THEY called it. It's in the name. So add that to the list of reasons.
Would really like to know what's your theory on why component based software failed in those cases and if Web Components learned/solved those problems.
It seems like a solution in search of a problem? How often do you need to embed a spreadsheet in word-processing document?
Furthermore, making components from multiple independent vendors interact seamlessly is just an incredibly complex problem. The web is probably the most successful decentralized system, and this is because the common integration point which all must support is very very simple: URL's and links.
Web components is more equivalent to GUI toolkits than office plugins. For web components to be a solution they'd need quite a lot of augmenting, like, a standard way to serialize and deserialize document-like content out of them. I don't think there is such a thing right now, having re-checked the MDN documentation on them, but if I'm wrong I'm sure the Internet will let me know.
You probably could augment your way up to something that would work more like OpenDoc without too much hassle in principle, but it'd be a lot of work in practice.
Is it fair to compare OpenDoc with something like Notion? It has the same concept of being able to construct documents from many smaller relatively independent parts, except of course that the parts are all created by the same company.
However, since LISA OS came with an integrated tools package (as in "7/7") turning the tools into components (to be used by universal documents) would have posed less a problem. I think, it's really the third party aspect that doesn't match the model.
Yep. The only way this could work in a real-world sense would be for it to be the OS, and for the OS to be purpose-built to function this way from the start. Completely extensible, completely communicative between modules (and good luck with that), completely a security nightmare.
Essentially every attempt to provide a viable mainstream alternative to Word for Windows failed (to a first approximation) until online office suites became viable. [ADDED: I understand this wasn't intended to be directly a Word competitor but it was part of a general industry interest in Microsoft competition.]
You can critique individual efforts but there wasn't really a big appetite for Word competitors and there was a lot of inertia among mainstream office workers.
I agree with your general point but I'd also argue that, for a lot of people (including myself), the reduced feature set was mostly a feature, not a bug. I use presentation and word processor apps a lot, but I'm not really a "power user" these days.
I can't say I've ever missed any Word features in Google Docs, and would pretty much agree there. There have been a few cases I wished Google Sheets did more and found Excel did support what I was looking for, though back when I used Excel (mostly in college) I used it less heavily then I use Google Sheets today.
These are complicated enough APIs that a developer is typically going to only implement one.
To better understand, it helps to go back in time when this was going on.
This was the early 90's, and Microsoft Windows was the dominant OS. In addition, Microsoft Office was also becoming the dominant office software.
Microsoft put a lot of it's energy behind OLE 2. Office supported it. If you wanted your application to be certified for Windows 95, you needed to support OLE 2. OLE 2 was pushed at all the Microsoft Developer conferences. Every book and magazine about Windows development pushed OLE 2. Microsoft's Visual C++ MFC framework supported OLE 2, and in fact, their Scribble tutorial included a section on implementing OLE 2. Visual Basic supported OLE 2, and in fact their custom controls were OLE 2 objects.
Thus if you supported OLE 2, you had a ton of documentation, tooling, libraries, dev environments that supported it. You could get Windows 95 application certification. You would be able to embed Office documents in your application, or have Office embed your documents in Office. IIRC, Visio started out as an independent application that had great OLE 2 support and was eventually acquired by Microsoft. And you could tell that OLE 2 was a huge priority for Microsoft. In fact, the rumored next generation successor to Windows 95 and Windows NT, Cairo was supposed to be built on OLE 2 from the ground up. (Cairo never materialized).
On the other hand you had OpenDoc, which did not have nearly as big of a market. It was not the priority for any of the companies pushing it. Unlike with Microsoft Office and OLE 2, there wasn't a halo product that showed off the user benefits of OpenDoc. There wasn't nearly the documentation and tooling and libraries for OpenDoc.
Given all that, I don't consider it surprising that OpenDoc failed.