Bill Gates interview: the transcript

I've been too busy here at the PDC to transcribe Tuesday's podcast of my interview with Bill Gates, but the folks at IDG kindly took care of that, so here it is:

JU: So, the Napoleon Dynamite thing was delightful.

BG: It was fun to do that. He's an amazing person. He was able to ad lib and I think we spent a little over three hours and got it done.

JU: I'll just note another interesting comment. I was having breakfast with a guy from Sweden at a table and was asking for his impressions, and the overwhelming one was -- I can't believe how things have opened up -- the transparency, the blogging, and what he felt like was genuine two-way communication flow, that made a big impression on him and he felt that, in particular, people really had listened to the feedback and really had reacted to the feedback from the last time around. So I thought you'd like to hear that.

BG: That's fascinating. We were talking last night about -- geez, they made us change our plans. What did we say? How to exactly bridge...and I put in the slide which was the PDC 2003 slide, they hadn't had that in there to really bridge, look, we were saying that it wasn't downlevel last time and WinFS was client-only, and we were going to try to get it to critical mass client-only. But even at lower levels of granularity, I mean Avalon went through a redesign, a big change for some performance-related thing that was driven by outside feedback. The whole IE plan didn't have a downlevel thing in it at all, it didn't have the RSS platform stuff in it. We got feedback on that. It's a pretty dynamic environment. And I'm glad people are still willing to come to a face-to-face event like this. I mean yes, there's a time you can do it electronically, reaching out to people, but our developers who sit in these sessions will have a stronger impression of what they should do, how they should do it, just from the face-to-face thing, than even today's best tools are going to be able to give them.

JU: So in terms of the down-leveling, can you clarify -- will Office 12 now require Vista or...

BG: No. No.

JU: It will only require the .NET Framework 2.0, is that then the case?

BG: Yeah, Office 12 runs downlevel. In fact, there's a lot of features, like the way search is more integrated, the way you get the new look. Using Office 12 on Vista, Office 12 is just that much better. We do expect a lot of corporate upgrades to do those two things together, but you can buy Office 12 and run it on XP, no problem.

JU: So the framework will be required, though, the runtime and the framework will be required?

BG: Yeah, it will automatically bring that down. We should double-check exactly how that works.

JU: But that's interesting, because I've really never met a developer who didn't like the framework and runtime once they got going with that stuff, but they often lament the relative non-ubiquity, still to this day, of those bits. And the question has been, you know -- what's the thing that gets that stuff out there? It sounds like maybe it will be Office 12 as much as anything. Is that...

BG: Right. That will be one of the things, I mean Vista, Office 12, there'll be a lot of things. And you know, that kind of download size is getting more acceptable, and we're getting more installations of it. But you're right, we've got to drive that forward. There comes a point where it's just common sense. We're not quite there.

JU: Right. Speaking in terms of data, I liked the point a lot about the need to get to higher-level semantics around business objects. It seems more and more that the strategy is to define those things in terms of CLR types, CLR objects throughout your various systems. And in fact, looking at the LINQ demos today, and also thinking back to the XAML stuff that I've seen before, it appears that from a standards perspective, there start to look like sort of two parallel paths where you have -- well in the case of LINQ a lot of stuff is very reminiscent of let's say XQuery, or a newer standard called ECMAScript for XML, right? In the case of XAML, a lot of presentation stuff, people originally actually confused with being an extension or a derivative of HTML with CSS, kind of assuming that that was the direction of evolution, and instead it's a different thing. So, do you think that this is true that in fact developers are kind of being taken down two parallel paths here in terms of standards and techniques?

BG: Say again what you think the two parallel paths would be?

JU: So one would be... Well in the world of data, it would be, let's say XQuery, ECMAScript for XML, things which are standards, in the world of presentation, the future evolution of DHTML and CSS and things like that, as you're actually even using yourselves...well you have been for a long time, but you're using now in a new context with these gadgets on the desktop. So that's one style of doing things.

BG: Who did DHTML?

JU: You guys did. You guys did, I know that.

