adopting open source in government

INDUSTRY INSIGHT

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.

About the Author

Mark Bohannon is vice president of Global Public Policy and Government Affairs at Red Hat.

inside gcn

  • cloud services (jijomathaidesigners/Shutterstock.com)

    AWS GovCloud gets more enterprise services

Reader Comments

Fri, Apr 15, 2016 Owen Ambur Hilton Head, SC

Regardless of whether COTS or GOTS software is used, the applicable data standards should be supported. Taxpayers should not be locked into paying for any particular "proprietary" software "solution" -- even if Uncle Sam is the proprietor. Software switching costs should be low because the data (records) should be free of software dependencies.

Thu, Apr 14, 2016 scott mccord

This forced decision hierarchy of GOTS/COTS/developed solutions is a bad idea born from the same misperception that open source solutions are ‘free.’ Solutions should be based on a clear understanding of the requirements and then thorough total cost of ownership analyses of possible alternatives. Further complicating the decision is Government’s persistent inability or unwillingness to adapt it’s practices to COTS product capabilities, preferring to customize instead. Why would adoption of a GOTS platform be any different? There are many GOTS solutions adopted by numerous other agencies with highly similar missions (e.g., training) that have failed or resulted in unoptimized systems with much left to desire. Just look around!

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group