3 ms·

There's absolutely an alternative, and that's what this person has done: stop providing free labor to others. There's no reason to put yourself in, or stay in,

by olliej 2y ago

There's absolutely an alternative, and that's what this person has done: stop providing free labor to others. There's no reason to put yourself in, or stay in, an environment where you are apparently expected to be subject to abuse. Saying the only option is "control yourself", when what that means is "suck it up and don't let abuse get to you" is BS. We keep getting people handwringing over the work load and treatment of maintainers or individual developers, but then comments like this that are just saying "so what? they should just get over it". This is a 100% serious question here - what is a maintainer allowed to do? There are three options: 1. Accept the abuse and continue to try to maintain the project while being subjected to that abuse. 2. Shutdown the project. 3. Hand the project over to someone else. You appear to be advocating for (1) as the only option. Most of the comments in this thread say the (2) is just not reasonable and that the maintainer should accept abuse as a fact of life (e.g. being more explicit that (1) is the only option). The final option is what the maintainer of xz did, and they then got blamed for an exploit that was introduced when they were definitionally no longer involved in the project. Certainly in such a world I would never sign up to be a maintainer of any project, and if anyone asked I would advise them not to as well. The rules seem to be that once you are a project maintainer you are required to accept abuse, and you are never allowed to stop, no matter how much abuse is sent your way. This maintainer did what is in my opinion the only reasonable option: they said "I am unwilling to put up with this BS and so I'm ceasing maintenance of the project". We've already established through xz that you can't hand off a project in response to abuse, as that makes you responsible for it if the replacement installs malware, and demanding people accept permanent abuse is immoral and selfish.

