The Artima Developer Community
Sponsored Link

JCP Watch
Froth and Compatibility
A Conversation with Rob Gingell, Part II
by Frank Sommers
January 20, 2002

<<  Page 2 of 5  >>

Advertisement

Innovation versus Fragmentation

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

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

The problem with that ideal is that the needs don't stay constant, and customers constantly seek improvements from suppliers. Products improve by such actions. If a customer genuinely depends on a capability, he or she is 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 don't solve 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?

Here's how life works: Assuming a shared initial condition, some derivation will occur, 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 grows too large, we criticize it for being fragmented. If the derivation is zero or too small, then we criticize it for being stagnant, non-innovative. There's a happy medium in which the "froth" ahead of the standard progresses the industry, but doesn't damage the base of commonality that defines a marketplace.

It's useful to remember that Sun created its operating systems group not to make an OS as such, but rather to be able to competently build systems, including 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 Unix's BSD distribution was. Around 1985, though, the weight of our differences led to a flip such that we treated new Berkeley distributions as source material to update or contribute to our source base. With time, we accumulated an operating system.

In a hypothetical world—in which the Unix community means 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 products that work at all levels of the system. Sun now has the best team in the industry. The ability to direct those resources to problems important to us is valuable, far more valuable than the software residue that results from having directed them 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, maintain, and evolve it—and less on its uniqueness.

That isn't a terribly new idea: NFS (Network File System) 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. We also did it almost entirely "behind the curtains." NFS was also remarkable in its transparency and its systematic approach to 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 conflicted with, the expectations of existing applications. There was no fragmentation of binaries or source code—making the work sharable across the industry's technology space.

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

But that doesn't make the fragmentation question moot. It applies to Java 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?

<<  Page 2 of 5  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us