The background to the play "Why the OMA is a date-rape product, and how the OMG finds true love"

Introduction

This document summarizes the unpublished correspondence that led up to that play, and sets it in the context of already-published web pages.

The play itself is part of a "sooner and better" tactic aiming to attract suitable collaborators to what is at present a one-man project with an initial objective that is difficult to credit, namely:

If that tactic fails now, the project enlarges at a later stage, probably at some cost of its own time or initial quality, but – I would suggest – at a far larger opportunity-cost to the OMG, the information product industry and the market at large, so spectacular has been the wonderful success of the Web, but so handicapping are the limitations of html/http and all presently associated or alternative software technologies, and such a tragic pity that as a result we global villagers should thus have to limp along on what we pretend is our information superhighway.

The "sooner and better" tactic

Attracted by Jeff Sutherland’s Object Technology Web Site and then by the OOPSLA ’96 Business Object Design and Implementation Workshop II organized and chaired by Jeff, I submitted a position paper, The emperor’s new clothes -- an outsider’s perspective, in which I introduced MACK, the Metaset Architecture for Common Knowledge, and from its perspective criticized the OMG for having backed away from their original plan published in November 1990 (Object Management Architecture Guide 1.0), which was to base that OMA on a "generalized object model" instead of on a "classical object model".

Andrew Watson of the OMG responded with a "Coda: OMG Rationale for Choosing the Classical Object Model", explaining why the OMG had no option but to choose as it did when it did (That was for CORBA in 1991).

Since MACK is intended as a total replacement both of the present OMA/CORBA and of its competitors such as Microsoft’s DCOM/ActiveX, I took care to open the paper with a heading and a limerick showing an awareness of how disproportionate my little project must appear to those who are aware of the enormous difficulties that are presently associated with end-user-oriented distributed-database applications:

… where angels fear to tread

Here is a fool programmer from Africa South
who sees evolution well needs a good rout:
  "No one has all qualities
  so let’s stir those authorities...
and surely together we can pull a plum out!"

Soon Jeff also published my faq, in which one of the answers (to q 2, "Why the fairy tales and nursery rhymes?") contained this explanation:

The "pull a plum out" in the last line of the limerick harks back to the English nursery rhyme: Little Jack Horner / sat in a corner / eating his pudding and pie. / He put in his thumb / and pulled out a plum, / and said "What a good boy am I!"

The origin of this rhyme is also relevant (and little known, what a pity!). It relates an incident in that classic Church/State struggle in which Henry the Eighth, King of England, began confiscating the properties of the Church. A Bishop tried to cut his losses by giving the King some of the Church’s properties secretly: he baked their Title Deeds into a pie which he sent with the kitchen boy, Jack Horner, to the Palace as a present. Jack extracted one and kept it. To this day that property is still in the Horner family. [...]

The incident was a classic win-win: the Bishop got to keep his other properties, the King didn't have to lift a finger for the ones he received, neither knew about the missing one. So in an updated way we may identify with Little Jack Horner: the current suppliers of information products – represented by the Bishop – might be more secure after some major adjustments, the customer – who is King – will be much better off without really trying, and we – by being instrumental in a small but key way in the transaction – will make something out of it.

In this picture of IT supply and demand personified, we may recognize the thus-updated King in the play as King Customer, while the Bishop becomes the Archbishop Informatico-Technologus with the standards-setting sons, the youngest of whom, Bishop ArchiBoard of OMG, we see entrusted by the representative of market demand with a beautiful and marvellous challenge, the older standards bodies having been rather slow off the mark.

But who is the "we" who "will make something out of it"? Jack in the play is still just myself, whom you see trying to get into the plural with appropriate collaborators. As I said in an e-mail to my OMG-related respondents recently, "for many tactical and strategic reasons, the less of me that remains in the initial launch, the "sooner and better" it would be for us all."

As you see in the play, Jack wishes merely to apply the technology. That was why – considering the absence of appropriate existing tools (a sad state which still prevails!) – he embarked on this initial tool-building project in the first place. See the references in my faq q 2 & 3 replies to my 1986 book, Beyond Apartheid, whose own objective is becoming ever more relevant and urgent to pursue, that being my own further project. (The faq q 3 reply pointed out that South Africa is the best and most eager microcosm in which to develop the information-based democracy that would apply world-wide. And as I said in concluding my paper, "the medium will be the message as never before." Thus while the tactics of that book obviously require some updating, its strategy is still 100% appropriate to the emerging information-based new world order, rather ominous though such a project may certainly appear. On that last thought, see the "Sixthly" point of that q 3 reply.)

