The theme of open government that pervades this volume depends on drawing participation from as wide a swath of the public as possible, and this goal in turn calls for the use of software that is universally available, easy to use, easy to adapt to specific needs, and easy to modify to match evolving requirements. Free and open source software meets these goals more consistently than any alternative.
In this chapter, we use the term FLOSS for this type of software: free/libre/open source software. Although it’s usually distributed free of charge, its distinguishing trait is a license that allows anyone to change the code and redistribute the changes. This keeps FLOSS from being dominated by one set of developers, and therefore from being burdened with restrictions that users may reject and that even may violate government policies (e.g., terms of service that let the developers collect personal information from users). The alternatives are usually called “proprietary software” because they are often free of charge but are still under the control of the organization that created them.
FLOSS is already in widespread use within government agencies, and will have an even greater role to play in open government technologies that can be really useful for public administrations. However, adopting or migrating to FLOSS is a complex, multidisciplinary effort involving several areas of expertise. It requires taking a hard look at current workflows in the organization, as well as how people interact with information technology (IT) systems day to day. The unique complexities found in each public agency add more difficulties.
So, FLOSS migration is a major endeavor, and as any migration, it can easily go wrong. All too often, agencies are discouraged by one failure from pursuing other opportunities, and may even blame the software or the community that supports it instead of the logistics of the migration. This chapter will hopefully persuade you that adopting FLOSS is crucial and will additionally give you guidelines to avoiding mistakes during its adoption.
The common hurdles in adopting FLOSS fall into three major categories:
Understanding the procedures that agency heads need to put in place, and how staff members must be coordinated
Choosing software appropriate for the job, and interacting with the community that developed the software in a productive manner
Presenting change to staff members in a positive manner and handling the various forms of resistance they will put up
Before introducing guidelines based on experience, we’ll lay out some of the specific advantages of FLOSS for public agencies. Then we’ll present a set of best practices obtained through research by European projects that have analyzed adoption and migration experiences.
Government agencies, and public institutions to which they contract out services, are large software users with special characteristics derived from their obligations toward citizens and their unique legal status. For example, most agencies are expected, or even required by law, to provide services accessible to all residents of their regions, including those who are disabled, who lack education, or who are geographically isolated. Agencies must also be neutral in their relationships with manufacturers, and must often guarantee the integrity, privacy, and security of the data they handle over long periods of time.
All these needs play into their considerations when adopting software, beyond the cost/functionality evaluation that businesses and individuals perform. An analysis of these common requirements shows a clear advantage to FLOSS solutions where they exist.
Any institution values the advantages of keeping open options for different vendors, because it tends to lower costs and leave an escape path when a chosen vendor leaves the business or fails to provide up-to-date features. But for public agencies, a competitive market is usually more than a preference—it’s a legislative requirement. The legislation enjoins them to initiate procurement by issuing calls for tenders that don’t favor a single vendor. Any interested company that fulfills reasonable criteria can produce a bid that competes on its own merits with everyone else.
But this critical adherence to disinterested policy is violated in the case of proprietary software. Each product is available from only one supplier (even if it uses a number of intermediaries). If a particular product is specified in a call for tenders, the administration has predetermined the supplier that gets the contract. In the case of computer applications, it is virtually impossible to avoid specifying a particular product because the agency needs compatibility with products that are already deployed, savings in training and maintenance, or other reasons.
Requiring a proprietary format (such as the ability to deal with certain kinds of spreadsheets) is a looser limitation but still a means of lock-in, because the vendor that defined the format and continues to update the format over time is the only one the agency can rely on to handle the format in all its subtleties.
FLOSS offers a way out of this situation. If the specified functionality is delivered by FLOSS, any interested company can offer the product and any service based on it, subject only to the capabilities and knowledge of the company. In addition, agencies that enter contracts this way can easily switch to another supplier without needing to switch to a new product.
Public agencies, like other organizations, benefit from using software they can adapt to specific requirements. When they license a proprietary product, modifying it normally involves reaching an agreement with the producer, the only party that can legally (and often technically) make modifications. Under these circumstances, getting the company to agree to and deliver the desired changes is hard to achieve.
In the case of FLOSS, software can be adapted either by its copyright owners or by any third party, which means that instead of negotiating with a single company, the service can be purchased in a competitive market. Some companies that deliver FLOSS will stop support if the software is altered by the customer—but support for these products is also available on an open market.
FLOSS commonly follows open, published standards. In addition, because the source code is available, any format and protocol the standards implement can be reimplemented by other software developers, effectively turning the format or protocol into a standard. The advantages of this neutrality are especially significant for public agencies, particularly in their interactions with citizens, who should not be forced to purchase a product from a particular company just because it is the only one that implements a proprietary protocol the agency is using.
Public agencies have become increasingly committed to transparency. The public rightfully demands not only to be kept apprised of each stage of decision making—such as in urban planning—but to see the data behind the planning, the steps made in taking the decision, and the reasons for the decision. Being able to let citizens inspect the agency’s software extends this public scrutiny to the field of IT. In addition, agencies need to guarantee that their computer systems do what they are intended to do (in many countries, by legal requirement). Many systems manage data with privacy restrictions (tax data, criminal records, health information, etc.), which must be kept out of the malicious grasp of unauthorized third parties. Ironically, experience has taught that systems tasked with keeping secrets are more secure and more likely to fulfill their requirements if the source code is open to examination; only encryption keys should be secret.
Proprietary applications without source code are difficult to evaluate rigorously to guarantee that the application will process the data in the way that it should, with no leaks or back doors. Even if a vendor does provide a customer with its source code, the possibilities of a public institution ensuring that it is free of malicious or insecure elements are very limited. Remember that every major software product contains security flaws that are routinely reported and fixed only after the product has been in the field for months, or even years. Only if software inspection can be routinely done by third parties, including any citizen who may want to do it, can the agency be sure that it is taking all reasonable measures to comply with this fundamental duty.
Much of the data processed and stored by agencies, and the programs used to manage this data, have mandatory availability requirements measured in decades. Proprietary software, being subject to the commercial strategy of the company producing it, cannot be guaranteed to be available in the platforms of the far future. It is quite possible that the producer will lose interest in the product, or in the data format used to store the information. Since only the producer can port the software to new platforms, negotiation will be difficult. A producer can go out of business or be purchased by another company that decides to leave the current business. Producers have even been known to deliberately change software so as to make it incompatible with earlier data formats, leaving all documents in those formats unreadable unless the agency can maintain an old computer system running old software.
In the case of FLOSS, however, the source code of the application is certainly available and the vendor has given permission for its modification. Therefore, many companies can compete to provide the porting service when the agency decides to contract it. Documents in old formats can also be recovered because the programs can be revived or reverse-engineered.
Many applications used by public agencies are useful to other sectors of society as well. That means that investments in software can have an impact on those sectors, well beyond their use by the administration itself. Common examples involve sophisticated new technologies developed for military use, which often prove valuable later in civilian aviation, communications, or even consumer products.
If the government’s investment is devoted to proprietary software licenses, the impact does not reach outside the administration. But if it is devoted to FLOSS, the improvements, adaptations, or new software that results from the investment is also available for the rest of the public.
A specific example case concerns localization of FLOSS. When a public agency localizes a product, that localization is almost automatically available to citizens. In the case of small linguistic communities, this can be the only way to have localized software available.
FLOSS can help to develop or support a local IT industry, which in some cases is a secondary mission for the investment of public agencies in software. In the case of proprietary software, the expenditure in licenses usually goes directly to the producer, generating little technological activity in the region.
But in the case of FLOSS, local companies will compete to provide software and services to the administration. FLOSS therefore levels the playing field, making it easier for anyone to compete. Companies with a strong local presence will usually have a competitive advantage, all other factors being equal.
Although some FLOSS developers provide excellent support, formally or informally, both the developers and the larger community surrounding the software tend to expect a user to take some responsibility for understanding the software and investigating a problem before asking for help. Whether the user is reporting a bug or merely trying to get information about confusing product behavior, the request should show care, thought, and research; failure to do so in a free-support forum may be received with negative messages that may be perplexing for the user. The availability of source code, while usually not of interest to end users, guarantees that an internal support staff can, eventually, reach an arbitrarily high degree of expertise on the software being employed, and at the same time it provides for the opportunity of creating local modifications that in some instances may provide a significant added value.
These expectations place more of a burden on the agency’s IT staff, but the long-term effects can benefit the agency. Staff morale may be improved because these professionals feel they have more control over the resources they’re working with, and they have more scope to learn skills they find both interesting and valuable for career advancement.