Slashdot Mirror


Open Source Code Maintainability Analyzed

gManZboy writes "Four computer scientists have done a formal analysis of five Open Source software projects to determine how being "Open Source" contributes to or inhibits source code maintainability. While they admit further research is needed, they conclude that open source is no magic bullet on this particular issue, and argue that Open Source software development should strive for even greater code maintainability." From the article: "The disadvantages of OSS development include absence of complete documentation or technical support. Moreover, there is strong evidence that projects with clear and widely accepted specifications, such as operating systems and system applications, are well suited for the OSS development model. However, it is still questionable whether systems like ERP could be developed successfully as OSS projects. "

2 of 264 comments (clear)

  1. You don't want to know what goes into sausage by melted · · Score: 4, Informative

    I've worked on a major product in CRM market, and let me tell you, don't want to know what goes into sausage. If you knew, you wouldn't touch this code with a 10 foot pole much less bet your company on it.

    I'm sure it's the same with ERP. It's just a huge polished turd, but because you don't have the source code you don't know it's a turd. You only see the polish.

  2. Re:Was this really a surprise? by Rei · · Score: 5, Informative

    Well, the importance of a test suite rises dramatically with the complexity of the project. The difficulty of making a test suite increases with the amount of hardware that you need to implement it. When I think of "big" open source projects that aren't very hardware dependant - for example, ITK (the Insight Toolkit), they tend to have nice test suites. Naturally, the little ones don't, but little projects of most things don't have test suites.

    I agree, though, that automated test suites are underused. Also, not enough programmers (OSS or otherwise) seem to understand the importance of refactoring.

    A message to coders: People, if your function is more than 10 lines long, you should start to consider splitting it. If it's more than 100 lines long, you're probably doing something wrong. If you have the same code written with slight modifications two or more different ways, you're probably doing something wrong. Use templates rather than repeating code if your language supports them. If you ever feel "this should probably be commented more", don't comment it - split it up into functions and let the functions be their own comments (if you have to, comment the functions as well). Use const as much as physically possible (in supporting languages). Use array objects that clean themselves up instead of arrays allocated on-the-fly whenever physically possible. If you find certain variables being used often together, group them into an object. If you find a set of functions operating on an object and only that object, make them member functions. Etc.

    Just doing basic refactoring can make code far more organized and readable.

    --
    "Well, then fire it up and show me what this..." (sigh) ... "coccoon can do."