I will never understand people like GitHub user “shushtain” in the linked issue.
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?
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.
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.
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.
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".
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
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.
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.
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.
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.
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".
This is not "passion". This is sheer entitlement, and abuse on top.
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.
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.
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.
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?
> Unless the goal isn’t a productive outcome, but just to be mean?
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.
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.
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].
Think of the average person, in terms of communication skills, education, critical thinking, emotional regulation, etc. Now realize that half the population is below that.
If you're in a social bubble, which is hard to avoid nowadays, I recommend watching police body cam videos to help recalibrate where the ends of the spectrum are. It's also given me sympathy for police in general
Empathy goes both ways. You can recognize them being unfair while still appreciating their reasons for being unfair.
People seem to have this notion that there's some theoretical possible world where everything is completely moral, and we're just failing to get there. But that is not true. You get locally moral and globally moral arrangements, and they're not necessarily going to mesh. It's just like any other large system.
Guy can be justified from their perspective, people can be justified for distancing themselves from him. That's life. Having a reason for something is further the bare minimum, not the endgame.
The source of a library needs an update every time there is a configuration change in _any_ tree-sitter parser supported.
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.
And in a similar vein, if queries (.scm files) were hosted in each parser repo, it would also be fairly easy to handle.
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.
For my text editor I had to yank nvim-treesitter queries and rewrite them.
I think it would make a big difference even if the aggregation of queries was separated out into a separate repo from the other code, so that you can pin the code for installing and updating parsers while still being able to get updates to the queries, and it isn't as much of a problem if the installation code make major breaking changes (like requiring you to use 0.12)
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.
No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at https://github.com/nvim-treesitter/nvim-treesitter/graphs/co... , 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.
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.
This is a common issue with tooling used by open source.
Either you alone own the repo but then you're a single point of failure. Or you give those perms to others but then any one of them can abuse it (or get hacked).
I'd like to see tooling which requires consensus or voting to make certain changes such as archiving a repo or publishing a new release.
If you had the option to also delete all your contributions to the side, would you have done it?
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?
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.
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.
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.
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.
> the nature of FOSS is that i can't really prevent anyone from using it
That's my point - maybe FOSS isn't the absolute good we've been lead to believe.
It was a response to locked down proprietary software which increasingly became hostile to its users. And it is (from a user's perspective) better that that for sure. But from a dev perspective, it's not as good as it could be.
> my answers
Exactly, those are your answers, your work. We've spent a lot of our limited time working for other people's benefit because we believed in it or sometimes because it was fun. But ultimately, it's becoming clear other people don't care and will throw us under the bus as soon as we're no longer useful. And then there's people who are just looking for a way to take advantage of us.
And I want to exclude both from benefiting from my work.
We should strive to find methods to make good, productive, pro-social people to benefit while keeping anyone who wants to exploit us away.
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.
Unfortunately this is a social problem, requiring a social solution, not a technical one. (Which isn't to say that the solution won't involve pressing the fork button. But just pressing that button doesn't solve anything.)
That's true. Good governance, initiative, and leadership are rare and nonzero cost. The big plus is that the code is FOSS rather than closed source. It would really suck way more if it were closed and suddenly went away.
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.
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
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 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.
I couldn’t when I started out doing that. But I don’t want PRs, either, so this works out for the best: I contribute a benefit and if someone forks it then I can consider merging their work unbothered by their expectations that their ‘request’ be granted.
Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!)
Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover?
1a) A project that has recent commits, but has pull requests and issues disabled.
1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it.
2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled.
2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it.
As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub.
Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.
You could add your own banner that makes it clear what the status and expectations of the project are. In fact, that is probably a valuable thing to do if the project is archived too.
If you archive it, then sure user's are less likely to send you disrespectful messages by whatever means (assuming they can find such means), but they are also less likely to use it, because you have basically said "this project is abandoned". Which if you don't want users at all, I guess that's fine, but then I'm curious why you bothered to publish it publicly at all.
This is the way. You can also just decide to not accept contributions and feedback in general.
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.
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.
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.
tree-sitter still works. Many features are implemented in neovim itself. This project provides an easy way to set up parsers for various languages (including installation and retrieval of necessary queries), along with some quality-of-life features. You can just fork it, and it will work perfectly fine for the 0.12 cycle (barring any underlying parser changes), or you can fork the previous version on the master branch if you want to keep using 0.11.
Considering this is a very common plugin in the neovim ecosystem, it will probably get forked and maintained by someone else, like null-ls was forked into none-ls.
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.
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.
To clason: Thank you for all the work you did maintaining nvim-treesitter!
I would not worry too much about the maintainer - judging by his GitHub profile he does a bit of professoring as a side hustle ;)
Thank you Christian Clason for giving us nvim-treesitter! And always remember, for each idiot insulting you there are thousands of happy, silent users.
You could probably make things work without nvim-treesitter, but it's an additional maintenance burden you're taking on. As the repo itself says, it's an abstraction layer. You don't _need_ it, but it's nice to have.
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.
If you have a problem with how open source works just please head back to vscode.
It's not one person. The maintainer's been getting abuse over their decision to rewrite the plugin for quite some time now, despite being very clear about what they're doing. It's fine for users to be upset, but not to treat the author like this.
What will happen now is not clasons problem anymore I guess.
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.
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.
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.
Hate it when people break backwards compatibility. For me it's sacrosanct, more important than absolutely anything else.
I only have a handful of plugins so the system works well. And I have a 500 line init.vim (and no other config).
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
I will never understand people like GitHub user “shushtain” in the linked issue.
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.
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.
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.
Though many of my projects are completely free for the users.
Latest being this one already past 1000+ active users https://play.google.com/store/apps/details?id=com.macrocodex...
If you don't listen to your passionate users, i doubt you'll ever grow.
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?
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".
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
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.
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.
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.
incredible jugaad saaaaar!!!!
++ izzat!!!
> They are just passionate and most of the times annoyed because something as simple is not being done right.
No, this is not adequate justification for such behavior towards volunteer FOSS maintainers.
It isn't justification for being rude. But just because someone is being rude doesn't mean what they are complaining about isn't an issue.
> They are just passionate and most of the times annoyed because something as simple is not being done right.
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".
This is not "passion". This is sheer entitlement, and abuse on top.
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.
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.
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.
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.
He's just incompetent:
1. He blames the maintainer that his distro doesn't ship latest neovim.
2. He didn't pull neovim from the Extra-Testing Arch branch.
3. He didn't pull neovim from AUR.
4. He doesn't have the knowledge to build from source.
5. He didn't pull the tarball from git.
6. He didn't pull the AppImage from git.
There's so many solutions to choose from and he chose none; pure ragebait.
You should totally post this on the original thread just for adjustment :-)
The project is archived, you can't.
> Unless the goal isn’t a productive outcome, but just to be mean?
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.
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
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].
[0] https://youtu.be/aoag03mSuXQ?t=597
You see, humans are emotional beings, not rational beings. Surely you've seen examples of that basically everywhere there is human interactions.
Think of the average person, in terms of communication skills, education, critical thinking, emotional regulation, etc. Now realize that half the population is below that.
If you're in a social bubble, which is hard to avoid nowadays, I recommend watching police body cam videos to help recalibrate where the ends of the spectrum are. It's also given me sympathy for police in general
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?
Having a bad day does not entitle you to take it out on others
Empathy goes both ways. You can recognize them being unfair while still appreciating their reasons for being unfair.
People seem to have this notion that there's some theoretical possible world where everything is completely moral, and we're just failing to get there. But that is not true. You get locally moral and globally moral arrangements, and they're not necessarily going to mesh. It's just like any other large system.
Guy can be justified from their perspective, people can be justified for distancing themselves from him. That's life. Having a reason for something is further the bare minimum, not the endgame.
that's why i said it's not really an excuse?
This is a bane of all such aggregator libraries, that suck maintetance from other projects into themself. Null-ls suffered from this, too: https://github.com/jose-elias-alvarez/null-ls.nvim/issues/16...
The source of a library needs an update every time there is a configuration change in _any_ tree-sitter parser supported.
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.
And in a similar vein, if queries (.scm files) were hosted in each parser repo, it would also be fairly easy to handle.
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.
For my text editor I had to yank nvim-treesitter queries and rewrite them.
https://github.com/ivanjermakov/hat-tree-sitter
I think it would make a big difference even if the aggregation of queries was separated out into a separate repo from the other code, so that you can pin the code for installing and updating parsers while still being able to get updates to the queries, and it isn't as much of a problem if the installation code make major breaking changes (like requiring you to use 0.12)
Good for the maintainer, hope they find peace and do things just for their fun, without needing to deal with comments like that anymore
Stepping away from the project would be fine.
Archiving a project which has other maintainers is an overreaction.
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.
No idea if this is the case here, but I hope the author sticks with this decision. Although, looking at https://github.com/nvim-treesitter/nvim-treesitter/graphs/co... , 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.
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.
This is a common issue with tooling used by open source.
Either you alone own the repo but then you're a single point of failure. Or you give those perms to others but then any one of them can abuse it (or get hacked).
I'd like to see tooling which requires consensus or voting to make certain changes such as archiving a repo or publishing a new release.
If you had the option to also delete all your contributions to the side, would you have done it?
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?
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.
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.
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.
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.
> the nature of FOSS is that i can't really prevent anyone from using it
That's my point - maybe FOSS isn't the absolute good we've been lead to believe.
It was a response to locked down proprietary software which increasingly became hostile to its users. And it is (from a user's perspective) better that that for sure. But from a dev perspective, it's not as good as it could be.
> my answers
Exactly, those are your answers, your work. We've spent a lot of our limited time working for other people's benefit because we believed in it or sometimes because it was fun. But ultimately, it's becoming clear other people don't care and will throw us under the bus as soon as we're no longer useful. And then there's people who are just looking for a way to take advantage of us.
And I want to exclude both from benefiting from my work.
We should strive to find methods to make good, productive, pro-social people to benefit while keeping anyone who wants to exploit us away.
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.
The fork button exists. That's the technically easiest solution.
Unfortunately this is a social problem, requiring a social solution, not a technical one. (Which isn't to say that the solution won't involve pressing the fork button. But just pressing that button doesn't solve anything.)
That's true. Good governance, initiative, and leadership are rare and nonzero cost. The big plus is that the code is FOSS rather than closed source. It would really suck way more if it were closed and suddenly went away.
> since people apparently can't read
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.
It's clear to me that the maintainer is referring to "shushtain" and those type of people
> when they take that tone with you.
This makes it sound as if you took it personally?
Genuine question: Why not just close such derailing and burdensome issues and/or block mean people?
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
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.
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.
Can't you just disable issues?
I've seen DRF did that. Not sure if that is not possible for normal accounts.
I couldn’t when I started out doing that. But I don’t want PRs, either, so this works out for the best: I contribute a benefit and if someone forks it then I can consider merging their work unbothered by their expectations that their ‘request’ be granted.
You can disable PRs as well
Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!)
Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover?
1a) A project that has recent commits, but has pull requests and issues disabled.
1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it.
2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled.
2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it.
As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub.
Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.
You could add your own banner that makes it clear what the status and expectations of the project are. In fact, that is probably a valuable thing to do if the project is archived too.
If you archive it, then sure user's are less likely to send you disrespectful messages by whatever means (assuming they can find such means), but they are also less likely to use it, because you have basically said "this project is abandoned". Which if you don't want users at all, I guess that's fine, but then I'm curious why you bothered to publish it publicly at all.
Try publishing on https://repo.or.cz (or another old-style web interface), and just leave an email for contact.
You will hear only crickets.
Adding the slightest friction, and making potential drama 1:1 only, demotivates most people.
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.
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.
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
I guess he really needed the latest ci/chore commits
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.
tree-sitter still works. Many features are implemented in neovim itself. This project provides an easy way to set up parsers for various languages (including installation and retrieval of necessary queries), along with some quality-of-life features. You can just fork it, and it will work perfectly fine for the 0.12 cycle (barring any underlying parser changes), or you can fork the previous version on the master branch if you want to keep using 0.11.
Considering this is a very common plugin in the neovim ecosystem, it will probably get forked and maintained by someone else, like null-ls was forked into none-ls.
The Fandom Menace strikes again.
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.
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.
To clason: Thank you for all the work you did maintaining nvim-treesitter!
I would not worry too much about the maintainer - judging by his GitHub profile he does a bit of professoring as a side hustle ;)
Thank you Christian Clason for giving us nvim-treesitter! And always remember, for each idiot insulting you there are thousands of happy, silent users.
Isn't treesitter integrated to nvim anyways at this point, even if it's experimental support?
You could probably make things work without nvim-treesitter, but it's an additional maintenance burden you're taking on. As the repo itself says, it's an abstraction layer. You don't _need_ it, but it's nice to have.
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.
If you have a problem with how open source works just please head back to vscode.
It’s like the law of big numbers. Once a project grows large enough, some entitled free-riders are bound to pop up.
What to do as maintainer? Can everyone of them find piece?
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.
It's not one person. The maintainer's been getting abuse over their decision to rewrite the plugin for quite some time now, despite being very clear about what they're doing. It's fine for users to be upset, but not to treat the author like this.
What will happen now is not clasons problem anymore I guess.
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.
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.
Hate it when people break backwards compatibility. For me it's sacrosanct, more important than absolutely anything else.
I only have a handful of plugins so the system works well. And I have a 500 line init.vim (and no other config).
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