Free and Open Standards and Software: The Digital Basis of Open Government
To enshrine open standards in government and make sure they are robustly implemented, governments should lean whenever possible toward free/libre/open source software (FLOSS). As described in Chapter 32, FLOSS code is available to everybody without any royalty or legal restriction. Everybody can install as many copies of the program as they wish, or create and redistribute, under the same conditions, custom copies of that program starting from the source code.
Still, FLOSS is not enough to guarantee that owners of documents will always be able to read them, because the original source code might be lost or fail to work on newer computer systems. In such cases, files become unreadable not because of software licenses, but simply because their authors never bothered to demand that the programmers use fully documented file formats. That’s why it’s important to stick to really open standards that exist and are defined regardless of any specific software program, regardless of its license. So, FLOSS is an important step toward open government, but truly open formats and protocols are often even more important, because most programs are worthless without other programs with which to talk, or without data to process. We run software to manage data, not the other way around.
Open formats and protocols are standards whose complete specification is published in enough detail that any programmer can, without royalties or other conditions, write new software fully compatible with that format or protocol. Such standards don’t rely on any proprietary subcomponents, are developed through consensus and experimentation, and are maintained by a recognized international, nonprofit community. Only standards such as these give real guarantees that our data remains ours and that its formats will remain readable, while no one can exploit them to lock in users and exclude competition.
So-called de facto or industry standards often aren’t open. They often belong to one (usually for-profit) company. Even when they are entirely published, their owners can change them at will, whenever they feel like it, and without informing everybody else of which changes were made. In other cases, you need explicit permissions to use the standard. Such standards may even be created just to stifle competition: a company may create a specification that describes the file format incompletely and with proprietary features that only it can provide, and then lobby to have it recognized as a standard. This is a mock standard, because no one else can develop software that really works with the format. This is relevant because conformance to some standard is often (rightly!) a mandatory requirement in contracts for information and computer technology products and services paid with your tax money.
There is another reason why relying only on adoption of FLOSS to keep everything open, instead of starting from truly open standards as defined earlier, is not the optimal solution. File formats should be as few as possible and as stable as possible. FLOSS makes it always possible to convert data from one format to another, but why create the need for conversion if it isn’t absolutely necessary? Think of software as pens, and formats as alphabets. We went from quills to email in just a few centuries exactly because the alphabets remained practically unchanged, allowing each generation to learn and build on what already existed rather than rewrite every manuscript in a different way every few years.
Innovation whose impact is limited to internal software features is less of a problem, as it leaves documents readable by everybody. An insistence on open formats and protocols (which can be used also by proprietary software) will actually stimulate developers to improve the user experience and other aspects of their software (aspects that are independent of the standards) rather than try to dominate the market through their control over formats.
In other words, insistence on open standards for file formats and protocols will also make it much easier to evaluate software programs according to their actual merits: performance, flexibility, ease of use and customization, documentation quality, and so forth. Think again to pens and alphabets. There is nothing wrong in selling luxury pens made with secret or patented technology, as long as cheap pens can also exist. But the whole thing is contingent on everybody using the same alphabet, without needing to pay fees or learn special secrets.
Go here to read the Conclusions