Looking for contributors in the open source world

Chris Blizzard recently posted an interesting article "open source is a side effect" in which he discussed the problem of encouraging the growth of open source developer communities in India, and by implication in other countries outside the so-called "developed" world. This is a subject of interest to me in my Mozilla Foundation role, because I think one of the Foundation's goals should be to help grow the Mozilla community, especially in countries where there aren't currently a lot of Mozilla contributors. In general I think Chris comments are spot on, but I wanted to add a few comments of my own.

First, I agree with Chris's diagnosis of the basic problem in attracting people in India and elsewhere to become active open source developers, namely that at these countries' present stage of economic development almost all software developers and related IT professionals are primarily concerned with making enough money to provide themselves and their families with a middle-class lifestyle, and have little time for activities like volunteer open source development that have no immediate economic return.

This is basically an application of Maslow's "hierarchy of needs" theory to open source software development (not a new insight, of course--Eric Raymond mentions various people making this point in response to his arguments in "Homesteading the Noosphere"). People aren't motivated to do open source hacking until they satisfy their basic security needs and are then free to address other needs, such as the need to feel part of a larger community, to have the esteem of others, and to make the most of their own abilities.

I also agree with Chris's point that the way around this problem is simply to forget about trying to recruit large numbers of people, and instead to focus on that (possibly quite small) group of people who have a passion for technology and a potential interest in applying that passion in an open source context--in essence, people who have in their own minds moved beyond just worrying about how they're going to earn their daily bread, and are looking for rewards other than financial ones.

This approach in turn relates to two useful ideas from the world of business. The first, from my past work as a "sales engineer" supporting software sales groups, has to do with the nature of the "sales funnel" by which (at least in theory) a large initial set of sales leads is winnowed down to a smaller group of qualified prospects, which in turn results in a smaller number of sales being made.

Obviously one possible way to grow sales is to get more people into the front end of the funnel: send out more direct mail, run more ads in magazines, attend more trade shows, make more "cold calls", and so on; another is to "close" more deals at the other end of the funnel by more effectively persuading people to buy something. However it's common wisdom among more effective salespeople and sales managers that the most important task is rather to address the middle part of the funnel, by determining as early as possible whether prospects are able to and likely to buy something, and then immediately dropping unqualified prospects and spending no further time with them.

Persistence is typically lauded as a supreme virtue in sales, but in many ways the worst thing a salesperson can do is to pursue a deal where the prospect appears unwilling to buy for whatever reason; it distracts the salesperson from other opportunities that might be more likely, demoralizes SEs and other people supporting the sales process, and greatly increases the risks of deals going sour later (should the salesperson actually succeed in getting the prospect to buy something).

This applies to our role as "open source recruiters" as well: We should have no compunction about aggressively rejecting people as possible candidates for recruitment to our open source projects. Yes, we need lots of people who can help, but it's far better to have little or even no help than to have help that's unreliable or inconsistent due to a fundamental lack of interest on the part of the people helping. As Chris put it, "The question should not be about 'how many' so much as 'who'."

This in turn leads me to the next business idea I find relevant here. In his book The Innovator's Solution Clayton Christensen recommends that investors in new businesses "[be] patient for growth but impatient for profit" (p.236). Being "impatient for profit" forces a company to rigorously evaluate which of its products are capable of actually sustaining a business, and then to concentrate only on the most successful products. Early profit also builds a foundation for future growth by allowing investment of profits back into the business.

In trying to recuit new people as new open source contributors our "investment" is our time and energy, and our "profit" is in the form of substantial ongoing contributions by new recruits. As Chris notes, going for mere growth in terms of numbers of contributors is not important (and can even be counter-productive), what is important is that we pursue approaches to recruitment that maximize the return from our investment in time and energy. If we can find successful ways of doing that then the growth will come eventually, and the power of compounding ensures that even a small growth rate sustained over time will eventually result in a large and thriving community.

Comments

Iang wrote at 2006-02-14 11:29:

Certainly being quick to move on to more profitable leads is valuable, but how one picks these leads remains the question. If we knew that we wouldn't be having this conversation!

How to pick a good open source contributor is much like picking someone for any club. Do you want someone just like yourselves? Or do you want diversity? Do you want someone with skills or are you ready to train up from the ranks of eagerness?

Do you want the best? Or are you going to make the best? You can't have both. Or, is "best" not really important, something else is important?

When I think of who to bring in to open teams, I tend to use self-selection a lot. Who cares about the mission, enough to stay the course? Enough to take some knocks and be still there the next day? To do this, you would have to cast the net wide enough, and spend enough time chatting to the people out there. To find out who cares enough to take some time, patiently and consistently.

Of course, an underlying assumption here is that we know who we are. There is no point in trying to recruit people to our club if we don't have a good grounding in what it is the club is about. We need our own mission, our own sense of shared understanding, before knowing who else to invite in.

Mozo's mission might be to give people a choice in browsing - at least I've heard that a lot. Is that enough to define who you are? Try it on the programmers in India - they might care, they might not. Then, ask yourself whether their reaction is aligned with your views as to who you want. Chances are it is pretty close.

Trackbacks

Hacking for Christ mentioned this post in ""How To Be A Good Mentor"?":

There are multiple documents on how to write good bugs, documents on how to release software, and even documents on what to call your computer, both serious and humourous. But has anyone written a document on how to be a good mentor to a contributor who has joined a free software project? I think one is sorely needed. Once we've picked the people we want as quickly as possible, it would be good if everyone knew the best ways to encourage them......

wakeless.net mentioned this post in "Clubs and Open-source":

Franck Hecker, Gervase Markham and Chris Blizzard have all been talking about ways to get more people involved in open-source....

Submit a comment

Please enter comments as plain text only; no HTML tags are allowed. All comments and trackbacks are moderated, and will not be displayed until approved by the moderator.

Comments are closed for this story.

Trackbacks are closed for this story.