OSEHRA Community Responds to the Federal Government's Proposed Open Source Policy

The OSEHRA community today submitted a response to the "Draft Open Source Policy for Federal Agencies" released by the White House on March 10. The policy was open for comments through today. This is a major milestone for the OSEHRA community as well as the open source community as a whole. Currently the US Government spends nearly a hundred billion dollars a year on software purchases from the private sector or procured from government contractors. Most of this software acquisition ends up in failure. President Barack Obama has made it a priority to shift technology acquisition policies to solve this problem and restore technology innovation by embracing open source.

Tony Scott, US Chief Information Officer, made this clear when he announced the release of the draft open source policy. Scott stated:

America has long been a nation of innovators. American scientists, engineers and entrepreneurs invented the microchip, created the Internet, invented the smartphone, started the revolution in biotechnology, and sent astronauts to the Moon. And America is just getting started.  That is why since the start of this Administration, the President has taken concrete actions to support the spirit of innovation that makes America so strong. By harnessing 21st century technology and innovation, we’ve found new ways to tap into the collective knowledge of the American people and make it easier to share data, improve tools and services, and return value to taxpayers...

And that’s why today, to deliver on the commitment made in the Second Open Government National Action Plan, we’re releasing for public comment a draft Federal Source Code policy to support improved access to custom software code. This policy will require new software developed specifically for or by the Federal Government to be made available for sharing and re-use across Federal agencies. It also includes a pilot program that will result in a portion of that new federally-funded custom code being released to the public.

Through this policy and pilot program, we can save taxpayer dollars by avoiding duplicative custom software purchases and promote innovation and collaboration across Federal agencies. We will also enable the brightest minds inside and outside of government to review and improve our code, and work together to ensure that the code is secure, reliable, and effective in furthering our national objectives. This policy is consistent with the Federal Government’s long-standing policy of technology neutrality through which we seek to ensure that Federal investments in IT are merit-based, improve the performance of our Government, and create value for the American people.

Recognizing the potential benefits of open source, a number of private sector companies have also shifted some of their software development projects to an open source model. Today, the Federal Government is already building some of our most important projects using open source, and more are launching all the time.

Tony Scott, U.S. Chief Information Officer.More than 50 members of the OSEHRA community actively participated in drafting the community's response to the Draft policy over the past several weeks. This is a particularly important contribution as the US Department of Veterans Affairs (VA)  has been a leader in the adoption of an open source collaborative development model for its electronic health record (EHR) known as VistA. As part of its open source strategy the VA created OSEHRA in 2011 as an organization that could serve as a bridge between the VA and the private sector. Thus OSEHRA, and the open source efforts around the VistA code, have in many ways been the initial experiment that the policy calls for.

It should noted that this is not the first time that there is a clear call for an open source collaboration between the government and the private sector. Back in 2008 Congressman Pete Stark (D-CA) put together a well crafted bipartisan health IT bill (H.R. 6898). As discussed by Dr. Bruce Wilder in this article in Open Health News, the bill called for any taxpayer funding for health IT to go towards an open source solution in a manner similar to what the White House open source proposal is calling for. The Stark bill was unfortunately defeated by a massive lobbying campaign by proprietary EHR vendors, who then wrote the HITECH Act.

Imagine where health IT in the U.S. would be today if the $35 billion in meaningful use taxpayer subsidies had been used to develop and improve an open source EHR as opposed to being forked over to line the pockets of proprietary EHR vendors? In a second article, Dr. Wilder points out "During a recent visit to Haiti, including a visit to Hospital Albert Schweitzer in Deschapelles, I learned about OpenMRS, an EHR system used by that and another hospital in Haiti, and by their satellite clinics, areas quite remote from them due to extreme travel limitations because of the geography of the region." Dr. Wilder notes that using OpenMRS, Haiti has been able to achieve "the goals of interoperability and relative security against destruction by natural disasters, without the burdens of 'meaningful use' requirements and excessive costs."

This is particularly relevant to the expanding scope of OSEHRA as a large number of open source global health IT projects, including OpenEMR, and OpenMRS, and increasingly collaborating with the organization. This is reflected in the decision to feature a Global Health IT panel for first day of the upcoming OSEHRA Open Source Summit that will take place at the end of June in Washington.

The full OSEHRA response to the Draft Open Source Policy can be found below. A PDF version can be found here. Additional background documents can be found in the OSEHRA Community Response page.

---------------------------------------------------------------------------------------

Dr. Seong K. Mun, President and CEO of OSEHRAApril 11, 2016

Office of Management and Budget
725 17th Street, NW
Washington, DC 20503
Re: Comments to Draft Open Source Policy
To Whom It May Concern:

OSEHRA is an independent, 501(c)(6) nonprofit organization established by the U.S. Department of Veterans Affairs to facilitate the adoption of open source innovations in health IT. Since 2011, OSEHRA has shaped the community’s open source ecosystem, which has made a great impact. We may be one of very few open source organizations that sits between a government agency and the private sector, while covering both the domestic and global markets. We are pleased to have this opportunity to share our unique open source experience within a public-private partnership.