zzo38computer 2y ago
> We've already established through xz that you can't hand off a project in response to abuse, as that makes you responsible for it if the replacement installs malware, and demanding people accept permanent abuse is immoral and selfish. You are right, but that does not necessarily mean that ceasing maintenance of the project is the only reasonable option. Although, it also does not necessarily mean that it is not a reasonable option. You can be too stressed to work on the project properly if you receive such abusive messages, so maybe it is reasonable. However, that does not necessarily mean that it is the only possible option. For example, maybe some people can handle it better than others, or maybe you can just disable the email so that you will not have to receive any more abusive messages like that while working on the project, etc. About malware, that is a reasonable precaution. Of course other people can still maintain their own version of it if they like to do, but then they will have to call it a separate project (even if the file name is the same), so then they don't have the "hand off" problem like you describe as badly as that. And since it is FOSS, you should not need to demand people accept permanent abuse, or to demand them to work on the project for any other reason. Proprietary software is more of a problem with this since then a vendor-lock is possible and if they refuse to work on it then it can affect everyone and it is much more difficult to recover from than FOSS.
Exuma 2y ago
There is writing between the lines you are missing. The very phrase "accept abuse" already puts one in the position of victim. I suspect you won't "see" this though because I'm going to guess you'll look at it as some kind of behavioral impasse which you are either "subjected" to or free from. That's not what I'm saying This has nothing to do with OSS maintenance, it has nothing to do with projects, it has nothing to do with development even. It is a life lesson, one which entirely directs your life as a victim, or as a sort of life-long learner (because it never ends!) of how to control your own reaction... and as one gets better at this (hard) feat, the bigger situations one can be in before "tapping out" so to speak. IMO, the goal of life should be to be on that second path, and look at all situations like this email more as "challenges" to practice this life-long lesson. It's entirely freeing as it's now simply a sort of zen meditation with the self... you are no longer chained to constantly reacting to what is around you. It is a profound shift in thinking. So objectively speaking, if I were him in his shoes (and I have been there)... I would read the email, feel a "ugh" wash over me, then realize... this literally has nothing to do with me, and then I would go on living my life
jsthrowaway 2y ago
Are you familiar with the Open Source Guides Best Practices for Maintainers [1] and Maintaining Balance for Open Source Maintainers [2]? Perhaps these helpful pages and the resources linked within may give you some guidance on how experienced maintainers can handle such matters without a hostility-first mindset. [1] https://opensource.guide/best-practices/ https://opensource.guide/best-practices/ [2] https://opensource.guide/maintaining-balance-for-open-source-maintainers/ https://opensource.guide/maintaining-balance-for-open-source...
- zzo38computer 2y ago
  They are good ideas. For my own projects, I do try to avoid scope creep. (In some cases I had thought something should be in scope but later changed my mind (before actually implementing it), though.) I did not add a file called VISION but maybe that would help, so I will consider that. I do want to keep communication public (mainly using NNTP, although IRC and GitHub issue trackers can also be used), but nevertheless there isn't any communication on there. > If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. Forking a project doesn’t have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project’s vision. This is correct. However, it is also possible for some of the features of a forked version to later be put into the official version (or a different fork) (after being reviewed by the maintainer). This does happen sometimes, too. > Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. Nevertheless, it make sense; there is more to say if they have a complaint (or a suggestion for improvement, or a question, etc) than if it works OK. I don't mind this; my problem is that I rarely receive any feedback at all, regardless of good or bad. (However, I think that it is helpful even for positive feedback to be specific. This way, it can also help other people to decide whether or not they think this program is suitable (or almost suitable) for their intended uses.) (I have received stars on GitHub (for some projects), but they don't help me at all, since they do not say anything.) > Working alone: Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. This is my problem; lack of other people discussion and contributions.

by olliej 2y ago

zzo38computer 2y ago

> We've already established through xz that you can't hand off a project in response to abuse, as that makes you responsible for it if the replacement installs malware, and demanding people accept permanent abuse is immoral and selfish. You are right, but that does not necessarily mean that ceasing maintenance of the project is the only reasonable option. Although, it also does not necessarily mean that it is not a reasonable option. You can be too stressed to work on the project properly if you receive such abusive messages, so maybe it is reasonable. However, that does not necessarily mean that it is the only possible option. For example, maybe some people can handle it better than others, or maybe you can just disable the email so that you will not have to receive any more abusive messages like that while working on the project, etc. About malware, that is a reasonable precaution. Of course other people can still maintain their own version of it if they like to do, but then they will have to call it a separate project (even if the file name is the same), so then they don't have the "hand off" problem like you describe as badly as that. And since it is FOSS, you should not need to demand people accept permanent abuse, or to demand them to work on the project for any other reason. Proprietary software is more of a problem with this since then a vendor-lock is possible and if they refuse to work on it then it can affect everyone and it is much more difficult to recover from than FOSS.

Exuma 2y ago

There is writing between the lines you are missing. The very phrase "accept abuse" already puts one in the position of victim. I suspect you won't "see" this though because I'm going to guess you'll look at it as some kind of behavioral impasse which you are either "subjected" to or free from. That's not what I'm saying This has nothing to do with OSS maintenance, it has nothing to do with projects, it has nothing to do with development even. It is a life lesson, one which entirely directs your life as a victim, or as a sort of life-long learner (because it never ends!) of how to control your own reaction... and as one gets better at this (hard) feat, the bigger situations one can be in before "tapping out" so to speak. IMO, the goal of life should be to be on that second path, and look at all situations like this email more as "challenges" to practice this life-long lesson. It's entirely freeing as it's now simply a sort of zen meditation with the self... you are no longer chained to constantly reacting to what is around you. It is a profound shift in thinking. So objectively speaking, if I were him in his shoes (and I have been there)... I would read the email, feel a "ugh" wash over me, then realize... this literally has nothing to do with me, and then I would go on living my life

jsthrowaway 2y ago

Are you familiar with the Open Source Guides Best Practices for Maintainers [1] and Maintaining Balance for Open Source Maintainers [2]? Perhaps these helpful pages and the resources linked within may give you some guidance on how experienced maintainers can handle such matters without a hostility-first mindset. [1] https://opensource.guide/best-practices/ https://opensource.guide/best-practices/ [2] https://opensource.guide/maintaining-balance-for-open-source-maintainers/ https://opensource.guide/maintaining-balance-for-open-source...

zzo38computer 2y ago
They are good ideas. For my own projects, I do try to avoid scope creep. (In some cases I had thought something should be in scope but later changed my mind (before actually implementing it), though.) I did not add a file called VISION but maybe that would help, so I will consider that. I do want to keep communication public (mainly using NNTP, although IRC and GitHub issue trackers can also be used), but nevertheless there isn't any communication on there. > If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. Forking a project doesn’t have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project’s vision. This is correct. However, it is also possible for some of the features of a forked version to later be put into the official version (or a different fork) (after being reviewed by the maintainer). This does happen sometimes, too. > Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. Nevertheless, it make sense; there is more to say if they have a complaint (or a suggestion for improvement, or a question, etc) than if it works OK. I don't mind this; my problem is that I rarely receive any feedback at all, regardless of good or bad. (However, I think that it is helpful even for positive feedback to be specific. This way, it can also help other people to decide whether or not they think this program is suitable (or almost suitable) for their intended uses.) (I have received stars on GitHub (for some projects), but they don't help me at all, since they do not say anything.) > Working alone: Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. This is my problem; lack of other people discussion and contributions.