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.
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.
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
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.
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
gopassis 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
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
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.
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.
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
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
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
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
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
We’re also planning to polish the UX further, easing the useability for novice users.
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.