[bobbylarrybobby]

I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience.

Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668)

[deadbunny]

And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.

[imran0]

Well, Bram is the author of the parent project, he doesn't have any obligation to make it compatible with the derivative.

[jonaustin]

Vim has been around long enough that I'd argue it's just as much owned by the community at this point.

[anonydsfsfs]

I just checked the repo[0], and it says Bram has authored 95% of all commits to Vim. To say "the community owns Vim" when they've done ~5% of the work reminds me of group projects in school where one person does all the work and everyone else claims credit.

[0] https://github.com/vim/vim

[animal_spirits]

For a while Bram would copy paste all proposed changes from other peoples branches to his own branches and therefore giving himself the git-blame for the code. I think only recently he started allowing other people to actually maintain the repo.

[kelnos]

I'm not sure this is because no one wants to contribute. I think it's more because Moolenar prefers to do the work himself, and doesn't like to accept much in the way of contributions from others. He's certainly allowed to run his project that way, but I can see why it might turn some people off.

[LeonidasXIV]

Which is yet again contrasted with how NeoVim runs things and the 824 contributors to the repository at time of writing. I believe that justinmk, one of the principal drivers of the project specifically stated that he doesn't want to be something like a BDFL and I assume that's also pretty much a reaction to Vim.

[j16sdiz]

for a long time vim do send patch over email, and the git history did not preserve the original author info

[wirrbel]

Understandable in SVN times, but lack of Attribution in git times

[viccuad]

One is not a better parent by controlling their kids for their foreseeable future. One needs to let them join the world and grow on their own, with their own friends.

[usrbinbash]

vim is open source, so everyone who wants can fork the repo and change the code however he pleases.

[self_awareness]

If you use something for a long time, this doesn't make you an owner of it.

[webkike]

You can argue that, but what would that even mean? Forceful requisition of his website and private keys?

[calvinmorrison]

Godwin's Law of HN, soon enough someone will chime in that European Regulators should force someone to do something for the dubious good of the public

[kingofpandora]

Of course, there was no obligation.

But he went about it in a way that certainly looked petty.

[kzrdude]

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.

[slgeorge]

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.

[0] https://en.wikipedia.org/wiki/Vim_(text_editor)

[masukomi]

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.

[kzrdude]

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.

[thayne]

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).

[margarina72]

open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible.

It is fully open source.

Open source does not mean the maintainer is under the obligation to add features, or integrate PRs.

[0]: https://opensource.org/osd

[1]: https://www.gnu.org/licenses/vim-license.txt

[kelnos]

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.

[enriquto]

> 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.

[dspillett]

> 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!

[lifthrasiir]

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".

[yjftsjthsd-h]

Perhaps "community led" or such?

[capableweb]

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.

[usrbinbash]

> but its development model is not the one we've come to be comfortable with

I am very comfortable with this model.