A Federal IT Contractor Makes the Case Against Open-Source Obamacare

Photograph by Nikita Buida/Alamy

Kendall Clark is the founder and chief executive of Clark & Parsia, a 10-person software product and service firm that does development and R&D in enterprise semantics. He has worked for and with several federal agencies, including NASA and the National Cancer Institute. After my essay in this week’s Bloomberg Businessweek, “The Obamacare Website Didn’t Have to Fail. How to Do Better Next Time,” was posted, Clark (with whom I once worked at the website XML.com) reached out to tell me that he disagreed with my thesis—namely that open source would lead to fewer failed software projects. He’s not against open-sourcing some government code, but he questions the relationship between opening the code and improving the quality. I asked him a few followup questions.

In my piece I proposed that if the federal government developed its code in the open, there would be fewer failed launches such as healthcare.gov. You don’t buy it. How come?

I think we have to start by asking not so much why healthcare.gov failed, but why most large (i.e., complex) software projects fail in the sense that they’re either too buggy to be useful or they blow past the budget or the schedule, or, in some cases, all three of these.

And there are lots of reasons why software projects fail: The wrong people are building them; the wrong people are making technical decisions, which is basically a proxy condition for a different one, namely, that substantive technical or design choices are just wrong; the budget or the schedule (or both) are simply unrealistic; it doesn’t matter that the system is a success (true more often than we might want to admit); the system is too complex and should have been several, simpler systems, and so on.

Why why not just open up all the software that the government produces by default? Then at least we could all see the messes people make and try to fix them.

Open source is a set of conditions for license terms of software. But notice that license terms aren’t among the reasons I listed for complex software system failure. So initially we should be very skeptical that different license terms would make any difference at all to either healthcare.gov’s success or to any other similarly complex system’s success.

Well, it’s too late for healthcare.gov—that ship has sailed. But in the future, don’t you think that opening the whole process, making government code freely available as it’s developed, would increase transparency and lead to better code?

It’s possible that open-source license terms for government systems would indirectly address some of the reasons that software systems fail. For example, open source might mean that a different set of people work on the project. That could make the project more likely to succeed.

I don’t think that would tend to be the case, but it might, and it’s a factual question, and we don’t have much data, so let’s punt it for now.

OK. I do want to note that the Consumer Financial Protection Bureau has done a ton of open-source stuff that appears to be of really great quality, so that’s one data point. But I concede that it is exactly one data point.

I can offer other data points: Library of Congress does good open-source work; NASA does good open-source work; National Cancer Institute does good open-source work. I simply question whether the good work is caused by the open source. Most of reasons software projects fail just seem to be very different from anything to do with license terms. For example, license terms don’t make the budget or schedule more realistic.

There’s an assumption, which I think we both would agree tends to be false, that open-source terms just means free labor from strangers. Not only is that false; I don’t think the government should proceed on that assumption for policy or political reasons. Open-source license terms don’t tend to empower technical people to make technical decisions or to make the right decisions. We both know about many open-source systems that are just technically dopey.

OK, but what about Linux and Firefox? They’re both open-sourced, both work really well, are known for security—and are both developed totally in the open. The government couldn’t get in on that?

Both Firefox and Linux are open source and have tons of people working on them. At this point, most of those people are paid employees of some organization that employs those people to work on those systems. That the systems are open-source licensed means that many different organizations can employ people to work on the systems in a kind of free way, i.e., legal ownership of the system is so dispersed (or it’s held by a nonprofit entity as a kind of public trust) that some kinds of profit motive and economic incentive not to share code are removed.

Linux grew organically via “free labor” in the early years, but there are probably Linux-specific reasons why that happened that are unlikely to be replicated in government software. I’m skeptical anyway. We should also mention, perhaps ironically, that the NSA did fund a lot of security work on the Linux operating system that is, as far as I’ve ever heard, quite good. You can speculate about [whether] NSA would have done that in light of recent news reports.

I guess my dream is that the government could figure out how to create a culture around software development that is like the cultures around Firefox or Linux.

The U.S. federal government is unique in many ways, and it’s not at all clear that it either needs or wants to share software in the same kind of way. In some cases, there are legal, regulatory, or policy reasons why it should not share software. For example, some software systems that are part of defense or intelligence gathering should probably be closely held (but not all of them). The government also has R&D and investment programs in which the point is to help small businesses get funding; I don’t think you’d want, as a matter of policy, to dictate business models to these companies by requiring them to use open-source licenses only.

I don’t think the federal government is very good at creating cultures. It is good at creating systems that play by rules on which people may create cultures. Arguably that’s precisely how open source came about, since it relies deeply on features of copyright law [that] the federal government put into place and now enforces (although, surely, the patent system in regards to software is completely broken).

But I still like the idea that the code the government writes would be out in the open by default, contributing back to the commons. More participants, and hopefully better code, as a result.

I think it’s likely that open source would mean more participants (for some government projects), but it’s hard for me to see why that would be a direct benefit or desirable outcome for the government. Software isn’t like food or water where, by definition, you want to maximize the number of people who participate in it or even maximize the number of people who participate in creating it.

What about the innate value of transparency?

I can think of more direct ways to achieve transparency. We could go back to preventing Congress from being exempt from insider-trading laws. We could do FOIA reform to make it more robust. Probably the main impediment to transparency today is massive, systematic overclassification of documents and government information. All of these would have a bigger impact than open-source licensing.

I agree that open-source terms should probably be the default (or a lot easier to choose) for government software—with some important exceptions—because taxpayers paid for the software and open-source terms won’t usually hurt. But that’s different than saying they’ll tend to help or necessarily help.

    Before it's here, it's on the Bloomberg Terminal.