As such, we have organized an Open Source Policy Workgroup and have conducted weekly community calls to seek community insight for this response. Approximately 50 enthused participants have joined this endeavor, many from the greater open source community beyond health IT. Our resulting conversations and documents have been preserved on our website for public review.

We have synthesized the work of our team in this document. In order to offer our comments in a proper context, we have organized comments using the line numbers from the draft document. We included a separate discussion at the end of this response for the topics focused on the open source community. It is critical for the open source community and government agencies to collaborate, especially considering the numerous rules and regulations that would surely hinder progress without continued communication.

I thank our community members who contributed to this important effort. We sincerely hope that the demonstrated government leadership on this issue will ensure future government software projects are more efficient.

Respectfully,
Seong K. Mun, PhD
President and CEO, OSEHRA
202-320-4613
[email protected]

OMB Open Source Draft Policy Comments by lines and pages:

1. Objectives

The objectives should include Government participation in collaborative code maintenance throughout the software life cycle, such that improvements made by subsequent users can be considered for adoption by all users of the software (including the originating agency).

2. Scope and Applicability

This policy should apply to software developed by grantees of research projects. In the past, for example, certain programs at the National Institutes of Medicine required submission of code developed under research grants. However, we do not know how the submitted code was archived or managed.

This policy should also include major modifications or improvements to existing code.

3. Software Considerations

* Line 140 on “customizing existing Federal … product”:

If custom development is undertaken, the policy should not only mandate the release of the developed code, but also all subsequent changes/improvements to that code so that they are available to adopting entities.

4. Government-wide Code Reuse

* Line 159:

Suggest that “(including build instructions and, when applicable, software user guides, other associated documentation, and automated test suites)” be replaced with: 

“(including build and testing instructions, unit tests, test data, sample test reports, available automated test suites and, when applicable, software user guides and other associated documentation)”

* Line 162:

When the ultimate intent is to release code for use outside government, the expedient approach is to designate a desired open source license and require delivery from the third-party contractor as licensed open source software. This provides clarity on the provenance and usage rights associated with the software, and greatly simplifies the process of subsequent release to the community.

* Line 163:

Government rights should include modification.

* Comments:

Does giving government unlimited rights to the code also mean the general public will have the same rights once the code is released as public domain software? In order to have a vibrant non-government community surrounding the code, the community (the public) must have rights associated with open source code. It should be noted that the public domain software can be relicensed under a new licenses.

Usability of Open Source Code:

The usability and quality of open source code varies tremendously, as there are no community standards or guidelines for documentation, testing, etc. Recently, OSEHRA has become a Standards Development Organization (SDO) accredited by American National Standards Institute (ANSI). Our intent is to promulgate a standard for usability of open source code in the healthcare information technology. The Department of Veterans Affairs has been an active member of the process and we expect them to participate in the consensus body as we develop the national standard. This standard will include software licensing, documentation, basic functionality, and testing.

Open Source Software Licenses:

This is a complex issue with a long history of debate based on some fundamental
philosophical differences on the meaning/purpose of open source. For Government, a requirement for unlimited rights that would allow the Government to release the code as licensed open source software would avoid some of the controversies surrounding open source licenses. Alternatively, as mentioned above, the delivery of software to the Government could be made under an OSI-approved open source license.

In the case of Department of Veterans Affairs, the use of the Apache License Version 2.0 as a primary software license has worked well. Apache 2.0 includes proper attribution of code developers and contributors who become active members of the community and sustain the code base for the government and private sector.

The following diagram, developed by David Wheeler, shows the compatibility of major open source software licenses. We recommend that the Government avoid protective licenses and standardize on one or more permissive licenses. This approach will provide maximum flexibility in reuse.

5. Federally Funded Custom Code as Open Source Software

* Line 187, API’s

The APIs themselves are developed code, and should be treated like any other software (including release as open source software).

* Line 217:

We are very pleased to see the three principles of transparency, participation and
collaboration spelled out here. We have found that the essence of open source is
collaboration, and that the developed software is a by-product of that collaboration. Note that proper licensing is also critical to ensure clarity and support community governance.

5.1 Pilot Program

* Line 229, 20%

The definition of “20%” should be clarified. We understand that this is a target percentage for the pilot program with duration of 3 years. However, is the percentage based upon lines of code, total number of software development projects, dollar value, etc.? Successful implementation will rely on an unambiguous measure.

For the overall policy we suggest that the government should adopt “open source by default” policy. Unless there is clear justification such as national security, all Federally-funded software should be shared and the Government should benefit from participation in collaborative development and maintenance.

5.2 Membership in the Open Source Community

* Comment

There is confusion on this issue within Federal agencies. How should government engage with or join the community? Should government become a paying member of the community where that is the norm? Should government engage the community via the contracting process? Some government contracting specialists claim that current FAR regulations do not allow government’s support for community engagement because the benefits do not accrue solely to the contracting agency. Others say that Cooperative Agreement (CAs), rather than acquisitions, are more suitable vehicles for funding government participation in open source communities. But not all agencies have CA authority. Agencies would benefit greatly from definitive guidance on how to engage with communities and how to provide funds in support of community activities and governance.

