Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
One of my favorite things about being a writer is hearing comments from readers about my work. I have even learned to have a thick skin when readers tell me I am an idiot. My last article on Developer.com was no exception. In that piece, I presented the idea that all commercial source code should be open. In other words, part of the delivery package for any software purchase should be a copy of the source files. I argued for source code transparency with the goal of improving quality. If everyone could see a software vendor’s design and coding, the vendors might stop shipping us such lousy programs. The article generated a fair amount of controversy on this Web site and others that linked to it. Some readers agreed with me, and many did not. Several repeated the observation about my general lack of intelligence.
Included in the printable mail were critiques that raised valid points, which I want to respond to. I still hold to the basic premise of my article, but have come to believe it needs to be adjusted in its details. The primary objections to my article center on these areas:
- Key parts of complex software systems are true intellectual property of the creators, and the owners would never open up that code.
- The copyright laws in the United States might be a good deterrent to theft of U.S. software within the U.S., but they are no help in other countries.
- Some source code has national-security purposes and opening it up would compromise the defense of the country that created it.
- Safety-critical software already is inspected closely for quality. There is little additional benefit to letting software buyers look at it.
I’ll discuss each issue in order.
Intellectual property—The solution to this problem is simple. All commercial software should include a copy of its full source, except for a few crucial algorithms. Well-designed software isolates important functions into small, non-redundant subroutines. Those routines simply can be replaced with empty stubs prior to including the source code in the purchase package. Customers could even compile and link the source files, but the resulting executable would not operate in a meaningful way without the key routines. In any large software system, the truly unique code probably accounts for about 1% of the source. By releasing all the other pieces, a company can show off the quality and design (or lack thereof) of its software product, while still protecting its intellectual property. If the key algorithms are not isolated in a few small places, customers should see this, since it is indicative of poor design.
International copyright laws—This is an excellent point and I’m glad someone raised it. Theft of copyrighted material (including software CDs) is a big problem overseas for U.S. companies. The theft is often impossible to discover because it happens in dark warehouses in faraway places and is even harder to stop. Attempting to bring a lawsuit against these software pirates is a joke because they do not operate on U.S. soil and our courts cannot recover their assets. If dishonest people in the world have access to source files along with the executables, their thievery will certainly increase. The solution is similar to that proposed above: Ship the complete source code, minus the constant definitions. In the C programming language, this means excluding the #define statements; for Basic, it is the const statements. For more protection, exclude user-defined data types also (typedef in C, type in Basic). A customer could examine the software design closely or even compile the code (with a little effort), but the resulting program would do nothing. The goal of my proposal—allowing customers to look at software quality—would still be met without the constants and types. What if the source code contains hard-coded strings and data structures, rather than symbolic constants and user-defined types? Shame on the designers; their indiscretion should be on display for all to see.
National security—This is a valid point, but the principle of software transparency can still be applied. The customers for this type of software are national agencies and military organizations. The contracts between the software vendors and the receiving agencies should include provisions for some type of inspection of the source code by the customers. (This may already be the case in some instances, but I am not privy to the details of these contracts.) The intention is that software vendors stand behind their design and coding. Currently, software is delivered as a black box, with vendors able to hide horrible programming practices. Allowing inspection (by the relevant agencies) of software related to national security will accomplish this goal.
Already inspected—In response to my article, I heard from a reader who argued that important software already is inspected for quality. He referred specifically to safety-critical software for national transportation systems. While it certainly is true that some conscientious vendors are especially carefully with life-critical software, not all such vendors take proper care. A scan of news:comp.risks illustrates this quickly. The other problem is there is a huge difference between inside versus outside inspection. A quality-control group that is part of the same development organization as the programming team cannot make an objective assessment of software quality. The potential for conflict of interest is just too great. Imagine a company that is about to lose an important contract if the software does not ship on time. Is the quality control group really going to have the independence to halt software delivery if they have questions about the code? What if halting delivery puts the whole company in financial peril? A software development organization cannot police itself. Source code transparency solves this problem by allowing any customer who chooses to inspect the software, or to hire someone else to do so.
The general problem I described in my article is that software is different than many other types of engineering because of its lack of internal visibility. It is easy for software vendors to hide bad design (or no design) and embarrassing coding gaffes because customers cannot see inside of executable code. Allowing customers to see underlying source code will force software development organizations to improve their products and processes. I appreciate the comments from readers who helped me refine the details about how such openness might be achieved.
About the Author
Charles Connell is president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics.
