Ray Ozzie on Longhorn & Groove Networks
Ray Ozzie on Longhorn & Groove Networks
Since the early days of his development of Lotus Notes, Ray Ozzie has competed vigorously with Microsoft while working closely with Redmond as a leading ISV on the Windows platform. Now, with Microsofts significant investment in Ozzies Groove Networks, the collaboration has broadened. In the aftermath of Microsofts Professional Developers Conference in Los Angeles, Ozzie spoke about Longhorn and Groove with eWEEK Contributing Editor Steve Gillmor.
SG: What are your gut feelings about Microsofts Longhorn Wave?
Ozzie: If anybody had any doubt that the rich client is alive and well, this should extinguish any of that doubt. They are pouring billions into keeping the rich client alive and well and healthy, and there are just an amazing number of very smart people working on the stuff. Yeah, its early, but all I can hope is that a lot of people pay attention to it. And at the appropriate time, sensitive to how people can make investments over long periods of time, I hope we see a lot of new interesting stuff come out, because there are a tremendous number of new services that are going to be available on the client side. Im pretty psyched about it.
SG: You spent all week at the PDC.
Ozzie: Yes. Were a Longhorn design partner so were very familiar with it, but what I was absorbing more than anything else was how Microsoft was positioning how it works to the developer community. Thats very important.
SG: Where are you in your goal of componentizing the Groove services?
Ozzie: We started out as probably the most componentized app thats ever been written with COMits COM to the extreme. About a year ago, though, we sent the message out to our partner base that the COM way of doing things is obviously not strategic any more and we would be shifting toward Web services. And progressively, we are refactoring and re-exposing all of the services that were available on the COM side of the world out via Web services.
Some of those Web services only make sense when run essentially on localhost; some of them make sense when youre talking to a Bot server; some make sense on the client. Whats in V2.5 right now, I would characterize as first light. In the next major version of Groove, we will continue to make progress. Will it be as robust as our COM surface area? No. But were making a lot of progress.
SG: Theres been some controversy about Microsoft moving away from some of the core Web services standards with Longhorn. Do you share this concern?
Ozzie: I dont share it with Indigo. Indigo is Microsofts standards offering, so if anything Indigo is absolutely standard in its implementation. Those are the people who are doing the collaborative stuff with IBM and WS-I, so no Im not concerned. In fact, quite the opposite.
SG: The concern is that in the area of XSD and XAML we seem to have a partitioning of the rich client into the core Windows calls versus the standards-based Internet API calls.
Ozzie: Right. On XAML, I am totally with Microsoft on that one. What theyre doing there is essentially a textual representation of the object model. Its not like they have the option to separately parse it and figure out elegant mappings. You write part of your classes in code and part of your classes declaratively. I dont think they have a choice there about standards or not. From where I stand I dont see any mischievous behavior. During the Hailstorm controversy they got beaten up quite a bit by not paying attention to standards. As a result, much of the schema effort that theyve done is the result of all the hard lessons learned from Hailstorm.
SG: Do you see the Hailstorm DNA in Longhorn?
Ozzie: Certainly in things like Contact schema. What they learned in Hailstorm was that every single group in Microsoft, no matter what they were doing, had the representation of a contact in their own internal data structures. And they went through unbelievable efforts internally to sort out what would be a good way of schematizing a contact.
Ozzies view of the
future of Groove">
SG: Ive jokingly suggested it would be 2008 before we actually see Longhorn. Whats the opportunity for Groove between now and then?
Ozzie: We stay focused on solving the business problem that were working on, which is to reduce the cost of coordination between individuals. The good news about Longhorn is I dont know if youve looked into the peer contact stuff that theyre doing, but its tremendously exciting to me because essentially its very similar to what weve done in Groove, except taken deeper--down to the file share level,
In Groove we have this model where we distribute contacts to people with vCards. In Longhorn, its very similar they call them iCards or Information Cards but you essentially serialize your identity and send it to people. And once youve sent it in a peer way, you can do a net use. Its at a very low level and its very similar to Groove. I am totally pumped about that, because when we go talk to IT people now we can say "Hey look, you see this stuff in Groove? Thats where theyre going too. So get your practices in place ." The more of us who can talk in this way to IT, the more they become comfortable with it.
Generally, we sell more to line of business IT than to corporate IT because thats where theres business pain. For corporate IT, when they encounter Groove, and this peer authentication model, this is the first time theyve dealt with it in their environment. And now that Longhorn has sort of come out of the closet, we can bring Longhorn into the conversation and say "See, this what youre going to be dealing with in that environment, too." Its good for both parties.
In terms of an actual investment in code, we have to go through the same thing that every ISV has to go through timing the investments to the ship date. If you over-invest too soon its problematic. Were still a startup. Yes, were investing, but the investment increases as a function of how close to market it is.
SG: In the interim, will you alter your core infrastructure to emulate what Microsoft is doing, or will you wait?
Ozzie: Its not so much emulating. At any given point in time, a prudent engineer will look at the next version of whats coming down the pike, and if you have an opportunity to re-architect whats coming down, you do it. So, for example, when we knew Office 11  was coming down the pike, 18 months ago, we started recoding stuff in Groove to take advantage of certain things that were going to be in WSS [Windows Sharepoint Services] and Office 11. Thats the great thing about having a close working relationship with Microsoft -- knowing whats coming down the pike.
In WinFS, for example, we are starting already to re-conceptualize how we deal with record storage in our forms tool. Were re-conceptualizing how some of our contact stuff worksnot in a big bang sense but as we do version after version we reshape it so we can intersect it at that right time, so that when WinFS becomes real, were ready to store records directly in the OS. Or when contacts are in the OS that our infrastructure is ready to either federate or unify our contacts with the contact infrastructure. That when the Sidebar is in place, our UI is already refactored enough such that its easy to take the components we want to put into the sidebar and rehost them there. Its progressive.
New details on Mac,
Sun and Linux versions of Groove">
SG: Hows the Mac version coming?
Ozzie: [laughs] The Mac version is great. I am so happy that Microsoft bought Connectix. I dont have a good answer for you there, Steve. I just dont have customer demand right now to fund a native port. I would love to do it. I would really love to do it. I just dont know how to fund it.
SG: Given the direction that Longhorn is moving with XAML and Avalon, separating UI calls from business calls or the rest of the code, do you see that as an opportunity to move, if not the actual client, then the Groove services over to other platforms -- the Mac, Linux, Sun?
Ozzie: Let me answer a question with a question -- and Im not trying to evade I just think this is really the higher-level question that we should be asking as an industry: Linux-- and to a smaller extent the Mac because it is OS/X, a Berkeley derivative -- is reliant on the fact that the OS layer is stabilizing and becoming a commodity. That is, it would be great for both the Mac and Linux if nobody could make money on operating systems anymore because it was all generic and all the same and it all looked like 1970s 80s-ish Unix.
Now what if, as has happened in applications, the core abstraction of what is in a contemporary OS moves up by many notches? What if APIs become frameworks? What if a file system becomes more like a database? If higher level service-oriented architectures are in the underlying infrastructure as opposed to just generic standard C library runtime calls?
As a client side developer, I really want to take advantage of that stuff. It lets me be a whole lot more productive. But the more I do that the more I rely on higher-level infrastructure being around. So what I would ask you is the following: Are the Linux community and the Mac community prepared to step up their client-side investments to build higher-level frameworks to make it easier for me to code like a Microsoft is doing?
SG: Or Sun, whos given a fairly strong indication that they are going to match certainly not the dollars but the investment in an uber-OS of the type youre talking about.
Ozzie: On the server side I think I see that theyre investing like that. I dont know that theyre doing that on the client side. Maybe Im not well versed enough.
SG: There seem to be three basic groups attempting to marshall that transition: Apple; Novell with their investments in Zimian and Evolution - and now with SuSE,; and Sun with its Desktop System, and Looking Glass - which is not coincidentally a somewhat Mac-oriented OS/X interface in the same way that Microsoft seems to be borrowing some of Os/Xs glass look and feel.
Ozzie: Restating the obvious, but at a high level, the good news is: As an industry, of all the players that youve talked about, were all agreeing on the wire. A service-oriented architecture objects on the client, services as a way of dealing with servers--were all agreeing on that. Its looking good for the customer, in that respect, because it doesnt matter whats on the client and whats on the server, were all going in the same direction. The client is still about moving from a world of APIs to a world of objects.
To the extent that, through Mono and through various things like that, there is a uniform object abstraction that a client programmer can use between the systems, life is good for a developer. To the extent that there are different object models on the client, its going to bifurcate the camps and that isnt what you want because you want my program sorry, I would like you to want my program on the Mac.
I havent seen Apple making overtures that its going to try to unify the object model with the future object model that would be the Windows platform. Id love to see that happen. But if compatibility was tough with GUI APIs we aint seen nothin yet with respect to the world of object models. The level of service offering and complexity to emulate is tremendous. As developers we want that intensity because it saves us time. Its going to be interesting to see how things evolve. Im really looking forward to see what Novells angle is.
Discuss This in the eWEEK Forum