Unplugged: Sun chief engineer Rob Gingell, Part II

Rob Gingell

Rob Gingell is accustomed to herding cats.

He has spent much of his 17-year career at Sun Microsystems trying to get the other technology gurus at the company to follow his lead. As the chief technologist for Sun's system software group, Gingell ran herd on Solaris, Java, and the entire portfolio of servers and development tools. Four months ago he was appointed Sun's chief engineer, and now is responsible for crafting a cohesive strategy as Sun moves from it first-generation systems based on Unix to a second generation oriented around Java.

Gingell talks about his desire to open source Solaris and intermarry it with Linux. He also discusses his focus on other parts of the software stack, especially Java, and why he believes that Sun will succeed at time when Solaris and SPARC are no longer the company's crown jewels.

Get an inside look at Sun's strategy in this final installment of our two-part interview with Gingell. Click here for part one of this interview.

Tech Update: You've said that the future of Sun is more about Java than the somewhat commoditized hardware and software that Sun sells. How do you build an ecosystem for Java?

Rob Gingell: [Gingell draws a circle with three planets on an orbital path: developers, volume, and applications] For platform suppliers like Sun, this ecosystem defines life. As you get developers, they generate applications that [platform suppliers] must mine to produce volume. It's a positive feedback loop that works when it's going up and when it's going down.

Digital had to buy apps to cause them to appear there [points to the "applications" planet] because the volume wasn't sufficient; that's how you knew that Alpha wasn't going to matter. As soon as you see anybody having to artificially prop up one part of the [ecosystem], it's all over. That's a tragedy, right? Digital was always great at doing beautiful instruction sets from an aesthetics standpoint. It's a real tragedy in some way.

Tech Update: You're not the first person to tell me this. Over the years I've heard developers talk about Digital products like Alpha and StrongARM, and how it was like breathing pure oxygen.

Gingell: Some of it was the culture at that company, but everybody has heard about technologically superior failures. It's not enough to be wonderful in that one dimension. You have to figure out how you work within the ecology.

When I say we're working on our second-generation systems, our first generation was about practicing this loop with Unix. We have anywhere from 300,000 to a million people operating in this space [points to the "developer" planet]. The Solaris applications catalog is essentially 100 percent of any Unix applications [points to "apps" planet] that exists. You can't find Unix applications that aren't available on Solaris. Out of that potential energy, we achieved a 40 percent market share [points to "volume" planet], and that's what we do to drive our revenue.

When we talk about the next generation, we're just talking about another instance of this circle that's based on Java, where the developer number is already at three million. The apps space is only beginning to appear in some areas like your Java phone. There are various obstacles to being successful that we haven't worked through yet. Certainly, some fraction of our server business is being run by this [Java ecosystem] to the extent that it's driven by application servers. All of our initiatives around things labeled SunOne are really about translating that into market share [points to "volume" planet] for us so that we can start to see this develop into a self-sustaining ecosystem.

Tech Update: How difficult will it be for Sun to shift gears?

Gingell: The potential energy for this is just phenomenal compared to the previous edition [of Unix], just based on the number of developers alone. The challenge is, does Sun reapply its business model to this different collection of technologies or does it do what most hardware companies do by following their technologies into commoditization?

That's where the 17 years of business experience comes in. When I got to Sun, we didn't make our own chips. We used the Berkeley operating system, made changes, and sent them back. They ate some of them and didn't eat others. We put them back in when they sent us the next tape, and it was all about building the system and not about having those things.

In that sense, I've always viewed things like Solaris and SPARC as tactics in this larger strategy of integration. There isn't any other story that has this same starting point that you can find that we've already created out of Java. The question is, are the individual primates that make up Sun so wedded to the technologies they've been laboring away on for twenty years that they can't actually see the forest that they're part of?

Humans hate change. They hate disruption. All institutions act to suppress it. This is a case where we need people to pick up their heads and say, "I'm a chip designer. I can actually design any chips. Not just SPARC chips. I design chips that go inside systems and do other things. I can do other sorts of things. I am an operating system builder and I know about OS technologies. What I really know about is computation and computing in general."

The company that can harness all of those skills is potentially a much richer source of product possibilities than a company that can only do software or can only do chips or can only do one of the other things.

