[bodhiandphysics]

This seems like a great idea! It was in fact a major focus on effort by basically everyone from about 1988 until 2004... This was the idea behind Microsoft's COM, IBMs SOM, smalltalk, Objective C and Openstep, many different projects at apple, and many more places.

It failed for reasons that are obvious in retrospect. Creating a system where you can embed one app in another requires everyone to agree the interface standard. But the interface is extremely complicated! You have to pass arbitrary data between two applications, and do so quickly. You also have to decide on how much the apps are isolated from each other (getting it wrong creates either massive security failures, or performance that is way too low). You also have to deal with such issues as how to synch the user interfaces!

So any such system is going to be extremely complicated, and getting everyone to agree on standards is almost impossible. What standards do get created are so complicated that they become unusable except for very stereotyped use cases. The other alternative is when a single company forces a standard down everyone's throat. But that creates the problem of vendor lock in, so people tend to reject that!

There are in fact a couple of notable successes. The most obvious is the digital sound market, which btw is a really interesting software market because there is huge competition. There are 4 major DAWs (digital audio workstations), and a number of still used minor DAWs, plus lots of companies that make synths, effects, tools you name it. And they all get sold! A huge amount of this software is in the form of "plugins" apps that run in the DAW as a container. This works because the interaction between plugins is a) similiar to unix pipelines (it forms a directed acyclic graph), so the interation is relatively controlled, and b) there are two standard data interchange methods. One is raw sound data in the form of 32 bit 48 kbs PCM, and the other is midi (a form from the early 80s for controlling synths). The user interface problem was solved in the easiest way... there is no user interface specification, or library, and every app has to roll its own interface (which it does by just using bitmaps... you end up with the most horrribly skeuomorphic designs you've ever seen!). There are actually 3 different standards for interfacing with the DAW, but one VST is dominant. Moreover, because of the simplicity of the data exchange format, the interfaces are actually quite simple to use, if you know about the weird world of audio programming.

The other success story is Microsoft Office. Office is based on MS's tech for creating components, known as com. When you a draw a graph in word or excel, you're actually using a different little app that draws graphs... and you can embed that in your own (windows) app. But COM is extremely complicated, and com components are almost used in apps specifically designed to be part of Office. There's a fairly big ecosystem of these apps (or there was) but its very tightly controlled and integrated by Microsoft.

[1000100_1000101]

You don't need everyone to agree on an interface if you approach things slightly differently. Like Unix shell scripts and pipes, each program can have its own particular inputs and outputs, as long as they're useful and documented... people will find ways to stitch them together.

This was the approach taken by Arexx. I've never used or seen IBM's Rexx outside of the Amiga version, Arexx. While a PC version of Rexx existed, it's obvious why it didn't take off... IBM wanted exorbitant fees per end user, and even higher developer fees. As a result it had no users, and with no users, no software bothered to supported it. Most PC developers likely had no idea it was even a thing.

It was different on the Amiga. Commodore somehow got the rights to including it in their OS, no additional licensing required. As such, there was a ready user base, and thus many apps had Arexx support. You could query data from one app, massage it in the scripting language, then pass it off to another app.

It was a well-loved feature allowing all sorts of automation that wasn't really available anywhere else.

[bodhiandphysics]

you still need to agree on some things... For instance even if you're passing data through text, you have to agree on the actual encoding (Unix uses ascii, but there are lots of different text encodings!). You also have to agree on the meta-properties of the communication. How do programs find other programs to communicate with? How do they actually pass data to each other? How do they maintain transactional integrity (i.e. a request sometimes needs to be atomic, either happening or not happening, and the requesting program needs to know if a request happened!).