MESSAGE
| DATE | 2020-02-12 |
| FROM | Eli Zaretskii
|
| SUBJECT | Re: [Hangout - NYLXS] State of the GNUnion 2020
|
> From: DJ Delorie
> Cc: gnu-misc-discuss-at-gnu.org
> Date: Tue, 11 Feb 2020 12:00:51 -0500
>
> ams-at-gnu.org (Alfred M. Szmidt) writes:
> > You make the incorrect assumption that the health of the GNU project
> > should be measured in how many new projects are adopted or released --
> > instead of what our goal is to provide a free operating system.
>
> Are we DONE producing that operating system? No? If not, why not?
> Aren't all those developers who finished their packages working on
> other, new packages? Why aren't the package counts continuing to
> increase, if the developers are otherwise unoccupied?
Those are very important questions, and they should have been
investigated, analyzed, and answered _before_ showing us a bunch of
naïve graphs and drawing conclusions from them (which unsurprisingly
coincide with the opinions the author expressed long before showing
those graphs).
So: _are_ we done developing that OS? How do you tell? Do other OSes
constantly increase their package counts? If so, by how much and with
what rate? How come we attempt to answer the former question without
studying the latter ones? Is that an attempt at a serious analysis,
or is this an attempt to "prove" what we think we already know?
> I think, package activity *is* a valid metric if the goal is "all
> packages in the OS are free."
Yes, but _what_ package activity is that? Who says that package
activity is measured by the number of new packages? Isn't it
reasonable to see the number of packages level out at some point, and
the activity then switches to making new releases? And for packages
that have a limited set of features, isn't it reasonable that they at
some point slow down development and even stop making new releases?
Take Sed, for example, or 'ed', or even GNU Hello -- how many new
features can you stuff into that? Or take GNU Make -- is it really
unreasonable that it is in maintenance mode? I don't think so.
And then there are packages which simply no longer have the demand
that would justify new releases. DJGPP comes to mind. If someone
wants to try answering this question:
> If a set of developers finish a package, and don't start on a new one, I
> think that says something interesting about the health of GNU and its
> community.
then they could try tracking down the DJGPP developers of yore and see
what happened to them, and try through that deduce what does that say
about the health of GNU and its community. Why wasn't such (or
similar) analysis done before coming up with this "state of GNUnion"?
I think such anecdotal studies can speak volumes more than those
graphs.
I could also offer a different measure of the health of GNU: look at
the projects that are at the base of any OS: GCC, glibc, Binutils,
GDB, etc. These are thriving by any measure, putting out new releases
every few months. Even Emacs, which was always, and still is, blamed
for notoriously slow release cycle, keeps delivering a major release
every 3 years -- for the last 25 years.
And then we have Guile, whose development pace leaves a lot to be
desired, if we really want it to become the GNU standard extension
languages. Strangely, the Guile developers, including Andy Wingo,
don't seem to do anything about that. There are no discussions about
making the project more active, none at all. Does that mean the Guile
level of activity is OK with Andy? If so, how does that live in peace
with the seemingly grave outlook for the rest of GNU?
Last, but not least: I'm not at all sure that statistics of the kind
we were presented, which is based on various measures of package
activity, tells anything about "the health of GNU", because GNU, at
least as I understand that term, has almost nothing to do with
development activity of GNU packages. The development activity is
determined solely by the project's development team and its abilities
to draw contributions and find worthy development goals. GNU as an
organization doesn't have any impact on that, because they almost
never interfere into these matters (unless there's some sort of
scandal, which happens only very rarely).
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
