8 ms·

"Is This Project Still Maintained?"

79 points by bo0tzz 2y ago

palata 2y ago
I do agree with what I take as the general message: most people don't really understand how open source works and have unreasonable expectations. Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task. Developers should understand what it actually means to depend on a project. If one needs a fix or a change down the line, it could be that nobody will be there to do it for free, or at all. Therefore one should be ready to either pay or take over the maintenance. And this should be carefully put in balance every time: "Should I add this dependency, or should I write it myself?". Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies (and then be pissed at the maintainers who don't want to maintain for free or at all).
- bayindirh 2y ago
  > Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies... Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way. Then people whine about dependency hell.
  - throwaway11460 2y ago
    > Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process? Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.
    - bayindirh 2y ago
      The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice. The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull. Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins. Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
      - throwaway11460 2y ago
        That's why we use Semver, at least in the Node land. A security fix should be a patch, at most minor version bump - API/behavior shouldn't change.
        bayindirh 2y ago
        This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that. You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
    - barkbyte 2y ago
      Dependencies can also do that in node with post install hooks (or in rust with build.rs even if you don’t call into them, I think)
    - edflsafoiewq 2y ago
      The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.
      - 2y ago
  - sureIy 2y ago
    > Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code. If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
    - bayindirh 2y ago
      I use big and well matured libraries for the critical parts of my code. These can be logging, option/file parsing, or linear algebra. When I add these libraries, I use most parts of them at the end of the day. However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries. I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things. When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier. It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
    - Chris2048 2y ago
      > There’s no middle ground unless using a language that supports tree-shaking. Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).
- ozim 2y ago
  *Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task.* I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific. If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something. But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
  - sureIy 2y ago
    This is such a bad take, I’m glad you already got like 8 replies. My code is open source, at a minimum it’s there for your own perusal to be copy-pasted. I don’t owe you anything.
  - bayindirh 2y ago
    Free Software ecosystem is not black and white (i.e. Build a community or don't share). I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place. If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something. If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better? If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open. But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate. Plus, who decides which codebase I open to the world, and in what way?
- Gigachad 2y ago
  I’m not sure cargo is really the fault rather than developers who import a library just to use a trivial utility function in one place. Modern package managers solve 1000x problems and make one pitfall slightly easier. But it’s still a very easily avoided problem.
  - deleted 2y ago
    [deleted]
seumars 2y ago
My pet peeve with this question is that sometimes it’s completely fair to call a piece of software "finished".
pavlov 2y ago
> 'A PR is what is often called a “gift of work”' It's like showing up unannounced at someone's place with a grocery bag of ingredients and asking them to cook for you. "But I brought steak and brussel sprouts! Surely you like these things too. Why don't you just prepare the meal now?" It might be a great meal and a generous offering, but clearly it's not exactly in the spirit of a gift to do this.
- chimprich 2y ago
  If you want to go with that analogy, it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!) I have a fairly popular free/open source project and I both agree and disagree with the author. Mostly users are polite and non-entitled, but it's exhausting answering all the (very polite) questions and requests for help. I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.
  - shoo 2y ago
    > it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!) that may be a better analogy for you, but i reckon the best-fit analogy is up to each individual, depending on where they want to set their boundaries. some may prefer the analogy of being an author of a book: the author researches and writes a 10 chapter book, then copy-edits and publish the finished work, perhaps releasing it into the public domain. not obvious that the author would be willing to copy-edit and release a 2nd edition of the book incorporating an 11th chapter written by someone else.
  - gampleman 2y ago
    > I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ. As someone who has submitted PRs without much communication to repos asking to talk before PR are submitted: in my case these were generally cases where it just seemed easier for me as a user to just change the code rather than to contact the author, try to make some sort of social interaction online, explain why and what I'm trying to do, potentially enter some sort of negotiation trying to hammer out some agreement and then doing the code change PR dance anyway. Much easier to just make some straightforward code changes - done and dusted in a few hours. And sure, I completely understand if a maintainer then says "no thank you". That's the risk I took by my just do it attitude. No hard feelings on my side.
