[
Lists Home |
Date Index |
Thread Index
]
Ok, but let's differentiate scale and reach as
we have here recently. If I want to reach
as many customers as possible I have two choices:
1. Weaken the specification or standard to cover
only the most common features as interpreted safely
by each player (meaning, no critical semantic side effects as a
result of local interpretations). This is essentially
the minimal victory strategy. HTML works because it
is mostly boxed formatting, the variations of actual
rendering are minor and don't seriously impair the
meaningfulness of the content.
2. Create a highly customizable specification or
standard with as many optional features as necessary.
This is the approach that XML abjured but SGML embraced.
It works but is costly (try to create a product for
a single market that is actually a lot of little markets
you have made one by abstraction rather than function).
Given a complex product, however, this is the way to go
until the market converges and complexity is subsumed
in a commodity product.
I think if one is creating a standard, buy in is
important but it is buy in among a select group
of domain vendors who have a market. If I am creating
a specification, I want buy in among the likely implementors
but also I want as many potential customers as possible because
the goal is to create a market. Unless you are certain
of the customer base and have first mover advantages, run
that one open as long as you are certain of success in
getting it implemented.
In the first case, the problem is the vendors attempt
to make the standard favorable to their product so they
have the least to do for the most gain. In the second
case, someone will want to dominate the specification
process if they have other advantages they can leverage
to capture as much of the market as they can as it emerges.
If the process is open, that can be seen. If not, it
can't. No news there. While I believe that standards
processes should to the maximum extent possible be open,
no such requirement exists for specification processes
which by their very nature are disruptors. That doesn't
mean one should close them. It means dealer chooses.
This is why I emphasize leadership experience:
Open standards processes with too many non-market
players can fritter away a lot of time and energy. On the
other hand, if one closes the processes and there is a
lot of customer interest, they will open up elsewhere
and you will be shut out. That is exactly what has
happened to my company. We have been very slow about
blogs and open communications, so our customers formed
their own Yahoo users board for their own
community. They purposefully exclude the vendor.
That's one of the lessons the MBAs should learn
and right fast about the web. It doesn't just route
around one; it builds a wall around what doesn't work
with it in a mode of trust exactly like an ecosystem.
It isolates non-cooperators; it doesn't kill them but
they may suffocate.
The problem of openness is the tacit assumption that
only one game is in play. In fact, today multiple
true and faux standards and specs organizations are
attempting to organize the same markets with varying
successes. This is when it doesn't come down to
the 'smart people' or even the 'right people'. It
can come down to who can hold their breath the
longest. The 3D market is a splendid example of this.
The money in 3D is in games and that is where standards
are least likely to take hold and specifications proliferate
like park pigeons. A standard must have a substantial
and clear payback or it won't thrive. A
specification is, well, speculative, so as in music,
a gambler's game.
len
From: Wolfgang Hoschek [mailto:whoschek@lbl.gov]
It appears that "scale" aka "organizational size" is at the heart of
the problem.
A spec process for a small audience is easier to manage than one for
a large audience including all the heavy weights. Having more
participants means having more differences wrt. perspectives,
backgrounds, priorities, timelines, strategies, policies, etc.
Getting broad buy in and rough consensus before having running code
makes it more likely agreements and a spec will eventually emerge,
though it unfortunately also increases the odds for a spec that may
be bloated, fuzzy and ultimately of dubious quality and merits. On
the other hand, having running code first implicitly puts someone
into a dominant riding seat, and while it increases the odds for a
focussed quality spec, it reduces the odds for broad consensus across
many heavy weights. It's a difficult chicken and egg problem.
Ideally, the "running code" and consensus building process would go
hand in hand in parallel at multiple participants, and inform each
other continously. But that's easier said than done when working "at
scale".
Wolfgang.
|
