Principles for e-Government and Government-Funded Research Software Development.

Bruce Perens (bruce at perens dot com)
Visiting lecturer, Agder University College, Kristiansand, Norway
Vice President, Sourcelabs

The choice of technology in e-government projects and government-funded research can result in unfair discrimination and unintended harm. This set of guidelines will help the technologist avoid that harm.

Goals

Government should be fair to all citizens, while giving preference to none. It's important for government and society to protect people who are at a disadvantage - for example those with physical handicaps - and to make sure that they can participate in society and interact with their government to the same extent as the more normally able. And government should give the people the most possible benefit for their tax dollars, and should use those dollars efficiently.

The Problem

But what does this have to do with software? Many software products are unique to a single manufacturer, and will only readily communicate with other products produced or licensed by that same manufacturer. For example, a number of e-government web sites are only fully accessible when using the Microsoft Internet Explorer web browser. Such a practice, if it continues to be allowed, will require that a citizen install and use Microsoft products to interact with their government, placing the government in the inappropriate position of granting an advantage to Microsoft over other businesses.

Locking the customer in to a particular product through incompatibility has been an oft-used tool in building some of the largest software businesses. But vendor lock-in is by nature anti-competitive and anti-customer. Monopolies result in increased cost and lower quality, no choice for the customer and less opportunity for business in general. Thus, it is clear that the practices of e-government should be structured to avoid vendor lock-in.

The proper practice would be to implement e-government web sites using open standards that are compatible with web browsers from many different sources, so that artificial monopolies are not created and the citizen will be free to choose one of many possible software platforms. Then, competition will drive vendors to differentiate their products with higher quality and lower cost rather than rely on technological lock-in to drive funds to a particular business.

The need for standards and choice is most severe for the handicapped. For example, blind users will need web browsers that present information by other than visual means. And they have such systems, but many web sites are created in such a way that only a visual presentation is available. Existing open standards provide facilities for blind users, but not all developers use them. It's essential that developers of e-government and government funded research and development do so.

Why don't all developers produce universally accessible sites today? Not for any technological reason, and not out of malice. Either because of ignorance of the issues, or a desire to get the job done as quickly and cheaply as possible without taking extra time to make things fair to everyone or to accommodate the handicapped - which really translates to an ignorance of the issues among management.

We can set this situation right by promoting the guidelines in this document, and by requiring them when e-government facilities are developed and when governments fund software development and research.

Thus, we arrive at some goals:

• Don't require a particular product.
• Don't convey an unfair advantage to a particular business by creating an artificial monopoly based on that vendor's unique technology.
• Use open standards to promote interoperability among many products.
• Use the facilities provided in open standards for the accommodation of handicapped users.

It's important that open standards be carefully defined so that they are truly fair for all. One of the most important considerations is that the copyrights and patents embodied within open standards be usable for all implementations. But unfortunately this is not the case for many standards. For example, few standards organizations require that the material of the standard be under copyright and patent licensing that is truly compatible with Open Source software development.

Open Source is probably the dominant paradigm for the development of infrastructure software today. It's inherently fair, because the copyright licensing of Open Source allows any manufacturer to include it, without a need to pay a royalty or fee. And many Open Source licenses have provisions to keep all improvements to the software accessible to the public. That deters the creation of artificial monopolies through incompatibility.

Open Source is certainly too important for the standards used by e-government to rule it out, but to be fair to all software developers, those standards must also support the development of proprietary software. Thus, it is important that we apply standards for copyright and patent licensing to the technical standards that we use. A statement of those standards may be found in Open Standards, Principles and Practice. An earlier version of that document influenced the succinct Danish position on Open Standards: An Open Standard is accessible and free of charge to all. It remains accessible and free of charge.

In what parts of our products must we require Open Standards, and where can we leave developers the leeway to differentiate their products using non-standard, proprietary developments? Open Standards are only essential for the parts of products that communicate with other products. These are file formats and intercommunication protocols. For example, the HTML file format is defined in a standard of the World Wide Web consortium that provides interoperability between many web servers and browsers, defines the proper facilities for accommodation of handicapped users, and sets an acceptable policy for the licensing of patents and copyrights.

Sometimes it will be necessary to depart from standards in order to create new innovations and make them immediately usable by the general public. After all, many useful standards have taken five years or more to develop and ratify, and we might not be able to wait that long. But we still should provide the openness, even while falling short of requiring a formally developed and ratified standard. We can do so by requiring that all file formats and intercommunication protocols that we use must be publicly documented, and implementable by anyone without discriminatory licensing or the need for a royalty or fee. Documents can be used to specify such file formats and intercommunication protocols, or they can be implemented in Open Source software, or both. Open Source is to some extent self-documenting, because it can be read and analyzed by anyone and the knowledge gained (although not always the specific implementation) can be used in the development of either Open Source or proprietary software.

Organizations that wish to promote a particular file format or intercommication protocol for use by all would be well advised to create an Open Source reference implementation, using one of the subset of Open Source licenses that allows the licensed product to be incorporated into either proprietary or Open Source software. The remainder of a product, everything that is not either a file format or an intercommunication protocol, may be under any Open Source or proprietary licensing paradigm.