Open source projects competing for manpower

By Andrew Smith

It’s that time of the year when people who have a life go live it fully, and people like me are left bored to death, cause their work is not as interesting :) So I looked over my to do when you’re bored to death list and found this idea – research, or at least articulate what I believe about how a limited number of volunteers can handle an ever growing number of open source projects.

The premise is simple – there is a limited number of people in the world who are capable, interested, and willing to dedicate their time to helping out open source projects.

I’ll expand on that a little. Here are the factors that affect this number:

  1. The total number of people on the planet.
  2. The skills required to do anything remotely useful for an open source project.
  3. The time and will to volunteer for an open source project.

I was going to put that into a formula, but I don’t have the patience.

Anyway, my point is that either we already surpassed this number, or we’ll get there really soon, and either way there is already tremendous competition for manpower in open source.

Projects ranging in scope from wordpress to the Linux kernel wouldn’t be worth my time thinking about if it wasn’t for the volunteers. Often it’s a small group doing the coding, sometimes there is a small group of artists and/or usability experts, a larger group of testers, and an even larger group of bug reporters and evangelists. Get rid of either of these groups and the resulting project will be either not working at all, or unusable, or very buggy, or with such a low rating on Google that you’ll never find it.

So to get an open source project you need volunteers. How does one make a project more interesting to volunteers than the competing project? It’s a science, you can be sure. I’ll put together a list of things I can think of right now, but it is highly unlikely to be complete, or even useful. Just food for thought.

Easiest first – choose a popular domain

What I mean is make your project useful for a large number of people, i.e. potentially everyone would use it – doing a job everyone needs done, working on all the platforms, with features rivaling the proprietary (expensive) software, and cheap (or even better if it’s free).

A project with millions of users will have self-sustaining communities of bug reporters and evangelists, that’s the really great part. Basically you don’t need to worry about this, unless you’re really serious – then you can have a marketing department arranging all sorts of competitions and other events for the fans.

Harder – a good social environment for sociopaths

One of the things your project needs that I mentioned is serious testing. Very few normal people will use alpha/beta/rc versions of software if they don’t have to. Some will, and depending on the popularity of your project you will get a few or a few more volunteers to do this testing, but never enough.

An obvious solution to this is to do what some projects do and have no releases, at all – have the users or the distributors get the software straight out of the version control repository. You don’t want to do this. Unless you have no competition at all your users won’t stick around to put up with your broken-forever software.

What you really want to do is create the infrastructure where the geeks (the abnormal people who will use alphas) will get to communicate with other geeks, brag about their accomplishments, complain violently (but about things that won’t offend anyone in the group), etc.

Basically you want to give the geeks a life. And in return all you ask is that they keep using pre-release versions of your software and file bugs.

The tools to build this infrastructure are well known – IRC, forums, newsgroups. But it’s not as simple as build it, they will come. They would come, but also would a bunch of trolls who would make the imaginary life a worse ordeal than the real life. You need serious moderation, you need to identify and single out the unproductive trolls, and exterminate them with big bangs.

To do this properly you need a person working full-time on this part of the project, and it’s unlikely a volunteer will be willing to constantly do the dirty work.

Hardest – you get what you pay for

One may argue about how critical the testers, bug reporters, and evangelists are. But one must be out of his mind to argue that the programmers developing the core of a product are anything but priceless.

You will never form the groups of people to support, promote, and grow your program if the program isn’t there to begin with, or if you can’t fix critical issues quickly, or if the code is so foreign to all working on it that new bugs get added quicker than the old ones are fixed.

You absolutely need programmers working full time on your program. If it’s small enough and you have the ability to sustain your lifestyle by other means, you can do this job yourself (assuming you’re a programmer). But the larger and more complex the program gets, the more coders you need to take care of it.

Sadly most companies go with hiring rock stars, but I already complained about that, and the fact is – it works. The point is, you need one or a team of capable coders to work full-time on supporting the core of your product. You may allow some features to be done by volunteers, but only because you can do just as well without them.

So you need to hire exceptional minds and offer them whatever remuneration they will find most valuable. It may be interesting work, fame, a great team, but one thing is needed for sure – money. So no volunteers.

Now I realise I’m getting too far from what I started to write about, but I’m too tired to make corrections. So I’ll just add a couple of points.

It is physically impossible for all open source projects to be fully staffed, there aren’t enough qualified people on the planet who have the time. Open source projects compete for the volunteers, and the ones most successful at this get more of everything – more quality, more promotion, even more features. The ones who do it worst die quickly, or stay afloat on the maintainer’s back until a competing project takes over the scene.

Naturally this doesn’t apply to all projects – there are plenty of programs like ‘ls’ which don’t have, nor do they need, volunteers, they are so small and so low-maintenance that a part-time maintainer will keep it in tip-top shape for a long time. So don’t worry if you have a tiny open source project – I wasn’t talking about you. Except of course.. just you wait till you have enough bills to pay :)