I came across Richard Monson-Haefel’s blog today and I am impressed.  Its the first blog I have seen that opens the kimono about the working life of an industry analyst at one of the major firms, in this case, Burton Group. How…

Today Teressa Jiminez commented on my blog, something I really wish IBM staffers would do more often. So Teressa, I salute you: welcome to the ranks of the monkchips mega value readers! It turns out someone else recommended IBM pick up the…

The Redmonkers are big fans of Adobe’s Duane Nickull and his “cosmic genius”, so its pleasing to know that he has finally joined the conversation, here. [For those of you that don’t know already, Adobe also has some pretty nifty developer…

The same thing happens all over. For example, supporting multiple platforms for your product is a great marketing story, and architecturally feasible, but it generally comes at a performance and development complexity cost. That performance overhead of XML, for example, is quite steep (about 10x) compared with a custom format. Is that a devil’s bargain? Some say so, and this is a hot topic these days (Shameless pitch - I’m chairing a panel discussion on Efficient XML at the XML 2005 conference).

From my tiny little corner of the empire, it looks like the real strategy is to support both tight and loose coupling scenarios. Those who are need the vendor/platform/version/etc. neutrality can use the XML, HTTP, web services, etc. technology in which MS invests heavilty. Those who don’t need it don’t have the pay the performance/complexity price of all that Open Internet API stuff, but of course have a more expensive migration path if they decide to abandon the fold. Ya architects yer software and ya takes yer choice, MS will be very happy to sell the infastructure for either.

that said, it’s my contention that the “Integrated Innovation” approach that is core to MS’s approach brings with it certain risks not inherent to other systems, simply b/c tight couplings almost invariably introduce additional security risks.

in other words, you can and have gotten better, but the approach itself introduces risks.

Fair enough. I think (or at leat hope) than no one still employed here would think that the decisions made in the mid-’90s were correct from a security viewpoint. I’d caution, however, against assuming that Microsoft hasn’t learned these lessons extremely well.

as an aside, you’re one of the individuals i had in mind when i was referring to the respectful discourse we’ve had in this space, and this post keeps that trend in line so thank you.

anyhow, good points all around, but as you might expect we disagree in a few areas
“Uhh, I believe Chairman Bill figured that out about 10 years ago and announced it to the world on December 7 1995.”

i’m not sure i agree with this. it could be argued, i think, that one of the reasons that Ajax was not pushed actively by Microsoft given its early lead in the space was the fact that it undermined the Windows API in favor of a thin client, web services based approach. while MS has definitely “gotten” the internet and done an admirable job of realigning the business around it, i think it’s a fair statement that much of MS’s behavior is about fiercely protecting the Windows platform from more heterogeneous alternatives. not that i’d expect MS to do anything differently, as you’ve made a bit of money in that area :), but it’s not the same as targeting the “open internet” that Gary refers to.

“My sense is that the Open Internet API is *not* what mainstream developers write to.”

if you’re referring to the Open Internet API as a single specification, i agree. but while i won’t speak for Gary here, i believe the Open Internet API to instead be a collection of open interfaces that leverage the existing infrastructure of the web. in James Snell terms, it’s chmod 777 web.

“The unseen barrier IMHO is the immense complexity of the “Open Internet” ecosystem — not the APIs, formats and protocols themselves, but the way they interact in ways that few really understand, the way they offer their power to the various vandals and scammers who pervert their potential, and so on.”

the complexity and security concerns, i think, are fair pushback on a set of wildly proliferating interoperability options. i tend to believe that will be self-correcting at some point, but there’s some truth in that statement.

“The common thread running through what most of us do (at MS, everywhere else I’ve worked in the last 10 years or so, and from what I see at most commercial software companies and open source projects) is to provide a level of convenience and security on top of that ecosystem that ordinary people can use to do real work. That creates a tradeoff for end users, to be sure — some narrowing of options in return for comfort and convenience. That’s true for commercial and F/OSS software - projects as well as products can become overhyped and sweep the herd toward a cliff.”

given that i’ve been fairly critical of “Integrated Innovation” in the past, it shouldn’t be a suprise to hear that i don’t buy this. i’ve been listening to the “integration as a means of simplifying things for customers” arguments for a long time, and while i think there are certainly instances where this is true, i think it obscures the fact that it actually introduces complexity (via unanticipated dependencies) and, in many cases, creates lock-in. again, these are at least marginally justifiable business decisions, but not ones that i think can be universally portrayed as serving customers. i’d caution against using security as an example, as well - i don’t think it’s viable to argue that integrating IE into Windows was a good security decision.

so while i understand the point - and certainly think there are instances where its true - on the whole, i don’t buy it.

“So, success will go to those who offer the most real value on top of the Open Internet, and those who help it evolve as new possibilities emerge.”

surprise we’re in total agreement here.

“Even though the great herd of Windows users remains tethered to Microsoft, it is the Open Internet API that developers write too. Sure you can cloak the Open Internet in .NET and MS XML garb, but they are always dancing around something owned by none, used by all. ”

My sense is that the Open Internet API is *not* what mainstream developers write to. If people did write to the lowest-level open APIs rather than to APIs like XmlHttpRequest, why didn’t the “AJAX revolution” occur years ago? It wasnt’ until convenient APIs for HTTP, DOM *extensions* that minimize the pain of raw XML, etc. became de-facto standardized and ubiquitous that “Web 2.0″ took off, even though the fundamental levels of the stack have been around much longer.

“Microsoft’s strategy is one of deception. They hope to erect unseen barriers in hopes that by the time the great herd realizes they’re trapped, it will be to late to route around the problem.” Astonishingly enough that’s not the way I see it The unseen barrier IMHO is the immense complexity of the “Open Internet” ecosystem — not the APIs, formats and protocols themselves, but the way they interact in ways that few really understand, the way they offer their power to the various vandals and scammers who pervert their potential, and so on.

The common thread running through what most of us do (at MS, everywhere else I’ve worked in the last 10 years or so, and from what I see at most commercial software companies and open source projects) is to provide a level of convenience and security on top of that ecosystem that ordinary people can use to do real work. That creates a tradeoff for end users, to be sure — some narrowing of options in return for comfort and convenience. That’s true for commercial and F/OSS software - projects as well as products can become overhyped and sweep the herd toward a cliff.

So, success will go to those who offer the most real value on top of the Open Internet, and those who help it evolve as new possibilities emerge. That’s what I see people doing at Microsoft, and I’m sure that’s the attitude at other places that are really helping the Web and related ecosystems evolve.