Last week, on his blog, open source software analyst Alex Fletcher highlighted ease of participation as an indicator of successful projects, and asked whether providing incentives is the answer for projects seeking more collaboration. The short answer is yes, but I think it’s also got something to do with barriers. In fact, surprisingly enough, I think that many of the ideas known intrinsically by most salespeople can be used to increase open source participation.
After all, for the most part, sales is all about eliminating barriers. If there are 100,000 potential customers for your product, 10,000 might have a genuine need for it and the necessary money to buy it. Of that 10,000, 1000 might actually decide to contact you about your product, 100 might decide they want to buy it, 10 might actually purchase it, and eight might actually keep it without returning it. This is metaphorically described by some as the “sales funnel.”
Customers at each level of this funnel are confronted with a barrier that prevents them from advancing further, and the job of a salesperson is to eliminate those barriers. “Don’t think you need it? Here’s a study that says you do.” “Costs too much? It’s on sale.” “No money? Zero down, no payments for ninety days.” I’ve been on the receiving side of the process enough to see that it works on me — if I don’t have a reason not to buy, I generally will.
In open source software development and consumption, the barriers are different but I think the metaphor still applies. If 100,000 people are exposed to the project, how many will download it, install it, run it, use it, and care about it enough to get involved? And, more importantly, how can we eliminate barriers to their involvement?
The first step for projects seeking participation is to break down the barriers to consumption. In other words, widen the top of the funnel. Solve a problem that needs solving, solve it on as many platforms as possible, and make it really easy to download and install.
How many times have you thought a project would solve your problem, but discovered it doesn’t run on your platform? Have you downloaded a project and unpacked it, only to find out that it was a source package without a straightforward build process? Or, once you got it built, found that it didn’t suit your needs at all? If your answer to any of these questions was “Yes,” you got caught at the very top of the funnel.
Alex writes, “…an open source community cannot be considered a success unless it engages members [current or potential] to a point where participation is a natural continuation of the experience,” and I totally agree. I think that given the right conditions (and absence of barriers), everybody will contribute a certain amount based on their individual dispositions.
At this point, I’ll be honest. I’m not much of an open source contributor these days. I’m willing to file a bug report, post a forum message, or validate that it works on my system, but that’s about all. Still, any time Firefox crashes (which is rare) and it asks me to send a report, I’m willing to enter as much information as I can, but that’s about as much as I’m willing to do. I won’t open an email client or go to a web-based defect tracker, not even if they paid me, but I’m willing to enter some text when Firefox prompts me. Firefox has successfully eliminated the, “Should I bother filing a bug report when something goes wrong?” barrier for me and has made it possible for me to contribute in a way that fits into my workflow naturally, on my own terms.
Now let’s look further down in the funnel. Have you ever wanted to fix a bug or implement a feature, but found that the source was unintelligible, the testing unreliable, or the project’s approval processes were far too bureaucratic? If you’ve said “Yes,” you were caught again.
Projects like Gallery and Pidgin have eliminated the, “Should I implement this feature?” barrier by sporting extensible, plugin-based architectures. Developers who are willing to code and have an idea for a feature, but are unwilling to become formally engaged, can contribute to the project independently. Lots of larger projects have gone great lengths to produce clean code and have adopted test-driven development practices to deal with the “but I’m afraid to break the code” barrier.
So, yes, projects are doing well to ask themselves what they can do to motivate contributors. But first, they need to ask themselves what is keeping potential users and contributors from moving far enough down the “sales funnel” that contributor motivation enters the equation at all.