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.
It takes being interested in a project for one to pour himself into it. Most hackers/programmers have a thing for Operating System and programming tools, So it's not suprise that OS projects are doing betters. Or Programming tools, GCC, editors, Programming Languages, Databases... I love to program, but I could never find myself programming an ERP system, just for some company to make money of. How is it going to meet my personal need? There has to be something in it for me!
This is why accounting software, office software and lots of general use applications "suck" in the OSS word. The "motivation" is not there, even "ego" is not a good enough motivation. My fellow hackers will give me more props for some lousy 500 line python hack which does something weird and not so useful than a complete accounting software suite.
What would be interesting is to see a group of companies start an OSS project from the ground up, pour their own money, pay programmers. But then again, there is no motivation for that! Big companies are only interested in jumping on OSS projects that happen to have gained fame...
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
However, it is still questionable whether systems like ERP could be developed successfully as OSS projects.
Yeah, it's also still questionable whether systems like ERP can be developed successfully at all. I'd like to see statistics on the number of ERP implementations that go horribly wrong and wind up crippling or even bankrupting companies.
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.
Anyone who has used perl knows that if you need anything beyond POD, you're not ready for perl.
Perl is "unclean" for a reason - it is there just to get the job done quickly, not necessarily cleanly.
Just try and start documenting perl - since there is more than one way to do things, you'll end up giving in to the urge to change code as you document it - so the documentation never gets written, and the code never gets finished. It's a fool's errand, a sisyphian task, the modern equivalent of a "bucket of steam". Sort of like the distraction of commenting while meta-modding.
Teach a man perl - he writes code to do the task in a few minutes. Ask him to document perl - he writes code forever - and still leaves the job unfinished.
Some tasks, and some languages, just weren't made for documentation. [tt]
Good corporations understand the value of corporate alliances. Often, the cost of doing something by yourself isn't worth the payout. Business support software is one of those. Companies don't make money from selling their internally developed software. OSS provides a means for lots of small companies to get together to create this kind of software, without having to create a formal agreement. Sure, some companies are going to take advantage, but if it is open, then every company can add the features that it wants.
The problem with a software company filling this role is that their system is proprietary and unmodifiable by the client. Most companies *do* have the resources to hire a programmer or a contractor to add a feature to a piece of OSS.
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?
Mad Software: Rantings on Developing So
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.
Quality is still a happy user. Users like software
the works well and hopefully doesn't need a lot of documentation to make it work well. Great software
tends to teach the user how to make it perofmr or at least motivate the user to want ot invest the time to master the software for a particular use.
These guys need to understand that this approach to quality applies to all software, irrespective of
development model behind it. A software product with a lot of customers creates the momentum to maintain and enhance that product. An OSS product can be infused with similar energy due to acceptance by a large community of users (esp if many are programmer's too). The feedback from the users incents the programmers to maintain and enhance the product.
New models can be built from hybrids of OSS (donated programming in the commons) and products
that one must buy. If there emerges an ERP OSS app then there will be a business opportunity to document/train, support/fix/enhance/customize that application... and Oracle will feel the same frustration competing with that model that MS does competing with Linux.
These complaints against OSS as a model (no obtion to buy support or docs) are a business opportunity
that has been put into play by JBOSS, MySQL, and soon to be hundreds of others. The low barrier to entry is the key to high usage... It's try and don't buy (unless you'd like some training, customization, focus product enhancements, etc).
Volume, usage and effectiveness drives the software world. Quality just makes the ride more comfortable. And OSS gets more comfortable everytime the train puls through the station.
> design documents, which end up being
> dead documents that are outdated as soon
> as the first line of code is written.
So true. Or only one page will be kept up to date - the database schema diagram, because it can be automatically generated from the production database schema.
Meanwhile, new hires are referred to these documents with mumbles of "this is the design documentation, read this and you'll know everything". This statement is usually accompanied with a cynical smile and a shrug, indicating to the new hire the uselessness of the ritual. Ack.
The Army reading list
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.
If you can't write test cases for it because it's too tightly coupled to the rest of your code, you probably misunderstood the problem in the first place (or at least you're approaching it from the wrong direction)...
All the comments and documentation in the world won't make spaghetti understandable or maintainable.
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.
I have seen many a software project disregard performance, features, and development speed all in the name of maintainability.
We can't use JSP's, there hard to maintain!
We can't use Javascript, it's loosely typed!
We have to use an Object Broker, SQL is not maintainable!
All the projects that I have been on where code maintainability has been the primary goal have one thing in common. They all failed.
If you spend all of your time worrying about how the code looks, you will never finish the project. Talk to people who have built successful software. (The ones that sold millions of copies.) Very few of them are proud of the code the wrote, but they are happy with the product.
The focus should always be on product quality, not code quality.
... but at least with OSS, if there's no documentation, you can at least read the code to see what it does
... In OSS, if there's no documentation, you can read the code.
And if it not OSS, then either you have access to the code (in which case you can read it also), or you don't (in which case maintainability isn't even the issue, because there isn't any).
Whether the source is open or closed has no (direct) bearing on how good the source and documentation are, for those allowed to see the source and documentation.
I am not a sig.