Don't couple your Go code to GitHub

The author starts from one of Go's nicer design choices: import paths double as the location to fetch code from, so hosting a library at github.com/thetrueares/boneclone means users write import "github.com/thetrueares/boneclone" and Go fetches it over git. This makes it easy to find where to report bugs and lets Go distribute libraries without a central package manager — but for most people the path is literally their git host's URL, which he argues is a mistake.

The core problem is coupling to a hosting provider. If you move from GitHub to GitLab, you have to change your import paths or users keep pulling the old version, and the switching overhead can become so large that teams simply never migrate. He cites a company running code on GitLab, GitHub and Azure DevOps simultaneously because relocating the code was too big a task and they "didn't have time" — so the coupling directly cost them money in three hosting bills. He says this is why he built Boneclone, a tool for replicating skeleton code across multiple git hosting platforms at once.

The proposed fix is vanity import paths on a custom domain, such as go.iain.rocks, go.uber.org or go.mongodb.org: go.iain.rocks/boneclone points at github.com/thetrueares/boneclone, and if the code later moves to GitLab, end users' install commands stay identical. He recommends every commercial Go team use custom domains for internal libraries and packages as a cheap way to avoid pointless coupling.

He also publishes the configs to do it, including an Nginx server block for go.iain.rocks that serves static HTML when the query string contains go-get=1 (the Go tool's probe) and otherwise issues a 301 redirect to GitHub using $request_uri, plus the usual Certbot SSL certificate lines.