Developer.com has published a short article by Charles Connell in which he claims that "opening up commercial source code is a necessary step towards solving the widespread problem of poor software quality."

This secrecy is the key reason we have such lousy software. Software designers, programmers, and managers get away with bad code because no one outside their small workgroup ever sees it. Developers write code they are ashamed of because they are pretty sure no one will look at it. Managers encourage engineers to write "quick and dirty" code to meet the next project milestone, with confidence they will not be held accountable for their part in the poor result. I have personally witnessed these actions and suspect most other software professionals have as well. Commercial software is filled with bad design, horrible coding style, inefficient algorithms, and snide comments (or no comments at all).

The solution is to release all software with a copy of its source code. This is currently the practice with nearly every other engineering discipline, because their designs are open for visual inspection and physical testing. In addition, each software developer, designer, and manager should attach their name to the sections of code they work on. All code (good or bad) would be traceable to the people who created it. This sunshine policy would improve software quality for two reasons. Everyone involved in the software creation process would take more pride in their work because their names would be on the code. And any buyer who cared to could inspect the source code to make sure they were getting good quality. Of course, not every software buyer has the expertise to perform this inspection, but some do.

I can picture software executives everywhere clutching their chests in horror at this proposal. What about intellectual property rights? Wouldn't software companies engage in widespread theft of each other's hard work? No, they wouldn't, because this is already covered by copyright law.

I do not agree that the accountability for code would increase quality of code. Most organisations already has this stipulated and controlled in the software process and many times, the organisation is the consumer of its own produced code. The narrow the view on only looking on code that is licensed to a consumer I do not agree with, as alot of code is actually developed in house, by professionals and with "decent" timelines. During my time as a developer I've been wading through code, but none of them has been packaged and sold to anyone outside the organisation without the source code following the packaged product. The quality is still not apar with what it should be, even though every developer, designer, code reviewer can check who did a certain piece of code. The responsibility model only works if people can relate to really good design and models.

In my opinion there is actually three vital steps in increasing the quality of code that has to be accomplished and I will try to explain my views, what I percive is the current state of obtaining these steps.

Step one, we need to make people learn from how other people solve their problems and how good programming structure actually looks like.

It would be a great step towards this by making more commercial softwares source code available as it would be beneficial to education. Normally, most work involving creativity/engineering/logic are able to build upon what other has accomplished before them. Architechts can see how and what other architects have created before, they can themself collect the information what is to be considered good design. It is also the fact for work that involves logic, a good mathematician gets a good feeling when a good proof is found and presented, and they also has a wast amount of material to draw conclusions from and for themself learn the valuable lessons of what composes a good proof.As Richard P. Gabriel & Ron Goldman writes in their essay "Mob Software: The Erotic Life of Code" ( http://www.dreamsongs.com/MobSoftware.html ):Fast-lane capitalism has created a nightmare scenario in which it is literally impossible to teach and develop extraordinary software designers, architects, and builders. The effect of ownership imperatives has caused there to be no body of software as literature. It is as if all writers had their own private companies and only people in the Melville company could read ?Moby-Dick? and only those in Hemingway?s could read ?The Sun Also Rises.? Can you imagine developing a rich literature under these circumstances? Under such conditions, there could be neither a curriculum in literature nor a way of teaching writing. And we expect people to learn to program in this exact context?

And the simple answer is, we can't. If we are not able to learn from others mistakes and successes, we will repeat them. It has always been a part of the GNU manifesto ( http://www.fsf.org/gnu/manifesto.html ) thatSchools will be able to provide a much more educational environment by encouraging all students to study and improve the system code.

The complaint is usually the classical rebuttal of "How will we as programmers still make a living". We need to protect our turf to feed our family. Freeing the source does not, as the article explains correctly, in the instant we open it up, forfeit our work. The copyright has been with us all along. I can publish my code for others to read and admire or scorn, but it will still be mine.

Step two we need to make coders feel pride in their work, enough pride to leave their arrogance behind and see wisdom in other peoples solutions.I take great pride in my designs and coding, but I do not consider my code to be the ultimate answer, on the contrary, I always seek rebuttals from my peers to find what I could change to the better.

This brings us to step three, which is to have the ability to discuss great design or code with the same frames of reference. Without anyone argumenting that my design or code is flawed, how would I otherwise learn how to make it better. This is not fully here, but discussion forums (like http://www.artima.com/ , http://www.javasoft.com/ ) makes us it available altough they are not the ultimate solutions as the amount of irrelevant information is mixed with the rare tidbits of vital information. The response would to limit, but how to limit without creating an elitist club ( http://www.kernel.org/ ) is still up for debate.

> I do not agree that the accountability for code would> increase quality of code. Most organisations already has> this stipulated and controlled in the software process and> many times, the organisation is the consumer of its own> produced code. The narrow the view on only looking on code> that is licensed to a consumer I do not agree with, as> alot of code is actually developed in house, by> professionals and with "decent" timelines. During my time> as a developer I've been wading through code, but none of> them has been packaged and sold to anyone outside the> organisation without the source code following the> packaged product. The quality is still not apar with what> it should be, even though every developer, designer, code> reviewer can check who did a certain piece of code. The> responsibility model only works if people can relate to> really good design and models.> I agree with you here. I don't see how making code visible would provide incentive for developers and companies to create better software. I don't even agree with the author's statement that other kinds of designs, such as bridges, are open to the eye. Some of the bridge is visible, but not all of it. The bridge still has a visible interface and hidden implementation.

I'll third that. Having perused (yes, perused) some open source code, I was appalled at the poor quality of some of it. The simple fact that code is open source doesn't make it better quality.

I think that if a company were planning to release code to open source, they may want to clean it up. However, if they are forced to release it to open source, they might be motivated to dirty it up and remove comments, etc.

I see more validity in the arguments of the authorthan the other posters.

Making source code visible will not make code any worse,and will in some cases make it better.

Many companies do not release source code now,they will still not want to release source.There are professional obfuscation tools that dirty code up. Compilation can be seen as an extended obfuscation tool.Dirtied, obfuscated or compiled source is not source.

I don't think the quality of free code vs commercial codehas bearing on the discussion.There are other factors there.

I think open source inside a company is also different,internal developers are not trying toconvince you of the value of their code.

While I agree that the author's overall premise has some merit, I think many of the arguments put forth are weak. For instance, it is really not that easy for me to tell whether a house or a car is well constructed. The schematics, much less the original design documents of these are not available to me. When I buy a car, they don't give me all the blueprints and technical data on it. How do I know whether the thick strong-looking cables on a bridge are not hollow? I think some big lawsuits against car manufacturers were precisely because the designs, which were not available to public scrutiny, showed the vehicles to be dangerous, but the company decided it was not economical to make the thing safer. So, this whole idea that all other industries are open and transparent is false.

And on the other side, software is really not a black box at all. I bet many companies wish it were more so. You can get all kinds of reverse engineering and profiling tools for examining how software works, regardless of whether you have source. Hackers seem to have no problem updating compiled programs to behave as they like. Tools like bounds checker can tell you that a particular app behaves badly (has memory and resource leaks, etc.). Moreover, with software that comes in bytecode form (like Java, .net and many others) is even more transparent.