Under the Brim Interview with David A. Wheeler, August 2002

This is a transcript of Red Hat's Jeremy Hogan interviewing me (David A. Wheeler). The interview was originally published in Red Hat's electronic magazine "Under the Brim" on August 2002; the actual interview was held earlier in July 2002.

1) So, who are you in fifty words or less?

I'm a software researcher and developer interested in how to develop "risky" software systems (primarily systems which are large or have to be secure). I've written books on how to write secure programs, Ada, and software inspection. Outside computerdom, I'm a Christian living in Northern Virginia. My website is at https://www.dwheeler.com.

(Note - the original Red Hat posting added some odd quote here about reading The Economist and The Nation. This was not in the interview, and was accidentally cut and pasted into the text. Jeremy Hogan of Red Hat said that it “Looks like someone used a template when they posted. It should come down within the hour. It's from someone else's interview... Sorry 'bout that.”)

2) What made you decide to write some of you[r] papers? For example, what's the motivation behind "Why Open Source Software/Free Software (OSS/FS)?"

Actually, I had different motives for writing different papers/books.

My paper "More than a Gigabuck: Estimating GNU/Linux's Size" (https://www.dwheeler.com/sloc) came out of pure curiosity. It was clear to me that GNU/Linux systems are extremely capable; I was very curious to know how much code was in it, as well as how much effort and money it would have taken to develop using proprietary means. No one could tell me, so I did an analysis of Red Hat Linux 7.1 and found the answers (30 million physical lines of code, 8,000 person-years, and $1 billion). I wrote the paper because I suspected that others would share that curiosity. I believe that if you want to know something, don't just wonder - go and find out!

My book "Secure Programming for Linux and Unix HOWTO" (https://www.dwheeler.com/secure-programs) explains how to write secure programs for Linux and Unix. I saw different developers falling into the same security pitfalls, again and again, and I found that disturbing. I developed the book in the hope that future software developers won't repeat past mistakes, resulting in more secure systems for everyone.

My paper "Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!" (https://www.dwheeler.com/oss_fs_why.html) started because I had become very interested in OSS/FS, and in particular I wanted to know if OSS/FS programs could really live up to their claims. Many were claiming that OSS/FS had various advantages (e.g., reliability and security), but many only had questionable arguments and unsubstantiated stories. I prefer experiments and truth data to anecdotes or opinion polls, so I searched to see if there was objective data to support the claims. Surprisingly, I found that there was quite a bit of quantitative data supporting OSS/FS, but the data was painfully hard to find - there was just no single place to find it. After I'd searched and found the data, I posted my findings to the web so that others could find that data more easily. The data has convinced me that OSS/FS approaches should always be carefully considered when acquiring software; it has a lot of advantages, including freedom from control by another.

3) How do you go about making the business case for products like Linux in the enterprise?

I'm tempted to tell you that without warp drive and photon torpedo control, it's not ready for the Enterprise. But seriously, the biggest issue for making a business case for OSS/FS products is simply making sure that OSS/FS is considered as an acquisition option. OSS/FS business models are radically different from proprietary models, and many organizations' acquisition processes have not been updated to consider this option. And be honest and straightforward; neither OSS/FS nor proprietary products are always the best technically for a given situation.

Once OSS/FS products are considered, they often sell themselves, particularly when you compare them to the long-term licensing fees imposed by some proprietary vendors who lock you into their products.

4) How do you decide what stats to use? How do you determine what is the credible data?

I determine what's credible by examining the evidence presented and the reputation of the source. When I examine the evidence, I look for clearly stated assumptions and environmental conditions, a description of what was done (including how they countered any potentially serious problems with their approach), and carefully defined results. Also, I should be able to replicate the study using their information.

5) In this age where the proof is in the proverbial pudding, is there still a place for testimonials and word of mouth advocacy?

Absolutely! Testimonials and word of mouth are important, because few people will try out a new approach without knowing that at least some others have had success with the approach. But that's not enough. Experimental data are important for helping to sort out opinions from facts. For example, at one time, there were many arguments that OSS/FS couldn't be as reliable as proprietary software, but experiments have conclusively silenced that argument.

But none of that is as important as whether or not OSS/FS actually works for a particular application. So in the end, the proof is in the pudding: you should examine OSS/FS approaches for yourself when acquiring software.

6) Changing gears a bit toward some of your other interests, how do you approach the topic of security in applications?

A critical principle is defense in depth - don't assume that any one component is invincible. Developers need to figure out what their requirements are, design their programs to have least privilege, and need to avoid past mistakes by other programs (see my book!). Administrators need to lock down their system configurations and keep up with security updates. Users need to be vigilant - use good passwords and don't give passwords away. For security in the long term, there needs to be much more investment in computer security in general; research grants are far too small, and major users need to invest in their suppliers to make sure their products are secured.

7) What do you say to those who would have us believe that because Open Source code is open, that it's a helpful blueprint for malicious hackers?

Revealing source code helps both attackers AND defenders; those who ask the question often mistakenly assume that source code only helps attackers and forget that source code also helps defenders. There's been a long debate on whether or not OSS/FS is more secure than proprietary software; the evidence is generally in OSS/FS's favor, but it isn't as simple as either some proprietary or some OSS/FS proponents wish to make it.

