January shot by like an SR-71 Blackbird reaching full speed. I hope to catch up in February. In the meantime, enjoy this interview.

from the July 15, 1985 issue of ComputerWorld magazine

Bud Tribble Explains it All

Before joining SunSoft as vice-president of object products in June 1992, Guy L. (Bud) Tribble was a founder of NeXT and its leading software architect. More than anyone, Tribble is the visionary behind OpenStep. He is also the software manager charged with making it a reality. A team of NeXTWORLD editors interviewed Tribble about the implications of the OpenStep announcement.

NeXTWORLD: Sun evaluated various options before settling on the OpenStep strategy. What were those options, and why did you decide to go with NEXTSTEP?

Bud Tribble: For the past several years, Sun has had a distributed-object program called DOE, or Distributed Objects Everywhere. The piece of DOE that actually provides the application environment, as opposed to the infrastructure, is the piece where we had some alternatives. There were basically three options that we were looking at. One was to build something from scratch ourselves. Another was to go talk to Taligent, which is the other company developing things in this space, and the third was NeXT.

What about Microsoft?

Well, Microsoft is another company that has a strategy in this space with Cairo, and we considered that. What it came to for us was looking for something that not only could fit into our distributed-object vision, but something that already existed, that was out there shipping and was customer-tested. Typically, when things ship, it takes roughly 3.1 versions to get a real product. I think Microsoft has proven that. We wanted something that had a time-to-market advantage.

To what extent did your familiarity with NEXTSTEP play a role in the decision?

That can be a double-edged sword. The closer you are to something, the more you can see what is good about it, as well as its blemishes. I would say our team did a good technical and business evaluation of each option.

Keep in mind that the original project for distributed objects actually started within Sun Microsystems Labs - the research arm of Sun - more than five years ago. About two years ago, it moved from the research stage into the product stage. For the past two years, SunSoft has been working together with the Object Management Group (OMG) and the other companies in OMG to create an infrastructure for building systems out of distributed objects. It’s kind of a backplane that you can plug objects into such that they can cooperate in running a company over a network.

The OpenStep technology adds the application framework. In other words, we’ve got this great infrastructure for having objects communicate over a network and for building distributed systems. But what are the APIs and what’s the GUI and what are the components for building applications?

In terms of timing, Sun’s OpenStep version of Solaris, or whatever the product will be called, is at least 18 months out. Taligent ought to have some kind of product in that time frame as well.

We actually haven’t announced a date for OpenStep from SunSoft. We expect to have a better road map available at our April developer conference, but I believe that we’re going to be able to field a product - OpenStep on Solaris - that is actually a year or possibly two ahead of similar robustness available from either Taligent or Microsoft.

We’re starting from something that’s shipping today. OpenStep is not going to be a redesign of NEXTSTEP. It’s going to be very close to NEXTSTEP 3.2 in how it works.

Now, just to play devil’s advocate, you could argue that NEXTSTEP was designed six or seven years ago. Something like a Taligent coming along today may be a generation ahead.

You’ve got to get perspective on this whole thing. Objects were invented by Xerox in the 1970s, and some people actually go back as far as Ivan Sutherland in the 1960s. We’re mining technology that was developed a while ago in terms of developing products that solve customers’ needs.

The big discontinuity is the object paradigm. NeXT is on the far side of that discontinuity today. Taligent and potentially Cairo, it’s hard to say, will also attempt to be on the far side of that paradigm shift. Within that shift there’s going to be gradations, but I don’t see there being huge, leapfrog, quantum differences between the various object systems.

Another factor coming into play is that you will see more and more of the object systems out there gravitate around some of the OMG standards. You even see Microsoft now with OLE and Cairo kind of centering around that. And that’s simply due to the fact that some level of commonality here is what’s going to be necessary to actually create an ObjectWare industry, as we go forward into this decade.

Open standards

What needs to happen for OpenStep to emerge as a broadly based standard in the industry?

First, we need to write the specification down and take it forward to the appropriate standards bodies. There is nothing magic about the standards process. I do think it’s important to realize that standards are necessary to enable an ObjectWare industry at some point in the future.

