---

Developer.com: All Source Code Should Be Open

“Software, on the other hand, is a crucial piece of engineering
that is shrouded in secrecy. Experienced software developers cannot
look into the source code of Raytheon’s air traffic control system,
Windows XP, or a dental X-ray machine to see how they are built. We
cannot see the number and depth of comments in the code, the
calling sequence of the routines, the clarity of the variable
names, or the simplicity of the executable statements. This fact
makes software vastly different from other important products. We
cannot see whether we are buying junk or quality. The physical
equivalent would be a new bridge with all structural parts encased
in impenetrable black plastic, and the builders asking us to trust
them that everything is okay. As a public safety measure, we never
would allow this. Similarly, few people would buy a house if the
contractor refused to allow a home inspection prior to the sale.
Unfortunately, this is how we buy software. Software systems have a
huge global importance, but their structures are hidden from
independent inspection.

“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…”


Complete Story

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis