... to remember is that services run on servers. Hopefully they run on our servers. If they do, we make money on that. If they don't, then we don't. It's up to us to build something compelling so they do.
Can you give us an update on the status of WinFS, the new file system originally intended for Vista and Longhorn Server?
It's going into beta 2 in early fall. People are playing with it. I think WinFS is one of those examples where we clearly got ahead of ourselves; there's no ambiguity on that. It never went through the appropriate incubation phase. The right way to build a technology like WinFS, and certainly the way we will do that in the future, is to spend a couple of years in incubation and gather some feedback. Where we're going with it is that we basically see many of the WinFS technologies very clearly as being important to incorporate into our overall database product line, into SQL Server. So you will see some of those features being incorporated into SQL Server over time. And some of the other pieces which may not be appropriate for SQL, we're looking to see where and how it's appropriate to bring them to market.
Possibly into the operating system?
Possibly into the operating system, maybe into the Office products even.
How did WinFS get ahead of the process, so to speak?
It's part of the Longhorn wave of getting ahead of ourselves. A little overambitious. We learned from that.
Looking forward, does Microsoft envision doing these monolithic operating system releases, or will you adopt more of a downloadable model of adding onto the base kernel?
We've done a lot of downloads and we will continue to do those. An example of where we need to do those is when the industry moves and you've got to be there. So for example, we just did this scalable networking pack for Windows Server 2003. The industry was there. We needed to do that as an out-of-band release. So we will continue to do those. That one was relatively easy because we're attached to the hardware community. What we've learned is that out-of-band releases have a hard time getting customer acceptance in the enterprise. Businesses don't like lots of little things.
It's actually an advantage we think we have over open source in an interesting sense, in that open source has this continuous development philosophy, which has some advantages to it. But it's not a great consumption approach for organisations. They need to run things through their test processes, standardise on them, and then run them for a long time. So having releases actually turns out to be a better way to get things out to the market. That's why we introduced this R2 concept (with Windows Server). These are interim releases that customers pick up and consume. We'll do more of that for businesses. Maybe it's not the right vehicle for consumers who (want things more quickly).
The other part of what we're asking is, does it make sense for Microsoft to rewrite the kernel for every new release of Windows?
Well we don't rewrite the kernel every time, let me be clear. We do make substantive updates to it. Frankly, you have to. The answer, kind of, is "yeah". Let's take, for an example, virtualisation, and the impact virtualisation has on our core infrastructure. There are kernel implications to it, and we made a bunch of those changes in Longhorn and we made many, many changes in the operating system to prepare us for Windows Server virtualisation. The idea that we would go back and do that to Windows Server 2003 is just sort of unthinkable for our customers. It just wouldn't work. So you kind of do need these opportunities to get in and take the engine apart and put it back together again.
Let's talk a bit about your responsibility for technical documentation related to the US Department of Justice consent decree. Is the documentation up to snuff now?
We were confused about this, and frankly everybody was confused about this... The feedback was clear from the government agencies and others that we had to rethink this. When we went in and took a look, we realised that we thought of this as doing documentation and we put people who are quite qualified at doing technical documentation on the job. But it ain't that. It's an engineering project. It's especially an engineering job because it isn't a core part of our development process yet. It will become part of the core process moving forward.
But the first piece of work that needs to be done is an archeology project to go through the protocols that are in the system, some of which date back 15-plus years, many of which (were written) by engineers that are no longer with the company, and we've had to pull quite a few of our key engineers onto this and they're working to get standardised formats in place and all of the basics. We're making really good progress on it and we are working as hard as is humanly possible and we'll be doing that for a bit of time now.
How much of your time does that consume?
I meet on it every week. I have multiple meetings and I'll be going back to Washington, DC every quarter or so to meet with the DOJ.
How will this change the documentation? What's the end result of all of this?
We have an agreement with the (European Union). We're hopefully days away from having an agreement with the DOJ on a standardised format for delivering the documentation. Hopefully, they will be very much the same. We think the result will be 90 percent the same. We'll have that coherent view of what the documentation should look like. So the next time we have a new protocol, we'll send out that document as part of the process. It will be a lot easier when they're doing it as they invent it, as opposed to 15 years later.
