Agreed on not shaming forking, but creating a serious fork for anything substantial takes a fuckton of effort and many times you wind up with multiple mutually-incompatible source trees. In libre, community-run software, it's almost always advantageous to settle your differences and centralize efforts than to fork and split the efforts.

Most forks die because its hard to get people to jump ship. Think about how much lemmitors cry about Lemmy, the devs, and lemmy.ml, yet they cannot muster the effort to keep kbin alive or get sublinks off the ground. OG Hexbear was eventually rebased back to upstream too.

When forking, there are a few paths, all having some serious disadvantage:

1. Soft fork and remain at the mercy of the decisions of the project you forked from unless your fork becomes the de facto default. This is usually only really beneficial if you want to rectify disagreements on a handful of small features. (e.g. Ungoogled-Chromium / Brave vs. Chromium, various Linux kernel forks)

2. Hard fork and lose compatibility of upstream patches, making keeping feature parity difficult. This is only really beneficial if your fork gets a critical mass of users/devs and can outpace upstream at features users want. (e.g. Forgejo vs. Gitea, Lemmy vs. OG Hexbear)

3. Rewrite from the ground up, building the same or a similar API but upon a better architecture. This is the most effort, but keeps compatibility with the ecosystem, and potentially has a massive payoff once fully implemented (e.g. like Tvix vs. Nix, OpenHarmony vs. Android)

4. Write an alternative from scratch, focusing on implementing the most important features and not caring about feature parity. This is the best balance for small utils, but you lose the ability to be used as a drop-in replacement. (e.g. lsd / eza vs. GNU, ripgrep vs. grep)

Getting a critical mass of devs onboard is key to success, but also difficult. Outside of some open core software making some shitty money-grabbing decision and sparking community outrage, that's not very probable.