[
Lists Home |
Date Index |
Thread Index
]
It's just management. Provide a rule/policy that discriminates
project deliverables and their processes by project type.
If a project is producing a specification, that has different
processes and deliverables than a standard. Prior to the
W3C-engendered perceptions of 'standards', this was well-understood
in the engineering world. As-built vs as-designed, design notes
vs product documentation, etc. are part of any reasonably sized
engineering corporation's design methods. It all looks like
YAGNI to someone itching to code, but for very large systems
development, it is very necessary. The W3C correctly labels
what it produces as specifications and that is indeed where
it does its best work. It does nothing to correct the mythInformation
in the press or here that it is a standards organization, something
it would do, if it did it, badly.
IP is now a top concern because some systems within the ecosystem
decided that the cost of software should ideally be zero. Other
parts of the ecosystem looked for other ways to recoup their
energy budgets and IP is a way to do that. Emmninently predictable.
We're managing a world we made even if unintentionally. That
doesn't mean it is in a fixed form. Quite the opposite. If we manage
it better, it will evolve into better and perhaps higher forms.
If we keep using myths to make decisions, it will devolve into
competing camps for every decision and every opportunity. Thus,
it becomes a pack of dogs where the only reliable rule is force
and what we piss on.
Rule of thumb: if a consortium announces a project to develop
a standard and the sign-up list doesn't include at least two
to three recognized vendors for products of the kind that is
to be the output/deliverable, the consortium is just marking
territory (pissing on it). If after a year of reportable
work, a working product has not been produced, they are dogs
jealously guarding a bone. A specification, on the other
hand, has a research phase that can alter the evolution of
the product dramatically, but if steady progress is not
shown, they are just digging holes to bury the bones in
so other dogs won't benefit from their work.
len
From: Michael Champion [mailto:mc@xegesis.org]
Well, the W3C flourished in the ecosystem of the 1990's when there was
a lot of intellectual capital floating around and the trick was to
figure out how to extract the common ideas and expose them in a
standardized way. Now the trick is to take this to the next level
without having the ideas spend 20 years wandering around academia
accumulating value by accretion and selection. I completely agree that
the W3C process is demonstrably not up to that task, but I don't agree
that its former reputation is based on myth.
I'm not sure whether the way forward is by figuring out how to make
design by committee actually work (and be allowed to fail, and forced
to prove itself) so that software gets written and standards can
advance in a short timeframe, or to abandon all hope and come back in
20 years or whenever there are enough good ideas that need to be
standardized rather than forced to learn to survive in the wild.
|
