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. "
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...and much too often, the companies that make some of the obscure CAD stuff (my field, once) are out of business. At least having it open makes it possible to change something...even if you don't.
In fact, I'd go so far as to extend this to software in general. Even when the comments can really matter, like API docs for libraries, the documentation sucks as often as not. I see no advantage to OSS here, but I don't see a disadvantage either.
O.k., perhaps its not a surprise, but in the end the community needs to do away with the 'more eyes make better software' myth in order to move forward. In that sense, it is good that 'professionals' are now pointing out that some of the software out there is actually quite bad and that it is _not_ generally acceptable to not maintain documentation and uphold good project hygiene.
Here's a nice experiment for you:
1. Select a random project, preferably one that's slightly buggy during ordinary use.
2. Subscribe to project's mailing list.
3. Politely inquire if the project has any kind of automated test suite.
4. Observe stumped reaction.
5. Kindly explain the absolute necessity of such a system in any non-trivial app.
6. Go down in flames.
That attitude needs to change.
Right, and what the hell does "Enterprise Resource Planning" mean?
It used to mean the combination of MRP ("Material Requirements Planning") + Accounting. Then along came PeopleSoft and kinda changed it to HR + Accounting. Then along came Siebel and everyone scurried to make it MRP + HR + accounting + CRM (not quite there yet, though). Then they noticed Kronos and they all scurried to make it MRP + HR + Accounting + CRM + Time & Attendance. And failed, because Time & Attendance is a big pain in the butt. Heh. So they partnered with Kronos instead.
The march of "embrace and extend" continues. Next app up: Expense Reporting (say bye-bye to Concur, etc., that's an easy app). Already on deck: data warehousing (say bye-bye to Cognos, Business Objects, etc., say hello to SAP BW). Soon to come: business process automation (say bye-bye to Ariba, etc.)
And so on, if you believe the pundits.
"ERP" has become a meaningless acronym, an umbrella under which every business app known to man is rammed into the same stinking pile of multi-million dollar shit. At some point it will probably implode from its own weight, and we'll go right back to the "best of breed" interoperable software model.
But it will be a while yet. I suspect in the meantime there will be some Open Source alternatives. I sure hope so.
You're actually trying to claim that Winamp's design is good?
Winamp and other players which try to emulate the look and feel of a "new wave" stereo do nothing but piss me off. Stereo systems have the bad interfaces they do because of an inherent lack of physical space; something that's still a concern with computers, but much less of one.
Here's to more programs like Rhythmbox and iTunes which have the *important* controls accessible, allow for easy categorisation of songs, and use screen space nicely. All that without having to resort to 6pt fonts.
No comment.
I'll probably get flamed for this, but at least with OSS, if there's no documentation, you can at least read the code to see what it does. I know, that's no substitute for proper documentation, but with closed source, if there's no documentation, you're just fucked, plain and simple. In OSS, if there's no documentation, you can read the code.
It's only amusing to people who don't bother to think about why it's there. It's actually a very insightful part of the metric.
First of all, perCM ranges from 0 to 1, not 0 to 100. Yes, that isn't explicitly stated, but it would be ridiculous otherwise. Second, try looking at the damn graph.
As I told somebody else, do it now. Don't pretend to do it, GRAPH the damn thing and look at it: sin(sqrt(2.4*x)) for x=0..1.
That graph makes it completely transparent what they're trying to accomplish with that part of the formula. First off, if comments are 0, the value is 0. Having no comments does not positively impact maintainability! Second, the function PEAKS at around 0.43. This represents an avgCM of 0.03, or 3%. Then, the function begins to go down again, but not as drastically as it rose.
What this is saying is that the benefit of comments has a maximum at around 3%. Having more comments than this tends to DECREASE the maintainability (and this is borne out by experience). However, having too many comments is better than having too few comments, so the function is skewed to the left side by the sqrt() function.
You see, every part of that expression makes total sense if you spend more than 2 nanoseconds thinking about it. Sheesh.