Earlier quoted context omitted.
Forking and managing has a cost associated with it too. If your own DC burns down you also have nothing. There is no "wrong way" just a different ways to evaluate risks-benefits and choosing whatever works best for your case.
100% this. As soon as you fork a project, you are now responsible for the evolution of it (even if that's just merging in upstream changes). It puts a large burden on engineering teams to track changes and maintain the fork.
You don't necessarily have to fork it, just the possibility of the fork changes the game. It means that the original maintainer cannot shut you down. If enough people deem a fork useful they can work together.
Of course there's a cost associated with it. But how much is it compared to the risk of someone shutting a core element of your business down? You have to evaluate.