[tomtomtom777]

Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up.

Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with.

In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.

Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason.

I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.

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

[j16sdiz]

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

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

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

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

[capableweb]

> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.

> Couldn't they not convince Bram Moolenaar of proposed changes

I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason.

That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript.

But that's how I remember it being started at least, but I could remember it wrong.

[aidos]

Correct. HN threads from the time:

https://news.ycombinator.com/item?id=7057051

https://news.ycombinator.com/item?id=7278214

[dvogel]

This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2...

My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):

    You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*

The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:

    Bram,
    I happy to see there is still some hope for this patch getting merged.

Then shortly afterward the other author gave Bram an ultimatum:

    Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
    
    If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.

Considering where the patch started, iterative feedback seems appropriate.

Bram replied (in part):

    It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.

The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.

[mkh]

I caution anyone reading this to not take this summary at face value. If you're interested, you should read the linked threads for yourself. I'd say you can leave out that someone followed up on some technical detail three years later, but you be the judge.

FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.

That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.

[mayama]

> The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

So, who forked neovim and what does this timers patch have to do with forking if the patch authors weren't the ones forking neovim.

[dvogel]

The founder of neovim did briefly attempt to participate in the vim dev process. This was a few months later. The most relevant thread is here:

https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...

He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:

https://news.ycombinator.com/item?id=7279358

In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.

[mempko]

Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.

[TotempaaltJ]

As above[0], these are different people than the author's of neovim

[0]https://news.ycombinator.com/item?id=31942444

[mempko]

Weird, so people who give justification for neovim and use that thread are wrong. Thanks.

Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?

[otikik]

It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua.

Of course I am stretching things a little, I know.

I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.

[teilo]

Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.

[kzrdude]

Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim.

To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.

[calvinmorrison]

To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.

[fatbird]

async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in.

Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors.

So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.

[cardanome]

Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me.

Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?

There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.

[fatbird]

The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.

Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim.

This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.

[cardanome]

> You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.

This seems more like an inexperienced developer getting frustrated with the process. I absolutely would expect that new contributors will have to go through multiple revisions before they can get anything merged.

When I started working as a junior dev my first merge request had more comments from seniors requesting changes than lines of code. It can be absolutely brutal but that something everyone needs to go through.

If he had tried for years he might have had a point but just because it took months does not mean Bram was not interested in the patch at all. Otherwise he wouldn't have suggested any fixes.

[fatbird]

Considering what Thiago accomplished by forking Neovim, you can’t describe him as an inexperienced developer. By all accounts the cleanup alone was was a huge and very successful effort—-from 300k LOC to 170,000, huge jump in test covereage, modern build chain and code checking with Coverity. He didn’t do it alone, but he led the effort and managed it incredibly well.

Seriously, you don’t have to love Neovim, but credit where it’s due.

[williamsmj]

I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/.

[akerl_]

Nobody needs to justify forking a project to other people.

[stonekyx]

The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years.

Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.

[xvilka]

> Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice?

I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.

[calvinmorrison]

lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.

[Tyr42]

I mean all Bram had to do was accept the async patches instead of ignoring them.

Then neovim wouldn't have got off the ground.

Once they started building, they wanted to "cut the cruft" and just went from there

[mempko]

Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.

[weakfish]

Forking is hardly easier

[KerrAvon]

Easier on the ego