A lot of F/OSS does not understand Conway's Law and that they are copying systems that exist in the shape that they are because they are projections of organisations and business models into software architecture.
They are not designed to make modification easy, because making it easy for other people to modify and extend them makes it harder to sell the next version. They are not designed to interoperate with competitors' products, because that makes it easier to switch to competitors' things.
These are exactly the opposite of what a F/OSS project should look like if it wants to convince people to switch. It should be trivial to extend and modify, because that empowers the user and also means that they can address their use case without needing the original author to do any work. If it turns out that their problem is similar to other people's then it should be easy to share those improvements, either upstreaming them or distributing them along side. It should be easy to integrate with other systems because then your project doesn't need to reinvent the world, or grow and subsume the world, neither of which is desirable.
If you're selling software and you reach a state where it solves all of your users' in-scope problems, that's a disaster. You might be able to sell a few more copies as more people encounter the problem, but you're stagnant. People won't buy the next version unless you convince them to move to a subscription model, or you bolt in something that they don't really need but you can convince them they do.
If you're maintaining a F/OSS project and you solve all of the in-scope problems that users have, you've won. The project is done (modulo bug fixes and a little bit of ongoing maintenance as it needs to run in new environments). Now you can do something else. That's a totally different mindset to the COTS model and is why the most annoying F/OSS projects to deal with are the ones that try to look like COTS products.
