---
title: "Go’s import paths point at GitHub, and one developer says that’s a problem"
description: "Use your own domain before your landlord moves, says Iain Cambridge — though the internet has opinions"
author: "Tomasz Idle"
published: 2026-09-28T08:45:41.636Z
modified: 2026-09-28T09:16:23Z
url: https://rews.cc/a/go-s-import-paths-point-at-github-and-one-developer-says-tha-693165
language: en
tags: ["go", "git", "open-source", "infrastructure", "programming", "tech"]
publisher: "Rews (https://rews.cc)"
---

# Go’s import paths point at GitHub, and one developer says that’s a problem

*Use your own domain before your landlord moves, says Iain Cambridge — though the internet has opinions*

By Tomasz Idle · September 28, 2026 · https://rews.cc/a/go-s-import-paths-point-at-github-and-one-developer-says-tha-693165

## In brief

- Go names packages by the URL where their code lives, welding imports to hosts like GitHub
- Cambridge says one firm ended up paying for GitLab, GitHub and Azure DevOps at once
- His fix: import packages via an owned domain, like go.uber.org, that silently redirects
- Critics note Go’s “replace” directive already solves this, and domains can lapse or be hijacked
- Others argue GitHub may simply outlast any custom domain an open-source developer can fund

Your house has an address, and the address is useful: the mail arrives, your friends can find you, the pizza guy does not end up in a field. Now imagine the address is not yours. It belongs to the landlord, and it is stitched into the fabric of the building itself, so that the day you move to a nicer neighbourhood, the address rips out a load-bearing wall on the way. This, says developer Iain Cambridge, is what the Go programming language has done to a large slice of the software industry, and almost nobody has noticed, because the pizza always used to arrive.

Go’s clever trick — and it was clever, once — is that there is no central library catalogue. The name of a Go package is simply the web address where its code lives. If your project sits at github.com/thetrueares/boneclone, then everyone who uses it writes the word “github.com” into the very first lines of their own code, and the Go toolchain dutifully fetches it with git. One system handles names, discovery, downloads and bug reporting. Beautiful. Also, as Cambridge points out in a blog post this week: welded to one company.

The failure mode is mundane. You decide to move your project from GitHub to GitLab, for any of the reasons a person might want to stop giving their work to a Microsoft subsidiary, and now you must rewrite every import line, in your code and in the code of everyone who depends on you. Or you don’t, and the world keeps fetching the stale copy. Cambridge writes that he watched one company grow so paralysed by this that it ended up running GitLab, GitHub and Azure DevOps *simultaneously* — three bills, three sets of plumbing — because it never “had time” to change where its code said it lived. Quitting a hosting provider had become more expensive than paying three of them forever.

(He liked the problem enough that he built a company around it: Boneclone replicates so-called skeleton code across multiple git hosts at once. So yes, the man selling umbrellas is telling you it rains. The forecast, in fairness, is still accurate.)

His remedy is the one boring, unglamorous technology that has outlived every platform it routes around: DNS. Put your packages behind a domain you actually own — go.iain.rocks, or go.uber.org and go.mongodb.org in the wild — and point that domain wherever the code happens to live this year. The trick is a small HTML convention the Go toolchain understands: when your program asks for a package, a hidden meta tag on the page whispers where the repository really sits, while human visitors get bounced along to GitHub with a 301 redirect. Cambridge helpfully published his nginx configuration and the dozen lines of HTML involved. The whole apparatus is about the size of a business card.

“Every commerical software development team using Go should be using custom domains,” he writes, typos included, calling it “an easy way to avoid any pointless coupling.”

The internet, being the internet, read the post and immediately produced the counterarguments, several of them rather good. One Hacker News commenter, dewey, noted that Go already ships an escape hatch — a “replace” directive in the go.mod file can redirect an old GitHub import to a new GitLab home without touching the code — and called the custom-domain routine a premature optimisation for a problem that rarely bites.

The sharper objection runs the other way: that owning the label is its own kind of trap. Commenter st3fan described what happens when a company dies and its domain lapses — the next person to register it inherits the names other people’s software now trusts. “You will never be as good as Microsoft to keep paying for the domain,” st3fan wrote. Another, SenHeng, put the same thought more gently: “GitHub is almost forever. Your custom domain disappears when you stop paying the bills.” And one more, p4bl0, pointed out that your registrar can become the problem itself — as domain owners found this month when VeriSign unilaterally deleted thousands of names.

So the honest summary goes like this: coupling your code translations to a single landlord is risky, decoupling them through a domain you must renew every year until the heat death of your career is risky, and the difference between the two risks is mostly a question of which bill you are more likely to forget to pay. Commenter thih9, unhelpfully and correctly, widened the blast radius: this is not even a Go problem, since GitHub links in code comments rot in exactly the same way everywhere.

Perhaps that is the real lesson, the one nobody at a hosting company will put on a billboard. Every dependency is a promise that someday somebody will keep paying the rent — and the only question programming ever asks is whether that somebody is you.