open source software developers are getting fed up and are finally recognizing that they can just fucking leave.

  • the owner of nvim-treesitter gets a really shitty comment from a user saying that the update to a required version broke their workflow
  • the owner replies saying "hey just pin what you need instead of mainlining it if you need this for an older version"
  • the shitty user replies back saying "go switch to something that doesn't require interacting with people"
  • the owner says "OK." and ARCHIVES THE REPO

https://github.com/nvim-treesitter/nvim-treesitter/discussions/8627

like, holy shit, what a power move.

@chirpbirb To be fair, making an at least somewhat functional plugin crash on some versions just because you don't officially support them is quite hostile and practically malware.

Of course they can maintain whatever versions they want, and the other guy is a dick, but deliberately making it crash when users use it "wrong" is quite toxic. Especially for something as essential as a text editor. Livelihoods could be at stake 

@lianna @chirpbirb If ”livelihoods are at stake” then they can do the most basic amount of work required, read the readme and just pin the commit they want. Come on.
@krig Or you know, do _anything_ to support the development of the tool that apparently their livelihood depends on. @lianna @chirpbirb
@lianna @chirpbirb bailing out with an error message is hardly "making it crash" - and at the end of the day how hard is it to click the fork button and revert that change? Bearing in mind this software pretty much guaranteed to be used by people with development experience.

@lianna @chirpbirb

> practically malware

can we please stop saying this. it's patently not true and just waters down the term "malware" to the point where it's useless. there are other terms you can use.

@gsuberland @lianna @chirpbirb
gotta love it when the comments just prove the maintainer right...
@Yuvalne @gsuberland @chirpbirb I guess making people's setups crash if you don't like their software is now completely acceptable in Mastodon reply-guy land. what a wonderful eternal september we're having on fedi
@lianna @gsuberland @chirpbirb
step 1: make an experimental plugin an indispensable part of your workflow.
step 2: ignoring the implications of step 1, use said plugin in an undocumented way.
step 3: bully the maintainer into supporting your unsupported usage.
step 4: ???
step 5: profi– oh nvm we made the maintainer quit FOSS and now the indispensable plugin is abandonware. dang. didn't see that coming.
@lianna @Yuvalne @gsuberland @chirpbirb simply remove the plugin and it stops crashing? a plugin written for a future version of a software is not "malware" when it's being used wrong ​
@mitsunee @gsuberland @chirpbirb @lianna
or pin an older version, like the maintainer suggested....

@gsuberland @chirpbirb Malware is defined by software with unwanted, unexpected, malicious behaviour. Not every piece of malware needs to result in data breaches or something serious to be malware. Even a jumpscare screensaver is malware per definition.

Intentionally crashing your text editor if the maintainer is upset at your personal setup is pretty squarely in malware territory.

@lianna @gsuberland @chirpbirb

Well, it was pretty solid migration path for breaking changes - especially for an _experimental_ plugin:

1.) announce impending breaking incompatibilities - but keep legacy quirks enabled even if that's hindering development

(wait)

2.) give alerts/warning about the really coming breaks when old API is called - still works

(wait)

3.) throw proper errors for legacy API calls instead of silent/unpredictable fails

@lianna @gsuberland @chirpbirb

Yes: don't ever break APIs.

But while initial development or long life with everchanging input data dependencies (I am looking at you, CKP!), the architecture can be in need of a complete architecture overhaul when the old one proves to be too much of a misfit.

@lianna @gsuberland @chirpbirb

_mal_ware is defined by
_mal_icious intent.

The software exits _very defined_ and with a _very clear message_ on a mismatched software part - to _prevent_ crashes and data corruption. No hidden, malicious function.

Use a compatible version - i.e. either an old plugin or a newer nvim.

You won't expect to attach a new M.2 NVMe-SSD to your old floppy disc cables.
So why when installing the new plugin to old nvim?

@lianna @chirpbirb as an eight year maintainer of a packaging tool for a popular programming language there is no fully acceptable way to deprecate features. Someone will loudly, annoyingly complain no matter what path is chosen. From my multiple personal experiences attempting this I will never fault a maintainer’s choice
@drbrain @chirpbirb I mean, not going ahead actively putting effort into implementing sabotage features to crash setups is pretty easy. The ideal – if not perfect – solution would probably have been a deprecation warning and that's it.

@lianna @chirpbirb warnings gave no fewer annoyed users and, when it was time to remove the functionality, the same types of complaints that lead to nvim-treesitter being archived

“You were warned” did not stop them, plus I had to deal with complaints about the warning for N extra months during the warning period

@lianna @chirpbirb

SOMEONE THINK OF THE CHILDREN!!!

@m @lianna @chirpbirb "Mommas, don't let your babies grow up to be F/OSS maintainers..."

(With apologies to Waylon Jennings and Willie Nelson.)

@lianna @chirpbirb Considering this isn't a stable plugin, nobody should be using it for anything related to livelihood yet. If someone chooses to do so, that is entirely on them.