1. A Win-Win scenario could really torpedo open standards
"HTTP-DAV. DAV is complex and the protocol spec provides an infinite level
of implementation complexity for various applications (e.g. the design for
Exchange over DAV is good but certainly not the single obvious design).
Apache will be hard pressed to pick and choose the correct first areas of
DAV to implement."
That is, a Windows client-Windows server pair offering binary "enhanced"
modes. Worse yet, ramming everything through an increasingly complexicated
HTTP-DAV (email? news? directories? WBEM? printing? it's all DAV!).
Actually, it's telling that they even think of it as HTTP-DAV, some
conglomerate beast at the server level (rather than, say, DAVable resource,
viewing DAV as a wrapper for isolated chunks of existing webspace). This
lends credence to the tone of HTTP-DAV as a 'filesystem-like' piece of
infrastructure.
You know, it's interesting to sit here and rail against the sort of
integration I hope a *TP could achieve. But when I think of merging the
classical TPs, it's through simplification: coming up with the minimal
interoperable envelope format and using Mandatory and MIME to add back in
specific semantics. In other words, I'm studying the *intersection*. My fea=
r
is that MS could end up pursuing the *union*: support all kinds of
traditional traffic in a new binary WindowsTP as an enum. It's only a matte=
r
of code complexity, and what does that matter? Furthermore, the
"integration" is only developer-visible through APIs: do mail, news, word
docs all look the same from a Storage+ perspective (rather than the wire:
MSDN filk never *see* the wire, so what do they care if an MS*TP munges the
wire? Or it's all rammed through an OORPC like DCOM or HTTP-NG?
2. Can OSS really innovate?
"When describing this problem to JimAll, he provided the perfect analogy of
=B3chasing tail lights=B2. The easiest way to get coordinated behavior from a
large, semi-organized mob is to point them at a known target. Having the
taillights provides concreteness to a fuzzy vision. In such situations,
having a taillight to follow is a proxy for having strong central
leadership."
"Of course, once this implicit organizing principle is no longer available
(once a project has achieved =B3parity=B2 with the state-of-the-art), the level
of management necessary to push towards new frontiers becomes massive."
Jim Allchin is a smart guy. This is the fundamental barrier I see to OSS: i=
t
can't do new stuff. Sure, you could get people to write a clone of 1-2-3 --
but could anarchy create Improv? abiSource is tracking Word; some group of
mathematicians could even choose to take on Wolfram Research. There are no
shortage of ideas to follow for a long time to come (q: how long before
someone had proposed a Sherlock-like tool for Linux?) But where will the
world get truly new ideas? Where, also, will the really hard work get done,
like the grind which goes into a speech recognition system (do we all
implicitly expect DARPA to fund the OSS bits no lone volunteer can?)
XML is a fine example of *directed* evolution, at the outer envelope of
multilateral developments' powers. That's still a long way from innovation
in an absolute sense. SGML, DSSL, and HyTime all provided scales to measure
against.
Not that Microsoft is the place I look for radical innovation, mind you!
But, there are bits of innovation that require more than tinkering on
individual modules; heck, some kinds of innovation like the iMac aren't eve=
n
software alone...
Tired & going to bed,
Rohit