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.
That's pithy but a characterisation that misses many important aspects.
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.
vim's support for legacy platforms is... IMNSHO extreme to the point of self-harm.
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.
I think it's fair that a new person is needed at the helm to want to look forward to new features. A comparison with Vi only means the status quo is good enough. When we put it like this, Neovim is unavoidable. (The fork is unavoidable, but it doesn't mean the demise of the old project.)
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.
The success of Neovim is great example of the advantage of open source. When the developer of a popular piece of software didn't want to implement features some of it's users wanted, those users were able to fork it and create a successful project that had those features, and eventually led to more innovation in the original project.
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).
I think you mistake the parent's point. Vim's code is certainly open source (I don't think anyone disputes that), but its development model is not the one we've come to be comfortable with. Moolenar maintains an iron grip on vim, and controls what goes in (and what doesn't) much more strictly than many other open source projects. That is certainly his prerogative, but it's also the prerogative of others to not like that, and want to fork and create something that is more welcoming to outside contributions.
> the development model is not the one we've come to be comfortable with
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.
> but its development model is not the one we've come to be comfortable with
"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!
But "open project" is not a helpful term either, which can mean anything from an open-for-suggestion proprietary project to a maximally open project (whatever it means). The correct term would be "open governance". We perceive "open" as something positive, which is of course not always true and there are different kinds of "open".
Give a read to "The Cathedral and the Bazaar" and subsequent essay "Homesteading the Noosphere". They'll give an overview of different software designs, including the management of building those designs, in a open source/free software context.
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.