benfortuna 2y ago
I feel he may be overthinking it.. people just want to understand the best options available for their use-case. If you see a project with no new commits for 3 years (1), you would rather not invest time trying to get it working if there is a newer/maintained project. 1 And whilst you may argue the software is "finished", reality is very little software survives without maintenance. Unless you have zero dependencies and future exploits in no way apply.
- swiftcoder 2y ago
  > Unless you have zero dependencies and future exploits in no way apply. This was the default for most software up until maybe a decade ago, when everything-in-the-cloud software-as-a-service ate the world
- flohofwoe 2y ago
  pystring [1] is such a "finished" project, they even have a note in the readme that the project is not dead (I guess they got a lot of such questions too). It's a small yet complete library with a very narrow focus, so there really is nothing to change once it's done (and despite that recently merged CI pipeline having failed on macOS for some reason, it works just fine there, I make heavy use of pystring in one my projects across Windows, macOS and Linux). Quote: "Note: Despite the infrequent updates, this repo is not dead/abandoned - just stable! We use it every day at Imageworks." [1] https://github.com/imageworks/pystring https://github.com/imageworks/pystring
  - Timshel 2y ago
    I like that the example you gave has a merge less than a year ago :) and more than 10 in 2022.
    - flohofwoe 2y ago
      ...OTH just 54 commits over 16 years ;) Most of the more recent commits seem to be project scaffolding (build system, CI support etc).
- 2y ago
JodieBenitez 2y ago
It's also perfectly fine to release source code out of the github/gitlab decorum: Just the source with the license and maybe an email. No git repo history, no comments, no PRs, no bug reports. That would probably filter a large number of self-entitled consumers.
- spiderbugicon 2y ago
  This is something I don't understand about the author's stance. Why are they seemingly insulted by the prompt? The insult doesn't come from the asker's lack of helpfulness or unwillingness to fork or merge request, that's all irrelevant in their eyes. Just from the questions in of themselves, be them loaded or not. But there IS an implicit contract at the moment of creation of a repository which states "you may contact me here" and... that's what those people did? The only way to address a maintainer with the question beyond email, which isn't generally available anymore in the current environment, is the repo issues. Issues and merge requests are opt-out features, not opt-in, so, unmaintained repositories will in fact appear completely indistinguishable from maintained one. But repo creation is opt-in. Repo public status is opt-in. You can retract both of those contracts. If the question annoys someone so deeply - you can stop reading other repo's public issues, and you got a toggle to mute your own. I also am annoyed with people and things. I wish mosquitos disappeared, but I'm not going to make a ideological statement on it with so many more actionable approaches avaiable. Heck, even if the whole purpose of the article is to vent, you still got a way to direct that emotion "productively" - just give a cute little angry emoji to the issue's author.
Timshel 2y ago
I think it's interesting to reflect on what we mean with maintain vs support. And while I agree with the author that people often expect too much of what maintaining mean at the same time I don't understand why the author want to be able to say that he maintains the library while ignoring potential bug ... If you are ignoring bug reports just say it's not maintained and if your forge allows it just disable issues, and it will be clear to users what they should expect.
- em-bee 2y ago
  your bug is my feature. some bugs are critical, and some are a mere inconvenience. for example, my app not looking right on your device could be considered a bug. but it works fine on mine because i have a different resolution. so it's not a bug for me, but rather the application was not designed to work on your device. the same goes for any bugs that result from interactions with a different environment. an environment i don't have, and possibly can't even test against. i'll fix those bugs if i have time and motivation (strongly influenced by the tone of the submitter, but also by the fact that i have a family and need to make a living) and if i can verify that the fix doesn't impact my own use.
