Dan Farber raises the issue of Longhorn adoption and quotes a Jupiter analyst who claims the challenge is that XP is “good enough”. There is actually a more fundamental reason the question of adoption is interesting. What is that and what does it have to do with content technology?

I’ll start the answer with a little history. In 1994 at our first Documation conference, I moderated a debate between Tony Williams, Chief Architect of COM at Microsoft, and Larry Tesler, Chief Scientist at Apple. The Microsoft COM and OFS/Cairo and Apple OpenDoc efforts both recognized the need for operating systems to provide more support for the richness of unstructured information than is possible with the primitive file systems we had then.

Before the debate I preferred the OpenDoc approach because it seemed more consistent with my view that new operating systems needed to be able to manage arbitrary information objects and structures that could be described with a markup language (like SGML at the time). However, Tony convinced me that OpenDoc was too radical a change for both users and developers at the time. Tony agreed with the ultimate need to make such a radical change to file systems to support the growing need for applications to manage more complex content, but he said that Microsoft had decided the world was not ready for such a shock to the system yet, and defended their strategy as the more realistic.

Eleven years later and we are still stuck with the same old-fashioned file system in spite of the fact that every modern business application needs to understand and process multiple types of information inside files. This means that database platforms and applications need to do a lot more work than they should to work with content. I am no expert on Longhorn, but the file system that will be part of it (although maybe not initially), WinFS, is supposed to go a long way towards fixing this problem. Is the world ready for it yet? I hope so, but it will still be a big change, and Tony’s concerns of 1994 are still relevant.