Forks in the free software world are usually a messy business. Egos get damaged, development effort dilutes, and it takes a long time before the two resulting projects end up working together. But, at the same time, forks are sometimes necessary to keep the bulk of contributors happy and keep the project moving along – look at what happened with XFree86 and X.org, for instance. The former was moving at a snail's pace and failing to attract new developers, but when the X.org fork arrived and most of the XFree86 team moved over, things got a lot better.

What has this got to do with Vim [1], the venerable command-line text editor with its notoriously steep learning curve? Well, Vim has had its own set of problems over the years. It's a very mature and reliable editor, but the code underpinning it was packed with cruft and suffering from bit-rot. This is inevitable given that Vim runs on pretty much every major operating system you can name – but the ancient codebase was impeding progress. New features were hard to implement, and new contributors were sometimes scared off.

So, a fork called Neovim came to life in 2014, with the goal of drastically refactoring Vim's code to provide better scripting support and improved performance and to generally clean up the cruft. For a while, it looked like Neovim could become the new Vim – just like X.org became the new XFree86. Bram Moolenaar, the lead developer of Vim, was skeptical about some of the changes in Neovim, but he didn't just close up shop and declare Neovim as the future (Figure 1). No, he and other Vim developers have been incentivized by Neovim to improve the original codebase – so, whatever happens with Neovim in the months and years to come, the fork has definitely benefitted the original project as well.

[...]