Open Source Production: Time-based release management
Time by gastronauten
First I wish to public thank Martin to mention our paper “Capability Coordination in Modular Organization: Voluntary FS/OSS Production and the Case of Debian GNU/Linux“. He cited our findings talking about release management in volunteer teams and also about problem of organization when a coordination effort is required to accomplish complex goals.
I totally agree with him when he states that the ‘release when it’s ready’ policy might heavily affects large (complex) projects, because:
It can lead to delays, out-of-date software, and frustration, and it also means that users and vendors cannot plan, because nobody knows when the software will actually be released.
I remember Mark Brewer, Covalent CEO, saying that, even if Covalent has about 40 software engineers involved with Apache, they can’t assure that a feature will be available at a certain date. He also did similar considerations talking about road-map’s decisions. No wonder though, that is the way it is when it comes to community-driven Open Source projects.
Getting back to Martin research his abstract reports:
This dissertation explores why, and under which circumstances, the time based release strategy is a viable alternative to feature-driven development and discusses factors that influence a successful implementation of this release strategy. It is argued that this release strategy acts as a coordination mechanism in large volunteer projects that are geographically dispersed. The time based release strategy allows a more controlled development and release process in projects which have little control of their contributors and therefore contributes to the quality of the output.
I read some chapters of the paper, and I was impressed by the quality and the depth of his studies. I believe that the introduction of time based releases leads to a more controlled development, positively affecting the resulting overall quality. In his words:
[..] the time based release strategy can be considered as an important means of quality improvement in FOSS projects.
Kudos to Martin to honestly have highlighted that there are problems in Open Source projects, he also stressed the importance of Regularity and the Use of schedule. As a matter of fact the use of schedule claims a project management function (release manager), reducing somehow the degree of independence among contributors. Our research in this respect stated that:
[..] a pure modular structure – that is one lacking of hierarchy, such as a market – embeds flexibility, but it lacks coherence, the ability to coevolve after adapting to change.(cfr. Langlois Richard “Do firm plan?” 1995)
A hierarchy is a must, then, when you need to manage a complex activity coordinating many contributors, either volunteers or employees. Martin makes clear that policies and infrastructures are needed to support his release strategy.
Reading the paragraph “Limitations and Future Research” I would suggest another question:
Introducing time-based release management could move developers’ focus from software’s effectiveness to meeting release targets? How to balance the trade-off between time and quality?