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

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

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.