I post a lot about my thoughts around Community OSS Software Development because, well, a lot of people who run projects /don’t/, so people have to guess about it, and I think there deserves to be a bit more out there, regardless of what people’s thinking processes are. (Learning what others think is good — I want to hear from other people doing the same too). So anyway, today’s theme — spurring more contributions to an established project.
Lately I’ve been taking a track of working on the major features that I want to work on, while encouraging people to do things that they want to work on.
This is can be better given another name “ignore the RFE (Request for Enhancement)” list (albeit for small items only, I know some of the hard stuff I’m still the one who needs to do it). It seems to be the right track — let people know who are asking for ideas that the queue of good ideas is already HUGE, and that you won’t be able to get to them soon, but it’s very easy for them to add what they want to add — even if they are relatively new to programming — and provide them a bit of help to get them going down that road. (I am lucky to have a lot of sysadmin users, who usually already know Perl and Python is just a small leap, or in many cases, already know Python… this is why I consider sysadmins to be the great awesome untapped OSS hackerbase — and it especially helps that they all seem to join me in hating featurecreep and having a good appreciation of simple code).
So far I think this is working — partially. I know that if I did everything, we wouldn’t get as many contributions, and as a result, the app would be less interesting because I’m onl only one person.
However other experiments — such as “Learn to Hack on Cobbler Week” did not go quite as well. I think we spurred interest in another 4-5 developers, but it wasn’t quite as huge as I had hoped, and I wasn’t busy with IRC questions about development all week at all. Maybe those questions didn’t need to be asked, but also most people are busy and really contribute on their own schedule. This is ok. The generated interest will kick in over time, I imagine. I think the code has to teach, not people, in some ways, further increasing the importance of simplicity and easy entry points. At least we learned something by doing this.
I am currently thinking that the way to get more contributors though, really, is and has always been to simply get more users — and rely on the fact that (depending on the app) you’re going to get solid code contributors from anywhere between one in 50 to 1 in 250+ users. Perhaps this is what I’m really using. I can’t be sure, but it helps.
This underscores the importance of making sure the codebase remains easily hackable, which is where I’ve been focusing my efforts almost exclusively in the last few months…. making things simpler, cutting out code that doesn’t need to be there, and in some cases, not doing features that will not be useful to more than 20% of the user base — because that extra weight increases complexity and therefore lowers the complexity of contribution. (Example right now — if someone adds a new field to a class, make it so they don’t have to edit the command line or the web application templates to make it show up — make it /just/ work).
In some sense, deprecation of features, something I’ve been very much trying to avoid, can also be good for keeping that small. Are there things only 1 or 2 people use that are not worth maintaining that can result in removing a lot of code infrastructure? Still, I don’t like to do this very much, having been burned many times in the past with supporting multiple JVM versions. It’s better to just find new ways to support such things and make the upgrade path as painless as possible, I think. Current users are future contributors and can share your app with their friends/colleagues (even at future places of employment), so it is up to you to ensure you keep them happy.
Another thing that is important is sharing excitement — do you blog about new coming features and do things to reach the user-audience that might not be on the mailing list (or post new features and thought processes to the mailing list?). A lot of projects can seem to “just appear” with new releases, and many users aren’t going to be following something as (relatively) obscure as the F12 feature process for seeing when a new cool feature will be usable by them, or how they can influence the planning of feature. Sharing that excitement and talking about the future is a very important social activity. A list can’t simply be a collection of patches and all business, for every project is really it’s own micro-community. This source of motivation about ideas can spark other ideas, and also sometimes new contributions — ideas, I maintain, are often just as important. Even if it’s just a subtle correction: “that would be better if”, you totally need that. I think a lot of projects could do better on the marketing/soft-skills in order to drum up that kind of interest. It is important to show that development is an open process and everyone can come to the table, and is welcome even if they aren’t going to share patches right away…. you never know what may come later.
In all fronts, how to increase contributions remains something of an art, not a science. I’ve been lucky and have about 70 or so contributors thus far (in code, many more so in testing/ideas/etc), though my goal in writing this is to share ideas with others about the same — and to see if we can’t pass on that knowledge to build larger communities around other things. I think the number that I have achieved is still much smaller than I’d really like… not bad… but I want more.
I will say it, community building is hard work. For me, “thank you, that is awesome” is some of the best motivation, and it’s even better when you can say “thank JimmyBob1984″ knowing those are some of the first software contributions you’ve made. To paraphrase the old saying, you can both do and teach 
More so, looking at the path of an application over many years and seeing all the unpredictable changes you didn’t plan, knowing you really have a hive mind thing going on and are tapping as wide a net for potential neurons as possible — is also fun to watch.
More succinctly, the “finding more contributor thing” requires a two pronged approach — (A) expand the userbase (conferences seem good for this, word of mouth builds on itself and kicks in later), and (B) convert users into contributors by enabling their path and encouraging their contributions by asking frequently and preparing the codebase and documentation for their arrival. I think folks sometimes do one without the other, and you need both.
