OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] RE: [x3d-public] RE: [xml-dev] Which Will Be ReleasedFirst

[ Lists Home | Date Index | Thread Index ]


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

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS