Act III  --  The Future

by Christopher Spottiswoode
cms@metaset.co.za

November 1999 -- 16 January 2000

Table of Contents

The author suggests a first reading from beginning to end before using the Table of Contents.

The indented sub-entries identify only the sections of more continuous monologue addressing the indicated matters.

Executive Summary

With this document the author is making an offer to Microsoft to adopt a new distributed-application or Internet-leveraging information-system architecture.  The proposed future is shown as a radical though logical evolution of Microsoft's presently-apparent strategy.

Alternatively, some other organization might take up the offer in its own way.

Independently of who accepts the offer, and even if nobody does, there are two main outcomes in the depicted future.

The background there is that the present antitrust actions by the US Department of Justice (DoJ) against Microsoft, led by lawyer Joel Klein, have so far culminated in Judge Thomas Penfield Jackson's "Findings of Fact" (United States of America v. Microsoft Corporation, C.A. 98-1232, announced on 5 November 1999 and accessible from here).

While the antitrust issue is a most convenient context for arguing the significance of the project, the fundamental reason for the wider opportunity is that the new architecture represents a radically more appropriate approach to the complex realities of the brave new world of the Internet.  (That's one reason why the reasoning is often rather abstract!)

Better recognizing those realities -- and long-proven generic approaches to complex situations in other domains -- allows far better success with the conventional aims of software component reusability, and application interoperability and portability.  It is implicit in those aims that they will surely lead to a more stimulating and creative market, and in its turn, to an ever more pervasive burgeoning of development and use of information technology.

Such liberation from the constraints of the dominant existing architecture will produce such a competitive situation that the software monopoly problem that Judge Jackson has identified will simply no longer apply.

More significantly, of course, such an architecture-facilitated market, inevitably involving far more than mere e-commerce, will powerfully promote the creative and collaborative resolution of virtually any social problem.

Background

This Act III is a sequel to the same author's Act I, Past, and Act II, Present, written in May 1997.  (More precisely, the latter were in the form of "program notes" on a dramatized play on reality.  You may access the earlier play and its background document from here on the OOPSLA'97 section of this Web Site.)

The original play criticized the presently dominant architectural approach to distributed applications, most specifically in the context of the OMG's BOF efforts (that is, the Object Management Group's RFP for a Business Object Facility).  On the basis of many rather abstract arguments the author predicted disaster for those efforts.

He did so because he had an alternative which he had proposed in his paper submitted to the OOPSLA'96 Business Object Workshop II with a view to attracting collaborators to his project.  However, trade secret and presentational difficulties, both concerning the radical novelty of the alternative and his need to preserve his tactical options, prevented him from disclosing its inner details.  Furthermore, the degree of abstraction of his argumentation does not help the reader towards firm yet accurate conclusions.  In addition, the autobiographical details which he intended as a counterweight to the abstraction also distract or put off many readers.

By now, however, the predictions can help evaluate the validity of his abstract perspectives.  So, what conclusions can be drawn?

During the intervening two-and-a-half years the future, supposedly so unpredictable in the modern software world, has already been unfolding very much as the author had foreseen in the original Act II and associated web pages.

Most specifically, the OMG's BOF RFP has been withdrawn.  Further predictions have also been largely confirmed, such as that the then very fashionable Java would do nothing to reduce Microsoft's dominance, and (later in 1997) that XML, despite its strong points, would disappoint, and on account of its inappropriate orientation.  Significantly, and though he does not pretend that they give the complete story, the reasons for the predictions also seem to have been valid.

The original Act III of 1997 presented an admittedly rosy sequel (that is, it was rosy from the point of view of the OMG, to whom it was addressed).  But the author expressly bet against it.  On the contrary, in the background document he had repeated an earlier urging of an industry-wide collaboration including Microsoft.

The realizable sequel is at last presented in this new Act III, The Future.  We enter as Scene 2 opens.  Scene 1, covering what is by now the more recent past, is not presented, but the later scenes (which follow here) do give further details of the earlier predictions and of their subsequent confirmations by actual events.

As will become plainer as it proceeds, this instalment of the author's ongoing public story on this website further develops an already very extensive and coherent picture (which the dramatic form helps bring out...).  Vast coherence is the first prerequisite for significant bodies of truths.  The second -- and most telling -- is prediction which is consistent with the abstract picture and is subsequently confirmed, with no fundamentally significant refutations.  So the moral of the elaborate combined saga is this:

There is a serious chance that the future will transpire essentially as set out here.  

"Essentially" here means ignoring the obviously irrelevant details required by the dramatic form, and the still-expected compatible contributions by the actors themselves, including those (such as you, the reader?) who have not yet come on stage in the fragments that follow, yet have an own role to play in the collaborative making of the relevant aspects of our common future.

(On the other hand, the past as related below is actual historical fact, in every detail.  Real historical characters are given surnames.  Those without surnames do not exist at all.  Each one merely represents the role which is evident in each case.)

Act III, Scene 2.  Two men are alone in an elevator.  The lights for the 20^th and 21^st floors are both on.

Older man, bright and breezy:  Hello, you must be Mister Gates?  Well, this elevator is sure going to make this a lucky day for both of us!

Younger man, glaring, grumbling:  Don't talk to me about luck.  There's that man Klein and his gang buzzing around me like flies.  Anyway, who are you?  (And please call me Bill.)

Older man:  Thanks Bill.  My name's Christopher Spottiswoode (though you've surely not heard of me).  I'm from South Africa, but right now I'm squatting on the floor above you.  And as it happens, the lucky bit for both of us is exactly that man Klein.

B:  Impossible!

C:  Not nearly as impossible as the rest of my story.

B,  always good at ironic repartee:  Oh, like a bunch of clowns like the OMG or the W3C is going to threaten Windows?

C:  No, just that a clown like me is threatening the OMG and the W3C ... and Microsoft as it is right now.

B, having heard perfectly:  Then leave me alone.  Right now, I've got Klein to worry about more.

C:  Wait till Klein hears about it.  He'll leave you in peace right away.

B, hesitating for a rare moment:  Hmmm.  But you don't know Klein.

C:  Funny you should say that.  As it happens, I think I can almost act his part in your story.  Shall I show you how it might well act out?

B, quickly regaining his composure, and as the light for 20^th is turning off:  Then get off here too.

Both exit from the elevator.  

Act III, Scene 3.  The same two enter and sit down at a low table in an executive office.

B:  Now, quick, before I get it again from my secretary:  "No more sparring with every nutcase making far-fetched claims!"  What do you think you know about Klein?

C:  Joel has a very strong sense of justice, beyond mere legalism.  He is driven by it ... or believes he is.  Not necessarily everyone's idea of justice, but he'll be steered by anything that fits into his own sense of it.

B, growling again, half to himself:  Hmmph, where's the justice in breaking down individual enterprise?  And Windows supports more entrepreneurs than any software ever before.  It couldn't do that if that wasn't good.  That makes it moral too.

C, laughing:  Don't worry!  My story won't get you bogged down in any moral hair-splitting.  Anyway, on those points I wouldn't quibble with you.

B:  But how can you say such things about Klein?

