Federal Agencies Told to Share Their Software

U.S. government agencies have been directed to share with each other software code that has been developed on a customized basis for individual governmental units. Much of the code involves commercial vendor offerings. In addition to interagency sharing, government units are required to share portions of their customized code with the general public, a move characterized as promoting an open source approach to software utilization.

The Office of Management and Budget, along with U.S. Chief Information Officer Tony Scott and U.S. Chief Acquisition Officer Anne Rung earlier this month issued a final federal policy incorporating the sharing initiative.

The policy has drawn the support of open source advocates, but a major IT business group has expressed some significant concerns about how the directive affects software vendors that market their offerings to federal agencies.

Duplication Drives Up Costs

Many agencies utilized customized software exclusively for their own purposes and basically kept it to themselves, OMB found. As a result, many other agencies often acquired similarly configured customized software that was largely duplicative in nature,driving up government IT expenses.

“By making source code available for sharing and re-use across federal agencies, we can avoid duplicative custom software purchases and promote innovation and collaboration across agencies,” Scott noted.

Enhanced reuse of custom-developed code across the federal government not only promotes efficiency but also results in reducing vendor lock-in, according to OMB’s policy statement.

Federal agencies each year spend more than US$6 billion on software through more than 42,000 transactions. Those expenditures to a large extent involve pre-existing federal solutions or commercial solutions — including those based on proprietary, open source and mixed source code — that often do not require additional custom code development.

However, when agencies are unable to identify an existing solution that satisfies their specific needs, they may choose to develop a custom software solution on their own or pay for its development. Too often, such software is not shared.

“Even when agencies are in a position to make their source code available on a government-wide basis, they do not make such code available to other agencies in a consistent manner,” notes the OMB policy statement. “In some cases, agencies may even have difficulty establishing that the software was produced in the performance of a federal government contract. These challenges may result in duplicative acquisitions for substantially similar code and an inefficient use of taxpayer dollars.”

Software Code Reforms

In order to attain efficiencies in software utilization and promote open sourcing, OMB has directed agencies to take the following steps:

• Obtain appropriate government data rights to custom-developed code — including, at a minimum, rights to government-wide reuse, as well as rights to modify the code.

  “Agencies shall make such custom-developed code broadly available across the federal government,” OMB directed.
• Develop a means for releasing custom-developed source code, including securing the rights necessary to make some custom-developed code releasable to the public as open source software, or OSS.

To achieve the OSS goal, OMB established a “pilot program” that requires agencies to release at least 20 percent of new custom-developed code as open source software for three years, and to collect additional data concerning new custom software to gauge the performance of the program.

OMB policy followed an earlier draft proposal. Yet the final version is still somewhat flawed, according to the IT Alliance for Public Sector.

OMB’s definition of “custom code” was not sufficiently clear in the draft document, ITAPS said in comments submitted this spring.

It “does not set out a definition of what constitutes custom code, and it raises significant concerns over whether contractors will be asked to give rights to their commercial source code and to its valuable commercial, intellectual property,” ITAPS said. “Moreover, to the extent that the government seeks to limit IP rights based on such customization, it would be acting outside the norms of customary commercial practice, raising government contract law concerns.”

More Questions Raised

The final policy does not completely resolve that issue, according to ITAPS.

While the final directive is an improvement over the draft, “there is still some confusion in the final policy that must be addressed,” said Pam Walker, senior director for federal public sector technology at ITAPS.

“For instance, it remains unclear what intellectual property the government will have access to if a software vendor customizes its commercial code for government purposes. In general, the commercial market considers such customization to be a minor modification to a commercial product and therefore subject to the applicable commercial license agreement,” she told the E-Commerce Times.

In the final policy, OMB defined “custom-developed code” as code that is first produced in the performance of a federal contract, and that phrasing “may leave some companies’ commercial IP vulnerable,” Walker noted.

Open source advocates favor the OMB approach.

“We would expect to see a shift toward contractors that specialize in maintaining and improving systems, as opposed to building new products for each engagement. We also would expect to see increased participation by new, geographically distributed entities in such development and maintenance, including people far outside of Washington,” the Sunlight Foundation said in its comments on the draft.

Those comments apply to the OMB’s final policy as well, said Alex Howard, a senior analyst at Sunlight.

“We expect that the final policy will increase the quality of options available to agencies across government as more code is shared, particularly if 18F’s best practices and experiments are adopted by agencies,” he told the E-Commerce Times.

The “18F” reference applies to a special unit within the General Services Administration, which is dedicated to advising federal agencies on IT solutions.

“Should micro-purchasing be combined with an agile blanket purchase agreement in which approved vendors submit working prototypes of open source code as part of modular contracts, quality of software should rise while cost falls,” Howard pointed out.

Impact on Market and Innovation

The evolution of the OMB policy has the potential to affect IT innovations such as Software as a Service, Infrastructure as a Service and other cloud capabilities.

“At this early stage, it’s unclear — and only time will tell what effect this policy will have on the market. As this goes forward, we encourage policy makers to think beyond today’s capabilities and focus on the art of the possible, so that policies created today do not hamper innovation in the future,” ITAPS’ Walker said.

“ITAPS strongly supports OMB’s efforts to emphasize that agencies should leverage commercial off-the-shelf solutions first, before attempting to procure a custom software solution. We believe this approach, providing preference to existing federal software solutions such as federal shared services or existing reusable code, or a purchasable off-the-shelf software solution is sufficient, but OMB has never enforced this long standing requirement,” Walker wrote in a blog post.

“Relying on COTS will allow the government to take advantage of industry’s best solutions,” she added.

“We expect the government’s use of public cloud for hosting and SaaS to increase, lowering the costs and increasing the pace of experimentation and deployment of Web services, irrespective of the new source code policy” said Sunlight’s Howard.

“It’s possible that major enterprise firms that sell proprietary SaaS offerings could be affected eventually, but the 20 percent requirement allows considerable flexibility to agencies in procurements,” he explained.

“This is a big step forward on internal re-use of code within the federal government and a small step ahead with respect to the re-use of public code outside of agencies,” noted Howard. “The final policy contains a commendable commitment to public participation in the cooperative development of the policy, with important focus on modular architecture, interoperability through open standards, and considerations regarding sustainability.”