Artima.com has published Part II of an interview with Sun Microsystems' fellow and chief engineer Rob Gingell in which he discusses the pressures on vendors to both create froth -- to add value on top of standards -- and maintain compatibility in a multi-vendor industry.
Here's an excerpt:
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.
Artima.com has published Part I of an interview with Sun Microsystems' fellow and chief engineer Rob Gingell in which he discusses open source licensing, source and binary compatibility, binary standards, and the Java Community Process.
Here's an excerpt:
The Unix industry was regarded as fragmented by customers because you couldn't interchange the binary artifacts between systems, either in whole or in part. Yet we had all those Unix standards, and everyone claimed to conform to them. So what went wrong?
Well, in some ways, nothing?only, we had an audience mismatch. Unix was very successful in having a technology standard?source code was relatively portable. Linux's rapid rise is in part due to a ready-made set of applications, and its historical evolution was partly driven by finding an application it couldn't run and then adding what was needed. The programmers actually did, and largely do, enjoy "open systems" in Unix.
End-customers, however, did not. For them, the Unix standards have a similar import that steel standards have to a person trying to buy a car. No one cares about them explicitly, nor makes a purchase decision based explicitly on them. The JCP manages Java in both spaces, providing both programmers and end-users of their work the benefits they're seeking.