BG: Okay. And you know, it's there. Other browsers did the same thing, that was great. In terms of this Atlas runtime stuff, other browsers may well do the same thing. Actually, a lot of the Atlas stuff is even independent of that. So I'm not sure of the parallel path you're drawing. Certainly when you look at something like LINQ, there's always going to be these query type things that are outside of normal programming languages. And great, we'll support those things. But the complexity for a developer of having this funny query utterance which is separate from their functions and their logic, that's never going to be as simple as being able to have the set-type operators right in the language itself. And so the two will co-exist. If somebody wants to have that big XSLT thing or XQuery thing inside their source code or just a reference off to another file that has that, great. We support that. The brilliant thing is giving you a choice of having that right there in the logic in a way that's readable. That's the breakthrough, is that the impedance between -- okay, here's my data mapping logic and here's my business logic. Those two things can be in a readable piece of code.

JU: That part's really sweet. Anders has done an excellent job with that.

BG: And he's been working on this for years.

JU: I know, he's been talking about it for years.

BG: You know, I've been hoping he would just pull the trigger and say -- hey, it's ready, it's ready. Now he feels good because he's used it in many different contexts -- persistent databases, in-memory databases -- and he's gotten a sense of all this XML heterogeneity. He's been able to look at these dedicated query environments and say -- okay, can I map enough of that functionality inside the program itself that it'll cover 90 percent of what people want? There will be cases where you'll still -- that in terms of deep richness, you'll go out to those essentially different query languages. And so in no way are we holding back on that, but having it in the language itself just makes development easier.

JU: So is it fair to say that you see the CLR object system as the way to express those higher-level abstractions and you see XML as more of an interchange language across systems?

BG: Those CLR objects, live objects in memory, that's going to be important. But then being able to persist and exchange that stuff as XML is going to be important. I think in a way that's -- this is just me, personally, I'd be interested to see how Anders would react to this -- but that's one of the big breakthroughs recently is that you get the loose coupling through XML, and then when you want to build an application, you get the rich behavior through things -- in our case, CLR-type objects. And to really benefit, both of those things need to work, and you draw boundaries in your application where you're mostly working with XML. Certainly once you get to connecting to another company, as the extreme case, you can work in this XML approach. And the thing that's invariant across a huge system is much more the XML, and the thing that's invariant across many, many, many versions is the XML. But, when you're writing this neat little application wanting to get code reuse, that's where the objects come in. I think the world was way -- taking the object idea, the runtime binding idea, and trying to use that to solve software componentry, and that created really big versioning problems.

JU: Agreed. You guys went through the whole COM exercise.

BG: And we saw this played out inside Microsoft, you know, even developing Vista, this versioning problem where things are rich runtime objects. You know, small behavioral changes have these very dissonant effects, whereas if it's just XML, you can actually define the contract, that is the expectation between the components. And in the world of software, we've got to get to the point where most of our testing is more at the component level and less at the system level and so you can understand -- okay, I changed this component. Am I okay? Not -- oh, let's rerun the last ten years and see what happens.

JU: Yeah. And in some cases, those contracts wind up being fairly sloppy, which arguably is a good thing. I mean RSS was woven through a lot of the stuff that you showed and that other people showed today, which I think is a nice example of an XML interchange that is intentionally, if you will, kind of sloppy and accessible even beyond the developer to somebody who can just kind of hack up a file full of XML and make it work. Right? I think that's a good thing and I'm guessing that you're sensing that this emerging, what I call the RSS data Web, is going to be a big deal.

BG: Absolutely. And the RSS data Web is a natural development coming out of the acceptance of XML, and it's the notification infrastructure for XML. It is going to get richer in that things like two-way -- we've got some ideas internally that we want to put out about making RSS work two-way. RSS things need to have...you need to be able to look at their type in a slightly more predictable way, so you understand which application that things should show up in slightly better, have a little better filtering for these things. You know, small change, big change. So the fact that it's kind of chaotic right now, that's okay. You know, there were even the Atom things, there were some different formats that we're now in our runtime having to re-map to each other, but RSS platform tries to hide most of that, the early things that came along.