Historically, we've lived on the notion that innovation lives elsewhere, and no matter how big or successful you are, the total number of smarter people is greater than you somewhere else. That's why we were always offering away some of our value-added technologies, from NFS on down. Every Unix in the world runs almost all of the crap that's in Solaris that's architecturally important. The thing they don't run are the specific code changes we've made in the last two years. Even if we let everyone look at our source all the time, it will still be true that the real advantage we have is our capacity for doing that kind of work, not the residue of the work that we've already finished. We don't pay our programmers for the code they've already written. We pay them for the code they haven't written yet. That's really the value to us.

It's what they're going to create. Not what they've already created which does have value to us, but it's a lot like movies. The first day a movie ships, it's worth eight bucks a shot. But a couple of weeks from now, it's four bucks a shot and two years from now you'll be watching it free on television. Or maybe just a year if it didn't get that much of a box office draw. A lot of the code itself is a "What have you done for me lately?" kind of asset. It's the capacity to make the code that's really valuable.

Tech Update: Let's go back to open sourcing Solaris and the supposed marriage to Linux. IBM is already involved in making things happen in the Linux world. This would certainly be a new thing--Sun playing more of a role in that ecosystem. When you said you wanted to see Solaris open sourced, is that a reality? And given Linux's momentum, does it matter?

Gingell: Some parts of it have already been open sourced. NFS for instance was open sourced a couple of years ago, and there's a project at the University of Michigan that does that for Linux based on our stuff. People--except for those who weren't born yet--lose sight of the fact that Linux is the latest version of Unix. The real key thing here is that there's always been a community around Unix. There hasn't been an intellectual property protection model that you can use as a flag like there is for open source.

The thing I really see when I talk about open-source Solaris isn't open sourcing per se as much as [the fact that] this community operates by trading code with each other. That's the way we worked in the 1970s and 1980s, and it wasn't until when all the companies we worked for got into siege mode that we stopped doing that and even then, we still did it at some low-grade rate. Just about everything that started the Unix wars, which was based on AT&T picking Sun OS as the basis for going forward with Unix, everybody now has it. After the war was all done, they got it all anyway. So, you almost wonder what the war was fought about to some extent.

A lot of this is about ending isolation for one group of brains from another group of brains, which is nothing more than a residual effect of that balkanization period. It's certainly true that there's a window of opportunity where, if we [Sun] do nothing, [the Linux] community will eventually do everything we would have offered them. How much of that has already happened? Well, Solaris is actually the result of a lot of community work. There's a couple of hundred copyright holders to the material that's in Solaris and not all of them have agreed to operate according the Linux community's rules. We don't own it all. We don't have the ability to say, "This thing you gave us, we're now going to give away to everyone else." That wasn't the deal we struck.

The really valuable thing to us is this community. Not all predecessor communities have agreed to operate on the same IP principle that the Linux community operates on. Getting by that is a real impediment to throwing open the kimono and saying, "Here, Solaris is now open sourced." So, some of it has happened, and we are working on the rest of it. We may never be able to do it all because we may never be able to reach an agreement with the originators of the stuff. In short, the answer is that we're just sort of chipping away at it.

Tech Update: But what difference would there be between Linux by Solaris, and Linux?

Gingell: "By Solaris" is a reference to Team Solaris, which is an asset that Sun has that consists of about 3,000 coders.

Tech Update: But what would be the difference in the final deliverable? If, five years from now, I got Linux by Solaris, how would it be different from any other distribution?

Gingell: I don't know how to answer you specifically because, at any point in time, it will have to do with the problems that we worked on in the last two years that maybe nobody else worked on.

Tech Update: But it's an open source thing. You'll be beholden to contribute that back to the Linux community. Maybe you can do some value-add, but if you follow the same path that Red Hat just took, then we are right back to the balkanization.

Gingell: Earlier, you observed that we're talking about a commoditized space. So, all value-adds to a commoditized space are transient. Let's go back to the original part of Unix. Up until the mid-1980s, Unix operated according the same basic rules that Linux does today. So, why did Sun become preeminent in Unix despite operating under that rule? We became leaders of a community because we did more than other people that the market considered important, and we were effective, not just voluminous, contributors.

