(No Title)
WinFS Axed from Longhorn Client, Server
Let me preface this by saying that I am now a Linux enthusiast, not a Linux advocate. I do not believe that Linux should replace Windows on “The Desktop” as of now (I capitalize because this term is important in Linux/Windows Holy War circles).
This story seems to highlight the biggest problem with Microsoft’s model for innovation. The corporate model is great: acquire and develop technologies that seem profitable and marketable, port them to a ubiquitous and arguably quite good user interface model, and then package or sell the technology to a market saturated with demand for a “friendly” version of the product.
However, I believe the problem with Microsoft’s capacity to innovate lies in a two-forked market situation, the two inhibitors being the average semi-incompetant business/home computer user and the reactionary OEM.
I’m reading Linux advocates writing with the classic I-don’t-see-why-this-is-taking-Microsoft-so-long-because-my-operating-system-had-this-several-years-ago argument. In light of this legitimate question, I have a hypothetical (very fictional) headline:
New WinFS File System in Longhorn Renders All COBOL Applications Obsolete
What would a Linux user say if this was a Linux-related headline (beyond that COBOL sucks and that no applications should be written in it anyway)? They would probably start porting all their COBOL applications to C++ or perhaps python or java. This would be an easy task because there is a strong chance that most of these applications are open source. Perhaps an interpreter/VM could be written, or a binary patch to fix each program individually.
There is an interesting issue for Windows, though (not to dwell on COBOL, but to prove a point):
COBOL accounts for approximately 34% of all applications although only 16% of all professional programmers work with it.
Uh oh. Sounds like legacy applications. Does the (closed) source code still exist? Does the programmer still exist?
I wrote a VB.NET application for a company and (quite smartly, I would say) did not give them the source code for the application. What if the CLR (Common Language Runtime) becomes unsupported?
The fact is, Windows has become so successful that it must play into the hands of its higher-order customers (businesses and OEMs) as much as they play into Microsoft’s hands. And, as the lagging trouble with innovation, people who believe that one needs computer “training” to word process and change their desktop background run the risk of not understanding the innovation. And if a General Manager isn’t allowed to make the VP look stupid, how is Windows Next Version going to get away with it?
Linux advocates need to see and respect that it is this kind of relationship between OEM, customer, and OS-provider that makes Microsoft such a powerful option for massive deployment and ease of use. Microsoft needs to consider that perhaps it is time for COBOL to die, so to speak. At what point should innovation take the wheel?
Perhaps Microsoft needs to “fork” its development model. Could we imagine a WindowsHP (High Performance) with the Avalon presentation system (a la Longhorn, nee DirectX) and perhaps WinFS, and WindowsEP (Enhanced Productivity) for the corporate and HP/Compaq/Dell low-end desktop? Wouldn’t WindowsEP be a much lighter weight system with a more limited (by the day’s standards) API that would run (gasp!) well on a Celeron?
I actually propose that WindowsEP should run on a live CD that uses a hard drive partition for third-party program files and swap space, then another partition for data. It would be virtually virus proof (just try to corrupt DLLs on a CD). A new live CD would be mailed to you on a subscription basis monthly with all security patches built in (Microsoft: think MSN subscription upgrade option).
Anyway, that’s it for the rant. Off to lunch.