Code Quality In Open and Closed Source Kernels 252
Diomidis Spinellis writes "Earlier today I presented at the 30th International Conference on Software Engineering a research paper comparing the code quality of Linux, Windows (its research kernel distribution), OpenSolaris, and FreeBSD. For the comparison I parsed multiple configurations of these systems (more than ten million lines) and stored the results in four databases, where I could run SQL queries on them. This amounted to 8GB of data, 160 million records. (I've made the databases and the SQL queries available online.) The areas I examined were file organization, code structure, code style, preprocessing, and data organization. To my surprise there was no clear winner or loser, but there were interesting differences in specific areas. As the summary concludes: '..the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.'"
Re:Is it just me? (Score:5, Insightful)
windows is teh suck blah blah blah (Score:0, Insightful)
No-one has ever claimed (Score:4, Insightful)
CScout Compilation (Score:5, Insightful)
Given that the Solaris kernel has been compiled by two very different compilers (Sun Studio, of course, and gcc), it isn't that surprising. Because of the compiler issues, it is likely the most ANSI compliant of the bunch.
statistical wash-out? (Score:5, Insightful)
You found that '..the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.' -- or in plain English: "the app specs had a much bigger influence when compared to internal efficiencies".
I would wonder if you're just seeing a statistical wash-out. Are you dealing with data sets (tens of millions of lines and thousands of functions) that are so large, that patterns simply get washed out in the analysis?
Oh dear, my post is no more clear than the summary...
Re:Is it just me? (Score:5, Insightful)
Really? (Score:3, Insightful)
Re:Not that surprising (Score:4, Insightful)
Half completed, unpolished commercial software usually stays unreleased and safe from this sort of scrutiny. However many of the same types of projects get left out in the open and easily visible to everybody when developed as open source. The low code quality of these projects would drag down the average for open source projects as a whole.
On the lighter side, you could say that you'd only consider software that was "out of beta" or version 1.0 or greater, but that would leave out most open source projects and commercial "Web 2.0" products....
KLOCs? (Score:5, Insightful)
"To my surprise there was no clear winner or loser..." Not really a surprise at all, actually.
Re:Not that surprising (Score:3, Insightful)
The winner is still open source (Score:3, Insightful)
People make claims about the need for closed source all the time, usually revolving around the need to a predictable level of quality, or some other factor. The fact is, this results proves that its a wash whether you choose open or closed--so why not choose open?
There's a deep significance here I'm failing to capture completely. Someone else word it better if they can. But there didn't need to be some blow-out victory of open source over closed source for this to be a victory. All open source needed to do was compare--which it did, clearly--with closed source, in terms of value, to secure its worth.
Re:Is it just me? (Score:2, Insightful)
Re:The 99% Solution (Score:2, Insightful)
Much of the code in Linux, for instance, is drivers.
Re:Is it just me? (Score:5, Insightful)
Re:Really? (Score:3, Insightful)
What he says is that a cluster of metrics that collectively say something general about code quality (e.g., better code tends to have smaller files with fewer LOC; worse code has more global functions and namespace pollution) show little difference between four kernels with diverse parentage.
He speculates (and says he is speculating) that obvious differences in process might account for small variances in where each kernel scores well or badly.
Re:Stupid metrics (Score:4, Insightful)
Using one of the tools you propose, you will still not obtain results regarding the analysability, changeability or readability of the code.
This is virtually baseless (Score:2, Insightful)
It's a well known fact that code will always resemble the institution that produced it, to some extent. To describe the Microsoft code as "poorly structured" is likely a bit out of touch.
The absolutely best kernel code is generally extremely beautiful and descriptive when dealing with the system's abstracts (with nice, long descriptive names for each function) and then unbelievably hellish and ugly in the sections that deal with hardware. Kernels represent an intersection between the idealistic system code and the hideously complex and inhuman machine interaction code. For this reason, we gauge the value of the systems based on how cleanly they compile into assembly, their performance, and ideally how well they do what they were written to do.
Kernel code fills such a complex role in the computer science paradigm that it is likely impossible to gauge the value or quality of any of them through any sort of automated means. What we have here is a mess of a research paper that comes to no obvious conclusions because they didn't really discover anything. If it were of any value, its final summary and conclusions wouldn't be so obfuscated. The researcher may or may not have mastered the art of understanding the zeitgeist of kernels but he certainly hasn't mastered the research paper.
Re:"Code quality" is bunk (Score:4, Insightful)
It has lasted that way for a very very long time.
Is it good code simply as function of its survival and (sort of) working?
I tend to think of good code like good engineering or good architecture. Surely you wouldn't define good architecture as "a building that remains standing," would you? The layout of the rooms, how well that space is used, how well it fits the needs of the users, how difficult it is to make modifications, etc all factor in to "good design" and have nothing to do with whether the building "works."
I am not sure you can put a metric to it anymore than I could put a metric to measuring the quality of abstract expressionism or how well a circuit is laid out--there may be metrics to aid in the process, but in the end one can't necessarily assign a numerical rating to the final outcome for the purpose of rating.
That doesn't mean that there isn't such a thing as good quality and bad quality code.
Re:Not that surprising (Score:4, Insightful)
Re:statistical wash-out? (Score:4, Insightful)
My personal opinion is that if statistics are a wash-out in general, then the researcher is asking the wrong questions. I know that the author pre-defined his metrics in order to avoid bias, but that's not necessarily good science. Scientific questions should be directed toward answering specific questions, and the investigatory process must allow the scientist to ask new questions based on new data.
There is clear non-anecdotal evidence that these operating systems behave differently (and, additionally, we assign a qualitative meaning to this behavior), so the question as I understand it is: is this a result of the development style of the OS programmers? The author should seek to answer that question as unambiguously as possible. If the answer to that question is "it is unclear", then the author should have gone back and asked more questions before he published his paper, because all he has shown is that the investigatory techniques he used are ill-suited to answering the question he posed.
Re:Is it just me? (Score:5, Insightful)
If I seem overly critical, I do not mean to, it is only that I hate to see good, useful research made less accessible to non-academics by the use of academic language.
Re:Not that surprising (Score:3, Insightful)
The problem with your conclusion is that it assumes that code quality as measured in this sort of way is the only or even the most important thing.
It's like buying clothes. Sure, the quality of the clothes you're buying does matter some in making your choice. So does price (which you mention above.) But, what the clothes look/feel like is also often important, and something like whether or not they actually fit you can trump all of those concerns.
In general I would say the open source world (as represented by the best known / flagship projects) produces higher quality code. It's better at finding and fixing bugs. It's often better at fixing inefficient algorithms and the like.
What it's generally [i]not[/i] as good at are higher-level or market-driven concerns, like if a UI is just bad and needs to be replaced whole-cloth, or if key feature that a developer would never use but that most users will want is present, or if documentation is provided or of sufficient quality.
As long as that's true, both open and closed source projects will continue to exist. They're best at different kinds of things, and I would argue they exist in a kind of symbiosis.
Re:Is it just me? (Score:3, Insightful)
Re:Not that surprising (Score:4, Insightful)
It will, in the end, come down to a value proposition. The value proposition of freedom to modify code is very hard to quantify, so that will probably factor into the eventual success of open source not at all. The actual quality, usability, documentation, trainability, ease of install, compatibility with existing infrastructure (usually Microsoft), etc., will probably be the deciding factors, and I don't see open source having a clear-cut advantage in those metrics.
Re:KLOCs? (Score:3, Insightful)
Re:No Clear Winner, but... (Score:3, Insightful)
Weird logic (Score:3, Insightful)
Re:Makes no sense anyway. (Score:2, Insightful)
Re:No-one has ever claimed (Score:4, Insightful)
Open Source Case for Business [opensource.org]
Having worked heavily in both areas of software development, I think this particular article's conclusion was obvious: code quality depends on the people who wrote it, not the process the used to license it. But only people who have done extensive proprietary and open-source development could really see that first-hand, and our opinions are automatically dismissed as being pro-Microsoft shills. Thus, I predict this paper will be roasted over an open flame, crushed into a tiny ball, soaked in gasoline, lit on fire, and ejected into deep space by the most devoted open source proponents in both camps.
pointless handwaving (Score:3, Insightful)
Re:Not that surprising (Score:3, Insightful)
You seem to forget that the Linux forums are generally stellar for resolving HOW-TO questions. Additionally, there are FAQs and instructional blog posts that are readily accessible through Google. In other words, "Toggle That Doohicky" is easily obtained in the FOSS environment as well, and can be done WITHOUT sitting on hold and taking your chances with the quality of the rep who answers.
Additionally, if the source were available, features you want could be added, someone ambitious enough could actually investigate *why* the damn thing works the way it does, and it'd probably have working Linux and Mac versions by now.
Re:Not that surprising (Score:3, Insightful)
Then restrain yourself to "what Fedora ships" or "what Canonical supports in main". These are the presumably viable software products with a living upstream.
But you missed an interesting problem: failed commercial programs sometimes convert into open source projects. Its not clear to me whether this is a positive or negative effect. Are there more s out there or [aaronbishopgames.com]Blenders [blender.org]? Is the OpenOffice.org software good or bad?
Re:Is it just me? (Score:3, Insightful)
First, Mr. Spinellis I found the report to be rather intriguing and captivating. I much respect the work put into it, and I think it'll prove valuable resource for study or reference.
With that said, the above quote struck a chord with me.
Let's take fire control systems for weapons of mass destruction. Without going into detail, the basic fact is that if a thermo-nuclear warhead is launched from Russia, France, UK, Isreal, US or any other country, it was and will be a deliberate act. The systems are far too complex and far too reliable for error or mistake. In other words, regardless of political position, no ruling body is going to ignore the possibility of an oopsie launch.
So, I do understand, that certain objectives, though may be approached and implemented vastly differently, will have strong similarities in the end result and with how it was successfully applied.
My problem is with this. What your saying is that there is no quality difference between Windows and Linux, and this is the discordant chord struck.
I can not extrapolate the agreeable portions of your thought to the seemingly obvious short comings of the Windows operating system. On any facet, whether it is security, stability, functionality or reliability. Windows is, far behind on all fronts.... aside from secrecy from a Microsoft point of view.
I once told my boss, who well understood, that he would never get the quality of code from me in the workplace as I might submit for the Open Source realm. It's just painfully obvious, that I will, at some point, hack an improper solution together for his deadline. And the nature of business, after the product is built, no one wants to change it unless they have to. So, while the economics all come into play here, why Microsoft might choose to fix one bug versus the other, the fact is in Open Source a bug will be fix on merit of a fix being available and acknowledgment that the bug is in fact a bug. Regardless if it's economically sound or feasible to fix the bug, in Open Source, it will be fixed.
While the end results that you present are interesting, I can not accept the proposition that the Windows kernel is too similar in quality. All one has to do is actually use the blasted thing, and no amount of numbers can be that convincing to ignore all the pitfalls well perceived from actually using the dreadful software.
I think you have overlooked overwhelming variables that directly effect the quality of software. Or, perhaps, the WRK has been a meticulous focus at Microsoft before it's release... this is likely possible, as it's WIDELY known, from nearly ALL examples of closed source proprietary software being released to the Open Source, that it takes years just to clean up and prepare for the ultra high standards of the OS community.
Re:Is it just me? (Score:3, Insightful)
Only a small portion of the
Even amongst that population, only a small percentage are qualified in large operating systems development.
Similarly, a small percentage of the programmer subpopulation of
The target population of the paper are people who fit into all three of these groups. Thats not very many people.
I've been doing software development for a living for almost 2 decades, but arent familiar with many of the metrics and approaches used to analyze the source code (of course some, like cyclomatic complexity, line lengths, operands per line, etc etc I am familiar with).
This is incredibly narrowly focused stuff, even for