I maintain that the 1,000 engineers that are a part of core Solaris should retain that capacity. The capacity is invested in the team and not in the code. Part of open sourcing Solaris is a declaration--I'm overstating this--that I don't care about the code they finished. I pay them for the code they haven't written yet, about solving customer problems that we will be there to solve first--which is why you as a customer want to relate to the people that are setting the pace. The fact that you can get it from anyone else is true. You won't have to go see the movie day one. If we all wanted, we could wait six months to see Star Wars  for three bucks. Why did we all show up day one to pay ten bucks? It's because being first sometimes matters a lot.

Tech Update: So, do you believe that in the value-added Linux space, where customer problems pop up, you'll be able to solve them with Linux much quicker than anybody else?

Gingell: In this world where OS layers are commoditized, our capacity to do the engineering at the OS layer when needed will be better than anybody else's. That's historically been so. IBM's Unix efforts have been "laughers" in a lot of cases. They're the people that couldn't get [memory allocation] right, for God's sake.

Tech Update: So, you'll be taking on IBM here more than anybody else?

Gingell: No problem. Bring 'em on.

Tech Update: Red Hat is also very committed to that sort of coding capacity. They just opened a campus in Massachusetts and filled it up with nothing but programmers. Based on what you're saying, it feels like this is going to turn into a programming war.

Gingell: I agree, and that's cool. That's not a loser for us. Let's assume that I'm just the number two guy for this commoditized technology. Well, it's like being number two in transistors. Who cares? I'm gonna get it. If certain customers don't perceive that there's a huge amount of value there, the fact that I lose one or two of the battles doesn't actually matter.

Tech Update: Well, it's a big battle if a lot of your business is based on the hardware component. Now you're making the concession that the hardware component is less important. So it's a gamble.

Gingell: Be careful. Incompetent resistors become noticeable very quickly. It's not that it's unimportant. It's undifferentiating, and there is a subtle but important difference between the two.

Tech Update: But you're not going to sell an incompetent resistor.

Gingell: Well, not for very long.

Tech Update: But, if someone wants an Intel box with Linux by Solaris, that incompetence is not really an issue, is it?

Gingell: People ask for Linux when they're dealing with applications running in the Unix instance of that ecosystem we've been talking about. But people don't ask for a Linux or a Solaris when they're running the Java version of this ecosystem.

Most of the developers are in the Java ecosystem at this point. [Gingell draws a graph with time on the x axis and volume of apps on the y axis. He plots two "hockey-stick" curves that are parallel to each other and that level off at the top. One just takes place later in time than the other.] Here's the Unix ramp [points to first curve] and here's the Linux ramp [indicates later curve]. You can't make the extrapolation that Linux applications are going to ramp past the plateau of Unix applications. It's not going to go past that line. It's really easy to catch up with thirty years of history, particularly when you've got the volume hardware base [editor's note: Gingell is speaking of Intel's architecture] on which to do it. You can go to market with a cost reduction, which is what makes the Linux instance of the ecosystem interesting.

If the Linux community had built itself on Alpha instead of on PCs, we wouldn't be talking about it today. It wouldn't have had the volume to make any difference. The reason we're talking about them is that the volume instruction set in the marketplace finally has a unique application binary interface (ABI) on it. Interestingly, Red Hat is fragmenting that ABI, which, personally, I think is an incredibly stupid idea. All that does is balkanize what should otherwise be a sweetheart story. If it proves to be true that Sun only stays as a Unix company, then of course we're victimized by anybody that does cost reduction in the Unix space. But the deal here is that we ain't staying there.

We're going to this other space [points to his diagram of the Java ecosystem] that's three to ten times larger. In my view of the world, people don't ask for Solaris or Linux. They ask for the things to run the apps they have now. Linux co-resistors or Solaris co-resistors might be what the manufacturer of the device that runs those apps chooses to use, but it's an undercurrent. It's like the steel supply industry to the automobiles. Yeah, there's a lot going on there and they have they're own magazines and stuff like that, but those of us who buy cars don't pay any attention to it. We're beneficiaries of this. I can assure you that the Steel Producers of America Industry Association Magazine has all ten thousand subscribers of people that the choice of steel matters to. The industry probably has its own trade press, but none of us car buyers care.