kreyenborgi 2y ago
After https://research.swtch.com/xz-timeline https://research.swtch.com/xz-timeline (see Prologue), open source maintainers should feel no qualms with marking such comments as spam/abuse.
latexr 2y ago
> Gee, You Sound Like an Asshole If you feel the need to write an entry for this at the end, I recommend you go back and improve the rest of the document so this section isn’t necessary. Even when someone has been actively rude to you (which isn’t the case here, as the document is unprompted), being rude back only makes it worse. But being kind sometimes makes the other person change their attitude, or at the very least doesn’t make future contributors think of you as an asshole too. And there’s the bonus that sometimes you misinterpret someone as rude when they were not, so being disrespectful makes you the sole offender in a public interaction. Remember you can always not reply to someone, or politely say you don’t accept abuse—especially not when providing something to others at the expense of your free time and at no cost for them—and lock the conversation and/or block the user. You think when you’re rude back you’re shoving the other person away so they leave you alone. You’re not. You’re giving them ammunition to come back harder and for others to pile on. Be kind and deprive them of their weapons instead. Ask them to leave if they’re repeat offenders. Force them to leave if you have to, but don’t make a show of it. Remember you’re the maintainer. It’s your house that you opened for others to visit. Don’t give them reason to trash it.

79 points by bo0tzz 2y ago

I do agree with what I take as the general message: most people don't really understand how open source works and have unreasonable expectations. Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task. Developers should understand what it actually means to depend on a project. If one needs a fix or a change down the line, it could be that nobody will be there to do it for free, or at all. Therefore one should be ready to either pay or take over the maintenance. And this should be carefully put in balance every time: "Should I add this dependency, or should I write it myself?". Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies (and then be pissed at the maintainers who don't want to maintain for free or at all).

bayindirh 2y ago
> Modern language package managers like cargo amplify this problem by making it almost too easy to add tons of dependencies... Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. One of the worse offenders I have seen was adding whole Pandas and the kitchen sink for a simple table lookup. I have seen other programs which adds almost hundred libraries for something which can be implemented in a relatively simple way. Then people whine about dependency hell.
- throwaway11460 2y ago
  > Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process? Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.
  - bayindirh 2y ago
    The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice. The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull. Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins. Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
    - throwaway11460 2y ago
      That's why we use Semver, at least in the Node land. A security fix should be a patch, at most minor version bump - API/behavior shouldn't change.
      - bayindirh 2y ago
        This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that. You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
  - barkbyte 2y ago
    Dependencies can also do that in node with post install hooks (or in rust with build.rs even if you don’t call into them, I think)
  - edflsafoiewq 2y ago
    The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.
    - 2y ago
- sureIy 2y ago
  > Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well then which one is it? There’s no middle ground, unless at some point you decide it’s now worth using a big library and start replacing your own code. If you decide to write everything from scratch, good luck to your users, they’re not getting a better product.
  - bayindirh 2y ago
    I use big and well matured libraries for the critical parts of my code. These can be logging, option/file parsing, or linear algebra. When I add these libraries, I use most parts of them at the end of the day. However for other one-off things like internal state handling or stuff which I can prop up using the standard library, I refuse to use external libraries. I kindly disagree on the part of they're not getting a better product. On the contrary. They require to manage less dependencies, most critical parts are well cooked/tested, and other parts are built using the standard library which is built to build these things. When rolling things forward, I need to juggle less dependencies, too. So things can move forward easier. It's not like I'm banging the keyboard and shouting done when it prints something meaningful to screen.
  - Chris2048 2y ago
    > There’s no middle ground unless using a language that supports tree-shaking. Also, you could also use the same interface (fn-signature etc), or even add a flag for if the lib is installed (in python, try-except over import, with "dummy" module as fallback).
ozim 2y ago
*Maintainers don't owe users anything unless the user actually pays for it and the maintainer accepts the money for the task.* I have a nitpick on that take. If maintainer was actively building community and advocating use of his project (for whatever reasons but usually to gain audience - money is not the only value exchange that there is) they still do owe users bug fixes or reviewing bug fixes made by community. Especially if there were other community contributions, cash on hand is too specific. If someone doesn't want to owe users anything, don't make project open source or make it clear "don't use this or fork for yourself, please" in read-me or something. But also one should not pull dependencies willy-nilly especially if one is building business on top of that.
- sureIy 2y ago
  This is such a bad take, I’m glad you already got like 8 replies. My code is open source, at a minimum it’s there for your own perusal to be copy-pasted. I don’t owe you anything.
