Open Source Production: Time-based release management
is completing his doctoral thesis at the University of Cambridge with a thesis entitled “Quality Improvement in Volunteer Free, and Open Source Projects: Exploring the Impact of Release Management“.
Time by gastronauten
I happened to know about his thesis reading an article on linux.com, and I saw also Matt Asay posted on the subject, so over the weekend I took my chance to read it.
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?
Roberto Galoppini, 
][ stefano maffulli » links for 2007-04-04 1:06 pm on April 4, 2007 Permalink
[…] Open Source Production: Time-based release management Letture estremamente interessanti. Grazie Galop. (tags: software engineering free+software release+management) […]
Simon 11:22 am on April 28, 2007 Permalink
I think this is the key question.
GNOME has happily released versions with key features missing because they weren’t ready in time. This just isn’t viable for a commercial provider of desktops, who would then have to cover for the “failure” of the open source model, probably by not shipping that version of GNOME in their desktops.
Ubuntu similarly has shipped releases with major holes in them, again something that the proprietary world would not do, because it would slow adoption, and defeat the commercial point of a release.
Sure clearer time tables, and clearer planning may be good for organizing the work, but ultimately deadlines will go whoosh, if the work isn’t done, and that is how it needs to be if people depend on the product finally delivered.
Roberto Galoppini 7:29 pm on May 1, 2007 Permalink
Simon,
I totally agree with you, at the end of the day time-based release management can address few issues indeed, but it is not a panacea.
In another post I mentioned that within an hybrid production model paid employees are often responsible for less attractive tasks, as results from “GNOME, a case of open source global software development”, also by Martin.
Do you agree?
Jon 3:58 pm on March 3, 2008 Permalink
I don’t see why dropping features to hit a target is necessarily a hallmark of F/OSS process failure. Consider Microsoft pulling WinFS from Vista.
The company I work for will not consider using Debian for any server because of the lack of any kind of predictable release cycle. Indeed, having a commitment to (say) 12 month release periods, and missing that commitment, would be better than none at all.