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.

[an error occurred while processing this directive]

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.

Previous page |   1 2 3 4 5	| Next page

[an error occurred while processing this directive]

[an error occurred while processing this directive]