Michlmayr advocates time-based release management for FOSS projects

Former Debian Project Leader Martin Michlmayr is completing his doctoral thesis at the Centre for Technology Management, University of Cambridge. Entitled “Quality Improvement in Volunteer Free, and Open Source Projects: Exploring the Impact of Release Management,” his thesis is based on case studies of major free and open source software (FOSS) project, including Debian, GNOME, the Linux kernel, OpenOffice.org, Plone, and X.org. A supporter of the open access movement, which tries to make academic work as widely available as possible, Michlmayr is blogging and discussing his work as often as possible. He also plans to make the final version of his thesis available on the Internet. As part of his efforts, Michlmayr talked to Linux.com about why he concludes that regularly scheduled releases are desirable in large FOSS projects.

Michlmayr says that FOSS projects have two characteristics that make them unique in software development. First, their members are geographically dispersed, which delays communication. Second, many members are volunteers, and, although highly motivated, may not always be available at crucial times. These features have some advantages — for example, members’ dispersal means that all communication is recorded — and are certainly preferable to centralized, paid workers who lack motivation. However, “taken together,” Michlmayr says, “these aspects can make coordination and release management quite difficult.”

In particular, these characteristics often result in a lack of planning. “Quite a few large and complex projects adhere to a ‘release when it’s ready’ policy, but this strategy is disastrous in large projects where there is always something to be done,” Michlmayr says. “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.” In the draft of his thesis currently online, Michlmayr singles out Debian as a prime example of these problems.

Left unsolved, these problems can lead to “loss of credibility and fewer contributors,” Michlmayr says. “Why would volunteers want to contribute to a project when it takes years for their contributions to be shipped to actual users? Loss of credibility is particularly problematic because it’s a vicious circle. If you repeatedly face delays, nobody will believe that the project can actually release on time, and further delays are inevitable.”

The solution to this situation, Michlmayr says, are regularly scheduled releases. He concedes that converting to a schedule requires “considerable work,” but he points to GNOME as proof that it can be done. In fact, he considers it a necessity when a project begins to have trouble with its release strategy.

“Many problems with release management occur because processes that worked well when the project was small are not suited to a large project,” Michlmayr says. “In a small project, it’s possible to say, ‘release when it’s ready.’ In a large project, such an unorganized approach will lead to significant problems.”

The advantages of time-based releases

According to Michlmayr, a move to time-based releases benefits everyone involved. For large organizations using the software produced by the project, time-based releases provide the predictability they need for their own business and infrastructure planning. Similarly, commercial distributors can plan their marketing, while individual users can have increased confidence in the project.

However, the largest benefits of time-based releases are for the project’s own development community. Over time, Michlmayr sees regular releases as increasing the discipline in the community, allowing its members to coordinate their efforts more efficiently. Regular releases also allow better planning in both the short and the long term. In addition, as part of the cycle, user feedback becomes more timely and can be incorporated into planning with less effort.

By contrast, Michlmayr says that “so far, no clear disadvantage has been found” for regular releases. He notes that it is uncertain “whether you can make major changes while still following a time-based release strategy,” adding that GNOME has debated this question in talking about how to develop GNOME 3.0. He says that “this question cannot fully be answered yet,” and suggests that “it’s possible for features to be developed on a branch over more than one release interval,” which would make major changes compatible with a regular release strategy.

Knowing when to move to time-based releases

As with addiction treatment, the first step in moving to time-based releases is to acknowledge that your current strategy doesn’t work, Michlmayr says. He gives four criteria for knowing when the solution might be appropriate:

• Significant new fixes and features are added with each release. When a project is small enough that releases are incremental, time-based release is probably an unnecessary discipline.
• Distribution is cheap. In other words, time-based release is not practical for commercial shrinkware, but is for free software downloaded over the Internet.
• The next release does not require specific new functionality or major changes. That excludes work done for a specific client, or for a commercial product that needs new features to convince users to upgrade.
• The code is modular, so that individual components can be developed and released independently of other ones. This requirement helps to provide flexibility that makes meeting deadlines easier.

Once a project has decided to move to regular releases, it needs to choose an appropriate release interval and to develop detailed schedules, policies, and infrastructure.

For Michlmayr, a particularly important part of the transition is the appointment of an effective release manager. He defines such a manager as someone with both management skills and the ability to build communities, develop a strong vision of where the project is heading, and to stay on target and refuse requests when necessary.

He also emphasizes that release managers must “actually perform hands-on management. Some projects believe that simply publishing a release date or schedule is enough and that project participants will automatically do their work. In reality, it’s important to constantly remind people of the schedule and of looming deadlines.”

Applying the findings

Michlmayr declined to suggest a detailed set of best practices for release management in FOSS projects. “That would be a whole Ph.D. (or three) on its own,” he says.

However, Michlmayr did say that his research was not only potentially useful for FOSS projects, but for any volunteer effort.

“With the Internet, there will be more collaborative, volunteer projects in the future,” he says. “The insights we’ve now gained with free software can be applied to these projects. My research on release management in free software projects can be seen as a way to approach the question as to how products can be released by projects with little control over their contributors.”

Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager’s Journal.