gddo

gddo is the Go module behind godoc.org, the community-run service that crawled public Go package repositories on GitHub, Bitbucket, Launchpad, and Google Code, rendered their Go doc comments into browsable HTML, and served as the de facto Go package index before the official module proxy and pkg.go.dev existed. It is structured as several importable Go packages — gosrc for VCS source fetching, doc for parsing and formatting Go documentation, and database for the Redis-backed package cache — wired together by the gddo-server command, which runs the actual web frontend and background crawler.

As of 2021 the project is explicitly archived: its README states that requests to godoc.org now redirect to pkg.go.dev and that gddo is “no longer accepting contributions.” It remains on GitHub as a historical reference and a working example of crawling, parsing, and rendering Go documentation outside of the official toolchain, but it is not maintained and should not be adopted for new projects.

What You Get

• A working reference implementation of a Go documentation crawler and renderer, split into gosrc (VCS fetching), doc (Go doc parsing), and database (Redis-backed storage) packages.
• The gddo-server command, a full HTTP frontend for browsing, searching, and viewing Go package documentation.
• Multi-host source fetching logic for GitHub, Bitbucket, Launchpad, and Google Code repositories.
• A gddo-admin CLI for managing the crawled package index.

Common Use Cases

• Studying how a pre-modules-era Go documentation service parsed and rendered doc comments from arbitrary VCS hosts.
• Borrowing the gosrc VCS-fetching logic as a reference for building a custom package indexer.
• Standing up a private, self-hosted godoc.org-style browser for internal or legacy Go code that predates Go modules.

Under The Hood

Architecture gddo-server/main.go implements an HTTP server whose handlers drive package browsing, search, and playground-style rendering; it composes the gosrc package (source retrieval from GitHub/Bitbucket/Launchpad/Google Code, each in its own file — github.go, bitbucket.go, launchpad.go, google.go), the doc package (parsing and formatting exported Go declarations and comments), and database/database.go (a 1300+ line Redis-backed store for crawled metadata and search state), with crawl.go and background.go driving a periodic refresh loop that keeps the index current. The layering is straightforward — server → business logic → VCS client → Redis persistence — but the per-VCS-host special-casing in gosrc without a shared abstraction, plus vendored dependencies checked directly into the repo, make it feel dated and somewhat tangled by current Go standards.

Tech Stack The module targets Go 1.13 and vendors its dependencies under vendor/. Storage runs on Redis via garyburd/redigo; configuration is loaded with spf13/viper; Go source parsing leans on golang.org/x/tools; and cloud.google.com/go’s logging, pubsub, and trace packages plus google.golang.org/appengine tie the service to Google App Engine, which app.yaml and the checked-in Dockerfile both confirm as the intended deployment targets.

Code Quality The repo carries 20 _test.go files spanning gosrc, doc, and gddo-server (gosrc_test.go, path_test.go, present_test.go, browse_test.go, template_test.go, pkgsite_test.go, and more), which is respectable coverage for a project of this age, and .travis.yml wires go test into CI. That CI config is itself a sign of the project’s age, though — it targets Go 1.10/1.11 even though go.mod declares Go 1.13, and it depends on downloading an App Engine SDK build via a Google Cloud Storage API call, infrastructure that has likely rotted since the project was archived in 2021. Error handling is idiomatic explicit-return Go; there’s no linter or formatter config beyond an incidental dependency on the now-deprecated golang/lint package used inside doc/vet.go.

What Makes It Unique Ahead of the official Go module proxy and pkg.go.dev, gddo was the tool that made “go get and read the docs” work across arbitrary GitHub/Bitbucket/Launchpad/Google Code repositories, and its design directly informed the service that replaced it. Read today, though, it’s a standard HTTP server plus Redis cache plus template renderer — historically significant, but not a technique that stands out on its own merits, and the project’s own README now points readers to pkg.go.dev instead.