I recently had the opportunity to proof-read Martin Michlmayr‘s PhD thesis on release management in large open source projects. Martin is an ex Debian project leader, so he has personal experience. His research confirms what I believe to be true about the benefits of a time-based schedule rather than a feature-based schedule, based on GNOME’s release planning:
- Coordination: This allows sub-teams to coordinate their work, by specifying certain times when it’s most appropriate for them to do their work, and preventing them from interfering with each other.
- Decentralization: This coordination happens without much central coordination, because the schedule is known and reliable.
- Quality: This allows more features to be released in a suitable state over the long term, without finished features having to wait for not-yet-ready features.
- Modularity: This encourages us to question the suitability and stability of individual features rather than attempting to judge only the whole as all or nothing, and allows us to create a whole out of parts that are ready. The schedule encourages major long-term changes to happen in branches without disrupting regular development.
- Iterative Development: This keeps quality under control, because the difference between releases is small.
(This are my wordings of my favorites after reading his text. For accuracy, read his actual conclusions when they are online.)
Update: His PhD is now online.
It’s obviously easier to get detailed evidence from open source projects, so he must restrict his conclusions, but I think the conclusions apply equally well to software projects in general. Given any two large projects, with existing sub-teams of developers, pay alone is not a sufficient factor to achieve a feature-based schedule on time, given all the other things that can and do go wrong. It’s easy to feel that it should be, but reality isn’t what it should be, and time-based schedules are all about managing reality. Blame doesn’t get things done. So I think a time-based schedule is the best way to make your developers release software, regardless of how you acquired those developers.
Of course, you decide which of these releases to actually release to the public.
Note also that I think the GNOME schedule could do with more occasional adjustment to emphasize different needs at different times, such as sometimes having a longer stabilization phase, or a longer features phase. But the adjustments would have to be small, because we need to be careful about breaking our stride. I’ll post more about features-based planning tomorrow.
I’m not fan of the repetitive high-word-count form of most academic texts, but Martin does a good job of getting the ideas across, based on specific studies and interviews, with some good quotes. He has just started blogging some of it, and I suspect that this will be more direct than the thesis itself. I hope he keeps blogging it, particularly his conclusions, but here’s some links into what he has online so far:
- Project Summaries: