Re: State of the GNUnion 2020

[Eli Zaretskii]

> From: DJ Delorie <dj@delorie.com>
> Cc: ams@gnu.org, gnu-misc-discuss@gnu.org
> Date: Sat, 22 Feb 2020 10:34:31 -0500
> 
> > The guiding principles of what it takes to be a maintainer of a GNU
> > project are communicated to each one of us when he or she is
> > appointed.  Those principles have very important impact on what we do,
> > day in and day out, as part of our job as maintainers.
> 
> But being a leader in a project for a community of developers is so much
> more than just doing the GNU maintainership duties.  One of the side
> effects of being a good leader is that you have a stronger community,
> more developers, more *effective* contributors, etc.  A leader can grow
> a community, not just accept patches from it.  This is what the
> "outsiders" can see when they choose which project to contribute to.

I think we are losing the context.  See below.

> > If you disagree, please show a few examples of such interest, where
> > deeper involvement of the leadership in routine management of a
> > project did or could have mattered as far as general public is
> > concerned.  I could think of none, but maybe my memory is biased.
> 
> Can you not remember all those years of djgpp development?  All the
> users who came for help, and stayed to help?  You were as responsible
> for the success of that community as I was.

Sure, but neither of us was "GNU leadership".  Which is exactly my
point in this sub-thread: the project developers and maintainers have
a much more significant effect on the project than "GNU leadership".
And neither do I remember how any of what happened in DJGPP was of any
interest of the general public.

> > "Can provide" or "does provide"?  Are you saying that leadership _can_
> > be from more than one person, or are you saying that it already is?
> 
> Both.  Looking at the tools (gcc, glibc, binutils, gdb) I see a strong
> guiding hand from the project leads (stewards, maintainers, whatever)
> that very much says "leaders".  These are people who not only accept
> patches but organize conventions, plan future work, arrange for tutors,
> and even in some cases handle sponsorships.  I would say these projects
> are thriving under their own leadership *despite* the lack of leadership
> from above.

You say "despite", and by that postulate that leadership from above is
lacking, and moreover, if it were available, it could do a lot better
than the project maintainers do.  But this still has to be proven, and
my personal opinion and experience is that any outside influence
cannot help on any significant level.  Attracting new developers is
mainly about the technical details of the package, and then about the
communication and educational skills, but most significantly it is
about intimate day-to-day communications.  How can any outsiders help
me in this matter, when they generally lack any detailed knowledge
about the particular software and its development trends, don't
routinely speak on our forums, and don't even know who are the
veterans and who are newcomers?

> But still, a growing concern in these projects is - why do people choose
> to work for other projects and not GNU?  How do we convince, for
> example, younger developers to participate?  Having someone who can
> accept patches is insufficient to solve this.

The context of this was the question I asked whether "GNU leadership"
has any effect on the metrics that Andy presented, which looks at the
frequency of releases.  We can talk about other and broader aspects,
but then we'd lose context and wander to other pastures.  Going back
to the original context, I still don't see how any of the aspects you
mentioned are relevant to the metrics which was proposed as a measure
of the leadership's fitness for the job and/or the health of GNU in
general.