With the dep tool and Go modules at our disposal, why would we ever need to manually fork any of the packages we depend on? Before we answer this question, let me first elaborate on how this process works.
Firstly, we need to fork the dependency we are interested in. If the package sources are available on a platform such as GitHub, GitLab, or BitBucket, then forking the package is as simple as visiting the repository page and clicking a button (see the following screenshot); otherwise, we would need to rely on the functionality provided by our preferred VCS to persist a copy of the dependency to a location under our control:
After forking the repo, we would need to scan through the code base and replace the imports for the original package to point to our forked version. Of course, a much better alternative would be to use the dep tool's provided escape hatch for overriding the source for a package dependency. In the latter case, we wouldn't need to modify any of the import statements in our code.
That brings us back to the original question: why fork in the first place? When working for companies that process sensitive data, such as the ones that operate in the fintech or healthcare domains, it is quite common to have an in-house security team that must audit each imported dependency for potential security flaws before the engineering teams are allowed to use it in their code.
Performing a full security audit on a package is quite a lengthy process; it stands to reason that auditing each package from scratch each time a new release becomes available is neither feasible nor cost-effective. As a result, security teams seek to amortize the initial audit cost by forking packages, performing a full audit, and then vet and cherry-pick any upstream changes.