C, suddenly very earnest:  A lawyer called Joel (I'll call him Joel X as he is a real historical figure) was the centre of a software-industry lawsuit episode I remember as clearly as when I heard of the Challenger disaster.

B, pensively:  Ah ... yes ... the classic example ... your mind takes a photo of it.

C:  And how!  I still see it exactly as it was in 1977.  We were going down an escalator in Downtown Los Angeles.  (I was with Joel X and his colleague, on our way to lunch.  They were representing a colleague and friend of mine in a software-related lawsuit-plus-countersuit.  I was busy making a 2&1/2-day deposition in both suits.)  I had mentioned casually to the lawyers that both lawsuits should really be dropped.  In an instant that changed Joel's very being.  He swung around to face me, his elbows out, like I'd physically threatened him.  He barked back (and here I quote him absolutely verbatim), "What!  But there've been damages, and where there are damages there must be redress!" As you can see, his attitude engraved the situation in my mind.  I see the same kind of zealous absorption in your Joel Klein.  And that's great!  You can rely on it.  Build it into your strategy.  The lawyer will choose to become an ally.  Then you'll see some "evangelistic advocacy" ... fervour in moral and legal dimensions ... effectiveness squared!

B:  Continue.

C:  I'll come back to our Joels later.  For now I'll just add this tail to that episode:  Outside that exchange, I tried very seriously to persuade the lawyers on both sides to drop their respective suits.  Of course they only scoffed at legally-ignorant me.  It took them over two more years before they eventually did drop both suits.  The non-lawyers in the story -- and their respective businesses and customers -- would have gained a lot if the lawyers had respected my reality- and experience-based intuition.

B nods slowly for a brief moment, but is suddenly alert and intent:  Back to here and now.  You bracketed Microsoft with the OMG and W3C.  (What an idea!)  But tell me more?

C:  Yes.  It's about a whole new application architecture to supersede your's and both of their's.  So this present lawsuit is only a very small part of the story.  But it is the tip of the iceberg of Microsoft's strategic market positioning.  So while that tip might just melt away ...

B:  ... I would still do well to steer the iceberg away from any threatening heat?

C:  No, it won't be that difficult ... in fact, when you get into it you'll see how you'll ride it!  But it is a big story ... iceberg big ... so you'll have to concentrate.  [He looks around]  So we must get you well away from calls.  Let's go on up to my office on the 21^st.

B, somewhat taken aback:  Well ... umm ... okay.

They go out, the younger man shaking his head, rebuking himself for having got into this.  But he is always game to listen to such stories.  In fact, the idea of a radical threat sometimes rather haunts him...  And he is intrigued by the antitrust link.  It is obvious, after all, but the danger to Microsoft!  And the details...?  So he'll give this odd stranger the benefit of the doubt.

Act III, Scene 4.  The same two enter a cluttered study with a couple of PCs.  

B:  I thought you said "office"...

C:  A world away from your's?  But me, with 30 years of IT, I'm a programmer again ... though one who thinks he's quite in touch with the market.  As you might guess...  [He gestures towards the rows of books and stacks of journals, open ones lying around, conference proceedings, pencilled notes of meetings.  Then glancing towards a PC:]  Quite apart from the Internet.  Anyway, do please sit down ... and away from the PCs.  We must talk context.  (Especially when the program is not flying yet...)

The younger man's sudden disappointment does not turn to loss of interest, but is dispelled when he recalls what brought him there.  The Flying Window screensavers evoke a small but reassured smile, growing slightly as he makes a further mental note:  "And it's 2000." They pull two chairs away, make a rather cramped space.  A bumped mouse reveals Microsoft Visual C++ and a window of pure C code.  The smile grows further.  The other's immediate and resolute ctrl-alt-del K locks the computer.  They sit down.

B:  Well?

C, taking a breath:  I have been busy, on and off for a long time, as you'll see, largely designing and (so far) partly coding the next program that will run on almost every Internet-connected computer on the planet ... the next program after your Windows, of course ... and it's a plain Windows program, as you've just noted.  So you should like it.

You'll also like the parallels with the tightly-integrated browser+shell.  [He smiles briefly to watch the effect.]

Then -- as I said in your office -- there's a whole new application architecture too, so it'll also launch a very interesting process.  For example, the market will surely soon replace the original program with many conformant variants.  And of course the architecture is such that the replacement process itself will be compliant and generally very smooth too.  But another consequence will be [he watches the other carefully] that fully-conformant variants will also soon be on every Internet-leveraging computer that does not run Windows.  [Conclusively:]  That's why Joel Klein will like it.

B, his mind easily racing along with such ideas:  But what about Judge Jackson's "chicken-and-egg problem" ... his "applications barrier to entry"?[1]  That's the one I really like, of course.  And besides, you can't replace all those applications [with a quick sweep of the hand] just like that!  The judge was right.

C:  The judge was 100% right.  So, no, it is inconceivable ... now ... with present architectures.  But with the new architecture the market will make it happen to a sufficient extent in far less than Judge Jackson's "few years".  And it will happen more easily if you chose to be the one to set the whole process in motion.  I think you'll soon see why you might choose to do so.  But right now I can assure you that with the new architecture some things are absolutely certain:  

• Fluent component reuse will ensure that developers will leverage each other to great mutual advantage.
• All conformant applications will be highly interoperable.

Both features will pertain at quantum levels higher than with present architectures.  So most present Windows developers will want to climb on the bandwagon.

• Applications will also be naturally portable to any other compliant operating system, so most other developers will climb on the bandwagon too (since mutual compliance will be quite easy to achieve for almost any basic host operating system with some windowing capability).

So most new Internet-leveraging applications will fit into the new environment ... and only into it.  Clearly therefore -- and especially for you -- a lot will depend on who gets in first.  But either way, it will totally undermine Klein and Jackson's problem.

B:  That's crazy!  Hey, now that's what they would call a monopoly!

C, rather impatiently (not seeing that he is being baited):  There is only one Internet.  Does anyone seriously call that a monopoly?  No.  The universal market requires such a standard, and most people see its further development as a very open process which unduly favours no single supplier of add-on products.

In an even more open and collaborative way, my program -- and maybe it'll be "our" program? -- will provisionally define, sufficiently illustrate and widely propagate a new standard that will be fully complementary to the Internet, and will meet the market's clamour for higher-level standards.

As you know, the basic Internet is up to Layer 4, Transport, of the 7-layer ISO/OSI model.  This new standard, leveraging Layer 4, covers -- roughly speaking -- at least the presently-controversial remainders of Layers 5 through 7:  Session, Presentation and Application.  That's a fine closure!

And it's no monopoly as everyone will build their specific applications, in a conformant way, leveraging that architecture and the conformant infrastructure, and openly evolving both architecture and infrastructure at the same time too.  "OSI" does after all only mean "Open Systems Interconnection".  It will surely greatly influence and shape the applications, but it will never define and freeze them too.

It is not for nothing that I so like quoting Heinz Zemanek, a past President of IFIP:

"An architect does not tell people how to live.  He creates an environment in which people may live their own lives creatively."

B, now imagining that "applications barrier to entry" crumbling even more seriously, he reels off objections:  But what form can such a standard take?  And why would anyone go for it?  I mean, can you really see the industry agreeing on such a thing?  [He thinks of all Microsoft's existing standards and infrastructure in such areas.]  Look at how long it has taken to get to where we are now!  And what's wrong with everything that's already in place?  You mentioned an infrastructure:  is that not an application and a service?  That is exactly the hottest property on the Internet right now:  control over the marketplace itself.  Everyone agreeing on a standard and infrastructure at this stage?  No way!!

C, with a glimmer of a weary look as he's heard it all before, many times, but the enthusiasm quickly resumes:  Look at how the Web has been adopted by everyone, despite the profusion of alternatives and long history of hypertext.  And the Web infrastructure?  At the centre of the Web there's only the W3C.  Did Tim Berners-Lee need a massive American-style marketing campaign?  No.  Or dominant-supplier muscle?  No.  Maybe it's just that the time was ripe?  Maybe, but certainly he aimed just right:  Coin a dream -- "The World Wide Web" -- and a simple tool so that everybody helps it come true by easily pursuing their own interests.  And how he got that one right!  So it can be done.

But now the time's ripe for escaping the tangle we've all spun with that Web:  big junk docs ... linked into hyperjunk ... therefore specific feedback's too difficult ... so it's far too supply-driven.  On the demand side you can't aim your searches.  You don't know what they do with your responses.  You can't trust it.  It needs better precision.  Hence of course XML.  What a consensus there is in the market for that!  What a burning and driving focus!  And it's not for controlling, it's for enabling.  E-business has been screaming for smooth interoperability and ...

B interrupts with a cut by both hands:  Yes, yes, yes...  But forget the generalities.  Forget the hype.  Everybody knows it all.  Be specific.  For example:  [and to emphasize his points he counts them off on his fingers]

C, holding up both hands in his turn:  Okay, okay.  That's enough for now.  And those are excellent questions!  I can keep to them.  (Well, more-or-less...)  And finally on your last question I'll end up with two good sample scenarios.

But first:  the answers will be shorter by contrast with the new paradigm.  Yes, obviously there has to be a new paradigm.  I was serious when I implied it would threaten all the big structural players at the higher software levels!  Full, square, and plumb in the middle:  at the moment I'm calling it MACK, the "Mainstream Architecture for Common Knowledge".  

B, quick as a flash, as he had the question coming:  "Mainstream" and "new paradigm"?  Contradiction!  [Any major innovation has the same central marketing problem, though he hasn't before seen the challenge so explicitly invited...]

C:  No, just a useful paradox.  An evolution of existing themes while synergetically there'll be a revolution.  Sellable while challenging.  Reassuring but stimulating.  You know it of course, though your own "Embrace and extend!" was more cautious.  The MACK project has a similar slogan:  its founding document in 1990 had the title "Ride The Mainstream!"  Grab the present and go places.  Conservative but radically on top.  Build on the strengths of "The System" and it will be more all-inclusive rather than alienating...  Hey, even the cynics might buy that one from Microsoft!

B, deadpan:  Is that your idea of specifics?

C, half to himself:  Ah well, I guess I meant the introduction to provoke.  [He glances back at his interlocutor]  Anyway, thanks for the interruption.

B, impatiently:  Now I'm also waiting to see how it's radical.

C:  I am working on what might still be the first implementation.  It's called Metaset®[2].  Yes, that's a very mainstream name for a development tool.

But the radical bit is that "Meta is better!" with a huge difference.  We'll soon see how that involves a radical reidentification of the mainstream in distributed application design:  our industry is at present way off up a minor sidestream (or "out on a limb", to resume evolutionary parlance).

The real mainstream, on the other hand, adds up to this:  (And patience please till I get to the end of it!  It is quite a mouthful...  Right:)     [He starts slowly, carefully, trying to pitch it right for this listener, and hoping that every word will be weighed.]

So it's always a matter of "helping people simplify complexity."  If you want a summary of the whole medium's function in one short phrase, that's my choice!

B, with only half-mock despair:  And that's what you call "being specific"?

C:  Okay, now let me put it in slightly more familiar terms.  Down to the next layer of my top-down introduction for software people...  [Shrugging his shoulders in regret:]  But the actual bottom-up technical angle involves too much detail![4]  So this is the next top-down layer:

[The listener remains silent, but he is absorbing it as the dynamic growth aspect does give it life and bring some kind of depth and closure...  So the speaker continues with the greater closure:]

B, willing to suspend his disbelief for a moment longer:  Yes, clearly.  It does tie up at a very high level...  But all that is still too mainstream!  In what ways is it so different from what we've got and where we are already aiming?  [Then more urgently]  So we must drill down:  to my specific points!  [Then interrupting himself as the general picture settles in as it revolves in his mind:]  No ... wait ... buzzword alarm!  Too much hinges on a buzzword.  So first this:  when we don't have AI yet, how on earth can we have any so-called "artificial creativity"?  Microsoft just isn't interested in anything that has always been in the future and probably always will be!

C, after a brief pause:  I am really so mainstream:  My background is in DP, in business and industry.  I may have trained as a mathematician, but I've been a nuts-and-bolts designer and programmer for longer, and then a software businessman for longer too.  Then this decade I'm back at being a low-level programmer.  So MACK has also developed in a very bottom-up way.  It has boiled out of a very lengthy but specific and nitty-gritty though market-oriented application development process.  [He pauses again.]  Can we leave it at that for now?

B:  Okay.  Yes, it's true, it's often said about AI:  all the real progress in AI gets absorbed into the mainstream.  That makes it familiar and obvious, so we stop calling it AI.  But I can see that alarm going off again soon, for sure!

C:  It'll be most welcome.  [He smiles, looking forward to the prospect, though wondering how his waffle-proof listener will take it...]  Maybe I can plant a few more general thoughts at this still-abstract stage?

B:  Try.

C:  Creativity is about seeing things in new contexts.  So a specific and formal yet also internally very dynamic representation of context is the really key detail.  That's at the same time a very epistemological and very technical exercise.  The representation has to mirror the way we think, in some hopefully asymptotic way, and yet still be technically feasible.  Often that is not too hard:  it can sail along in the middle of the very commonsense mainstream too, with its many familiar and positive social dimensions.  And of course the market aspect means that the key technology can very intimately derive much relevance, accuracy and power from those human angles, and cut the right corners.  The "mainstream-riding craft" is even driven by such integrated perspectives.  That's that infrastructure, or "medium", or "market vehicle".

But it's far more than mere e-commerce.  It's not just for Homo Economicus.  It's for whenever and wherever some people try to meet other people's needs, in whatever way, or for whatever exchange or reward.  So it's also the market for ideas, values, education[5], systems, ... everything with any degree of objectivity or sharability ... including what we often call "public services", that is, governance in any way, whether by Government or NGOs.  So on the other hand it is often very political too, with the mainstream metaphor well insisting on the swirls and turbulences and fringes...  Those must also be taken into account, "fully" and yet without oversimplification, by the craft's architects and navigators.

B:  All that makes a lot of sense.  You didn't have to be so coy about it!

C:  I guess so.  After all, it is very mainstream too.  Any active Internetter can easily identify with that kind of position.

B:  Though it's still very general, as you said...

C:  But before we drill down I hope you'll permit this note too:  this 58-year-old IT system designer and programmer, from that fascinating First World / Third World microcosm and crucible that is South Africa, has long and continually been reminded that that so-called "full" -- insistently in quotes -- always relates merely to Homo Activus (even then, often only in some irregular and meagre way) and cannot aim to capture Homo Sapiens...

B, smiling indulgently at such pretences to wisdom, however sourced:  Well, for now I'll be charitable and agree that your picture is definitely coherent, [then as the smile gradually levels:] even though that's also consistent with the suspicion that it's merely circular and without content...  [then, focusing again:]  So, let's get down to those points!

C, duly business-like again:  Now I can tick them off one by one.  You'll see how they fit into the overall picture we've got so far, and already give it some of that content you're looking for.  The first was this:

B:  A big picture, but overall it is clear enough.  It's the integrated browser+shell you mentioned, though more powerful yet still generalized.  So MACK might be quite compatible with XML?  Almost complementary?

C:  Yes!  Well ... XML is "so near yet so far" from MACK:  MACK does the "meta-" job properly.  Its uniquenesses go a lot further:

B:  Then don't forget to tell me what MACK has that Exchange doesn't have!  (Or Lotus Notes...)

C:  Oh, I've already told you:  at the very least it's that missing technical programmer again ... and of course the spontaneity!  (Sure, next-generation hypertext and mail are implicit.)

Then apart from the usual distribution-architecture aims of reusability, interoperability and portability, I'm sure you can see that more spontaneous creativity -- based on the reflectivity of good semantics in the right form -- should also be able to apply any relevant existing design wisdom in the enhancement of reliability, integrity, confidentiality, congeniality, flexibility, scalability with growth in any dimension, and any other "-ility" or system-wide quality you care to think of.  (Including the inventability, negotiability, reconciliability and practicality of any necessary compromise between the primary or "non-meta" ones!)

Back to XML, though...

B, insistently:  Yes, and more specifically!  For example, I've been wanting to ask if XML's namespace concept does not address the "context" requirement you have noted as so central to the very notion of creativity?

C, delightedly:  Good question!

B:  Quite so.  Good.  I think I might quite like that:  you should see our people shaking their heads after W3C Working Group meetings!

C:  But I would guess that that is a comparatively recent trend?  At the beginning of XML it was all fairly obvious.  They had SGML to give them a lead.  There was a lot of mainstream leeway to catch up as far as still-abstract semantic packets were concerned.  It was easy to agree on the simple interface stuff.  But it was only later that they started pushing the refinements and wading into the application.  That bumps into the limits of mere document-centrism.

For example, one even sees (in the most respectable places which I shall leave nameless...) serious suggestions that user data can happily be left in the hierarchical form of XML files and thereby constitute a database.  They seem not to know of the IMS experience (that is, IBM's hierarchical DBMS from the Seventies), which worked fine with simply-hierarchical "physical databases" but whose interconnected "logical databases" did not give efficient or flexible scalability with database size or complexity.  That is of course precisely the scene which Relational DBMS so effectively exploited, and MACK addresses even better.

For a more modern trap that XMLers are being tempted into, consider this even more respectable one.  On the "onto-std" mailinglist from the Stanford KSL (Knowledge Systems Laboratory), and in response to a call for a more powerful logic facility from the W3C, we find this admission, dated 10 November 1999, from Dan Brickley (one of the editors of the W3C's RDF Schema Spec):

"There's a recognised need to layer more sophisticated systems on top of the base provided by the current RDF specs."

And as soon as that dread word "sophisticated" starts appearing, that's when one would expect the divergences to start...

B, candidly:  Exactly.  It's almost enough to push us into a repeat of our attempted Java hijack, but this time just so that the industry can get on with things.  If only they would let us!

C, with a wry smile:  Yes ... let you "enable" it without "controlling" it!  [More matter-of-fact:]  Sure.  You want to give value now.  Yes, it is one of the ironies -- and sources of tensions! -- of any supposed "mainstream-riding" or "embrace and extend" stance:  one necessarily has to select amongst existing currents.  Thus in my case:

This is a good time to expand on my own now-proven "mainstream-selection" already touched on:  I spent over a year prior to OOPSLA'97 quite closely studying then radically debunking the OMG's Business Object work (and very accurately, as it has turned out).[6]  But in the proper and well defined places MACK does preserve that very conventional procedural programming recommendation of "thin coupling" between "well-encapsulated" program units.  However, the conventional distributed-architecture paradigm (already noted) pushes a good idea out of its proper niche:  the intentionally-thin and also poorly-expressed semantics of the procedure-call tend to create problems between otherwise-independent program units, and particularly when applied as RPC (Remote Procedure Calls).  That occurs without or with any supposed "OO", that is, as plain RPC or as remote object method invocations.  So much meaning is merely implicit in the API or class and method names, as in the parameters.  And while that clearly does generally work well for local procedure calls, or RPC development by a tight team, it is too risky in an Internet development environment, with many independent developers, such rapid change, and the whip of commercial pressures.  Thus there is no problem with simple ActiveX controls, but -- especially in thicker-client, distributed-server, peer-to-peer or otherwise more complex applications -- the inevitable semantic mismatches break down trust in so many out-of-control ways.

B:  Yes, those problems have been popping out everywhere...  And that's partly why we like XML.

C:  Ah, but I hope you don't mean that in a SOAP[7] kind of way, which is generally seen as just another way of doing RPC, amounting (from a MACK perspective) to little more than replacing the RPC wire protocol (DCOM or IIOP) with an http/xml one.

B:  Clearly.  But wasn't that rather cheeky?

C, unperturbed:  Yes.   But ever since I saw the Web, in the early Nineties, I wasn't very interested in it, on account of its poor semantics and lack of extensibility.  That was all by contrast with the semantic net basis of Metaset's 1988 precursor, which we prototyped on South Africa's public videotext network.  So I just continued with what I could immediately see would be a later generation, and has since become MACK.

B:  Ah, and I guess you would call that "confidence" rather than "arrogance"?

C:   Well, I am told that Berners-Lee was also planning a later generation, with extensible semantics, right from the beginning, but he saw the need for the interim html stage.  So shall we call it "informed foresight"?

B:  Fair enough!  But let's get on with my other points.  And don't forget that "applications barrier to entry":  your talk of mass migration is beginning to look more seriously threatening!

C:  No, I won't forget that one:  we must obviously examine your whole system of defences quite critically.  You might even be somewhat reassured by what you'll see.  Right, your next point (and be prepared for some merely "somewhat reassurance" here too!)

B:  None of that sounds very reassuring at all...

C:  Well ... if I don't unsettle you a bit first (and we must forget Klein, as you said...), what would the happy ending be worth?  [The other man glowers darkly.]  Right:  You had asked:

B, venting the frustration that has been building up:  I asked for specifics!  What kind of an argument is that?  It still looks like some vague dream, not a program!  Maybe possible ... it's all still coherent ... yes, even very tightly coherent, as your closures indicate ... but where's the content and the reality?

C, allowing himself some vehemence:  Right.  Good, you've noted the coherence of that "dream" with my entire leadup and its specifics up to now, high-level though they still are.  So we shall rather call it an "abstract model" of the IT ideal.  So now take a hard look at where it takes us:  bluntly to these specifics:  you will want to clean up the whole of BackOffice in that clearer and explicit semantic way.  You will very naturally recast all its essential functionality in MACK form.  It will be some work, of course, but well worth it.  The quality of the product will be higher in every way, in its use and manageability.  Yes yes:  so what is the precise nature of that "MACK form", more specifically?  Ah, [he draws back] now that is exactly where you'd expect my trade secrets to be situated...

B, still frustrated, now angry too:  You're wasting my time!  Threats are bad enough, but smug threats and empty promises get nobody anywhere!

C, shooting back:  If they weren't still secret what would I have to sell you?  Why should I risk your programmers writing quickly to clearer specs or a concretely visible vision?  I expect you to want to pay for great market advantage.  Your money is not yet on the table.  I shall be inviting you -- in detail -- to put it there.  [More calmly, half smiling:]  But your betting options are part of the answer to your other specific questions.  [So, more brightly:]  Anyway -- okay! -- it's fair for you to want to know more about what you might win.  So here's some more.  It is safe for me to give you these specifics:  [The other is only partly disarmed...]

B, calmed down, but still deadly:  Wait!  Are you saying that the whole system will be self-managing, and do its own housekeeping, without being programmed in detail how to do it?

C:  That is how it will appear.  Of course there is no magic.  Every minutest step will be completely deterministic in terms of the knowledge accumulated from the market.  (Surely auditability and accountability are also indispensable "-ilities"?)  And naturally, it will also keep well in touch with -- and rely on -- the enduser, and in his or her own terms, as a human and as the individual it "knows".

B:  But that is one helluva difficult thing to do!  That's just our problem, as you've said yourself.  [Victoriously:]  It was even a starting-point in your first summary:  something about "too many interdependencies", I think it was...  [He is right, it was here in the above.]  Yes!  Then you also admitted "tempting complexity"...

C, quite unfazed:  Sure.  You have brought us back to the generic opportunity of helping ordinary people simplify complexity in more appropriate ways.  Fittingly, therefore, there are two more absolutely central considerations, this time from those wider contexts I rather boasted of:

[He pauses to see if those very big features are registering at all.  Yes!  They seem to be making some of the sense they should...  (There is a bit more about it here in the author's OOPSLA'98 paper.)  Still, caution beckons:]

B, the irony still deadly:  And all that is supposed to tell me specifically how it will do without BackOffice?

C, still unfazed, as he has seen his listener further populating the general picture in his mind (since it is all so coherent, and so mainstream after all!)  But he'll enjoy taking the point:  Okay, here's a more nitty-gritty view of exactly the same scene.

B, unimpressed:  You still haven't told me how it is done.

C:  No, indeed not!  Well, once again, I could disregard the trade-secret aspect, and expand on those final generalities by showing in more detail how this kind of thing can be catered for in terms of non-procedural MACK models:

Concurrency is handled -- even in a distributed-database situation -- by the model-driven kernel by reflective "thick coupling" -- that is, via more detailed and effectively "full" semantics -- of MACK models so that potentially-conflicting resource usage can be coordinated automatically by dynamic predicate locking -- that is, in a reflectively "meta" way again -- and without the limitations of that technique as conventionally applied, such as those due to orthogonal predicates or unscalabilities.

And that is possible thanks to MACK's radically-different process structure and integrated memory management, yet with a market-extensibility leagues away from the familiar rigidification by 4GL-like approaches to high-level application specification.

But though MACK's relativity is once again crucial in those inner technical details, I don't think such horrendous details (or sentences...) would advance our discussion in the most useful directions for now.

However, there are -- as always! -- significant mainstream currents which recognize the corresponding application realities[8].  In such contexts one often sees the distinction made between database transactions and business transactions.  And it is in the latter kind where the standard ACID facilities of the bottom tier of the traditional 3-tier architecture or application segmentation approach are no longer sufficient, so the main problem is once again with that dread "application".

And since BackOffice is still the subject, it is relevant to add that it is in that "application" where even your COM+, with its oh-so-conventional procedural-programming notion of "context", is set to discover -- and with a vengeance -- the confusions and other shortcomings of that very non-Divine Programmer (of Part 1 of my OOPSLA'98 paper).

B:  I'll grudgingly accept that for now, but only because (given your clam-like trade-secret position) it offers a different angle to try in building up a picture I can relate to.  Take that 3-tier picture, as in our "Microsoft DNA".  From your XML-prompted talk it looks as if the presentation tier rather fades away (though not entirely as you later still use the term "view"), while from the BackOffice side the data tier completely disappears!  Everything is effectively middle-tier.  Can that really be the case?

C:  Another attentive question!  Yes, that is very much the case.  As I implied right at the beginning, most applications are constructed entirely in enduser terms, while in the already-specialized remainder the 3-tier notion is simply not relevant.  So everything can be seen as middle-tier "business rule", or more generally, as "essential functionality" of whatever kind.

Thus the view-construction models or rules which the ordinary MACK "application-programmer" follows automatically (in the way that replaces the old-paradigm painstaking calling of top-tier functions) would indeed have been created -- or "programmed" -- by a view specialist, capturing the essential functionality of view-design and -construction principles.  Likewise, persistence services too are integral and implicit, fitting into the overall picture in a similarly automatic though ultimately very plain fashion.

But it is not helpful to regard such many-fold specializations or divisions of labour as tiering.  While with MACK the whole notion of orthogonality is indeed central, the precise implementation of relativity naturally ensures whatever "separation of concerns" one used to seek with tiering.  Yet it does so in a uniform yet ultra-flexible way, and without tiering's oversimplifying rigidities which collapse when the interconnections raise their ugly heads (due -- for example -- to exceptional conditions, realworld or internal operational-environment variations, or scalability requirements which start demanding a better-informed "intelligence" in other-tier services).

B:  More high-level generalities!  So you are in effect wanting me to accept some statement like this:  "Programming will never be the same again!"

C, laughing sheepishly:  Yes ... in a sense ... though I would prefer this:  "Application design and construction will never be the same again!" [More seriously:]  I think it more relevant to bring out the many-dimensionality of MACK as a distributed-application architecture at the higher levels I have been keeping to, together with all those rather meta-level confirmed predictions.

The way the whole picture is market-centric, from top to bottom, and therefore impacts directly on the competition or monopoly scene, is also rather appropriate to the level of the strategic issues between Microsoft and its US users to whatever degree they are being represented by the DoJ right now.  And it is certainly at the level of that whole coherent picture that I am expecting you to accept the bet I shall be offering you.  As I've said, the antitrust tip indicates that massive iceberg of everything that is so important to Microsoft.

So in that vein I can conclude my answer to your second question by tying all those points together in this way:

B, seeming to have been following all that:  Okay, I'll agree to abandon my search for further details, and accept your story at that level of generality.  But there is something missing even at that level.  You are supposing that a full gamut of rules has been built up.  That would have to be the case if the total behaviour is to add up to something human in every situation.  For otherwise the system will be too damned stupid too often.  So it would continually fail the Turing Test, and that would destroy any trust that's been built up!  You have yourself already invoked our entire heritage of design patterns.  Is that not rather a tall bill?  Or even an impossible one!

C:  I am impressed!  Even better, you have raised some further rather fundamental points.  And they invite a few more of the many closures in my whole story.  Yes, the process is necessarily a never-ending one.  But thank heaven that that is so!  Otherwise life would be very boring.  (We are getting very philosophical here...)  But that gets us back to "context" and "relativity" again.  Clearly, we shall never have an omniscient (or "Newtonian") Agent or Digital Assistant.  So it has to make its own contexts -- its own varying assumptions or limitations -- clear to its various kinds of users.  It must create realistic expectations and deliver on them.  That is merely another aspect of its ability to explain and justify itself.  Furthermore, all that has to be relative to the enduser in his or her own context.  So "appropriate simplicity" in the form of user-relevance will be pervasive, and we will expect its limitations ... and accept them, because we can understand and influence them.  And that is where the market comes in again:  self-characterization by both demand and supply will lead to the creation by the market itself of many variants of rule-set too, and the survival of the market-fittest products will do the usual rest of the job.  In general we may expect growing richness yet still accessible simplicity in the usual more-personalized ways.  But after all, nowadays all that is really such mainstream cliché!

B:  But each niche will surely still be complex.  Any single rule-set will still have to be interpreted by the computer.  Will that not be too inefficient, too slow and unresponsive?  Leaden creativity will never be inspiring!

C:  Another good point!  (Hey, we'll have to make sure you remain part of the technical team...  [Then mischievously:]  Or was that just the re-emergence of some very old memory of interpreted Basic on a prehistoric computer?)

But there's no problem ... only more closures, at the same time external and internal again:  a market niche is a describable thing, making certain assumptions, and any assumptions can be "locked" (in a MACK-canonical "TotalOffice" kind of way, of course!) and -- cutting a long story short -- bound-in into a specialist kernel, precompiled and superefficient for its niche.  That recalls this rather cryptic quote, also from the original 1997 play:  "... precision in relevance of semantics, giving precision in its application, enables computational efficiency."

And any single user may have many such relativistic kernels available, with any degree of focus, from the narrowly specialist to the widely discursive.  Their more fully-compiled-in form is the scene of all those "agates" of Part 2 of my OOPSLA'98 paper, as described in this extract:

"Thus for example we may expect to find such agates representing any point in the spectra from hardwired application to development workbench, from thin-client to thick-client, or from appliance controllers to multi-user servers."

Such agates will be the product of the application design process as already described above and in this paragraph from my OOPSLA'96 paper:

The application design process is also carried out in a market-like way, matching the claims of well-defined Products with the needs and constraints of the user community.  Thus client-server information system design will generally be a matter of simple assembly:  Metaset is guided by logical coherence and consistency criteria through available product and component metadata.  It asks appropriate questions and mediates negotiation where necessary (the hard part!), gradually composing a tightly-bound application incorporating the thus established degree of common knowledge.  Binding is intimately associated with the whole market scene, where suppliers make commitments to their customers.  That in its turn creates the opportunity for highly-bound high-granularity application components to be code-generated for efficiency where it really counts.  Such relative inflexibility will tend to have high user-legitimacy hence high specification-reliability.

The last sentence is perhaps the most significant one there.

B, shaking his head:  Wait a bit!  You started with some kind of "total" picture, then you used it to define a practical subset.  But that leaves you with exactly Judge Jackson's chicken-and-egg problem that we started with!  How do you get your whole application-set started?

C:  Well, it wasn't easy!  But thank you once again:  at last we can cut all this top-down abstraction and start with some practical bottom-up work.  And that was of course your next specific question, though I'll answer it first in a very specific and technical way.  That is, I'll here answer from the product point of view, as the project part of the question falls under your other questions:

B:  But how do you get that process started?

C:  That will only be a pleasure!

B:  But why will anybody want to download the program?

C, incredulously:  Are you really asking that seriously?

B, his scepticism obviously not dispelled, but seeing that he needn't chase after more of that kind of "specifics":  So what have you come to me for?  

C, candidly:  Because the Boot Product is not ready yet.  Despite its "relativistically" practical scale it is still non-trivial.  And I believe that Microsoft is one of those many organizations which have the kind of resources needed for expediting that first release.  [More matter-of-fact:]  Anyway, sometime it has to become a team effort, and the sooner the better.  I have all along insisted publicly that I wish to become a mere user rather than a primary developer.  At the very least, there will have to be an organization and an Internet node responsible for the small residual central functions of that infrastructure, somewhat like the W3C itself.  (Or maybe even exactly the W3C itself?  Maybe it can remain in charge of the "New Web" too?  (Or "MackWeb", even looking almost like an appropriately Scottish-parsimonious "Son of Web"!))

B:  Whoa, isn't it a bit premature to get carried away!  [The other one looks duly guilty...]  But don't worry:  I like marketing enthusiasm ... just be prepared to adapt its form.  [Then, seeing that the older man is taking it well, he tests him further:]  Well, why not the W3C, then?  After all, you quite like XML and you do see an eventual migration process as a fairly smooth one?

C:  Fair comment!  But there is too much momentum -- or inertia -- in their present direction.  It seems crazy to even try to persuade them of a major shift in emphasis and form:  away from the text-stream and SGML form, and away from document-centrism.  Apart from anything else, they are still too successful!  (That is, within those limited assumptions...)

The OMG, on the other hand, ... now they're the ones who've run out of steam, they've lost the initiative.  As I've already told you, I've long been openly critical of their architecture, successfully predicting disaster with their higher-level Business Object efforts, and on account of their lower-level interface-based architecture.  But with at least one of their recent RFPs they are really showing how badly they've lost their way.  And even they don't seem happy with it, as the relevant Architecture Board minutes show.  But the updated RFP didn't change the fundamentals either:  they should just have thrown the whole thing out![13]  But they can't do that without upsetting virtually everything they've done.  So they're the ones who should be doing more soul-searching by now.

Sooner rather than later they'll be more susceptible to the radical alternative.  At and around OOPSLA'98 I detected many promising signs of it...  The success they doubtless think they are having has little to do with the qualities of their technology.  It is merely a sign of the massive pent-up demand for interoperability, and even that seems to be veering off in the XML direction, consistently with my opening mention of XML.

B:  Well, then why aren't you talking to them, rather?

C:  Good question!  As it happens (and as I did after OOPSLA'97) I started a "reflections" document on OOPSLA'98 too.  It was addressed to some of the high-power and charming notables -- mostly OMG-connected -- whom I'd met at that and the previous OOPSLA.  Intended to be sent a year ago now, it was entitled, "Happy New Year, OMG, you're on your own way to "Ride The Mainstream!"" But it grew too long, and while it was very correct as reportage, architecture and philosophy, I eventually concluded that it would not help me get a larger project going.  So I dumped it.  (I did however e-mail a heavily-truncated version to the same individuals, as a poor way of saying thank-you for their discussions and references.  That was the document I've already mentioned in which I more specifically foresaw XML's getting bogged down).  And that -- at least provisionally -- concluded my nearly three years of trying to interest them in bigger ways.

B:  What!  So long?  But why did you get nowhere?

C:  Many reasons, of course!  Some intrinsic, others self-created.  Here are just some of the obstacles I think I've encountered:  

• the "trade secret" aspect (despite my explicit public and revision-inviting justifications for it);
• the "new paradigm" that conflicts so radically with their own (so that's why I was merely trying to attract some of their members away from their direction!);
• the rather philosophical bent of my presentations and objectives (which doesn't appeal to everyone, while I regard the philosophy and particularly the epistemology as fundamental);
• the whole story being so darned big (requiring so much knowledge of software, the software industry and their wider contexts);
• and yet the inevitable selectivity with which anyone's own knowledge is gathered, which necessarily complicates any communication (So, with the inevitable arrogance of "The Mainstreamer", in that self-labelled way, I have to regard myself as having been extremely lucky to have had the specific experience I have had!).

Then quite understandably, at a later stage, my increasingly successful predictions of relevant industry events and trends have been offset by my own failed prediction of how soon I would be able to finish the Boot Product on my own.  (And even though for that failure I can at least partly blame the distractions of all these attempts at involving others!)

B, unimpressed:  But three years was a long time to conclude nothing more than that!

C:  No, the exercise has taught me a lot more about the market.  And I was programming too.  

B:  And that prevented you from trying other quarters?

C:  Wait a bit!  All those attempts were public invitations:  I was addressing everyone, including Microsoft!  So maybe also I wasn't trying hard enough, or in the right way?  Certainly, I was doing it in a hard-assed way, liberal with caustic comments on every alternative architecture, then insisting on my own terms and threatening to finish the job myself if nobody was clear-sighted enough to join in.

B:  You could have adapted your approach.

C:  Yes, but there have been supports for that attitude too:  I am reluctant to once again risk setting up and managing a venture with extra staff to whom I could not convey my vision.  Sure, that vision has advanced into a far firmer shape, both conceptually and programmatically, than the previous times [as related here (and find "1988", and also "1990")], but I am still looking for a high degree of understanding of and appreciation for the whole project in all its dimensions.  I have not been willing to spend undue resources on looking for all that, overcoming those obstacles I listed ... and possibly compromising my trade secrets at the same time.

So I have been expecting a possible partner to be willing -- up to a point -- to take a bet upfront.  Without that, I am less sure of my possible partner's appreciation of the vision.  I want to quantify any reassurances in that way.  I have been making that clear on the Web since 1996.[14]  True, as I said in the original 1997 play, "Considering my secrecy, [my gamble that someone might accept the bet] depends -- for long-shot success -- on finding an extraordinarily well-informed and perspicacious gambler, and in general such is not a creature to bet on finding!" So that is why I have not been wishing to move too far away from my option of finishing the job myself.

B:  So then why haven't you finished the job yourself?  If you think you have the right design, appropriately simple -- and you emphasized that! -- then surely it's small enough for one person to program it to the stage you're aiming at?  And if Metaset is so well advanced...?

C, with some surprise:  Yes, sure, it is ... they are ... all that is true.  Despite the obvious reasons not to believe it, such as the one I've already raised, or the inevitable question on the subject after my first paper, which you may see answered as the question 12 reply in my 1996 faq.  [Ignoring the disbelief in the irony and steaming ahead:]  Yes, "right", "simple", and "small enough" ... that's exactly how I've long figured it too.  And I have several times since 1996 tried to finish it.  Last year I even short-circuited a revision cycle by rewriting everything I had.  In several technical respects I really took the bull by the horns, and it's come out almost better than I'd dared.  The elbow of that exponential growth curve is sure going to be sharp!  Everything in the design just keeps getting tighter!

B, almost willing to believe it, after all:  Well ... yes ... that might even be the case too...  [But the scepticism returns:]  So -- again! -- why haven't you "simply" finished it?!

C, slowly:  Maybe ... maybe it's just that after all I'm not -- or no longer -- the programmer I think I used to be?  Certainly, I am not one of those hotshot young programmers I've worked with in the past and been so impressed by!  And I never have been.  Then, working alone as I have been for five years, I continually find my mind wandering off the programming onto all the wonderful things I plan to do with the new market medium.  Hence of course this invitation...

B, half admiring the candour, but definitely still needing to dig:  How sure are you that the job is so small?  Is the rest of the plan clear enough?  Do you really know what you are doing?

C, with a slow but very convincing deliberateness:  Many years ago, and perhaps most strikingly from 1972 to 1976 [more details here (and find "1973")], I have on several occasions been quite involved in system-level programming.  From that date, and with no live help, I analysed extensive source listings of assembler code from the supplier (at the same time observing directly -- and with amazement! -- what one programmer, Harry S.  Pyle, could achieve).  I married the opportunities with the application needs, coded some quite drastic new programs or extensions, and they generally worked exactly as I had imagined, sometimes even first time.  Yes, that was a long time ago [though for a 1991 repeat see also the same document and find "contract"], but I still have a very extensive recollection of the technical details.  I just carry a lot of that kind of thing around in my head, and that includes design reasoning, with its enduser and organization-political aspects too.  Metaset is a mere -- and cumulative! -- extension of such experiences.  True, some of my schemes have never materialized -- and that in itself is a very educative experience! -- but not one of them has been proven irrelevant.  On the contrary, they have all subsequently been shown to have been very far-sighted (including even those I have said nothing about on this Web site).  And all of them find their niches in MACK.

B:  So how much do you think -- realistically! -- is still involved in reaching a launchable Boot Product stage?

C, obviously having amply considered the matter:  I venture this estimate with some confidence:  On the basis of what I've coded already, then with two top-class yet open-minded programmers (the one specialized in WIN32_LEAN_AND_MEAN programming in C, the other with a more wide-ranging technical experience but still a C programmer), with good and committed external management, in an otherwise well-resourced and settled organizational environment, and me available for fulltime design and programming, we could have the Boot Product in Alpha within 3 months.  Then with some help in setting up online service facilities, we could launch within 6 months.

B:  And why would that scheme not be just another one of those that have never materialized?

C:  Because all the currents, of so many kinds, have converged so well!  Maybe this is the time to quote myself from my 1996 faq (as parts of the answer to question 3, "Why all the philosophy?", bold italic in the original).  This summarized one section:

So we have had a long time -- under appropriately varied circumstances -- in which to explore the difficult business and politics of federated activity with end-user control, within and outside the IT domain.  The immediate practical relevance of all this philosophy to IT standards has been very real to me, and should contribute to the present apparent solidity and future real stability of the development.  

Any open-eyed entrepreneur worth his or her salt would bank on that!

This summarized another section:

So the market research and resulting product development behind MACK has extended into surprising domains, and its findings are sufficiently universal to indicate a cast-iron entrepreneurial bet.

Since then (1996), so many more currents have further converged.  And that includes the present programming as well as subsequent public trends, that is, both the supply and the demand.  It is all according to the long-held vision as it has been zeroing in on an ever more detailed and nearby target.  That enormously coherent story so well matches the realities that it has described, explained, successfully predicted, and still aims to influence.  I find it so comprehensively convincing, reassuring, and compelling!

B, with some finality:  Right!  I do too.  Up to a point.  But I am always willing to consider a bet on enormous coherence with reality-matches, even when incomplete.  I can see enough of those in your story, and you didn't try to cover up the gaps in it.  I like the very specific and limited initial objective.  And I can see how the whole thing might well take off exponentially as you expect.

But I did say "consider" your bet, not "accept" it!  So now I want to look more closely at these further aspects of it:  (They are adaptations of the remaining three of my questions from the beginning.)

4. How is anyone going to make any money with Metaset and MACK?  (Free software will always be merely fringe stuff!)
5. How could it fit into a Microsoft software and business strategy?  (And what would your role be?  Frankly, I'm scared of all the ego I've seen today!  And that is despite your various maybe-academic protestations[15] along the usual lines of "the more you know, the more you know you don't know.")
6. What options would such a strategy offer in our discussions with the DoJ?  (And not just "scenarios" please!)

[The other man nods in happy agreement.]

But first, I want to consider more carefully what you've said ... and maybe look up some of your references ...

C:  I second that!

B:  ... and I want some of my people to get into the whole story.

C:  And you will fill them in -- at least briefly -- on the "specifics" of today's discussion?

B:  I'll do my best.  So I suggest we meet again tomorrow?  [The other clearly finds all that most reasonable.]  We'll be too many to fit in here, so let's meet again back on the 20^th.  (And I'll make sure we are not interrupted there!)  [The other nods emphatically.]

But I must also warn you that we are still very far from an acceptable bet.  For example, what are the stakes, more precisely?  And the others might be less tolerant than I have been today...

He exits.  The other looks down, thinking soberly.

Act III, Scene 5.  They are back in the same executive office.  Four others are there too.

B:  Good morning Christopher.  Or is it "Jack"?  [C recognizes his own persona from the 1997 play[16], so is immediately on his guard.]  And thanks for risking it right into the "lair" of "The Sorcerer of Redmond"!  [Smiling broadly:]  Yes, you can see that I had some entertainment last night, carefully reading your 1997 predictions in that play, "How the OMG finds true love".  [He briefly savours how the boot is no longer on the OMG's foot...]

But you can relax!  It's obvious how it was aimed primarily at the usual anti-Microsoft crowd.  And as you've pointed out, the accompanying background document did urge collaboration with Microsoft.  So we've decided to more seriously consider a "side bet", as you called it in this rather casual aside in your OOPSLA'98 paper:

"(Oh, hmmm, yes...  The architecture will also -- almost incidentally -- result in the withering of Microsoft's dominance.  That will be better for our industry and therefore for Microsoft itself:  a safe side bet with a quite plausible and very attractive outcome -- "rather a proportionately smaller slice of a far bigger and safer cake" -- could well be reason enough for them to choose to take part themselves, right away.)"

And by the way, you missed a rather strong argument in favour of your project:  your story has been public since 1996, your development project's roots go back at least to 1987, and despite the notoriously hectic waves of change in our industry, both your technology and your account of it have been extraordinarily constant and unaffected by what seem to it to be mere ripples!  Far from being buffeted, your project has been emerging stronger.  That is clear evidence of some fundamentally accurate marketing ability, or perception of a supply/demand match.  Even better, its explicit foundation on complexity and associated human behaviours has obviously become ever more relevant.  [As invited, C is indeed tempted to relax...]  So we think there are sufficiently solid grounds for some further investigation.  [C does not relax.]

[B turns towards the newcomers:]  Now, please meet Leigh, she's the project leader we would have in mind:  a good listener yet ruthlessly logical and practical ... Tom, he's our top technologist ... Merlin's my marketing magician ... and Al's our admin ace who keeps my feet on the ground:  you know, finance and law.  [They exchange greetings one by one.]  They are each going to give you a hard time.

C:  Fine.  But have they also read up those references?  (Well ... at least some of them.)

B:  I think they've done their best, but have some pity!  Remember, despite some lighter touches (I can see you had a lot of fun writing them!) they are long and heavy ... and the poor folks haven't had the benefit of the evidently later overview you gave me yesterday.

But I did enjoy drawing their attention to your actual predictions of OMG tragedy[17] in that play (since come so true), as well as this paragraph in your background document to it:

"So while I have bet on the JBOF submission among the present BOF submissions,[[18]] 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."

And as you pointed out to me yesterday, there are signs that they are indeed sinking into that quagmire!

C:  Ah, but take care:  as I've said, that quagmire includes your COM and the XML part of it that's threatening you too!  You're only escaping sinking into it because your far tighter organization is more easily able to impose some form on a raft to keep you afloat.  As I said in that same document, my non-MACK money was on you only because "it is precisely Microsoft's single-supplier coherence and hence the relative simplicity of their toolset that are giving them the edge." Technologically, that is a very fragile state of affairs, and I am sure you are very aware of it, even if the DoJ and the rest of the industry tend to see other factors predominating.

B:  Yes, I'm afraid all that is only too true.

C:  Anyway, let's not go over that ground again now, and as you've asked, I'll try to remember to have that pity on your folk when faced by my heavy abstractions.  But then can I also try to keep them to your specific questions of the end of yesterday?

B:  We must all work hard at that together.

T:    But first, maybe I can open with a summary note and related question?  Not having had Bill's advantage, I read all three years of your Web output, and I found it very interesting to follow the evolution of your criticism of the conventional distributed-application paradigm, as you called it yesterday (and which we all still follow these days...).

In 1996 (and its links) you identified the "confusion of algorithm time and real time", in 1997 (both play and paper) it was the "misconception of encapsulation", finally in 1998 it was the "Divine Programmer Syndrome".  Then Bill tells me that yesterday you saw how your development fitted right into that vacuum -- or market need -- in that "black box" of that difficult and untrustworthy Web "application", whether client or server, which is itself progressively taking over from the more low-level RPC-based client-server notion.  Clearly, then, the "application" is still the product of the inescapably non-divine programmer struggling with all those allegedly well-encapsulated "island classes" or supposed "pills of wisdom", and increasingly failing to give the combination the desired always-sensible hence trustworthy behaviour.

So you spoke further of providing an actual mechanism which "orchestrates components and choreographs interactions", effectively reconstituting both "algorithm time and real time", and especially real time, giving snappy spontaneity yet well-supported workflow.  Now that is one helluva consistent story, and some enormous closure!  So, well done!

[At least one listener is genuinely impressed and delighted by that evidence of hard reading, clear insight and synthetic ability, while the others more-or-less, in their various ways, make as if they have followed it all too.]

C, still smiling:  But now I must congratulate you:  that phrase 'supposed "pills of wisdom"' -- which is your's, not mine -- beautifully captures that point and fits in perfectly!  So obviously your own understanding of the whole scene must be very thorough, enabling such creativity already.  [More reflectively, enjoying the new metaphor:]  Yes, "supposed" pills of wisdom but generally oversimplified, cut down to the size of the increasingly inadequate human programmer's mind.  And your "snappy spontaneity yet well-supported workflow" is its own concise requirement spec!

T, having enjoyed his turn for modest basking:  But there's still my question!  Why didn't you put the whole story together right at the beginning, in 1996, all nicely sewn up like that?  Why are we only getting it all now?

C:  Very fair question!  Well, evidently I was still trying to formulate it.  As you will have noticed, in 1996 and 1997 I was focusing on the Classical Object Model, but I mentioned it yesterday only in the context of the OMG's disastrous efforts, and that only in a footnote.  Despite the validity of the criticism, it was an unfortunate focus, as the only commonly-known alternative with which I could contrast it, namely the Generalized Object Model (or "Generic Function Model" as Andrew Watson of the OMG kept insisting on labelling it in our e-mail debate on the matter), is not the real issue either.  And however much I insisted that MACK was so different also from any generally-known Generalized/Generic approach, the point still couldn't get through.  It was only in my 1998 paper that I emphasized MACK's relativity more strongly in contrast to the Divine Programmer Syndrome and its Newtonian outlook, and as we saw, it is of course relativity that enables the grasping of the application-complexity nettle.

After all, criticism of the alternative architectures was not my prime theme.  I'm sure you also picked up my continual invocations of what I call "Medawar's Dictum", namely "Theories are not displaced by facts, they are replaced by better theories."  So "displacement" has never been the main objective.  That's just not realistic.  And it wasn't where the whole thing came from, either.  Historically, Metaset was being developed for some specific and still very constant purposes, and out of it boiled its essence, the architecture "replacement", MACK.  The functionality was always the focus, and I've had it pretty clearly in my own mind all along (especially since 1995, as I related last year).  But the contrast with the alternative architecture (then entirely based on RPC, of which I was totally unaware when we started in 1987) was still very much out of focus.  Meanwhile, I was trying to concentrate on my invitations to entrepreneurs to join the "replacement" bandwagon-to-be.

Odd though it may seem from many of my clichés, I am really a practical guy.  I've been trying rather to say to everybody, "Hey, come and look at this fine concept!" rather than "Hey, come and listen to all this criticism of bad concepts!" But of course, both trade-secret and incomplete programming are some major obstacles there.  So my criticism has come across as destructive rather than constructive.

So, yes, I have seriously misjudged what I thought might be some significant receptivity -- out there in the market -- to big abstract pictures, unusual as they are and out-of-focus as much of the argument has been.  There has evidently been some receptivity, and quite gratifyingly so, but not to the extent of making it to the attention of someone with knowledge, foresight and money!

B:  And a gambling spirit, as you said yesterday in no uncertain terms!

A, suddenly recognizing his domain:  And an ability to carry it through, concretely!

C:  It surely goes without saying that any entrepreneur has to have both of those.  But both comments nicely return us to Bill's first remaining question as he rephrased them at the end of yesterday:  the one about making money.

M, interrupting quickly:  Sorry!  First it's my turn for a global comment and question:  You had a lot to say about BackOffice, but you didn't mention FrontOffice at all, that is, our "Microsoft Office".  Now as you know, it is absolutely central to Microsoft's entire strategy.  Quite apart from its major contribution to our profits, it is our own main rampart in that "applications barrier to entry" of Judge Jackson.  I just cannot see how your story ... your scenario ... your crazy hypothesis ... would fit in there.

B, firmly:  I'll answer that one.  It is perfectly obvious from his whole story, to me yesterday and in all his Web references, as well as from our own existing directions, that Office just has to be integrated with some new-generation browser+shell.  (And even though that flies in the face of some of the proposed antitrust remedies...)

C, delighted:  Yes!  But Merlin, you obviously didn't spot a certain piece in my 1997 paper [under here, as part of the functionality of "the initial product" (The paper, by the way, was entitled "Beyond Business Objects")], so if you don't mind I'll repeat it:

• Another natural consequence of the basic way of working is "office suite" functionality in such areas as document-processing and spreadsheeting, though in such a special and semantically-integrated way that the prefix "beyond-" may most emphatically be applied here too.  For example, in an integrated application environment a "document" or a "spreadsheet" -- to help avoid both great cognitive dissonance and just plain error -- is easily tied semantically to the contexts of both creator and intended users.  That is not just as a whole document or spreadsheet, but downwards with multi-leveled component granularity, and outwards in a distributed fashion too.  Such -- as ever -- is MACK's delight (in a great contrast with, for example, html as well).
• Old-fashioned functions such as screen design and report generation have simply merged into the above.  Health and logic rule, as usual with MACK (i.e. relevance and respect of known constraints come first), but beauty is not neglected as cosmetics may be added afterwards.  

B:  There can be no question of any of that.  XML is already helping us move in that direction.  But we are still so far from it!  And I sense that we're bumping into that complexity thing everywhere.  So this "Metaset" story fits in there, "full, square, and plumb in the middle", as he said he addressed that mainstream.

You might have read about those "agates" he referred us to:  those specialized or niche-wise and precompiled market agents.  Well, there'll be agates with varying degrees of functionality, covering the whole lot, from IE and FrontPage and Word through PowerPoint and Excel to Outlook, while Access and SQL Server and Exchange and all the others are already implicit.  You'll mix and match, in small pieces of functionality, dynamically, depending on your own capabilities and needs.  And of course it'll be easy, and far more tailorable, and they'll all interoperate much better than now.  You can even have them all together, plus more.  (Even though you'll usually knit a more comfortable subset for yourself...)  And technically all that's no problem, even for the dummies, as it'll be spontaneous, and at their own individual levels.

[All the others are watching, open-mouthed.  The speaker merely grows more emphatic:]

Can't you see that?  That direction is already implicit in absolutely everything we're doing.  Only we've not made significant progress for years.  We still have those enormous programs, with so much duplicated functionality and yet with annoyingly nonsensical differences.  And whenever we rationalize a bit we get customers complaining about the clunkiness of the result.  I like the diagnosis that we have a basic structural or architectural problem.  And I like his Medawar's Dictum:  he could well have a "replacement"!  [But he sees he has to address their various disbeliefs:]  Sure!  I'm making major assumptions.  I'm assuming his story is true.  But it has the coverage and the coherence.  It's up to all of you to find the holes...

M, spluttering:  I can't believe it!  Bill!  What's happened to you?  Can't you see yourself?  You're behaving like a puppet on this guy's strings!  I would never have thought I'd ever see any such...

T, breaking in again:  Sorry folks, I've got to come in again.  Merl, make that two puppets.  I am the one who carries the can for the technical management and evolution of all our products.  As you know, I was an IBMer long ago, and I don't want another dinosaur of a product range.  I am always on the lookout for ways of revamping ours.  We want new generations.  We did it with NT, and it's just great how 16-bit is headed for a natural extinction.

Now, on the other hand, we're wrestling with exactly what he was talking about:  the repository/database scene which is definitely very far from being integrated invisibly in our applications, whether to developer or user.  Registry, Repository, Relational DB, blobs, hypercubes, Excel files, legacy data, and now Installer Database and Active Directory too!  What a nightmare!  Inevitably data and metadata need to be integrated.  That reflectivity he was always talking about -- and which sounds so right! -- means layer upon layer of metadata, so you cannot separate the data out:  each meta layer is data for its own metalayer.

Then we may like to believe that we've got all that nicely separated out into the lower tier of DNA, but then what are we doing with that succession of data-related acronyms?  And recent technical articles with headings like "Porting DAO Code to ADO"?  Can we pretend it'll be the last port?  And why is our OLAP metadata in SQL Server and not in the Registry or Repository or Directory?  Why have we been treading clay with Active Directory?  We're being pushed into interoperation and integration, so it can only get worse.  Who do we think we're fooling?  It can't all be hidden in nicely-tiered APIs:  the real application interdependencies just keep on growing!  So we're time and again consciously sacrificing quality so that we can get some kind of product out the door.

And do you know what the nub of the problem is?  I can see it now, from his criticism of the conventional "thin-coupling" RPC paradigm and the XML-invited opportunity for fuller semantics:  it's that so much system-wide yet program-critical semantics is hidden in the database, and it's all over that goddamned mixed-up database.  We've already got so much "fat coupling" but we don't even want to see it, let alone admit it!  Who are we trying to kid with COM and thin coupling?  So can you see now how our programs are semantic spaghetti?  And those of our entire developer community and customer base too.  And yet as Bill has just said, "Office just has to be integrated with some new-generation browser+shell." How are we going untangle all that stuff?  Look how much untangling Y2K took ... and it's basically such a simple problem!  No, "spaghetti" is not the right word for all those applications ... "wire"? ... "girders"?

Do you think it's possible to do all that re-choreographing with tangled iron and steel?  (And can we do it with XML?  It just doesn't come near the problem.  Its document-centric model even insists it shouldn't try.)  I see our entire existing "applications barrier to entry" just collapsing in a great big ugly heap!  Developers will just go some place else.  We've been trying to do exactly what he has been doing:  the invisible builtin repository/database.  And we're getting further from it, rather than nearer.

Can't you see where that MACK "thick coupling" takes us?  It's unstoppable!  The messages and the database can't have different forms ...  [Suddenly turning to C:]  Hey, I'll bet MACK messages are structured like databases?  [C agrees enthusiastically.]  Yes!  And of course -- unlike XML -- they're "pre-digested", with most references already resolved.  (That's of course why he can't show "MACK code" to us very easily.)  They have to be maximally linked-in, since they're so rich in semantics.  That's what makes it possible to talk about "market-driven spontaneous creativity"!  [To the others:]  Can't you see it?  As the message arrives there's an easy and fast match because of the already-established common knowledge, and -- whether it's a "mere" query or a new version upgrade -- there's a creative new marrying of contexts.  [To C:]  So you can see I've also read Koestler![19]  And clearly, MACK has to have a very rich session concept.  But the more managed relationships you mentioned can take that in their stride?  [C is stll agreeing, but resists the temptation to qualify and expand.]  As you say, that's the deep yet creative matching of supply and demand!  [M turns back to the others:]  And I can't see any holes in those parts of the story.  It just makes so much sense.  It really will seem so mainstream.

[His boss just nods slowly.  His other two male colleagues are dumb-struck.  L, also experienced in application design and implementation, is nodding too.]

C, ignoring those reactions:  Yes.  Mainstream.  That's exactly what I've been saying for a long time:  people will want to know why it hasn't always been like this.

M, his glare flashing from Tom to Bill and back again:  Okay, wise guys, now I can't wait to see how he answers Bill's first question.

C:  Sure.  The question ...

B:  Sorry, another interruption!  [Firmly once more:]  Merl, you've just got to get this straight.  You may think that Tom and I are puppets, but wasn't it clear from our own words that we're dancing to our own long-played -- and single -- tune?  I can see that Leigh knows and likes it too.  You can see that we all know that we've not got that tune quite right yet, but it clearly exists and we've long been trying hard to work on it.  So it looks like you're the one we've got to get on board.  This is not a game of product-lists and veils and appearances.  It's a playing-out of inner substance.  Office and browser and shell will be one, with an integrated database, all manageable thanks to clear semantics and the whole market's contributions.  Christopher, you were about to say?

C:  Right.  The question was:

Yes, each of you will have an own angle on that one ...

B:  No!  You can cut it there.  Unless you're wanting to add to what you said in your OOPSLA'98 paper?

C:  No.  I've nothing to add to that.  The many finer details, such as the ease of the option of auditable and trustable microbilling, easily fit within the managed framework that was implicit there.

B:  Good.  If any of you haven't read it yet, it was all in his Part 2 of that paper.  He even had a section on it, headed "Commercial incentives for developers in the MackWeb".  And yes, it does fit in with everything he has said to us.  It really comes down to this:  the market is the throbbing heart of it all!  Can you think of anything more Microsoft-Mainstream than that?

A lot of conventional coding will still fit into his "RE-method" concept [as described earlier in that Part 2 and alluded to yesterday] and be sold as usual, though in a far more integrated and manageable way, considering the integrated market infrastructure.  Maybe I can just add that those "agates" very much fit the packaged-Linux model as from Red Hat and the others.

M:    But that's no good at all!  How much can we charge for that kind of thing?  And how do we maintain that "applications barrier to entry"?

T:    Those two questions boil down to the same thing ... and the answer is once again in those managed relationships I've already mentioned, only this time at the level of reality too.  We are virtually going to formalize that enormous though presently implicit relationship we have with every single user of Windows and Office out there, and help them move forward from where they are, first migrating to our new architecture and then growing from there.

A:    Yes!  I can already see that contract.  We'll just take our ...

T:    Oh hell no, Al, no you won't!  It won't be a dead legal document.  It'll be a living thing, market-driven, managed using the networked system.  It'll be a mere part of that closer or "fuller" relationship between supply and demand -- mediated by that thick coupling -- which is the logical outcome of the properly-networked semantics-based market.  Then with the more easily-richer feedback it is also the basis of every next generation or at least version-cycle of product and service.  What a resource to build on!

All our people out there will just adapt to it.  They'll have to.  No!  ... they'll want to.  They'll see it as an easy opportunity for far greater job satisfaction.  Did you notice that concept of "profound congeniality" scattered about his past papers, relating to the enduser-ModelledWorld relationship?  Well, the supplier-customer relationship is obviously part of that too.  Proper one-on-one marketing will at last be possible, corresponding to that Common Knowledge but creatively building on it, and it'll be up to us to maintain our lead, whether with agates or with those conventionally-coded true application-niche "RE-methods" that we're already at home with, or -- above all -- with the real professional-partnership services that are intrinsic to such relationships.

B:  But we'll have to move quickly otherwise someone else will grab the opportunity!  Christopher, I think we've largely covered my next question too, which was:

So we can just get on with the next one.

C:  No, there is still the sub-question to your question, as to what my role would be in that strategy.

A:    Yes, you can expect some very hard negotiations there!  For example, I would insist on ...

C:  No, Al, as far as I personally am concerned, there would be none at all beyond my very standard temporary programming role with you, on a monthly basis.  As far as the capital side is concerned, it is also very simple from my point of view:  for the upfront lumpsum just mentioned I hand over everything I've got, code and documentation, in straight exchange, with no further conditions either way.

A:    But we must tie down what we would get.

L:    Al, I'd like to answer that one.  You have seen how the main point is a top-down one, almost "from first principles".  He has been able to formulate it that way because he has built up towards it from a technical basis.  He has told us clearly enough that the process is not complete, but Bill and Tom and I can all see the full picture in sufficient detail for us not to worry too much that it might not be completable.  We can see that his "trade secret" metadata should exist, on account of the intuitive match with the very natural realities of conceptualization itself.  We can trust him there.  [Two quick glances satisfy her that she is speaking for them too.]

As far as the programming itself is concerned, I've been a programmer and application designer for long enough to know that my programmers will most likely recode almost everything he has already done.  (And pretty smartly too!)  So let's just face such programmer realities, and follow the consequences.  He is right:  any attempted legal specification would serve no purpose at all.

C:  Thank you Leigh.  I can see we'll be able to work together well.  But I think I've got some neat code there, so I hope you'll also let me try to sell the others on it!  [She smiles in agreement.]  Good.

A, horrified:  But what code would you give away at that point:  What you came to us with?  Or what we have jointly developed?

T:    Al, it's obvious you still haven't got it:  it's got to be the latest stuff!  He would have the current picture in his mind anyway, and there's no way anyone could separate out his contributions from ours'.  (Gee, I myself sure want to sit in on the initial technical sessions with him!)  Then just take a closer look at the position at any such hypothetical point.  Firstly, we must assume that we have a viable position, otherwise the problem doesn't exist anyway.  Secondly, we would be thinking that our position is radically better than his.  Or else that he is impossible to work with, or screwing up in some other way.  So what picture would he put in the public domain?  His own, of course, as at that time!  And there we have a normal competitive situation that I can confidently live with.

B:  Hey, Tom, I can see you're the one for further negotiations with Klein!  But Al, let's also see it from Christopher's point of view.  He has his strategic objective:  that much better market and medium.  He's been very open and eventually even clear about it at that level.  There's no other way he can believe he's on the shortest route towards it.  So we must just take that as part of the bargain.  And his short-term objective coincides completely with ours, as we've seen amply enough.  That is our very fitting protection.

T:    Yes, that's the point I was getting to.  (And I'm not sure Klein would believe his ears if he heard you there!)

C:  Right, that's me taken care of.  But what about the more public situation?  We can now get on with Bill's final question from yesterday:

[C turns to address the audience:]

What is more open is what the options are if Microsoft does not take up my bet.

There is in fact little option.  Either Plan C proceeds (i.e. my solo programming continues until some more developed stage, when the whole matter would be easier to raise again).  Or somebody else could initiate a Plan B or a Plan A.  I think that a Microsoft-owned Plan B, as foreseen above, would quite likely be the best for the quickest spread of MACK and the resultant establishment of the market medium that I have been aiming for.  But not everybody in the industry would agree.  So any of you may express yourself or yourselves in the substantial way that Plan A or Plan B invites.

Only you might be well advised to do so quickly, for even if Microsoft does not take up the offer, they might still use the plausibility of something like MACK to illustrate to the DoJ how monopoly fears may easily be exaggerated.  (They might, for example, take up this point.)

So, perversely, MACK might simply have to be supported by someone soon, otherwise Microsoft might merely get stronger.  As Judge Jackson in his ignorance of MACK has most correctly concluded, there is at present no alternative prospect of real relief for everyone else, relief that is stably founded on software realities.  Instead, the only remedies currently mooted seem either rather precariously perched on legal artificialities, or unduly draconian in unconstructive ways.

And the author's ego in that attitude should also evaporate, as already indicated, once it would no longer be required...  And that happy stage will come more easily if you sooner started playing your own role in the correcting and making of the future as provisionally depicted here.

[Happy Ending X:]

L, after a quick glance to each of the others in turn:  Good.  Okay, Christopher, can we get on with the job now please, while we leave the others to tidy up those loose ends?

C:  Great!  Okay, Leigh, let's get started.  And I'm sure you'll remember that we won't be able to get very far until Al has my banking details and used them in the obvious way.  Less urgently, Al, please would you also send me your standard monthly project-programmer contract with a dollar figure filled in already?  (Minus the Microsoft copyright- or other IP-ownership part, as we've agreed, of course.)  Oh, and don't forget an ample budget for travel expenses to Redmond (or wherever else you decide) for me and my family, including for final return to Cape Town after Boot launch.

[Happy Ending Y:]

The same as the above, with "you" in the place of "Leigh", for a comparable Plan B, mutatis mutandis, or a Plan A, mutatis mutandis even more easily.

Endnotes

[1]  ... which "would make it prohibitively expensive for a new Intel-compatible operating system to attract enough developers and consumers to become a viable alternative to a dominant incumbent in less than a few years." (From Judge Jackson's Findings of Fact, paragraph 31).

[2]  Registered trademark of Metaset Close Corporation, the sole property of the author and his family.

[3]  That is an increasingly mainstream diagnosis:  by now, when high-profile gurus pronounce on any big problem in the real world out there, they tend to reduce it to the intractability of complexity.  Of course, when they do, it usually doesn't help.  But sometimes it does, as it has at least got the context right at about the highest level that we can get it.

There is a further point to the diagnosis here.  There is a very specific set of behavioural or cognitive problems that manifest themselves when the complexity of the situation begins to overwhelm us.  In my various web papers referred-to here those problems are categorized in terms of the metaphor -- from Homer's Odyssey -- of Scylla and Charybdis, respectively the many-headed monster and the whirlpool, between which we must chart our course.  Thus Charybdis, the disorientating whirlpool of complex reality, brings perplexity, while Scylla, the many forms of oversimplification that we cannot help making of that reality, brings tragedy.  It is possible to make an extremely detailed interpretation of the allegory, and -- far more interestingly! -- that includes generic recommendations as to how to deal with the twin problems.

I spare you the detail here, but I do recommend looking into it by starting here in my OOPSLA'98 paper (then find "Scylla" and follow the links).

The point here is that the present situation in the software world is so full of aberrations that so well fit the Homeric diagnosis that we can be sure that unmanageable complexity is indeed the crux of the problem.  We may then also be sure that we may usefully follow the Homeric advice in avoiding the common pitfalls.  And such advice may even be cast in MACK-conformant form, in the generic way we shall soon encounter below.

Of more immediate significance, my own successful predictions are largely thanks to the Scylla and Charybdis typology of conceptual aberrations, while the MACK recommendations are fully consistent with the Homeric advice.  The above references describe various aspects of my debt to Homer.

[4]  Though you can find some of it in its historical context here if you really want it.

[5]  That is, education in the communicable self-knowledge sense as well as in the commodity sense.

[6]  That was mentioned in the Background, and spelled out in some detail here in the author's OOPSLA'98 paper.  Events since then have further corroborated that line of criticism.

[7]  SOAP is Microsoft's proposal to the IETF for a Simple Object Access Protocol.

[8]  See for example the concept of the "Conversational Service Transaction" in the paper by Dan and Parr at the OOPSLA'97 Business Object Workshop III, as most approvingly commented on in my already-cited reflections (and find "Parr" there for the two relevant paragraphs).  See also the highly-relevant focus on the contract in the paper by Marshall, Organization in a Chaotic World, at the OOPSLA'98 Business Object Workshop IV, and his follow-up at the OOPSLA'99 Business Object Workshop.  

[9]  That was thanks to the special theme proposed by Jeff Sutherland for the 1998 instance of the Business Object Workshop series for which he is responsible (and at which my own cited papers were presented).  See also his own paper at that Workshop, and his slides for it.

[10]  Under the heading:  "2.1. Definition of Agent".

[11]  I must thank Jeff Sutherland for his Object Technology Web Site pointers to the OMG work on agents.

[12]  The "design patterns" continually referred-to are at a quite different level from, for example, the classic GOF book's kind (i.e. Gamma, Helm, Johnson, Vlissides).

[13]  The RFP is for an "Encapsulated Relationships" service.  The virtual contradiction in the title betrays the basic problem of the "island classes" of the Classical Object Model (It was Booch's observation that "No class is an island" which led to the quoted phrase, as may be seen at this url).  The RFP should be thrown out as it is mere tinkering with two very fundamental oversimplifications:  the incorrect initial segmentation of functionality in terms of Classical classes, and the problem of the non-divine programmer, which is that all those relationships have become just too much for one mind (or a conventionally-managed team) to handle anyway.  The nettle of complexity must be properly grasped, and only MACK's relativity on the basis of its cumulative-wisdom metadata makes that possible.

[14]  Find "gamble" in my OOPSLA'96 paper and particularly its faq.  Then find "strategy" in my Introduction to my comments on the other OOPSLA'96 Business Object Workshop papers.

[15]  In this document, here and here.

[16]  Cited here in the introduction.

[17]  Find "trag" in the play for the four occurrences of "tragedy" or "tragic", and especially the last one!

[18]  "BOF" is the Business Object Facility which was the subject of the OMG's RFP, "JBOF" was a joint submission in response to it.

[19]  Arthur Koestler, The Act of Creation, Hutchinson, 1964.  See further here (and find "Koestler").

[20]  The title was "Beyond Apartheid".  See for example here in my OOPSLA'96 faq, or here in my resume for how predictions of that book have come true too.

[21]  See for example here in Part 1 of my 1998 paper.

[22]  (That only becomes clear from the text of the paper when I point out that it was originally written in the ABC order of Plans, and not in the CBA order in which I later put it, forgetting to modify the Plan B wording at the same time.)