5 principles of government software development

[caption id=”attachment_19968” align=”alignnone” width=”1024”] Photo: White House[/caption]

Technology has always been a prime concern of government. The U.S. Constitution created the power to confer patents and copyrights. The Manhattan project, Apollo program, eradication of smallpox, and the Internet were all government projects.

The inexorable march of technology and the rise of computers, software, and free and open source software in particular, requires that we articulate principles by which a government of the people, by the people, and for the people develops software.

Here are five principles of government software development:

1. Action Transparency: In order to be fully transparent and accountable in its services to the public, the government at all levels shall use only free and open source software.
2. Procurement Transparency: In order to be fully transparent and accountable to the taxpayer in its procurement of software the government shall develop in an iterative way, inviting the public to view, use, comment on and contribute to its process, progress and code contemporaneously with its development.
3. Execution Security: Because closed-source code is inherently insecure, the government shall use only free and open source software.
4. Democratization of potential contribution: In order to foster civic involvement and to save money and foster competition, the government shall facilitate the contribution of source code from the public.
5. Contribution Security: In order to be secure, the government shall retain absolute control over what code is deployed and accepted as official code, without restricting the development of potential contributions in any way, and pay whatever it has to in order to obtain the technical capability of this review.

Principle 1 — Action Transparency

In order to be fully transparent and accountable in its services to the public, the government at all levels shall use only free and open source software.

Because many government services are now provided by computer software, the action of the government cannot be transparent unless the programs that provide the services are transparent. If government makes a decision based on software, the people have a right to examine that software.

In some cases, as in the case of the Federal Aviation Administration or the Federal Emergency Management Agency, it is easy to see that the very lives of citizens depends upon software systems, and those systems should be open to examination and contribution from the public. If the action depends on software, for the action to be transparent as generally implied by the civil right of equal protection under the law, the software must be open-source, and freely testable.

In order for the citizens to have the right of potential contribution, the software must be freely modifiable without legal restraint.

Principle 2 — Procurement Transparency

In order to be fully transparent and accountable to the taxpayer in its procurement of software the government shall develop in an iterative way, inviting the public to view, use, comment on and contribute to its process, progress and code contemporaneously with its development.

Technology does not stand still. Software is never done. Software is always being constructed — -or becoming obsolete.

Because of the great investment in money and time that the public taxpayer makes in this construction, the government must build software in the most transparent way possible.

Software does not spring, like Athena, fully complete from the foreheads of programmers. Rather, it is developed in a long, often arduous and error-prone way over time. Efficient methodologies now exist and are widely used allowing a team to observe, communicate about, and measure this progress. These methodologies must now be used to open the development process to public comment.

If the public is paying taxes to develop a piece of software, it has the right to observe the construction of that piece of software. This implies that the government has a duty to publish not only the final code, but all intermediate code, wireframes, user interviews, ideas, tests, designs, and decisions every step of the way, at approximately the same time it is being developed.

Principle 3 — Execution Security

Because closed-source code is inherently insecure, the government shall use only free and open source software.

Closed-source software is inherently untrustworthy because by definition it must be a known to a small group of people, and everyone else is excluded from examining it. It must be known at least to the persons who worked on its development. If it is not developed both under the scrutiny of the public and with the idea of public scrutiny in mind, it is more likely to contain a security flaw.

If you attempt to keep the source code a secret, this vulnerability may be hidden for some time. The security of the public becomes dependent on keeping this secret.

A large computer program is a very hard secret to keep for several reasons:

1. It unavoidably must be present on computers.
2. The secret must be exposed at least to the persons who work on it.
3. If the secret is divulged, you may never know.
4. It is almost impossible to quickly change a large program, and therefore it is very hard to quickly change the secret if it is compromised.

Therefore, the public, whose money and sometimes very lives depend on the security of government software, should demand of its government the use only open source software.

Principle 4 — Democratization of Potential Contribution

In order to foster civic involvement and to save money and foster competition, the government shall facilitate the contribution of source code from the public.

Free speech allows us to criticize the government. This means we have the right to complain about the government; we also have the privilege and duty to constructively criticize by offering our talent and expertise to the government.

The government often invites comment on policy and plans from the public. That invitation must be extended completely to the realm of software development by inviting and facilitating constructive comments at every level of software development.

The public has the right to contribute potentially better code for every feature of every program in every week that the government is developing software. The creation of potential contributions of software should be completely democratized. Most persons are incapable of making informed comment on software, but none should be excluded from doing so.

If the government does not use an open process that furthermore invites and facilitates comment and potential contribution, it forestalls the civil right of free speech in the form of public comment.

The democratization of software development may be hoped to greatly decrease costs. It is unclear that the public at large will actually make gratis contributions which save the government money, but it is clear that the potential exists, and no harm can come from the potential.

Principle 5 — Contribution Security

In order to be secure, the government shall retain absolute control over what code is deployed and accepted as official code, without restricting the development of potential contributions in any way, and pay whatever it has to in order to obtain the technical capability of this review.

By providing a formal process for decision-making, representational government gives minorities a voice, but not tyranny. Everyone has freedom of speech, and nobody is free to dictate laws or actions. The government must democratize contribution of potential improvements, but must not abrogate its responsibility and power to decide what code is actually used.

There are two fundamental reasons for this. The first is the practical fact that it would be insecure to do so. If a person or minority has a right to force code to become part of a government project, that person has the power to sabotage the code. As a matter of practice, the government does confer this right on a small number of government contractors whenever it does not have sufficient staff to properly review with its own employees all code contributed by a contractor, which is fairly common. Luckily for us, government contractors are rarely saboteurs.

The second is a matter of principle. The people delegate the power and responsibility to the government to build software to which they will entrust their lives and livelihood. The government must retain in-house sufficient technical capability to create a trustworthy process of review for every line of code.

Ideally, this review would be carried out by the most trustworthy government servants, but in practice, and certainly today, this is not possible due to insufficient numbers of technical experts in the government. Review can be delegated to non-government employees in various ways, including in-house review, review by the public, and review by a firm that did not develop the code. However, the government must retain ultimate responsibility for this review. The Executive must accept this responsibility, and the government actors must be prepared to bravely call for help when the complexity of the review problem exceeds their technical ability.