Keeping Important Go Packages Alive
Announcing: The Gofrs
One of the biggest benefits of using the Go programming language has to be the number of third-party packages available for different things. When needing to find a package for doing something like generating UUIDs, you head on over to https://godoc.org/ and use the search function to look for a package that contains a keyword of what you’re looking to do:
Enumerating the packages available for you is the easy part, the one problem we’ve yet to solve as a community is a good way to assess the quality of a package. Is the package bugfree and still being maintained?
A Quality Package
Over the past two years I’ve become more involved with certain areas of the Go community, specifically with the Slack workspace. One of the biggest types of questions we field in the main channels are people asking for recommendations on which packages to use in certain situations. They have a problem they want to solve, and want to make sure they using something they can rely on.
A common issue we’ve run in to are packages which are largely in a good state, but appear to not be actively maintained. So while we can recommend their use, we have a hard time making guarantees about the future. These packages often have quite a few issues and PRs open, with no visible progress being made on any of them. Sometimes the original author is looking for someone to take over maintenance.
A less common but more severe situation we’ve hit are projects that are widely used in the Go ecosystem, but that are no longer maintained and have open issues that make it hard to recommend their use. These projects are sometimes in the middle of a breaking API change, or they have bugs that make them unsafe in their current state. These often have issues and PRs on them asking for the project to find a new maintainer, and to be marked as deprecated.
One challenge that compounds the issues above, in relation to determining the quality of a package, are around versioning of the packages. Up until the last few years, package authors weren’t exactly encouraged to release their packages using semantic versioning. Because go get didn’t concern itself with versions, many saw no value in providing that type of information. That has been changing with the availability of tools like glide and dep, but it means that not all packages are versioned well (if at all).
While seeing these types of issues come up on a regular basis, I began to ask myself and others in the community about how we can improve either. Over a few discussions, we came up with a focused plan of attack.
The Gofrs
To help pick up the maintenance of packages that are heavily relied on by the Go community, a few of us in the Slack workspace have banded together to start a group we’re calling The Gofrs (pronounced like gophers). One of the challenges we’ve seen in finding maintainers for projects, is that one individual is generally not going to take-on the full project from another person. If they do, it doesn’t reduce the risk of the project becoming unmaintained again were they to become unavailable.
One goal of The Gofrs is to have a group of people maintaining these projects, while working together openly in the community. We plan to pick-up projects that are relied on by many, but appear unmaintained or are actively searching for a maintainer, and to shepherd them forward so that consumers can continue to safely use them. We also hope to start work on new projects that we feel would benefit the larger Go community. With the group working together to maintain these projects we hope to reduce the risk of the project becoming unmaintained, and to have diverse set of perspectives.
Our First Project
The conversation around creating The Gofrs was started after some issues were reported with the most popular UUID generation package in Go, https://github.com/satori/go.uuid. Specifically, the library was not generating unique UUIDs and had some breaking API changes that had not been included in a tagged release. Based on the open issues, pull requests, and current state of the repository, it did not appear that the original author was actively engaged. With this we decided to fork the project together, and to bring it back in to a good state.
To facilitate forking this repository, we felt it made sense to create a GitHub organization that we can use to group all of our projects together. We then forked the repository in to this organization, and renamed it slightly to be a little more idiomatic:
- https://github.com/gofrs/uuid
v2.x of gofrs/uuid should be API compatible with the current master branch of satori/go.uuid(36e9d2e), while including fixes for the critical bugs that made it unsafe for use. The decision was made to do a major version bump from v1.2.0 to v2.0.0 as breaking API changes had been made in the master branch of the upstream project after the v1.2.0 release. Please see our v2.0.0 release notes for more details.
We will be releasing a v3.0.0 soon, which will include proper JSON support for the NullUUID type as well as the ability to spoof MAC addresses in V1 UUIDs (if you’re concerned with exposing your physical device address in the UUID).
What’s Next?
We’ve not discussed this much as a group as we’ve been focused on getting our UUID package in to a good state. I think one of the first things we should do is get a simple static site set up on https://gof.rs. The domain has been reserved, but it’s currently not serving content.
How Can I Help?
If you know of a project that’s pretty widely used in the community in need of maintainers, please open an issue on this repository so that we can evaluate whether we’re a good fit to adopt it:
If you’d like to get in touch with us, you can find us on the #gofrs channel in the Go Slack workspace.
