Re: State of the GNUnion 2020
On 25.02.2020 23:37, Samuel Thibault wrote: I never asked for a "crown". FWIW, I didn't mean to imply any character fault. Just saying that it might not be the way to reach the stated goals. Not in the context of the Social Contract, but in the context of the Joint Statement. Specifically, the first paragraph. What free software values the maintainers do not currently agree to uphold, but will if they adhere to the Social Contract? Maybe you guys should have a talk between yourselves and figure out whether everyone shares the same understanding and vision for it. ? Why would we talk between ourselves? There is not secret plan or such thing. To avoid sending mixed messages. For better or worse, you now both appear to be part of Something together. With an end goal, strategy, or whatever. Not saying you necessarily have to talk in private. Commenting on the message that I quoted would work even better. Apparently Ludo meant it to go further than what I'm talking about. But the text does not say that much (and it doesn't match the current state of GNU maintainers, so it should not IMHO). I'm glad that we've cleared that up.
Re: State of the GNUnion 2020
On 2020-02-25 06:22, Andreas Enge wrote: On Tue, Feb 25, 2020 at 08:56:24AM -0500, Alfred M. Szmidt wrote: The text circulated is not a text by or for the GNU project, so this is indeed not the best place for discussion of it Quite on the contrary, it is a text by members of the GNU Project for the GNU Project. That's different from a text *of* the GNU Project, which is what it is being presented as. It's the same way that a memo put together by some disgruntled Google employees isn't a Google document. They can't just print that on Google letterhead, call it a new Google policy and get employees to sign off on it.
Re: State of the GNUnion 2020
John Darrington, le mar. 25 févr. 2020 07:04:20 -0500, a ecrit: > On Tue, Feb 25, 2020 at 08:50:51AM +0100, Samuel Thibault wrote: > > Could people actually *READ* the text > > Why? It is nothing to do with GNU. So why should any subscribers to > this list spend any time on it at all? I wrote it: before discussing about a small excerpt that thus doesn't have the context. There is no point in bringing arguments if one doesn't check the whole of what is being talked about. Samuel
Re: State of the GNUnion 2020
Dmitry Gutov, le mar. 25 févr. 2020 12:24:25 +0200, a ecrit: > On 25.02.2020 1:55, Samuel Thibault wrote: > > > > That is a problem. But one that wouldn't be solved simply by the > > > leadership's say-so. GNU is usually all volunteers, and if existing > > > developers don't accept the new project management platform, they won't > > > use > > > it. > > > > As I mentioned in another mail, I am not talking about the software > > running the platform, but the community around the platform. It's the > > contact they get from the community living on a given platform, which > > makes the welcoming atmosphere. And there leadership does matter. > > Okay then. I'll rephrase what I said in another email as well. > > As a part of the community, I think you can work on that welcoming > atmosphere without pushing RMS out, or asking for his blessing (which is > surely already implicitly given, with Kind Communication Guidelines out > there). And, to repeat myself, having the "crown" on your head is unlikely > to make this process particularly easier. I never asked for a "crown". I just support that text which, among other things, summarizes the Kind Communicatin Guidelines. > > > If we declare that all of GNU should share a certain set of values, and > > > especially that maintainers must share the free software values, whatever > > > it > > > really means in practice, *that* sounds exclusionary already. > > > > Did you really read what was actually written on > > https://wiki.gnu.tools/gnu:social-contract ? > > It does not talk about the values that contributors hold for themselves, > > it talks about the values put in the software of the GNU project: > > > > “ > > The GNU Project provides software that guarantees to all users the Four > > Essential Freedoms, without compromise: > > ” > > > > etc. It does not talk about exclusively using free software etc. > > *shrug* Again, you have put out a document that reiterates things that > should already be so. So that leaves (apparently not only myself) guessing > what is it for. > > Could you clarify, then, what that message might have been about: > https://lists.gnu.org/archive/html/gnu-misc-discuss/2020-02/msg00224.html > > ? > > Specifically, the first paragraph. What free software values the maintainers > do not currently agree to uphold, but will if they adhere to the Social > Contract? > > Maybe you guys should have a talk between yourselves and figure out whether > everyone shares the same understanding and vision for it. ? Why would we talk between ourselves? There is not secret plan or such thing. Apparently Ludo meant it to go further than what I'm talking about. But the text does not say that much (and it doesn't match the current state of GNU maintainers, so it should not IMHO). Samuel
Re: State of the GNUnion 2020
Le mardi 25 février 2020, 15:22:52 CET Andreas Enge a écrit : > On Tue, Feb 25, 2020 at 08:56:24AM -0500, Alfred M. Szmidt wrote: > > The text circulated is not a text by or for the GNU project, so this > > is indeed not the best place for discussion of it > > Quite on the contrary, it is a text by members of the GNU Project for > the GNU Project. If some GNU maintainers, outside of GNU, work on a software, and want it inside GNU, but GNU refuses, that’s absolutely not GNU software. It is not even about GNU. This text was rejected by GNU’s structure, and was elaborated outside of GNU (because it was rejected), so it’s not GNU.
Re: State of the GNUnion 2020
On Tue, Feb 25, 2020 at 08:56:24AM -0500, Alfred M. Szmidt wrote: > The text circulated is not a text by or for the GNU project, so this > is indeed not the best place for discussion of it Quite on the contrary, it is a text by members of the GNU Project for the GNU Project. And the GNU project rejected it. For very good reasons. So it isn't at all contrary > seeing that those wanting to discuss the text refuse to discuss > it here, it might just as well be worth moving any such > discussions to their web site. May I remind you that we have been elaborating this text from the start on this list, and that this openness is indeed one of our goals? Then please answer why you are not mentioning the stance of the GNU project. I've asked this several times, over now several weeks, and silence. It is written by some GNU maintainers, it is not one that is representative of the GNU project -- since as GNU maintainers you do not speak for the GNU project, I suggest you read Richard Stallman's email on that topic, or the governance document how the GNU projet actually works. So calling it a GNU document or pretending that it is, since that is obviously not true, is just silly.
Re: State of the GNUnion 2020
On Tue, Feb 25, 2020 at 08:56:24AM -0500, Alfred M. Szmidt wrote: > The text circulated is not a text by or for the GNU project, so this > is indeed not the best place for discussion of it Quite on the contrary, it is a text by members of the GNU Project for the GNU Project. > seeing that those > wanting to discuss the text refuse to discuss it here, it might just > as well be worth moving any such discussions to their web site. May I remind you that we have been elaborating this text from the start on this list, and that this openness is indeed one of our goals? The first draft was actually circulated already in October: https://lists.gnu.org/archive/html/gnu-misc-discuss/2019-10/msg00050.html Since then and until opening the endorsement period, we have been discussing the document on this list (just look for threads having "social contract" in their title), and feedback from the list has been continuously integrated into the document (including feedback by you, Alfred, if I remember correctly). I am not sure who you mean by "they"; if I am included, then I would say that I am happy to discuss the GNU Social Contract here if people wish to do so, but that I am not pushing for it. It has been discussed on this list for several months, and version 1.0 was posted on February 10th. Maybe you want to reopen the discussion for creating a version 1.1, but this strikes me as premature for a document that has just been finished and needs to pass the test of time. Andreas
Re: State of the GNUnion 2020
The text circulated is not a text by or for the GNU project, so this is indeed not the best place for discussion of it, seeing that those wanting to discuss the text refuse to discuss it here, it might just as well be worth moving any such discussions to their web site. In either case, please help improving the discussion signal level by not assuming that a person said/mean/thought or didn't, it is neither helpful nor constructive. If you are unclear as to what they meant, ask them politley instead of pretending that you understand their argument. It is also unhelpful to constantly start tangets, the point being addressed wasn't what is or isn't something about the GNU project, but the specific text being circulated.
Re: State of the GNUnion 2020
Le mardi 25 février 2020, 09:49:02 CET Dmitry Gutov a écrit : > On 25.02.2020 3:58, Alexandre François Garreau wrote: > >> Regarding punishing repeat offenders anyway, as we've seen just > >> recently, you can't censor a determined individual on a public > >> mailing > >> list anyway. Limit their audience, sure, but banning them outright > >> seems impossible. And I can hardly see the whole GNU project > >> migrating off mailing lists. > > > > If new younger people come in charge and want to succeed to “compete” > > with github, gitlab, etc. I can see how they’d like to replace > > mailing-lists with gitlab or other SaaSS-like web software… > > They would replace it with Discourse, which is web-based, but also Free > Software. I personally would probably endorse that, but it indeed needs > a browser to use. Or specialized clients using the web API, etc. Well Discourse has the advantage that you can pretend that it does maling- lists because you can somewhat interact with it by mail… yet it replaces all mail addresses (so to completely break the concept of mail-federation and makes mandatory for everything to be centralized on its plateform… which, for censorship sakes, is likely what they’d like) and breaks headers… But Discours is also so much full of javascript and “interactive” stuff, as well as being heavy for both server and client, that I believe they wouldn’t go as far as that. There are limits…
Re: State of the GNUnion 2020
On Tue, Feb 25, 2020 at 07:04:20AM -0500, John Darrington wrote: > Why? It is nothing to do with GNU. So why should any subscribers to > this list spend any time on it at all? So what do you think are the requirements for having "to do with GNU"? Since apparently you claim that GNU maintainers discussing things about GNU have nothing to do with GNU. Andreas
Re: State of the GNUnion 2020
On Tue, Feb 25, 2020 at 08:50:51AM +0100, Samuel Thibault wrote: > > Could people actually *READ* the text > Why? It is nothing to do with GNU. So why should any subscribers to this list spend any time on it at all? My understanding is that the people who are promoting it have thier own infrastructure, so it can be discussed there. Of course some people might be members of both groups - which is fine. But this list is about GNU. Please keep on topic. People are free to read it if they want (or not to) - they are free to "endorse" if they want (or not to).But whatever they choose to do with that text is of no concern to this mailing list. The people who spammed the maintainers with a message asking them to post here were acting out of order.
Re: State of the GNUnion 2020
On 25.02.2020 1:55, Samuel Thibault wrote: That is a problem. But one that wouldn't be solved simply by the leadership's say-so. GNU is usually all volunteers, and if existing developers don't accept the new project management platform, they won't use it. As I mentioned in another mail, I am not talking about the software running the platform, but the community around the platform. It's the contact they get from the community living on a given platform, which makes the welcoming atmosphere. And there leadership does matter. Okay then. I'll rephrase what I said in another email as well. As a part of the community, I think you can work on that welcoming atmosphere without pushing RMS out, or asking for his blessing (which is surely already implicitly given, with Kind Communication Guidelines out there). And, to repeat myself, having the "crown" on your head is unlikely to make this process particularly easier. If we declare that all of GNU should share a certain set of values, and especially that maintainers must share the free software values, whatever it really means in practice, *that* sounds exclusionary already. Did you really read what was actually written on https://wiki.gnu.tools/gnu:social-contract ? It does not talk about the values that contributors hold for themselves, it talks about the values put in the software of the GNU project: “ The GNU Project provides software that guarantees to all users the Four Essential Freedoms, without compromise: ” etc. It does not talk about exclusively using free software etc. *shrug* Again, you have put out a document that reiterates things that should already be so. So that leaves (apparently not only myself) guessing what is it for. Could you clarify, then, what that message might have been about: https://lists.gnu.org/archive/html/gnu-misc-discuss/2020-02/msg00224.html ? Specifically, the first paragraph. What free software values the maintainers do not currently agree to uphold, but will if they adhere to the Social Contract? Maybe you guys should have a talk between yourselves and figure out whether everyone shares the same understanding and vision for it.
Re: State of the GNUnion 2020
On 25.02.2020 3:58, Alexandre François Garreau wrote: Regarding punishing repeat offenders anyway, as we've seen just recently, you can't censor a determined individual on a public mailing list anyway. Limit their audience, sure, but banning them outright seems impossible. And I can hardly see the whole GNU project migrating off mailing lists. If new younger people come in charge and want to succeed to “compete” with github, gitlab, etc. I can see how they’d like to replace mailing-lists with gitlab or other SaaSS-like web software… They would replace it with Discourse, which is web-based, but also Free Software. I personally would probably endorse that, but it indeed needs a browser to use. Or specialized clients using the web API, etc. You might think support for proprietary OSes and “endorsement” of them (of proprietary software in general, non-endorsement of the strict GNU philosophy (which isn’t even actually so well described in the social contract as to imply that proprietary software, should, indeed, stop to exist, I believe)) are not anyhow related… but actually to support something, you need to test it, to use it, and to know how good it is in comparision with other similar uses on the same platform. That’s why emacs OS X port is known to be pretty good. There are people using it. It's actually the worst port among the main three, AFAIK. Not to say it's bad (it's usable, and it's fairly popular), but we collectively have less macOS knowledge, and Apple liked to shake things up in its releases.
Re: State of the GNUnion 2020
> I am not clear what It's explained down below in the text. And I read it, it still does not explain it clearly to me or its implications or how it is something the GNU project is about. Truncating my message and then dismissing everything else seems strange, why not elaborate on the issue?
Re: State of the GNUnion 2020
Alfred M. Szmidt, le mar. 25 févr. 2020 03:07:04 -0500, a ecrit: > I am not clear what It's explained down below in the text. Samuel
Re: State of the GNUnion 2020
The text also says: â the GNU Project, which creates and distributes a software system that respects users' freedoms â There is a slightly confusion here, and implication that isn't the intent of the GNU project, I think. Namley, "distribute a software system that respects user's freedom". I am not clear what the meaning a "software system" that "respects user's freedom" means here, how does the _operating_system_ (assuming it is already free software) respect user rights? That seems to be a technical goal, say by allowing easier ways to modify source code, writting "simpler" code that is easily understood by others, or by reducing obstacles like not needing a root user to do specific actions. We might even decide on technical solution that might not at all lead to that -- say by eskewing ways that make it easier to load third-party modules in the inevitable situation that it might lead to propietery software doing something nasty. While lofty goals worth striding for, I think they are slightly different than what the GNU project, and the GNU system are about.
Re: State of the GNUnion 2020
Alexandre François Garreau, le mar. 25 févr. 2020 03:10:35 +0100, a ecrit: > Le mardi 25 février 2020, 00:55:09 CET Samuel Thibault a écrit : > > Did you really read what was actually written on > > https://wiki.gnu.tools/gnu:social-contract ? > > It does not talk about the values that contributors hold for themselves, > > it talks about the values put in the software of the GNU project: > > > > “ > > The GNU Project provides software that guarantees to all users the Four > > Essential Freedoms, without compromise: > > ” > > > > etc. It does not talk about exclusively using free software etc. > > Oh my god so this is even worse I could believe. > > So… this statement is not about society, it is not about the actual > *goals* of GNU (making people able, in their life (= in their general > usage of computers), to only use free software, so that they can act to > make proprietary software disappear), it is simply about GNU… Could people actually *READ* the text instead of relying one a single sentence of it? The text also says: “ the GNU Project, which creates and distributes a software system that respects users' freedoms ” Which very precisely is about being able to only use free software. But that doesn't *forbid* people from using other software, why would it? That'd be exclusive for sure, but that's not the goal. Samuel
Re: State of the GNUnion 2020
Le mardi 25 février 2020, 00:55:09 CET Samuel Thibault a écrit : > As I mentioned in another mail, I am not talking about the software > running the platform, but the community around the platform. It's the > contact they get from the community living on a given platform, which > makes the welcoming atmosphere. And there leadership does matter. The central point was “leadership does not matter”, it was not refuted with arguments. > Did you really read what was actually written on > https://wiki.gnu.tools/gnu:social-contract ? > It does not talk about the values that contributors hold for themselves, > it talks about the values put in the software of the GNU project: > > “ > The GNU Project provides software that guarantees to all users the Four > Essential Freedoms, without compromise: > ” > > etc. It does not talk about exclusively using free software etc. Oh my god so this is even worse I could believe. So… this statement is not about society, it is not about the actual *goals* of GNU (making people able, in their life (= in their general usage of computers), to only use free software, so that they can act to make proprietary software disappear), it is simply about GNU… But there are already commitments asked by RMS about *not endorsing proprietary software* in GNU project, about everything going to be free… So actually you ask not to support free software outside of GNU, not to support it inside (this is already the case), but to *agree* with it… but *only inside*: this is the combined worse of two worlds. Either you don’t ask anything about their ideas to people contributing (or maintaining) GNU, so to be maximally inclusive… either you ask them to agree with its end goals, so to ensure, if, as you desire, they get involved in leadership, they’ll take the right decisions. There, you ask to hold a subset of those end goals (such as the total disappearance of proprietary software… and SaaSS, which is even worse), so you begin promoting exclusion, or at least some forms of priviledge… without having them being useful to anything! I mean, if some, most or all key GNU people endorsed that text I couldn’t less care if that doesn’t even ask them not to promote the usage of SaaSS for developing it, or the disappearance of proprietary software outside of GNU. For instance GNU does stuff such that proprietary software doesn’t exist out of it. That’s why it actively *promote* copyleft, even if it doesn’t directly serves GNU. That’s why LLVM is politically *an enemy* since it is supported, financed and partially developed *so that* proprietary frontend (or even optimizing backend) can be plugged into it. That’s why GNU refused to support stuff related to LLVM, even if it is *outside* of it, even if our compiler is different. If LLVM had been copylefted, I think GNU (rms) would have been *glad* to merge code, or at least copy or mimicate interfaces so that to help compatibility (because compatibility is a good thing), porting, migrations, etc. But the state is very different: it is that GNU isn’t eager to develop interfaces with LLVM, and this is not related to GNU (otherwise a possible argument could be “yes it competes with GCC, but it’d bring more people to GNU! and after all, it’s free!”). Compilers nowadays, and computer languages in general, because of the vast monopoly of GCC, have been something which are *basically* expect to be *naturally* free. LLVM is an attempt, or at least a serious possibility, of changing that. This has nothing to do with GNU. This has to do with free-software movement. This is exterior to GNU. And yet GNU has to act about it.
Re: State of the GNUnion 2020
> Regarding punishing repeat offenders anyway, as we've seen just > recently, you can't censor a determined individual on a public mailing > list anyway. Limit their audience, sure, but banning them outright seems > impossible. And I can hardly see the whole GNU project migrating off > mailing lists. If new younger people come in charge and want to succeed to “compete” with github, gitlab, etc. I can see how they’d like to replace mailing-lists with gitlab or other SaaSS-like web software… It’s a general tendency that web tends to eat any internet-related computer usage… I dislike that… web is not appropriate… > For better or worse, a lot of my colleagues, and a lot of users and > Emacs contributors (the main GNU project I contribute to) use > proprietary OSes. Even the maintainers do (though not exclusively). I am > not fond of that, but I started using Emacs in a similar position years > ago, and I wouldn't want to exclude any of them from being a part of > our project because their stance is more lax, or that their end goals > are more utilitarian (at least for the time being). I know several people (I’m not anymore sure of it it includes even myself) who started using emacs on a proprietary OS, and then the beauty of Emacs brought them to 100% free-software life. This is something of value indeed. You might think support for proprietary OSes and “endorsement” of them (of proprietary software in general, non-endorsement of the strict GNU philosophy (which isn’t even actually so well described in the social contract as to imply that proprietary software, should, indeed, stop to exist, I believe)) are not anyhow related… but actually to support something, you need to test it, to use it, and to know how good it is in comparision with other similar uses on the same platform. That’s why emacs OS X port is known to be pretty good. There are people using it. But then, either we make already-convinced full-librist use proprietary software, which is a pity, and not really natural… or we even stop then to go to 100% free software… which is even worse… either we *need* to accept people who don’t use 100% free software *because* they don’t want to, *because* they’re not convinced. They’re likely a major amount of people who would be the last to be convinced. By opposition with most of mankind who either never heard of free software, or doesn’t understand what it does imply (and what proprietary software imply (or simply what computer software is)).
Re: State of the GNUnion 2020
Dmitry Gutov, le mar. 25 févr. 2020 01:44:02 +0200, a ecrit: > On 20.02.2020 15:45, Samuel Thibault wrote: > > > > > The activity by itself, yes, but the choice of where to start a new > > > > project, or starting contributing an existing project, leadership does > > > > have a lot of importance. > > > > > > What kind of choice? Contributors come and go, largely depending on their > > > own needs and interests. > > > > Yes, but also, and I believe most likely, depending on their knowledge > > of project places (github vs gitlabs vs savannah) and the contact they > > get with the people there. The GNU project is less and less known > > compared to other free software platforms, so it'll get less and less > > newcomers. > > That is a problem. But one that wouldn't be solved simply by the > leadership's say-so. GNU is usually all volunteers, and if existing > developers don't accept the new project management platform, they won't use > it. As I mentioned in another mail, I am not talking about the software running the platform, but the community around the platform. It's the contact they get from the community living on a given platform, which makes the welcoming atmosphere. And there leadership does matter. > Regarding punishing repeat offenders anyway, as we've seen just recently, > you can't censor a determined individual on a public mailing list anyway. > Limit their audience, sure, but banning them outright seems impossible. That does not mean we can't write that we at least try to do it. > If we declare that all of GNU should share a certain set of values, and > especially that maintainers must share the free software values, whatever it > really means in practice, *that* sounds exclusionary already. Did you really read what was actually written on https://wiki.gnu.tools/gnu:social-contract ? It does not talk about the values that contributors hold for themselves, it talks about the values put in the software of the GNU project: “ The GNU Project provides software that guarantees to all users the Four Essential Freedoms, without compromise: ” etc. It does not talk about exclusively using free software etc. Samuel
Re: State of the GNUnion 2020
On 20.02.2020 15:45, Samuel Thibault wrote: The activity by itself, yes, but the choice of where to start a new project, or starting contributing an existing project, leadership does have a lot of importance. What kind of choice? Contributors come and go, largely depending on their own needs and interests. Yes, but also, and I believe most likely, depending on their knowledge of project places (github vs gitlabs vs savannah) and the contact they get with the people there. The GNU project is less and less known compared to other free software platforms, so it'll get less and less newcomers. That is a problem. But one that wouldn't be solved simply by the leadership's say-so. GNU is usually all volunteers, and if existing developers don't accept the new project management platform, they won't use it. And vice versa, if they like it, the project can migrate to it unilaterally. With the exception of strictly proprietary stuff like Github, but it's out of the question for GNU anyway. Depending on how flexible the core developers are, I guess RMS's recommendation on questions like that will have some influence. But so would enthusiastic, targeted advocacy toward the use of new tools. One doesn't really have to be RMS to work with individual projects and their contributors and discuss their choices and needs. And it's a more difficult endeavor (think Mozilla-type initiatives) than just releasing a document saying "hi all we don't discriminate and accept everyone", which is basically stating the already obvious. From seeing the discussions here, it doesn't seem so obvious :/ Really? For all the shouting and stomping of feet, I haven't seen here any one email stating or even implying that the gender or the race of a contributor is somehow important, or that we'd turn somebody away because of it. Sure, the contrary was explicitly said indeed. But anything one can bring about not only acknowledging it, but also making efforts on inclusiveness is mostly rejected with arguments like "it's too hard to take care when writing something on a mailing list". The argument was, in a typical programmer fashion, that a lot of things could be taken as "harassment", and so a subjective thing like that can't be explicitly disallowed. And that our existing "kind communication guidelines" cover a lot of the same ground already. Regarding punishing repeat offenders anyway, as we've seen just recently, you can't censor a determined individual on a public mailing list anyway. Limit their audience, sure, but banning them outright seems impossible. And I can hardly see the whole GNU project migrating off mailing lists. On the flip side, an argument is made that your initiative might make GNU more exclusionary because of the extra conditions on what it takes to be a part of it. At some point you have to exclude some people in order to include other people, yes. We can see that in various communities: when somebody is having a toxic behavior and does not changes behavior even after strong warnings, one has to exclude that person, because otherwise that person will make a lot other people fly away. Not taking the steps to exclude the toxic person does mean excluding people that can not stand the toxic behavior, even if that latter exclusion is not explicit. That seems to be the ground of what some people do not understand here: full inclusiveness can not work, there will always be some people you will be excluding one way or the other, voluntarily or not. Making sure that the choice of who you exclude gets written down seems important to me. This is a very common argument about CoC's. I was talking about something different. Forget harassment and antagonistic behavior. If we declare that all of GNU should share a certain set of values, and especially that maintainers must share the free software values, whatever it really means in practice, *that* sounds exclusionary already. For better or worse, a lot of my colleagues, and a lot of users and Emacs contributors (the main GNU project I contribute to) use proprietary OSes. Even the maintainers do (though not exclusively). I am not fond of that, but I started using Emacs in a similar position years ago, and I wouldn't want to exclude any of them from being a part of our project because their stance is more lax, or that their end goals are more utilitarian (at least for the time being). And that is where your argument stops working.
Re: State of the GNUnion 2020
On 2/21/20 3:07 AM, Ludovic Courtès wrote: > I don’t think so, but I’d rather emphasize “symbiosis†with some > projects than disagreements with others. That is too bad because the goal of GNU is to seperate GNU from other projects that don't maining the Four Freedoms Ruben -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Re: State of the GNUnion 2020
On 2/20/20 3:55 AM, Samuel Thibault wrote: > Our concern is that at some point GNU may be just completely unknown > to free software enthousiasts. Don't worry about that. It is not your concern an a package maintainer and it's not even a remote possiblity. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Re: State of the GNUnion 2020
Le jeudi 20 février 2020, 22:55:37 CET Kaz Kylheku (gnu-misc-discuss) a écrit : > On 2020-02-20 11:42, Andreas R. wrote: > > On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote: > >> > On the flip side, an argument is made that your initiative might > >> > make GNU more exclusionary because of the extra conditions on what > >> > it takes to be a part of it. > >> > >> At some point you have to exclude some people in order to include > >> other > > >> people, yes. We can see that in various communities: > One group whose inclusion is being specifically promoted by the > proposed social contract is people with a low level of experience. > The exact rhetoric is that people must be included regardless of > their level of experience, which can only possibly mean > regardless of how low is their level of experience. Hopefully that could bring them gaining experience (even better, GNU experience, within GNU), rather than keeping doing bad contributions… depending on time maintainers dedicate to them. > So, if people have to be excluded to bring about inclusion, > let us ask: whom do you have to exclude in order to include > people with a low level of experience? Lazy, busy or at least people who easily despice others? But I’m not sure for that too they want to exclude… or so? is that your only point?
Re: State of the GNUnion 2020
Le jeudi 20 février 2020, 18:39:52 CET Samuel Thibault a écrit : > Alfred M. Szmidt, le jeu. 20 févr. 2020 12:32:16 -0500, a ecrit: > >> > Our concern is that at some point GNU may be just completely > >> > unknown > >> > to free software enthousiasts. As in, when you'd ask people > >> > what free > >> > software is about, they would answer "ah, yes, the stuff on > >> > github, > >> > right". > >> > >> Okay, sure. But going back to Eli's point, the development > >> activity of > >> individual projects is determined by individual project's > >> members, and is rarely affected by the actions of the > >> leadership. > > > >The activity by itself, yes, but the choice of where to start a new > >project, or starting contributing an existing project, leadership > >does > >have a lot of importance. > > > > How does that have to do with the overall project leadership, which > > hasn't changed significantly over the years, and yet had significant > > growth in new projects for several decades (if we take the graphs by > > Wingo at face value). > > "Significant growth" is very little compared to the huge growth that can > be seen on other platforms. So when measuring we should only dare to measure GNU stuff in comparison with other software projects and platforms. Very interesting. > I'm not saying that GNU will necessarily stop growing and decline. What > I'm afraid is that it might just become insignificant compared to > others, and thus its voice for the 4 freedoms become less and less > heard. That’s a reasonable fear, so that should be what should have been measured in the metrics discussed in this thread.
Re: State of the GNUnion 2020
Le jeudi 20 février 2020, 05:08:13 CET DJ Delorie a écrit : > Jean Louis writes: > > * DJ Delorie [2020-02-19 21:01]: > >> "Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes: > >> > On 2020-02-17 12:37, Andy Wingo wrote: > >> >> Thought experiment: what would GNU be if all of its packages > >> >> stopped > >> >> developing? Dead, right? > >> > > >> > The immediate effect would become more of a stable base for the > >> > vast > >> > amount of material that depends on it. > >> > >> For about a month or so, until the next bug, security problem, or > >> missing feature were reported... then people would switch to whatever > >> software was responsive to these problems. If GNU doesn't respond, > >> someone will eventually fork the software (because they can :) and > >> GNU > >> would lose users. > > > > When people continue developing free software it is a win, not loss. > > The question wasn't "what would free software be?" it was "what would > GNU be?" > > There are a lot of projects that are free software but not GNU. If > people choose to work on those projects instead of GNU, GNU loses, even > if free software wins. Certainly GNU loses something (if ever they intended and had the ability to do as such constructively and most usefully), but not loses absolutely. GNU would start losing *at all* if people started to choose to *use* other project instead of GNU. Like, invent a language, and use LLVM instead of GCC (more than “wanting to contribute a compiler, and contribute to LLVM rather than to GCC”, especially as it never happens that way: you contribute to what you use, not the opposite).
Re: State of the GNUnion 2020
Le vendredi 21 février 2020, 22:57:55 CET Samuel Thibault a écrit : > Alexandre François Garreau, le ven. 21 févr. 2020 11:59:42 +0100, a ecrit: > > Le jeudi 20 février 2020, 18:39:52 CET Samuel Thibault a écrit : > > > I'm not saying that GNU will necessarily stop growing and decline. > > > What > > > I'm afraid is that it might just become insignificant compared to > > > others, and thus its voice for the 4 freedoms become less and less > > > heard. > > > > That’s a reasonable fear, so that should be what should have been > > measured in the metrics discussed in this thread. > > But how can you measure *that*? Do the same metrics with other projects, possibly linked but faarer, included in GNU(/Linux) OS, be it Linux, Xorg packages, (La)TeX, KDE, Gnome, etc.
Another idea of health indice [Was: Re: State of the GNUnion 2020]
I’ve another idea of measurement: What software is for? Is software first of all for developers, or users? For people who write it, or people who run it? I mean, software is made to be used right? not only read (and actually, continuously changing software also is an issue for those who read, then you’d need to reread it several times to stay updated… what you’ve read would loose value as it was obsoleted, etc.) I can see how we can say that “swift” is “more alive” than bash, but it is arguable to say something that constantly changes, at the point of being barely usable for anything else than a unimportant scripting language or even only a command-language (swift), is in better health, if bash’s stability allows to build ever growing stuff with it. Aliveness doesn’t equate health. A mix of meat and shit full of moisture, parasites and any insect is very alive, but it is not healthy. Health require size, reliability, and hence stability. You’re absolutely not considering that. So software is not made to do releases or patches, it’s made to be used. According your definition guile scheme is more alive than emacs lisp, which is more than C, which is more than common lisp, which is even more alive than TeX, the then deadest of all languages… Yet TeX is terrificly old, used in a lot of ways, keeps growing, and is the official presentation language of GNU software (via one of its dialect: texinfo). And many believe its stability is a good things. Bugs are not that much a problem as not only they were a few from the beginning, and the software was simple, but it wasn’t given unreasonable powers such as accessing the network or *modifying* files. Even more so as it’s only a scripting language (purely interpreted), never a (be it natively or byte-code) compiled/VM one, so most of time we can read source. And simple copyleft allows it to be easily free. And wheter to obfuscation… most of programs are written by mathematicians who have no idea of how to make it readable anyway x) and programs in TeX are notoriously hard to read (so it’s more a social deficiency becoming technical instead). so instead… why not measure *actual usage*? Yes this is hard, but can be done in some reasonable way: measuring packaging, and measuring dependencies. popcon also can be used. We could count how many are packaged into debian, and ponder that by how many dependencies of them are. We could also nuance that by the proportion of bugs. Then even an old and untouched software (inetutils, coreutils, bash, etc.) could show pretty good health. Not talking of TeX and its thousands, millions packages (who’d need to be counted separately), emacs lisp would humbly be less than common lisp, yet be seeable as pretty active, same for guile, etc. Popcon would talk of it even more. The ideal metric being going out and asking random people whether they used today some software, or any dependency of it (so barely asking what software did they use). Debian doesn’t do a such metric, it would be pretty invading as is (maybe with some anonymification, decentralized adding up, etc.?). This method also encompass the fact to give more importance to core infrastructure project such as glibc, gcc, etc. on which almost all free operating systems depends nowadays (even competitors such as llvm were bootstraped using these, so we could count bootstrapping as well). The fact at some point LLVM hackers considered to merge with gcc (but rms wasn’t aware by then :/) also shows to be as a sign of health for the time it happened. Forks are examples of usual increase of development, I guess they happen both after times where development increase (so disagreements, or at least difference of developing pace, become more likely), and before moments of enthusiasm leading to even more contributions… yet I don’t see them as healthy in any way because this increase of effort is actually an increase in duplicated effort. Merge are pretty much the opposite (except for some enthusiasm as well: enthusiasm of change).
Re: State of the GNUnion 2020
Le jeudi 20 février 2020, 14:45:02 CET Samuel Thibault a écrit : > Dmitry Gutov, le jeu. 20 févr. 2020 15:31:17 +0200, a ecrit: > > On the flip side, an argument is made that your initiative might make > > GNU more exclusionary because of the extra conditions on what it > > takes to be a part of it. > > At some point you have to exclude some people in order to include other > people, yes. We can see that in various communities: when somebody is > having a toxic behavior and does not changes behavior even after strong > warnings, one has to exclude that person, because otherwise that person > will make a lot other people fly away. Not taking the steps to exclude > the toxic person does mean excluding people that can not stand the toxic > behavior, even if that latter exclusion is not explicit. > > That seems to be the ground of what some people do not understand here: > full inclusiveness can not work, there will always be some people you > will be excluding one way or the other, voluntarily or not. Making sure > that the choice of who you exclude gets written down seems important to > me. This is interesting but too familiar to me. I’ve already seen this discourse, and the last paragraph about “gets written down” seems to be really right and really convincing to me, as I already seen it as well, and each time it is time to support a similar thing the only point I judge valid. But there are three issues with this reasoning: it is defeatist, it is paternalist, and it is apolitical (in the “right-wing” meaning) It is defeatist because it departs from the basic idea you’ll *have* to exclude someone at some point. No solution will ever be found. And rather than taking the risk of not reacting immediately (“tolerance zero”, another right wing thing), you prefer to “aknowledge” this “will have to be done at some point”. Is if there wasn’t any middle ground for compromision there. The idea of shared kill/blacklist or /ignore have been already proposed. That solves it. Just as two places whose one is moderated and the other not (actually you have private GNU list for better moderation, this is the “free” one, you chose that). The fact trolling could happen even once moderation is there also was told about. It could still go on privately, or as spam. But for some reasons this isn’t taked as a “failure” of it. Like prisons and repression happens and grows to solve issues that still exist anyway, as if the only issue wasn’t to fix the problem, to find and/or develop The Right Thing, but to be able to claim you’re not responsible of it because you’ve done everything possible (even the wrong). It is paternalist because it assumes *the chiefs* have to take care for “uncomfort” and “stuff people couldn’t stand”. “Standing” something is always physically possible. The issue is psychological. But thankfully psychological diversity exists (something that is all too often forgotten (and advertised as if it should be!)), as well as psychological evolution. To me, and by experience, from any possible social group, there will be people who can stand anything. Even more so: people from marginalized groups can sometimes have some people who can stand *more* (not of everything necessarily, but of some kinds), on average, because they’re used to. This is, unfortunately, an useful ability in nowadays world. An ability that are also lacking some snowflakes who are because of the luxury of a comfortable lifestyle all along (which is a privilege), more than any dispriviledge (but is that worth defending? is it *possible* defending, as some people will be oversensitive to anything?) It always will be, because “excluding” these “toxic” people won’t make them disappear away, they always will be somewhere. So either you exclude progressively more until you’ve made ghettos, prisons, or killed them, either you only divide the world into the places for you, and the places for them (so now you restrict yourself to only a part of the world: limited). Now, in the previous case, with no exclusions, these people who learnt to stand anything could, as soon as there is no official exclusion, participate in anything, that is good. While otherwise now there are always places where you couldn’t if people disagree with you… and that leds to the next part: It is apolitical because it denies the inherent issue of political disagreement. I’ve already seen the “broken window” argument out there. This is the same kind of right-wing points that come from those who denie that. Like there are no diverse social groups with diverging interests, to be arbitrated, but a big block “society” that needs order, and the dissidents, the “gangsters” that allegedly would like to create chaos, against society (as if they could be outside of it). There are the “good” the “common” people, and the “bad” ones. This is the very mindset behind the idea that, to keep society clean and in order, we
Re: State of the GNUnion 2020
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.
Re: State of the GNUnion 2020
Alexandre François Garreau, le dim. 23 févr. 2020 01:08:25 +0100, a ecrit: > Le dimanche 23 février 2020, 00:02:27 CET Samuel Thibault a écrit : > > I see my students not think that much when they put software on github, > > if I don't discuss with them. When you create a repository on github, > > it proposes to set a licence, and it happens to list essentially free > > licences (it may not be so long-term wise on github). But if you > > don't explicitly make a choice, no license is set, and thus in many > > juridictions the software is not free. > > This is bad of github, but this is a bad copyright law trick (that all > States favoring copyright (that is, imho, all of them) do), and people > should be warned against. > > So we need education… but only because work is done *against us* in the > other direction! Wouldn’t the State instantiate such tricky laws, in a > world where everybody publish stuff and don’t expect it to have special — > and technically obvious to circumvent— restrictions, we wouldn’t need to > do that. Ok, but that's what we have now. So yes, we have to teach people. > > > We shouldn’t be defending free software because it is good but because > > > it gives freedom, so we shouldn’t try to make it good *just* for the > > > fantasy of it to be considered as such so then people agree on free > > > software. People need to be *politically convinced*. > > > > Sure. But if your software is unknown, it will not attract new > > contributors, and you will not have the opportunity to discuss with them > > about the politics. > > It’s not with contributors that you should discuss about the politics but > with the users. To make sure that long-term-wise you have free software alternatives, you want to discuss with contributors too. > > > So people will want to uphold freedom anyway. Maybe fewer, and that > > > would be sad, but then we’d need to give them *political* > > > hand-holding, not technical one. > > > > But they'll most often come from a technical door. > > Personally I’ve more seen the opposite. As most people aren’t technically > skilled, or programmers anyway. I'm talking about contributors. They would most often come contributing for technical reasons, not for political reasons. > > We often see this kind of situation in the community-driven ISPs of > > FFDN: people often come with technical questions to help some people > > with Internet access, and they come home not only with technical > > answers, but also political aspects of why e.g. network neutrality is > > important etc. > > Do people join *before* knowing about political aspects, in areas > where it is already possible and even common to use commercial ISPs? Yes. > Anyway, as I’ve told before, these local ISPs are way different, For various reasons, yes. But for teaching people about the politics involved behind just setting up Internet acceess, I believe there is a lot in common with teaching people about the politics involved behind just writing software. > > If we were not nice/welcoming on the technical questions, they would > > just not listen to whatever politics we'd like to talk them about in > > addition to the technical parts. Because they have no idea that these > > questions are important. We have a similar situation with free software. > My current ISP is part of FFDN. [...] Sorry, I didn't understand the actual relation with the point I was making. > So here, in the end, you could think it is like GNU, a bunch of expert old > hackers who control everything because they were here from the beginning… > > …except actually it’s not, pretty much the opposite: > > — these weren’t there from the beginning, they just happened to arrive in > the middle, and were enough “skilled” and “meritant” to set up a > completely informal meritocracy (like what was argued for since several > months), by doing the right things in the right time; So perhaps some written constitutional text was needed to prevent this from happening? > — statutorily it is democratic, so it is a proof constitutions proves > nothing (it just takes from people who gave their name to the states, who > reserved domain names or who are root on the right machines to do whatever > they want if we let them, and them justify themselves); > — constitutionally, it is upholding free software, as FFDN statuses > require to, ?? Where does FFDN requires that? The word "logiciel" doen't appear in the statuts, règlement, and charte. Samuel
Re: State of the GNUnion 2020
Le dimanche 23 février 2020, 00:02:27 CET Samuel Thibault a écrit : > Alexandre François Garreau, le sam. 22 févr. 2020 23:32:13 +0100, a ecrit: > > giving a link to GNU coding standards (actually even packaged into > > debian), for instance, would be pretty reasonable mentoring. > > Sure (but also telling which piece is questioned in the contribution, > e.g. "there are missing spaces in function calls, see the corresponding > part of the GNU Coding Standards"). Sure, if there’s enough time (otherwise it is anyway good to read it from the start to the end anyway, isn’t it?) > Providing a link may not even be > necessary, the contributor can easily find it with a webcrawler. GNU existed before they did. And I dislike them. We actually can easily do without, when they’re not needed. And now they’re not needed. > > > So the new generation will have to learn by itself? Do not be > > > surprised > > > if it doesn't wish to pick up the software that was produced by the > > > previous generation, and will just rewrite everything with non-free > > > tools etc. > > > > If they do non-free, it’s not because “they are not teached” > > appropriatedly, that’s the fantasy of the “homo homine lupus > > est”. If they ever do, it’s actually because they were *teached* > > into non-free software, or tricked into it, either by bad teachers, or > > by bad laws. > > No: in many juridictions it's simply the default if you don't explicitly > make it free. That’s precisely why I said “tricked” and “bad laws”. > I see my students not think that much when they put software on github, > if I don't discuss with them. When you create a repository on github, > it proposes to set a licence, and it happens to list essentially free > licences (it may not be so long-term wise on github). But if you > don't explicitly make a choice, no license is set, and thus in many > juridictions the software is not free. This is bad of github, but this is a bad copyright law trick (that all States favoring copyright (that is, imho, all of them) do), and people should be warned against. So we need education… but only because work is done *against us* in the other direction! Wouldn’t the State instantiate such tricky laws, in a world where everybody publish stuff and don’t expect it to have special — and technically obvious to circumvent— restrictions, we wouldn’t need to do that. We have to be ambitious, and look forward for a world where there’s no any special work to do for everything to be free. We shouldn’t expect that a society where it is to be said to everybody that murder is bad and torture is bad is the end goal of improving society. > > We shouldn’t be defending free software because it is good but because > > it gives freedom, so we shouldn’t try to make it good *just* for the > > fantasy of it to be considered as such so then people agree on free > > software. People need to be *politically convinced*. > > Sure. But if your software is unknown, it will not attract new > contributors, and you will not have the opportunity to discuss with them > about the politics. It’s not with contributors that you should discuss about the politics but with the users. And by “user” I nowaday actually mean the physical people you find out there, AFK, not the few one who will think to come to you, if they use your software. It’s more like “potential user” or “people needing to do things with computers”. > But anyway the matter I was discussing was not about the software being > "good", but about welcoming contributions. Some software might be very > good, if it is not welcoming new contributors they will just rewrite it, > even if that'd result with a much less good software. Okay, but that can’t be accused of being the cause of proprietary software. > > So people will want to uphold freedom anyway. Maybe fewer, and that > > would be sad, but then we’d need to give them *political* > > hand-holding, not technical one. > > But they'll most often come from a technical door. Personally I’ve more seen the opposite. As most people aren’t technically skilled, or programmers anyway. If we (like, actually, more: States) started to teach *everybody* about programming, so that most of population would try to contribute, *then* that question would be really urging… but it is not the case, and I’m really doubtful that the current discussions about welcoming or dying would occur if that happen. Given a such wave of new contributors, there would be necessarily some that would be content with current state of things (so our software would grow as well anyway), or who would fork and either stay wrong, or technically prove they were right so to be merged again (but then it’s not as bad as our software would be slow and lacking in comparison, the effort wouldn’t be duplicated, but only, at first, happening somewhere else). > We often see this kind of situation in the community-driven ISPs of > FFDN: people often come
Re: State of the GNUnion 2020
On 23.02.2020 0:49, Alexandre François Garreau wrote: But what will rather happen is that the new generation will just rewrite another program, possibly without caring about making it free software. So what? it still can be run. If people value freedom, they should prefer the free one, to which they could contribute and get live again, if they need to. But prefering the non-free one is a problem of moral philosophy, of personal misjugment to prefer not to be free… One of the primary goals of the FSF is the promotion of Free Software and the awareness of it, including and especially among the new generations or users and developers. There is already non-free software. So the solution is not anything technical, it is not something positive. We don’t have to “do something more” to “bring people to write more free softwares”. We have to make non-free software*disappear*. Stop being written. Stop to be used. Until the point where, with time, all proprietary software gets lost, rewritten, useless, unrunnable, or reverse-engineered. That's simply a pipe dream. Let's not present any pipe dreams as the end goal of our movement, or else we won't be able to set our priorities straight.
Re: State of the GNUnion 2020
Le samedi 22 février 2020, 22:50:03 CET Samuel Thibault a écrit : > Alexandre François Garreau, le sam. 22 févr. 2020 22:43:36 +0100, a ecrit: > > Le samedi 22 février 2020, 21:10:33 CET Samuel Thibault a écrit : > > > Alexandre François Garreau, le sam. 22 févr. 2020 19:21:18 +0100, a ecrit: > > > > > > > > No, you can’t know. > > > > > > Strictly speaking, sure, but at some point when things only get > > > worse > > > and worse, it's way better to resort to exclusion than continuing to > > > see a project get stuck due to only one person, even if with > > > several dozen years you might find a solution. > > > > However I’m still dubitative about the fact a single person could get > > ALL A PROJECT project stuck alone, without exception. > > I was indeed taking an extreme example. But a much simpler case would be > somebody calling everything names, thus driving away newcomers, who > will wonder that the heck this project is about. That seems pretty simple to issue a warning about a such issue, to explain a such person why it’s not good (because it looks really repetitive and simple), and possibly to filter the way I propose later. > > > How different is this from exclusion? > > > > It is different in that that anybody have the free choice of > > moderation, or not. You could have your own moderation filters > > overriding those of your trusted friends, you could change the amount > > of trust you give to each, etc. > > Ok, so newcomers would have to know about it and make it work to avoid > the nasty messages? No, it has to be instantiated either as an explicit choice at mailing-list subscribing, either as a default, but one that can be tweaked, either as a standard protocol to be complied with (be it based on something already existing such as MIME and/or rfc822 headers, but if it’s backward- compatible we have to make sure the non-complying clients can get a server-side “default“ that would comply to desired behavior according historical implementation (that is classical moderation that is possible to tweak/disable)).
Re: State of the GNUnion 2020
Alexandre François Garreau, le dim. 23 févr. 2020 00:00:11 +0100, a ecrit: > Le samedi 22 février 2020, 22:32:24 CET Samuel Thibault a écrit : > > Jean Louis, le dim. 23 févr. 2020 00:04:46 +0300, a ecrit: > > > GNU project is about making free operating system, thus it is there, > > > as long as it is compatible with computers, you may carry it on in the > > > future life. > > > > Sure. But how to make sure it will outlive me? > > By backing it up on a hard disk, or a SSD (depending on frequency of use). Nobody will take the time to read it back. They will just rewrite it. Samuel
Re: State of the GNUnion 2020
Alexandre François Garreau, le sam. 22 févr. 2020 23:49:30 +0100, a ecrit: > Le samedi 22 février 2020, 21:49:13 CET Samuel Thibault a écrit : > > Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 12:22:55 -0800, a > ecrit: > > > On 2020-02-22 01:50, Samuel Thibault wrote: > > > > Really, not including the next generations in a project is running > > > > the > > > > risk of the project just dying with its leaders. > > > > > > Project "liveness" is not the ultimate value. If nobody is found who > > > will maintain it the way it ought to be, then let it die. > > > > Sure. > > > > But what will rather happen is that the new generation will just rewrite > > another program, possibly without caring about making it free software. > > So what? it still can be run. But then you'd have missed an opportunity of discussing about free software questions with the next generation. See my other mail. Samuel
Re: State of the GNUnion 2020
Alexandre François Garreau, le sam. 22 févr. 2020 23:32:13 +0100, a ecrit: > giving a link to GNU coding standards (actually even packaged into > debian), for instance, would be pretty reasonable mentoring. Sure (but also telling which piece is questioned in the contribution, e.g. "there are missing spaces in function calls, see the corresponding part of the GNU Coding Standards"). Providing a link may not even be necessary, the contributor can easily find it with a webcrawler. > > So the new generation will have to learn by itself? Do not be surprised > > if it doesn't wish to pick up the software that was produced by the > > previous generation, and will just rewrite everything with non-free > > tools etc. > > If they do non-free, it’s not because “they are not teached” > appropriatedly, that’s the fantasy of the “homo homine lupus > est”. If they ever do, it’s actually because they were *teached* > into non-free software, or tricked into it, either by bad teachers, or > by bad laws. No: in many juridictions it's simply the default if you don't explicitly make it free. I see my students not think that much when they put software on github, if I don't discuss with them. When you create a repository on github, it proposes to set a licence, and it happens to list essentially free licences (it may not be so long-term wise on github). But if you don't explicitly make a choice, no license is set, and thus in many juridictions the software is not free. > We shouldn’t be defending free software because it is good but because it > gives freedom, so we shouldn’t try to make it good *just* for the fantasy > of it to be considered as such so then people agree on free software. > People need to be *politically convinced*. Sure. But if your software is unknown, it will not attract new contributors, and you will not have the opportunity to discuss with them about the politics. But anyway the matter I was discussing was not about the software being "good", but about welcoming contributions. Some software might be very good, if it is not welcoming new contributors they will just rewrite it, even if that'd result with a much less good software. > > If nobody is there to hold their hand, I don't see a reason why they > > would listen to the free software goals. > > Freedom. Freedom is valuable per se. How can they know about the need for freedom if nobody gets to tell them about the dangers of non-free software? > So people will want to uphold freedom anyway. Maybe fewer, and that would > be sad, but then we’d need to give them *political* hand-holding, not > technical one. But they'll most often come from a technical door. We often see this kind of situation in the community-driven ISPs of FFDN: people often come with technical questions to help some people with Internet access, and they come home not only with technical answers, but also political aspects of why e.g. network neutrality is important etc. If we were not nice/welcoming on the technical questions, they would just not listen to whatever politics we'd like to talk them about in addition to the technical parts. Because they have no idea that these questions are important. We have a similar situation with free software. Samuel
Re: State of the GNUnion 2020
Le samedi 22 février 2020, 22:32:24 CET Samuel Thibault a écrit : > Jean Louis, le dim. 23 févr. 2020 00:04:46 +0300, a ecrit: > > GNU project is about making free operating system, thus it is there, > > as long as it is compatible with computers, you may carry it on in the > > future life. > > Sure. But how to make sure it will outlive me? By backing it up on a hard disk, or a SSD (depending on frequency of use). As long as architectures doesn’t change… or don’t get complex enough to be hard enough to get a gcc port to them…
Re: State of the GNUnion 2020
Le samedi 22 février 2020, 21:49:13 CET Samuel Thibault a écrit : > Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 12:22:55 -0800, a ecrit: > > On 2020-02-22 01:50, Samuel Thibault wrote: > > > Really, not including the next generations in a project is running > > > the > > > risk of the project just dying with its leaders. > > > > Project "liveness" is not the ultimate value. If nobody is found who > > will maintain it the way it ought to be, then let it die. > > Sure. > > But what will rather happen is that the new generation will just rewrite > another program, possibly without caring about making it free software. So what? it still can be run. If people value freedom, they should prefer the free one, to which they could contribute and get live again, if they need to. But prefering the non-free one is a problem of moral philosophy, of personal misjugment to prefer not to be free… > > I suspect that these initiatives to have inclusion of regardless > > experience are driven by project zeal, and envy of popular projects. > > It's not a question of envy, but of making sure that on the long term > we still have a free operating system. If we don't include the new > generation, and alongside teach it why we need free software. The new > generation may just not care about picking up the task, we may then grow > old in a world with non-free software. The issue is that non-free software, software proprietariness at all, exist at all… If it didn’t whatever we would do, whatever whoever would do, software would stay free, by default. There is already non-free software. So the solution is not anything technical, it is not something positive. We don’t have to “do something more” to “bring people to write more free softwares”. We have to make non-free software *disappear*. Stop being written. Stop to be used. Until the point where, with time, all proprietary software gets lost, rewritten, useless, unrunnable, or reverse-engineered. This is a negative act, not a positive one. It it a negative act *on others*, and not on ourselves (if it was positive, it would be). So it is a collective action, not an individual one. So it is about politics, not about technique.
Re: State of the GNUnion 2020
Le samedi 22 février 2020, 21:43:00 CET Samuel Thibault a écrit : > Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a ecrit: > > On 2020-02-22 01:50, Samuel Thibault wrote: > > > Yes. Which doesn't mean they should immediately be given commit > > > power > > > etc. But at the very least be helped to improve and acquire > > > experience. > > > > I strongly disagreee; people should come to freeware projects > > as "self starters" with some meaningful combination of decent > > industry experience and talent. > > Perhaps that's one point where opinions diverge. Especially if the freeware (it commonly is) is proprietary software… as according free-software philosophy, GNU’s philosophy, proprietary software *shouldn’t exist at all*. But moreover, what if those other projects also have low quality standards? or simply standards different from GNU ones? giving a link to GNU coding standards (actually even packaged into debian), for instance, would be pretty reasonable mentoring. > > Simply put nobody has the time to tutor you. > > You have all the code; you can study it. There are books, > > tutorials, and other resources. > > So the new generation will have to learn by itself? Do not be surprised > if it doesn't wish to pick up the software that was produced by the > previous generation, and will just rewrite everything with non-free > tools etc. It could simply be “rewrite everything”. It doesn’t have to be non-free. “all reserved” copyright, and stopping people from studying and reading code, has not to be the norm for mankind. If they do non-free, it’s not because “they are not teached” appropriatedly, that’s the fantasy of the “homo homine lupus est”. If they ever do, it’s actually because they were *teached* into non-free software, or tricked into it, either by bad teachers, or by bad laws. But that problem is absolutely not technical, it is political. What is to be fixed here is philosophy, politics, not anything technical such as ability to contribute or so… We shouldn’t be defending free software because it is good but because it gives freedom, so we shouldn’t try to make it good *just* for the fantasy of it to be considered as such so then people agree on free software. People need to be *politically convinced*. Otherwise, it’s simply moot. They may simply betrail as soon as the economical conjoncture or the political system (say: one that *forbids* free software) abandons us, and put their comfort at stake. We shouldn’t value freedom just because at a certain time it gives us comfort, because it could change. Freedom is not freedom to be comfortable, freedom is freedom to do anything you find appropriate to *make stuff comfortable* when you find it is not already. Without the possibility of discomfort, there wouldn’t be a point in freedom. If we sucked, then maybe they should rewrite other free-software from scratch… very good, if it’s a consequence from the fact we’re unable to understand them, they shall not simply listen and obey to us! but if they write non-free software… then being “good” wouldn’t help in anyway, because they wouldn’t do that for freedom. And anyway, if we want more software to be free, we should research to be used, for instance as dependency, for linking, for scripting, etc. because by the virtue of GPL it would make their things free, regardless of their opinion. And to obtain that, we need to produce software that runs well and that have proper and clean interfaces… which require skills, sometimes precise people whose departure would be a certain loss. Then what if more contributors are attracted, but the software less used? less linked against? less relied upon? > If nobody is there to hold their hand, I don't see a reason why they > would listen to the free software goals. Freedom. Freedom is valuable per se. I think the biggest downside you could find *against* rms would be that if he never existed, some other people at some time (maybe later, maybe less consistently) would have got his ideas. This is something you can point against him, and at the same time a compliment… of consistency, of strength, of moral value. So people will want to uphold freedom anyway. Maybe fewer, and that would be sad, but then we’d need to give them *political* hand-holding, not technical one. Because free-software philosophy is philosophy, freedom philosophy, universal philosophy, we don’t need to be specially nice or welcoming to uphold it. We can do it, and at the same time be true to self, even the worse person imagineable… Imagine what if we needed to be nice to be against something as bad as torture? because then people would say “if we are not convincing they will turn to accept it”… but holy crap! it would be horrible! we don’t need to do anything special for torture to be bad already! you can’t say it’s purely our fault then, because we’re not nice or welcoming enough, if people
Re: State of the GNUnion 2020
Alexandre François Garreau, le sam. 22 févr. 2020 22:46:11 +0100, a ecrit: > Le samedi 22 février 2020, 21:15:19 CET Samuel Thibault a écrit : > > Alexandre François Garreau, le sam. 22 févr. 2020 13:50:49 +0100, a > ecrit: > > > Le vendredi 21 février 2020, 22:57:55 CET Samuel Thibault a écrit : > > > > Alexandre François Garreau, le ven. 21 févr. 2020 11:59:42 +0100, a > > > > > > ecrit: > > > > > Le jeudi 20 février 2020, 18:39:52 CET Samuel Thibault a écrit : > > > > > > I'm not saying that GNU will necessarily stop growing and > > > > > > decline. > > > > > > What > > > > > > I'm afraid is that it might just become insignificant compared > > > > > > to > > > > > > others, and thus its voice for the 4 freedoms become less and > > > > > > less > > > > > > heard. > > > > > > > > > > That’s a reasonable fear, so that should be what should have been > > > > > measured in the metrics discussed in this thread. > > > > > > > > But how can you measure *that*? > > > > > > Do the same metrics with other projects, possibly linked but faarer, > > > included in GNU(/Linux) OS, be it Linux, Xorg packages, (La)TeX, KDE, > > > Gnome, etc. > > > > That would allow to compare with other free software projects, yes. But > > what I'm after is not comparing with other free software projects, but > > with other places where people may want to contribute. Places which are > > not necessarily so much about free software and do not aim to be, such > > as github. > > But then it is not really specifically about GNU anymore… > > And if something between github vs. the rest is to be learnt… then this is > something to be learn to how much SaaS (“cloud”)-based platforms are > preferred to self-hosting… this does not indicate anything toward what to > do. It is obvious that centralization and uniformity is more simple hence > more attractive… but we shouldn’t do it anyway… I guess "place" was a wrong word to mentioned what I meant. I'm not talking about the host platform by itself, but the community. A lot of people on github don't necessarily think much about free software. Not attracting people to GNU projects means they'll go to such other communities, where the goals of free software are not exposed. Samuel
Re: State of the GNUnion 2020
Alexandre François Garreau, le sam. 22 févr. 2020 22:43:36 +0100, a ecrit: > Le samedi 22 février 2020, 21:10:33 CET Samuel Thibault a écrit : > > Alexandre François Garreau, le sam. 22 févr. 2020 19:21:18 +0100, a > ecrit: > > > I recall some of them (likely one of those you’re thinking about is > > > the > > > same as I), > > > > Possibly. > > FDN right? Yes. > > > > > you prefer to “aknowledge” this “will have to be done at some > > > > > point”. Is if there wasn’t any middle ground for compromision > > > > > there. > > > > > > > > Sometimes you can't find any. > > > > > > No, you can’t know. > > > > Strictly speaking, sure, but at some point when things only get worse > > and worse, it's way better to resort to exclusion than continuing to see > > a project get stuck due to only one person, even if with several dozen > > years you might find a solution. > > However I’m still dubitative about the fact a single person could get ALL > A PROJECT project stuck alone, without exception. I was indeed taking an extreme example. But a much simpler case would be somebody calling everything names, thus driving away newcomers, who will wonder that the heck this project is about. > > How different is this from exclusion? > > It is different in that that anybody have the free choice of moderation, or > not. You could have your own moderation filters overriding those of your > trusted friends, you could change the amount of trust you give to each, > etc. Ok, so newcomers would have to know about it and make it work to avoid the nasty messages? Samuel
Re: State of the GNUnion 2020
Le samedi 22 février 2020, 21:15:19 CET Samuel Thibault a écrit : > Alexandre François Garreau, le sam. 22 févr. 2020 13:50:49 +0100, a ecrit: > > Le vendredi 21 février 2020, 22:57:55 CET Samuel Thibault a écrit : > > > Alexandre François Garreau, le ven. 21 févr. 2020 11:59:42 +0100, a > > > > ecrit: > > > > Le jeudi 20 février 2020, 18:39:52 CET Samuel Thibault a écrit : > > > > > I'm not saying that GNU will necessarily stop growing and > > > > > decline. > > > > > What > > > > > I'm afraid is that it might just become insignificant compared > > > > > to > > > > > others, and thus its voice for the 4 freedoms become less and > > > > > less > > > > > heard. > > > > > > > > That’s a reasonable fear, so that should be what should have been > > > > measured in the metrics discussed in this thread. > > > > > > But how can you measure *that*? > > > > Do the same metrics with other projects, possibly linked but faarer, > > included in GNU(/Linux) OS, be it Linux, Xorg packages, (La)TeX, KDE, > > Gnome, etc. > > That would allow to compare with other free software projects, yes. But > what I'm after is not comparing with other free software projects, but > with other places where people may want to contribute. Places which are > not necessarily so much about free software and do not aim to be, such > as github. But then it is not really specifically about GNU anymore… And if something between github vs. the rest is to be learnt… then this is something to be learn to how much SaaS (“cloud”)-based platforms are preferred to self-hosting… this does not indicate anything toward what to do. It is obvious that centralization and uniformity is more simple hence more attractive… but we shouldn’t do it anyway…
Re: State of the GNUnion 2020
* Kaz Kylheku (gnu-misc-discuss) <936-846-2...@kylheku.com> [2020-02-23 00:30]: > On 2020-02-22 12:50, Jean Louis wrote: > > * Samuel Thibault [2020-02-22 23:45]: > > > Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 > > > -0800, a ecrit: > > > If nobody is there to hold their hand, I don't see a reason why they > > > would listen to the free software goals. > > > > I am in agreement with you. Why not make your free software philosophy > > seminar somewhere? Promote the free software philosophy. > > This is not going to be an easy seminar. Today, your audience will > not consist of people who use downloaded and installed applications on > a PC or Mac for which we'd like them to have free alternatives on > a free OS, or even on that same non-free OS in some cases. It does not matter. That was always so. Wasn't it? > You will have to have solid answers for people who are tied to > proprietary services that execute somewhere in a cloud. I don't see a problem. I talk to people face to face about proprietary software every day, and problems are solved by installing free software on their computers and devices, so they may be tied, but we cut it off by communicating about it. > If you're unlucky that day, a heckler in the audience will speak up > about how Free Software cheerfully provides much of the > infrastructure that powers the exploitation. It requires some skills to handle hacklers, but in some countries, hacklers are non-existent, so it is not my specific concern. I will try to do what I can myself. Jean
Re: State of the GNUnion 2020
Le samedi 22 février 2020, 21:10:33 CET Samuel Thibault a écrit : > Alexandre François Garreau, le sam. 22 févr. 2020 19:21:18 +0100, a ecrit: > > I recall some of them (likely one of those you’re thinking about is > > the > > same as I), > > Possibly. FDN right? > > > > you prefer to “aknowledge” this “will have to be done at some > > > > point”. Is if there wasn’t any middle ground for compromision > > > > there. > > > > > > Sometimes you can't find any. > > > > No, you can’t know. > > Strictly speaking, sure, but at some point when things only get worse > and worse, it's way better to resort to exclusion than continuing to see > a project get stuck due to only one person, even if with several dozen > years you might find a solution. I’m more arguing about solution-finding that “no you’re wrong it’s better to get stuck”. However I’m still dubitative about the fact a single person could get ALL A PROJECT project stuck alone, without exception. If the only way is then to make the person gone… well that’s then a fragile project with a fragile social structure… even if exclusion looks like it solved anything, to me this is only appearance… in a world where cointelpro existed… I wish we would work to more resilient social structures. > > > > The idea of shared kill/blacklist or /ignore have been already > > > > proposed. That solves it. > > > > > > Not necessarily for less strong people. Just leaving out is simpler > > > than having to yet again set up some filters and everything. > > > > If it could be automatic, nope, it would *even politically* be more > > simple, if it was decentralized (yet automatic). Think of a WoT of > > blacklists, for instance. > > How different is this from exclusion? It is different in that that anybody have the free choice of moderation, or not. You could have your own moderation filters overriding those of your trusted friends, you could change the amount of trust you give to each, etc. The simplest thing is a boolean: moderation / no-moderation. That already would be really good. Only then people would begin to actually realize that moderation is subjective, and not obvious.
Re: State of the GNUnion 2020
* Samuel Thibault [2020-02-23 00:35]: > > GNU project is about making free operating system, thus it is there, > > as long as it is compatible with computers, you may carry it on in the > > future life. > > Sure. But how to make sure it will outlive me? > > Samuel Maybe you just think of GNU in terms of community. I know there is community around GNU and within the GNU. If you like to community, contribute to community, don't divide it. Contribute free software, make free software philosophy promotion, report bugs, install free software to hospitals, friends, in schools and university, contribute to awareness. To really make sure is impossible, just as anything else in the world, there is nothing sure on this planet. Jean P.S. Other solution could be a time capsule?
Re: State of the GNUnion 2020
Jean Louis, le dim. 23 févr. 2020 00:04:46 +0300, a ecrit: > Give me a break. I explained what I meant to mean. I don't see what else you would want. > > > > I'm here speaking as an oldie, actually. An oldie who had to ask himself > > > > that very question for some projects already. I have already seen some > > > > projects litteraly die with their leader. You have to welcome newcomers, > > > > beginners, etc. otherwise your project will just stop when you're not > > > > there to continue them any more. Getting old is just an example. Having > > > > children or moving onto another project are other examples. > > > > > > So what, it happens for last 500,000 years ago. > > > > Ok. But don't we want the GNU project to outlive ourself? To make sure > > that the next generations will have a free operating system? > > GNU project is about making free operating system, thus it is there, > as long as it is compatible with computers, you may carry it on in the > future life. Sure. But how to make sure it will outlive me? Samuel
Re: State of the GNUnion 2020
Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 13:17:06 -0800, a ecrit: > On 2020-02-22 12:43, Samuel Thibault wrote: > > Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a > > ecrit: > > > But does it? If inexperienced people are a protected class, then it > > > doesn't matter how the blocking is done. The blocking violates the > > > social > > > contract and that's that. > > > > Could you avoid interpreting everything either pure black or pure white? > > The point is that if you codify things in documents, you *have* to > 'debug' those documents through a black and white interpretation, > because that interpretation will happen. We were talking about my mail, it's not meant to be codifying. > > > In what industrialized nation can you not reject job applicants for > > > low > > > experience, due to that being discrimination against a > > > constitutionally > > > protected class? > > > > The protection is against harassment, not about getting changes > > commited. > > I don't see wording to that effect, though; that's just what you think. The text does precisely say "harassment". Samuel
Re: State of the GNUnion 2020
On 2020-02-22 12:43, Samuel Thibault wrote: Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a ecrit: But does it? If inexperienced people are a protected class, then it doesn't matter how the blocking is done. The blocking violates the social contract and that's that. Could you avoid interpreting everything either pure black or pure white? The point is that if you codify things in documents, you *have* to 'debug' those documents through a black and white interpretation, because that interpretation will happen. What you're asking for is like, "can you just test what my program is supposed to do with just the intended inputs?" You have to think about the unintended consequences. The text is saying "It welcomes all contributors". That doesn't mean committing everything that gets submitted. Someone who cannot get *anything* submitted will get upset and cry foul about not-welcoming behavior, and so it goes. In what industrialized nation can you not reject job applicants for low experience, due to that being discrimination against a constitutionally protected class? The protection is against harassment, not about getting changes commited. I don't see wording to that effect, though; that's just what you think.
Re: State of the GNUnion 2020
* Samuel Thibault [2020-02-22 23:58]: > Jean Louis, le sam. 22 févr. 2020 23:43:55 +0300, a ecrit: > > * Samuel Thibault [2020-02-22 23:22]: > > > Jean Louis, le sam. 22 févr. 2020 18:02:42 +0300, a ecrit: > > > > * Samuel Thibault [2020-02-22 12:51]: > > > > > Really, not including the next generations in a project is running the > > > > > risk of the project just dying with its leaders. > > > > > > > > I can see great bunch of disrespect there. > > > > > > > > I am born in place where our parents teach us good manners. > > > > > > I'm sorry and apologize if you felt disrespect, that was not meant to > > > be. > > > > No, I do not feel any disrespect to me, and I would not care really, > > as we are far apart and there is no practical influence. > > > > But to use the GNU mailing list, to divide the GNU, and to use the GNU > > mailing list and to speak of RMS dying, with its leaders, that is > > disrespect and bad manner. > > I was not talking about a particular person, but about projects in > general. Also, see the "s" in "leaders". That was really meant to be a > general phrasing. Look -- let me come to the house of my friend's father, and then speak that houses are often sold when fathers as owners of the house dies. I am not speaking about particular person, but just about general fathers of houses in general, and I am using "s" for plural, as that is meant to be general phrasing. Give me a break. > > > I'm here speaking as an oldie, actually. An oldie who had to ask himself > > > that very question for some projects already. I have already seen some > > > projects litteraly die with their leader. You have to welcome newcomers, > > > beginners, etc. otherwise your project will just stop when you're not > > > there to continue them any more. Getting old is just an example. Having > > > children or moving onto another project are other examples. > > > > So what, it happens for last 500,000 years ago. > > Ok. But don't we want the GNU project to outlive ourself? To make sure > that the next generations will have a free operating system? GNU project is about making free operating system, thus it is there, as long as it is compatible with computers, you may carry it on in the future life. > I'm not saying that all current GNU packages should live on > indefinitely. I'm saying that if we don't make sure to include newcomers > to GNU packages, newcomers will not consider making their new software > part of GNU, and the GNU project will just shade with time. Give me example of one newcomer who was not included. Please cut the generalities, give me one example, and let us contact somebody in GNU project to see why that particular example was not included. Jean
Re: State of the GNUnion 2020
Jean Louis, le sam. 22 févr. 2020 23:43:55 +0300, a ecrit: > * Samuel Thibault [2020-02-22 23:22]: > > Jean Louis, le sam. 22 févr. 2020 18:02:42 +0300, a ecrit: > > > * Samuel Thibault [2020-02-22 12:51]: > > > > Really, not including the next generations in a project is running the > > > > risk of the project just dying with its leaders. > > > > > > I can see great bunch of disrespect there. > > > > > > I am born in place where our parents teach us good manners. > > > > I'm sorry and apologize if you felt disrespect, that was not meant to > > be. > > No, I do not feel any disrespect to me, and I would not care really, > as we are far apart and there is no practical influence. > > But to use the GNU mailing list, to divide the GNU, and to use the GNU > mailing list and to speak of RMS dying, with its leaders, that is > disrespect and bad manner. I was not talking about a particular person, but about projects in general. Also, see the "s" in "leaders". That was really meant to be a general phrasing. > > I'm here speaking as an oldie, actually. An oldie who had to ask himself > > that very question for some projects already. I have already seen some > > projects litteraly die with their leader. You have to welcome newcomers, > > beginners, etc. otherwise your project will just stop when you're not > > there to continue them any more. Getting old is just an example. Having > > children or moving onto another project are other examples. > > So what, it happens for last 500,000 years ago. Ok. But don't we want the GNU project to outlive ourself? To make sure that the next generations will have a free operating system? I'm not saying that all current GNU packages should live on indefinitely. I'm saying that if we don't make sure to include newcomers to GNU packages, newcomers will not consider making their new software part of GNU, and the GNU project will just shade with time. Samuel
Re: State of the GNUnion 2020
Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 12:22:55 -0800, a ecrit: > On 2020-02-22 01:50, Samuel Thibault wrote: > > Really, not including the next generations in a project is running the > > risk of the project just dying with its leaders. > > Project "liveness" is not the ultimate value. If nobody is found who > will maintain it the way it ought to be, then let it die. Sure. But what will rather happen is that the new generation will just rewrite another program, possibly without caring about making it free software. > I suspect that these initiatives to have inclusion of regardless > experience are driven by project zeal, and envy of popular projects. It's not a question of envy, but of making sure that on the long term we still have a free operating system. If we don't include the new generation, and alongside teach it why we need free software. The new generation may just not care about picking up the task, we may then grow old in a world with non-free software. Samuel
Re: State of the GNUnion 2020
* Samuel Thibault [2020-02-22 23:45]: > Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a ecrit: > > On 2020-02-22 01:50, Samuel Thibault wrote: > > > Yes. Which doesn't mean they should immediately be given commit power > > > etc. But at the very least be helped to improve and acquire experience. > > > I strongly disagreee; people should come to freeware projects > > as "self starters" with some meaningful combination of decent > > industry experience and talent. > > Perhaps that's one point where opinions diverge. > > > Simply put nobody has the time to tutor you. > > You have all the code; you can study it. There are books, > > tutorials, and other resources. > > So the new generation will have to learn by itself? Do not be surprised > if it doesn't wish to pick up the software that was produced by the > previous generation, and will just rewrite everything with non-free > tools etc. > > If nobody is there to hold their hand, I don't see a reason why they > would listen to the free software goals. I am in agreement with you. Why not make your free software philosophy seminar somewhere? Promote the free software philosophy. Promoting only software does not really educate people on free software, it is a long process to get it spontaneous that way. > I didn't mean *pure* protection. I just mean that for instance when > a complete newcomer proposes a crappy patch, one should tell him why > it should be improve (and not just call it crap). I can totally understand what you mean, but it is not practical to try to police other people's behavior. There are many different mentalities, planet Earth is developing, but it does not need new type of fascism to police what and how people should behave. It is always good to help people. But you should not police other people, rather do it yourself. Help people in that manner how you think it is appropriate. But let other people be. You are not creating any community that way, you wish to create police to control other people's behavior. So far I know, GNU project was always welcoming, and kind, I cannot say different. Jean
Re: State of the GNUnion 2020
* Samuel Thibault [2020-02-22 23:22]: > Jean Louis, le sam. 22 févr. 2020 18:02:42 +0300, a ecrit: > > * Samuel Thibault [2020-02-22 12:51]: > > > Really, not including the next generations in a project is running the > > > risk of the project just dying with its leaders. > > > > I can see great bunch of disrespect there. > > > > I am born in place where our parents teach us good manners. > > I'm sorry and apologize if you felt disrespect, that was not meant to > be. No, I do not feel any disrespect to me, and I would not care really, as we are far apart and there is no practical influence. But to use the GNU mailing list, to divide the GNU, and to use the GNU mailing list and to speak of RMS dying, with its leaders, that is disrespect and bad manner. > I'm here speaking as an oldie, actually. An oldie who had to ask himself > that very question for some projects already. I have already seen some > projects litteraly die with their leader. You have to welcome newcomers, > beginners, etc. otherwise your project will just stop when you're not > there to continue them any more. Getting old is just an example. Having > children or moving onto another project are other examples. So what, it happens for last 500,000 years ago. Sorry, I don't find it excused or justified. You are using the gnu.org email address given to you by RMS, to speak about the death of RMS in a jokingly manner. No, I don't find it well. Jean
Re: State of the GNUnion 2020
Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a ecrit: > On 2020-02-22 01:50, Samuel Thibault wrote: > > Yes. Which doesn't mean they should immediately be given commit power > > etc. But at the very least be helped to improve and acquire experience. > I strongly disagreee; people should come to freeware projects > as "self starters" with some meaningful combination of decent > industry experience and talent. Perhaps that's one point where opinions diverge. > Simply put nobody has the time to tutor you. > You have all the code; you can study it. There are books, > tutorials, and other resources. So the new generation will have to learn by itself? Do not be surprised if it doesn't wish to pick up the software that was produced by the previous generation, and will just rewrite everything with non-free tools etc. If nobody is there to hold their hand, I don't see a reason why they would listen to the free software goals. > Changes from outsiders should be merged based on the merit > of those changes. Sure! > I think that someone who keeps sending bad changes may come to > be routinely ignored as an optimization; Sure! I'm not saying otherwise. If even after remarks etc. somebody doesn't improve, it's fine to stop trying to help. > Lastly, who have commit powers have nobody above them; they must > themselves be experienced. The GNU project should not take on > dabbling amateurs as maintainers and should never have any > sort of document which suggests otherwise. Sure, see what I mentioned above. > > > So, if people have to be excluded to bring about inclusion, > > > let us ask: whom do you have to exclude in order to include > > > people with a low level of experience? > > > > > > I suspect that the answer is: some experienced people, > > > who would block their bad work. > > > > That wholy depends how "block" is done. > > But does it? If inexperienced people are a protected class, then it > doesn't matter how the blocking is done. The blocking violates the social > contract and that's that. Could you avoid interpreting everything either pure black or pure white? I didn't mean *pure* protection. I just mean that for instance when a complete newcomer proposes a crappy patch, one should tell him why it should be improve (and not just call it crap). And if after a few iteration there is no progress, one can just say "well, I'm sorry, the contribution does not have the level we can accept, please work on it and come back once you have improved". > Analogy: you can't refuse patrons from your restaurant, on the basis > of their race, no matter how politely you behave. That's not the same situation. I'm not saying the social contract would impose to accept contributions from inexperienced people. The text is saying "It welcomes all contributors". That doesn't mean committing everything that gets submitted. > In what industrialized nation can you not reject job applicants for low > experience, due to that being discrimination against a constitutionally > protected class? The protection is against harassment, not about getting changes commited. > > If the blocking is just "this is > > bullshit" mail without explanation, and stick with such behavior, that > > That's just a straight violation of the kind communication guidelines. And the proposed social contract provides the general idea. > > > Older people are politically insensitive, and too smart to accept crap > > > software changes. > > > > I'm not saying to accept crap software changes. > > *You* may not be, but that "social contract" appears to be. > It supports that interpretation. How is it appearing to be? "welcomes contributions from all and everyone" "providing a harassment-free experience for all contributors" "give everyone the opportunity of contributing" "welcomes all contributors" None of these say changes have to be committed. "Welcome" or "give opportunity" doesn't mean "commit the change". > > I'm saying to explain why they are crap without calling them names. > > There can be situations when you just have tobe done explaining > and that's that. As a volunteer, you don't owe anyone anything, > including detailed explanations which amount to tutoring someone about > why their change proposal cannot be merged. Sure, volunteers can take the amount of time they wish. But the minimum is to point out the problems. Samuel
Re: State of the GNUnion 2020
On 2020-02-22 01:50, Samuel Thibault wrote: Really, not including the next generations in a project is running the risk of the project just dying with its leaders. Project "liveness" is not the ultimate value. If nobody is found who will maintain it the way it ought to be, then let it die. If I leave behind some program that so few are interested in that the best talent willing to maintain it is not very good, then so be it. It doesn't have to be forced on me while I'm still able to shake a fist. I suspect that these initiatives to have inclusion of regardless experience are driven by project zeal, and envy of popular projects. The idea is to bring in people to generate activity. Any people. Just warm bodies to stimulate project liveness.
Re: State of the GNUnion 2020
Jean Louis, le sam. 22 févr. 2020 18:02:42 +0300, a ecrit: > * Samuel Thibault [2020-02-22 12:51]: > > Really, not including the next generations in a project is running the > > risk of the project just dying with its leaders. > > I can see great bunch of disrespect there. > > I am born in place where our parents teach us good manners. I'm sorry and apologize if you felt disrespect, that was not meant to be. I'm here speaking as an oldie, actually. An oldie who had to ask himself that very question for some projects already. I have already seen some projects litteraly die with their leader. You have to welcome newcomers, beginners, etc. otherwise your project will just stop when you're not there to continue them any more. Getting old is just an example. Having children or moving onto another project are other examples. Samuel
Re: State of the GNUnion 2020
Alexandre François Garreau, le sam. 22 févr. 2020 13:50:49 +0100, a ecrit: > Le vendredi 21 février 2020, 22:57:55 CET Samuel Thibault a écrit : > > Alexandre François Garreau, le ven. 21 févr. 2020 11:59:42 +0100, a > ecrit: > > > Le jeudi 20 février 2020, 18:39:52 CET Samuel Thibault a écrit : > > > > I'm not saying that GNU will necessarily stop growing and decline. > > > > What > > > > I'm afraid is that it might just become insignificant compared to > > > > others, and thus its voice for the 4 freedoms become less and less > > > > heard. > > > > > > That’s a reasonable fear, so that should be what should have been > > > measured in the metrics discussed in this thread. > > > > But how can you measure *that*? > > Do the same metrics with other projects, possibly linked but faarer, > included in GNU(/Linux) OS, be it Linux, Xorg packages, (La)TeX, KDE, > Gnome, etc. That would allow to compare with other free software projects, yes. But what I'm after is not comparing with other free software projects, but with other places where people may want to contribute. Places which are not necessarily so much about free software and do not aim to be, such as github. Samuel
Re: State of the GNUnion 2020
Alexandre François Garreau, le sam. 22 févr. 2020 19:21:18 +0100, a ecrit: > I recall some of them (likely one of those you’re thinking about is the > same as I), Possibly. > > > you prefer to “aknowledge” this “will have to be done at some > > > point”. Is if there wasn’t any middle ground for compromision > > > there. > > > > Sometimes you can't find any. > > No, you can’t know. Strictly speaking, sure, but at some point when things only get worse and worse, it's way better to resort to exclusion than continuing to see a project get stuck due to only one person, even if with several dozen years you might find a solution. > > > The idea of shared kill/blacklist or /ignore have been already > > > proposed. That solves it. > > > > Not necessarily for less strong people. Just leaving out is simpler than > > having to yet again set up some filters and everything. > > If it could be automatic, nope, it would *even politically* be more > simple, if it was decentralized (yet automatic). Think of a WoT of > blacklists, for instance. How different is this from exclusion? Samuel
Re: State of the GNUnion 2020
On 2020-02-22 01:50, Samuel Thibault wrote: Kaz Kylheku (gnu-misc-discuss), le jeu. 20 févr. 2020 13:55:37 -0800, a ecrit: On 2020-02-20 11:42, Andreas R. wrote: > On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote: > > > On the flip side, an argument is made that your initiative might make GNU > > > more exclusionary because of the extra conditions on what it takes to be a > > > part of it. > > > > At some point you have to exclude some people in order to include > > other > > people, yes. We can see that in various communities: One group whose inclusion is being specifically promoted by the proposed social contract is people with a low level of experience. Not "promoted" but "protected". The exact rhetoric is that people must be included regardless of their level of experience, which can only possibly mean regardless of how low is their level of experience. Yes. Which doesn't mean they should immediately be given commit power etc. But at the very least be helped to improve and acquire experience. I strongly disagreee; people should come to freeware projects as "self starters" with some meaningful combination of decent industry experience and talent. Simply put nobody has the time to tutor you. You have all the code; you can study it. There are books, tutorials, and other resources. Changes from outsiders should be merged based on the merit of those changes. (And that has been my experience; I've never been challenged to provide a resume detailing my level of experience!) I think that someone who keeps sending bad changes may come to be routinely ignored as an optimization; there has to be room for associating bad changes with a person or online account, for expediency. Lastly, who have commit powers have nobody above them; they must themselves be experienced. The GNU project should not take on dabbling amateurs as maintainers and should never have any sort of document which suggests otherwise. GNU programs and components are production code relied upon by the world in "mission-critical" deployments. I'm all for mentoring. Maybe there should be a dedicated GNU or FSF initiative for that, "GNU Bootcamp" or something. Where would the resources come from. So, if people have to be excluded to bring about inclusion, let us ask: whom do you have to exclude in order to include people with a low level of experience? I suspect that the answer is: some experienced people, who would block their bad work. That wholy depends how "block" is done. But does it? If inexperienced people are a protected class, then it doesn't matter how the blocking is done. The blocking violates the social contract and that's that. Analogy: you can't refuse patrons from your restaurant, on the basis of their race, no matter how politely you behave. Basically, equating inexperience with attributes like race is completely unacceptable, insane nonsense that's not practiced anywhere. In what industrialized nation can you not reject job applicants for low experience, due to that being discrimination against a constitutionally protected class? If the blocking is just "this is bullshit" mail without explanation, and stick with such behavior, that That's just a straight violation of the kind communication guidelines. Older people are politically insensitive, and too smart to accept crap software changes. I'm not saying to accept crap software changes. *You* may not be, but that "social contract" appears to be. It supports that interpretation. I'm saying to explain why they are crap without calling them names. There can be situations when you just have tobe done explaining and that's that. As a volunteer, you don't owe anyone anything, including detailed explanations which amount to tutoring someone about why their change proposal cannot be merged.
Re: State of the GNUnion 2020
Le vendredi 21 février 2020, 22:55:04 CET Samuel Thibault a écrit : > Alexandre François Garreau, le ven. 21 févr. 2020 12:39:37 +0100, a ecrit: > > It is defeatist because it departs from the basic idea you’ll *have* > > to > > exclude someone at some point. No solution will ever be found. > > Yes. Been there a few times, had to resort to it, I remember a case > where it was after a couple of *years* trying with others to find a > solution. I recall some of them (likely one of those you’re thinking about is the same as I), as the technical and political solutions I proposed keep staying the same… > > And rather than taking the risk of not reacting immediately > > (“tolerance zero”, another right wing thing) > > I never said reaction had to be immediate. Sorry then, my bad. > > you prefer to “aknowledge” this “will have to be done at some > > point”. Is if there wasn’t any middle ground for compromision > > there. > > Sometimes you can't find any. No, you can’t know. We’re talking about social stuff, hence, complex and pretty unpredictable, and not possibly all-understandable. You can’t demonstrate things about people the same you can make a mathematical proof so you know there aren’t any unthought possibility left. So the only thing you can say is “we (a fixed set of people) couldn’t find any *in that limited amount of time*”, and then, if it’s so hard, that’d more to me an incentive to harder measures… but total exclusion is the ultimate one. I’m sure with good will or at least inventivity, we can find all sorts of middle grounds to this one… For instance, a plain moderation-less list, and a moderated one, that would replicate the first, with moderation added. > > The idea of shared kill/blacklist or /ignore have been already > > proposed. That solves it. > > Not necessarily for less strong people. Just leaving out is simpler than > having to yet again set up some filters and everything. If it could be automatic, nope, it would *even politically* be more simple, if it was decentralized (yet automatic). Think of a WoT of blacklists, for instance. > > It is paternalist because it assumes *the chiefs* have to take care > > for > > “uncomfort” and “stuff people couldn’t stand”. > > In my book, parts of chiefs' role is making sure people are comfortable, > yes. I don’t like giving so much power to anyone… > > It always will be, because “excluding” these “toxic” people won’t make > > them disappear away, they always will be somewhere. > > Possibly, unfortunately. That said, sometimes some people are only toxic > in a given situation, and just excluding them from it avoids the issue. Though I always despice the word and concept of “toxic” as much, this is an interesting point. I’d be content to see example, but even the very idea is interesting and new to me. > Sure. But not everybody can (I'm not sure anybody can really in all > situations). Yeah some can and are really hardskinned, but a few and not always equally distributed in all social milieus.
Re: State of the GNUnion 2020
> From: DJ Delorie > 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.
Re: State of the GNUnion 2020
* Samuel Thibault [2020-02-22 12:51]: > Really, not including the next generations in a project is running the > risk of the project just dying with its leaders. I can see great bunch of disrespect there. I am born in place where our parents teach us good manners. Jean
Re: State of the GNUnion 2020
Kaz Kylheku (gnu-misc-discuss), le jeu. 20 févr. 2020 13:55:37 -0800, a ecrit: > On 2020-02-20 11:42, Andreas R. wrote: > > On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote: > > > > On the flip side, an argument is made that your initiative might make > > > > GNU > > > > more exclusionary because of the extra conditions on what it takes to > > > > be a > > > > part of it. > > > > > > At some point you have to exclude some people in order to include > > > other > > > people, yes. We can see that in various communities: > > One group whose inclusion is being specifically promoted by the > proposed social contract is people with a low level of experience. Not "promoted" but "protected". > The exact rhetoric is that people must be included regardless of > their level of experience, which can only possibly mean > regardless of how low is their level of experience. Yes. Which doesn't mean they should immediately be given commit power etc. But at the very least be helped to improve and acquire experience. > So, if people have to be excluded to bring about inclusion, > let us ask: whom do you have to exclude in order to include > people with a low level of experience? > > I suspect that the answer is: some experienced people, > who would block their bad work. That wholy depends how "block" is done. If the blocking is just "this is bullshit" mail without explanation, and stick with such behavior, that is detrimental to the project: newcomers will not come, and the project will not be florishing. If the block is "this can't work because this and that, this is not properly written because this and that", that's helpful to the newcomer, who will improve over time, and become a useful contributor to the project. > Older people are politically insensitive, and too smart to accept crap > software changes. I'm not saying to accept crap software changes. I'm saying to explain why they are crap without calling them names. Really, not including the next generations in a project is running the risk of the project just dying with its leaders. Samuel
Re: State of the GNUnion 2020
On Fri, Feb 21, 2020 at 09:09:47PM +0100, Andreas Enge wrote: > As I see it, the GNU Social Contract > contains only trivialities in the sense that it summarises values of the > GNU project that are already there, and as such it is far from extremist. It could have contained only elements that were not controversial or trivial, but it doesn't. If concerns about the name of the document had been addressed, and point 3 had simply been lifted from the GKCG, I don't think there would have been much opposition. It might even have become published as a GNU document, because it would have contained, as you say, only values that were already there. Unfortunately, from the outside, it looks like the opposite happened: critique on the controversial parts were ignored, then doubled down on. It has been lamented by supporters that resistance seems to focus on the mere existence of the document, but that seems to be by design of those who drafted it: to stir up controversy and keep it controversial to garner attention. The whole process has not reflected well on the inner workings of the draft working group, especially given its political ambitions for a later stage. iirc you personally had no objections to amending the document on these points, and, from what I gather, were more interested in introducing and discussing Debian style governance. "Would GNU benefit from having a more Debian style governance, and is this possible whilst safeguarding its current values?" would have been a worthwile and straightforward discussion, but unfortunately, that was not to be at this point in time. thanks, Andreas R.
Re: State of the GNUnion 2020
> From: DJ Delorie > Cc: gnu-misc-discuss@gnu.org > Date: Thu, 20 Feb 2020 13:10:49 -0500 > > a...@gnu.org (Alfred M. Szmidt) writes: > > That speaks more to the fact that the GNU project leadership has no > > impact on project adaptation, or contributor activity. But rather it > > is a individual effort by each project maintainer. > > One could argue that this indicates that what you term "GNU leadership" > is not providing leadership to the projects, and that the maintainers > must provide that leadership themselves. What is the point of > leadership that has no impact? No one, not even the above quote, said they have "no impact" in general. 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 whether to accept this or that changeset, in what direction to develop the project, which new features are more important then others, how to attract more contributors, etc. etc. -- here the leadership has almost no impact. They will if we ask them for advice or help, but we rarely if ever do, because we generally know how to that stuff ourselves, and because besides general advice an outsider cannot really help in these matters. So the actual health and longevity of each project is almost completely dependent on the project maintainers, and the leadership has almost no influence there -- until and unless there's a crisis, of which we had a few: the Emacs/XEmacs fork, the EGCS split, the glibc incident, etc. Those are the few and far-in-between exceptions that IMO squarely tell us what the rule is. > Perhaps this view does not align with your view, but we must also > consider how the general public (or at least the general > free-software-involved public) views us from the outside. If they are > more likely to be influenced by the maintainers than by RMS, from > *their* point of view, the maintainers *are* the GNU leadership. We > should not be blind to how we are perceived by others. 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? IME, they only care when there's some potentially scandalous issue, or one that seems to be brewing. 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. > And don't fall into the trap of thinking leadership can only come from > one person. RMS may be "the leader" but he's not the only one providing > leadership to others. "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? If the latter, who specifically did you have in mind that is providing leadership to others at this time, or did in the past? And what kind of leadership is/was that?
Re: [Hangout - NYLXS] State of the GNUnion 2020
> Date: Fri, 21 Feb 2020 21:09:47 +0100 > From: Andreas Enge > Cc: gnu-misc-discuss@gnu.org > > Well, you are of course entitled to that opinion, but I am naturally of the > opposite one. Why "naturally"? Can you be convinced that your opinion is wrong? (If not, this seems to be a kind of religious argument, where no agreements or compromises can ever be reached.) If you can be convinced otherwise, what would it take for you to change your opinion?
Re: State of the GNUnion 2020
a...@gnu.org (Alfred M. Szmidt) writes: > That speaks more to the fact that the GNU project leadership has no > impact on project adaptation, or contributor activity. But rather it > is a individual effort by each project maintainer. One could argue that this indicates that what you term "GNU leadership" is not providing leadership to the projects, and that the maintainers must provide that leadership themselves. What is the point of leadership that has no impact? Perhaps this view does not align with your view, but we must also consider how the general public (or at least the general free-software-involved public) views us from the outside. If they are more likely to be influenced by the maintainers than by RMS, from *their* point of view, the maintainers *are* the GNU leadership. We should not be blind to how we are perceived by others. And don't fall into the trap of thinking leadership can only come from one person. RMS may be "the leader" but he's not the only one providing leadership to others.
Re: State of the GNUnion 2020
On 2020-02-20 10:06, a...@gnu.org wrote: I'm not saying that GNU will necessarily stop growing and decline. What I'm afraid is that it might just become insignificant compared to others, and thus its voice for the 4 freedoms become less and less heard. I think everyone would agree that we do not want the four freedoms to become irrelevant, or that the GNU project be forgotten. And I think everyone can also agree that there are groups that are working against it (see e.g. the whole idea of "ethical" licenses). There are more issues than four freedoms. For instance, the software developed under the GNU license, conforming to all the required freedoms, can easily be the platform for a weapons system used to strike non-military targets in contravention of the UN Charter. The suffering caused by users not having the right to build from source, modify and share the programs they use is rather one of these: https://en.wikipedia.org/wiki/First_World_problem Don't you think? Debates that are hinged to First World Problems get so heated precisely because the stakes are so small. It's just a bourgeoise thing. Look, I have a good tech job in a safe country, my belly is full. What to do? I know, I will get pissed off at proprietary software! Fast forward a few decades, and Microsoft is making in boatloads of money running a cloud business on GNU/Linux. Don't get me wrong; there are important issues this Digital Age. Unfortunately, most of them are not fixable simply via copyright.
Re: State of the GNUnion 2020
On 2020-02-20 11:42, Andreas R. wrote: On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote: > On the flip side, an argument is made that your initiative might make GNU > more exclusionary because of the extra conditions on what it takes to be a > part of it. At some point you have to exclude some people in order to include other people, yes. We can see that in various communities: One group whose inclusion is being specifically promoted by the proposed social contract is people with a low level of experience. The exact rhetoric is that people must be included regardless of their level of experience, which can only possibly mean regardless of how low is their level of experience. So, if people have to be excluded to bring about inclusion, let us ask: whom do you have to exclude in order to include people with a low level of experience? I suspect that the answer is: some experienced people, who would block their bad work. I smell age discrimination in disguise: experienced people tend to be old farts. Why not just make a simpler social contract: people are to be retired out of GNU on their 50th birthday. Older people are politically insensitive, and too smart to accept crap software changes. These factors work together to create an environment which prevents snowflakes from contributing to the GNU project. Am I getting warmer? Some examples of those communities and their problems might be helpful here to see if these communities can provide a useful parallel with GNU. Screw examples! Let's see the actuals. Under the proposed governance: - who is going to be included who currently isn't included? - who is going to be kicked out? Because ... that's obviously what this must be about, right? Or, if there are no such specifics, then this initiative is then simply about being able to wield that power. To wave it people's faces, and from time to time, use it.
Re: State of the GNUnion 2020
Alexandre François Garreau, le ven. 21 févr. 2020 11:59:42 +0100, a ecrit: > Le jeudi 20 février 2020, 18:39:52 CET Samuel Thibault a écrit : > > Alfred M. Szmidt, le jeu. 20 févr. 2020 12:32:16 -0500, a ecrit: > > > How does that have to do with the overall project leadership, which > > > hasn't changed significantly over the years, and yet had significant > > > growth in new projects for several decades (if we take the graphs by > > > Wingo at face value). > > > > "Significant growth" is very little compared to the huge growth that can > > be seen on other platforms. > > So when measuring we should only dare to measure GNU stuff in comparison > with other software projects and platforms. Very interesting. I never said you should *only* do that. I just said it is a comparison worth making, because it *does* have an impact on what platform people find about, and thus where they get ideas. > > I'm not saying that GNU will necessarily stop growing and decline. What > > I'm afraid is that it might just become insignificant compared to > > others, and thus its voice for the 4 freedoms become less and less > > heard. > > That’s a reasonable fear, so that should be what should have been measured > in the metrics discussed in this thread. But how can you measure *that*? Samuel
Re: State of the GNUnion 2020
Alexandre François Garreau, le ven. 21 févr. 2020 12:39:37 +0100, a ecrit: > It is defeatist because it departs from the basic idea you’ll *have* to > exclude someone at some point. No solution will ever be found. Yes. Been there a few times, had to resort to it, I remember a case where it was after a couple of *years* trying with others to find a solution. > And rather than taking the risk of not reacting immediately > (“tolerance zero”, another right wing thing) I never said reaction had to be immediate. > you prefer to “aknowledge” this “will have to be done at some > point”. Is if there wasn’t any middle ground for compromision > there. Sometimes you can't find any. > The idea of shared kill/blacklist or /ignore have been already proposed. > That solves it. Not necessarily for less strong people. Just leaving out is simpler than having to yet again set up some filters and everything. > It is paternalist because it assumes *the chiefs* have to take care for > “uncomfort” and “stuff people couldn’t stand”. In my book, parts of chiefs' role is making sure people are comfortable, yes. > It always will be, because “excluding” these “toxic” people won’t make > them disappear away, they always will be somewhere. Possibly, unfortunately. That said, sometimes some people are only toxic in a given situation, and just excluding them from it avoids the issue. > Now, in the previous case, with no exclusions, these people who learnt to > stand anything could, as soon as there is no official exclusion, participate > in anything, that is good. Sure. But not everybody can (I'm not sure anybody can really in all situations). Samuel
Re: State of the GNUnion 2020
Hello John, On Fri, Feb 21, 2020 at 12:54:19PM -0500, John Darrington wrote: > Therefore I'm extremely dissapointed that recently a small group of > GNU maintainers has started spreading nagative and misleading propaganda > about others within GNU this is not founded in any argument, but seems to be pure propaganda itself. Can you instantiate this claim? Who has spread which negative propaganda about whom? > demanding conformance to rules - sometimes > capricious ones - which have no relevance to GNU, and spreading of > extremist and quite orthogonal rhetoric. Can you give a concrete example? As I see it, the GNU Social Contract contains only trivialities in the sense that it summarises values of the GNU project that are already there, and as such it is far from extremist. > None of these actions are going to attract people to GNU. Quite the opposite. > They are driving people away. It has to stop - and the sooner the better. Well, you are of course entitled to that opinion, but I am naturally of the opposite one. And we have received feedback going exactly in that direction, that our initiative would be a good starting point to make someone come back to GNU. Andreas
Re: State of the GNUnion 2020
On 21.02.2020 10:07, Ludovic Courtès wrote: I don’t think so, but I’d rather emphasize “symbiosis” with some projects than disagreements with others. Oh well. So I'm yet to witness a practical disagreement that you have with RMS.
Re: State of the GNUnion 2020
Dmitry Gutov skribis: > On 20.02.2020 15:12, Ludovic Courtès wrote: >> As I see it, the point of the Social Contract you’re referring to is a >> commitment to work hand in hand with our natural allies. These could be >> projects that build software the GNU system or GNU applications rely on, >> or it could be projects fighting the same fight. > > To clarify: does LLVM fit either of the descriptions, in your opinion? I don’t think so, but I’d rather emphasize “symbiosis” with some projects than disagreements with others. Ludo’.
Re: [Hangout - NYLXS] State of the GNUnion 2020
Ruben Safir, le jeu. 20 févr. 2020 16:30:40 -0500, a ecrit: > On Thu, Feb 20, 2020 at 06:39:52PM +0100, Samuel Thibault wrote: > > Alfred M. Szmidt, le jeu. 20 f??vr. 2020 12:32:16 -0500, a ecrit: > > >> > Our concern is that at some point GNU may be just completely > > > unknown > > >> > to free software enthousiasts. As in, when you'd ask people what > > > free > > >> > software is about, they would answer "ah, yes, the stuff on github, > > >> > right". > > >> > > >> Okay, sure. But going back to Eli's point, the development activity > > > of > > >> individual projects is determined by individual project's members, > > > and is > > >> rarely affected by the actions of the leadership. > > > > > >The activity by itself, yes, but the choice of where to start a new > > >project, or starting contributing an existing project, leadership does > > >have a lot of importance. > > > > > > How does that have to do with the overall project leadership, which > > > hasn't changed significantly over the years, and yet had significant > > > growth in new projects for several decades (if we take the graphs by > > > Wingo at face value). > > > > "Significant growth" is very little compared to the huge growth that can > > be seen on other platforms. > > Non-sense. This is a platform to gaurantee the public has a Free System > to choose from. It is not to be measured feature by feature by grossly > over built systems which spinning insecure parts in every direction. > > The priority here not to build the best facebook ap. It is to build a > system that respects the user, user privacy and freedom. I'm not saying otherwise. But I'm saying that what newcomers mostly see nowadays is the github trend. And thus will not even be aware of its problems and the GNU project alternative. If GNU does not make actual efforts to be attractive (without leaving out its goal, of course), its message will not get received by new generations. Possibly a useful statistics to have would be the evolution of the average age of contributors. Samuel
Re: State of the GNUnion 2020
On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote: > > On the flip side, an argument is made that your initiative might make GNU > > more exclusionary because of the extra conditions on what it takes to be a > > part of it. > > At some point you have to exclude some people in order to include other > people, yes. We can see that in various communities: Some examples of those communities and their problems might be helpful here to see if these communities can provide a useful parallel with GNU. > That seems to be the ground of what some people do not understand here: > full inclusiveness can not work, there will always be some people you > will be excluding one way or the other Either of these ways could include maintaining a killfile and knowing the "/ignore" command, both actions that should be in reach for GNU maintainers. Ignoring someone in a private capacity is a powerful tool. If enough participants do so, a troublesome person can effectively be ostracised without having to formalise any edicts. In a way, extra social conditions curtail this privilege of personal responsibility for one's interactions with others; if interactions must be deemed appropriate by some third party, and if you disagree with the practice, you are no longer free to ignore others because they can punish you. Obviously some are not going to be comfortable with that concept in principle, especially if no actual need for such extra conditions have been demonstrated. > Making sure > that the choice of who you exclude gets written down seems important to > me. That's true if and only if you start excluding people from a position of power in the first place. Otherwise it's just people being people, getting along with some and ignoring others, as they naturally would. thanks, Andreas R.
Re: State of the GNUnion 2020
I'm not saying that GNU will necessarily stop growing and decline. What I'm afraid is that it might just become insignificant compared to others, and thus its voice for the 4 freedoms become less and less heard. I think everyone would agree that we do not want the four freedoms to become irrelevant, or that the GNU project be forgotten. And I think everyone can also agree that there are groups that are working against it (see e.g. the whole idea of "ethical" licenses). There are probobly many questions to answer, but the way that the group of five are pushing it is activley harmful, and show the same behaviour as those groups trying to push for weakening free software.
Re: State of the GNUnion 2020
Alfred M. Szmidt, le jeu. 20 févr. 2020 12:32:16 -0500, a ecrit: >> > Our concern is that at some point GNU may be just completely unknown >> > to free software enthousiasts. As in, when you'd ask people what free >> > software is about, they would answer "ah, yes, the stuff on github, >> > right". >> >> Okay, sure. But going back to Eli's point, the development activity of >> individual projects is determined by individual project's members, and is >> rarely affected by the actions of the leadership. > >The activity by itself, yes, but the choice of where to start a new >project, or starting contributing an existing project, leadership does >have a lot of importance. > > How does that have to do with the overall project leadership, which > hasn't changed significantly over the years, and yet had significant > growth in new projects for several decades (if we take the graphs by > Wingo at face value). "Significant growth" is very little compared to the huge growth that can be seen on other platforms. I'm not saying that GNU will necessarily stop growing and decline. What I'm afraid is that it might just become insignificant compared to others, and thus its voice for the 4 freedoms become less and less heard. Samuel
Re: State of the GNUnion 2020
Alfred M. Szmidt, le jeu. 20 févr. 2020 12:32:15 -0500, a ecrit: > I would suggest everyone to read the GNU Kind Communication Guidelines > as for how we wish to communicate within the GNU project. Calling > people names, be it calling them toxic or any other name is unkind > even if one might think it is justified.. I am not calling anybody toxic here. I'm sorry and apologize if anybody thought I was, I was just making a thought experiment. (even if it is actually not only thoughts: I have seen that scenario happen in various places, with the exact problem of having to exclude somebody, so as to be able to include some other people) Samuel
Re: State of the GNUnion 2020
> > Our concern is that at some point GNU may be just completely unknown > > to free software enthousiasts. As in, when you'd ask people what free > > software is about, they would answer "ah, yes, the stuff on github, > > right". > > Okay, sure. But going back to Eli's point, the development activity of > individual projects is determined by individual project's members, and is > rarely affected by the actions of the leadership. The activity by itself, yes, but the choice of where to start a new project, or starting contributing an existing project, leadership does have a lot of importance. How does that have to do with the overall project leadership, which hasn't changed significantly over the years, and yet had significant growth in new projects for several decades (if we take the graphs by Wingo at face value). That speaks more to the fact that the GNU project leadership has no impact on project adaptation, or contributor activity. But rather it is a individual effort by each project maintainer.
Re: State of the GNUnion 2020
I would suggest everyone to read the GNU Kind Communication Guidelines as for how we wish to communicate within the GNU project. Calling people names, be it calling them toxic or any other name is unkind even if one might think it is justified.. That seems to be the ground of what some people do not understand here: full inclusiveness can not work, there will always be some people you will be excluding one way or the other, voluntarily or not. Making sure that the choice of who you exclude gets written down seems important to me. I think it is understood quite well, which is different from having a different view on how to achive the end goal of a fun, and kind place to hack in. The GNU project takes a road which is slightly more bumpy, where we try to get everyone to play along together, and not to exclude them for whatever reasons. Since that is a road that is very slippery and only leads to very shaky reasoning, and it can can be seen very well here where one party refuses to even show the other side -- and that is not because of unkind behaviour from that side.
Re: State of the GNUnion 2020
Dmitry Gutov, le jeu. 20 févr. 2020 15:31:17 +0200, a ecrit: > On 20.02.2020 14:41, Samuel Thibault wrote: > > > Okay, sure. But going back to Eli's point, the development activity of > > > individual projects is determined by individual project's members, and is > > > rarely affected by the actions of the leadership. > > > > The activity by itself, yes, but the choice of where to start a new > > project, or starting contributing an existing project, leadership does > > have a lot of importance. > > What kind of choice? Contributors come and go, largely depending on their > own needs and interests. Yes, but also, and I believe most likely, depending on their knowledge of project places (github vs gitlabs vs savannah) and the contact they get with the people there. The GNU project is less and less known compared to other free software platforms, so it'll get less and less newcomers. > > > And it's a more difficult endeavor (think Mozilla-type initiatives) than > > > just releasing a document saying "hi all we don't discriminate and accept > > > everyone", which is basically stating the already obvious. > > > > From seeing the discussions here, it doesn't seem so obvious :/ > > Really? For all the shouting and stomping of feet, I haven't seen here any > one email stating or even implying that the gender or the race of a > contributor is somehow important, or that we'd turn somebody away because of > it. Sure, the contrary was explicitly said indeed. But anything one can bring about not only acknowledging it, but also making efforts on inclusiveness is mostly rejected with arguments like "it's too hard to take care when writing something on a mailing list". > On the flip side, an argument is made that your initiative might make GNU > more exclusionary because of the extra conditions on what it takes to be a > part of it. At some point you have to exclude some people in order to include other people, yes. We can see that in various communities: when somebody is having a toxic behavior and does not changes behavior even after strong warnings, one has to exclude that person, because otherwise that person will make a lot other people fly away. Not taking the steps to exclude the toxic person does mean excluding people that can not stand the toxic behavior, even if that latter exclusion is not explicit. That seems to be the ground of what some people do not understand here: full inclusiveness can not work, there will always be some people you will be excluding one way or the other, voluntarily or not. Making sure that the choice of who you exclude gets written down seems important to me. Samuel
Re: State of the GNUnion 2020
Dmitry Gutov, le jeu. 20 févr. 2020 12:26:38 +0200, a ecrit: > On 20.02.2020 10:55, Samuel Thibault wrote: > > Our concern is that at some point GNU may be just completely unknown > > to free software enthousiasts. As in, when you'd ask people what free > > software is about, they would answer "ah, yes, the stuff on github, > > right". > > Okay, sure. But going back to Eli's point, the development activity of > individual projects is determined by individual project's members, and is > rarely affected by the actions of the leadership. The activity by itself, yes, but the choice of where to start a new project, or starting contributing an existing project, leadership does have a lot of importance. > And it's a more difficult endeavor (think Mozilla-type initiatives) than > just releasing a document saying "hi all we don't discriminate and accept > everyone", which is basically stating the already obvious. >From seeing the discussions here, it doesn't seem so obvious :/ Samuel
Re: State of the GNUnion 2020
Dmitry Gutov, le jeu. 20 févr. 2020 10:43:47 +0200, a ecrit: > On 20.02.2020 6:08, DJ Delorie wrote: > > There are a lot of projects that are free software but not GNU. If > > people choose to work on those projects instead of GNU, GNU loses, even > > if free software wins. > > Well, this is disappointing. > > I figured your "collaborates with the broader free software community" item > was about how non-GNU free software are a "good thing" still (e.g. LLVM has > the right to exist, and we should interface with it properly as well), but > apparently not. I believe you are misinterpreting his words. Our concern is that at some point GNU may be just completely unknown to free software enthousiasts. As in, when you'd ask people what free software is about, they would answer "ah, yes, the stuff on github, right". Sure, seeing free software being developped outside GNU is a great achievement of the GNU project: the goal outpassed the only context of the GNU project. But the GNU project being less and less known is not good news for the GNU project by itself. To avoid that, you can't just say that the existing software can just be maintained and does not need new development. To keep a strain of new incoming contributors, you need new features (thus new releases), new ideas, new projects. Just maintaining old stuff isn't appaling for newcomers. Samuel
Re: State of the GNUnion 2020
On 20.02.2020 15:12, Ludovic Courtès wrote: As I see it, the point of the Social Contract you’re referring to is a commitment to work hand in hand with our natural allies. These could be projects that build software the GNU system or GNU applications rely on, or it could be projects fighting the same fight. To clarify: does LLVM fit either of the descriptions, in your opinion?
Re: State of the GNUnion 2020
On 20.02.2020 14:41, Samuel Thibault wrote: Okay, sure. But going back to Eli's point, the development activity of individual projects is determined by individual project's members, and is rarely affected by the actions of the leadership. The activity by itself, yes, but the choice of where to start a new project, or starting contributing an existing project, leadership does have a lot of importance. What kind of choice? Contributors come and go, largely depending on their own needs and interests. And it's a more difficult endeavor (think Mozilla-type initiatives) than just releasing a document saying "hi all we don't discriminate and accept everyone", which is basically stating the already obvious. From seeing the discussions here, it doesn't seem so obvious :/ Really? For all the shouting and stomping of feet, I haven't seen here any one email stating or even implying that the gender or the race of a contributor is somehow important, or that we'd turn somebody away because of it. On the flip side, an argument is made that your initiative might make GNU more exclusionary because of the extra conditions on what it takes to be a part of it.
Re: State of the GNUnion 2020
Hi, Dmitry Gutov skribis: > I figured your "collaborates with the broader free software community" > item was about how non-GNU free software are a "good thing" still > (e.g. LLVM has the right to exist, and we should interface with it > properly as well), but apparently not. As I see it, the point of the Social Contract you’re referring to is a commitment to work hand in hand with our natural allies. These could be projects that build software the GNU system or GNU applications rely on, or it could be projects fighting the same fight. It’s not about “embracing” any free software project out there. Thanks, Ludo’.
Re: State of the GNUnion 2020
On 20.02.2020 10:55, Samuel Thibault wrote: I believe you are misinterpreting his words. One reason for that is I'm trying to find some technical goals you guys have , thinking back to older discussions. Our concern is that at some point GNU may be just completely unknown to free software enthousiasts. As in, when you'd ask people what free software is about, they would answer "ah, yes, the stuff on github, right". Okay, sure. But going back to Eli's point, the development activity of individual projects is determined by individual project's members, and is rarely affected by the actions of the leadership. Now, if people wanted to promote the GNU project more, make it better-known and approachable, that's a good thing, of course. But promotion is hardly something that can be a part of our "values". And it's a more difficult endeavor (think Mozilla-type initiatives) than just releasing a document saying "hi all we don't discriminate and accept everyone", which is basically stating the already obvious.
Re: State of the GNUnion 2020
On 20.02.2020 6:08, DJ Delorie wrote: There are a lot of projects that are free software but not GNU. If people choose to work on those projects instead of GNU, GNU loses, even if free software wins. Well, this is disappointing. I figured your "collaborates with the broader free software community" item was about how non-GNU free software are a "good thing" still (e.g. LLVM has the right to exist, and we should interface with it properly as well), but apparently not.
Re: State of the GNUnion 2020
On Tue, Feb 18, 2020 at 12:25:33PM -0500, Alfred M. Szmidt wrote: >Thought experiment: what would GNU be if all of its packages >stopped developing? Dead, right? > > Software that can be run, studied, redistributed, and modified is in a > state that is strarkly different than matter that is decaying in an > irreversiable chemical reaction -- i.e. death. > > So lets not call software for dead, or alive. Getting a program > running again is quite possible, but a dead chicken quite the > opposite. If the point of GNU is to create a matrix for evaluation project development and OS developed, honestly, we would be better off developing AI tools to accomplish that. Mayor guilliani used to say, quite correctly, that there is no liberal or conservative way to pick up the garbage. This is largely true -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Re: State of the GNUnion 2020
I'm going to skip over this much of this interesting and valid discussion on metrics and data analysis, which is likely useful if it was in a different context, and get to the more criticle issues > 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. > While analysis of the development of an OS is a valid concern, it is the the criteria or measure of the goals of GNU. It is almost complletely irrevant. There are cornerstone technologies that provide needed leverage to assure the four freedoms, but frankly, ADROID has all but proven that any free system can be latched down. In the end, what really matters is not creating the technology as to having the opppurtunity to creaste free technolgy and convinsing others to use free technolgy as a political, not technological consideration. In that regard, this whole analysis is useless. > > > 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. It is a single part of the GNU mission. Promoting Four Freedoms is what GNU is created for an one method is to promote and develop Free Software, and a foundation of free Software. But time has proven that far more constructive coding has been done by the world at large with GPL licnes as protection and OS in development, than anything GNU can muster by itself, and that it fine. It is not a contest. > 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. It wouldn't even matter. If all the packages stopped developing in a few weeks we would have aa whole new group of people to take over packages, and create new ones. iMeanwhile the GPL protects access to everything that has come before, > 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. > > 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. > The OS develope was always secondary to its licensing regiment. The adoption of GPL licenses is the key measure of a successful GNU, not lines of code. > 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. Eli, they have no idea what a validation process is. I've had this conversation dozens of times with people. they have never run a large production run, and they completely fail to understand what validation or quality assurance is. You are beating a dead horse. These stats are generated for political purposes, not for program anagement. > 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. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Re: State of the GNUnion 2020
Jean Louis writes: > * DJ Delorie [2020-02-19 21:01]: >> >> "Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes: >> > On 2020-02-17 12:37, Andy Wingo wrote: >> >> Thought experiment: what would GNU be if all of its packages stopped >> >> developing? Dead, right? >> > >> > The immediate effect would become more of a stable base for the vast >> > amount of material that depends on it. >> >> For about a month or so, until the next bug, security problem, or >> missing feature were reported... then people would switch to whatever >> software was responsive to these problems. If GNU doesn't respond, >> someone will eventually fork the software (because they can :) and GNU >> would lose users. > > When people continue developing free software it is a win, not loss. The question wasn't "what would free software be?" it was "what would GNU be?" There are a lot of projects that are free software but not GNU. If people choose to work on those projects instead of GNU, GNU loses, even if free software wins.
Re: State of the GNUnion 2020
* DJ Delorie [2020-02-19 21:01]: > > "Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes: > > On 2020-02-17 12:37, Andy Wingo wrote: > >> Thought experiment: what would GNU be if all of its packages stopped > >> developing? Dead, right? > > > > The immediate effect would become more of a stable base for the vast > > amount of material that depends on it. > > For about a month or so, until the next bug, security problem, or > missing feature were reported... then people would switch to whatever > software was responsive to these problems. If GNU doesn't respond, > someone will eventually fork the software (because they can :) and GNU > would lose users. When people continue developing free software it is a win, not loss. Four freedoms are explicitly giving that permission to fork and modify and distribute it. It is win, not a loss. -- Thanks, Jean Louis
Re: State of the GNUnion 2020
"Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes: > On 2020-02-17 12:37, Andy Wingo wrote: >> Thought experiment: what would GNU be if all of its packages stopped >> developing? Dead, right? > > The immediate effect would become more of a stable base for the vast > amount of material that depends on it. For about a month or so, until the next bug, security problem, or missing feature were reported... then people would switch to whatever software was responsive to these problems. If GNU doesn't respond, someone will eventually fork the software (because they can :) and GNU would lose users. Even DJGPP continues to be responsive (albeit very slowly) to these things, to remain relevent to the subset of users who need it.
Re: State of the GNUnion 2020
On 2020-02-17 12:37, Andy Wingo wrote: Thought experiment: what would GNU be if all of its packages stopped developing? Dead, right? The immediate effect would become more of a stable base for the vast amount of material that depends on it. Nothing that depends on GNU Anything would experience a breakage due to a newer version of GNU This or GNU-That. The world would converge on a single version of GNU Autotools, and so then people could just have that one version installed in order to update ./configure script images with minimal diffs, instead of having half a dozen versions installed and using the closest matching one.
Re: State of the GNUnion 2020
Hello,
On Tue, Feb 18, 2020 at 06:30:22PM +0200, Eli Zaretskii wrote:
> > > 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?
> >
> This argument is a simple application of the health criteria you
> consider significant to your own work as a project manager.
bickering about the health of individual GNU packages is probably not very
interesting concerning the health of the GNU project as a whole. But here
you are simply wrong. I have no particular affiliation with GNU Guile,
except that I use it when working on GNU Guix. But I can look up the ftp
directory:
https://ftp.gnu.org/pub/gnu/guile/
Andy's (of course somewhat subjective, but reasonably debatable) criterion
of health of a package was "a release in the last three years". So as you
claim to do to ("this argument is a simple application..."), let us apply
the criterion to GNU Guile.
I see releases in every year since 1997, except for 1998, 2001, 2005, 2015.
So "a simple application of the health criteria you consider significant"
shows that GNU Guile has been a healthy project since its start, and what
you write above is simply not true.
Andreas
Re: State of the GNUnion 2020
Thought experiment: what would GNU be if all of its packages stopped developing? Dead, right? Software that can be run, studied, redistributed, and modified is in a state that is strarkly different than matter that is decaying in an irreversiable chemical reaction -- i.e. death. So lets not call software for dead, or alive. Getting a program running again is quite possible, but a dead chicken quite the opposite.
Re: State of the GNUnion 2020
> From: Andy Wingo > Cc: gnu-misc-discuss@gnu.org > 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.
Re: State of the GNUnion 2020
Hello Eli :) On Wed 12 Feb 2020 19:13, Eli Zaretskii writes: >> From: DJ Delorie >> 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 Glad you agree! > and they should have been investigated, analyzed, and answered 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. > _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 started with an open question about what it would mean for GNU to be a project in good or bad health, settled on using project release data as a base, and in the end thought active projects could be a good measure. There are other ways to interpret the data; again, if the data have problems, corrections are welcome, or fork the repo and do your own analysis... seriously. If we admit the possibility that GNU may be in a bad state, then we should certainly look into it. I have my conclusions which I stand by but which are certainly not set in stone. > 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. I agree entirely, it's a very good question. > 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. > 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. We can never know what might have been, but I believe that without my work on Guile, it would certainly be dead now. If you believe otherwise, it's an interesting discussion, but not germane to the current one. > 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? I understand that some GNU developers feel that things are fine. I heartily encourage you to come up with criteria by which to understand the health of GNU and to make an associated investigation. I have done so for myself and the results are not satisfying. Regards, Andy
