Edit to answer the first point: free software as a cultural movement grew out of a need to control the hardware a software engineer bought and which came with n

Edit to answer the first point: free software as a cultural movement grew out of a need to control the hardware a software engineer bought and which came with no source code for the drivers. Friends made along the way was great, and I agree that's lovely, but ultimately that's what free software enables, among other lovely things (like not depending on a manufacturer you disagree with, or another programmer you disagree with). Forking a project does not duplicate the effort — collaboration requires a lot of effort, and the more collaborators, the more expensive it is (usually even more than 2x). This is why many well-run free software projects have their own BDFLs (Linux, Python... OK, maybe not so benevolent at all times :)). If the two of us wanted to take a project in a different direction, and insisted on keeping it a single project, we'd have to do more work to reach compromises all the time, neither side ever being fully happy, but doing duplicate work for an imperfect result. As you are well aware, RoI calculation is not as simple as LoC count, and typing in the code is the fast part. With two projects with clearer missions, willing contributors flock to the one they align better with, which leads to one being more stable, another being quicker to add new features. And no, getting all of those contributors on a single project would not result in a single project that is both stable and adding new features quickly. Obviously, no expectation on you to do anything. I just find it surprising you do not see the value in a different way to organize a community compared to what's common, even if what's valuable to you is different.