Re: A Call For Open Governance Of X Development

Daniel Stone wrote:
[SNIP]
 >>The gcc steering committee is an example here: It 
administrates
 >>the CVS and Web servers and - as this is a matter for the 
FSF
 >>- watches over license issues. It consists of the 
original people
 >>who initiated egcs, new members are invited in.
 >>Where is the flaw in your proposal?
 >>How would a serious developer feel who has worked his 
butt off
 >>if anyone with little to no involvment in his project 
would be
 >>able to elect who is to preside over it - on a one-man 
one vote
 >>basis - with the same voting rights as him?
 >
 >
 > A 75-year old who has volunteered on the polling booths 
and with various
 > civic projects has the same right to vote as anyone who's 
just turned
 > 18: them's the breaks.

This is total B.S.  I sure as hell wouldn't want some pompus
bureaucrat guiding the direction of XFree86,
thank-you-very-much!  Democracy is also supposed to be a
meritocracy, where you are rewarded for hard work and
commitment.  I'd expect no less from anyone involved in this
process.  Can you imagine if only %50 of the people on
slashdot got a chance to vote? Good gods man...

 >
 >>How would this person feel if soemone happened to be elected
 >>to take over the leadership who has not written a single 
line
 >>of code for the project, but for example happens to be 
working
 >>for a "System integrator and distributors packaging X 
technology
 >>in various forms"?
 >
 >
 > Why not? I'd personally feel good about it, if the person 
was a better
 > leader. Some people are brilliant leaders, and their time 
is best spent
 > leading, rather than hacking - to have to lead may 
actually *detract*
 > from their work. If the distributor was an excellent 
leader, more power
 > to him.

No offense to Gnome, but I'd prefer to see XFree86 free of
any corporate "guidance" from companies with a vested
interest in XFree86.  The less politics and agendas, the
better...

 > The leader doesn't have to be the best hacker, just the 
best leader. Any
 > other mindset is selling yourself short.

I disagree, having people understand what the people they
lead are doing makes a world of difference.  Even better is
the fact that they can make decisions based on that
perspective.  People who've worked their way up generally do
a better job.  Frankly, I wouldn't mind seeing David Dawes
fall into a role analogous to Linus' role in the kernel.  He
did, after all, start this project and as such it should be
his right.  That way you could go to someone for a
definitive thubs-up or thumbs-down.

 > Oh, and by the way, distributors do a lot more than you 
think. 18,000
 > lines of patches, all of which have to work and apply 
cleanly, and then
 > there's the small matter of the 6 or 7 architectures that 
RedHat

That isn't true!  Maybe that was the way it once was, but
RedHat is almost exclusively x86/ia64 now.  They've dropped
sparc for sure and one can only wonder about alpha...  Sure,
   they have some ppc64 stuff, but that's more server
oriented as opposed to desktop oriented.

 > packages have to work on, as well as 13-17 that Debian 
packages work on.
 > Combine this with the fact that most XFree86 releases 
only work on i386
 > and powerpc out of the box, and it's a seriously 
non-trivial effort that
 > involves a lot more hacking than you think, especially 
since we are most
 > often the first point of contact for users with bugs, so 
we end up
 > solving a lot of problems ourselves.

Isn't this true for most major OSS/Free projects?  I can't
remeber a gcc/glibc release that didn't have at least one
thing which didn't work.  Oh, and as for pusing patches
upstream being difficult,  have you ever tried getting the
self-appointed dictator of glibc, Uli Drepper, to commit
changes?  Good luck if you're a mips developer...

 > It's a non-trivial effort, and I invite you to try 
something such as
 > updating Debian's XFree86 packages to the next major 
release some day.

I think that most of the effort is in dealing with all the
politics and bureaucracy involved with a new debian release.

 >>Do you expect any serious developer would continue to work on
 >>this project?
 >
 >
 > Yes, there are many serious Debian and KDE developers who 
don't care
 > about who leads them, as long as they lead well. Some 
don't really care
 > at all, since it doesn't directly affect them.
 >
 > I've continued working on those projects, happy in the 
knowledge that
 > I'm being led by the best *leader*, not being led by 
someone who happens
 > to be really good at something else, but poor at leading.

It shouldn't be just about who's a good leader.  It should
be someone who's really good at coding and has good
leadership abilities.  Again, I'd point to Alan Cox and
Linus for examples.  I'm sure neither of them invisioned
being a leader, but they rose to the occasion.  Having
anyone else, esp. those with ambitions/agendas, is a recipie
for disaster.  Look at what happened to Qwest and Global
X-ing when they hired technically-incompetant people with
agendas to lead them.