Why your Go code should not be coupled to GitHub

Go has an unusual trait among programming languages: a package's import path is also the address the toolchain fetches its source from. If a library lives at github.com/example/thing, that string appears verbatim in every file that imports it. In a blog post published on 27 September 2026, engineer Iain Cambridge argues that this convenience quietly ties a Go project to one hosting provider, and that teams should namespace their modules under their own domain instead.

Where the coupling comes from

The core of the problem is that the git host's address becomes the module path, which binds the code to that host. Move a repository to GitLab, Codeberg or a self-hosted server, and every import path, go.mod entry and replace directive naming the old location has to be rewritten, or the toolchain keeps fetching the old copy. The author writes that the overhead of switching is large enough that companies simply stop doing it, so the code effectively stays coupled to GitHub.

He describes a company that was working on GitLab, GitHub and Azure DevOps at the same time. Relocating the code was such a large task, and the team had so little time, that running three platforms in parallel was easier than consolidating. The cost was concrete: the company paid for three hosting services at once. Cambridge says this experience is why he built Boneclone, a tool that replicates skeleton code across several git hosting platforms simultaneously.

The fix is to publish modules under a custom domain, the same pattern used by go.uber.org, go.mongodb.org and his own go.iain.rocks. The domain is the import path, and behind it the same address can point at wherever the code currently lives. go.iain.rocks/boneclone resolves to github.com/thetrueares/boneclone today, and if the repository moved to GitLab, users would install it with an identical command and notice nothing. In his view, every commercial software development team using Go should namespace its internal libraries and packages this way.

Own the namespace, not the host

The mechanism is already built into the language: when the tool requests a path with the go-get=1 query string, the server returns a small HTML page carrying a go-import meta tag that names the repository URL. The author's entry reads go.iain.rocks/boneclone git https://github.com/that-guy-iain/boneclone, paired with a go-source tag that helps editors build links to files. His Nginx config serves that page to the Go tool and issues a 301 redirect to GitHub for human visitors who do not send go-get=1.

What the configuration looks like

The same story applies to CI and to the issue templates a project rarely touches: provider-specific badges, automated checks built from hard-coded URLs and links written into documentation all need separate edits when the host changes. A custom domain removes most of that work in advance, and switching providers becomes a matter of editing one meta tag and one redirect target.