“Middleware” has been used several ways in the last few years but I mean here things such as software libraries, fonts, style-sheets, and synthesizer voices, that do not come with either an application or document but are assumed to be “generally available” at the “corner drugstore”. It is good that few documents come with the common scaled fonts. It is good too that MIDI files can assume that their destination is equipped with a few appropriate voices. Some of these materials are available for free and others are proprietary. There are difficult business considerations lurking here. Capability discipline together with tamper resistant hardware might support micro-payment systems but this is way off.

Then there is the issue of whether these middleware resources are compatible with the software that would invoke them. It is good that middleware can evolve but that will interfere with applications that viewed the old behavior as a feature and not a bug.

An additional problem arises when two software applications interoperate by passing references to middleware objects. Apple’s OpenDoc was predicated on this pattern. I don’t know if this problem was observed in OpenDoc.

A hard line on version numbers is as fatal as an entirely promiscuous attitude on versions of middleware. Life is still hard with capabilities. Some think that persistence makes the problem harder. I address that here a bit. I think that the ability of a capability system to have multiple versions of the same middleware solves far more problems than it creates. It gives the user more options. Perhaps too many options.

I can imagine in the future a public data base indicating which combinations of versions work, vouched for perhaps, by authors of some of the versions. These good combinations would necessarily grow and shrink well after the software was shipped.