Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Source Code Maintainability Analyzed

Zonk posted more than 9 years ago | from the i-read-about-this-in-college dept.

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

cancel ×

264 comments

Sorry! There are no comments related to the filter you selected.

Results would be fairer (3, Funny)

Anonymous Coward | more than 9 years ago | (#11682005)

If they excluded PERL.

Re:Results would be fairer (1)

barryman_5000 (805270) | more than 9 years ago | (#11682047)

haha, try and document all 400 million perl modules.

Those who forget history are doomed to reimplement (2, Funny)

Thud457 (234763) | more than 9 years ago | (#11682131)

You lazy young whippersnappers and your precious Perl! You probably think you INVENTED write-only code. In my day, we wrote APL, and nobody liked it!!!!

Re:Those who forget history are doomed to reimplem (1, Funny)

Anonymous Coward | more than 9 years ago | (#11682161)

In my day, we used punch cards, and once you made a hole, it was there for life.

Re:Results would be fairer (3, Insightful)

tomhudson (43916) | more than 9 years ago | (#11682499)

"The code IS the best documentations" vs "code looks like line noise"

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]

Re:Results would be fairer (0)

Anonymous Coward | more than 9 years ago | (#11682817)

Odd.

In my portfolio, along with my resume, references, etc., happens to be a simple, well-documented Perl script I use as an example of my coding style. To each their own?

I tried to read it but... (5, Funny)

Anonymous Coward | more than 9 years ago | (#11682013)

by Ioannis Samoladas, Ioannis Stamelos, Lefteris Angelis, Apostolos Oikonomou ...it was all Greek to me.

Only one man... (3, Funny)

game kid (805301) | more than 9 years ago | (#11682147)

...dared to challenge this article.

(insert rousing action-series music) Hercules!

Re:I tried to read it but... (1, Funny)

Anonymous Coward | more than 9 years ago | (#11682192)

That's easy for you to say!

bah! (2, Funny)

eggoeater (704775) | more than 9 years ago | (#11682020)

I just keep my code on one 3 1/2 inch floppy.
Haven't had a problem yet....

I guess... (1)

game kid (805301) | more than 9 years ago | (#11682203)

...that's where it'll stay, once you get a new PC. I've been seeing less floppy drives built-in these days, if only because of CD-R[W]s, the Internet, and now USB keys and the like.

Re:bah! (3, Funny)

Sponge Bath (413667) | more than 9 years ago | (#11682253)

...3 1/2 inch floppy

Nothing to be ashamed of, that's a pretty average size.

bah! "experts" (2, Funny)

Anonymous Coward | more than 9 years ago | (#11682610)

From TFA: "Four computer scientists ... argue that Open Source software development should..."

I stopped reading at that point.

If they think they're so smart, those 4 guys are welcome to fork whatever project they want and do it themselves.

Was this really a surprise? (4, Interesting)

StateOfTheUnion (762194) | more than 9 years ago | (#11682026)

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?

Re:Was this really a surprise? (0)

Anonymous Coward | more than 9 years ago | (#11682331)

Have you ever actually seen one of these mythical environments where people document code, proprietary or otherwise?

Re:Was this really a surprise? (1)

irexe (567524) | more than 9 years ago | (#11682487)

Ehh.. yes. As a rule I don't work for anybody that doesn't have a basic, decent software development practice going. I've had no trouble finding jobs as of yet. Quality pays off, both ways.

Re:Was this really a surprise? (4, Insightful)

arkanes (521690) | more than 9 years ago | (#11682361)

In my experience, OSS is no more or less well documented than commercial, in house code. Some OSS projects have great docs. Most don't. Most in house software is poorly documented. The number of companies that actually have technical writers on staff for internal software is very, very small. Certainly I've never worked for one.

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.

Re:Was this really a surprise? (4, Insightful)

Feztaa (633745) | more than 9 years ago | (#11682631)

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.

Re:Was this really a surprise? (1)

micromoog (206608) | more than 9 years ago | (#11682864)

This can never be stressed enough. People generally respond to this with "I don't know how to read code", "I don't have time to read code", etc. but a large company will certainly have the resources to handle this, and will ultimately get better and faster support from said in-house resources than they ever would from a vendor.

Re:Was this really a surprise? (5, Insightful)

Anonymous Coward | more than 9 years ago | (#11682394)

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.

Re:Was this really a surprise? (5, Informative)

Rei (128717) | more than 9 years ago | (#11682731)

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.

Re:Was this really a surprise? (1)

tcopeland (32225) | more than 9 years ago | (#11682813)

> If it's more than 100 lines long, you're
> probably doing something wrong.

Quite right! Once that 100 line method is broken out into a class or two, you'll find two or three other places where you've got minor variations on the same code. Those variations (and their attending bugs) then get refactored away, the codebase shrinks, and good times result.

Thanks for the great post!

were you reading the same paper? (2, Interesting)

idlake (850372) | more than 9 years ago | (#11682414)

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.

Re:Was this really a surprise? (1)

uglyduckling (103926) | more than 9 years ago | (#11682768)

open osurce software - I like the sound of that, what's your philosophy? What kind of beard do I have to grow?

Re:Was this really a surprise? (1)

Mr. Slippery (47854) | more than 9 years ago | (#11682843)

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?

Do you really think that commercial software is as a general rule well documented? (Or documented at all?)

I've only worked on two proejects that had technical writers, and their job was mostly to clean up grammar and spelling from the developers. (Which, lest I be misunderstood, is a valuable job.) They were first on the post-boom chopping block anyway.

Most projects I've worked on, you were lucky if you got meaningful comments in the code at all.

This "study" is complete BS. With no comparison at all to proprietary software, no conclusion about the maintainability or quality of F/OSS is possible.

Extremely Ridiculous Publishing (3, Interesting)

bperkins (12056) | more than 9 years ago | (#11682033)

GNU General Public License (GPL)
Berkeley Software Distribution (BSD)

are all defined in the article.

But not ERP.

Go figure.

Re:Extremely Ridiculous Publishing (2, Informative)

rdwald (831442) | more than 9 years ago | (#11682150)

GNU General Public License (GPL)
Berkeley Software Distribution (BSD)


are all defined in the article.

But not ERP.

Go figure.
It seems like ERP stands for Enterprise Resource Planning [wikipedia.org] .

Re:Extremely Ridiculous Publishing (4, Insightful)

Bozdune (68800) | more than 9 years ago | (#11682548)

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.

Re:Extremely Ridiculous Publishing (1)

ergo98 (9391) | more than 9 years ago | (#11682425)

It's Enterprise Resource Planning, and is a catch-all phrase that allows large enterprises to dump millions on garbage solutions.

It really boggles the mind that ERP is presented as some sort of mythical height - most ERP systems are absolutely abysmal, terrible monstrosities. Most commercial software bought by Joe and Martha Average has a complexity, and quality, surpassing ERP systems.

Re:Extremely Ridiculous Publishing (1)

srini91 (859711) | more than 9 years ago | (#11682681)

Quality is lower for ERP? Yes. Complexity is lower for ERP? Not true. That 90% of things that no one uses in commercial software? Doesn't always apply to ERP. The dependency graphs on large ERP implementations is just huge.

At least... (4, Insightful)

BJZQ8 (644168) | more than 9 years ago | (#11682040)

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.

Re:At least... (2, Interesting)

pclminion (145572) | more than 9 years ago | (#11682167)

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.

Re:At least... (2, Insightful)

micromoog (206608) | more than 9 years ago | (#11682370)

It can be done.

But it's usually illegal. The copyrights to that program are still owned by somebody somewhere, collecting dust and mold.

Re:At least... (3, Insightful)

pclminion (145572) | more than 9 years ago | (#11682441)

I don't see how copyright applies in this case. I can take a book, mark it up, cut pages out and paste new content into it. It's my book. I would be in trouble if I wanted to then sell that book, but I'm not trying to. Why should a piece of software be different?

Re:At least... (5, Insightful)

Anonymous Coward | more than 9 years ago | (#11682392)

As a software engineer, I do like to point out something to you. "At least with open source you CAN maintain it if necessary" is not true! Maintenance takes up a good 60+% of a software cycle. Doing maintenance requires good documentation, fixing a bug is a minor issue, especially when it's easy to track down. Understanding design decisions, understanding architecture so that you can extend the software is a big challenge.

Without appropriate documentations, you end up doing what has been done all over again, studying the software to understand how it works, which can be taxing. Go look at somewhat complex OSS projects, try hacking gcc to spit out a different binary format without reading any documentation. Try understanding postgres without documentation. GUI applications like a CAD system are even harder to make sense out of. If you are actually talented enough, the sheer effort you will poor into understanding the system, you might as well spend it designing from the ground up.

Most people are not hackers, If they were, why would they need source code? crackers don't need source code to add functionality to any system, it's a matter of patching the object code, having a section of the code jump to your own code and return. But it's ugly, having source code makes it a little bit prettier but not much.

Documentation is the key! .segmond

Re:At least... (5, Insightful)

charvolant (224858) | more than 9 years ago | (#11682528)

At least with Open Source Software you CAN maintain it if necessary.

Sort of ... kind of ...

There comes a point where, particularly without design documentation, the bar is raised so high that the effort involved in maintaining something is more than that involved in moving to a new product. There's a scaling problem here. What works with small, simple direct programs doesn't work with large, complex or indirect programs.

And some OSS code is simply completely undocumented, not even a comment -- apart from the licence. Something I discovered wandering through the XFree86 XKB code.

See http://firstmonday.org/issues/issue4_12/bezroukov/ index.html [firstmonday.org] for a discussion some of the weaknesses of the open source model when it comes to program comprehension.

Bleh (3, Interesting)

Neil Blender (555885) | more than 9 years ago | (#11682062)

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

Re:Bleh (3, Interesting)

pclminion (145572) | more than 9 years ago | (#11682329)

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

Re:Bleh (1)

Neil Blender (555885) | more than 9 years ago | (#11682421)

I'm not blaming OSS for this, only pointing out that their conclusion is obvious. I'm sure you could pick 5 random closed source commercial projects and find (nearly) the same thing.

Re:Bleh (2, Insightful)

pclminion (145572) | more than 9 years ago | (#11682474)

I'm sure you could pick 5 random closed source commercial projects and find (nearly) the same thing.

The difference, though, is that commercial products can't exist (or at least by all economic rights SHOULDN'T exist) without a userbase. SourceForge is littered with stuff that's so bad it's completely unusable. You can't get away with that with a commercial product, although that doesn't necessarily mean the project is MAINTAINABLE ;-)

And I didn't think you were blaming OSS, just picking up your thread and running with it.

This assumes commercial software is any better (4, Interesting)

Augusto (12068) | more than 9 years ago | (#11682077)

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.

The article says OSS is as good or better. (1)

khasim (1285) | more than 9 years ago | (#11682802)

From page #2, almost at the end:
1. 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.
The article is rather thickly written so it's difficult to find, I had to read through it twice.

But, OSS wins.

Bias! Bias! (1)

Seth Finklestein (582901) | more than 9 years ago | (#11682080)

Look who underwrote the so-called "survey." It's a leading ERP "solution provider." I've dealt with these bullshit artists before, and trust me when I say that you cannot believe anything they say. They care only about big money, not about the quality of their software -- which 99% of the time is utter bilge. I've actually fixed errors in their products while they're in the middle of their sales pitch!

Don't believe any of this FUD. The open source ERP revolution is coming, and these assbastards are the first against the wall.

Re:Bias! Bias! (0)

Anonymous Coward | more than 9 years ago | (#11682244)

"Informative," please.

They are confusing open source again (0)

Anonymous Coward | more than 9 years ago | (#11682126)

Commercial open source can work. Look at Qt. Its well documented and maintained. DUH!

GUI (2, Interesting)

kaalamaadan (639250) | more than 9 years ago | (#11682127)

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.

Re:GUI (1)

computational super (740265) | more than 9 years ago | (#11682261)

Did you switch topics, or was that a typo? You went from talking about interface design to talking about I/O programming. I'm just curious which one Knuth actually discussed, and don't feel like going out and buying the book to find out. ;)

Re:GUI (1)

kaalamaadan (639250) | more than 9 years ago | (#11682356)

My point was that what I/O programming was in the hoary past, it is GUI programming now. Programmers hate the part where data has to be presented.

Re:GUI (1)

John Pliskin (769478) | more than 9 years ago | (#11682426)

Strangly in my CSCI 40 class (read: C programming), our teacher had us do more I/O then anything, to the point where any of us could do it in our sleep.

So to write I/O really does not bother me much. documentation....on the other hand....

$

Re:GUI (0)

Anonymous Coward | more than 9 years ago | (#11682437)


Ad hoc designs could be enormously good - like Winamp


You're kidding, right? Winamp is (was?) a reasonably funtional media player trapped in an almost infinite selection of hideous and unusable interfaces.

You trolls - you got me again.

Re:GUI (0)

Anonymous Coward | more than 9 years ago | (#11682608)

The original winamp was actually very nice, simple, and functional. The later versions had really bad UIs, cluttered, confusing, with stupid defaults.

Re:GUI (0)

Anonymous Coward | more than 9 years ago | (#11682795)

Don't they all use the same skins? More importantly, don't they all use skins?

Re:GUI (5, Insightful)

Phleg (523632) | more than 9 years ago | (#11682556)

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.

Ah yes. (2, Funny)

Stumbles (602007) | more than 9 years ago | (#11682138)

What more documentation do you need than the source code? Seems plenty enough to me, seeing as by and large only developers would look at it anyway. Even if a non-programmer wanted to spin their propeller on it, the original author is only an email away. Seems rather complete to me. Of course the analysis would not be complete without an equation. 43 sounds about right to me..... it's one better than THE answer.

Re:Ah yes. (2, Insightful)

generic-man (33649) | more than 9 years ago | (#11682195)

Yes, but the original author is not required to answer your question satisfactorily if at all. Companies that plan a massive roll-out of an ERP tool can't rely on ad-hoc support; companies typically expect a support contract of some kind. Some Linux companies offer support contracts, but only for products which they have chosen to support.

Re:Ah yes. (0)

Anonymous Coward | more than 9 years ago | (#11682549)

Of course, all of us geeks who have ever worked in, or used, software support know it's a huge, useless crock of shit anyway. The suits will figure that out eventually. Probably when someone tries to lay the blame for a huge, devastating bug on their software vendor and fails miserably.

Re:Ah yes. (1)

pjt33 (739471) | more than 9 years ago | (#11682224)

At the very least I want a bit of plain English so that I can use grep to find the part of the source code I need to read without having to work out the naming conventions and hope they're used consistently.

Re:Ah yes. (0)

Anonymous Coward | more than 9 years ago | (#11682701)

Mod parent troll. Have you ever actually programmed anything outside your parents basement?

Re:Ah yes. (1)

jdog1016 (703094) | more than 9 years ago | (#11682787)

Apparently many people in the community are either lazy or share your view, wrong as it may be. Anyone who has ever worked on large pieces of code knows this. Documentation in code is not only important, it is often as important as the code itself, and this is especially true in open source projects. Unfortunately, that still doesn't prevent it from being absent from most of them.

Documentation? (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11682148)

The disadvantages of OSS development include absence of complete documentation or technical support.

Yeah, it's nothing like closed source software, which always has complete documentation. I mean, look at Windows itself. All of that documentation about all of those API calls, lots of useful specifications about interoperating with the underlying kernel, plenty of specifications about the NTFS file system...

Oh, wait. It's all kept "secret". Nevermind.

Martin Taylor would say... (1)

E IS mC(Square) (721736) | more than 9 years ago | (#11682448)

Windows? Ask Martin Taylor. He whould say in some very specific scenario on some very specific platforms, for some very specific tasks, Windows code is, say, more maintainable by some certain set of people.

In other words, if he can paraphrase it, its like 'Hey, i can still compile it (windows code) in some specific cases!'.

Not always true. (1)

Richthofen80 (412488) | more than 9 years ago | (#11682149)

disadvantages of OSS development include absence of complete documentation or technical support.

I don't think this is true. OSS, by its definition, does not preclude lack of docs or tech support. There are lots of projects and commercial or public ventures in OSS that provide great documentation and technical support.

Individual developers or efforts spawn these things. Maybe the OSS community should set limited expectations in these fields and have a standards set. IE to be part of a certified OSS project (in whatever certification one would like to invent for this), a project must provide documentation for developers and users that covers X number of things. Same for tech support, require that levels of support be available and published, and turnaround times be expected, etc.

I think that things like docs and tech support and others are , in the non-OSS world, enforced by competition. (IE, Everyone's doing it, we must do it to be competitive). Maybe the competition paradigm will be replaced by a standards / certification paradigm in the OSS world. (IE, everyone's required to do this to get on sourceforge or something)

Re:Not always true. (1)

sdm39 (859661) | more than 9 years ago | (#11682334)

The main problem with OSS documentation is that a lot of the core team members are involved in the evolution of the project and the less inclined users are on the doc. team. That's one of the reasons it lags behind.

Mirror this article for closed source development. (3, Interesting)

dilvie (713915) | more than 9 years ago | (#11682159)

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.

But... (-1, Offtopic)

game kid (805301) | more than 9 years ago | (#11682164)

...is it digitally signe--nah, VeriSign's prices wouldn't help, nevermind...

Disadvantage? (2, Insightful)

null etc. (524767) | more than 9 years ago | (#11682171)

The disadvantages of OSS development include absence of complete documentation or technical support.

And this differs from commercial software, how?

I've spent 20 hours trying to figure out how undocumented or broken features behave in Rational's Enterprise Product Suite 2003. And that's expensive software.

I'll choose the software whose source code I can examine any day of the week. Granted, I'm a developer. But it's much worse to lack both documention and source code.

OCO is Loco (1)

KiltedKnight (171132) | more than 9 years ago | (#11682264)

That's what was on a sign in a coworker's office many years ago when I was working at a company that used IBM Mainframes, Solaris, and various other systems too.

It was one of my first jobs, so she explained it to me by saying that OCO meant "Object Code Only"...

Design docs (1)

cowboy76Spain (815442) | more than 9 years ago | (#11682199)

What I suffer more for are for design docs. I am not askind ERD, DFD or UML, but inline docs. For functionality docs there exist automated ways to make sure that developers write a minimum documentation (v.g., checkstyle can force people to document all Java methods if they want to commit them to CVS). The trouble is when I see a code (and I am not refering to OSS only) that performs the functionality in what looks like an odd way, just because the programmer did not care to write that "if you do it in the way you are thinking, you'll find those troubles". And, in a code that is tipically subject to change by a larger group of developers (and with less formal and informal communication channels) this can lead to adding the same bug again and again...

Re:Design docs (2, Insightful)

miu (626917) | more than 9 years ago | (#11682512)

Required javadoc/doxygen/VCS comments often result in "XXX: required for checkin" type comments.

Not knocking inline documentation - I think it is a great idea, but you have to make sure that developers buy into it.

Really there is a lot of common sense that can go into coding standards to help reduce recurring bugs in "problem functions". Rules for initializing and using globals, rules for maximum method length, code ownership, and small group code walkthroughs can do a lot to prevent the kind of problems you mention.

Re:Design docs (1)

tcopeland (32225) | more than 9 years ago | (#11682604)

> Required javadoc/doxygen/VCS comments
> often result in "XXX: required for checkin"
> type comments.

So true. Or, just as bad:
/**
* The getFirstName method returns this person's first name
* @return the first name
* @author Fred
* @version 1.2.1.3
*/
public String getFirstName() {
return firstName;
}
Argh!

Re:Design docs (1)

miu (626917) | more than 9 years ago | (#11682679)

...but that kind of passive aggressive joke is only really funny if you can manage to keep a straight face during a code walkthrough :)

Re:Design docs (1)

tcopeland (32225) | more than 9 years ago | (#11682744)

> a straight face during a code walkthrough :)

In the code reviews I've attended, this code would be greeted with "but where's the '@param none' Javadoc?". Argh++.

Is maintainability the problem? (1)

gelfling (6534) | more than 9 years ago | (#11682201)

OR is it complex melange of requirements, funding, skills, time, staffing, testing and packaging? I looked at LWN yesterday and noted there were 400+ different distros for Linux. Probably 300 of them are either orphans or one or two person operations or the work of whichever crop of college labrats are working the time. Maintainability in this context is really a matter of discarding 4/5ths of the code out there that should be left to die. Take the time, skills and money and build more cooperative projects over a smaller set of large distros. Or if that's not feasible, then break the problems down into snap ins that more generic.

Experience may vary... (2, Interesting)

moz25 (262020) | more than 9 years ago | (#11682229)

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.

Deja vu (1)

Bozdune (68800) | more than 9 years ago | (#11682235)

This is so reminiscent of other stupid claims of the past. "Cars can't go 60 mph." "Planes can't go supersonic." "Computers can't play checkers." "Computers can't play (pick one) expert level/master level/grandmaster level/world champion level chess." And so on.

Now it's "Open source can't build ERP systems." As if it's that f-ing hard to glue together an MRP system, an accounting package, and maybe some CRM and HR software. I mean, duh.

No suprise, some projects are best suited for OSS (3, Insightful)

segmond (34052) | more than 9 years ago | (#11682246)

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

Re:No suprise, some projects are best suited for O (1)

zutroy (542820) | more than 9 years ago | (#11682338)

But what incentive would the companies have to start an OSS project? Why not just make it closed-source and, at the very least, have "security through obscurity" (which DOES work, at least for a while)?

Re:No suprise, some projects are best suited for O (1)

segmond (34052) | more than 9 years ago | (#11682447)

If they are going to join and support an existing OSS project, then why not start one? Of course, why open source a project from the get go when they can sell it?, that's the problem. Just like they don't have any incentive for pure OSS project unless there is cash in it for them, OSS hackers don't have incentive for business type of software unless there is cash in it.

Corporate OSS is an Ad-hoc Corporate Alliance (3, Insightful)

Mr. McGibby (41471) | more than 9 years ago | (#11682523)

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?

Re:No suprise, some projects are best suited for O (1)

Homology (639438) | more than 9 years ago | (#11682411)

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

There are several examples of companies doing this, singly if not in group. For instance, Subversion [tigris.org] has paid developers to design and implement Subversion. X11 has seen quite a bit of paid development by various companies.

You don't want to know what goes into sausage (4, Informative)

melted (227442) | more than 9 years ago | (#11682252)

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.

Re:You don't want to know what goes into sausage (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11682387)

Bingo! Actually that's true of most closed source software. Software is usually closed source because the source code is ugly as crap. If you were to buy a building, you'd want to see the blue prints first before the building was built. If you want to buy software, you'd want to see the source code first. Companies don't want you to see the source because then you'd realize the software is nothing but a shakey foundation ready to collapse.

Re:You don't want to know what goes into sausage (0)

Anonymous Coward | more than 9 years ago | (#11682477)

Best. Post. Ever.

Re:You don't want to know what goes into sausage (0)

Anonymous Coward | more than 9 years ago | (#11682519)

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.

The Polish? The Polish are hiding turds? What kind of racist crap is this?


ERP (3, Insightful)

fatcowtoes (105989) | more than 9 years ago | (#11682280)

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.

OSS projects should be more maintainable (1)

zutroy (542820) | more than 9 years ago | (#11682281)

In a commercial organization, people are able to have face-to-face meetings and ask each other questions with few problems. In a widely-distributed open-source project, communication can be much slower and misunderstandings abound. All of this should be incentive to make clear, concise interfaces with method names and variables that are clear to another programmer. So it seems to me that the most successful open source projects (the ones with the most developers) probably have very clean and maintainable code. If anyone who has participated in Firefox would like to comment, I'd be interested in the clarity of Mozilla's code.

Guess we'll find out. (2, Informative)

Brent Nordquist (11533) | more than 9 years ago | (#11682297)

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

GNU | Enterprise [gnuenterprise.org]

Why not open-source ERP? (2, Insightful)

SharpFang (651121) | more than 9 years ago | (#11682301)

No joking here. An old question, what's the best accountant's answer to "how much is 2+2" is "whatever you'd like it to be."

Custom Enterprise Resource Planning software sometimes includes parts no boss would want the IRS or other authorities to know. With Open Source they become blatantly obvious. In this case Security Through Obscurity is the only safe model.

Sure a HONEST resource planning software can be open source. But it won't ever make the company as successful as one with some... extras.

Jakarta code is fairly damn decent. (1)

tod_miller (792541) | more than 9 years ago | (#11682310)

I actually learnt a lot of programming top from just studying the code as I integrated thier solutions.

People who write OS are because they are so good at what they do they enjoy it.

Let them manage thier code and quit bitching, not all OSS is a community OSS.

community (ala jakarta) are awesome and lovely, and better then browsing pr0n.

greenday on tv. it all keeps adding up... I think I cracking up.... hdfkasu0 rar.

bogus measurements (1, Interesting)

bluGill (862) | more than 9 years ago | (#11682321)

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.

In theory... (3, Interesting)

the_skywise (189793) | more than 9 years ago | (#11682374)

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.

maintainability index = bullshit (2, Insightful)

idlake (850372) | more than 9 years ago | (#11682383)

You can find a description of the maintainability index here [cmu.edu] .

If you look at the desription, you'll see that the equation was mainly "calibrated" based on a bunch of projects at HP. But fitting such an equation to a handful of self-selected projects doesn't give you any idea of how statistically valid it is.

Furthermore, the maintainability index contains measures that you would expect to go up as software systems become bigger; therefore, it isn't even a meaningful comparison of software systems of different size (or a single software system over time): maintaining a 1MLOC project is just a lot harder than maintaining a 100kloc project, but you may be doing equally well on both of them.

Particularly amusing is a term of 50 * sin (sqrt(2.4 * perCM)) in the maintainability index, where perCM is the average percentage of comment lines per module. As perCM ranges from 0 to 100, the argument for the sin(.) function will range from 0 to 15 (ponder for yourself what that means about how much you should comment).

Until someone produces sound maintainability data with hundreds of software projects, the use of MI is just bullshit.

No ERP, eh? (1, Informative)

Anonymous Coward | more than 9 years ago | (#11682386)

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

It is funny how sourceforge [sf.net] lists [sourceforge.net] several [sourceforge.net] ERP [sourceforge.net] -systems [sourceforge.net] then [sourceforge.net] . And the list goes on, by the way.

Open Source ERP (5, Interesting)

stiller (451878) | more than 9 years ago | (#11682485)

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

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.

Confusion (1)

shaitand (626655) | more than 9 years ago | (#11682494)

These gentlemen seem to be implying that open source is a development model when in reality it is a licensing scheme.

Microsoft might want you to believe open source is a development model they can learn from and harass the benefits of, but the truth is that open source is a set of rights and philosophy related to licensing. An open source project can use any development model.

I wish people would stop talking about... (2, Interesting)

m3741 (800673) | more than 9 years ago | (#11682544)

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.

Sin(Sqrt(comments_in_percent)) ??? (2, Insightful)

phkamp (524380) | more than 9 years ago | (#11682643)

Have you guys looked at the formula ?

They take sin(sqrt(mumble_percent)).

Now, I'm all for emperical data, but that is just bistromatics and totally insane.

They don't even say if the argument to the sine function is in degrees or radians and one is left to wonder if they even know themselves...

I have no doubt that if you take a piece of code and does a before&after check after some major rewriting it may tell you something.

But comparing two different pieces of code with this formula is just plain bogus.

Poul-Henning

Functions (0, Redundant)

Ann Coulter (614889) | more than 9 years ago | (#11682646)

This might sound too removed from the "real world" but as you will see very soon, I will give a perspective that is more practical than what I will assume to be a procedure used in a lot of development groups.

Every function must have an expectation specification that defines what the mapping of the said function is. The expectation specification must also define the domain of the function as well as the co-domain. Whatever variables that unchanged, up to an isomorphism, by the mapping can be excluded from both the domain and co-domain.

The expectation specification defines a Platonic object that is given an element from the domain and maps it to an element in the co-domain. The two important points here are that the specification is definite and that it is Platonic.

We never ever destroy an expectation specification. This point can not be stressed enough. An expectation specification defines everything about a function. If one were to destroy an expectation specification, then the associated function must never be reused. Therefore, one must never destroy an expectation specification.

We will now discuss the practical formulation of an expectation specification of a function. Each function accepts a subset of the entire system state and maps it to a new subset of the system state. One can give any isomorphism of an element of the domain. The isomorphism and the function makes the general form of the function become g^{-1} (f(g(x)). Here, f is the function and g is an isomorphism. Note that we have never mentioned how we should represent the mapping, domain, or co-domain or elements of the latter two.

One can assume that the result of the mapping will replace the element from the domain in most practical computer installations.

We have established that a function is defined by an expectation specification that is Platonic. This Platonic object is what developers will strive to emulate in any implementation of a function. Notice now that we have invoked the concept of an implementation. An implementation must never take precedence over the specification in the minds of developers. One function can have many implementations. Furthermore, a function can exist as an expectation specification with the specification represented somehow. Note, however, that an implementation is almost meaningless without a specification.

In conclusion, the specification is the function. A function may adopt various implementations for any number of reasons. The important point is that when one develops a function, it must endure. It might be used or kept somewhere, but a function must never be destroyed or changed.

With regards to the beginning statement, one must never omit the Platonic function. A very common mistake made by a lot of developers is the destruction of specifications. While their intentions might be benign, even a slightest change in a function must always lead to a branch into a new function. One can call the new function anything in the implementation language, and in a lot of situations, it is recommended. However the specification must always endure. The strict adoption of the approach where one develops an expectation specification, forbids any destruction of a function, and develops implementations based on the expectation specification, is crucial to the development of any project.

Quality is still a happy user (3, Insightful)

mcdtracy (180768) | more than 9 years ago | (#11682691)

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.

Failure to strip license header (1)

LetterRip (30937) | more than 9 years ago | (#11682711)

There metric that measures self descriptabiity, is going to be way off if they don't strip out the GPL license for projects that include it in every file.

LetterRip
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>