And there's a lot more issues to be solved than RSS. It's one of these cool things where the user experience is getting better. We think, okay, Outlook's now got this built in, SharePoint's got it hooked in. And the basic technology is improving. And because it's XML, it's both a data platform thing that developers think about and end users think about it. So it's very rich what's going on nowadays.

Ultimately the whole problem of notification, of what is it should I be paying attention to next? Is it the e-mail that came in? The phone call? The bid we're supposed to make? That's actually a very deep user interface problem, you know, having all these things understand your context and their priority and who's saying that they think something is urgent. And then you just go to your computer screen and it's ranked for you. You know -- first pay attention to this, then pay attention to this. That's the holy grail that these technologies are in service of, is that the thing where you always had to go find things, now the system is being a bit smarter for you in terms of now you're not polling the world.

JU: Yeah, somebody had a nice quote that RSS is the human face on Web services. I kind of like that a lot and related to that is something that I've said a few times, which is that human beings are the exception handlers in all workflows. And so...

BG: Absolutely. That's a really good way of capturing something I was saying about the boundary between structured and unstructured. Eventually you've got to know who in what role and how to communicate to them, because if software could just talk to software, we could get rid of all the humans. Everything that's real, eventually there's a human involved in. And there is a little bit of tension between very interpretive, simple-to-create stuff, like REST or POX, and very structured, tight stuff like Web services. And if the industry is smart, we can get the best of both worlds, where things that are not very complex, you just want to go get a stock quote, a weather thing, fine. Use REST. Even, you know, go to Wordpad and type in the ugly URL.

But as you get up to secure protocols that you want to audit what's going on, you really have got to exchange lots of data, things coming out of order, you want to correct that, if you get to richer protocols, you want to have continuity that you can start something in the simple form and then put it into these richer, very statically type-checked, contract-driven approaches. And so that's an evolution you've seen in the last, even last nine months, in the Windows Communications Framework, Indigo. Where they came from was, hey, you know, this is very tight stuff, and the only way we can give you the guarantees that the guy at the end does the right thing is if it's very heavily typed, and so some of the initial reaction to the more interpretive thing was -- oh no! What about that?

JU: Well there's the issue of evolving from a less strictly typed protocol to a more strictly typed protocol, but even in the looser environment, I mean even just plain old RSS feeds in the enterprise are going to start to need reliability. They're going to start to need intermediation and routing and things like that, and location-neutrality...

BG: Absolutely. When you start putting... Corporation A puts an RSS notification on the directory of Corporation B, there's just too much data. You don't want to send all that data. Every data thing in the... People are acting like -- oh, this is all solved. We'll just put subscriptions onto every piece of data in the company. Well, the amount of stuff that's going to flow and the need of IT to be able to log and filter and have rights and all that stuff, it's just not going to work. So there's an RSS naivete today that is wonderful, but cannot last.

When Ray Ozzie internally drove this idea of the two-way RSS thing, then, you know, we were having RSS feeds in and out of Active Directory, in and out of Exchange, in and out of SharePoint. And people were finally going-- my god, we've got to encapsulate this stuff into all these rich things that we've got. We can't just let this thing be something out on the side. And so the WS guys, they knew that RSS grew up as a phenomenon on its own, SIP grew up as a phenomenon on its own, XMPP grew up as a phenomenon on its own. They have to encapsulate those things into their value-added framework. There's just too much RSS, too much...and for good reason, and SIP and XMPP, to just say -- okay, no. It's a little bit like the old Pascal versus C type thing, where the Pascal guys always said -- look, you untyped guys are going to kill yourself. But, you know, actually for systems programming, C won and Pascal lost. Because it wasn't flexible enough.

JU: So a few people in the audience spontaneously commented when they saw the light version of the presentation framework, I heard the words "Flash competitor" in the audience. Do you think that's a fair observation? And do you think that that's potentially a vehicle for getting Avalon interfaces onto not just devices but non-Windows desktops? To extend the reach of Avalon that way?

