Longhorn's longer odds
Longhorn has been sold on the strengths of three major components - Indigo, which is the new, improved .Net; Avalon, a new 3D user interface and display system; and WinFS. This is nominally a filing system but is really a relational database that speaks XML. Of the three components, it is the most exciting and the only one that promises to significantly improve day-to-day working: Microsoft says that by treating files as interrelated objects about which much is known, finding information and classifying it into useful collections will be easier. Searches will be much faster, and we'll be able to handle files much more naturally.
Unfortunately, all that has changed. While Avalon and Indigo are still on the menu for Longhorn - indeed, they'll be brought out so you can run them on XP and Windows Server -- WinFS has been sent back to the kitchen for further cooking. It will only be available in beta when Longhorn finally ships -- that's if 'Longhorn' is anything more than another complicated service pack for XP by then.
The reason behind this deconstruction of Longhorn is simple. Microsoft has to persuade developers - the only people besides patent lawyers that it deeply, truly loves - that all these disparate components should be part of their game plan. With all these innovations come new APIs, Microsoft's true warp drives of revenue. For developers to write software that uses the APIs - and thus the operating system - they must learn the ropes, download new development tools and spend a lot of time and money.
It's hard to justify that if there's no way to use what you've learned, or if you can't do much more afterwards than you could before. But Microsoft needs people to lock themselves into future generations of Windows: it has to have armies of programmers and a nice cushion of products ready when Longhorn ships, otherwise who'll buy it?
With Avalon and Indigo, the official line is that while they will run with the current crop of OS, they'll be a lot better on Longhorn. So please start working on them now, and when the bright new dawn comes, you'll be there and your competitors will be nowhere. It's not much of a story, but it's the best that Microsoft has got.
With WinFS, the story is murkier. Microsoft has long been confused about what it is, even from the time it was named. It's a filing system! No, it's a relational database with rich XML metadata capabilities! No, hold on, that's SQL Server 2005, aka Yukon. No, don't confuse them, says Microsoft, even though they have stuff in common. Yukon is a real database, not a mere file store. So why is Yukon going to be used as the filing system for future versions of Exchange, and not WinFS? What, exactly, is the difference between them? If I'm developing a product that could do with a nice database engine, should I code for WinFS or SQL Server?
And then there's the basic problem of metadata -- where does it come from? People aren't going to spend their lives carefully describing documents so that WinFS can find them blindingly fast. We can do that already -- Word can search on many different metadata fields within documents, and it's reasonably efficient -- but when was the last time you did anything for a file you created apart from try to think up a half-decent name? Anyone with a large MP3 collection will know how much hard work you need to do to make tags useful: the thought of your entire operating system depending on such attention to detail is not thrilling.
There is a way to make finding files very fast, and that's to come up with stonkingly good free text searching. By all means add as much metadata XML stardust as you like: developers will love you for it and over time it might come good. But while our PC experiences are so much worse than our Google experiences, the wrong questions are being answered. Is Google itself contemplating the problem? Well, what do you think?
So, Microsoft is asking you to make a bet. If you're going to develop for WinFS, you'll have to bet that the big gaping search-shaped hole in Windows won't be plugged by anyone else for a good two to three years. In fact, you'll have to bet on WinFS coming out at all: I wouldn't give you good odds. If you're going to develop for Avalon and Indigo, you'll have to bet that while they'll limp like a dog on crutches at first, the performance will eventually be better than .Net and the display API. And you'll have to bet that Longhorn without WinFS and with its other components available elsewhere is going to be a substantial product. Roll them dice.
Jim Allchin, Microsoft group vice president for platforms, has said that people are "super happy" about the Longhorn triage and "dancing everywhere", which certainly puts a new light on the Notting Hill Carnival. Let's hope that this exhilaration doesn't blind people to the need for a plan B: one with no lock-in, plenty of developments on the way, widespread industry support and a history of high performance, perhaps. Any suggestions?