With respect to our business, the reason some people still care now is that they're still tapping the Unix version of the ecosystem, and they're not into the Java ecosystem yet. [Gingell draws three ecosystems: one for SPARC and one for IA-32, both of which are in the same layer, and then one for Java, which is in a layer above the other two.] So, we have a Unix version of this circle that was SPARC, and there's the Unix version of this circle that's IA-32, and there's the version that's based on Java Virtual Machines (JVMs).

If we pull this transition off and this layer (pointing to the hardware layer with the SPARC and IA-32 ecosystems in it) becomes non-differentiating, we have two opportunities. First, we can operate within the hardware layer somewhat indiscriminately in terms of architectural investments that our customers make. For example, you don't know from production run to production run that we use a different manufacturer of disks or resistors or things like that. You won't know which of these components we're using or even how many.

Tech Update: Well, you might know based on cost.

Gingell: But they're both free. There's been no price differential for years. Nobody pays anything for Solaris.

Tech Update: But for the hardware, they do.

Gingell: Well, that's true, but there's not an instruction set-based difference behind that cost. It's really related to volume. They have higher volumes, and can do more cost reduction. That's what Sun did to SGI. Rather than beating them at 3-D graphics, we beat the crap out of them by cost-reducing 2-D graphics over a larger volume, and that made SGI irrelevant. Eventually, we did our own 3-D solutions when SGI was wounded and just limping along. You're never removed from the effects of economics in this space. But those economics only matter when there are architectural differentiators. They're not differentiators in a world where that's no longer the basis for the architecture.

Where could we screw up? Suppose we don't quite reach escape velocity and we land here--midway between the hardware and software (JVM) layers--we'll just fall back into the same space only different. Then, the war is a different kind of war. It's a cost-reduction war. It would be a PC economics kind of drill, and somebody has already done this.

Suppose you wanted to recreate Sun in 1999 versus 1982, and decided to use the then most popular chip. In 1982, it was the [Motorola] 68000. In 1999, it was IA-32-based chips. Then, you would have decided to use the then most academically popular operating system. Well, in 1982, it was BSD, and in 1999 it was some variant of Linux. If you combined them and offered a product line, you would then call yourself VA Linux. A 1982 Sun repeated in 1999 is VA Linux. Where's VA Linux now? So, that's not a terribly interesting model.

This process of sedimentation and commoditization is constant in the industry. The only mystery is whether any enterprise can successfully up-level itself.

The measure of our success is based on the fact that we have 300,000 developers in the Unix ecosystem and we have three million in the Java ecosystem. So, which vein looks like the richer place to serve? This one [points to Java] is the place to be. But it's a different world. Before this, there was another plane that was the 1960s and 1970s, which was a world of vendor lock-in. If you had an IBM mainframe in 1970, and you decided to buy Burroughs, you had to be really pissed at IBM to decide to go through the sort of hell you'd have to make that switch.

Gingell: (cont.) Part of the drill that drove both PCs and Unix was the open systems notion that we will lower the cost for you to treat every purchasing decision as an independent one. We only got part of the way there because if you were already invested in a bunch of our products, you were actually bound to SPARC and you have to be kind of pissed at us. You don't have to be really pissed at us because it's not that hard to move. But it's hard enough that you have to be kind of irritated.

In the Java world, where we have the write-once, run-anywhere thing, it may not be perfect, but it so much more closely approaches the ideal in which everybody is actually pretty much the same so that the barrier to switching is practically non-existent--the exception being app servers.

You can wed yourself to an app server if you really work at it, but most of the customer base doesn't do those sorts of things and have shown that they can jump around pretty easily. That means you, as a vendor, have to be excellent at product execution in order to be competitive in this space. You get no lock-in effect at all. That's why having a company that has the capacity to apply a variety of skills to solve problems becomes really important because it will be as close to ideal as we can imagine. You can treat your machines like cars. If you bought a Ford the last time, there's no obligation to buy a Ford the next time. You have no vested interest in choosing Ford again unless they did something as an enterprise that earned your loyalty at some level.

Tech Update: So, it is a programming war. In this scenario, for the stakeholders out there, how does Sun make its money? Where is its source of revenue? Is it because you are growing the entire world of Java itself, and there's royalty you collect on every instantiation?

