I had a chance to catch up with David A. Wheeler, a long-time leader in advising and working with the US government on issues related to open source software. As early as the late 1990s, David was demonstrating why open source software was integral to the US goverment IT architecture, and his personal webpage is a frequently cited source on open standards, open source software, and computer security.
In this interview, we explore the current state of use of open source software by the US government, the challenges of the Federal acquisition system, and what he's excited about as he looks ahead for open source and government.
What is the state of play of open source software in the US government?
I think open source software (OSS) is considered and used much more often than in the past. I don’t know of any quantitative study that confirms this, but anecdotally I see much more of it, including Red Hat Enterprise Linux (RHEL), JBOSS, Drupal, and PostgreSQL.
There are also many uses of smaller components embedded in larger websites and systems, but it’s often difficult to know when that occurs. Sadly, it’s still common for acquisitions to ignore OSS alternatives, but I think that there is already an inexorable trend towards considering OSS as an option. One reason for the trend is that younger people in IT are used to using OSS, so as they enter the workforce they come understanding OSS instead of being ignorant or resistant. Also, budget pressures are making many people in government re-examine OSS. OSS is not free in the monetary sense, but it is often a good deal, and budget limitations sometimes make people consider change.
In addition, the US government appears to be developing and releasing more OSS, including bug fixes, major function improvements, and even whole new projects. Of course, the US government has done this for a long time. A key reason the Internet succeeded was that the US government paid to have the base Internet protocols (TCP/IP) implemented as OSS—that OSS implementation served as the basis or reference implementation for others. Though they have done it before, I think that has accelerated. See this list of OSS developed and released by the US government. (I didn’t start this list, this is just a simpler URL). Notice things like "DARPA Open Catalog" and GitHub "Government Open Source Projects," which are not just individual projects but entire lists of projects now being released as OSS.
You mentioned the challenge of acquisition. Can you elaborate on what acquisition teams need to know about OSS and what can be done to educate them?
The biggest problem is that most acquisition personnel don’t understand that practically all OSS is commercial software. Under U.S. law, the Federal Acquisition Regulation (FAR), and the DoD FAR Supplement (DFARS), software is commercial if it has a non-government use and is licensed to the public. In particular, see U.S. Code Title 41, Chapter 7, Section 403.
Because nearly all OSS meets the definition for commercial software, nearly all OSS is considered so. This is confirmed further in U.S. Code Title 17, section 101 (part of copyright law), which explicitly defines the term "financial gain" as including "receipt, or expectation of receipt, of anything of value, including the receipt of other copyrighted works." Because most OSS projects encourage others to contribute improvements to their projects, that means that they are seeking financial gain… and thus OSS is commercial.
This fact, that OSS is practically always commercial as defined by law, is a fundamental issue when working with the government and its contractors. First, government employees and contractors are required to follow a long list of rules. Sometimes people won’t accept OSS simply because they cannot figure out what rules to follow; once they understand that OSS is practically always commercial, they can just follow the rules that they already use for commercial software. Second, U.S. law (10 USC 2377) requires a preference for commercial items, down through all tiers of contracting, and this preference includes OSS. Agencies are required to "modify requirements in appropriate cases to ensure that the requirements can be met by commercial items." The government even requires preliminary market research to determine "whether there are commercial items" that "(A) meet the agency’s requirements; (B) could be modified to meet the agency’s requirements; or (C) could meet the agency’s requirements if those requirements were modified to a reasonable extent." This market research should occur "before developing new specifications for a procurement by that agency; and before soliciting bids or proposals for a contract in excess of the simplified acquisition threshold."
Someone who ignores OSS when acquiring software for the government is disobeying the law, because OSS is commercial and they are required to consider and prefer commercial items. Sadly, because people don’t understand that OSS is commercial, they can unwittingly disobey the law and end up excluding OSS, often procuring higher-cost software with less flexibility as a result.
People are working on educating others, but it’s a hard problem. I’ve spoken in many forums, including a number of Defense Acquisition University (DAU) classes, specifically to help acquisition personnel understand that OSS is commercial. I guess this interview counts too! Formal policy statements have been released to try to make this clear as well. However, in spite of all this, a lot of acquisition personnel still haven’t heard the message. I still hear nonsense like "commercial and open source software," as if they were distinct in some way. People who have such a fundamental misunderstanding of software law and regulations, especially about something so widespread in industry, are unlikely to make good decisions about software.
There are other problems in government acquisition that aren’t unique to OSS, but they certainly impede appropriate use of OSS. Organizations often fail to do market analysis of any kind, falsely assume that all relevant suppliers respond to government request for proposals (RFPs), and have software development program managers who don’t understand software development. All of these factors make it difficult to appropriately manage change, including increasing the use and development of OSS.
You have written a lot in the past about the U.S. government and forking projects. What the state of this today?
Yes, and project forking is still a big problem. Contractors typically get paid far more if they can convince the government that the software must be rewritten from scratch or must at least be changed and maintained "specially" in a way that will cause the government to pay for all future changes. Also, if the contractor can ensure that the software is unique to that customer, it will be difficult for the government to effectively recompete the contract.
Government employees who are officially managing the project may be smart in general, but they often know little about software. Obviously, managers who don’t understand what they’re managing are often easily fooled. For example, government managers often don’t realize that most software costs are in maintenance and typically do not understand that maintenance costs can be greatly reduced (through sharing) if changes are released back to a larger community.
Part of the problem is that in most agencies, the easy thing to do is to create project-special forks, even though it is almost always the highest-cost and highest-risk approach for maintenance. The data rights clauses are often confusing to non-lawyers, and contractors have strong financial incentives to get exclusive rights to the software, even when they did not pay to develop that software. Review and export control law requirements also encourage people to take the high-cost, high-risk approach.
I am a big fan of the OSS policy created by the Consumer Financial Protection Bureau (CFPB). In the CFPB approach, software developed using government funds must be released as open source software unless a special waiver is granted. You could call this approach "freeing the code by default." Forcing the release of most software as OSS, when it’s developed using government funds, eliminates nearly all of the perverse incentives that government projects otherwise have to cope with. It also makes philosophical sense; if "we the people" paid to have the software developed, then "we the people" should be getting it. The Free the Code website has been arguing for this for years. It makes no sense that we allow contractors to retain special rights over software they did not pay to develop. If the U.S. government released more of its code, it could save a lot of money and have higher quality as well, but it is a big change from today’s processes.
What are you most excited about when looking at OSS in the U.S. government?
I’m especially excited about the increasing amount of OSS being released by the U.S. government. These OSS projects are producing the kind of public/private partnerships that are often desired but difficult to achieve. The Consumer Financial Protection Bureau (CFPB) has released a lot of code, and more recently, DARPA has as well. NASA has been releasing OSS for years, and more recently is increasingly using standard OSS licenses instead of the NASA vanity license that is incompatible with industry and the rest of the U.S. government. Many agencies have set up OSS project sites or are actively contributing to various projects. The White House not only uses Drupal, but has released many improvements it’s made. For example, the White House improved Drupal’s accessibility; by releasing that improvement they have probably helped millions of disabled people around the world.
There are many benefits when government-funded software is released back to the people who paid for it. It’s far easier for other government agencies to find software once it’s released to the public, and it’s much easier to find competing support sources once it’s available to the public. I also think it’s harder to reflexively reject OSS when you’re also contributing to it.
How do you see OSS in the context of efforts to ensure adequate national economic security?
OSS is a vital element for ensuring national economic security. Automation is central to practically every modern endeavor. Creating and improving automation requires malleable building blocks. In particular, innovation necessarily requires building blocks that can be reshaped in new ways. By definition OSS is an innovation enabler, because it creates far more malleable building blocks. OSS is already widely used and developed throughout industry, so it is already vital to industry.
I believe that today the use and development of OSS is sometimes impeded by problematic government policies and misunderstandings, and these can hamper national economic security. For example, current federal circuit rulings now permit software patents; this is a reversal of well-considered older rulings. I believe software patents have had no demonstrable benefits, but have certainly imposed numerous harms. Another example is that typical data rights approaches in government-funded research have, I believe, hampered U.S. research very badly. Every time a U.S. university wants to use U.S. grant money, that university typically has to start from scratch if a different university did related work. That’s because the government pays to have research done, and then often gives all rights to that one university, apparently assuming that research never involves collaboration, never builds on previous work, and never requires reproducing previous work. In contrast, French universities using French government funds often easily share results among themselves using OSS licenses. This is not an idle case; in some areas, such as in high-assurance software, the U.S. risks losing its edge because of its inefficient mechanisms for funding research in software. And of course, the other policies and misunderstandings I mentioned earlier apply as well. These are, of course, my own opinions; I don’t speak for the government or my employer. But I do believe these things, and I hope that those roadblocks will be removed over time.
I do have hope. In the U.S. government OSS is considered and used much more often than in the past, and the U.S. government appears to be developing and releasing more OSS as well. I think we will see even more OSS public/private partnerships in the future, and I look forward to it.
David A. Wheeler works for the Institute for Defense Analyses (IDA), but in this interview he is not speaking for IDA or the U.S. government.
Comments are closed.