* Line 271, “minimum viable product”

This is a very important concept in enabling an agency to take full advantage of the benefits inherent in open source operations. For example, some government software will require redaction of sensitive information prior to release either as public domain or open source software. If not handled with extreme care, this redaction process can “break” the code, resulting in a non-functional distribution. Government software should be designed with this redaction in mind from the beginning, so that the public version remains viable. Agencies should carefully review their coding standards and conventions to ensure that they mandate a level of modularity and parameterization sufficient to ensure minimal redaction impact.

* Line 274, Incremental Release:

Such incremental code releases should include, documents, test routines, test data and test results necessary to comprehend and utilize the released code.

* Line 280, User Engagement:

In addition to engaging on the priorities of software release, the Government should engage with the community as part of the development process, and again after release to obtain the benefit of community improvements. Ideally, the engagement would begin during software development as part of an agile development process. The Agile process is designed to utilize and respond to frequent user engagement. In February 2016, the OSEHRA community responded to VA’s RFI on Agile capabilities in the community. In the case of VA, increased use of Agile will require improved contracting strategies to allow collaborative development.

* Line 285, Code Contribution:

Code contributions are an essential component of any successful open source operation. Some key questions about code contribution include:

• Who will contribute code?
• To whom should the code be contributed?
• Who will provide the code repository?
• Who will test, integrate and manage the code?
• Who will manage the repository?

* Line 304, Documentation

Suggest rewording item v as follows:

v. Any other relevant technical details on how to build, make, install, test, or
use the software, including library dependencies, test programs, test data,
sample test reports, testing instructions, and test results (if applicable).

6. Implementation

* Assumption

It is assumed that this section deals mainly with long term issues rather than the pilot described in Section 5.

* Comment: Misconception on Open Source

One widespread misconception regarding open source is that it consists merely of obtaining “free” software from a website. Conversely, some view open source as tossing software “over the transom” for some unknown use. These approaches fail to take advantage of the most important and fundamental aspect of open source, that is, the ability to obtain better and continuously improved code through active collaboration. This collaboration not only results in better and faster implementation, but also reduces cost throughout the software life cycle. While the Government has unique statutory, cultural and acquisition challenges in open source participation, the potential benefit from such collaboration is well worth the effort.

7. Definitions

* Line 464-465

Suggest that definition be amended as follows:

“OSS must be licensed under an open source license approved by the Open Source Initiative (https://opensource.org).”

+++

Key Recommendations for Federal Agency Participation in Open Source Communities

A successful open source ecosystem depends on three essential operational components: software contributions, governance and community. These components are closely related to the operating principles cited in the draft policy: collaboration (community), transparency (governance) and participation (software contributions). When all three components are successfully implemented, the result is superior software that can be productized for all participants.

The development and governance of a fully functional collaborative community is a significant challenge, and the quality of the resulting community will ultimately determine the success of any open source activities. Organizing a community takes time, effort and resources. The size and diversity of an open source community will depend on the potential user base (market size) of the software being developed/reused. If the potential market size were large, a community could be formed quickly and become self-sustaining within a short period. If the software has only limited applications within a few federal agencies, building a community with multiple markets will take time and resources. It would be in the government’s interests to provide financial support to build and sustain certain communities in order to protect the investment that the government made developing the software. If multiple agencies are potential users of the code then multiple agencies should support the community.

In order to realize the full benefits of open source initiatives, Federal agencies must become a part of the relevant open source ecosystem(s) and play an active role in the community. However, the operating principles for Federal government participation in open source communities currently vary widely depending upon the agency. Further, in the Government sector, contract software development is generally done by contractors that specialize in Federal government contracts. Because of the uniqueness of this acquisition environment, many large corporations have established separate business units for government business only. In many cases, these business units have little interaction with their commercial counterparts, and operate with completely different management and cost structures. They are oriented to guarding the scope and profitability of their contracts, and often see community collaboration as a loss of control. The result is that both the Government agencies and their contractor community will need to embrace cultural changes if they are to realize the full benefits of open source. We are seeing leadership from the U.S. Department of Veterans Affairs as they consider new hybrid contracting strategies that mandate Agile development and encourage a collaborative, flexible development strategy.

As stated in 5.2(a), it is important for the Government to leverage existing communities where possible. There are many such communities, some very large and others with narrow focus. Some business and governance models of these communities may not be compatible with Federal rules and regulations. For example, many open source communities are formed by single business operations. Joining a community organized mainly by a single contractor may be perceived as an endorsement of that contractor, and may create acquisition issues. It will be preferable to join communities with multiple active contractor participants, where governance is provided by a neutral, non-competitive entity. It will be important to provide guidelines to Government agencies to assist them in developing suitable policies and rules of engagement for identifying and dealing with open source communities.

Who should participate in the relevant open source community? As open source becomes the preferred strategy for software development, participation will become routine for a wide variety of Government personnel, including contracting, program management, and technical employees. Contractors selected for software development could be directed to participate in certain technical aspects of community activities, and to incorporate collaboration into their development plan. Once the impending culture change is under way, agencies will develop their own participation profiles in fulfillment of their specific needs.