We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.
Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time.
Vim favours being available on multiple platforms, alignment with Unix tradition and stability:
> Vim is a highly configurable text editor built to enable efficient text editing. It is an improved version of the vi editor distributed with most UNIX systems. (https://www.vim.org/about.php)
Neovim is built by people who value fullness of features, who see multi-platform as 'legacy platforms' and are happy to break backwards compatiblity for the value of making something more complete by contemporary standards.
The easiest summary is - Bram's comparison is Vi, Neovim teams' comparison is VS Code.
I love many of the NeoVim's new features and capabilities.
But, I think it's possible to like Neovim while also understanding the positive value of Vim and why their approach is different. There's something in the human condition about turning everything into a winner and loser, a hero or a villain - but it's just not true.
As a project that's been running for 30 years Bram and that community have an approach that they are comfortable with. There's a way of working, and a rhythm to the project that has worked over the long-term. They're evaluation of changes is against their own internal values - those values are different to the people that are working on Neovim. Personally, to me 30 years of effort and contribution to providing something totally free is unbelievable.
I'm not even sure it's human nature to put it as winners and losers. Our current culture is obsessed with seeing it in this way, very much influenced by "the economy" of the wide-area societies we live in, but I'm not sure it's universal.
many of the systems it supports haven't received updates in decades and have essentially no users. The old versions work just fine on them, and require no changes because those systems aren't changing. There's no reason why _new_ versions of vim have to be held back by the need to work on ancient platforms.
The divergence and incompatibility is unfortunate though, especially since some of it just seems petty. Made moreso, because it isn't possible to truly polyfill functionality from one in the other (native commands and functions are effectively in a separate namespace than user-defined ones).
It is fully open source.
Open source does not mean the maintainer is under the obligation to add features, or integrate PRs.
Says who? There are many free software projects, with public source code and free licenses, that are not developed openly. For example, lua itself (on which neovim is based). The lua team are adamant on not accepting external patches. And that is perfectly alright, and not contradictory with neither the letter nor the spirit of free software.
I am very comfortable with this model.
"Open source not open contribution" is increasingly seen, and people don't seem to mind, and the attitude described with regard to vim development seem less "thanks, bit no thanks" than that, so I don't imagine any majority have an issue with it.
If I finally get around to making and releasing some stuff I plan, "not open contribution" is where I'll be. These things are my toys, they'll go my way, though the source is there so feel free to fork if you need/want something I'm not planning to do or not planning to do soon enough (I'll even link to your efforts so people wanting the same know where to find it). Unless you want to pay for my time to maintain and support your feature going forward, of course!
Both development models are OK, and plenty of people are comfortable with both. I'd actually argue that most early/not-"modern" FOSS software have had the model of "you're welcome to contribute, but we ultimately own the codebase and therefore decides what goes in. If you're unhappy, feel free to fork", and it's not until lately, that some projects have decided to merge almost whatever people contribute.
Some projects even go as far as giving people direct write-access as soon as someone has got a PR merged, but I don't think that's very common, neither is the "merge without strict review" model you seem to referring to.