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.

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.

Corporate production has to be on Time on Budget. The firm solves the problem of finding the efficient management of human resources through time not allowing the free entry and exit, and delegating production control to a manager.

Community-based production on the contrary allows volunteers to enter and choose their tasks. Volunteers choosing what to do apply for tasks they like, and that they are likely to accomplish effectively. They can also freely exit from a project though, or not to end their tasks on time.

Do you agree?

How to balance the trade-off between time and quality?

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.