where we definitely align is that different customers have different needs and priorities. what i'm interested in seeing is, longer term, whose more effective at meeting the variety of needs. should be fun to watch.

James: short served the both of us link-wise, i guess thx for the correction.

Jason: great post, many thx for the link. Wonder Twin powers indeed

monkchips on interdependency management http://www.redmonk.com/jgovernor/archives/000945….

frankly tecosystems should also have linked to itself – your post on interdependency management
http://www.redmonk.com/sogrady/archives/000880.ht…

There's a cost to be paid for this. With a Mac, it's a simple dollar cost of having one supplier with no competition for most addons. Ironically Apple itself learned this lesson when IBM couldn't / wouldn't meet its processor requirements. For Microsoft, and I presume Apple, there's also an agility cost — depending on the cool features of some custom component means you're tied to their development schedule, and you slip when they slip. For a big product such as VS or SQL Server 2005, obviously all those little slips added up.

I'm not sure whether the loose coupling cure is worse than the disease or not. My first impression of MS was that they needed to eat a LOT of that tasty loose coupling dogfood they sell. I'm not so sure now … ultimately the products will be judged by their quality, reliability, performance, etc. not when they shipped or whether their internal interfaces used open standards or not. Tight coupling offers various benefits to offset the drawbacks, including performance (standard interfaces are generally more abstract and the mapping back to the application layer typically consumes cycles), security (tight coupling can reduce the surface area exposed to attack from the outside), and so on.

An OSS project has fewer alternatives to loose coupling than a big company does, if only because there's nobody in charge to wield the club to force SOME decision to be made. I guess they have to make a virtue of necessity. I don't have much first hand experience with open source projects, but open standards projects almost inevitably tend toward the some common denominator abstraction whenever things get controversial. That's probably a long-term evolutionary strength (keeping things simple and standard), but a short-term competitive weakness if your customers have more tightly integrated alternatives. Think of the relative market success of the X11 loosely coupled GUIs and the Mac and Windows tightly coupled ones. In other words, when asked to "trade customer convenience for the inability to substitute alternative components and product cycle time", customers tend to vote for convenience today rather than alternatives tomorrow.

So, like almost everything, there's no clear answer IMHO. The penduluum has swung away from tight coupling over the last 10 years, and it should probably keep swinging that way some more inside MS, but I see signs that it is swinging back as people start to complain about the performance and security cost of, for example, the Web / XML interfaces. One little data point – "binary XML" was once considered almost an oxymoron, now W3C is being driven to define a standard for it because of performance concerns. [For the record, MS is on the side of the loosely coupled angels on this particular matter and opposes this effort ... ]

The way I suspect it will end up is that code will become increasingly tightly coupled because it is just SO HARD to come up with clean, well-implemented, standard interfaces between independently evolving components. Competitive pressures of one sort or another will reward those who make it work better over those who make it work the same. Data on the other hand will become increasingly loosely coupled and hence usable and reusable across products and platforms, because nobody cares how "good" your data is if they can't use it.