Why should I care about being charming?
The open source software community can learn a lot about how to attract new users and grow them into contributors and maintainers by thinking about their user journey, similar to how marketers and customer success teams think about new customers using “Pirate Metrics.”
A cri de coeur to start treating the “funnel to contributor” user journey on par with the “funnel to customer” user journey.
Background
“Startup Metrics for Pirates: AARRR!” which as far as I’m aware kicked off with a conference talk by Dave McClure in 2007, has held a special place in startup lingo ever since, and became a large driver of how marketing and customer success leaders think of the journey their customers take on their software platforms.
At a glance, pirate metrics are:
Acquisition: I become aware of your product and you become aware of me. Perhaps I sign up for a free trial or give you my email address to send me more information.
Activation: I actually use your product. Maybe I sign in on your platform and click around.
Retention: I come back to your product a couple times, continue interacting with it.
Referral: I tell other people to use the product. Maybe I add a couple co-workers to my project or account.
Revenue: I sign up for a renewing subscription license to your product.
And the name comes from the acronym: AARRR!
Anyone who’s spent any time in a software startup in the past … 14 years … has run into at least major pillars of software that were based on these concepts, if not the term “pirate metrics” themselves. Think of customer success software, on-boarding software, marketing tracking software -- all of these are focused on getting you to Activate! Come back! Refer a friend! Net Promoter Score (NPS) (introduced by Frederick F. Reichheld in 2003) gets irrevocably tied into the referral step - would you recommend our product to a friend? Then we get a passing score.
Extending AARRR
When I was at Chef, working on Habitat, we had an existential debate that will sound very familiar to many people who work on open source software: how can we prove that any of what we’re doing is of value to our company who is funding our work?
Traditional marketing methods based on pirate metrics only work when you own the entire platform and can meaningfully track outcomes. As an open source software project, one of our primary “calls to action” is “go to github and check out our code,” then tracking the success of that motion -- and whether anyone ever comes back to try out the products that actually fund your paycheck -- gets problematic. You have a gap in understanding your user flows.
How can you prove that the money you spent sending five people to a community event like RustConf was beneficial to the company and not just a “personal development” expense? How do you prove that going to Kubecon and having engineers and product people staff your booth and explain your new technology to other attendees is better than a sales led motion?
Having data in this space would be incredibly valuable to the ecosystem of enterprises and startups who fund significant investments in the open source space. Being able to connect marketing spend to upstream project engagement and awareness would help push the conversation between product and marketing as to where to spend dollars in a much more productive direction.
And then we get Charming
Something I used as a framework at Chef for pushing how we understood our upstream investments was to re-frame pirate metrics for an open source project. So I put together a funnel sort of like this:
This framework has a number of exit ramps. You will have many more users than contributors; you will have many more contributors to configuration scripts and docs than to large distributed system functions. Failure to graduate the various stages doesn’t mean your project is unsuccessful, however, if you are an ecosystem/platform technology and everyone’s exiting without contributing, you’re missing on an opportunity to build a base of huge advocates for your technology. People show up for things they helped build and were included in ways they won’t show up for other technologies. If you can make the ramp from first touch to maintainer as smooth and pleasant a journey as possible, you give your technology a significantly better chance of success, because you are building a huge network of people who have a personal stake in you winning.
This doesn’t mean you have to make everyone a core contributor to your hardest technical challenges. It does mean that if you can figure out a space that is easy to contribute to (Chef Cookbooks! Helm charts! Habitat Plans! YAML! Docs! Language Drivers!), and you iron out and maintain that space and think about the new user journey there, you have a real asset that many people overlook or don’t bother to build.
Different open source projects do a good job at some parts of this funnel. For example, Chef Software did an excellent job mapping out points of integration that new open source contributors from the systems administration world could come in and feel needed and welcome, i.e. cookbooks and Habitat Plans. These spaces were intentionally designed, curated and guided by friendly community engineers who would help you get started, use the technology, and contribute back.
Kubernetes may not do the first touch / new user experience well, yet, but once you’ve jumped into the community (somehow made it past the first two steps in the funnel) and learned how to navigate the SIGs and Working Groups, you’ll find well run spaces to meet people who are trying to solve challenges similar to your own, and their Contributor Experience group (SIG Contribex) is a friendly space staffed by volunteers who are constantly working on making the large community function well for people of all levels of engagement. They also have excellent automation and coaching capabilities for the next funnel steps.
While mapping out these contributor funnel steps may seem like common sense or obvious, think about most open source projects that you engage with today, and ask yourself: have they really ironed out all of these steps? If you go to the average readme of any project, what you normally see is a bunch of boilerplate information about licensing. But what a new user needs to see is:
What problem does this project solve for me
How do I get started as a user, not as a maintainer
Where can I find help
As your community starts to scale - or even attract just a handful of interested users - you will quickly see your top maintainers start to be overwhelmed by casual questions and having to make major tradeoffs between basic new user support and actual critical feature delivery. This is where you need as a business to begin the necessary work hiring a community engineering team. A great community manager can start welcoming in new users and make sure they have a great first touch experience with not only your technology, but also your community. Think of them as a customer success manager for your open source investments. Many open source projects have even experimented with NPS surveys for this very reason. Scaling out your team with the addition of an appropriate number of community engineers -- engineers who can maintain and document core integration surface areas (APIs, clis, UIs, project websites), be responsible for working with key partners to help them scale on the technology and grow the ecosystem, and who can guide new users on their maintainer growth journeys.
Automate everything you can -- but remember that when it comes to becoming a maintainer and contributor, these people start to hold real power and impact over the future of your technology investment. Would you hire a new engineer and give them admin rights on your servers without an interview or a background check? Then why do people think this is going to work out well on contributing code to key pieces of infrastructure on a volunteer basis?
In summation
We need to treat the “funnel to contributor” on par with the “funnel to customers.” Billions of dollars has been invested and spent in tracking new customers. Billions of dollars have been spent and invested in open source technology around the globe. Almost nothing has been spent in understanding and measuring the contributor journey. We’re missing out on an opportunity to make a significantly larger return on our investment in open source technology. Let’s get on that.