BG: From a technology point of view, what the Windows Presentation Foundation/Everywhere thing does -- I think it was called Jolt internally. It overlaps what Flash does a lot. Now, I don't think anybody makes money selling lightweight presentation capability onto phones and devices and stuff like that. We're making this thing free, we're making it pervasive. I don't think anybody's business model is you get a bunch of royalties for a little presentation runtime. So there'll certainly be lots of devices in the world that are going to have Flash and they're going to have this WPF/E -- which they say they're going to rename, but that's the best they could do for now -- there'll be lots of devices that have both of those, but they don't conflict with each other. It's not like a device maker say -- oh my god, do I pick Flash, do I pick WPF/E? You can have both of those things and they co-exist easily. They're not even that big.

JU: And it's a portable runtime at this point, so is it something that conceivably takes XAML apps to a Mac desktop or a Linux desktop? Is that a scenario?

BG: The Mac is one of the targets that we explicitly talked about, so yes. Now it's not 100 percent of XAML, we need to be clear on that. But the portion of XAML we've picked here will be everywhere. Absolutely everywhere. And it has to be. You've got to have, for at least reading, and even some level of animation, you've got to have pervasiveness. And will there be multiple things that fit into that niche? Probably. Because it's not that hard to carry multiple...you as a user don't even know when you're seeing something that's WPF/E versus Flash versus whatever. It just works.

JU: A lot of people look at these demos and see obvious need in the consumer space, and however wonder about what's really the enterprise hook for Vista. And in particular, now that it looks as though a lot of pieces of what were Vista-only are going to be separately available, what would you advance as kind of the key reasons why an enterprise is going to upgrade? I mean I would offer a couple of security things, including the very cool virtualization sandboxing stuff that we saw today, which I guess is based on VirtualPC. Is that the idea? That'll be built in?

BG: Well we support VirtualPC, but the thing you saw called low-rights IE does not depend on VirtualPC. That's done at a higher level in the operating system. I don't have any doubt at all that IT departments are going to want to switch to Vista at full speed. Just the logging, security. We didn't talk here about the imaging, where you can have one image shared across all the things. There's a ton of stuff that just makes this a clear win for IT.

JU: So managing, deploying, those issues are going to be the drivers, you would say?

BG: Yeah. Even if it was just security, that alone is enough. But yes. And if it was just deployment, that alone would be enough. This -- I forget what they call LUA [least-privileged user account] now, the ability to have non-administrators not do the administrator thing.

JU: Defaulting to non-administrator is huge.

BG: Right. And so we have an experiment we're doing where we're managing a few company's desktops and to understand -- a non-Microsoft company where we're doing some desktop management things for them. And it's been fascinating when I meet with that team how much LUA comes up as they do their cost models, they're depending on LUA. In fact, the feedback that we've gotten, where we really see what those guys want to be as efficient as possible doing desktop management, that really impacts the software development thing, it's been huge. So we don't have any doubt that IT will move up. We've got SMS in place in a much higher percentage of customers, so a ton of this stuff can move out without anybody going out to the desktop itself.

The hardware that's out there, installed base, most of that is capable of running Windows Vista. And we've got to make sure that we get the performance metrics right so that people don't feel like they have a lot of hardware that can't run it. By the time we ship, most of the hardware will be capable. So we think we'll see better upgrade rates in the installed base, we think we'll see, particularly within Office release time, less of a version tail against us than we've had. A lot of enterprises are Windows 2000, [so] this is super compelling. But even for somebody who went to Windows XP, because the automatic framework is more in place.

The only place where we've had compatibility issues at all is where there's a big payoff, which is the administrative rights issue. But even there, we have these shims that for any particular app, you can do the pass-through and the administrator can just decide -- yeah, for that app, go ahead and put that shim in there.

So I think we're in very good shape on the fastest adoption by IT that we've ever had. Our goal would be that even an IT department that wasn't doing a full refresh of all their machines, that they let the new machines come in on Vista, and they'd have a mix of Vista on the newer machines and XP on the older machines until they get to their refresh time, and then they'd have a little bit less to do in the refresh. I don't know if we can achieve that or not, but we're going to make those refreshes a lot easier for people to do, and a lot more compelling feature-wise, and then Office coupled with it.

I was saying to Jim last night, convincing people that Vista be accepted by IT was not the big message we were trying to say here. We just take that for granted.

Former URL: http://weblog.infoworld.com/udell/2005/09/15.html#a1302