> From: DJ Delorie <d...@delorie.com> > Cc: a...@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.