I gave a talk at Limewire last week, and my talk rambled around to crowdsourcing and Free Software. The point I made then, and the one I’m making now, is that when it comes to making software, crowdsourcing is a myth. There is no project built by a multitude of people each making a few small changes and additions to a codebase.
When I was a kid, I played Tetris until I saw falling tetraminos every time I closed my eyes. Likewise, almost every Free Software project has a few people that see code when they try to sleep. These folks make a series of big contributions, and they’re usually the source of the vast majority of productivity in the project.
The crowd, those drive-by contributors who fix one shallow bug and then disappear, have relatively little impact, even cumulatively.
Despite this, most projects recruit developers by dangling shallow bugs and todo lists of easy-to-implement features. Many even offer to help people fix those shallow bugs, just to get them involved. It’s a lot of effort, probably more effort than it takes to just squash the bugs and implement the features. The hope is that today’s drive-by bug hunter is tomorrow’s big contributor.
This model is broken. Projects spend a lot of resources to get worse code (veterans are better contributors than newcomers) and the low conversion rate means they’re rarely paid of with bigger, better, and more contributors.
People who care about Free Software efficiency might want to think about how to increase the conversion rate. More importantly, it’s time to dream up ways to get large contributors other than by slowly growing them from small ones.
Many of the leaders of today’s GNOME project got started through the bugsquad- whose exact model is ‘small, easy contributions so you can get your feet wet.’ So… I can’t speak to the general case, but at least for GNOME, this model has worked quite well, multiplying the effort of people who supported it (primarily me) many thousands-fold.
I don’t want to overstate my case here. I’m not saying the current model never produces good results, and certainly there are projects where it works well. I am, though, saying it’s quite inefficient, and I’m aware of multiple projects that don’t get net benefit from bug squads as a recruiting tool.
Like everywhere else, we need to be able to try other approaches, to figure out what works well for a specific project. But I don’t see a lot of people doing that.
Sure. I think part of the success on GNOME’s part was that bug work was sincerely viewed as a real contribution in and of itself, not just a recruiting tool (which of course made it a more successful recruiting tool.) I agree that scattershot ‘I’ll just cross my fingers and hope a crowd fixes all my problems for me’ rarely works.
As someone who has as a programmer always had to work on someone else’s code, I think the real answer to this is not how can we find big contributors. Instead, I think it is better to look at how you can make your app/library as pluggable as possible. This doesn’t traditionally sit well in terms of user interfaces and the like, but in terms of development, if you make it easy for someone to write new code, then you exponentially raise the potential of finding a helpful contributor. Take Firefox for example. The number of core developers is relatively small compared to all the people cranking out extensions. Likewise, jQuery is another project with massive amounts of plugins, yet a rather small core group who work on the code. I’d argue the same is true for Ruby, Rails, Eclipse and even Apache.
The point being if you make it easy to write new code there are better opportunities to get involved in the code. Likewise, learning the core code becomes a much faster process since you have your very own code that you’re invested in.
Eric,
You are, of course, correct. One way to get new contributors is to give people an API that lets them contribute without ever joining up. No walls to break through, no lines to cross, no worries about fitting them into your structure, etc. It’s very clean.
I was thinking more in terms of the core itself, but that was foolish. Thanks for the reminder.
Hrm, Clay Shirky has a different perspective
http://www.youtube.com/watch?v=sPQViNNOAkw