By critiquing his reluctance to accept patches because he'll be stuck maintaining that code? By forking Vim and removing some compatibility and legacy support features when tarruda's multithreading patch was not accepted?
No, the core contributors have not been outright in their criticisms, but IMO the fork itself shows a lack of respect for Bran's work and a lack of willingness to work with him to make Vim better. And now tarruda has stepped back from NeoVim, perhaps recognizing himself the cost that Bram bears.
By simply contributing to the tests - one of the outright critiques of Vim itself - they could have brought a lot more confidence to accepting such patches to Vim, but they chose to take their ball and play elsewhere instead.
What frustrates me the most is that instead of two branches of Vim that are moderately better (with the future of one of the branches being left behind), we could have had one which was much better.
Way to misrepresent it. They made the async patch - it wasn't accepted. So they rewrote it to Bram's liking - still wasn't accepted. 5 rewrites further Bram says 'lol well actually I don't feel like accepting this PR at all'. Its very understandable to feel a bit of animosity after bending over backwards for someone with commit access and then after all the effort still having the PR refused. That's called being led on, and its ultimately a dick move.
People are free to fork open source projects. tarruda tried to merge the async job system before forking vim. Bram has the right to deny the patches, but the most successful projects are the ones that attract good contributors and don't depend on the output of a single coder. It's easy to say "just make vim better" without really trying to understand Vim's C codebase.
vim's source code is really hard to test. Refactoring is needed to make code testable. That's true for every project that doesn't have tests yet. Another thing that makes it really hard to contribute to vim is that it supports operating systems that don't even exist anymore. I really don't feel like spinning a VM to make sure my changes don't break it on MS-DOS. I would rather send a PR that removes MS-DOS support than support that.
Except that the direction we were moving wasn't one branch that was much better, it feels like it was no improved branches at all.
vim7 was a great improvement, and when I show people the time travel capabilities it blows their minds. But that was a long time ago. With the number of people to whom vim is very important, I'm surprised there isn't more results coming out of it.
Though maybe it is mostly that the core doesn't need to change and innovation can happen in the plugins? That is certainly true to some extent, but the async stuff was way overdue.
I don't think this is a fair assessment. Before forking an attempt has been made 'to make vim' better. It's open source thus imho all is well if there are two source trees with different 'philosophies' (one 'a bit' centralistic the other more team-like).
Regarding cost. Most developers need to be paid. I read [here](https://groups.yahoo.com/neo/groups/vimannounce/conversation...) that Google provided (some) funding to Bram. With neovim initially there were lots of new things (clean-up, async, terminal), I don't see a problem if there should be a bit of slowdown now. It's a team. I think it's robust. I prefer Neovim and occasionally use MacVim too, thus grateful to Bram also. No need for frustration imho (but I'm glad there is neovim:)
