Encourage Open Development Practices

[jateeter]

re Pull Request: #124

I greatly applaud those the progress made in the promotion of Open Initiatives by those with both foresight and passion within the federal government. The progress made, of which this source code policy is a prime example, has already changed the way we think about possibilities to better serve we the people.

I enter this issue in support of acceptance of pull request #124, as well as to provide a bit of background on the subtleties this pull request attempts to address.

On my first active day as a Presidential Innovation Fellow in June of 2013, I was faced with a conundrum - I was the leader, and most active code contributor, to the OpenESPI (Green Button) project on Github. My .gov orientation, as a new federal employee, emphasized that it was not clear if code I wrote could still be contributed within the OSS Apache 2 license of that ongoing project.

This policy now provides clarity to that question - that federal employees may contribute to open communities of practice and support OSS in a well defined way.

But we (the contributors to #124) felt that a small addition to the exactness of the source code policy will provide further value as resultant guidances are developed.

In particular, we feel that simply requiring a program or project to release developed artifacts a posteriori is not beneficial, and sometimes even counter to, a policy intended to encourage OSS development.

I have seen two federally funded programs that exhibit the property of significant technology development undertaken by private contract, with the stipulation that the developed code be made available as OSS. In both cases, code created was released after development onto a public repository, but without community of practice engagement during the development process, the code base was not used and, in both cases has disappeared over time as the supporting federal agencies realized that having these dead-end OSS efforts available were confusing and limiting their objectives of growing their respective program ecosystems. While the contractual commitments were met, the programs were not well served by the process by which OSS was developed, resulting in effective re-starts of the programs.

The #124 pull request does two things:

• Extends the phrase "release" -> "develop and release" when used to describe the process of achieving OSS.
• Defines (in appendix A) the phrase "Community of Practice" and uses that well defined phrase in place of the general term "communities" in those areas of the policy where engagement, during the development cycles of the OSS projects, was suitable.

The goal of these slight modifications is to provide and encourage active code review, oversight, and development from interested non-program participants and to insure that the large blocks of code are not released, as specified by this policy, without active and early opportunity to engage in the development process.