Comment by skeledrew
1 month ago
> the expressed preference
Marketing and culture can do wonders to one's preference.
> synonym for capability Yes and no. An "app" is usually a set of capabilities, not a single capability. Many of the core *nix utilities for example are specifically designed to have a single capability each, and these are then composed for complex requirements. But for the most part today's apps contain multiple, usually overlapping capabilities. For example Microsoft Word offers not only text editing and formatting, but also has a dictionary+thesaurus, spelling+grammar check, mail merge and lots more. Of course, you can abstract this all away as "word processor capability", but there are other word processing apps out there with varying capabilities, and so things become problematic fast especially in terms of interoperability.
> OpenDoc and OLE These "never worked" due to people/policy, not due to tech ability. OpenDoc essentially stagnated at Apple due to conflicts and lack of clarity, and then was outright killed by Steve Jobs[0]. OLE(tm) hasn't failed per se, but it's proprietary to Microsoft[1] and thus doesn't have much adoption outside Windows.
> Brand names matter All they really do is put a label on a bundle - or bundles - of capabilities to create handy associations. YouTube is associated primarily with accessing videos that can be made and uploaded by anyone, secondarily allows commenting on and liking said videos, etc. Again, marketing is a significant factor.
> a built-in feature You seem to be missing the forest for a tree here. That's a single example, of infinite permutations. Also, even given that example you're still missing parts of the flow.
[0] https://en.wikipedia.org/wiki/OpenDoc [1] https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
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.
1 reply →