My Time in the fastlane: Building an Open Source Community
Shortly after I started working at Twitter, fastlane and its creator Felix Krause joined our team. fastlane is a set of open source command line tools that help iOS and Android developers build and deploy their apps to beta services and the app stores. fastlane has had rapid adoption and has frequently grown at a rate over 2x per month in the past year.
By adding fastlane to Twitter we are able to help an even larger set of mobile developers ship great code. I was invited to join Felix and a set of internal engineers to manage the continued development and community adoption of fastlane. My role as a developer advocate for fastlane has been to build and foster the community while making sure that our users are as successful with the tools as possible.
To put fastlane into perspective, it:
- Has more stars than the Ruby language itself on GitHub. (10,300 stars )
- Has saved over 3,500,000 developer hours (that’s 2,000,000 soccer games or 1,600 developer years)
With such a rapid rate of adoption we’ve seen explosive growth in community discussion. The way fastlane’s community interacts with each other is focused around GitHub issues and pull requests. These discussions serve as the ‘town square’ and are a place where developers share their pain and successes with both one another and the core team. At a personal level, I love seeing a living breathing community.
With the product adoption rapidly growing, the community has grown too. In April we saw around 20 GitHub threads updated per day. Today we see over 60 most days. To make sure we stayed on top of this we needed to develop a mission and approach for our open source community.
Our mission for the fastlane community is to help mobile development teams automate their builds and deployment. While this seems straightforward, once we set out with this goal we realized it was much more complicated. Our tools don’t have infinite scope, so they can’t solve every possible problem. Even if we focus only on iOS build and deployment there is a lot of ground to cover. Our inbound community discussions range from problems with setup (40–50%), feature requests (20–30%), actual bugs (20–30%), and finally pull requests (~10%).
We’ve thought about adopting external tools to manage our community. GitHub has limitations as far as a CRM, including limited labeling, no private file sharing, and limited sorting. However it offers some great things. First and foremost, it is where our community already is, we didn’t want to force fastlane users to adopt a new platform just to communicate. It also forces transparency — anyone can see our full community discussion. Even more importantly, GitHub is where our code lives, the interlinking of community discussions and PRs makes our team move faster and brings the testing of PRs to life.
We’ve taken three big steps toward building the fastlane community on Github. The first is organization, with an intensive labeling system users are able to help each other. We’ve also recruited users to contribute both help and code to our project. Finally, we’ve launched some automation features to help us direct our attention where it’s needed most.
First we learned that a strong labeling system was important for fastlane. Because fastlane has over ten distinct tools, we needed a label for each of those. This is really important because it improves discoverability, by labeling things properly by tool they become much more searchable in the GitHub UI. This increased cross chatter between members of our community. Initially the newly combined discussion helped find patterns and identify bugs. As time moved on, the community started helping each other organically. In almost all cases, we’ve found having fewer individual threads around a discussion has sped up resolution time for our users.This is because we can get information faster and decrease the signal to noise ratio of errors.
We also needed a label for each thread type: question, feature, bug, and help wanted. By separating these out we aid the team internally. Generally something will start out as a question. This label is used when we are able to provide documentation, code snippets, or other help on the thread to get the user back up and running. We also use this when we aren’t sure what the user was trying to accomplish.
If the user is trying to do something that we don’t currently support, it becomes a feature. We encourage community involvement on these threads to see if other users are interested in seeing that feature implemented. We track these both internally too and use it for ideas of feature work.
The question and feature labels keep noise down on the bug label. When we find something is reproducible or affects many users we label it as a bug. Internally we have tool ownership by individuals so by crossing by tool name label, for example sigh and bug, the tool owner is able to find their current backlog.
With the labels in place, we realized there were several forms of valuable community participation. As mentioned above, some users started helping others on questions, before we could even get to them. They offered workarounds from similar experiences or good questions that led us to a quicker resolution. In cases like this, we both thank the user and encourage the help.
This experience taught me how powerful gratitude can be in community building. Seeing ‘frequent flyers’ helping others across our issues is awesome and contributes to our mission of helping users fast.
We encourage our frequent issue contributors and code contributors with gratitude and occasionally swag. We also provide them with other tools to make them successful as a fastlane ambassador. An example is a private Slack channel for people that are planning on speaking publically about fastlane and a deck with assets to help them get started.
Being an open source project, the scope of community involvement goes beyond help on questions. The community pushes actual code fastlane itself. As mentioned, we use the help wanted label to identify bugs and features we want community help with.
We’ve noticed that getting someone to commit code to the project really increases their engagement with the community as a whole. We’ve found it to be a truly worthwhile investment on our end.
Pull requests take a lot of time to test and reproduce and generally require the attention of a specific internal team member. Initially the community were frequently submitting new ‘actions’ which provided separate functionality outside the core tool set (like uploading to s3). We realized that not only did our team not always have the expertise to review and maintain some of this functionality, but we also weren’t able to quickly integrate them into fastlane.
The community has always wanted even more than we are able to implement. We quickly learned that not approving a PR because of product scope is really frustrating for our contributors. They can end up stranded on a branch or using an entirely local version of fastlane.
To make sure people don’t get stranded, and get them up and running faster with custom tooling, we created a plugin system. The plugin system basically creates a custom ruby gem that integrates with fastlane. We no longer have to refuse PRs because they are outside of scope, users can still implement similar functionality and use it within fastlane. This means a lot fewer no’s.
This has had an amazing impact internally because now we can focus on our core tooling rather than constantly expanding scope.
We want to find ways to make the process of getting help even faster. So we asked ourselves, where our users are when they decide to reach out. Most of the time, the user is at the bottom of a stack trace output so we added some info there. Now, when a fastlane user gets a crash while running a lane in fastlane, they see similar issues on GitHub right in the CLI. This works to both lead them to resolutions for questions but also helps us track down multiple people affected by the same bug. This uses the github API so it updates in realtime, which is really useful for new issues!
We also have a bot that suggests that issues are related to code signing if a person submits an issue that seems to be related. We found that about 60% of the questions submitted are code signing issues, so we send them straight to help guide.
Even with all of these steps, we’ve found that the GitHub community is tough to stay on top of. To keep things clean and focused on our active users if a thread goes over two months without being updated it gets a 5 day warning before being closed out due to inactivity. This allows us to give users time to get back to us, while still having a cleaner backlog.
We’ve really approached this cautiously to make sure that we stick to our goal of acknowledging every inbound comment. This has had the biggest impact on our back log of any effort and very rarely negatively inconvenienced our users. We reopen threads once a new comment comes in.
The community being built around an open source tool needs to be scaled quickly. By focusing on organization, community, and automation we feel we have a successful relationship with our community.
My goal for the future of fastlane is to put the community in the drivers seat. By supporting a transparent and well maintained community, we’ll allow new and old users and contributors to get and provide rapid help and improvements. Internally, we’ll work to translate the community’s voice into tools that are valuable across many use cases.