Comment by 3D39739091

Seems like the author's only talking about the extreme end of the spectrum. Not every fork is attempting to replace the forked project. There are so many other lesser degrees.

You can fork something just for a fun or experimentation. You could have a use case that the project doesn't handle and you aren't ready or interested in contributing that solution (especially if you only need this for a one-off scenario or a short-lived project).

This could also apply to needs that your client or company has, but it's out of scope for the original project, so you make a private fork that you and your team maintain internally. It could be that you DO actually make this public (either initially or eventually) so other people who have the same need can benefit and possibly contribute.

It could even be that, over time, the amount of users of your fork convince the upstream project that there is a need for this use case. Maybe they decide to handle it themselves or maybe your fork merges back in with the upstream. Sometimes projects just can't say yes to certain things because they wouldn't want to/be able to implement, maintain and support it. Seeing that you and others maintain a fork for a non-trivial amount of time can establish the credibility that there is indeed someone who will maintain this.