Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Source Code Maintainability Analyzed

Posted by Zonk on from the i-read-about-this-in-college dept.

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. "

21 of 264 comments (clear)

  1. Was this really a surprise? by StateOfTheUnion · · Score: 4, Interesting

    Was this really a surprise? Did anyone think that open osurce software is as a general rule well documented or documented as well as many commercial projects that have project management (for better or worse) and technical writers on staff to do internal as well as external documentation?

    1. Re:Was this really a surprise? by Tim+Browse · · Score: 2, Interesting
      If it needs more comments than code, it's a sign its overly-complicated and you need to rethink what you're doing and how you're doing it. In other words, your algorithm sux the bag.

      Well, mostly, but I have on occasion documented something to within an inch of its life because the problem is quite complex, and doesn't particularly lend itself to being broken down further. e.g. I wrote some mesh silhouette code recently, that used a lot of small, smart objects to do its job, and was only a screen or two of code, but it still needed a fair bit of explanation as to what was going on.

      Also, sometimes the algorithm is quite elegant, and I'm just pointing out that, yes, it does handle all those edge cases you were worried about, and here's how, etc. (That also kind of applied to the mesh code I mentioned.)

      But mainly I'm worried about the advice being given in a few posts of "don't add more comments" - these are OSS coders we're talking about - don't give them any ideas. :-)

      Sorry - spent today trying to understand a bunch of OSS code that was very complicated, and that has, by its very nature, lots of wrinkles and interdependencies, but of course, almost zero comments in the code. I can only assume such people only ever work on one project at a time - I don't know how I'd ever manage to come back to such a project.

      As an aside, I considered implementing a plug-in for the OSS project, on my company's time, that I could submit back, and would be of use to other people, but in the end, it was just way too involved and complicated, so I hacked up a quicker solution.

      Basically, I'm a bit tired of opening up the code of some OSS project I've got interested in, only to find that the only comments are the GPL boilerplate blocks at the top of each file :-(

      (I know, I know, it's free, I shouldn't moan, etc. But take that example today - that project could have had a few days' time from a developer with 15+ years experience, implementing a solid, tested new feature, but because the overall docs (ha! as if!) and comments were sorely lacking, that didn't happen. I'm just saying. Flame away!)

    2. Re:Was this really a surprise? by Arkaein · · Score: 2, Interesting

      Sorry, while I agree with the general thrust of this your 10 line rule seems overly pedantic and ultimately counterproductive.

      Often I have written largeish functions such that while they could be broken into smaller functions, at the time there would be no purpose in doing so except to enforce the "only short functions allowed" rule. In other words the small functions would only be called from a single point in the code. In situations like this recursively breaking a function into smaller functions adds function call overhead which impacts performance, but more importantly adds additional whitespace and boilerplate function definition code to the source that can detract from readability. This is especially true if a developer has to mentally step through every line of code in a function: if the function is monolithic the step through is basically linear, while if the function is heavily subdivided the developer must jump back and forth in the code to follow the chain of execution.

      Yes, yes, ideally each function should be tested and verified individually, but if a function was custom coded for a specific purpose only to be used in one larger function then this is often difficult to do, due to lack of alternative test situations.

      It is often the case that a chunk of code that is only useful in one location early on may be useful in multiple places later, but I believe it is best to wait until this time to refactor the original code into smaller, more modular functions.

      --
      The ultimate plays for Madden 2006
    3. Re:Was this really a surprise? by Peeteriz · · Score: 3, Interesting

      In the enterprise, for example, financial companies, is quite common to be writing and maintaining additions/modifications to some huge software package that your company has bought - you write routines that run together with their code, there are facilities for such modifications/additions.

      However, you can't *really* know how *their* code works - you must interoperate with this code, but their code has (a lot of) bugs and is poorly documented - there is a lot of documentation, but it mostly covers the trivial parts, and if you *need* to know the exact behaviour in some tricky situation, then trial-and-error is the only way.
      And of course, you have no access to their source code.
      You may pay a huge sum of money and get that access, but the amounts involved are ridiculously huge.
      You may request a change from them - but again, the costs are huge - for a trivial change they charge so much that you can fund a programmer man-year in-house - so in-house workarounds are the way to go.

  2. Extremely Ridiculous Publishing by bperkins · · Score: 3, Interesting

    GNU General Public License (GPL)
    Berkeley Software Distribution (BSD)
    are all defined in the article.

    But not ERP.

    Go figure.

  3. Bleh by Neil+Blender · · Score: 3, Interesting

    One need only peruse the source code of 5 randomly picked source forge projects to figure this one out.

    1. Re:Bleh by pclminion · · Score: 3, Interesting
      One need only peruse the source code of 5 randomly picked source forge projects to figure this one out.

      Yeah, but don't blame it on OSS. This is simply another embodiment of the long-tailed distribution of human stupidity. In any human endeavor there are a large number of people who are Unskilled and Unaware of it. These people will try their hand at whatever catches their attention, and the results usually range from mediocre to terrible.

      There's a lot of really bad fan fiction out there, too. And terrible amateur cartoons. And naive, uninformed political opinions.

      What we witness on SourceForge is merely a demonstration of the inability of most people to accomplish anything of any importance. Nothing specific to OSS.

  4. This assumes commercial software is any better by Augusto · · Score: 4, Interesting

    And it's often not.

    Many of us have and are working in the "real world" out there, and I've been less than impressed with most documentation on large products.

    Not to mention design documents, which end up being dead documents that are outdated as soon as the first line of code is written. To many corporations, there's no big incentive to spend so much money on these types of activities when you can have people just churning out code and finishing the darned product in the end.

    I'm not saying commericial development is any worse, but I can't say it's any better for sure either.

    --

    - sigs are for wimps.
  5. GUI by kaalamaadan · · Score: 2, Interesting
    Not to mention interface design. Ad hoc designs could be enormously good - like Winamp - or miserable - any of GIMP, the clipboard in X, the interface specifications for internationalization.

    In spite of drives towards a uniform consistent design, the OSS commmunity still has a long way to go in terms of interface design, which is the defining factor in acceptance of packages like ERP. In "The Art of Computer Programming", Knuth makes note that programmers hate I/O programming.

    After nearly 35 years, it is still so. OSS remains an extreme case-in-point.

  6. Mirror this article for closed source development. by dilvie · · Score: 3, Interesting

    I'd like to see the same story aproach done for closed source projects. Since the focus here was on open source, specifically, it wasn't really well balanced, and it didn't tell us anything new. Anybody who's browsed sourceforge could have told you that open source development has its share of problems.

    The real question is whether or not closed source projects are all that better off.

    --
    MakePassword.com Mp3 Blog
  7. Re:At least... by pclminion · · Score: 2, Interesting
    At least with Open Source Software you CAN maintain it if necessary. With closed source, there is no way to make any changes to old software

    Sure you can. It's easy to forget, but there are people who are fluent in assembly language and can figure out a defunct, proprietary piece of software if necessary.

    I agree that it barely meets the definition of "maintainable," but it can be done with some effort. I've done it myself, while trying to find a problem in one of our distribution binaries -- the bug I was trying to squish went away when we did a recompile for some obscure reasons, so I was forced to hack the binary itself in order to insert some debugging hooks. It can be done.

  8. Experience may vary... by moz25 · · Score: 2, Interesting

    The more high-profile OSS projects mostly do have quite extensive documentation and various mailingslists and forums to support it. Plus, if official support is lacking, it is always possible to get some sort of support from a third-party company as they have exactly the same access to the software as the original developers. With other words: the spectrum of support you *can* get is much larger, even if the support you *do* get (on the smaller) projects may be lower on average.

    --
    see a Text Widget
  9. bogus measurements by bluGill · · Score: 1, Interesting

    I gave up when I read about counting lines of codes with comments. Comments are useful, but they indicate nothing about quality or lack thereof. Some code is self documenting, and thus has few comments. Other code is just uncommented. You cannot safely assume either one, which is what you must do when using any automatically commenting counting method.

    Their other measurements seem bogus too, but I'm not interesting in looking deeper into them.

  10. In theory... by the_skywise · · Score: 3, Interesting

    I always thought that if you have enough people "chewing" (working) on the same module that it should eventually self-standardize into a least common denominator of maintainability. Which, if not the most maintainable code, should be as maintainable as possible given the design and interoperability constraints (with other modules). Evolutionarily speaking... it HAS to be maintainable or it "dies" (becomes unmaintained and then unused or superceded by another implementation).

    On the flip side, a closed source module could be built "top down" to a unified set of coding standards that would help maintainability. But it's not a requirement. I've seen plenty of code bases built just this way that were horrific... But still maintained and not changed because management was willing to throw enough money to keep things going (but not enough money to make it more interoperable).

    YMMV.

  11. were you reading the same paper? by idlake · · Score: 2, Interesting

    From the conclusions:

    Using tools such as MI derived for measuring CSS quality, OSS code quality appears to be at least equal and sometimes better than the quality of CSS code implementing the same functionality.

    So, apparently, the authors think that OSS is as a general rule better than CSS from a maintainability point of view.

  12. Open Source ERP by stiller · · Score: 5, Interesting

    However, it is still questionable whether systems like ERP could be developed successfully as OSS projects.

    I could be mistaken, but isn't Compiere an established OSS ERP implementation?

    I think the questin shouldn't be: 'Can software like ERP be developed as OSS?' But rather: 'Are there enough people in the OSS community interested enough to develop this kind of software without any form of financial support?' I think the answer has turned out to be 'no'. The same goes for things like (good) financial software, and anything that would require heaps of work, high precision and coordination, but no spectaculair result for the common man to brag about.

  13. I wish people would stop talking about... by m3741 · · Score: 2, Interesting

    the lack of technical support for open source software. I have gotten more help on more issues by searching Google than I have EVER gotten from some "central" help center for any closed source application.

  14. Re:Results would be fairer by tomhudson · · Score: 2, Interesting
    ... a simple, well-documented Perl script ...
    If it's simple, it doesn't need documentation (remember the bad old days when people insisted on commenting every line of assembler - akkk! :-)

    Me, I prefer the "Mobster" approach for perl - no comments:

    1. use half-decent variable names - that solves most of the problem about "wtf does this do"
    2. if it's more than a few lines, include code so that if it's run w/o parameters it prints out a "usage: ..." message
    3. I'm not building for eternity - just cut'n'paste, and change code as required to do what I want to do right now.
    If I wanted something /better/more permanent/elegant/, I'd write it in c. But I wouldn't want to show perl scripts to anyone - they're just fugly no matter how you slice them. And that ugliness sometimes oozes out into the surroundings. Look at the colour scheme at it.slashdot.org. Is it any wonder so many people "fix" it by typing "shit.slashdot.org" instead?

    [tt]

  15. The language is very important by doc+modulo · · Score: 4, Interesting

    - C++ is more readable than assembler
    - C# and Java are more readable than C++ ...
    - At the end of this list are functional programming languages.

    If you can read source more easily, then maintainability will be better.

    This article will tell you why you should be interested in functional programming languages. If you're smart and open minded, you will be convinced.

    The best functional languages are Haskell and Erlang (click "next" at the bottom of the page).

    For example, with Java you prevent bugs by static typing variables, example:

    int numberOfTries = 3;

    If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it.

    With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables.

    The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturere is going multi-core chip now. Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken PC.

    There are tons of other advantages but, as I said, the above links will convince you if you're smart. Haskell is a bit more academic in nature, they're figuring out the best possible language and Erlang is more polished and ready to go. It was invented by Ericsson to create ultra reliable realtime servers.

    --
    - -- Truth addict for life.
  16. Can I ask a stupid question? by rastin · · Score: 3, Interesting

    Are there standard methodologies for making non-oss code maintainable? If there are its news to me, every place I've worked has been uterly bass ackwards with their source code. Redundant libraries that do the same functions (one writen by Bob the other by Fred). Documentation that is years out of date with reality. And all the dead objects floating around, (its safer to leave them in that pull them out). With non-oss you get a pretty users manual, maybe that is what people call maintainable. Not to say there can't be sloppy OSS code. I think a great topic for discussion would be just plain maintainablity, whether its OSS or not.

    The article mentions doubt on whether an ERP system can be build OSS, why not? Are they planning on giving every end user the source code and ability to recompile the company's ERP? When I install Linux and friends on my mother-in-law's computer I don't plan on giving her the source code, is it implied that OSS is less maintainable because you cannot tell if someone has an altered version? It just freaking code!

  17. Re:Corporate OSS is an Ad-hoc Corporate Alliance by Ogerman · · Score: 2, Interesting

    Anyone have any ideas on how to prevent abuse of such a system? That is, too many people using the system and not enough people contributing?

    In my experience, you can't worry about the people who don't contribute. It's their own loss -- though most will realize with time that it isn't worth the cost of maintaining private forks.

    The business decision for OSS is always a very calculated one. It comes down to this: after investing in development of any necessary improvements to an OSS package, are you still saving money? The answer is often different depending on the term -- such as in the case of a less-mature project that needs more work. It is easy to envision a world where the short term costs of choosing OSS are always cheaper because everyone else has already done the majority of the work. But this is not where we are at today. As a result we need a maximum of cooperation with the realization of those involved that the beginning stages are the roughest and most expensive. Perhaps this is why we've seen the most OSS involvement from larger companies -- they have the resources to think longer-term and take more risks. For the rest, we probably need more heavily commercialized OSS business software to spread the load/risk.