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.---xj40dkcfea73---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.

http://www.artima.com/intv/froth.html

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.

Rob Gingell asks several interesting questions in this paragraph:

Early on, as the platform was being created, keeping the froth minimal was probably helpful in bootstrapping the marketplace. With the marketplace seemingly well-developed at this point, do we initiate more advancement by only bringing things through the JCP, or do we do things in products and then bring them to the JCP? Or, do we develop some things in the JCP that represent commonly agreed-upon attributes of new capabilities, and sort out the not-agreed-upon parts in products? How does one best find what practice to codify without doing some of it?

What's your opinion?