Gingell: No. There's a growing market where we supply platform products that people use to deploy applications on. That's what a systems company does. We make our money in the Java ecosystem the same way we made it in the Unix ecosystem. Is it because, as you say, I claim that the reason we made all of the money we made in this space is because of Solaris? Nobody buys our naked hardware. Well, maybe 10 percent of our business is that, but that's really inconsequential. The reason people buy us is because of the total systems package, the personality of which is primarily defined by the software. People want to map our accounting to cause and effect, and I know we annoy people by not doing that. But, you have to ask yourself why customers actually buy this stuff. I don't think they're buying it because of the instruction set.

Tech Update: So, you sold Solaris before. Tomorrow, the personality is primarily one of problem solving?

Gingell: The total network environment. There isn't going to be an operating system for the network in the sense that there's an operating system for computers, but there is a logical set of equivalents to that.

Tech Update: I'll agree that on the server-side there aren't a lot of people solving problems in parts.

Gingell: So, are you saying they do it on the client-side?

Tech Update: On the client-side, people are more inclined to buy a piece of hardware and do whatever they want with it. But today, if I'm an enterprise running servers, I get everything from pretty much one guy. So, if I buy from Dell, they sell me the server and they'll put some Windows or Red Hat on it and now, even a database. In that case, Dell is the integrator of the whole solution. Same thing goes for IBM. They could be that integrator for me. There aren't a whole lot of companies that are just out there selling plain vanilla servers to me and saying "go do whatever you want." So, it does seem like the line between hardware and software is becoming more blurred for companies that were traditionally hardware companies.

Gingell: That's partly why a company that has skills that cross the entire implementation domain can prosper in a world that's gray. We can navigate the entire gray space. If all you know how to do is software, well, that's all you're going to be able to do. Even if that's where the value of the system got defined from, in terms of the personality that made you choose it, these things are more expensive than other things you can buy. Why are we in business at all? There's something else to it. That's part of the value proposition that customers see. It's in that integration that isn't called out in a lot of the comparisons that people make. It's about the integration at some level.

Tech Update: So you're saying that the premise of your business is that in a world that's based on the Java ecosystem, where everything is portable and it's easy to switch, the reason people should go with Sun is that it can solve problems faster and better?

Gingell: Yeah. We know that we won't win every piece of business. In the Unix game, we win 40 percent of that business. Because we don't make the whole world of Unix--and it's a shared world--losing you today doesn't mean we've lost you tomorrow. It's OK if somebody else wins the battle. This was part of Digital's problem and ultimately, it's a part of Microsoft's problem. Digital hit paydirt with the VAX/VMS world, which was the envy of the industry in the 1980s. They did for that what they didn't do for PDP-11s, which was make it so that only they could answer your problems. They lost out on the effects of innovation happening elsewhere.

If they were the only ones who could solve your problems, they had to solve your problems. If they didn't get around to you because they were too busy solving the problems of everybody else who got there first, and you got frustrated enough, you left them in a way that caused you never to go back. You left them architecturally. Our circle is a shared thing and we don't need 100 percent of this [points to the "volume" planet in the Java ecosystem].

Tech Update: But the truth of the matter is that even if you don't have 100 percent of the volume in the Java ecosystem, you still get a cut of the action, right? Java is your IP.

Gingell: Well, we've practically open sourced that anyway. The only difference between JVM licensing and open source is that we say you have to stay compatible. An open source license says that you don't have to stay compatible. Compatibility is actually what the Java community cares about. So if you're going to use our stuff you have to stay compatible. Otherwise, there's no difference between it and an open source license.

Tech Update: Was Apache a catalyst in you practically open sourcing Java.

Gingell: The answer to that is a bit fuzzier than many realize. The reason open-source zealots don't like the Sun Community Source License is because it requires that you stay compatible. When they say, "We'd just rather you delete that phrase," we say no.

Since 1997, Java has been licensed on those terms. It's also been true, however, that the process by which Java evolved came with a set of terms that effectively prohibited anybody from using an open-source license. But that's not our intention. The way the JCP is built is that the person who does the work has the right to decide how it is they're going to make it available. After all, they did the work. Whether that's open source or some variant of open source or not open source at all, they can do whatever as long as the terms are not rejected by the Java community.

