Open Sources | Rodrigues & Urlocker » Research: Maturity of software processes and their impact on open source development

August 30, 2006 | Comments: (0)

Research: Maturity of software processes and their impact on open source development

TAGS: Open Source

I was reading a research paper [PDF] last night by Martin Michlmayr (University of Melbourne) entitled "Software Process Maturity and the Success of Free Software Projects." The paper addresses the question of "whether the maturity of particular software processes differs in successful and unsuccessful projects" (1).

While the paper offers little in the way of hard conclusions, it does make some interesting observations.

• Version Control Tools.

  Version control tools, such as CVS in the case of projects hosted on SourceForge, are used more widely in successful than in unsuccessful projects. Furthermore, a higher percentage of version control repositories are available publicly. In free software projects, CVS and similar tools play important roles related to coordination. Having a private version control repository limits the access of prospective contributors. On the other hand, a publicly available CVS repository allows contributors to monitor exactly what other people are working on. This allows multiple people to work together efficiently in a distributed way. In a similar way to defect tracking systems, public version control systems may attract more volunteers since users see what needs to be done and how they can get involved.

  
  
• Mailing lists. 80% of successful projects use mailing list archives, compared to 50% of unsuccessful projects.

  In both, version control tools and mailing lists, it is not clear from the present findings whether a successful project requires these types of infrastructure to flourish, or whether the implementation of the infrastructure has attracted more volunteers and so led to more success. Our assumption is that there is no clear causality and that both affect each other.

  Still, it would appear that mailing lists are important for lowering the "cost" of outside contributors getting involved with a project, as it serves as a form of documentation. (I've talked here about the importance of documentation.)

• Documentation. Interestingly, documentation wasn't found to definitively impact a project one way or another:

  it can be argued that user documentation is an important factor in free software projects. However, this factor alone does not determine success. Developer documentation, on the other hand, is not very common in free software projects. A reason for this might be that prospective developers find most answers to their questions from other sources, such as mailing list archives or the source code.

  Still, the author doesn't analyze code quality of the projects with/without extensive documentation, as well as other factors. My bet (based on experience) is still that documentation is outcome-determinative in open source projects.

• Systematic Testing.

  The analysis of processes involving testing shows that successful projects make more
  use of release candidates and defect tracking systems than unsuccessful projects. There is no difference in the presence of automated test suites. The availability of release candidates has been taken as an indication of a well defined release plan. While it would be revealing to qualitatively study and compare the release strategies of different projects, the present findings suggest that a clear release strategy coupled with testing contributes to the success of a project.

  Let the developers know where you're going, and when you'll get there. This makes it easier for them to find the time and inclination to help.

Not a lot of big conclusions in the paper, but it does point to one general theme: successful projects are permeable. They make it easy (or relatively so) to contribute and use the software. Less successful projects horde information and so require larger investments of time in order to use or contribute to the project.

So, if you're thinking of starting a project, or wanting to improve use of an existing project, try improving access to your CVS (or whatever you use), use of mailing lists, and follow a well-defined release plan. Oh, and document everything. It's boring work, but it's critical.

Posted by Matt Asay on August 30, 2006 05:53 AM

RATE THIS ARTICLE: