Time-based release methodologies and open source communities

Martin Michlmayr has just finished his doctoral dissertation at the University of Cambridge, and has posted it online. I've reported on some of Martin's other work before, and think it's fascinating. (Btw, if you don't want to plow through his dissertation you can find some of his commentary on his blog, as well as a summary on Linux.com. What is Martin's research?This research has identified considerable intere

Martin Michlmayr has just finished his doctoral dissertation at the University of Cambridge, and has posted it online. I've reported on some of Martin's other work before, and think it's fascinating. (Btw, if you don't want to plow through his dissertation you can find some of his commentary on his blog, as well as a summary on Linux.com.

What is Martin's research?

This research has identified considerable interest amongst the FOSS community in a novel release management strategy, time based releases. In contrast to traditional development which is feature-driven, time based releases use time rather than features as the criterion for the creation of a new release. Releases are made after a specific interval, and new features that have been completed and sufficiently tested since the last release are included in the new version.

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 think this is useful information, and certainly matches what I see happening in the commercial open source world. I don't follow projects like Debian and such closely enough to know if this is happening there, but I'll take Martin's word for it.

Unlike previous research which has described FOSS development as unstructured and unorganized, the present work has identified a major shift in large and complex projects towards a more organized and planned approach using increasingly disciplined processes. This finding suggests that FOSS development is gaining maturity, possibly in part as a response to new requirements of users and large corporations which rely on the output of FOSS projects. (175)

Interesting, and particularly because the way it is maturing is apparently by becoming more like proprietary software (in terms of release methodologies):

The introduction of time based releases is an effective mechanism to establish better planning in projects with little control over voluntary contributors. The evidence found in this research suggests that time based releases are more appropriate in complex FOSS projects than feature-driven releases because the completion of features in volunteer projects is hard to predict and therefore makes planning difficult, if not entirely impossible. (175)

I find this fascinating. I actually don't think it exclusively applies to community-based projects (as opposed to commercial-based projects), as the longer a commercial open source vendor (or proprietary vendor) is in business, the more its customers push it to time-based releases (because it makes it easier to consume the software that way). That was certainly what I heard at Alfresco's Customer Advisory Council last week in New York: "Slow down!" "Release early and often" is still a good release strategy, but perhaps for a different audience...

Why do time-based releases help coordinate projects?

The time-based release strategy is effective because it is associated with two factors that can be considered as coordination mechanisms: regularity and the use of schedules. Regularity establishes reference points, contributes to familiarity with the release process and leads to a more disciplined development process. Schedules are a means of describing dependency information between different work items and to set deadlines and milestones. As such, time based release management allows contributors to perform their work with a high degree of independence, thereby reducing the amount of active coordination required. (175)

In short, time-based release strategies work in open source for the same way that they work in proprietary software: deadlines help focus development and make consumption of the software easier on customers.

Proprietary vendors are increasingly exploring open source development methodologies. And now, apparently, open source communities are exploring prorietary development (or, at least, release) methodologies. There are strengths on both sides, so it's good to see interaction between the two.

Btw, speaking of interaction, one thing that Alfresco has found useful is to keep the pace of our Community product (functionally equivalent with our Enterprise product - we don't have a base version and then a pro version) very fast and slow our Enterprise product. Customers have asked for this, just as they once asked Red Hat and Novell SUSE to slow releases for Linux.

In our case, it helps us because it allows us to fuel our community with the latest and greatest in Community, while providing value for paying customers in Enterprise (more rigorous testing, longer release cycles, etc.). The Community-development is fast enough that it never becomes fully baked, nudging enterprises that need a production-grade system to opt for Enterprise.

It turns out that enterprises will pay for you to be stodgy, slow, and safe. :-)

Related: