[michaelmrose]

This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital.

It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want. In reality it is likely to lead to more total developers working on the ecosystem.

It contains the misconception that code created for the fork is worthless for the primary project despite the fact that compatibly licensed code can either directly be used or can be used as a conceptual v1 that can be improved with the benefit of the prior work.

> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.

If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades. This is brought to you by the same line of thinking that we all ought to work on one foo where foo is a an application because then and only then would open source compete with the billions of dollars poured into photoshop and the entrenched benefit of OEMs supporting the windows ecosystem with its application ecosystem, broad hardware support, billions of dollars to pay developers, and ability to earn money on shovelware and convince grandma to instead download Linux ISOs.

Just because its commonly expressed doesn't mean there is merit to the argument.

[coldtea]

>This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital.

And yet, projects that fail to get adoption and foster a community rarely go that far, except if they're small hobby projects that can fit on one or two developers scope.

>It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want.

Projects are not just about core developers. They're also about adoption, documentation (webpages, posts, books, articles), plugins, even themes, and configuration bundles. All of those are split in a fork.

And it's not like without NeoVim most of those vi-style-liking people would have gone to a totally different alternative editor. Most of them would have stayed with Vim. Especially when the differences where small to begin with (but enough to fragment compatibility in many areas).

Devs and users (including new devs and users) that would have gravitated towards Vim, now have the addec choice to gravitate towards NeoVim. The amount of people, that, absense of NeoVim, would have gravitated towards something completely different is, I'd say, much smaller.

>If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades

People have mentioned actual projects that have been hurt by forks. XFree86 vs X.org, OpenOffice.org vs LibreOffice, MariaDB vs MySQL, and others. The xBSD fragmentation didn't help either to them losing ground to Linux.