In a recent article in Government Computer News, I looked at the challenge of reshaping federal IT with open source without go-it-alone government-off-the-shelf approaches to open source software. In that article, I noted that the growing use of open source software by governments has shifted from "whether to use" to "how to deploy." The latest evidence for this is a draft Federal Sourcing Policy announced by the U.S. Office of Management and Budget (OMB), which drives U.S. government (USG) procurement and IT policy. It is a forward-looking policy in many respects. And with some clarifications, it could even be better.
A little context
The policy both reaffirms and broadens a goal laid out in the Administration’s Second Open Government National Action Plan for "improved access to custom software code developed for the Federal Government." The Plan emphasized use of (and contributing back to) open source software to fuel innovation, lower costs, and benefit the public. It also furthers a long-standing 'default to open' objective going back to the early days of the Administration.
The draft policy features several components. First, it provides a recommended "3-step process" on software procurement considerations to minimize procurement of custom-developed software. Second, it establishes requirements for releasing code in the public domain or as open source software, replicating early efforts by agencies to have in place policies to release code developed in-house.
Finally, covered agencies must deliver for reuse custom code produced in the performance of a federal government agreement and, subject to certain exceptions, make it broadly available government-wide. As widely reported, each covered agency will participate in a pilot program to "release at least 20 percent of its newly-developed custom code each year as open source," using existing Open Source Initiative licenses, but leaves room for additional licenses as necessary.
The "3-step analysis"
While the media reports have focused on the last item, it's the "3-step analysis" that caught my eye. It appears to attempt a restatement of current policy. But does the draft's formulation inadvertently risk encouraging government-off-the-shelf (GOTS) solutions over commercial-off-the-shelf (COTS)?
It requires a careful reading. As a first step, "covered agencies must first conduct an alternatives analysis and demonstrate a preference for the use of existing software solutions for which the Government holds appropriate license rights or ability to reuse. This may include Federal shared services or previously developed code available for Government-wide reuse." (emphasis added) Only when the analysis concludes "that no existing Federal solution efficiently and effectively meets its operational and mission needs, a covered agency must subsequently explore whether an appropriate COTS [commercial-off-the-shelf] solution is available." (again, emphasis added) This is the second step. (Only when no existing ‘Federal’ and/or COTS solutions is found should an agency go to step 3, and consider procurement of custom software.)
This formulation of the 3-step analysis contrasts with existing IT reform initiatives and policies to avoid GOTS and custom approaches. For example, the Administration's Shared Services Strategy emphasized the key role of commercial organizations in providing IT shared service to agencies, with growing use of commodity IT, modularity, and "open solutions," while reducing duplicative support. That key element should be reflected in first step analysis.
And it also contrasts with the long-standing approach of Circular A-130 which directs agencies to give priority as a first step "to use of available and suitable existing Federal information systems, software, technologies, and shared services and/or information processing facilities," and emphasizes in its latest version that "all IT systems and services operate only vendor-supported solutions."
Whether intentional or not, the emphasis on "Federal solutions" suggests that the policy may lean toward GOTS over COTS. This would be of great concern for open source communities, and solution providers, and also for government agencies that have embraced proven commercially-supported open source.
I and others have written that one of the benefits of road-tested, commercially-supported open source is that it is COTS. It can be supported by a variety of vendors and offers an agile, reusable, modular approach to agencies. A recent report by the U.S. Department of Homeland Security found that "a project fork is typically far more expensive for the government to maintain in the long term because the government must pay for every change (instead of sharing sustainment costs with others), and the fork is also cut off from the future innovations in the main open source project." This finding is consistent generally with the tenets of open source literature which "strongly recommends avoiding creating a project fork wherever possible." Yet the government and its contractors often unnecessarily encourage creating project forks. Addressing this issue clearly in the draft policy would be an important step forward.
The wind is at the back of open source use, both in government and the commercial sector. This draft policy is the latest example of that, focusing not on 'whether' open source should be used, but rather the 'how' of doing it. It is forward-looking, and will improve with needed clarifications, some noted above. Without them there is real risk of promoting GOTS over COTS, forking of open source projects, and 'go it alone' support.
Comments are closed.