Javaworld:

Sun is now an active Linux vendor, and you had mentioned in previous interviews your desire to merge Solaris and Linux into something like SunLinux. Do you imagine SunLinux keeping a certain edge over other Linuxen? If so, would that not cause a fragmentation in the Linux market - for instance, some things, such as Java VMs, might run on the Sun variety, but not on other Linux species? Conversely, if Sun is not adding significant capabilities to its version of Linux, what advantages will SunLinux have over, say, RedHat's?

Rob Gingell:

Your question gets to the fundamentals of how a multi-vendor industry operates for the good of a common customer base. The "open-systems" promise to end-customers was the ability to treat every purchase/deployment decision as independent of all others. There's no vendor "lock in." Indeed, customers have vendors locked in by the standards that they hold the vendors to. That's the ideal, in steady-state.

The problem with that ideal is that the needs don't stay constant, and suppliers are constantly approached by customers seeking improvements. Products improve by such things. If a customer is genuinely dependent on having a capability, they're locked in to those who supply it until, or unless, everyone supplies it.

Here's the basic conundrum: If you only implement the standard, you are not solving any new problems. If no new problems are solved, where does the evolving "practice" come from that finds its way into new standards? If you use a new thing, aren't you thus locked-in? How do you meet new needs without doing a new thing?

The way life works is that, assuming a shared initial condition, some derivation occurs, often in cactus-like fashion across an industry through competition. With time the economic benefit of standardization is sought to codify what has emerged as existing practice. If the derivation branching gets too large, we criticize it for being fragmented. If the derivation is zero or too small, we criticize it for being stagnant, non-innovative. There's a happy medium in which the "froth" ahead of the standard is progressing the industry but without doing damage to the base of commonality that defines "a marketplace."

It's useful to remember [that] we [at Sun] created our operating systems group not to make an OS as such, but rather to be able to competently build systems, including the ability to engineer at the operating system level. Until about 1985, we largely kept Sun's UNIX as a set of differences to whatever the state of the BSD distribution of UNIX was. Around 1985, though, the weight of our differences led to a flip such that we treated new Berkeley distributions as source material to be used to update or contribute to our source base. With time, we accumulated an operating system.

In a hypothetical world - in which the UNIX community meant largely a set of shared source code - the reason Sun would continue to have an OS group is the same reason we had one in the first place: To be able to create the products we make working at all levels of the system. Sun now has the best team in the industry. The ability to direct those resources to problems that are important to us is valuable, far more valuable than the residue of software that results from having directed them to be there. We would indeed argue through our sales force that our rendition is better, but we'd make that argument based on our ability to create and maintain and evolve it, and less on its uniqueness.

That isn't a terribly new idea: NFS was the first Sun-originated addition to UNIX as a supporting structure of distributed computing. We immediately made it available to all comers employing the practices of the day. The other thing we did, and a thing we mumbled to each other in the hallways, was that we did it almost entirely "behind the curtains" - "more vanilla than thou" was an expression of pride as a result. NFS was also remarkable in its transparency, and the systematic approach taken in working behind the standard interfaces, although it cut corners on obscure pieces of the standards that were inconsistent with, or obstructive to, the presence of networking.

In creating NFS, we did "fragment" the source code technology of a UNIX implementation by introducing a variation. We acted to close the fragmentation by making [NFS] available to everyone, and we also did it in a fashion that largely worked with, instead of conflicting with, the expectations of existing applications. There was no fragmentation of binaries, nor of source code - making the work sharable across the technology space of the industry.

Currently, we expect the most growth in applications which are built around the network, and thus not really applications of a single computer. Java is the primary way that will happen, and the developer pool around Java technology already vastly dominates that which UNIX has ever had. We don't tell anyone to convert to Java technology - this isn't about changing UNIX to something else as much as it's simply recognizing that new application forms are being created, forms which are largely additive to the world we already have.

But that doesn't make the fragmentation question moot. It applies to Java technology and to the UNIX environment that we're most likely to use in fabricating systems products. Whatever the domain, it's an exercise in tension management, and also one of philosophy: Do you innovate in a manner that is destructive of the tension or supportive?