Go's module system does something clever that also creates a trap: it uses the URL where your code lives as the canonical import path. If your code is on GitHub, every file in your project — and every downstream consumer — hardcodes github.com/yourorg/yourpackage into its source. Move to GitLab, and every import breaks. Your code is now structurally coupled to a hosting vendor, not by contract, but by namespace. The author, Iain Cambridge, describes a real-world case where this coupling metastasized. A company ended up running GitLab, GitHub, and Azure DevOps simultaneously because migrating import paths was too expensive in developer time. Three hosting bills, three sets of credentials, three CI pipelines — all because Go's import convention made switching a codebase-wide refactor instead of a DNS change. The fix is vanity import paths: you own a domain like go.yourcompany.com, serve a tiny HTML meta tag that tells the Go tool where to actually fetch the code, and redirect human visitors to GitHub (or wherever). The import path in your code becomes go.yourcompany.com/yourpackage, which you control forever. If you move from GitHub to GitLab next year, you update the meta tag. No code changes downstream. Cambridge provides the full Nginx configuration and HTML template. The setup is straightforward: a server block that checks for Go's ?go-get=1 query parameter, serves the meta tag to the Go tool, and issues a 301 redirect to GitHub for human browsers. Add a Let's Encrypt cert and you're done. Total infrastructure cost: one static HTML file and a few lines of Nginx config per package. The pattern isn't new — Uber uses go.uber.org, MongoDB uses go.mongodb.org — but adoption among smaller teams and individual developers remains low. The Go community's default behavior is to use github.com paths because it's the path of least resistance at project creation time. The cost only materializes later, when you need to move, and by then the switching cost has compounded across every dependent. This is a textbook case of a small upfront investment (30 minutes of DNS and Nginx setup) preventing significant future lock-in. The advice applies doubly to commercial teams managing internal libraries, where import paths propagate across dozens or hundreds of services. Cambridge built a tool called Boneclone specifically to handle skeleton code replication across multiple git platforms — a tool that exists precisely because this problem went unsolved for too long. The broader lesson extends beyond Go: any system where a vendor's domain becomes load-bearing infrastructure in your source code is creating invisible switching costs. Go just makes the coupling explicit enough to see.
