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.)
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.
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).
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.
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.
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.
Are both of these still not the case?
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:
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
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.
There are a lot more people working at AWS dependent on MS office than MS people depending on an Amazon service…..
As for office software, G Suite took over the top spot from MS Office a few years ago.
Userspace is a mix of Java, Kotlin, ISO C and ISO C++ standard libraries, and Android specific native APIs.
Nothing from Linux side is considered public API other than for OEMs providing their own device customisations, not app developers consumption.
G Suite still has too much to learn from Office capabilities.
https://www.ciodive.com/news/g-suite-passes-2b-monthly-activ...
> 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.
On the other hand, I hardly ever use the online version of GSuite, I use the iOS versions that can all work offline.
A little of column A, a little of column B - in the end it didn't survive.
But don't take my word for it - from the man himself: https://www.youtube.com/watch?v=FF-tKLISfPE
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?
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.