- bayindirh 2y ago
  Free Software ecosystem is not black and white (i.e. Build a community or don't share). I put my software in the open with a license which I think is fair, because I hope someone might find it useful, with a completely neutral stance. On the other hand, I set my expectations with the license I assign to my codebase. If nobody cares about what I do, I'm also fine with it. At the end of the day, I wrote that thing for myself in the first place. If somebody decides to contribute something back, my primary responsibility is to act as decently as other party allows me. They can report a bug, send in a fix, or ask something. If the proposed change is favorable to both of us (i.e. it also fits into the design/role I have in my mind for that codebase, or doesn't disturb it), why not work together and make something better? If the change makes the software unfit for me, but fit for the other party, they're free to fork and maintain their fork as they fit, as long as they honor the license. This is why is this thing is in the open. But, if the requester wants me to implement their changes to make the software fit for themselves, while making it unfit for me, and want to pass the burden of maintenance on me, then sorry, we can't cooperate. Plus, who decides which codebase I open to the world, and in what way?
Gigachad 2y ago
I’m not sure cargo is really the fault rather than developers who import a library just to use a trivial utility function in one place. Modern package managers solve 1000x problems and make one pitfall slightly easier. But it’s still a very easily avoided problem.
- deleted 2y ago
  [deleted]

seumars 2y ago

My pet peeve with this question is that sometimes it’s completely fair to call a piece of software "finished".

pavlov 2y ago

> 'A PR is what is often called a “gift of work”' It's like showing up unannounced at someone's place with a grocery bag of ingredients and asking them to cook for you. "But I brought steak and brussel sprouts! Surely you like these things too. Why don't you just prepare the meal now?" It might be a great meal and a generous offering, but clearly it's not exactly in the spirit of a gift to do this.

chimprich 2y ago
If you want to go with that analogy, it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!) I have a fairly popular free/open source project and I both agree and disagree with the author. Mostly users are polite and non-entitled, but it's exhausting answering all the (very polite) questions and requests for help. I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ.
- shoo 2y ago
  > it's more like opening a community cafe and hanging a sign on the wall saying "please bring a dish for our free communal meal - we'd be happy to add it (when we get around to it, if we like it, and if the cafe is still open - good luck, because you probably won't know if it has closed!) that may be a better analogy for you, but i reckon the best-fit analogy is up to each individual, depending on where they want to set their boundaries. some may prefer the analogy of being an author of a book: the author researches and writes a 10 chapter book, then copy-edits and publish the finished work, perhaps releasing it into the public domain. not obvious that the author would be willing to copy-edit and release a 2nd edition of the book incorporating an 11th chapter written by someone else.
- gampleman 2y ago
  > I've had to turn down dishes that wouldn't have worked for the cafe, and it makes me feel bad. I've requested users contact me before writing a PR but of course people don't read the FAQ. As someone who has submitted PRs without much communication to repos asking to talk before PR are submitted: in my case these were generally cases where it just seemed easier for me as a user to just change the code rather than to contact the author, try to make some sort of social interaction online, explain why and what I'm trying to do, potentially enter some sort of negotiation trying to hammer out some agreement and then doing the code change PR dance anyway. Much easier to just make some straightforward code changes - done and dusted in a few hours. And sure, I completely understand if a maintainer then says "no thank you". That's the risk I took by my just do it attitude. No hard feelings on my side.

benfortuna 2y ago

I feel he may be overthinking it.. people just want to understand the best options available for their use-case. If you see a project with no new commits for 3 years (1), you would rather not invest time trying to get it working if there is a newer/maintained project. 1 And whilst you may argue the software is "finished", reality is very little software survives without maintenance. Unless you have zero dependencies and future exploits in no way apply.

swiftcoder 2y ago
> Unless you have zero dependencies and future exploits in no way apply. This was the default for most software up until maybe a decade ago, when everything-in-the-cloud software-as-a-service ate the world
flohofwoe 2y ago
pystring [1] is such a "finished" project, they even have a note in the readme that the project is not dead (I guess they got a lot of such questions too). It's a small yet complete library with a very narrow focus, so there really is nothing to change once it's done (and despite that recently merged CI pipeline having failed on macOS for some reason, it works just fine there, I make heavy use of pystring in one my projects across Windows, macOS and Linux). Quote: "Note: Despite the infrequent updates, this repo is not dead/abandoned - just stable! We use it every day at Imageworks." [1] https://github.com/imageworks/pystring https://github.com/imageworks/pystring
- Timshel 2y ago
  I like that the example you gave has a merge less than a year ago :) and more than 10 in 2022.
  - flohofwoe 2y ago
    ...OTH just 54 commits over 16 years ;) Most of the more recent commits seem to be project scaffolding (build system, CI support etc).