Attackers generally don't need source code to find a vulnerability in programs delivered to customers. Attackers often use "dynamic" approaches, where an attacker runs the program, sends it data (often problematic data), and sees if the programs' response indicates a common vulnerability. Open and closed programs have no difference here, obviously. Attackers may also use "static" approaches by looking at the code. But closed source software doesn't prevent this; attackers can search the machine code for the same vulnerability patterns (using tools such as disassemblers to aid them); they can even use tools called "decompilers" that turn the machine code back into source code that's sufficiently good for finding vulnerabilities. Thus, even if an attacker wanted to use source code to find a vulnerability, a closed source program won't really prevent it; the attacker can use a disassembler to re-create the source code of the product. It's simply not as hard to attack closed source programs as closed source vendors want users to believe.

Case in point - Microsoft doesn't give its source code away to just anyone, yet look at all the vulnerabilities that have been found in their code. Clearly, having closed source code isn't a good defense against attackers, and the available quantitative data suggests that at least some OSS/FS programs are far more secure than their proprietary competition. See https://www.dwheeler.com/oss_fs_why.html#security. For example, it's been clearly demonstrated that the Apache web server has had far fewer vulnerabilities and web site defacements than Microsoft's IIS. No real programs are perfectly secure; the issue is simply what's better.

Fundamentally, since OSS/FS exposes the source code to examination by everyone, both attackers and defenders, the real question is who does it help more in the end. I believe that when a program began as closed source and is then first made open source, it often starts less secure for its users (through exposure of vulnerabilities), and over time (say a few years) it has the potential to be much more secure than a closed program. If the program began as open source software, the public scrutiny is more likely (than closed source) to improve its security before it's ready for use by significant numbers of users, but there are several caveats to this statement. Just making a program open source doesn't suddenly make a program secure, and just because a program is open source does not guarantee security:

For more information, see the section labeled "Is Open Source Good for Security" in my book "Writing Secure Programs for Unix and Linux HOWTO" (https://www.dwheeler.com/secure-programs).

8) How does using OSS/FS affect the planning, deployment, and maintenance of complex inter-dependent systems?

In general OSS/FS gives you more maintenance and support options, and since there are new options that means there are new decisions to make. Will you support the system in-house or via a third party? If you want to integrate components or add new features, will you do that in-house or hire an outsider? Will your changes stay inside your organization (which speeds development) or will you work to have the change integrated into the main release (which will probably lower long-term costs since it eases upgrade costs)? How will you evaluate your suppliers?

But managers shouldn't view this as a problem; it's an opportunity. Suddenly they have new options available, and they can select the option that best meets their needs.

OSS/FS should tend to make complex inter-dependent systems more reliable and cheaper to build. Proprietary programs are hard to integrate because there isn't enough information about their interfaces and the program can't be changed. In contrast, an OSS/FS program's interface is fully documented (at least by its code!) and the interface can be modified to simplify integration. Upgrading has many advantages too - for example, it's possible to see exactly (line by line!) what changed in an upgrade.

9) What's your OS of choice and why?

It depends on what I'm doing; for many tasks I prefer GNU/Linux. It works well on a variety of hardware, and it has a lot of wonderful tools. Also, I can install it on as many machines as I want, I can learn or change anything, and the GPL gives me greater confidence that I'll have those freedoms in the future, too.

But I use lots of OSs, including Sun Solaris, OpenBSD, Windows (various flavors), and occasionally MacOS, all for different reasons. Every OS has a strength.

10) How has OSS/FS changed the world? What is yet to come?

OSS/FS has made the world a far better place. Examples include the Internet (particularly the BSD TCP/IP stack), the Internet's naming system that makes the Internet practical (DNS through bind), universal e-mail (sendmail), and the World Wide Web (NCSA httpd and Apache). OSS/FS has made it far easier for people to communicate and to take control over their own lives.

Predicting what's to come is harder, though I'm confident that more security capabilities are coming (e.g., the Linux Security Modules work). OSS/FS is threatening to some incumbent software vendors, so I'd expect their counter-attack to widen. Technical attacks are ineffective against OSS/FS, so I expect to see software patents (especially those on obvious and prior art, even though they're illegal), attempted bribery or influence-peddling of world governments, laws proposed which have the non-obvious side-effect of making OSS/FS illegal, and manipulations of hardware to try to inhibit competition including OSS/FS (e.g., TCPA/Palladium). These may inhibit OSS/FS in certain areas, but I see little evidence that these approaches will kill OSS/FS. In particular, third world countries will increasingly take up OSS/FS (it's hard to bribe everyone), and later grow from there.

It's reasonable to expect that OSS/FS will continue to innovate faster than its competitors. After all, the techniques of OSS/FS development are very similar to scientific inquiry; both make it possible to merge a large number of people's ideas into a larger framework all can draw from. As Microsoft's secret internal document (now called Halloween I) notes, "Research/teaching projects on top of Linux are easily disseminated due to the wide availability of Linux source. In particular, this often means that new research ideas are first implemented and available on Linux before they are available / incorporated into other platforms... The ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing."

11) Lastly - existentially speaking, why are we here? That is to say, given a boundless Universe of unfathomable scope and wonder, what can man's purpose be on and from this tiny little fleck of flotsam called Earth? Feel free to quote Douglas Adams, most everyone else has.

I think I'll dare to answer that one seriously - I believe we're here to love God with all our hearts and love our neighbors as ourselves. I cannot do everything, but by providing to others some of the information I've learned, I hope to help others - which is not at all a bad legacy.

Thanks again for this and all you[r] other hard work.

You may see my home page at https://www.dwheeler.com.