> From: DJ Delorie <d...@delorie.com> > Cc: gnu-misc-discuss@gnu.org > Date: Tue, 11 Feb 2020 12:00:51 -0500 > > a...@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).