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. "
If they excluded PERL.
by Ioannis Samoladas, Ioannis Stamelos, Lefteris Angelis, Apostolos Oikonomou ...it was all Greek to me.
I just keep my code on one 3 1/2 inch floppy.
Haven't had a problem yet....
$7.95/mo, 200 GB disk, 2TBxfer, MySQL, PHP, RoR.
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?
GNU General Public License (GPL)
Berkeley Software Distribution (BSD)
are all defined in the article.
But not ERP.
Go figure.
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.
One need only peruse the source code of 5 randomly picked source forge projects to figure this one out.
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.
Commercial open source can work. Look at Qt. Its well documented and maintained. DUH!
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.
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!!!!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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.
My karma is not a Chameleon.
...dared to challenge this article.
(insert rousing action-series music) Hercules!
You can hold down the "B" button for continuous firing.
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.
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)
Reason, free market capitalism, and individualism
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
In my day, we used punch cards, and once you made a hole, it was there for life.
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.
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...
Why can't
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.
...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.
You can hold down the "B" button for continuous firing.
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
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.
"Informative," please.
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
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.
It was one of my first jobs, so she explained it to me by saying that OCO meant "Object Code Only"...
OCO is Loco
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 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.
GNU | Enterprise
Brent J. Nordquist N0BJN
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
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.
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)?
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.
You can find a description of the maintainability index here.
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.
However, it is still questionable whether systems like ERP could be developed successfully as OSS projects.
It is funny how sourceforge lists several ERP-systems then. And the list goes on, by the way.
There are several examples of companies doing this, singly if not in group. For instance, Subversion has paid developers to design and implement Subversion. X11 has seen quite a bit of paid development by various companies.
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.
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.
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.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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!'.
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.
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.
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
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.
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.
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.
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
Poul-Henning Kamp -- FreeBSD since before it was called that...
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 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.
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.
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
But, OSS wins.
OSS is no silver bullet. Their last point is "OSS code quality seems to suffer from the very same problems that have been observed in CSS projects." Er, big surprise, they're all software.
- David A. Wheeler (see my Secure Programming HOWTO)
I work in a fairly large entertainment company with worldwide reach (posting AC for obvious reasons). Not long ago the company abandoned the system they had (EMS) and spent billions (yes, billions with a "B") replacing it with the abomination that is SAP.
Yes, it's sad but true that the new system can't do something as simple as prevent duplicate invoices from being paid--something the old system did quite fine. I swear--whoever came up with the stinking, rotting, fetid piece of garbage that is SAP ought to be forced to use it. Their heads would implode after about fifteen minutes or so.
One would hope the relentless march of consolidation would end and end soon, but I doubt it. As long as decisions to purchase business software is in the hands of people who don't have to deal with it, things are only going to get worse.
but i will post some redundant, irrelevant, and misinformed spam.
Development sux when more than one person is involved.
What would improve open source development would be:
Every project MUST have a concise description of objectives.
A concise architecture overview.
Some flow charts?
Modularity.
What would be nice is if someone designed a nice CVS like system where anyone could submit patches. The system would force submitters to create a useful description of:
what the patch does,
how it works
why the patch is needed,
what sections of architecture it may effect
possible future improvements required
documentation
other notes
The system would workout what files the patch effects and any other stats and create a database entry, then post a report on a relevant section of the projects web site. Patches could then have a rating system so users could vote on quality of patches, quality of patch documentation, add comments, improvments, etc..
Would this be better than the typical mailing list?
I dunno but i think sometimes when people make patches they are often hacks that are not of sufficient quality for inclusion in a project or are only of use for a very narrow audience. If a project allows all submissions to be shown and rated it would give more democratic control and make it easier for project leaders to sift the wheat from the ergot.
This has probably been done already(I just havent seen it yet), tho I doubt this helps anyone and complex things are never going to be made easy.
embedded linux
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.
It's just my opinion, but I think if people stopped using older languages like C and moved to more self-documenting languanges, things would be a lot easier. For instance, Objective-C self-documents its own methods (i.e. "[object doThis:that forThis:that];").
- 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.
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!
I found that progress of open source software can often be measured by the availability of generic code. Once that code has been written as a generic library, collaboration is easy and higher level code is more maintainable. This is where Open Source software can have one huge advantage: Collaboration can take place on the libraries, and many applications take profit from that work *between different projects*. You have much more possibilities then in commercial software projects, where you seldom share much work between companies.
That also makes generic code even more important for OS. We have seen huge progress in the last years and most of the lower level stuff has appeared or become more mature.
Unfortunately though, this is also what I still found to be the most lacking in higher level libraries. Most projects go like this:
"We need a really cool search front-end for Google. Let's see whether there's a cool library for this. Nothing yet? Ok, then let's just start from scratch."
And then a library is implemented, with an API for searching using Google. It is perfectly usable for exactly what the developer wanted.
Now this seems reasonable at first, but think about this: In OS development, we are not bound to time lines. Why should we chose a half-hearted attack on a problem that will surely hit others after us again? Instead, the developer could also ask, "if I create a generic library, how generic can I make it? Do we have to limit it's capabilities to requesting stuff from Google? Or maybe I could even create a library that allows to query any search engine? Or maybe, provide an API the lets you query anything, like search engines, your local hard disk, p2p networks and a local database."
In commercial software development, this would be completely unreasonable overkill. In OS however, it's a great way to collaborate. And once implemented, the foundation for a lot of applications has been lied. And it's also fun - writing libraries is fun. It is a great component model either. And it is also a pleasure to see when the work is done, because once the foundation was set writing the actual application is as easy as plugging components together.
There are also good examples, of course. Gstreamer is one. But there is still so much potential. I would like to see this kind of thinking more and more.
what about star office -> open office? Isn't that sort of close to what you want?
But ya, I know what you mean. I'm not a coder, just a consumer, but I would be more than willing to pay good cash (not x -hundreds, but maybe x-couple/3 dozen dollars) for an OS (once a year, not 3-4 times a year scamola) that paid all the developers, was still open source, had fewer apps but all of them *worked* and if I had a question or problem still remaining, I could go post on their bulletin board and get an actual for-real honest informed reply, from a paid company person, that answered my question or resolved the problem or at least determined that it was in fact pretty close to impossible to be resolved. Tell me the truth in other words, I can live with it. I'm getting sorta tired of "yep, we gots us a real community volunteer effort and it's gonna be the bestus and it almost works, just you wait until the next release!!11!1" stuff.
There's an open source business model that might work to sell a real joe consumer desktop and still pay the coders. I'll pay for 20 really well written apps with extensive user accessible written in hoo-mann speech docs, said apps that work and serve basic normal computing functionality for this "the masses" guy (moi and probably millions more), but I am not going to pay for two hundred or one thousand "almost works" volunteer apps on 6 cds and a dvd plus download even more!, etc , including the no credible help even if they have a so called wiki or board or mailing list or irc channel. Nope. I used to believe that but not any more. Not prudent any longer. This is 2005. We have entered the "better work right now right when it's installed" era, not the "coming soon" era, that was LAST century.
signed, joe consumer
Although you intented to flamebait, the joke invites the consideration that some languages make it harder to write clear specifications and some make it easier. /also/ allow for "quick and dirty" style which is ideal for little tasks. If you maintain that style for larger programs, it is exclusively the fault of your lack of talent, methodology and wits as a programmer.
In Perl's case specifically, the language lends itself to quick scripting and shorthand. This is great for little tasks, but as everyone knows, it doesn't scale well. This isn't Perl's or Larry Wall's fault. It was designed to
However, I would like to point out that some languages actually enforce a clean specification. In particular, the functional languages almost literally *force* you to it. I am thinking here of the likes of SML, Haskell, OCaml, Clean, etc. This is not the place to discuss the fact that they also have a sane type system, where others have a broken one (e.g., C - see: http://perl.plover.com/yak/typing/). Language advocacy sucks, anyway ( http://www.perl.com/pub/a/2000/12/advocacy.html).
There's this story a guy posted once on comp.lang.functional about how once he wrote a Haskell program, handed it to the manager and he said: "great, you wrote a specification, now write the program." (!) The manager actually though what was executable Haskell code was just a "spec." Haskell fully suppports Knuth's literate programming approach.
If you ever tried writing something in those languages you know how they force you to write clean code. It is simply the easier way to break code in small functions. "Factoring", I believe it's called.
My point is that I feel the OSS community could greatly benefit from non-mainstream languages. These languages have seen nearly 2 decades of intense research. Arguments pertaining to performance just don't hold anymore vis-a-vis other mainstream languages like C#, Java, Python, Perl, etc. Clean has a video-game library to prove the point (http://www.cs.ru.nl/~clean/). OCaml, SML and Clean approach C performance (Ocaml coming second to C in some "language shootouts" for most benchmarks, for all its worth). Also, some of these have been used in large "real world" problems. OCaml has been deployed in the C code verification for correctness of the flight control software for the Airbus 340 airplane, for instance (http://www.astree.ens.fr/). It is widely known that Ericsson uses Erlang for their telephony switches (www.erlang.org). The CIL - Infrastructure for C Program Analysis and Transformation is written in OCaml and if more widely known, could prevent the weekly flow of buffer overflows developed in Berkeley and can be used *right now* in large OSS projects (http://manju.cs.berkeley.edu/cil/). They've tested it in the Linux kernel, for example (whether they sent patches or not, I don't know).
Of course, you have to have an open mind, and be willing to learn and throw some old tricks out and work using a different approach/mindset. Learning things thoroughly is always hard work, but the OSS shouldn't dismiss functional languages as "academic" - and for that matter, other serious approaches, like Squeak Smalltalk, for instance.
My 2 cents.
PS: I'm no expert at programming, just a beginner, but I offer my opinion here because I feel some people just haven't been introduced to some facts and haven't heard of some stuff. Not everyone has a big company to promote their language.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
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 that is their idea of "maintainable", they didn't fail because they shot for maintainable, they failed because they drank the kool-aide and trapped themselves into software paradigms that only work when oodles of resources are thrown at them. Smaller teams require more agile methods to get results, and that is also the mechanism whereby smaller teams can produce software where larger teams failed. (It goes both ways, I'm not claiming that as an absolute. But that small teams can and have beaten much bigger ones is an unassailable fact.)
Certainly you've got some good facts at hand to learn from, but I think you're taking the wrong lesson away. Projects that simply ignore maintainability fail, too. Can you imagine Mozilla with no concern for maintainability, or the Linux kernel?
The focus should always be on product quality, not code quality.
If you don't have quality code, you don't have a quality product. You may have an adequate product. You may be in a situation where an adequate product is all you need. I have an adequate set of knives in my kitchen, because I can not afford quality knives. But I do not pretend that they are therefore quality knives.
You're calling for a classic short-term focus, and you can and will suffer the classic penalties for short-term focus. I know, I've seen it first hand and dragged software products out of their local optima by the sweat of my brow. It's not easy, but either it happens or the product dies a code-quality death.
You need to use the proper metric for quality. Inappropriately using and paying for a strong type system is anti-quality in my book; that goes for your other two examples as well, when done correctly. (SQL and JSP code both need to be rationally minimized via the application of Once and Only Once, but they are not the cause of the unmaintainability; the abandonment of Once and Only Once is. Once and Only Once is one of the most important aspects of any proper quality metric.) Your quality metric should have functionality built into it.
In my experience, that's "petrified" code. Suppose the last maintainer dies (or becomes a Windows programmer). For someone to pick up the code base then the code itself has to be of a skill level lower than the person using it OR documented enough to explain those complexities that aren't readily understandable.
That's the one area where Open Source is weak. Closed Source can (again) throw money at the problem and fund a code "archeologist" to go through and resurrect the code base. Open Source requires individuals willing to have the passion to do so (although other open source individuals could fund the resurrection and then modify it to make it more open). But I think it more likely that if BSD did "die" this way then most people would just switch to Linux rather than spend the effort. (Not to be offensive, I'm just being pragmatic.. I could be wrong on the passion and number of BSD people).
This sounds kinda fishy...they say they "measured" 5 OSS projects but never mention which ones or which versions. You would think that this sort of "impirical analysis" would provide actual projects so the results could be verified.
Talk about one software to do it all...
Developers often have this attitude hold no reguard for the people who have to support it. I can tell you that its a nightmare to support applications, toolkits etc that half-baked features ie - things that may actually work in testing, but in a real environment are impractical and unsupportable.
"The disadvantages of OSS development include absence of complete documentation or technical support."
The article went on to say "On the other hand, the disadvantages of commercial software include absence of complete documentation or technical support."
"All the comments and documentation in the world won't make spaghetti understandable or maintainable"
A jar of spaghetti sauce will however make it edible.
" If it's sufficiently important to you, then you can pay someone else to grok the code for you."
Yes. Now once again, why should you make more work for either yourself or others?
"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."
And we're inviting most of them over from Windows, and encouraging them with tools like Mono.
Maybe OSS is just Mashovanist?
"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. "
And have to jump through the same hurdles as everyone else.
While they admit further research is needed,
It's not usually all that hard to get people to "admit" that they'd like more funding.
disclaimer: that was not meant as a rant, I work in science myself. But "more research is needed" is a running joke in the community. It doesn't detrect from the work, but every publication on the planet includes it, and every serious reader treats it as a mere formality and silently ignores it.
sudo ergo sum
TinyERP, GPL licensed. Note: home page is in French. And the fact that it's GPL does not mean you can download it for free from the author's website.
Donate free food here
Code is art, and good art is a joy to interpret. Bad art is well, bad needing little to no documentation at all. So, in the end, code is self documentating. I can look at code for seconds if not less and determine if it was done by someone with style, a thorough understanding and a desire to share that vision with others, by the work. Not someone telling me what it should or could do, but what is apparent by its implementation. I find documentation sort of like a salesman for a art gallery, its always hovering over interpreting the work for you or how great the artist is supposed to be. I'm usually left unimpressed, and much wealthier as a result for not buying into the habitual lies.
--- Old Time NeXThead
"Perl is "unclean" for a reason - it is there just to get the job done quickly, not necessarily cleanly."
...
I have to admit that it is harder to write readable code in Perl than in other languages.
There are a lot of features that are the cause of this, namely anonymous hashes and functions. The strange object oriented syntax. The default variable $_
On the other hand I can express a lot more in one line of Perl than I could in e.g. C.
And with a little practice even a line such as this:
return undef unless defined $self->{test};
gets readable. It even looks a lot like Python.
So what do you do to solve this dilemma?
Comments of course. Comment every regular expression and also every function.
And don't come back to me with C. Missing support for hashes and dynamic arrays (if you don't use glib) and missing garbage collection is a too big drawback.
My advice: don't use C for anything that can get messy..
Ah, the holes may have been there for ever (modulo tricks with sticky tape), but clever people could always make more holes.
P.S. I'm not joking, If all they keypunch machines were in use it was sometimes faster to modify a card or two using the hand punch, adding extra holes to a card.
UEA computer lab, 1977-78.
Watch this Heartland Institute video
"All the projects that I have been on where code maintainability has been the primary goal have one thing in common. They all failed."
:-P
They all had one other thing in common as well: they all had *you* working on them.....
That's management. Developers want to do what's right, but their management allocates about a half of the time it would take to do something right to any given task at hand. A polished turd is good enough for the management. Pressure developers to work on "compressed" schedule, then pressure test to certify the product before the deadline, throw all the bugs test finds over the fence to the next version. That's the product cycle of a software product for you. And then the product goes to sustained engineering team who doesn't know jack about the codebase and they fix it using their own assumptions. This is why fixes often result in more bugs - their assumptions may not be correct.
And no, developers don't have time to go back and revisit the TODOs everywhere in the code. TODOs remain TODOs forever.
And the chances of picking up a subtle bug in a comprehensive automated test system that runs at least nightly, compared to running "a few critical test cases" on the whim of a developer, are orders of magnitude higher.
Please don't confuse the bad idea that is "test driven design" with the good idea that is designing your code so that it can be tested regularly and automatically. The two ideas are completely orthogonal.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
So I've been told, sometimes by some of the biggest names in programming. Unfortunately, a firm belief among the industry doesn't make them right.
Rather than debunking this one here, I'll simply refer you to Steve McConnell's excellent Code Complete. McConnell cites a large amount of hard data to show that longer routines can be at least as good on both development time and error count grounds as shorter routines, and indeed exceptionally short routines (the 10-liners you're advocating) are amongst the worst on both metrics.
As an aside for general interest, since I'm sure a lot of people reading this comment also found that book very good, it seems a second edition has recently been published, updating the examples by a decade or so and putting much more emphasis on recent coding approaches, particularly OO. Whether that is an improvement remains to be seen, but I'll certainly be buying a copy. I guess if he's reversed his position based on more recent studies, I'll have to eat my words, too, but I doubt it. ;-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Inheritance IS using function pointers. C++ classes are really just structs with function pointers in them. C++ does it formally and probably cleaner than many programmers would, but to say "function pointers are evil" and then promote inheritance is a bit contradictory.