[TCLCORE] Re: FW: Q about managing open source development

[Jeffrey H. <jef...@aj...>]

Here are some responses to more comments from Jeff Law (former maintainer
of gcc development).  Insightful.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 9:07 PM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development 



  In message <NDB...@aj...>you
 write:
  > > So we contacted a group of folks, not necessarily all developers, that ha
  > d
  > > a long term interest in seeing GCC succeed and who were well respected
  > > in different communities that used GCC.   The steering committee basicall
  > y
  > > deals with political issues, not technical ones (which we leave in the ha
  > nds
  > > of the developers, where it belongs).  We've been very happy with the res
  > ults.
  > 
  > What is the difference between "political" and "technical" issues for you?
Political is anything non-technical :-)

ie, stuff like who's in charge of releases, when/who do we give global 
write access to the tree, how to deal with problem posters and dealing with
making sure that nobody's taking advantage of their position within the
project to push an agenda that is not in the project's best interest.

ie if Cygnus/Red Hat was to try and close development to not include its
competitors it's the steering committee's responsiblity to step in and
take appropriate action -- which would likely be revoking any write privs
for Cygnus/Red Hat folks that were taking advantage of their positions within
the project.

They're the 'or else'  behind the "play by the rules we've established or
else ..." way we run the project.


  > In creating the steering committee, is it functionally a figure-head group?
Nope.  They're not a figure-head group, but the hope is that there aren't
a lot of political kinds of things to do on a regular basis.  ie, most of
the work in a free software project *should* be technical.  Make the code
better (by whatever measurement of better is appropriate) -- not dealing with
infighting between developers :-)

  > We are trying to determine how to set up the technical future decision
  > making process, and thought that the steering committee would be used for
  > that.
It could.  It does to a small extent for GCC -- mostly in areas where
technical decisions have the potential for significant political consequences.

For example a technical direction which would ultimately undermine the FSF's
core goals/values would be one where the steering committee would have to 
step in and say "sorry, you can't do example, making sure that Cygnus/Red Hat
doesn't take advantage of having a large number of contributors and steer
the project away from its core goals.

It's definitely not a figure-head group, though in theory a steering
committee to deal with political issues shouldn't have a whole lot to
do in a technical free software project :-)  Though they do come up from
time to time.

Consider if there was some patches which made it easy for people to write
new front-ends or optimization passes that where not part of GCC (ie they
communicated with GCC via pipes/files).  That would undermine the FSF's
stated goals and the steering committee would have to get involved and
prevent such patches from being installed (and take appropriate action if
someone violated that decree).

  >   One model that the Apache Software Foundation uses is that incoming
  > ideas can be vetoed by a single member, and otherwise ideas must get at
  > least two supporting votes before getting in.  Who controls those kind of
  > feature related issues in gcc?
That's mostly hashed out on the development lists.  Sometimes the arguments
get a little heated, but they usually work themselves out.  We do not allow
a single member of either the technical community or the steering committee
to block actions.  That was done on purpose to prevent one person from 
instigating gridlock by just vetoing everything they didn't like.

That takes some time for people to get used to, but I think it's worked out
reasonably well.

Basically the core ideas behind the project stem from what was so badly
messed up in GCC development before the EGCS project was started.  Single
personalities were able to control/stall development simply by being
jerks and were able to move the project in what most developers considered
the wrong direction simply because those one or two people ultimately
controlled every aspect of the project including dissemination of information.

jeff

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.