The SunLinux edge
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?
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
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