So your advice is “accept all abuse while providing a free service to others”?
Sounds like you’re on team “maintainers should be required to support me for free despite me being an asshole”
Sounds like you’re on team “maintainers should be required to support me for free despite me being an asshole”
There's a big difference between demanding support while being an asshole and advising that obviously troll emails can be tossed in the trash without ruining your day.
James is totally free to do whatever he wants, of course.
That person is still demanding support - they're clearly using this library [minor edit due to garbage grammar] - they're just hiding who they are because they know their behavior is BS. Receiving mail like this has a mental and emotional toll even if it can be "tossed in the trash" you still have to at least start reading it to determine that it's a troll.
So this maintainer now has to read these messages, even if it's just to send them to the trash, and knows that the person sending this is a person that is using the library, and so any more work they do is helping this person.
Exuma is saying "you can only control your own reaction", which is pretty dismissive and contextually implies that shutting down the project is not a reasonable reaction. i.e. if you maintain a project, it's over reacting if you choose to stop maintaining that project just because you're being subjected to abuse.
I'm not sure how else to interpret Exuma's comment.
Something mentioned in the email message is private members of an interface. If they do abandon the project, then I suppose that whoever wrote that can make them public safely since there is not a new version, it is unlikely to break compatibility with newer versions if there aren't any. So, maybe abandoning this project, does possibly help them.
(This is not any kind of excuse for writing such a bad message nor a reason for continuing to maintain the project; it is just an observation.)
So, abandoning or not abandoning it isn't considering if it helps them or not. Rather, what is important to consider is how much it harms everyone else; how much it helps the person sending that message isn't important.
In the end, you have 2 choices:
1. try to control other people
2. control yourself
There is literally no other options. Theres no "middle ground." Any advice/comments/etc boil down to ONE of these two choices.
The entire first choice is moot, because given 10 million years, you will never be able to control other people's behavior. No amount of good advice, helpful HN comments, 1000 word blog posts, will never, ever, 100% remove all threads of possibility of getting teased/whatever. I would not categorize this choice as "wrong" (which implies bad), but merely "moot" (neutral).
Therefore, that only leaves option 2. Discussing anything to do with what people "should" do is, quite literally, a waste of time. This idea CAN coexist simultaneously with the idea that I treat people well. Why? Because being nice is option #2... its something I control about myself. I CAN control how I treat other people, just as I can control my reaction to other people.
I don't condone/not condone the person email, because I don't even look at things like that. I look at things in terms of what I'm capable of controlling (or, that is the goal, anyway. sometimes life can be tricky!).
If i were to look at things in terms of what other people "should" be doing, then I am destined for a lifetime of disappointment and emotional turmoil.
There is no other way.
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.
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
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/
[2] https://opensource.guide/maintaining-balance-for-open-source...
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.
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.