gopass - 1k GitHub stars later

About ten months ago, we released gopass into the wild, a complete and mostly drop-in capable rewrite of pass, which we used to lean on heavily before. With a renewed focus on better team capabilities and great user experience, we opted to cater to an audience of professionals — more on our reasoning in our initial anouncement.

Fast forward ten months, and we crossed the mark of 1000 Github stars, making gopass one of the more popular open source password managers — used and trusted by thousands of individuals and companies worldwide.

When we decided to release gopass to the public, we had no idea how well it would be received. Since we crossed the mark of 1000 GitHub stars a few days ago I’d like to look back, draw some lessons learned and try to give some outlook into the future of this project.

Measuring adoption

If you put a lot of work into some project, you may ask yourself if this is actually useful to anyone. We definitely were interested if we were on the right path and if we did something people liked.

As gopass is intended for a security conscious crowd, it’s pretty clear that we can’t use any kind of phone-home telemetry to collect usage statistics. The only web-enabled functionality is the gopass version command that makes a request to the GitHub API to check for the latest version, but we don’t get any information from this and we have no idea how many people actually use this command.

We could count the number of downloads from the gopass website but that wouldn’t too tell much either.

So the best we got are public GitHub metrics, like number of Stars, Forks, Issues and PRs.

As we crossed the mark of 1000 stars we wanted to recap how we’re doing and how we want to go on.

Putting things into perspective

GitHub has an amazing search and a GraphAPI. This allows us to explore the Octoverse a little bit.

• There are about 2M projects with more than 1 star
• Only 12k have more than 1k stars, that is gopass is now within the 0.6% most popular GitHub projects!
• The initial public release of gopass was on 02.02.2017, i.e. 306 days ago
• We got about 3.4 Stars per day
• We’ve got a new issue almost every day (0.71)
• There were even slightly more PRs than Issues (0.89)
• We had at least one commit per day (1.22)
• On average we released a new version ever other week

Motivation

Why did we start gopass in the first place?

Simply speaking, we were feeling to start the limitations of pass, our password manager of choice in the early days. Trying to extend the original bash codebase proved to be more challenging than any of us expected, and finally Matthias wrote the first few lines of a Golang based clone in his spare time.

Out of an exercise in pure curiosity, our team saw that getting to interface compatibility was feasible and we decided to give it a go in order to implement some of the features we always wanted — but first we had to catch up a lot of hard work by the pass developers.

We knew that it would take considerable time and effort, but we decided to do so anyway. The primary reason was definitely that we felt the need for such a tool and the available tools either didn’t satisfy our requirements, or we had trust issues with cloud based offerings.

We also wanted to contribute a to the broader open source ecosystem and at the same time give a little insight into what we do and how we do it. Since we have no commercial interest in selling software, it was a rational decision.

When considering how we would run gopass as an open-source project, we gave it some serious consideration. Should we run it as a personal project in on of our private GitHub accounts and dedicate some company resources to it, run it under its own GitHub organization or under the umbrella of our companies’ GitHub organization?

Since this project is a lot about security and trust we came to agree that it would probably leave the best impression to run this as a company project. That way our users can relate gopass to a great product they probably already know and use. Also you can easily find out who we are, what we do and meet us at meetups or conferences.

Lessons learned

When we released gopass, we took a lot of effort to prepare properly, but still we missed a few things and in the end it was a quite interesting experience.

After the code for the 1.0.0 release was finished, we took about two weeks to polish code and documentation, set up a website, prepare releases and organize some PR buzz for the initial release.

In planning the release, we made a timing blunder in releasing on a Thursday, i.e. shortly before a weekend. In our effort to display responsiveness to the public, we created a lot of stress in the team. This is generally OK, but not something you want to have on a weekend where at least some team members were not available.

After this initial burden, the workload from this project faded a little, but it takes some serious effort to respond to all the issues and PRs in a timely manner. Even without any new features we spend at least a full day per week working on gopass. Usually more or less evenly split between office hours and spare time.

Eventually we noticed that building releases required lots of tooling, some tribal knowledge, privileges and only one or two team members were actually able to push out new releases - if everything went well.

Taking an example from Dist::Zilla, I started looking for similar projects in the Go ecosystem and finally found the helpful Goreleaser.

We had to apply a few tweaks to it and still need to manually update the generated changelog entry on the GitHub releases page, but otherwise a new release can be built from a clean source with a handful of commands. This includes updating our website with any changes from the gopass repo.

Did we deliver upon our initial promises?

When we started gopass it was clear that we’d need to provide a migration strategy if we wanted to attract any users. So one of our first milestones was feature parity with pass. We achieved that (mostly), but made a small mistake that led to some issues being opened. When implementing gopass we worked with a slightly outdated version of pass (coming from distribution packages), so when we finally reached feature parity and stated so, we didn’t actually meet feature parity of the latest released version of pass. We added some of the missing features but after a while, most of us just didn’t track the development of pass anymore because we were all using gopass exclusively.

Acknowledgements

There has been a lot of initial feedback after the first announcement but also a quite steady flow of various contributions. The whole list of contributors can be seen in the GitHub repo and issue tracker, but I’d like to highlight a few individuals.

• Matthias for starting gopass and creating the very first useable version
• Philipp for spotting and fixing lots of small mistakes
• Sebastian for the website design
• Vincent for the awesome logo
• Christian for the password strength features
• Martin for the browser integration
• Aaron for the OpenBSD support
• James and Matthieu for lots of excellent bug reports and feature requests

Future work

Right now gopass serves us pretty well and we miss very little features. One thing that we’d definitely want to add is something we call store integrity but unfortunately this is not only difficult to implement but also hard to get right (crypographically).

We’re also planning to polish the UX further, easing the useability for novice users.

Closing words

We hope you enjoy gopass as much as we do. We appreciate any kind of support as well as the occasional thank you.

This post was brought to you by Dominik Schulz, Head of Infrastructure, core maintainer of gopass.