Technology news and Jobs 
Our Blogs Open Sauce Time and tide don't wait for FOSS projects
Our Blogs Open Sauce Time and tide don't wait for FOSS projects | Time and tide don't wait for FOSS projects |
|
| by Sam Varghese | |
| Tuesday, 29 January 2008 | |
|
Page 1 of 2   
Featured Whitepaper
5 Best Practices for Smartphone Support
Martin Michlmayr , a senior FOSS developer and a former Debian project leader who now works with HP's open source and Linux organisation as an open source community expert, certainly thinks the latter option is better. The soft-spoken Austrian completed a doctorate (PDF download, 800k) at the University of Cambridge last year on managing time-based releases in large free software projects. He shared some of his findings at today's distro miniconference which was held as part of the Australian national Linux conference. (A video of the same talk is here .) Michlmayr studied the Debian project, GNOME, the GNU C compiler, the Linux kernel, OpenOffice.org, Plone and X.org for his thesis. His selection of projects was based on four criteria: they should be large and complex, voluntary, distributed and time-based. Each project presented unique features which led to the delay in release cycles. For example, with Debian, release management was not very organised, there were infrequent release updates, there were impediments to release which were discovered very late during the release process, delays meant that the software being released was out of date and this resulted in the project getting a bad image. At the height of its release problems, Debian took 35 months to release stable version 3.1 or Sarge. Michlmayr said the project had solved some of the problems by implementing better release management structures, setting a release date well in advance and making updates, determining release targets and clarifying responsibilities within the project. However, one problem still remained - the developers needed to see that targets which had been set could be achieved. With the GNU C compiler, the problems in the past had been closed development, a long time between releases, no public snapshots, and the fact that when development picked up, changes often broke the development tree. Solving these problems meant the introduction of an open development style with a steering committee, dividing the development phase into three stages and having all patches subject to peer review. |
| < Next story in category | Previous story in the category > |
|---|
