June 26, 2006
@ 03:33 PM

I was reading Charles Miller's post entitled We Come to Bury WinFS... where he wrote

The first thing to strike me about the blog post announcing the end of WinFS as a Vista feature is how totally un-blog-like it is.

Every comment (bar one) got the point. WinFS is dead. Its carcass is being split between SQL Server and ADO.NET, and the relational filesystem that was going to change the way we use computers is no longer just postponed to be shipped after Vista, it’s gone.

The blog post itself, however, is written entirely in marketing-speak. The engineer talks about how super-excited the team is about this "new direction", how encouraging this news is, and leaves the fate of Vista for a final, particularly obfuscatory paragraph. Nary a word is allowed to suggest that the last nail in the coffin for Vista’s most eagerly anticipated feature might be a huge let-down to those people who have been watching it slip further and further down the schedule since its fanfare announcement as a part of Longhorn three years ago.

Did Microsoft forget everything Scoble was supposed to be teaching them, so quickly?

Every now and then, you’ve got to put out a mea culpa. You’ve promised something that turned into something else, or that you changed your mind about, or that you just can’t deliver. In the mass-media world, you do this by spinning the story as positively as you can. The message will be filtered by intermediaries before it reaches the public, and it’s expected the journalists in the middle will get the point, pulling quotes from the positive spin to offset the otherwise negative message.

I agree 100% with Charles Miller's sentiments about the blog posting on WinFS. This seems to be another example a case where Microsoft overpromised and underdelivered failed to deliver but even worse instead of owning up to this, the blog post spins this as being what customers want. From reading the hundred or so comments and trackbacks to Quentin Clark's post it doesn't seem that there are many people who are excited or encouraged that what once was touted as a pillar of Longhorn is now just another checkbox feature in SQL Server. This makes Microsoft look bad to developers because it means that we are either insulting our developer customers by thinking we can pull the wool over their eyes in such a blatant way or even worse that we are completely out of touch with them. Either way, it sucks and I feel like we should apologise to developers and perhaps even the software industry as a whole. Microsoft did offer a mea culpa to developers for the delay between Internet Explorer versions and I think this is another one of those cases where we should do the same.

I feel like I should probably throw in some last thoughts about WinFS, the technology, especially since in my previous post I claim that this decision should have been made a few years ago. Below is a random collection of my thoughts WinFS which can also be gleaned from my various blog posts on the technology over the last few years

  1. There was a divergence of opinion in what the team was building and what the people thought the team was building. A common misconception was that WinFS would somehow make search "better" on the desktop in the same way that desktop search tools like Lookout do. I addressed this misconception further in my post Killing the "WinFS is About Making Search Better" Myth from almost two years ago.

  2. The project had the biggest example of scope creep I'd ever seen at Microsoft. When WinFS swallowed ObjectSpaces the team decided that instead of just tackling the hard problem of building an object/relational file system for Windows that they also wanted to tackle the hard problem of  building an enterprise-class object to relational mapping technology with the same product in a single release. It also didn't help that key ObjectSpaces folks like Matt Warren, Dinesh Kulkarni and Luca Bolognese ended up joining the C# team to work on LINQ which meant WinFS inherited all of the problems of ObjectSpaces but not necessarily all the folks who had been working on those problems.

  3. The chicken and the egg problem. One of the key ideas in the WinFS type system for the Windows desktop was that we'd have common file system level types for high level concepts like people/contacts, email messages or photos instead of just opaque bits on disk with some file format specific metadata. To take advantage of this, existing applications would have to be rewritten or new [backwards incompatible] applications would have to be written targetting WinFS. The primary benefits of making this change [besides the improved programming model] were the network effects if lots of applications used these types (e.g. Outlook stored mail identified by a WinFS contact, RSS Bandit stored RSS feeds from that WinFS contact, AOL Instant Messenger stored IM conversation logs using that contact, etc). Even if you got these network effects you then had to deal with the Windows registry problem (i.e. apps stomping over each others data which is one of the main problems with the Windows registry today).

  4. I never saw good answers to the questions Jon Udell asked in his blog posts Questions about Longhorn, part 1: WinFS and Questions about Longhorn, part 2: WinFS and semantics. Specifically, the world is betting big on open file formats such as XML including parts of Microsoft (e.g. Microsoft Office) so why would anyone want to build aplications targetting a proprietary Windows-only file system that didn't have a good XML story for getting data out of the platform?

I should probably stop now. Even though all the information above is freely available to anyone who reads blogs and can put two and two together, some may object to the above collection of thoughts.