I will never understand people like GitHub user “shushtain” in the linked issue.<p>So obviously the guy is behaving like an entitled jerk, but it’s also surely counter-productive (volunteer maintainers are unlikely to respond well to plain rudeness)? Unless the goal isn’t a productive outcome, but just to be mean?
I've built many successful services by listening to entitled users so much that I used to talk with such entitled users all day.<p>They are just passionate and most of the times annoyed because something as simple is not being done right.
If those "many successful services" are FOSS, you are a very rare breed of developers - one I have not yet encountered in almost 30 years of FOSS development.<p>Could you please link some of your projects? I could use some inspiration how to deal with entitled FOSS users who do not understand that they already got much more than what they paid for.
I don't think you've done any of that - at least not for a successful open source project. The topic here is about open source volunteers and not your day job.
I built businesses not opensource projects.<p>Though many of my projects are completely free for the users.<p>Latest being this one already past 1000+ active users
<a href="https://play.google.com/store/apps/details?id=com.macrocodex.app&pcampaignid=web_share">https://play.google.com/store/apps/details?id=com.macrocodex...</a><p>If you don't listen to your passionate users, i doubt you'll ever grow.<p>Someone being rude/entitled doesn't matter to me, I only care about if what they are saying actually makes any sense
Don't take it personally but the people here are talking about open source projects and unpaid work in their free spare time. There is zero value you could share in this thread from your experiences on developing closed source business products because it completely misses the topic of volunteer work.
Ehm... no? It's not zero value?<p>He's making a general point about "regardless of how something is presented to you, at the end of the day you have to look at the actual information, and if there is some truth in it, then it would be illogical to dismiss it".
<i>at the end of the day you have to look at the actual information, and if there is some truth in it, then it would be illogical to dismiss it</i><p>sure, but the amount of nonsense (to avoid the b-word) i am willing to put up with depends on the amount of money i expect to make from the project. for unpaid work that amount is zero. if i am investing my free time and i allow you to benefit from it, you better be nice when you talk to me.<p>when i run a business then the information gained potentially makes my product sell better. for a volunteer project i may not care about popularity, so the information gained is not necessarily of any benefit.
Oh, how couldn't i see this. The author also did this and he concluded "OK." right before clicking on the "Archive Project" Button.
I will listen to a rude paying customer if I must, because my income will be tied to it. If a similar paying customer comes and they are better behaved, the rude customer will take second position.<p>On an open source project that I’m doing for my own enjoyment rude people are not welcome. I’m doing that for my own enjoyment - to decompress after dealing with rude people. Close issue, won’t fix, ban free user.
> They are just passionate and most of the times annoyed because something as simple is not being done right.<p>No, this is not adequate justification for such behavior towards volunteer FOSS maintainers.
> They are just passionate and most of the times annoyed because something as simple is not being done right.<p>I don't think this is the case at all. You are commenting in a discussion on how a maintainer of an unstable project which very clearly and unambiguously only targets and supports a specific version of a runtime. Still, said maintainer is being pestered by entitled users who attack the maintainer and how they chose to invest their free time contributing to the project with accusations of being "insane".<p>This is not "passion". This is sheer entitlement, and abuse on top.<p>If this was passion, you'd see users contributing their work with proposals to post releases. Even very low effort things like forking the repo and posting their custom releases would be infinitely more productive. You know, the core of FLOSS.<p>But no. You have someone doing their best generously contributing their time to provide something to the public, and in return they get insults and abuse.<p>No wonder projects get archived.
What successful services have you built because of entitled users?
Easiest people to understand: someone hurt you (in this case disrupted your workflow, especially if pointlessly like this user thinks), you express the dissatisfaction to the person who did.
> Easiest people to understand: someone hurt you (in this case disrupted your workflow, especially if pointlessly like this user thinks), you express the dissatisfaction to the person who did.<p>Are you aware you are talking about a FLOSS project that was gifted to you, and you are advocating for attacking for abusing the creator of said project because you can't even bother to contribute anything back?
Humans are notoriously bad at game theory.
You see, humans are emotional beings, not rational beings. Surely you've seen examples of that basically everywhere there is human interactions.
> Unless the goal isn’t a productive outcome, but just to be mean?<p>Some people are just mean. They spend their angry little lives walking around "outraged" by any minor inconvenience. They assume every single little happenstance was designed to make them miserable.<p>The greatest thing about having a good education and working with other experts is that I generally don't meet this people that much, but I remember them all too well.
Being rude is not effortless, it requires someone spending significant amount of energy on you<p>And most people who wronged me were never really rude to me. So i don't even use someone's rudeness as filter for anything.
Agreed. However, I often wonder if people like that are deliberately (or inadvertently) being a psyop seeking to burn out people ala how "Jia Tan" tried to become maintainer of xz [0].<p>[0] <a href="https://youtu.be/aoag03mSuXQ?t=597" rel="nofollow">https://youtu.be/aoag03mSuXQ?t=597</a>
He's just incompetent:<p>1. He blames the maintainer that his distro doesn't ship latest neovim.<p>2. He didn't pull neovim from the Extra-Testing Arch branch.<p>3. He didn't pull neovim from AUR.<p>4. He doesn't have the knowledge to build from source.<p>5. He didn't pull the tarball from git.<p>6. He didn't pull the AppImage from git.<p>There's so many solutions to choose from and he chose none; pure ragebait.
[dead]
not really an excuse, but guy's from Kharkiv, Ukraine - a city that is almost daily getting bombed by russia, maybe he just had a bad day?
This is a bane of all such aggregator libraries, that suck maintetance from other projects into themself. Null-ls suffered from this, too: <a href="https://github.com/jose-elias-alvarez/null-ls.nvim/issues/1621" rel="nofollow">https://github.com/jose-elias-alvarez/null-ls.nvim/issues/16...</a><p>The source of a library needs an update every time there is a configuration change in _any_ tree-sitter parser supported.<p>The only sustainable option is not use these helpers and manage editor dependencies manually: tree-sitter parsers, LSP servers (looking at you Mason), and plugins (looking at you neovim distros).
Managing the parsers yourself is fairly easy and could rely on running the tree-sitter CLI in each parser repo to build them. Other options exists like installing via Nix.<p>And in a similar vein, if queries (.scm files) were hosted in each parser repo, it would also be fairly easy to handle.<p>I think it’s the latter part with the query files that is the challenge here.
Queries are a part of tree-sitter, but unfortunately neovim extended those with more predicates and operators, making most nvim-sitter incompatible with tree-sitter API.<p>For my text editor I had to yank nvim-treesitter queries and rewrite them.<p><a href="https://github.com/ivanjermakov/hat-tree-sitter" rel="nofollow">https://github.com/ivanjermakov/hat-tree-sitter</a>
Good for the maintainer, hope they find peace and do things just for their fun, without needing to deal with comments like that anymore
This was probably near the breaking point before, it just needed an idiot to catalyze.
I had a similar emotional outburst where after contributing hundreds of hours to Stack Overflow, when I asked a question of my own, instead of answering an objective yes/no question people just argued with me in the comments about why I could possibly want to do whatever prompted me to ask my question. I delete my account and quit ever contributing to that site right then and there. I think I was just looking for an out and it was ultimately a good thing.<p>No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at <a href="https://github.com/nvim-treesitter/nvim-treesitter/graphs/contributors" rel="nofollow">https://github.com/nvim-treesitter/nvim-treesitter/graphs/co...</a> , it doesn't look like he started this project, so I'm not sure it's his place to archive it.
> doesn't look like he started this project, so I'm not sure it's his place to archive it.<p>This is a very valid point. It indeed looks like it was done in affect rather than after careful discussion with the (at least) ten members of the nvim-treesitter org.
If you had the option to also delete all your contributions to the side, would you have done it?<p>If you had the option to exclude only certain people (e.g. those who argues with you) from seeing/using your contributions, would you have done it instead of deleting your account?<p>I am asking because I've too been burned and it's very commonly how an open source contributor's journey ends. So I've been toying with the idea that contributors should be able to exclude certain people or perhaps even groups of people from using their work.<p>Basically "I give away my work for free for anyone to use and build upon but if you don't appreciate it, if you treat me like shit, if you do any of X Y Z which hurts me or other people, then you're no longer allowed to use it".
i understand the sentiment, but the nature of FOSS is that i can't really prevent anyone from using it. i'd have to police it, and that would just lead to more misery.<p>i too contributed to stackoverflow and eventually stopped because it didn't feel worth the effort. i never asked a question though, so i didn't have the experience GP made, but i doubt i would want to delete everything, at least not without moving all my answers to another location.<p>once or twice when searching for the solution to a specific problem i was lead to a stackoverflow question and had to discover that the answer that solved my problem was my own from a decade earlier. so i too benefit from posting answers. deleting them would reduce that benefit.
Incredibly based response to the "I am the customer" energy in OSS.
Nvim treesitter is kind of taken for granted even if nvim maintainers say it's experimental. So I think the community will have to find a solution and replacement project.
> since people apparently can't read<p>I know Free and OpenSource software is only available thanks to maintainers who spend their time and money to make it available.
This type of sentence though, makes all I just mentioned easy to forget, when they take that tone with you.
I get anxiety publishing open source because of things like this.
The one GitHub repository of original work I publish right now is kept in Archived at rest; I unarchive it to push commits and then rearchive it, every time. It has been perfectly quiet and my anxiety associated with working on it has dropped to zero. Highly recommended.
Try publishing on <a href="https://repo.or.cz" rel="nofollow">https://repo.or.cz</a> (or another old-style web interface), and just leave an email for contact.<p>You will hear only crickets.<p>Adding the slightest friction, and making potential drama 1:1 only, demotivates most people.<p>You might miss out on an occasional good feedback, though.
This is the way. You can also just decide to not accept contributions and feedback in general.<p>Further downside is that your project will have a harder time becoming popular, and being popular is secretly (or not so secretly) the motivation for many in open source.<p>Will be a lot more honest though.
I don't have my stuff on GitHub, but git push will send me email with a patch. I actually get real, useful patches out of it (more than before I had only email); not huge stuff, but scratching people's itches and bugs; stuff I can mostly just apply right away. I never get pure junk (e.g. the “I'm sure you want to switch to My Favorite Build System” patches, or AI slop). So somehow, for me, this is pretty much the perfect level of friction, it seems.
idgi, shitting on the maintainer takes 10x more time than forking the repo<p>I guess he really needed the latest ci/chore commits
Genuine question: Why not just close such derailing and burdensome issues and/or block mean people?<p>My guess: People would freak out if FOSS maintainers actually did this.
From personal experience that usually results in the person on the attack opening two additional issues:
1) the original issue recreated, maybe with a childish flourish added e.g. "because we're apparently in the DPKR for this project"
2) a new issue claiming baseless censorship and attacking the maintainer(s) motivation and governance<p>A variation on this is the above plus they get a hoard of friends/wellwishers/bots etc to raise more issues claiming censorship and it devolves into a massive ad hominem flame war, doxxing, death threats and the usual rubbish that ruin a good thing.
The Fandom Menace strikes again.<p>But seriously, this is messed up. People need to learn to treat others with respect and kindness. Hopefully the maintainer is able to simply move on after archiving the repo, and isn't dealing with any mental struggles from dealing with years of entitled users demanding things for free.<p>In popular open source projects this is a recurring issue. I suspect the only way to deal with it is to either shift to a platform that has better tools for moderation, or end the project like the maintainer has done. Let someone else fork it and deal with the users.<p>To clason: Thank you for all the work you did maintaining nvim-treesitter!
Will this mean the end to NeoVim, whose main (one of) selling point is the tree-sitter out of the box? I hope not, as I am the long time user and supporter of the project.
It’s like the law of big numbers. Once a project grows large enough, some entitled free-riders are bound to pop up.<p>What to do as maintainer? Can everyone of them find piece?
Isn't treesitter integrated to nvim anyways at this point, even if it's experimental support?
Honestly this is just a case of open source software users expecting a free lunch. Firstly, the maintainers of this package don’t owe you anything, secondly the new version of neovim and treesitter-cli are already in Arch extra testing, and since they don’t break anything they’ll probably be in extra next week, so chill the fuck out.<p>If you have a problem with how open source works just please head back to vscode.
Honestly I missed the neovim 12.0 being marked stable, and just updated when this happened.
So what will happen now? Who will take over? Abandoning a project because 1 person is kinda extreme.
What will happen now is not clasons problem anymore I guess.<p>The point they seem to be making is that it never was their problem, but they were just solving it for everyone for free anyway, and in return they were doing it wrong and they should stop interacting with people.<p>Honestly even when people are being paid to work for you and their job is to do what you ask them to, speaking to them like that is never going to work out.
I'm pretty sure this is not over a single user, but this was simply the straw that broke the camels back
This is why I built nvim from source, and git pull plugins into the pack directory. I think it's even a static binary. Whatever changes I need I git pull. After they added LSP I have not wished for anything else really, so I stopped pulling. I think I pulled LSP completion API in 0.11 era but that's it.<p>Hate it when people break backwards compatibility. For me it's sacrosanct, more important than absolutely anything else.<p>I only have a handful of plugins so the system works well. And I have a 500 line init.vim (and no other config).<p>Some ecosystems like golang share this principle and so I can freely update packages without worrying about breakages. But other ecosystems(nvim, python, etc) I'm a lone warrior