There is some complexity here. Go is one of the few programming languages with a fully-decentralized module system. I can upload a module to example.com, and you can use a module from example.com with no centralized coordination. This is very different from systems like Node/npm or Perl/CPAN, where if you want to write a module, you have to beg them for permission first. (This is a moneymaking opportunity, too. You can charge people for your package system if they want to keep their code private. And npm does! With Go, you can have private modules for free!)

There end up being some problems with this model. Popular modules might be hosted on some server that can't stand the load, and if you can't pull dependencies, the entire module system breaks down. So, you probably actually want the modules on a CDN, because high availability is important for CI systems. Before Go automatically pulled from Google's module proxy, I had my own. I had to, because Github rate-limited our pulls (and when it wasn't rate-limiting us, it was slow). Setting that up was a few hours I had to spend for no good reason -- it didn't make my product better, except by making some incidental step between idea and deployment slightly faster. You can of course vendor your modules (now your git clone is slow), or add caching to your builds (go's caching is very good, but doesn't play well with Docker). All of them take your time and mental energy to do something unimportant. So, Google made a module proxy that Go pulls from by default. It works every time. It probably costs them almost nothing. There is no business value in it. Google doesn't need Go for anything. They just have some employees that want to improve the lives of average programmers. You can turn it off. You can host your own -- go/x has an example proxy, and there are full-fledged open source projects that add more features (Athens). It's actually a very good situation. You can be as centralized or as decentralized as you desire.

Going back to centralized package databases, they do have some really useful features. The main one I use is looking at users of a package that I'm reading documentation for. No example code in the repository? No problem. You can go see how other people are using it. The problem there is getting a list of all possible packages. You can poll common repository hosts for them. You can convince everyone to use a certain proxy that gets the names of the modules you are using so you can go index them. That's what Google does, and the user experience is great. You trade Google the information "the IP address 1.2.3.4 uses github.com/foo/bar" to get the knowledge of every Go module in the world. Seems like a good trade. And you can easily fork go and tell it to use your proxy, and make your own package database. The code is open. The license allows it. Go for it!

Would it make more sense for Go to be owned by something like the CNCF instead of Google? Sure. But they did make it, so it's kind of their choice. It is pointless for a large company to make a brand new programming language, but they did it anyway, and it's nice that we have it. They give us lots of free stuff and ask for nothing in return. The fact that your CI system pulled a Go module is not something that advertisers are salivating over. If you want to hurt Google because you don't like them, ask your lawmakers to make advertising illegal. That would show them! But caching Go modules is not a big moneymaker for Google, it's just kind of a nice thing they do because a few employees thought it would be good. I appreciate it. If you don't, set up Athens and forget about them. I am sure you can render godoc just as nicely as pkg.go.dev with only a few hours of work. The thing is, it's boring and nobody would care.