Software development is rarely easy. Even though some open source pragmatists suggest that Linus’s Law makes traditional schedules and planning obsolete, I remain skeptical. (I’ve worked on a few pieces of F/OSS in the past decade; I believe that I’ve earned a right to be skeptical.)

### Napkin Math

Assume a work week of 40 hours. Assume two weeks for vacation. That gives 50 weeks times 40 hours, or 2000 hours in a work year. For every two thousand hours of work you do on a project, you’ve accomplished a year’s worth of work.

Suppose I work on a free software project. Over the past few years, I’ve averaged five hours of work per week on this project. Some weeks I’ve spent more, and some weeks I’ve spent far less. As a volunteer, I’ve never received payment for my work directly on the project. (I did have one full-funded 40-hour week on a related project with modest overlap, have received payment for writing articles about the project, and have spoken at various conferences and events about the project, though only for free admission and never an honorarium nor travel reimbursement. By rough calculation, I’ve not even received minimum wage for my work. Over five years, all of the remuneration is less than ten percent of one year’s salary and less than five percent of my normal consulting rate.)

Five hours of work per week, at the standard rate of fifty work-weeks per year, mean that in one calendar year I put in 250 hours of work on this project. In three more years, my work over eight calendar years will have contributed about one developer year of work.

If I were to work on the project as my day job for just one week, I could potentially make as much progress as I would in two months. (That’s eight calendar weeks of work during the day and my standard five hours of developer work during evenings and weekends.)

That’s an estimate, but I suspect the gains could be greater….

### Latency

Those rough calculations don’t take into account a critical fact of software development. That’s no surprise; most software development literature overlooks the high cost of task switching as well.

When I reach the zone–when I achieve a state of flow–I perceive (however subjectively) that my productivity increases measurably.

More importantly (and much more objectively), when I set aside the project for the night, I have to perform a costly context switch when I take it up again the next night, or two days later, or three, … or a week. Having a solid block of two or three hours between breaks at work or meals and, more importantly, not having other work priorities occupy the greater portion of my time and resources between the task, has led me to less re-work and greater throughput when I’ve achieved it on other projects.

Contrarily, I have noticed that having time to think about a problem away from the computer helps me solve problems by forcing me to think better, not just to grab the keyboard and flail away. It’s not clear whether the benefit of thinking time between coding sessions overcomes the high cost of context switches. I suspect that it doesn’t; too many other problems also occupy my mind for me to give an 1/8th time project fuller attention.

### 1/8 * 8 = ?

The often-unstated corollary to Linus’s law is “Where do the enough eyeballs come from?

On a proprietary project, the number of eyeballs is relatively constant. It’s the number of developers. Though vacations and illnesses may make this number fluctuate, you can expect that if there are ten developers on a team, there are ten people working on the code on any given day.

Measuring the number of potential contributors to a free software project developed in the bazaar style is more difficult. It’s reasonably easy to enumerate the core developers to a point: count the people with commit access.

At any point, there could be zero or a million people poring over the source code, ready to file a bug, add a feature, submit a patch, or report a failing test. There’s no way of measuring this until some number of the potential contributors actually contribute. The potential certainly exists for the number of contributors to grow far beyond that of a comparable proprietary project, even if each contributor only contributes one item apiece. The possibility for parallelization of work across all users is a compelling pragmatic benefit for encouraging community-based development of the work.

However, it’s by no means a guarantee, nor is it free.

Very few projects I’ve seen rely on a completely decentralized structure. Even for projects which give out commit access to almost anyone interested, there is one single official tarball released occasionally. Someone has to have the authority to say “This is a new version of our project. We vouch for it.”

Even the most minimal shepherding of a patch from a new contributor requires reading through and understanding the patch, if not applying and testing it or pulling it from another repository elsewhere. Where the core committer might perform all of this work as a matter of course by developing the patch in the first place, the work necessary to verify the patch for the project’s own standards requires some overlapping work. Thus given two volunteer developers, one a core committer who puts in five hours of work every week and the other a new contributor without commit access who spends five hours producing a patch do not necessarily provide together ten hours of work.

Even given eight core committers who each spend five hours of time each week working on the project, I’m not sure this adds up to a single solid developer week–the latency and task-switching costs may shave off several hours of time.

### Slow but Good

I almost hesitate to mention this all lest anyone take away the idea that I believe as an immutable law of economics and software development that free software projects take eight times longer to develop (in calendar year terms) than do proprietary projects, or that they need eight times as many developers. I don’t believe that, nor am I trying to generalize my experiences to other developers or other projects.

If these rough estimates are true, it appears that even one sponsored developer could make a tremendous amount of progress on a project staffed entirely by volunteers. I won’t promise that there’s an eight-fold increase in productivity with this model, but it may be time to entertain the possibility that expecting high quality software written quickly and solely by volunteers may be unrealistic for projects above a certain complexity threshold.

Certainly community-driven development has some well-enumerated advantages over proprietary development. One of the most important is the potential for explosive growth in contributions. Yet it’s rarely one-off contributors who do the hardest work of shepherding large projects to success over multiple years. It’s important to keep a realistic view of how much those volunteers can accomplish working in their free time. Pun intended.