Forking is a core Git feature and probably one of the reasons for its success. However, within a company forking in the wrong circumstances might do more harm than good. In the following, I will explain these circumstances.
Let’s start with a bit of history. In the old days, you could only contribute code to a project (conveniently) if you had write access to the project repository. Usually, the maintainers were reluctant to give anyone write access, because new contributors could easily mess things up. As a contributor, you had to earn trust to get write access, and this took time. Consequently, external contributions were cumbersome and slow to be accepted.
Then, Git came along and made the concept of distributed version control systems (DVCS) popular. In a DVCS, you can create a copy (a fork) of the original repository (also called upstream) without anyone’s approval and start working on your changes.
Later, GitHub launched and invented web-based pull requests. With pull requests, it is super easy to present your fork’s changes to the maintainers of the upstream repository. Furthermore, the maintainers can accept (= merge) your changes with just one click.
This is the reason why Git and GitHub are so successful in the open-source world. The combination of forks and pull requests make contributions very easy, especially to new contributors.
However, as with many things in life, forking also has a dark side. People could fork a repository and start working on changes without the intention to ever contribute back to the original repository ¹. This is sometimes called a hostile fork. The consequence is a new, usually incompatible, version of the project. This happens in the open-source world once in a while when people have different ideas about a project. Usually, the fork with the larger user base becomes the new standard in the end.
This natural selection mechanism works reasonably well in the open-source world. However, within a company, hostile forking is usually a very bad idea. First and foremost, it’s a waste of resources, as the company has to maintain multiple versions of the same project in parallel. Second, if engineers want to use the project, they will need to pick one of the versions. Third, bugs in the project will have to be fixed in several places.
In conclusion, every project repository should only exist once within in a company. If a certain project does not fulfill your needs, then get in contact with the maintaining team and discuss a collaboration. Don’t fork to avoid talking, as this will hurt your company in the long run. Fork only with the intention to contribute!
 Some companies try to fight the problem with gigantic mono-repos.