[
Lists Home |
Date Index |
Thread Index
]
Len,
Fabulous rant from the inner sanctum.
We're just misunderstood, abused and undervalued and paid!
After all its much easier to put a team of 30 engineers in a sealed room
for two months,
get them to build it, file all the IPR, then submit it to your favourite
pet non-profit
organization as a draft standards specification. Sometimes you can even
own the
non-profit too! This ensures everything is less messy and maintains a
veneer of
due process and openness that customers find comforting, and its mostly the
same engineers as are in those "other" organizations anyway, so what is the
difference?
Cheers, DW
============================================
Bullard, Claude L (Len) wrote:
>Lattice can tell their own story. I *believe* that will be
>a story of cooperation and interoperability perhaps based
>on CDF.
>
>The case of real contention in the 3D world is over
>VRML97. It has become moribund but companies that don't want
>to move to X3D, usually objecting to XML, are extending it
>with proprietary works and calling that standard.Note that the
>players doing this are not consortium members. This strategy
>plays the market and the customers for suckers.
>
>Standards are slow moving. Specifications don't have to be.
>Conflating the two has been a source of slowness because
>different processes rule these distinctly different works.
>The W3DC has improved its speed for putting out specifications
>by using the inner ring/outer ring methodology I mentioned
>earlier, but the improvements have been of late, and not as
>noticeable in the beginning when the fight over the next
>generation design was fierce and awkward.
>
>Here are things that slow us down:
>
>1. The game: companies and individuals sign up on the
>specification lists and after a honeymoon of 'cooperation'
>begin to argue endlessly without consensus. A strong chair
>and a clear process are needed, and the fact that some parties
>will walk off in a huff claiming they have been hoodwinked
>in some way is why that process has to be clear. It also
>has to be an acceptable outcome.
>
>2. Open lists without membership or participation agreements:
>Too many people come for the endorphin rush. They want to be
>heard regardless of the impact. They are inexperienced and
>ignore the process and the goals. Without membership, they
>have little incentive to cooperate and without the participation
>agreement, are not bound to the process. Believing they can
>run to slashdot to plead their case, they keep working against
>the process. Being asked to leave the working group has to be
>an acceptable outcome.
>
>3. In medias rex: technologies worthy of standards are already
>robust. Each company has its own version and that leads to the
>problems in item 1. The technologies are similar on the surface
>but not in the details. No one wants to start over. They see
>the standard as a marketing ploy, not a means to help the market
>grow or protect the customers' ownership and control of their
>information. After some period of negotiation, if the company
>cannot come to agreement, being asked to leave the working group
>has to be an acceptable outcome.
>
>4. Too many players in the game. Markets with too many players
>eventually sort that out and players fade. If they are resources
>for the spec creation, that's a bad thing. Spec teams usually
>come down to a few major contributors and a chorus. Where one fits
>into those categories has a lot to do with competence and willingness
>to compromise.
>
>Open source is a way of enabling companies to converge on technical
>implementations or get started. Full stop. Open source can be
>used as a sample implementation to proof the specification or to
>help jump-start efforts. As a reference implementation, they can
>kill off innovation and nail the specification to an early and
>possibly flawed implementation that becomes the de facto standard.
>On the other hand, if there is to be a reference implementation,
>open source is the way to go. The strategy one chooses here depends
>on things like whether or not the specification or standard has
>an accompanying object model as for example, X3D does. Even then,
>the larger problem of interoperation in an environment such as
>a browser and operating system where the implementation of the
>cross-object communications languages such as the scripting language
>has incompatibilities means the problems aren't completely solved.
>
>I understand the philosophy of going with what is working now. But
>it is a short term fix to a long term problem and it exacerbates the
>difficulty of getting a longer term solution. Perhaps it is the
>case that longer term solutions aren't desirable and one punts back
>to relying on XML to ensure one has a 50/50 chance of getting the
>semantic information back out of the data when the inevitable
>migration occurs. XML is at its best, a lifecycle option. The
>rest comes down to platforms and market share. Licensing is a
>normal business model. Companies that can't afford to license
>may be playing over their heads, but open source is an excellent
>alternative where they contribute in-kind. Free riders are the
>problem there, but part of that ecology. It's like a kid catching
>measles: not good but not avoidable without more expensive and
>thus unacceptable tactics.
>
>Microsoft played the game better and faster. That's all. As
>in any king of the hill game, staying on the top is the real
>challenge. The choice to be a good citizen and on the right
>side of history has costs. Some pay willingly; others cite
>self-interest; some come back to the standard. With the rare
>exception of HTML, very few technologies are standing still.
>
>We create specifications to get new technology up to scale.
>We create standards to protect our customers from us.
>
>len
>
>From: Niclas Olofsson [mailto:nicke.olofsson@home.se]
>
>
>
>Bullard, Claude L (Len) wrote:
>
>
>>Probably a good product, but a product that only interoperates
>>with itself is a pretty risky investment these days.
>>
>>
>
>I have different opinion. Sort of. The example given was perhaps not the
>best one, since they do seem to interoperate with what is important in
>that area of business. Risky is the other way around, going with
>standards. Standards (like VRML) is slow moving creatures, and companies
>can't really afford to wait for stuff to happen in a standard. They do
>what seem fit at the time they need it. *Most of the time* I've been in
>projects looking at standards, the management (perhaps badly advised)
>have chosen to go with what we need instead. May that be implementing
>parts of a standard or not, but never to go for the complete standard.
>You must understand that I usually work in medium-sized startup
>companies. If it wasn't for opensource, standards wouldn't stand a
>chance in that environment. It's far to expensive and time consuming to
>stick with standards. The normal scenario would be to buy 3'rd party
>products, and unless you have a paying customer, that's not going to
>happen. This is product development companies, not consulting. The only
>thing that we have actually payed for, Ever, I think is our development
>environment and licences for MS Office.
>
>The best a standards-based product selling company really can do, is to
>rely on "piracy" to sell their products. Far to many products today you
>can't even download and develop with, without paying development licence
>for it. Risky business for me is when you can't afford to have
>developers doing exactly that, because you have a product that you'd
>rather sell to one unhappy customer (that didn't get what he expected),
>instead of 100 happy ones that knew beforehand what they bought. Jasc
>did a great job on this (PaintShop). It was the first (really the first)
>software I downloaded out of internet. I could use it for free and
>learned it. Over the years I've bought at least 5 or 6 licences from
>them. Just because I could use it for free in the beginning. We all know
>how that works, don't we.
>
>But OSS is the joker in the game. With open source software, standards
>stand a chance. And that's where it works. You trade into a standard
>that you get for free, until you know you have it working (and someone
>is paying for it), then you can go hunt for faster implementations.
>Better support. Nicer logotypes. Whatever you need. And only then you
>pay for it.
>
>How to get X3D to fit into this is however darkness. It just doesn't
>seem to fit into the eco-system of software development... you know len,
>when you have a company like Lattice (which seem to be featured on the
>Web3D CD btw), it stands pretty strong againts X3D. Why interoperate
>based on a standard, when you have no competition? It's not like
>Microsoft lost the war, did they?
>
>Very little about X3D ...
>
>Cheers,
>/Niclas
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
>
>
|
