Open Source Code Maintainability Analyzed 264
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. "
Was this really a surprise? (Score:5, Interesting)
Extremely Ridiculous Publishing (Score:4, Interesting)
Berkeley Software Distribution (BSD)
are all defined in the article.
But not ERP.
Go figure.
Bleh (Score:3, Interesting)
This assumes commercial software is any better (Score:5, Interesting)
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.
GUI (Score:2, Interesting)
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.
Mirror this article for closed source development. (Score:4, Interesting)
The real question is whether or not closed source projects are all that better off.
Re:At least... (Score:3, Interesting)
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.
Experience may vary... (Score:3, Interesting)
bogus measurements (Score:2, 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.
Re:Bleh (Score:4, Interesting)
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 [phule.net]. 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.
In theory... (Score:4, Interesting)
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.
were you reading the same paper? (Score:2, Interesting)
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.
Open Source ERP (Score:5, Interesting)
I could be mistaken, but isn't Compiere [compiere.org] 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.
I wish people would stop talking about... (Score:2, Interesting)
Re:Results would be fairer (Score:3, Interesting)
Me, I prefer the "Mobster" approach for perl - no comments:
- use half-decent variable names - that solves most of the problem about "wtf does this do"
- 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
- 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[tt]
The language is very important (Score:5, Interesting)
- 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 [paulgraham.com] 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 [haskell.org] and Erlang [erlang.org] (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.
Can I ask a stupid question? (Score:3, Interesting)
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!
Re:Was this really a surprise? (Score:3, Interesting)
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!)
Re:Corporate OSS is an Ad-hoc Corporate Alliance (Score:3, Interesting)
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.
Re:Was this really a surprise? (Score:3, Interesting)
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.
Re:Was this really a surprise? (Score:3, Interesting)
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.