Menu
▾
▴
tcl-core
|
From: Jeffrey H. <jef...@aj...> - 2000-07-10 19:00:42
|
I thought I should share this with everyone on the core list as
we start considering how to open this process up.
Jeffrey Hobbs Tcl Ambassador
ho...@Aj... Ajuba Solutions (née Scriptics)
-----Original Message-----
From: Jeffrey A Law [mailto:la...@cy...]
Sent: Monday, July 10, 2000 11:54 AM
To: Jeffrey Hobbs
Subject: Re: Q about managing open source development
In message <NDB...@aj...>you
write:
> I got your name from Jim Ingham, who noted that you'd be a good person
> to ask about experiences related to managing an open software development
> effort (gcc).
As good as any I suppose :-)
> I'm currently the lead maintainer and manager of Tcl/Tk,
> but I've also been imbued with the responsibility by John Ousterhout
> (the original author and CTO of Ajuba) to foster better community
> involvement in the development.
Understood.
> Tcl/Tk has always been open source and
> invited people to hack on it, but in general the core parts have been
> fairly strictly controlled over its lifetime (you could say it lies in
> the Cathedral). So my job is to move it more towards the Bazaar, while
> trying to avoid the disadvantages of that development model.
Right. That's the 'trick' of course -- to reap the benefits of a Bazaar
model without the code turning into a mess of spaghetti code.
> The main ideas that have come up are opening direct CVS write access
> to more people (it's already in public NetCVS), and creating a
> steering committee.
Sound like the right steps. The first (hopefully) leads to more active
participation from developers and a wider team of "core" contributors that
everyone trusts to do the right thing.
That's one of the key things you want to build up -- a larger group of
folks that you trust to do the right thing and to whom you can delegate
tasks (or better yet, they just pick them up because they need to be done).
That's also the first big pitfall -- get the wrong group of core folks and
you end up with a mess of code or personality conflicts that rip the project
apart (witness the *bsd* splinters over the years).
The other big pitfall is just learning to trust a wider range of folks and
even if you disagree with them sometimes to realize that if you can't design
and implement a better solution (usually due to time constraints), then
sometimes you have to let them go in a direction that maybe you wouldn't.
> I noticed that the gcc steering committee was
> formed of people "to represent the interests of [different] communities".
> Did this prove to work well? I am currently making the decision on
> who should be considered for the steering committee (or on what basis).
This was both a practical and political move -- people have been more
comfortable knowing that it wasn't just Cygnus (or me) calling the shots.
It's been extremely valuable in dealing with RMS and some conspiracy theory
folks.
But is was also a very practical move -- in the past GCC had been controlled
by two people (RMS on the policial side, Kenner on the development side) and
experience had shown us that that model simply wasn't working and we had to
try something different.
So we contacted a group of folks, not necessarily all developers, that had
a long term interest in seeing GCC succeed and who were well respected
in different communities that used GCC. The steering committee basically
deals with political issues, not technical ones (which we leave in the hands
of the developers, where it belongs). We've been very happy with the results.
Overall, the biggest thing I've found is if you make the developers happy,
they'll want to contribute more time/energy. That in turn allows the project
to grow. If the developers are unhappy, then you have to find out why and
rectify the problem.
> I'd appreciate it if you could share with me any insight on what to
> watch out for, based on your experience, as I move forward with this.
> Perhaps also what you would have done differently.
I (personally) would not have gotten buddy-buddy with RMS again, it's been
a major headache, but I was outvoted on that particular issue. The lesson
is be very careful who you bring into the political decision process; people
who are not willing to compromise for the overall good of the project are
generally bad choices :-)
Good luck,
jeff
--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe: email tcl...@aj... with the
word UNSUBSCRIBE as the subject.
|
|
From: Jeffrey H. <jef...@aj...> - 2000-07-12 21:43:27
|
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.
|
|
From: Andreas K. <a.k...@we...> - 2000-07-20 07:06:58
|
I got this from the Python-URL! for this week. http://www.python.org/pipermail/python-dev/2000-July/013059.html -- Sincerely, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
|
From: Andreas K. <a.k...@we...> - 2000-07-20 07:10:34
|
I got this from the Python-URL! for this week (Jul 18). http://www.python.org/pipermail/python-dev/2000-July/013059.html -- Sincerely, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- -- The TclCore mailing list is sponsored by Ajuba Solutions To unsubscribe: email tcl...@aj... with the word UNSUBSCRIBE as the subject. |
Thanks for helping keep SourceForge clean.
X