In terms of the technology itself, objects are at a fairly early stage. If you talk to people at OMG, when will they get around to standardizing the file choosers and such? Not for a while. They’re standardizing from the infrastructure on up. It’s not going to be an overnight process. Nor should it be, because you don’t want to put in stone a set of standards that turned out to be not the best way to do it.

Is it a foregone conclusion that OMG will take OpenStep as its standard? What about X/Open?

We will be promoting OpenStep as a standard, but it is not a foregone conclusion. One of the important things about standards if you go talk to OMG, for example, or X/Open, which is emerging as the standards body that’s interested in some of the COSE efforts, is that they will refuse to standardize something unless a proven implementation exists. So you have to ask the question, are there competing standards out there for objects or for object-application environments? Today, there really aren’t any.

Aside from some standards organization stamping something, what’s really necessary is market acceptance of a product. Do you expect to see other companies that have been associated with the COSE process step forward and adopt OpenStep?

I expect to see that happen, and I think that, over the course of the next year, we will see significant movement there. Both NeXT and Sun will encourage that within the industry and among our own partners.

Do you think Hewlett-Packard will step up with the kind of commitment that SunSoft has made?

That’s hard to say. We would certainly welcome that. As you know, HP has already made an endorsement of NEXTSTEP, and we would have to talk to them about whether they would increase their endorsement.

Ins and outs of OpenStep

Moving on to the future OpenStep product, could you help us understand what exactly it is, and what it will look like?

Let me give you the context. The application environment that we ship today - OpenWindows, soon to become the Common Desktop Environment (CDE) - is a procedural environment. We believe that we will be shipping that procedural environment through the end of the century and probably beyond. We have customers who have either lots of legacy stuff or no desire to retrain for objects.

But we also need a solution for customers who do want to shift to the object paradigm. We don’t have that today, so we’re adding the OpenStep standard. Now, instead of one application environment, there are two. In fact, there are three, counting WABI (Windows Application Binary Interface).

It’s like this. If you write apps to the Windows API, they run on Solaris in the WABI environment. If you write apps to the procedural environment, they run in the CDE enviromnent. If you write them to the object environment, they run in the OpenStep environment.

Now it may be that the dominant personality for someone is CDE, and they never run WABI, and they never run OpenStep. Or it may that the dominant personality for someone is OpenStep, and they don’t bother running WABI or CDE. What we have to do is make sure that there is smooth interoperability. I need to have all these windows on the screen at the same time and be able to cut, copy, and paste between them.

Which environment will the user see? Does OpenStep include the Dock?

If you’re in a CDE-dominant environment, it’ll basically look like CDE, but you will be able to run Windows apps and OpenStep apps. If you’re in the OpenStep environment, you’ll basically see the NEXTSTEP environment, including the Dock.

Now, over time, we may be able to have a Dock concept that spans both environments, and maybe even the Windows environment. There’s nothing technically that says you can’t do that. And that would actually make users’ lives that much smoother. We wish probably that these different personalities all had exactly the same GUIs, but we live in a real world.

It is similar to IBM’s situation, where you’ve got an OS/2 personality and a Windows personality and, someday in the future, you’ll have a Taligent personality.

But the key point is that you will get OpenStep with every shipped copy of Solaris.

You get Solaris and you get the whole thing. Clearly, there are installation options. You can decide to install one thing or another.

For third-party developers, both NEXTSTEP and Solaris, what do you recommend they do today?

Clearly, NEXTSTEP developers should not only keep developing, but they should feel better about it. As for our CDE developers, we are not saying they should all switch to NEXTSTEP today. In fact, if they want revenue today, Sun’s current developers should keep building CDE applications. What we’ll find is that more and more people will convert over time. Initially, that will probably be more the in-house developers than the independent software vendors.

And in the longer term?

There will be early adopters, starting now, who are very interested in objects and will see the benefit of moving to that paradigm. But the bulk of customers will probably stay with the procedural environment. Over time, more people will move to OpenStep, and, by the end of this decade, more people will be using objects than the procedural environment. You’ll have people who are at one end of the spectrum and people who are at the other end of the spectrum.

Kernel vision

