Re: Discussing issues

Havoc Pennington writes:
 > On Tue, Apr 15, 2003 at 01:25:34PM +0200, Egbert Eich wrote: 
 > > There seems to be a misunderstanding:
 > > Havoc, you are talking about a project that deals a future
 > > 'base GUI platform for X11/UNIX' with library components
 > > GUI projects want to rely on. While Mark is referring to
 > > the realms that have traditionally been the focus of XFree86.
 > 
 > I'm not _only_ talking about libraries, there are also server-side
 > elements.

Yes, I know. But there are a lot of the things that have nothing to do
with the server. I expect that you your base GUI platform will contain
a lot of toolkit code as I don't expect you want to drink directly
from the fire hose.

 > 
 > But can you explain "traditional focus of XFree86"?  Does XFree86 not
 > want to work on the protocol/library/extension/API layers?  What about
 > dix/mi and the non-driver portions of the server?

Traditionally XFree86's focus was on the infrastructure around X.
With a strong emphasis on HW and DDX work to support XFree86 on
a wide variety of platforms. That's probably the area XFree86
has the most experience in: graphics hw programming which includes
knowledge how to make the best use of the features and capabilities
of todays hw, hw platforms and OSes. 

 > 
 > > I don't think anyone would argue that GUI projects should
 > > have a say on the library base they are going to use in the 
 > > future.
 > > However this 'community governance' when implemented in the
 > > way proposed would take away control over things people have
 > > been working on for years from these and turn it over to a 
 > > group that controls a much larger project than XFree86 
 > > currently is.
 > 
 > Wait, though. Even if XFree86 does include libraries and protocol
 > extensions, I don't think GUI projects should have a "say" in terms of
 > some kind of authority. It'd be smart if someone checked that the GUI
 > projects will use the features vs. ignoring them, but ultimately
 > individuals who *contribute* to the libraries and protocol extensions
 > should have the say.
 > 
 > All these other projects we're talking about are confederations of
 > little module dictatorships. Someone owns the foo subsystem, someone
 > owns the blah subsystem. If I write and maintain
 > libstartup-notification (random lame example), I get final say over
 > changes to it.
 >  
 > That works because 99% of decisions are not shared decisions.  The
 > only time you have to get all the dictators to agree is for a shared
 > decision, such as a release freeze process. Splitting
 > responsibility/authority in this way is what makes the organization
 > scalable.
 > 

Yes, I agree with what you have said. 
But, XFree86 isn't exactly new. We have gone thru these things before.
We have made shared decisions, we have had ways to deal with deciding
about interfaces, extensions etc. Nothing of this is formalized/
codified lots of it is dictated by common sense.
It has always been done in a collaborate way either among the the 
people interested in a certain interface or even among the broader 
audience of a mailing list. In fact the whole transition to 4.x was 
done this way, Mark Vojkovich's extensions have always been proposed
to the developers list for discussion, etc.
Therefore despite our technical problems - which we are currently 
addressing - I think we are able to handle things pretty well within
our given resources.

Please try to be realistic:
You are creating a new organization, fine. You plan to clone 
the 'Gnome Foundation' governance model for your organization, 
because you feel it suits your needs best - fine. 
Talk about governance first and start working later - this
is a rather unprecedented model in open source. If this is 
how you want to organize things - fine.
And, I'm 100% behind the goals of your organization: you want 
to remove duplication of work, remove the NIH mentality which 
has ruled the Gnome and KDE communities for too long. 

But why do you try to prescribe your governance model on an
organization that's more than 10 years old? Risiking to 
alienate people who have a lot of invaluable experience
but who don't want to buy in on this governance model because
they feel their model has served them well. Do you want to
sacrifice their experience by trying to force a new model
of governance upon them?
Instead, why don't you try find ways how to interface best 
with the exisiting organization and with their exisiting structures
talking advantage of all the experites and skills rested within
this organization?
If you think your model works better, why don't you go ahead
and proove it to this organization by producing some results?

Why do we have to deal with all these things now - even before
you have shown how well your concept will work?

Egbert.