GoKawiilBlog post argues Go projects should avoid hardcoding GitHub in import paths
Developer Iain Cambridge argues that Go's practice of importing packages by their git-hosting URL (e.g. github.com/user/repo) ties codebases to a specific provider like GitHub. He describes a company that ended up paying for GitLab, GitHub, and Azure DevOps simultaneously because switching import paths was too costly, and says he built a tool called Boneclone to replicate code across multiple git hosts. His proposed fix is to use a custom domain (e.g. go.iain.rocks/boneclone) that redirects to the actual host, so the underlying provider can be changed without altering import paths.
GoKawiil's interpretation of the reporting above, not reported fact.
The post highlights a lock-in risk baked into Go's package-naming convention, which could discourage teams from migrating hosting providers even when cheaper or better options exist. Using a custom domain as an indirection layer could reduce switching costs and vendor dependency, though it adds a small maintenance burden of managing DNS redirects. The example of a company paying for three git platforms simultaneously suggests this isn't just theoretical but has real cost implications for teams that ignore it.
- Go import paths often embed the git hosting provider's domain directly, creating vendor lock-in.
- A real-world company reportedly paid for GitLab, GitHub, and Azure DevOps at once because switching was too disruptive.
- The suggested fix is using a custom domain as a redirect layer so hosting can change without breaking import paths.
Source: iain.rocks, 2026-09-27
Published there as: “Don't couple your Go code to GitHub”
Read the original report → The summary and analysis above are GoKawiil's own, written from reporting by the source above. Facts and quotes belong to the original publisher.