2y ago

JodieBenitez 2y ago

It's also perfectly fine to release source code out of the github/gitlab decorum: Just the source with the license and maybe an email. No git repo history, no comments, no PRs, no bug reports. That would probably filter a large number of self-entitled consumers.

spiderbugicon 2y ago
This is something I don't understand about the author's stance. Why are they seemingly insulted by the prompt? The insult doesn't come from the asker's lack of helpfulness or unwillingness to fork or merge request, that's all irrelevant in their eyes. Just from the questions in of themselves, be them loaded or not. But there IS an implicit contract at the moment of creation of a repository which states "you may contact me here" and... that's what those people did? The only way to address a maintainer with the question beyond email, which isn't generally available anymore in the current environment, is the repo issues. Issues and merge requests are opt-out features, not opt-in, so, unmaintained repositories will in fact appear completely indistinguishable from maintained one. But repo creation is opt-in. Repo public status is opt-in. You can retract both of those contracts. If the question annoys someone so deeply - you can stop reading other repo's public issues, and you got a toggle to mute your own. I also am annoyed with people and things. I wish mosquitos disappeared, but I'm not going to make a ideological statement on it with so many more actionable approaches avaiable. Heck, even if the whole purpose of the article is to vent, you still got a way to direct that emotion "productively" - just give a cute little angry emoji to the issue's author.

Timshel 2y ago

I think it's interesting to reflect on what we mean with maintain vs support. And while I agree with the author that people often expect too much of what maintaining mean at the same time I don't understand why the author want to be able to say that he maintains the library while ignoring potential bug ... If you are ignoring bug reports just say it's not maintained and if your forge allows it just disable issues, and it will be clear to users what they should expect.

em-bee 2y ago
your bug is my feature. some bugs are critical, and some are a mere inconvenience. for example, my app not looking right on your device could be considered a bug. but it works fine on mine because i have a different resolution. so it's not a bug for me, but rather the application was not designed to work on your device. the same goes for any bugs that result from interactions with a different environment. an environment i don't have, and possibly can't even test against. i'll fix those bugs if i have time and motivation (strongly influenced by the tone of the submitter, but also by the fact that i have a family and need to make a living) and if i can verify that the fix doesn't impact my own use.

kreyenborgi 2y ago

After https://research.swtch.com/xz-timeline https://research.swtch.com/xz-timeline (see Prologue), open source maintainers should feel no qualms with marking such comments as spam/abuse.

latexr 2y ago

> Gee, You Sound Like an Asshole If you feel the need to write an entry for this at the end, I recommend you go back and improve the rest of the document so this section isn’t necessary. Even when someone has been actively rude to you (which isn’t the case here, as the document is unprompted), being rude back only makes it worse. But being kind sometimes makes the other person change their attitude, or at the very least doesn’t make future contributors think of you as an asshole too. And there’s the bonus that sometimes you misinterpret someone as rude when they were not, so being disrespectful makes you the sole offender in a public interaction. Remember you can always not reply to someone, or politely say you don’t accept abuse—especially not when providing something to others at the expense of your free time and at no cost for them—and lock the conversation and/or block the user. You think when you’re rude back you’re shoving the other person away so they leave you alone. You’re not. You’re giving them ammunition to come back harder and for others to pile on. Be kind and deprive them of their weapons instead. Ask them to leave if they’re repeat offenders. Force them to leave if you have to, but don’t make a show of it. Remember you’re the maintainer. It’s your house that you opened for others to visit. Don’t give them reason to trash it.