Can you clarify which parts of NEXTSTEP are included in OpenStep? What about elements like 3DKft and RenderMan?

The OpenStep spec will include, if not every NEXTSTEP API, a robust enough set that 90 percent of the applications that are written today can run on top of what we define as the OpenStep spec.

You have to realize that NeXT is an evolving system, and some pieces of the system are more mature and customer-tested than other pieces. Clearly, the parts that we’re most interested in are the parts where customers have actually used them to develop mission-critical apps. If there’s something that is more recent and hasn’t really been used, it would perhaps not find its way into the OpenStep spec. There may also be a few cases where we work on parts where people want to see enhancements or changes.

How difficult is it technically to take those parts of NEXTSTEP and integrate them with Project DOE?

We don’t see that as a very big difficulty. One of the aspects of DOE and the OMG CORBA specification in general is that it was designed to be very general and to accommodate a variety of object models. We see a pretty good fit there with NEXTSTEP technology.

Okay, but there are some differences. What about the issue of NeXT’s use of Objective-C as opposed to C++?

The OpenStep APIs are today defined in terms of Objective-C. SunSoft will support Objective-C as another language offering. Many apps are written even today where part of the app uses Objective-C and other parts use C++. With Improv, for example, the back end is in C++, and the GUI part was in Objective-C.

Part of our vision with OMG is that you raise objects above the language dependencies, and you define interfaces to objects in terms of the Interface Definition Language (IDL). Then you have bindings from IDL to a variety of languages. You shouldn’t have to know what particular language an object is implemented in.

In the procedural world, I can call a library, and I don’t know whether it’s written in C or assembly language or Fortran or Pascal. In the object world, we have to get to that stage.

Another issue is the imaging model. NEXTSTEP runs with the Display PostScript (DPS) server and Solaris uses an X Windows DPS server.

If you are going to have X Windows and DPS windows on the screen at the same time, you don’t want two different mechanisms to handle those windows. We will support the same DPS calls that NeXT does. Now, for some of the things, like the window management, NeXT has extended DPS. We will stick to the Adobe DPS. For the window management, we will do that through the AppKit calls, which is what everyone does anyway.

Resource Allocation

All this may be feasible, but it still takes work. What are the resources at NeXT for the SPARC port and the OpenStep implementation?

Well, first of all, welcome to the software business. NeXT has a lot less to do than they used to. In terms of the native NEXTSTEP port to SPARC, yes, NeXT has work to do. They’re actually getting pretty good at that, now that they’ve done Intel and PA-RISC. They’re building up some expertise. In terms of the OpenStep implementation on Solaris, we’re clearly the experts on Solaris and DOE. My group will provide the lion’s share of the work required to port to Solaris.

We’ve talked about different components of NEXTSTEP. What about different versions, such as future releases beyond 3.2?

The companies expect to work closely together as we go forward, though we are not committed to staying in lockstep. OpenStep today is a good core set of interfaces, but clearly you don’t want to stand still. NeXT has a lot of good ideas that we at Sun are in a good position to work with them on. We can either adopt those or do our own implementation when they come out.

Is this relationship your major responsibility here at Sun?

What I run is the DOE program, which was a preexisting program, and I took it over about four months ago and consolidated it. Prior to that, I was running the CDE program.

There is a lot of speculation that this is what you had in mind all along when you left NeXT, or even that you were actually sent by Steve Jobs. What’s the truth?

You’ll remember that at the time I came to Sun, NeXT was a hardware company. Clearly, there was no possible way that, given that situation, the companies could have gotten together. It was not even contemplated at NeXT at that point to become a software company.

So if you are asking was this all somehow planned out, absolutely not. At the same time, once NeXT did decide to become a software company, that set the stage for the possibility of synergy between Sun and NeXT.

In this deal, NeXT becomes a technology provider. In your view, to what extent do they continue as an independent platform provider and operating-system company?

At SunSoft, our business model is to do both - sell a complete operating system and also license people the technology - and we find it a very viable model. We will sell you an operating system, Solaris, and that’s a very good business. We will also sell you component technologies, NFS or the Common Desktop Environment or whatever and that’s a good business as well. It works for us, and I think that could be a fine business model for NeXT as well.

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.