The change we made recently was to make one of those options open source. Previously, it was debatable whether open source was an option. Some lawyers would read it and say, "I think it can be open source" and other lawyers would read it and say, "I don't think it can." So, we removed the ambiguity and said yes, it definitely can.

Tech Update: So, to be clear, that allowed people to come up with a JVM and distribute it under an open-source license?

Gingell: Literally, not true today. It will be true at some point in the future.

Tech Update: But some companies are actually doing that now.

Gingell: But they couldn't actually prove it because they couldn't run the conformance kits to show that they were actually compatible. When all the dust from this settles, they will be able to do all that.

Tech Update: When will that be?

Gingell: There was a collection of existing works that we agreed to retrofit with the new terms, which are only now being passed by the community onto a subset of the things, like servlets and JSPs, that we've prehistorically done.

Those were the things that were of particular interest to Apache because they were working on them. We agreed to retrofit those and we also agreed that on a going-forward basis starting this fall, all new things are created under that structure. We also said that over an indefinite time period we would retrofit the terms to all previous things, including ultimately J2SE and the platform. But we said that, generally, we would do that when they're being revised because it's actually expensive [due to the engineering expense] to split off test suites from reference implementations. There's a fair amount of work involved in doing that.

So, we wanted that scheduled over a period when we were doing the work anyway as opposed to just having to go through a fire drill to do a year's worth of engineering overnight. It didn't make sense. There aren't a lot of people clamoring to create naked clones of J2SE because that's really a lot of work, but eventually they'll be able to do that.

Tech Update: Do you have any fears that once the dust does settle, that IBM will try to co-opt it or take it over?

Gingell: I have some fears that they will want to try.

Tech Update: IBM has established a mode where if it wants something to go its way, it open sources a huge amount of code. They did it with UDDI, SOAP, and then Eclipse. It's a strategy that seems to work.

Gingell: That's sort of the R.J. Reynolds theory of marketing. Let's find the third world and dump a lot of cigarettes on it. Earlier you were talking about IBM leading a lot with Linux and so forth. I am unconvinced. I don't think IBM really gets it. If it's using communities as dumping grounds to accomplish manipulation, that's not really being part of the community. Dumping does not constitute merit. It is entirely possible that an initial large contribution is sincerely offered as a large contribution, and they are going to continue to keep it updated. But, what you just described as a motive for doing that was to manipulate. I don't think you can genuinely integrate with a community where your motive is manipulation. Your motive has to be to operate as part of that community. If you do anything else, the community will find you out.

When we talk about open sourcing Solaris, the idea isn't that we're going to ram it down everyone's throat. We're saying, "Look, you guys are trying to do a bunch of this stuff. We already did that stuff. Take it. Change it. Whatever." What we're interested in, in the end, is not that you took our code as much as that the collective product could be a basis on top of which we can build product too. If you don't take it, and we think it's a really important part of our business, we're just going to keep maintaining it. That's OK. It's allowed. I'm entitled to be different if I want.

Back when I first talked about giving away Solaris about four years ago--during one of the periodic "IBM talking to Sun about using Solaris" conversations- everyone here was like, "Gasp! IBM will see everything including the secret sauce!"

First of all, it's IBM. I would love to drop my code on them because you know what's going to happen. They're going to stop and stare at it for a while and wonder, what the hell are we doing? They're going to do anything but compete in Unix at that point, and that's because it's IBM. This is where the collection of primates becomes important. If you operate with the foundation belief that you can only interact with something because you control it, then I don't see how you are going to succeed in operating by merit.

Sun has been, and arguably still is, the leader in Unix. We've never owned it. It has never been titled to Sun. Never, ever. It has always been someone else's license. We've led entirely through merit.

As it happens, we do own Java. We created it. We own it primarily because an owned thing can be protected. The people who own Unix can't actually do anything to legally protect it because they're beholden to all the people they'd be defending it from. So, what else can they do?

I think IBM still actually wants to be in control. When you ask me if I worry IBM will try to get control, yes, I worry they'll try. I don't actually worry that they will be successful because if that is in fact a motive, they'll be found out. They may do some damage before they're found out. How long will they get away with it and how much damage will they do? I don't know. But in the end, you have to have some faith in democracy.

In the end, democracy usually wins even though it's periodically more inefficient than other things. Fundamentally, people ain't stupid. They'll figure out what's really going on.