How GoCenter Connects Go Modules Authors With Consumers

UPDATE: As of May 1, 2021 – GoCenter central repository has been sunset and all features deprecated. For more information on the sunsetting of the centers read the deprecation blog post

There’s no longer any doubt, Go modules are an accepted part of Golang. The over 300,000 versioned Go modules in JFrog GoCenter shows how they have been embraced for package management by the Go community. With Go modules now enabled by default in Golang 1.13, the number of publicly available modules will grow even more rapidly — and some of them may be contributed by you.

But once you share a Go module project with the community, what happens to it? Does it get used? We would all like our projects to become as useful and popular as testify or logrus, but how can you know?

When Go module authors know who is consuming their modules, what versions are more popular and within what domains, they can make better decisions. Authors can collaborate together to improve aspects like testing. Authors can engage with the consumers of their modules to discuss new features or design.

This is something that we always had in mind when we were designing the UI of the GoCenter public GOPROXY. GoCenter helps you to find versioned modules in its central repository, and also to know more about them once you do.

Using Used By for Go Packages

Search for a module in Gocenter, then view its modules page. Click the Used By tab.

The GoCenter UI shows every Go module version in GoCenter’s repository that uses the module.

Counting Downloads from GoCenter

The Used By tab tells you how widely your modules are being referenced by other modules. But how deep an impact is it really making? Click the new Metrics tab to see further statistics on the module, including the number of downloads of it were delivered each week.

How It Works

Now let’s talk about how GoCenter identifies these relationships. Building a version-to-version module  relationship is not straightforward. This applies to both dependencies and ancestors in a Used By graph.

For projects that have already adopted go modules, building a version-to-version module relationship is easy since the dependency versions are locked down in a `go.mod` file. However, that’s not the case for the majority of open source projects written in Golang. 

For projects that adopted other dependency managers such as glide or godep, the version-to-version module relationship can be captured via `go mod init` since this command also generates a `go.mod` file with dependency versions locked down.

In the example above, The Helm package manager for Kubernetes has not adopted Go modules yet but since they use dep, GoCenter builds the version-to-version module relationship using go mod init.

The challenging part is what to do when an open source project written in Golang doesn’t use any dependency manager, so there is no fixed versioning. In such scenarios, GoCenter runs `go mod tidy` (to explain in a very simple way) and captures the dependency versions along with the timestamp of when GoCenter ran this command. The timestamp helps GoCenter track the version-to-version module relationships as they change. GoCenter highlights this in the UI under the Mod File tab as shown in the example below:

The Power of the GoCenter Public GOPROXY

GoCenter is a public GOPROXY for open source Go modules that can help you accelerate builds of your Go apps. But it’s also a vital tool for telling you about those Go modules, and the relationships they have to each other. If you’re an author of Go modules, knowing who is consuming your projects can provide insights that can help your work, and that of the Go community, to continually improve.