Re: Discussing issues

On Mon, Apr 14, 2003 at 04:19:36PM -0400, Havoc Pennington wrote:
>On Mon, Apr 14, 2003 at 08:25:16PM +0100, Alan Hourihane wrote: 
>> I really don't think your going to get a clear answer to this question.
>> 
>> Open Source exists for the fact that people can't agree on how to do
>> things. KDE vs Gnome, Unix vs Windows, and so on. Technologies compete.
>> It's the way of life.
>
>I have no doubt someone will always disagree with the answer.  That
>doesn't bother me. What I'm interested in is what most of the key
>developers from X, GTK+, Qt, major vendors, etc. can agree on.
>
>In other words, sure there won't ever be a 100% answer, but I predict
>there will be a 90% de facto answer, and moreover my view is that
>there *should* be such a 90% answer. The reason there should be is one
>of platform vs.  applications, or choice vs. fragmentation.  (see
>http://lists.kde.org/?l=kde-core-devel&m=104725441423600&w=2)
>
>GTK+ and Qt, GNOME and KDE are very concerned to use the same X and
>have a standard place to put X enhancements; that alone is enough to
>get the 90%, even if OS vendors, Mozilla, OpenOffice, and others
>weren't concerned about it.
>
>There will also be some set of X APIs that lands in the LSB, and some
>set that is shipped across the major operating systems.
>
>One of my primary concerns in fact is to drive many platform aspects
>of GNOME/KDE/Mozilla/OpenOffice/whatever down into X. That's why I
>want to see a single X project, so it can include things like 
>fontconfig/STSF, or freedesktop.org.
>
>If Keith forks, you will get a "battle" scenario for a while, sure.
>But eventually, the "outside world" will pick one of the X
>implementation projects. The direction of X will effectively be
>whatever that X implementation project does. The other X projects will
>either have to copy the main one and sync to its APIs, or limit
>themselves to being a nice platform for twm or embedded or some other
>niche.
>
>However, if we get agreement among what's really a pretty small group
>of people (most of them on this list), we could avoid the hassle and
>delay and just design a solution up front. In addition to avoiding the
>XFree86 fork, we could take the opportunity to merge with X.org.
>
>I find it hard to believe that with all the smart people on this list,
>we can't solve what is essentially a simple problem - there are even
>many well-demonstrated case studies and proven approaches available
>for copying.

It's only a simple problem if everyone (or everyone that "matters")
agrees with your world view.  I think that's a big assumption right
there.

Effectively what you're talking about comes down to standards.
Standards should come naturally from implementations and innovations,
not the other way around.  Forcing everything to happen in one
place only stifles innovation.  I guess it's a sign that open source
is "growing up" that there's a sense that it now feels the need to
tightly control the way things happen.  That sounds like a recipe
out of the UNIX vendors' cookbook, and I fear that it will lead to
another "consortium" with self-interest in slowing things down.
Different name, different faces, but instantly recognisable
nonetheless.

David
-- 
David Dawes
Founder/committer/developer                     The XFree86 Project
www.XFree86.org/~dawes