An important fix for the federal open source software policy

The growing use of open source software by governments has shifted from “whether to use” to “how to deploy.” The latest evidence is the Office of Management and Budget’s draft Federal Sourcing Policy --  a forward-looking policy in many respects that, with some clarifications, could be even better.

The policy both reaffirms and broadens a goal laid out in the Obama 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 recommends three-step analysis for software procurement that minimizes the purchase of custom-developed software. Second, it establishes requirements for releasing code into the public domain or as open source software, replicating early policy efforts by agencies to release code developed in-house. Finally, covered agencies must deliver for reuse custom code produced in the performance of a federal contract and, subject to certain exceptions, make it broadly available governmentwide.

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.

The three-step analysis

While media reports have focused on the last item, it’s the three-step analysis that caught my eye. It appears to be an attempt to restate current policy. But does the draft’s formulation inadvertently risk encouraging government-off-the-shelf (GOTS) solutions over commercial solutions?

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. Then, 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 three-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 any step 1 analysis.

And it also contrasts with the long-standing approach of Circular A-130, which directs agencies to give priority to the use of “available and suitable existing Federal information systems, software, technologies, and shared services and/or information processing facilities,” emphasizing 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, solution providers and for government agencies that have embraced proven commercially supported open source.

I and others have written previously 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.

Copying, or forking, an existing open source software for independent development of new project is problematic, however.

A recent report by the 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 against project forks. 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 because it focuses not on whether open source should be used, but rather on how to do it. It is forward looking  and will improve with needed clarifications, some of which are noted above. However, without clear guidance there is real risk of promoting GOTS over COTS, forking of open source projects and ‘go it alone’ support.