Re: A strawman proposal for X.org & XFree86.org

There are fundamentally many issues X.org has to face, of which here
are four:

1) For better or worse, X.org has been tarred by association with the 
Open Group's behavior on the X copyright.  I know, from information inside 
Digital at the time X.org was founded, that this is not X.org's fault, 
and that the UNIX vendors were in fact working behind the scenes working 
to fix the copyright problem. 

The fact is (at least the last I knew) there were still ties/strings between 
TOG and X.org left over from the UNIX vendors concerns around Monterray 
(at least the last time I looked), and that not all ties were cut due 
to those concerns at the time X.org was established.

There is no trust in the community as a result.  If this is all not
true, then you have a major education problem on your hands.

2) X.org current corporate goverance structure has no say from the community, 
but is still patterned after the X Consortium. Bitter history has shown 
that industry control of X standards resulted in stagnation, and without 
such goverance reform (which would require fundamentally different corporate 
structure than X.org), it is hard to understand how the trust could be 
gained.  As Havoc has said in other messages, "Pay for Say" doesn't work.

I don't understand how this could be fixed without essentially starting
over at an organizational level.

3) The history of developing technology in standards organization is very 
dismal.  This is true not only for X (with notable failures like PEX, 
XIE to name just a couple), but true of other standards organizations.
(remember ISO networking?).

The IETF generally shuns such development, and to the extent it does, 
its process is arranged to ensure that the result is actually useful.
In fact, much of the HTTP work I was involved in was ex-post-facto
work to make existing pracice rigorous; there were sections where
actual development was done, but in areas essential for interoperability.
The IETF process, for example, requires multiple working, interoperable 
implementations to progess along its standards track. (And it sometimes 
kicks things back to the IRTF when it is research). 

If there are competing technologies the IETF usually tries to let the market 
decide (rather than inhibiting the political loser) and may start the 
full process on multiple possibilities, though once in a great while they 
have to choose between technology for interoperability's sake.  This is 
always considered the last resort, but it does occasionally happen.

There are occasionally issues which require up front work for good 
interoperability: (e.g. the freedesktop extensions to the ICCCM); this 
is the classic kind of work that goes on in the IETF, where everyone works 
in a working group to define how best to interoperate.  This is working 
well in the freedesktop case: but the long term the argument towards formal 
standardization is, in my mind, two fold - 1) the rigor the process can 
provide, 2) it allows adherance to be written into formal government RFP's.

Most technologies should be developed first and standardized afterwards,
after they have succeeded in marketplace.  It makes it easier to
discard failed technologies without them having been enshrined in
legal documents that define too much.  This strawman does not seem
to address this concern.

4) There are other venues that may be viable for formal standardization
as that becomes necessary (e.g. FSG) that already exist that are already
available with community governance.

So even if 4) comes up empty, it may be easier to start over organizationally
and build a venue for the formal standardization process.
				- Jim

--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[email protected]