Thus the quotation in the limerick was expanded in the paper, the faq introduction, and in my Introduction to my comments on the other Workshop papers (the comments being accessible from the respective papers, themselves accessible from Jeff's Business Object Design and Implementation Workshop II page). So I have consistently been inviting others to join me in finalizing MACK (and Metaset, its first realization). I was – and still am – hoping that the launch would thereby occur "sooner and better".

With a view to making such a project an attractive bet at this stage (among the other important reasons set out in the play and also in my faq q 11 reply) I withheld the details of MACK, and still am, but you can see an ongoing process of giving background and other argument (see especially my faq q 3 reply) with a view to tempting duly qualified and entrepreneurial software architects into joining and largely taking over this initial tool-making project.

The "play" document is merely the latest instalment, as I test how far I need to go. (On the other hand, the time could well be approaching when I decide that it is better to withdraw that invitation and just progress faster with programming it myself, with help from my local colleagues where necessary. In due course the product's demonstrability will far more easily sell the whole concept, and its use will promote and support the medium’s own further – and far more rapid – market-driven evolution.)

I have been targeting OMG-related or -knowledgeable individuals, believing that the OMG is the best-placed standards body to assume responsibility for the "MACK-to-ACK process", whereby MACK evolves – with the key help of the MACK-compliant market (the medium being the message) – into "the Architecture for Common Knowledge" as a suitable universal standard to replace all other contenders in the distributed object architecture stakes.

The paper was explicit in its intent: an enormous change of course is required of "the OMG Titanic". More specifically, "interface inheritance" has to go. But nonetheless there are good reasons why the OMG should take over that MACK-to-ACK process: see my faq q 1 reply.

Within the OMG I have been targeting Business Object people, rather than, for example, the Architecture Board. BO is an area well known to require an appropriate architecture. One would think that it should therefore be awash with at least speculative resources. More importantly, though, the further needs I plan to address require a qualitatively better and real business-driven "Market Vehicle" to support and power the effective simplification by Supply of the complexity of real democratic Demand (See my paper and faq q 3 reply). So in BO we have what should be a happy coincidence of demand and supply, as well as being a necessary checkpoint on the MACK route.

So I see that Titanic starting its turnaround (at the latest) after nudges by outside demand tugs rather than after easy sighting by its own bridge, such being the OMA blinkers that its navigators are wearing (the "blinkered fixation on a misconception of encapsulation" being a key theme of the play).

Knowing that "fools rush in where angels fear to tread", and being well enough aware of the quixotic nature of attacks on entrenched views (see my faq q 2 reply, and consider the whole "Scylla and Charybdis" scene of the paper and faq q 2 & 3 replies, also depicted on the cover of Beyond Apartheid), I have nonetheless been addressing OMG-related folk, in pursuance of my "long shot" tactic towards the "sooner and better" end. And that long shot target – the Kafkaesque bureaucratic castles of the standards worlds, with all their deep-rooted interests so underpinning the immobility of the Charybdian figtree – has indeed started to appear less impregnable than might normally be feared.

After all, MACK is The Mainstream, and I certainly feel as if I have trumpeted around the walls of Jericho at least seven times! And I have lived through apartheid's collapse, so I have seen long-entrenched resistance suddenly crumble. In Beyond Apartheid I had even given what I saw as a feasible timeframe for its fastest movement: the 5-year period starting 3 years from then (which was May 1986). Naïve revolutionaries thought that too long, for the hard-bitten realists it was far too short. In the event, May 1989 was the middle of FW de Klerk's January to September rise to the Presidency, while Nelson Mandela's Presidential Inauguration was in May 1994.

As boldly, I predict that it will be between one and two years from now that MACK will convincingly replace the OMA (and DCOM, HTML, Java Beans, etc) as the architecture of choice for Internet-leveraging applications.

My brief e-mail correspondence with Cory Casanave, the Chair of the OMG’s BODTF (Business Object Domain Task Force), and the glimpses he candidly gave me into life within the OMG straightjacket (my term), led to my reference to him in the play as "one of the more perspicacious of the BOF chefs".

There is also the TRC Inc’s submission (the "one exception" noted in the play), with its commendable generic-agent basis, further open-endedness and considerable MACK-compatibility that I have already expanded on at length to them and to the JBOF team. (That was in the "previous" or "Worker’s Day document" so often referred to in the play. It also contained the dense paragraph expanded into the play’s sub-headings under the "Some key details" heading. So the play itself was a postscript to that document). That document was addressed to the TRC Inc's Peter Walker, who is also the Chair of the OMG’s ORB/OS TF (Object Request Broker / Object Services Task Force).

So, notwithstanding the titanic exercise the MACK strategy openly envisages with respect to the OMG, I believe there may still be some tiny hope that the OMG will not proceed on any presently-proposed BOF basis, and a better hope that there may be at least one perspicacious and entrepreneurial OMG-related person who will realize that it would be better to "join Jack in the kitchen".

But what if none of them do?

The more likely but messier OMG future

Since it is difficult to sell a project without disclosing its key details (though – as I have recommended – do read at least my faq q 3 reply), I have already placed my bet that the OMG will choose the JBOF submission for its future BOF (Business Object Facility).

There are better semantics in that submission than in the others (though that is not saying much!), so if any of those submissions is to be chosen it must be that one ... that is, if the OMG wishes to persist with their present "make-believe" (as portrayed in the play) in their present OMA and all those disorganized "island classes" that a Classical Object Model inexorably leads to (the latter quote being from Grady Booch as requoted in the play from my faq q 7 reply ... though perhaps I make more of it than he intended)).

As I have said above, that would be at great opportunity-cost to all concerned, that is, everybody remotely concerned with IT, whether as supplier or user.

None of the would-be complete BOF submissions have anything sufficiently different from the status quo to give them any chance of competing against Microsoft, as I have already set out in greater detail to the JBOF team and other OMG-related folk. On the contrary, an OMA-based BOF would merely yet further complicate the OMA-based scene, and it is precisely Microsoft’s single-supplier coherence and hence the relative simplicity of their toolset that are giving them the edge.

I have even suggested to my OMG-related respondents (under the title "Not an April Fool message" last April 1) that they might consider inviting Microsoft to join a "sooner and better" project in preference to their shared allegiance to the interface-based approach. That was also a further stimulus to the "mitre" metaphor (for the II-based "MIcrosoft and The REst" syndrome, where the OMG so regrettably personifies The Rest), in which the II-mitre's removal represents the "major adjustments" that they will jointly have to make anyway once MACK is launched. The play of course enlarges on that theme, while the paper's very first prose paragraph (following after the limerick already quoted, and referring to the "emperor's new clothes" of the title) emphasized how easily that shared allegiance may be misinterpreted:

Its admirers are expecting the OMG with its CORBA-styled clothes to rule the object standards world. Encouraged, the OMG demands CORBA-compliance in its RFPs, even as the bogeyman scaring the industry into support of the OMG – Microsoft – imposes its own COM/OLE standard. But COM uses the same cloth (also being based on interface-inheritance) so the OMG can continue to flaunt in the belief that they might still look grand together (Bridges are being built between them to reassure the more circumspect courtiers). Microsoft plays cooperative though not seriously: they may not have the same intellectual airs, but it is sales that count in the fashion world.

For their part, Microsoft is more publicly open than the OMG about the inadequacies of interface inheritance, and even insists that their DCOM is "object-based" rather than "Object Oriented". However, at present they see nothing better, so their ActiveX is still interface-based.

Even Java, eventually a major example of Microsoft’s December 7, 1995 "embrace and extend" strategy, apes conventional OO. But as a basis for a distributed-object architecture, a single-inheritance, interface-based, procedural language is totally disqualified from a MACK perspective for each of those three adjectives! Even the "language" noun, with its implicit linearity, I have suggested is prima facie less suited to the representation of complexity that a "hyper-" approach such as MACK’s (See my faq q 6 & 11 replies).

So I see no hope in Java for the non-Microsoft camp, despite current trends such as IBM's sudden and enormous infatuation for that new legacy strand (itself coming so soon after their own Taligent debâcle, with its dashed hopes having hung on a conventional OO notion of "framework").

The TRC Inc "non-BOF submission" itself indeed acknowledges major difficulties with OO as it currently is. However, the OMG officially recognizes no problems with their OMA.

The OMG Titanic obstinately steams ahead as if icebergs didn’t exist.

So while I have bet on the JBOF submission among the present BOF submissions, my big non-MACK money is on Microsoft, as the OMG gradually sinks through its rotten OMA foundation into a needlessly over-complicated technological quagmire, ending in oblivion for them as technology passes them by.

However, there is of course an alternative future, as sketched in the notes on the still-incomplete play in which you are invited to participate.

Blue skies

How are we to regard the future in general? My Beyond Apartheid (see above) opened by quoting Karl Popper (from his The Open Society and its Enemies): "We may become the makers of our fate when we have ceased to pose as its prophets.". My first sub-heading was "Let us simply make it happen!". On the other hand, the Metaset project's founding document (of March 1990) was entitled "Ride The Mainstream!". Is there not a contradiction there, between activism and fatalism? Do we make or do we suffer the future? No, there is a mere recognition of reality: action is most effective when in the right direction. And what is "right"? See my faq q 3 reply, and especially its "Fourthly" item, where I argue in effect that we may expect to see a growing confluence of "right" in the moral sense as in the mechanistic, scientific or marketing senses, that is, between "good" and, on the other hand, "correct" or "accurate".

And we may simply do it by empowering our Information Society with suitable tools, thereby harnessing maximally-sharable values. That is, of course, "Mainstream" stuff too: it is to a greater or lesser extent already the instinct of everyone working towards the information-based society that that will increasingly be the case. Let us rather not delay it unnecessarily by going out yet further onto the OMA limb.

The OMG may go it alone with MACK, but it would make more sense for them to extend their gaze and embrace Microsoft sooner. As I said further in my April Fool's Day message (already mentioned):

I have been inviting the OMG – or associated entrepreneurs – so why not invite Microsoft to the party too? The "Microsoft and The Rest" syndrome, the Mitre, could dissolve before our very eyes, "sooner and better". What an appropriate picture, as by its role and very shape a mitre so nicely symbolizes that strange but typical ecclesiastical blend of brute-power-over-minds (Microsoft) with fine-but-conceptually-rigidified intentions (The OMG)!

Plain simple standards sense, too, surely demands such a resolution.

In that same e-mail I further set out how MACK, on its simpler and firmer conceptual foundation and with its cleaner and more integrated market-driven dynamics, would help cut Microsoft down to a size which would be better for everyone else and for Microsoft too, as it would be a more stable basis for their future. (Metaset is presently only Microsoft Windows-based, but has some novel portability features and will soon lead to a strong market for simplified and optimized MACK-hosting operating systems.) See my paper, faq q 8 & 9 replies, as well as the play’s eventual destiny for the Sorcerer.

So it is my optimistic and (I believe) not unduly naïve position that it would be in both Microsoft’s and the OMG’s long-term interests to take the tonic that would empower them to shake off that absurd "II" mitre.

The question remains, then: How messy – or tragic – will the opportunity-costs have to become before they take this strange initiative seriously enough? For some of the more obvious of such costs, see under the "need for tools" heading in my comments on Jeff Sutherland’s own OOPSLA’96 BO Workshop paper (find "software crisis" in it, or in its latest updates, on WebApps and on Homepage Journal). See also Jeff's masterly new synthesis of current approaches to addressing that crisis.

It seems preferable – and more realistic after all – that someone should help simplify the whole picture enormously, for the whole industry and its users, by accepting the invitation to mount a "sooner and better" project. (I repeat my desire that they should also take it over as soon as the initial or "Boot" product – see my faq q 9 reply – is running sufficiently for me to use it to start pursuing "my own further project" mentioned above).

It is true that anyone investing capital in this software project would at this stage have to regard any such investment as a mere hedging of bets, but once again, see my faq q 3, 8 and 11 replies for some factors which, with careful consideration, should reassure that there is, after all, little risk and much to gain.