Re: Re: A Call For Open Governance Of X Development (Egbert Eich)
Keith Whitwell <[email protected]>
| Newsgroups | gmane.comp.xfree86.forum |
|---|---|
| Message-ID | <[email protected]> |
Frank LaMonica wrote: > Egbert, >> The Gnome Foundation is the only organization that comes to mind that >> has a turely elected board. >> Most OpenSource projects are led by individuals who have been formally >> or informally been accepted as leaders for their long >> standing commitment, their experience and experise. If a formal >> governing body exists (in many cases because it is require by >> law) these boards perform purely administrational or political >> tasks. 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? > > FL-> XFree86 has evolved into a project with a much broader scope, so it > is logical to explore new ways to manage it if the current method is > threatened. This discussion was precipitated by current XFree86 > management, and by disgruntled developers who have "worked their butt > off", but now feel they don't have the voice they feel they deserve. > > My comments suggest just one possible way to manage diverse opinions in > a way that allows all parties to feel their voice is at least being > heard. Achieving that *might* help to prevent a fork that would affect > many, many people in an extremely negative way. > > Successful organizations recognize the fact that it takes many people > with many different skill sets to maintain a viable organization. There > are some excellent developers who also possess strong managerial > skills. Ideally, they are the type of person who would lead technical > organizations. unfortunately, there are many more great developers who > not only lack managerial skills, but who don't even recognize the value > that good management brings to an organization. Technical people who > start organizations that grow to global proportions almost always > relinquish managerial control to experienced managers when the > organization reaches a point where professional management is needed. > This has happened in so many successful large organizations, that it is > almost the expected evolution of a startup company. Xfree86 has grown > to global proportions, and it needs to seriously consider whether or not > its management is best suited to continue into the future. Only they > have the power to make the changes, and I sincerely hope they will > thoughtfully consider ALL options. Hmm, I think there's a big difference between a commercial company and an open source project in terms of the skillset required to set the direction for the group. I'd see the ideal membership of an elected advisory board as being the type of experienced developers who are involved in the current BOD and core team. In fact, if there ever were an elected board, I don't have any doubt that David Dawes would continue to find himself the leader, and rest of the BOD & core teams as valued members. An elected (or whatever) advisory board might compliment rather than supplant the BOD - which I'm told is primarily involved in the management of a small budget, equipment, etc. Anyway: I feel that the whole board issue is somewhat of a sidetrack. For me, the questions are: why does it take so long to become trusted enough to commit code, or even to directly fix bugs in code one has already committed? Or -- per Mark V's suggestion -- can we come up with a structure/culture where commit access isn't as vital to the timely integration of one's changes? There have been a large number of posters who seem to hold the opinion that the group of committers is too small. Rather than tearing down the whole structure over this, can we try tweaking it to address what seems to be the main concern? Here's a suggestion: - BOD: continue current functions & membership, but in a token of accountability, make minutes public. - New board, stocked with elder developers: - Has power to offer or retract CVS access, based on consensus. - Members may or may not still be interested in coding, but are expected to be deeply concerned about XFree86's future directions. - Current active and/or concerned Core & BOD members should reasonably expect to have a seat on the board. - There is some well-defined & documented method for selecting for board membership. - Committers - A much larger & looser group than the current core team. - Emphasis on granting access to 'promising' developers rather than '5 year proven' ones. The most minimal way to implement this is: - BOD minutes to be made public - The current core team & bod members become the board - With an initial task to rapidly identify and offer CVS access to say .. 20 new faces? - And a (very) secondary task to expand its own membership to include representatives from the broader community. Keith