Q&A: Microsoft's Jim Allchin on the Longhorn timetable

Computerworld - REDMOND, Wash. -- Longhorn is the code name for the next version of Microsoft Corp.'s Windows operating system, and the company often refers to the "Longhorn time frame" when discussing Windows and various associated products. But company officials have gotten increasingly sketchy about just when that time frame is.
During an interview last week with Computerworld, Jim Allchin, group vice president of platforms, confirmed that the target date for the next version of the Windows client operating system is still sometime in 2005. Allchin also discussed the philosophy behind the company's operating system plans as well as the next service pack for Windows XP, which is due next year.
Excerpts from the interview follow. Part 2 of the interview will be posted later today.
Microsoft Senior Vice President Paul Flessner displayed a slide at your TechEd Conference in New Orleans showing the Longhorn client targeted for 2005 and the next version of the server operating system projected for "2006+" (see story). We realize it's early, but what's the latest thinking about when they will ship and whether they will be synchronized? It is very early, and we have a general plan that we're working to, which I'll explain at a philosophical level, but as to the point about when do they ship, are they synchronized, a lot of things can happen between now and then. It's still a long time off, and it's just too early. Philosophically, we want as many months, years, whatever, as we can keep the code base synced as possible. The efficiencies are huge by us doing that, and frankly, we think customers are best served by that.
So there was Windows XP. There's [Windows Server] 2003. We've now got two code bases that we need to service in the customer base. The server team was still finishing up while people were working on the Longhorn client. So now we're moving to where the Longhorn code base will be one, and we'll keep it one, client and server, for as long as we possibly can. And that's about as much as I'll say right now.
Is there a point at which the server needs additional testing, or where feature differentials come into play? It's all technical reasons. ... For example, we have a new event system that we're working on because we think manageability is at the forefront of our next push, and so there has to be a piece in the client and a piece in the server. Now we'd like the teams just to