Interview: Steve Ballmer

There are two basic things to do. One I think we've done, and we need to get it used. The second thing we still need to do.The first, which we've done in Office 2000, is to provide the ability to secure the system so it will run only macros that come from a predetermined set of folks. We've got to get the Windows 2000 technologies pervasively implemented that essentially give the systems administrator the ability to'I won't say lock down the system because you still have some flexibility'lock out arbitrary macros from every Tom, Dick and Harry.The next step and the ultimate way to go is to force people to sign any code, including macros, that they want someone else to run. The person has to prove their identity before another user runs that macro or any other piece of code of any kind that happens to be embedded in an e-mail.Impersonating the sender is possible in the commercial world'even at DOD. Frankly, if you're not on the Defense Message System, you want to be able to prove that the code is something the sender has given his blessing and approval to. That's a longer-term direction. It's not true. We've done extensive testing with the Massachusetts Institute of Technology at an engineering level. It is true that the last guy in does not implement the old version of the standard. You implement what's current, and that's what we've done.But if you looked at DOD today and asked how much Kerberos is deployed, it's very small. People get confused about what the real issues are. Let's talk about what people want in their centers. I can tell you what people want in their data centers and what people want in their electronic commerce sites.People want, I would say, four things. They want great scale and high availability; they don't want a single point of failure if they can avoid it; and they want things that are simple to take care of. That's what people want.Now, in today's environment, some people say what they want is to consolidate. In fact, I'm not sure that's what people really want to do long term.The reason to consolidate today is primarily a question of manageability. You don't have the right tools to manage a bunch of servers, so the thing to do is have fewer servers. Physically you're only taking care of one thing even if logically you have the same number of files you used to have. But look what happens if you're eBay Inc. Bang! Big server! You've consolidated it, baby, and boom, you're dead. You're out of business. You have a single point of failure.So, are you better off? I think there are a lot of questions, and it will depend on the application and the architecture. But do you want fewer servers? Or do you want clusters of very manageable systems, very scalable, with no single point of failure? I think that's what you really want.There are three things we need to do from where we are. No. 1, we want to scale up, so that if you want to have one big honkin' machine, you can do it'more processors, eight-way, 16-way. The second thing we want to do is scale out with better cluster technology and better tools to manage the clusters. And the user wants to take an application approach that doesn't lead to a single point of failure. That's where we're putting our energy. It can work fine. Windows 2000 has a rich capability set. The question is, is that what you want to do? These PC servers are not expensive, so I'm not sure you want fewer servers. What you want is to have fewer logical entities to manage. BizTalk is a standard set of Extensible Markup Language schema that will let participating applications communicate at what I'll call a semantic level.For a given set of business processes, you want a BizTalk standard set of definitions that applications can use to communicate with one another at a higher level. For example, what is the standard XML definition of customer?What you want today is to do a lot of things that are richer than what you can do in electronic data interchange. BizTalk is a technology, but at some point it will be a product, probably called BizTalk Server. That technology will help you chain together sequences of actions by participating BizTalk applications. For instance, 'Pass this customer from that enterprise resource planning application to that customer management system to that Web site, and have the following actions take place.' XML is XML. Everything on top of XML does take some schema. We're not in the business application area. We have to work with third parties to try and implement standard XML schema for this thing to work. It will only be successful if it is not proprietary.Frankly, we hope to make our money providing the tools that let you chain together and describe the work flows against XML objects. So we need to get those things to happen. With a few exceptions, we don't have a vested interest in what the schema look like. Linux is not dominant in the market, but we get paid to focus in on competitive threats, and it's a really competitive threat.The interesting thing about Linux is that it highlights how much the technical community likes to have and get information about the products they work with.Do I think people like the fact that Linux is free? Of course they do, but that is not really a big deal. Do I think people like the fact that they can hack the source code of their own operating system? You tell me how many wing commanders in the Air Force want their IT guys out hackin' operating systems. They've got work to do.What people do like is having a better ability to self-diagnose by looking under the covers when they have a problem. Not everybody, but sort of the elite can peer under the covers. And you have applications that only the elite will touch and maybe that's OK. But most applicatons are not that way.What we need to do is respond to this notion of somehow giving people the tools to do more self-diagnosis. I hesitate to say publish the source code in the Linux sense. That implies a certain way of developing software that's chaotic and crazy, not very well managed in my view. And it implies a lot of other things. But if customers were to know they could peer at our various aspects, if not the entire source code, and answer their questions themselves.We have people you can call on our support staff and at the end of the call, the customer says, 'Thank you, but the only difference between you and me on this call was, you could look at the source code and I couldn't.' And so this is a need we are pondering how to address. We're pondering how to address the issue I just raised. That's the right way to say it. I've said what I said. I've said it the other way, too, but it gets so poorly reported upon that I'll just stop right there.