> From: Andy Wingo <[email protected]> > Cc: [email protected] > Date: Mon, 17 Feb 2020 21:37:55 +0100 > > I agree also! This sort of activity is natural in a project that > engages in self-reflection. If a project has leadership, then naturally > leadership would be conducting the exercise.
Do you actually know whether the leadership does/did such analysis? I don't, but if you do, please share the details. I do agree that leadership of any project should track and analyze the long-term tendencies in the project's life cycle. However, the methods and tools for such an analysis are not necessarily the ones you've chosen, and in any case what tools to choose is up to the leadership. > > _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). > > I know that we may disagree on interpretation of the data, and that > neither you nor I can avoid starting this kind of investigation with > preconceptions, but please believe that I did the analysis in good > faith. I didn't say and didn't mean that you did what you did in bad faith. I said the tools and methods chosen were naïve, which is something very different. The tendency to interpret complex data in naïve ways is a frequent human error, I see it every day on my daytime job. That we all tend to interpret the data in ways that are consistent with our prior beliefs is also a common cause of incorrect and biased conclusions, not at all a sign of foul play. I think your conclusions are naïve because they take all of the hundreds of GNU projects and apply simple statistics to all of them together, as if they were a homogeneous population. My point is that they aren't homogeneous, and any serious attempt to analyze the data you used to reflect on the health of the GNU Project as a whole must subdivide the projects into several groups and deal with each group separately, according to that group's traits. We all do this kind of selective analysis in each of our specific projects: we distinguish between major and minor aspects of our projects, between problems that affect the main functionalities and those which affect marginal ones, or happen on platforms about which we care less or not at all. We then consider only the important parts when assessing the health of our projects, or at least assign very low weight to the unimportant parts. Giving everything the same weight will more often than not produce absurd or nonsensical results. > or fork the repo and do your own analysis... seriously. Sorry, no. Criticism of the methodology and tools is (or at least should be) a legitimate response to a published analysis; saying "do it yourself or forever hold your peace" is not a valid counter-argument. If you are serious about your research, you should hear the criticism, refine your methodology, improve your tools, and publish corrected results. Or you can say "sorry, feel free to disregard my conclusions, they are not necessarily valid". > I have my conclusions which I stand by but which are certainly not > set in stone. I'm saying, quite simply, that the data and its analysis you provided don't support your conclusions. First and foremost, the criteria you've chosen as "health indicators" must be analyzed and validated, _before_ they are used to draw such conclusions. I've seen no such validation in your presentation. You seem to have accepted their validity as an axiom. > > 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. > > This could be! Please do go out and ask. Again, that was a suggestion to _you_ to try and validate your criteria. Don't turn the table and make it _my_ problem, because doing so doesn't make your conclusions any more valid than they were originally. The analysis you did was _your_ itch to scratch, not mine. If you want to convince me that your conclusions are valid, you will have to go the extra mile. > > 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? > > Honestly this argument is beneath you. You do not believe my > conclusions about GNU -- which is fine -- but instead you try to shift > the focus to the project I maintain, claiming that it is in poor health > -- something that which would not invalidate the argument -- but, with > no data or analysis to back it up, which is the aspect that you > criticise about my conclusion. WTF. This argument is a simple application of the health criteria you consider significant to your own work as a project manager. Presumably, if you consider the GNU Project to be in bad shape based on the criteria you proposed, and since elsewhere you clearly see yourself as a good candidate for making decisions for the whole GNU Project, then examining how you apply those same criteria to your own project is entirely reasonable. It is reasonable to expect that, given the slow pace of Guile's development, you'd do something to try to improve that by some changes in how your project is managed, how you attract new contributors, etc. > We can never know what might have been, but I believe that without my > work on Guile, it would certainly be dead now. I acknowledge and greatly appreciate your personal contribution to Guile development. I'm sure many others agree with me. But this is not what this discussion is about, it isn't about personal contributions and efforts of the leaders. Rather, it is about how those leaders manage their project, and what are the end results of that management, the bottom line. That is, after all, the basis of your call for changes in the GNU leadership, is it not? Suppose the current leadership of GNU would respond to your criticism by showing a schedule full of personal activities for advancement of GNU, like criss-crossing the world, giving talks, writing essays -- would that convince you that the leadership does a good job? It wouldn't convince me, FWIW. Because personal involvement and efforts are not the issue here. > > 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). > > Thought experiment: what would GNU be if all of its packages stopped > developing? Dead, right? Of course. But my point above is that IMO such total death can only happen if all the development teams of all those projects stop developing them. It _cannot_ happen due to some actions (or lack thereof) of the GNU leadership. And that, in my eyes, is one more serious deficiency in the criteria you've chosen as indicators of "the health of GNU" -- you think those indicators say something about the GNU leadership, whereas I think that if they say something, it's about the respective development teams of each project, i.e. about me and you. > I understand that some GNU developers feel that things are fine. I, for one, don't know for sure "things are fine". I proposed one way of looking at the health and the outlook for GNU -- consider the release data of the projects that are central to any OS. But this is a somewhat myopic view, and it cannot be used for any serious conclusions without considering other aspects. For example, what areas usually covered by any complete OS are currently absent in GNU, and why? And there are probably other aspects to consider. But the main point of this my criticism is that the criteria and methodology of analyzing relevant data shall be validated before the analysis is performed. As no such validation was done, and, moreover, there's at least some evidence that the criteria are invalid, I don't think the conclusions you've drawn are backed up by data, with all due respect.
