Comment by mike_hearn
1 month ago
FWIW the Look Up feature, whilst built in to macOS, can also be implemented using "services" which are a way to plug in to other apps and system features like text rendering and highlighting. I can also select text in your message, right click, services -> "Add to music as spoken track". That's a plugin offered by an app. It's only one extra click.
My perspective on why OpenDoc/OLE failed are different to yours. The model in which apps host targeted plugins which don't affect data formats proved very successful, the model in which an app is nothing but plugins wasn't. And if you want to talk about marketing and culture, well, OpenDoc and OLE both benefited from corporate marketing. Using OLE was part of Microsoft's "Designed for Windows 95" programme, which came with a badge and marketing dollars attached. This concept was heavily pushed at the time. OLE had more success than OpenDoc but only temporarily and only because it was a less pure implementation of the concept, closer to fancy plugins than truly decomposing apps into components.
I think the reason they didn't take off was a mix of technological problems and user demand problems. It wasn't people/policy related. Quite the opposite: both technologies lived on long after the real problems had become apparent.
Programming for both OpenDoc and OLE was extraordinarily complicated. The developer experience was atrocious. Making your app OLE embeddable required mastering not only COM and Win32 programming but dozens of other poorly documented and flaky APIs, like for compound documents. Code generation was rampant, everything was memory unsafe. I never did OpenDoc apps but I heard it was a very similar experience.
Then there was the user experience: if you embedded an object from an app and sent the resulting document to someone else who didn't have the app, or had an old version of the app, then the document would just have a hole in it. Useless. OLE tried to do a kind of weird mind-meld between totally different app GUIs, meaning that depending on where you clicked in a document the hosting app could look totally different. There were dozens of problems like this.
In the end it was all rendered irrelevant by the web. On the web, if you share a document with someone it always appeared for them correctly (or if it doesn't, it's a minor and quickly fixable bug). Reliable sharing mattered more than anything else and so all the non-web platforms started dying out.
> implemented using "services"
Yes that's a pattern offered and used on all modern OSes to various degrees, but most - particularly independent - developers prefer to bundle the capabilities they're offering in such a way that they're only available via their app's interface. I think partly because it's just easier to implement that way, but also because it's in their interest (not the users') to not allow the capabilities they've implemented to be accessed by apps created by others.
> perspective on why OpenDoc/OLE failed
It's not my perspective at all; that's what's in the Wikipedia articles, which I linked. OLE had more success because Microsoft was far more invested in it, since it was theirs, and is still used today in Windows (sounds like you're saying it's dead); OpenDoc was an attempt at an open standard, and failed because the participants just weren't invested and/or agreeable enough. Of course I can see Jobs driving the final nail because, for him, it wasn't exactly in Apple's best interest to create apps that interoperated with apps outside the Apple ecosystem. All those are people/policy things.
> rendered irrelevant by the web
I don't really get what you're saying here, in the context of capability provision. But I'd say no. There are many web platforms offering capabilities via APIs, but still many restrict access to their own apps, with Reddit being one of the latest to drastically restrict 3rd party access.
OLE has been dead for decades, yes. When was the last time a new app launched and being embeddable in Office documents via OLE was a key advertised feature? I don't know what even happens if you open a .docx with an embedded OLE object in Word Online.
Obviously the APIs are still there. You can use them if you want. It's just that nobody is writing pure/native win32 apps anymore, outside of browsers and legacy codebases. So, new code isn't being written as OLE controls.
I don't think Jobs killed OpenDoc because of some vision of an ecosystem of Apple's apps. At the time he made that decision Apple was on death's door because it had a culture of architecture astronauts spending years in front of whiteboards, writing features that didn't directly appeal to what the market wanted. He killed many projects at that time for the same reasons, like their line of printers.
If OpenDoc/OLE had been genuinely the right path we'd have seen people outside of MS/Apple try to reinvent them. Plenty of companies have the resources, as does the open source community. In fact KDE and GNOME both did try with KParts and Bonobo. But, both of those are dead too.
To your wider point, yes, it's often the case that what the app developers need/want is in conflict with what the users need want. I don't see that as a problem. Trade always involves tradeoffs, when users and developers trade there is always an implicit negotiation in the background. Sometimes that negotiation falls more on user freedoms and sometimes users choose to give up those freedoms to get other things they want. That's just trade, it's been true since before humans had writing. I don't think there's anything unique or special in computing in that regard.
Because something isn't widely adopted doesn't mean that it's dead. Microsoft continues to use and support OLE today, and there's a non-zero number of non-Microsoft-affiliated persons out there using it (I've seen forums with users asking how to do X regarding it).
KParts too is very much alive, as it's a core part of KDE Frameworks, which is used to build Plasma. And I know for a fact it works very well because I'm a Kubuntu user (11 years).