Donnie Berkholz's Story of Data

Adoption of software is a funnel

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

At our Monki Gras conference this February, the creator of Jenkins, Kohsuke Kawaguchi, gave an outstanding talk on building a community around open-source software.

(Aside: All the videos from Monki Gras are now online at RedMonkTV.)

One of the key concepts he talked about was lowering the barrier to entry for new users, with the great metaphor of a funnel. If you’ve ever heard of a sales funnel, it’s the same idea applied to adoption of software — a multi-step process, where failure at any of the steps kicks people out of the funnel, but success means they proceed to the next step.

In my view, the key point of this funnel metaphor is that the many small barriers to adoption are not independent minor factors. Instead, they’re additive and strongly interdependent, gradually ripping more and more of your potential users out of the adoption funnel.

Let’s take Red Hat’s RHEL as an example, and consider how this affects RHEL’s ability to get developers building software on its platform. Imagine that we start with 100 developers who are thinking about basing development on RHEL. I drew a picture to illustrate how many of these 100 might end up actually developing on RHEL, based on a funnel (with each stick figure representing 10 developers):

Every time users hit a problem, some percentage of them will give up and move on to an alternative (colored red, above). In the end, you might end up with only 20 out of 100 potential users actually running your software!

So when you’re thinking about the developer experience and how to get more developers running your software, think about the funnel. Here’s the 15-minute video of Kohsuke’s talk:

Disclosure: Red Hat and CloudBees (which employs Kohsuke) are both clients.

by-sa

3 comments

  1. The funnel metaphor is quite good. Some research is definitely needed to understand why people don’t join a certain project in order to understand the main causes and the actual rejection process. Nonetheless, this type of research has a major hurdle as it is nearly impossible to identify people who leave a project and it is even more difficult in the FLOSS context as you may never see these people even once. 
    To get back to the funnel, I think it could be used as some kind of model but shall be refined as it raises some problems. First, the funnel implies a sequence of obstacles (hard to download, register …) which then means that there is an order for these obstacles and it has also some connotations of ‘temporality’. This order may vary from one user (or developer) to another. One may be particularly interested in joining a community of users that are similar to him or her and may look at it first. Others (like experienced FLOSS developers) may first look at the development practices before deciding to join a project.

    Second, each of these factors (obstacles) has a different ‘slope’ in the funnel which means that they have a different strength in making people leave. In your diagram for instance, 2 people of of 10 leave because they can’t find the download, 2 out of 8 because of registration …. 

    It would be quite interesting to do some research and manage to get those numbers.  And the thing is that the numbers will probably vary from one project to another, making things a bit more complex …

  2. You may want also want to check out http://www.slideshare.net/xen_com_mgr/do-we-need-a-managament-theory-for-community-building … An example I used in that presentation was one variant of using a “community funnel” for visualizing the health of an open source community. I have used this model successfully for pitching areas of community development that need investment to my management team. Using funnels really helps explain how a community works, as the concept of sales funnels is well known and understood by business savvy managers, marketing staff as well as sales staff.

    It is also possible to map community metrics to parts of the funnel and use the funnel as a dashboard for community health. In the example in the deck, a software adoption funnel and a funnel for growing a developer community are overlapped, i.e. the premise is that some users will eventually become contributors.

    There are also other ways of looking at this: for example you can overlap a “community funnel” with a traditional “sales funnel”. The underlying idea here is that some users in an open source community can be sold support or can be converted into sales of a commercially availabele distro of the software the community produces.

    There are also other ways of looking at using funnels in open source. I have also used a number of other models for specific aspects of community, but have not publicly presented these.

    In a nutshell, we are missing an underlying theory of community management today. On the other hand quite a lot of techniques from different management disciplines intersect with community management and could be adapted.

  3. I thought Kohsuke’s description of people going from, ‘visitors to users to developers’ was a very simple, helpful description of the journey that the most active members of his community had taken.

Leave a Reply to Lars Kurth Cancel reply

Your email address will not be published. Required fields are marked *