[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of the GNUnion 2020

From: DJ Delorie
Subject: Re: State of the GNUnion 2020
Date: Sat, 22 Feb 2020 10:34:31 -0500

Eli Zaretskii <> writes:
> No one, not even the above quote, said they have "no impact" in
> general.

I didn't say that.  I said you could argue that.  It's a point to
consider and discuss, that's all.  Sometimes an extreme viewpoint makes
discussion clearer, and the results can be applied to the more vague
cases afterwards.

> 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.

> Are you really saying that the general public cares about our
> day-to-day decisions, or about how frequently we make releases, or our
> commit rate?

No, but if that's all a maintainer is doing, that's not leadership.

> 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.

> "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.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]