by Andrew Oram
This is a prepublication version of an article published in the Journal of Information Technology & Politics, Volume 8, Issue 3, July-September 2011, copyright Taylor & Francis.
Open source software has long been used by government agencies, and prospects for increased use have been greeted enthusiastically by both knowledgeable government employees and open source communities. But mobilizing the necessary forces in government to procure open source software has proven difficult. Instead of a vague statement of principle or a naive focus on cost reduction, government agencies should review and focus on core responsibilities to the public: access for all, vendor independence, archiving, special government needs, and security. Managers promoting open source should gain insight into how it is produced and what its adoption entails, while a statement of explicitly political goals an provide the necessary backbone to carry through with the project. This paper also introduces recent experiments in soliciting software contributions online, shows the relationship of open source software to open government, discuss the importance of open standards to the adoption of open source, and stresses the importance of a robust requirements assessment, highlighting models from the Department of Defense, the Commonwealth of Massachusetts, and the city of Munich, Germany.
Open source software1 has long been in use among government agencies, and prospects for increased use have been greeted enthusiastically by both knowledgeable government employees and open source communities. But mobilizing the necessary forces in government to procure open source software has proven difficult. This paper explores the reasons so many efforts have stalled, and the lessons taught by the successful efforts. It will cover:
Reasons for adopting open source software that are particular compelling in a government setting
The relation of open standards to open source software and the importance of standards to the adoption of open source software
The importance of starting with a profound insight into the community and development processes for open source
The value of explicit political goals
Processes for establishing government agency requirements
The use of open portals or version control systems to solicit contributions of software
Widespread enthusiasm for the use of open source software already exists in federal agencies, often invisibly to the public. The movement for open source software enjoyed a publicity boost when the White House launched its recovery.gov Web site on the open-source Content Management System called Drupal (Scola, 2009), but countless earlier examples of its use abound, such as Department of Energy’s Open Energy Information (OpenEI) platform, the Department of Homeland Security’s Virtual USA information sharing site, and the Veteran Administration’s release of its VistA health record system (Veterans Health Administration, 2010).
Yet most departments still have little understanding of fundamental goals of open source software adoption, and lack a path toward making decisions in keeping with core government responsibilities. Cost savings, the naive enticement, doesn’t provide good enough motivation in the end. Although proprietary software (the complement to open source software) tends to come with high licensing fees, whereas open source software can be downloaded without payment, monetary arguments for deploying open source software are usually unsuccessful because the high costs of conversion, retraining, and developing an adequate base for support can postpone the potential savings of open source software for many years.
Actual attempts at migration, both positive and negative, show that managers interested in open source must back up their commitment with explicitly political goals, while offering arguments that are more subtle than cost savings and that cite the public interest.
As open source proponents never tire of pointing out (but business and policy decision-makers rarely grasp), the key trait distinguishing open source software from proprietary software is not its availability free of cost, but its provision under a license that allows anyone to alter it and redistribute the altered form. Freedom to change, improve, and extend the software—that is the trait that draws a hard and fast line between software that can be defined as open source and software that remains locked in to a particular developer. Revealing source code to a particular customer or even to the general public is not enough to define a product as open source; it must also have a license that allows unlimited changes and redistribution by anyone.
The advantages this trait of open source software offers are well catalogued—the ability to continue support and development if the original developer goes out of business,2 the ability to extend it in ways that the original developer does not find worth its while, the community involvement in finding and fixing bugs quickly, and other benefits—but governments are additionally mandated with several responsibilities that make open source software particularly necessary:
If sharing documents or interacting with an agency requires a software purchase, the agency effectively discriminates against some of its constituents on economic or technological grounds.
To require software from a particular source, whether or not the source charges for it, is a form of unfair favoritism. In addition, dependence on the vendor increases risk in the event that the vendor goes out of business, stops supporting a product, or makes changes that leave documents incompatible with earlier ones.
Agencies must preserve many documents for periods measured in decades. A vendor, at its own discretion, can stop supporting a format at any time. Even vendors who commit to supporting their formats can upgrade them in ways that render old documents unmanageable. Large institutions consequently spend large sums to copy documents to new formats (both hardware and software) in a Red Queen’s race to simply maintain a consistent level of access to these documents. Many institutions require documents to be put on paper merely for archival reasons, but the paper obviously lacks the digital formats’ advantages in searchability and computer processing.
Governments have special requirements, notably regarding privacy, that vendors need not respect. This conflict came up recently not with licensed software, but with the federal rush under the Obama Administration to use popular online media and social networks such as YouTube and Twitter (Grove, 2009). On June 25, 2010, in recognition of the special responsibilities of federal agencies, the Office of Management and Budget released two memoranda governing the use of personally identifying information and social networks (Orszag, 2010a; Orszag, 2010b).
As shown by the previous item, private firms can insert features into software that may be detrimental to safety or organizational practices. Many private software solutions, for instance, use fragile encryption mechanisms and other poor security features; the users cannot even assess the vulnerabilities without access to the source code, and cannot fix them because they lack the legal right to alter and redistribute the program. Governments have procedures for doing assessments of critical software, but open source software provides a guarantee, unmatched by any closed source software, that users can find and fix security flaws without waiting for the vendor.
The cases cited in this paper demonstrate that new organizational initiatives often spawn an interest in open source:
A Peruvian law mandating open source sprang from attempts by a software architect to rectify ambiguities and inconsistencies in the application of tax codes (Chan, 2008).
The U.S. state of Massachusetts reached the decision to allow open source software when required to make a strategic plan for government software use (Updegrove, 2007b).
The city of Munich opened up an inquiry leading to the adoption of software when it had to face the end-of-life announcement for its Windows software (Schießl, 2009).
The adoption of open source software is more than a technical matter, or even a policy decision. It imposes new tasks on management and staff alike, requiring a heightened engagement with the software development process:
Merely learning about the existence of appropriate open source software can be difficult, because most projects lack marketing staff.
Installation often requires many manual steps and the integration of several different software packages, tasks simplified in the case of proprietary software because vendors provide a turn-key procedure or send staff to the agency site to perform installation.
Open source software tends to be updated more frequently than proprietary software and may require agency staff to explicitly check for updates, in contrast to proprietary products that roll out official upgrades.
Open source software provides valuable opportunities to collaborate with the community that builds up around the software, but this requires an understanding of the dynamics of such communities and the dedication of agency staff to maintaining a relationship.
Licensing of open source software, although intended to promote free exchange, embodies restrictions of its own that agencies must understand if they plan to distribute it publicly.
Hence, management and staff must possess an understanding of the open source movements and its communities that goes beyond what they can learn merely by reading about it in the press or talking to advocates.
Government agency managers like to think of themselves as rational actors who weigh courses of action objectively. In reality, of course, prejudices and simple inertia dog every decision. Resistance to major changes such as the adoption of open source software can often be blamed on vendors of the products in current use. But before they even face such lobbying,managers and advocates for open source software must recognize and counter the resistance that develops naturally within an agency. When all stakeholders inside the agency are firmly committed to a course of action, outside pressures can be more successfully parried.
Joseph Reddix, an entrepreneur with forty-two years of experience both inside and outside government, notes that the major barriers to change are cultural. These include:3
Familiarity with current software.
Fear of failure, which reduces willingness to undergo risk.
Lack of knowledge about open source, which requires the kind of direct experience described in the previous section.
Concerns about the maturity of software that is newer than the proprietary products in current use, as open source tends to be.
Other issues in government IT are double-edged: they can either retard or motivate the adoption of open source. These issues include:
Some managers with a poor understanding of open source accept the canard that it is inherently less secure. Those with a stronger understanding realize that they can evaluate its security directly by having knowledgeable staff or outside experts look at the source code and do white-box testing.
Most software must exchange data with other, existing programs, often in other agencies or with outside partners. When such programs are proprietary and fail to adhere to standards, they impede the adoption of any new solution, whether proprietary or open source. But integration works in favor of open source in departments willing to take on the costs of large-scale migration, because the transparency of open source software allows it be integrated more readily.
Proponents of open source therefore perform a delicate balancing act. They need to follow formal guidelines by producing objective justifications for a move to open source. But the inner fire that will actually make migration successful is grounded in political conviction.
Peru provides a good example. Chan reports the public agitation that saved the Law for the Use of Free Software in Government Agencies, Proposition 1609 (Chan, 2008):
…the proponents of Peru’s FLOSS bill had to undertake various forms of local and non-local work to advance their interests. Their practices departed from the language of technical and economic rationality that is repeatedly invoked to explain FLOSS’ adoption. They insisted instead on a new framing of FLOSS as necessarily engaged with governance and political reform….
…the bill was not motivated by economic rationales but by the state’s "fundamental" political obligation to citizens. These [sic] included ensuring citizens free access to public information and ensuring the permanence of public data.
The bill favored the use of open source in public agencies, stating the explicitly political justification of eliminating Peru’s dependence on foreign software. A later letter from congressman Villanueva, the bill’s sponsor, added to its goals (Greene, 2002):
Free access to public information by the citizen
Permanence of public data
Security of the State and citizens
Even more insistent political goals drove the civil society support for the bill (Chan, 2004): the demands for open formats and protection of data as a way to secure the rights of citizens vis-a-vis their own government. It was the General Manager of Microsoft Peru, in opposing the bill, who called for decisions to be made on consideration of technical requirements alone.
It cannot be overstated how important was the public mobilization in defense of the Law for the Use of Free Software in Government Agencies—a mobilization that had overt political goals and took on an international character—for the ultimate passage of the bill. Proponents helped Villanueva fashion his responses to critics and created a groundswell of public opinion in favor of the originally obscure measure.
Other governments have also mandated the use of open source software on the grounds of principle. An official announcement in Venezuela came straight from the President, Hugo Chávez, in 2004 (Wilpert, 2004). Sociological research by Shaw discovered a core activist layer of Brazilian proponents of social change whose work in the computer field and whose understanding of the open source movement propelled the adoption of open source by many Brazilian government agencies early in the Lula administration (Shaw, 2010). These leftists worked effectively with managers of state banks who saw practical advantages in the adoption of open source, and it certainly helped for IBM, the major computer services provider in Brazil, to champion Linux.
Such high-level support for open source can improve the general atmosphere for discussing its adoption, but to make adoption happen, the management of particular agencies must be firmly committed to it—and must understand the efforts needed to fulfill the commitment. No pronouncement by Hugo Chávez in Venezuela or Vivek Kundra in the U.S. can by itself bring open source into agencies; it is the local management and staff that will install it, resolve interoperability problems, provide training, and interact with the community surrounding the software.
The kind of fundamental dedication to change described in the previous section reaches its clearest expression in the movement known as open, transparent, or participatory government. This movement has been growing rapidly for the past several years. The best-known example comes from the most powerful body in the world, the U.S. Federal Government, where President Obama released a Memorandum on Transparency and Open Government on his first day in office (Obama, 2009). On December 8, 2009, the Office of Management and Budget pressed on with the initiative, issuing a directive to executive departments and agencies with steps to take toward openness (Orszag, 2009).
The open government movement tends to release information in digital form and to exchange digital information over the Internet to draw on public input to government decisions and projects. The new forms of public participation in government spread across a broad range of activities. A few examples include:
Expansion of the conventional "notice and comment" period for government regulations
Crowdsourcing, or requesting information about living conditions directly from ordinary citizens "on the ground" at a much lower cost and with much more accuracy than the agency could achieve by assigning staff to the task
Public monitoring to avoid fraud and waste, exemplified by the Federa IT Dashboard tracking federal IT project progress and expenditures, which Vivek Kundra, the first CIO of the U.S. federal government, unveiled shortly after his appointment
The creation and release of computer programs to collect and upload data from the public or to process mass downloads of data in program-friendly form provided at locations such as the U.S. government agencies’ data.gov site.
These initiatives provide new imperatives for open source software, because the open government movement relies and thrives on access by all and on the transparency of the data and software tools used to implement public interaction. Much of the information exchanged in the open government efforts comes in documents, audio files, or videos, running into the responsibility for access discussed earlier in this paper. Open formats, the topic of a later section, should be a requirement for any outreach to the public.
A standard can be established many ways—there are de facto standards as well as de jure standards, and the de jure standards can be established in a more or less open fashion—but open standards provide the most chance for wide-spread participation for setting the standard and the most opportunity for competitive implementations. Standards that are not completely open make it difficult or even impossible for anyone to provide working alternatives to the implementations currently in use, and any element that hinders competition in this manner is inimical to the impetus to create the standard in the first place.
A trivial but highly relevant example is the licensing that encumbers all popular digital audio and video formats. An open source MP3 player cannot legally be distributed in the United States and many other countries, because elements of the MP3 format were documented in patents whose owners exploit to extract on royalties (Thomson, 2010).
Robust and rich-featured standards exist for audio and video and are supported by many players, both proprietary and open source. But the proprietary software and hardware vendors prefer the encumbered formats and promote their use. The general public does not understand the complexity of patents and licensing and are generally shielded from their consequences because companies such as RealNetworks, Inc. (the distributors of RealPlayer), Microsoft, and Apple usually absorb the royalties and offer players for no cost. But unless the vendors choose to offer players for alternative operating systems such as Linux, no legal options exist—and even if players are offered, the encumbrances prevent them from being open source software.
The World Wide Web Consortium, which is led by Tim Berners-Lee and maintains the most basic specifications for the Web (starting with HTML and HTTP) came to a major fork in the road in 2001 when they were pressured to standardize technologies covered by patents and requiring royalties for use. The Consortium tried to create a pathway for royalties using the common language of "reasonable, non-discriminatory royalties or fees" (World Wide Web Consortium, 2001). They were quickly inundated by outcries from the WeWb developer community, pointing out that once technology requiring royalties became deeply embedded in Web technologies, individual companies could restrict activities on the Web. Royalties imply conditions for use, which in turn imply limitations, and because the way intellectual property limitations operate is that anything not explicitly permitted is forbidden, these limitations will at some point inhibit the rights of users and opportunities to innovate on top of the patented technologies.
The final policy upheld the principles of open standards and required all technologies to be royalty-free (World Wide Web Consortium, 2004). The W3C thus avoided the risk of promoting policies that could fence off key Web technologies. (Given the workings of the patent system, the principle applies only to those who participate in setting the standard—outside parties can still pop up to assert patents and try to exert control over commonly used technologies.)
More troubling is the famous case of the Microsoft Office formats, which went through a standardization process at Ecma (an organization known for standardizing JavaScript, among other computer technologies) and the International Organization for Standardization, one of the world’s premier standards institutions. The story made headlines in the mid to late 2000s. A bit of history concerning this standardization process and the attempt of the Commonwealth of Massachusetts to adopt open source software shows why governments must be cautious in endorsing standards.
In the mid-2000 decade, Massachusetts hosted what probably remains the most far-reaching attempt in the United States to deploy open source in government. A secretary of finance and the state’s Information Technology Division planned and began a massive move from Microsoft Office to OpenOffice.org. The experiment ended only when the state legislature defunded the project without explanation or justification.4
To understand how open source got as far as it did, we must start in 2003 when Governor Mitt Romney brought Eric Kriss into government as Secretary of Administration and Finance. Romney, as most Americans remember, is no political Hugo Chávez; rather, he is part of a multi-generation Republican family and holds socially and fiscally conservative values. The key factor in the migration decision was not ideology but information: Kriss came with some technical background in computing, which in turn gave him an appreciation for the achievements made by open source software and its potential in government (Updegrove, 2007b).
Reasons Kriss initially put forward for using open source included:
Cost savings. The ITD demonstrated that using OpenOffice.org would save money over time. The legislature challenged their claim and even had the state auditor make a special assessment, an almost unheard-of intervention into administrative affairs. The auditor upheld the ITD’s evaluation.
Taking advantage of the high quality of open source software, where pertinent.
Using open formats to protect access to information by public and by agencies themselves over time.
Promoting competition and breaking de facto monopolies of software vendors in certain state functions.
Until 2003, the government of the Commonwealth of Massachusetts had no policies or standards regarding software procurement. Although a few people in the administration knew of open source, there was no organized movement for it in the government.
The movement toward open source began with the passage of a state law that said nothing about open source and that the legislature could not have imagined would have any impact on open source. The law simply ordered a strategic plan for technology and the adoption of a set of best practices, and set up an IT commission to implement this initiative.
While working on the state technology plan, Secretary Kriss and state CIO Peter Quinn noticed that Microsoft held a patent on aspects of the XML format in its Office 2003 product. They were concerned about ways it might leverage its patent to demand fees or terms that they didn’t consider in the public interest. For instance, Microsoft could theoretically charge a fee for every document issued by the state.
Kriss and Quinn met with Microsoft managers, asking them to give up rights to the patent. Microsoft refused, never even explaining why they had obtained the patent.
Thus, while we have seen that Kriss was predisposed toward open source already, the patent irritant contributed to his statement in the official Enterprise Technical Resource Model in 2003 that the state would seek to use software and formats conforming to international standards. The model also indicated that open source would be preferred where it met the state’s needs.
After a number of CEOs from computer companies, as part of the Massachusetts Software Council, pressured the administration, Kriss and Quinn retreated slightly and said simply that open source would get fair consideration.
In 2005, Kriss and Quinn put the ETRM into effect by determining which employees using desktop computers would migrate to OpenOffice.org. The goal was to use OpenOffice.org wherever feasible.
At that particular time, Excel was superior to OpenOffice.org’s corresponding spreadsheet tool, and OpenOffice.org lacked (then and now) support for Excel macros. Therefore, finance department staff who created spreadsheets were kept on Excel. A few other departments with similar needs for Microsoft software were given dispensations to keep using it. However, Quinn found that most state are just consumers of data or creators of very simple documents; all they needed was a generic office suite and a web browser. Thus, 50,000 office workers in the Massachusetts state government were designated to move to OpenOffice.org.
Public debate arose over the issue of accessibility, particularly for the visually impaired, which Quinn had not considered. Massachusetts did not have an accessibility law, as the federal government does in the famous Section 508 of the 1998 revision of the Rehabilitation Act (IT Accessibility & Workforce Division, 2010).
Microsoft Office did not support accessibility until the community pressured it in the mid-1990s, but currently has that support. Microsoft noted OpenOffice.org’s lack of accessibility features and organized representatives for visually impaired to protest the adoption of OpenOffice.org. Quinn admitted he had made a mistake and said OpenOffice.org would not be deployed until it incorporated that support. This incident highlights the importance of understanding open source software thoroughly during the evaluation process.
However, the true barriers to adoption of open source came from special interests and from internal inertia. Lobbyists for commercial software vendors prevailed on the legislature at every juncture. The conservatism of government agencies described earlier in this paper also came into play.
Initiatives such as the one in Massachusetts to adopt ODF were launched in many U.S. states but ultimately defeated after sustained lobbying by Microsoft (Lai, 2007). One result of the budget cuts and political fighting in Massachusetts was the departure from government of the original backers of OpenOffice.org migration, a vacuum that set up a reversal of its principled demand for an open format.
As the Massachusetts administration was formulating its policy on open formats, Microsoft at first fought and failed to get the administration to accept Microsoft Office formats in the initiative (Berlind, 2005), then developed Office Open XML (OOXML), an XML implementation of its Office formats, and presented it to several government bodies as well as to Ecma and ISO for approval.
Critics of the Microsoft bid raised numerous grounds on which the Microsoft Office formats do not constitute a standard (ODF Alliance, 2008; Groklaw, 2010). Even topping 6,000 pages, the Microsoft specification for what they called OOXML did not fully specify the behavior of their office suite and could not serve as the basis for an alternative implementation. Even Microsoft Word in its different versions are incompatible. For instance, documents created with the current Windows version might not display properly on the current Macintosh version, or change tracking might cause corruption when documents are exchanged.
OOXML passed through Ecma quickly. This credential, giving Microsoft a claim to credibility in the standards space, played into an announcement by Massachusetts’ IT division in 2007 that OOXML was acceptable along with ODF as an open format (Johnston, 2007). In practice, of course, this announcement represented an acceptance of the status quo and an admission that the state would not switch any systems to ODF or OpenOffice.org.
Given the funding cutoff, the IT department had no recourse except to stick with Microsoft Office, but along with Ecma, their deviation from principle helped to blur the definition of an open standard. If practical necessities require a government agency to set aside its commitment to archival security, open access, and related responsibilities, this should be stated candidly. Abatements can be changed later when financial or technical improvements make it possible to use open standards. But to declare something open when it is not does more than sow distrust—it pollutes future debate and perpetuates public ignorance. Furthermore, agencies should not accept uncritically a moniker of "openness" from other institutions, even highly regarded ones such as Ecma and ISO, when these institutions take a lax attitude toward the traits held important in the open source movement.
ISO also turned down OOXML at first, one of the grounds being that it duplicated the functionality of the already adopted ODF standard. The debate led to an unprecedented politicization of ISO, as numerous members took advantage of loose membership rules to join at the last minute and vote on the issue, usually taking Microsoft’s side (Updegrove, 2007a). The administration of ISO also seemed determined to give Microsoft what it wanted, and managed to reverse the vote six months later, amid widespread accusations of arm-twisting and despite several appeals (Jones, 2008).
The purpose of this abbreviated history of the OOXML standard has not been to denigrate the use of Microsoft Office. Millions of office workers and ordinary computer users around the world depend on Office, and the creation of OOXML was a boon to developers who can use widespread XML tools to manipulate Office documents. Competition with ODF did in fact make Microsoft more open—though not in the rigorous sense described in the previous section—and create, in the end, more opportunities for Office users.
We can thus congratulate the open source software community for promoting competition—and Microsoft for improving its product in response—while holding aloft the ultimate goal of a truly open format, just as we can congratulate government agencies who have threatened to adopt ODF and have used that tactic as leverage to win lower license fees from Microsoft, but hope that the agencies reconsider ODF in the future.
What then constitutes an open standard? A good definition is fairly complex. One excellent example was developed by a European Union task force called Interoperable Delivery of European eGovernment Services (Final European Interoperability Framework, 2004). In addition to various common-sense prerequisites and an insistence that patented technologies be available on a royalty-free basis, version 1.0 of the document calls for the standard to be maintained by a not-for-profit organization open to all parties. This is not an iron-clad guarantee of openness, because an open body can be captured by biased leaders and its membership can be manipulated. But at least the definition precludes a vendor from simply declaring its product a standard. It is now the responsibility of IDABC to maintain the uncompromising clarity of this definition, and not to contribute to the same dilution of language and the public interest that can be laid at the feet of Ecma, ISO, and the state of Massachusetts.
The last section of this article offers some models and points to resources for government agencies committed to fulfilling the fundamental public responsibilities listed in the first section.
One fine model for open source planning is provided by a European Research project called "Consortium for studying, evaluating, and supporting the introduction of Open Source software and Open Data Standards in the Public Administration" (COSPA, 2005). (In Europe, the term "public administration" is generally used for an institution that in the United States is called a "government agency.") COSPA starts by asking not what kinds of software an agency needs, but what core computing activities or business processes it performs.
The emphasis on business processes is crucial to undercut historical assumptions that limit the possibilities for future evolution. As a trivial example, consider asking an agency IT manager what software they need for document creation and exchange. The IT manager might reasonably respond, "We need software to create and edit PDF files," because they currently exchange and release a lot of documents in that format. This kind of assessment locks the agency into historic practice, and probably into a proprietary product. But what is a PDF after all? A format designed specifically to produce printed pages. As documents are exchanged and collaboratively written online, PDFs become less and less relevant.
PDFs are particularly inappropriate for much of the information released by initiatives in open government. These initiatives tend to involve large data sets appropriate for searching, filtering, and automated processing. For instance, people who visit an agency’s Web site for crime statistics might want to compare the number of crimes reported in different counties or city districts. Governments typically release this information in tabular form in a Word or PDF file, making it extremely hard to extract in a form amenable to searching and statistical analysis.
In the COSPA framework,5 a better starting point for discussion is the question, "How do you create, exchange, and review information?" The IT manager would list the kinds of information each department works with and the types of work done by employees with that information. It may then emerge that the department’s needs are best met by a wiki, an online service such as Google Docs, or some other system focused on storing and exchanging documents online.
Such a conclusion still leaves several tasks to the agency. It must determine whether it can afford a move to more appropriate formats and software packages, and must develop a transitional program such as the one created by the Massachusetts IT division.
One valuable historical precedent for this task is the assessment of costs and benefits done for the city of Munich in Germany (UNILOG Integrata et al., 2003). Tellingly, the city adopted Linux even though the assessment showed that the transition would cost more than an upgrade to new Microsoft products. Conversion costs would, in the time frame feasible for financial planning, exceed Microsoft licensing fees, especially given aggressive cuts in pricing that Microsoft offered to maintain its contract (Best, 2004).
Like other projects described in this article, the Munich decision was the culmination of a more general inquiry—in this case, the need to replace Windows NT 4, whose end-of-life had been declared by Microsoft. City regulations required the staff to consider alternatives to a simple Windows upgrade (Schießl, 2009).
The Munich experience provides a lesson to other government bodies in determining their true values and requirements. Their research balanced a "Cost-effectiveness analysis" against a "Qualitative-strategic analysis" that reflects some of the responsibilities in the first section of this article, along with other strategic considerations such as employee satisfaction and the ability to work with other organizations. (As the IDABC document illustrates, inter-agency cooperation is a key motivator for re-examining software use in European governments.)
A staff person coordinating the migration therefore defends the pragmatism of the decision: "it’s not a kamikaze mission by some crazy free software enthusiasts." (Schießl, 2009) Nevertheless, the decision ultimately was based on political considerations, specified in one document (Schießl, 2010a) as:
Independence and increased flexibility for decisions about software and architecture
Sensible and sustainable use of taxes
Strengthening of Munich as an IT location
One of the key considerations I mentioned earlier that can impede the adoption of open source, the difficulties of interoperability, became very evident in Munich. Schießl reports that Munich started the migration with the following environment: "More than 300 apps, many of them redundant…21 different Windows clients, different patch levels, different security concepts." (Schießl, 2010b). Taking control of this gangly IT creature took precedence over the migration itself.
The IT staff wisely allowed five years for migration. Three years were devoted to setup, customizing, and prototyping. This period included setting standards, determining migration paths, identifying the potential for consolidation, and building knowledge. Two more years were allocated for migration to OpenOffice.org, followed by rollout of Linux on all desktops. This period included training and quality assurance. It was necessary to expand technical support and put it on a firmer footing by such means as formalizing expertise and creating self-paced training materials. For a substantial period—all during the migration—Microsoft Office was still the standard. (Schießl, 2010c)
Cassell reports, from research in Munich and two other German municipalities, that centralized IT also facilitates a major migration such as the adoption of open source software (Cassell, 2010).
As of December 2009, the migration effort had accomplished the following:
All 15,000 workplaces use free software (presumably OpenOffice.org).
Open Document Format is the standard for exchange.
All employees are trained to use OpenOffice.org.
2,500 workplaces use the Debian GNU/Linux operating system
Coordinated efforts to share best practices around open source software in Europe have led to an Open Source Observatory and Repository, which describes itself as "a platform for exchanging information, experiences and FLOSS-based code for use in public administrations" (OSOR, 2010). Two other European projects using robust analytical frameworks include Eurostat’s data interoperability project (Bierhals, 2009) and an open source migration project by Finland’s Ministry of Justice (OSOR, 2008).
An analytical framework allowed these agencies to determine what was really important to them, and to balance financial against non-financial goals. If agencies adopt the course followed by Munich—a robust methodology for determining their software requirements combined with the political will to carry through migration in the face of multiple barriers—the path to open source can be taken by government agencies in the United States and around the world.
Agencies with an interest in open government and open source have recently adopted a software adoption strategy radically different from standard procurement procedures, which emphasize top-down planning and requirements processes that are discredited in much of the software industry. The new procurement procedures use version control and communication tools that have sprung up naturally among software developers, particularly the open source movement, as means of soliciting and building software. Sharing and collaborative development—including Darwinian processes in which different implementations of features can compete for favor among users—have taken place for years on sites such as SourceForge and Github, so the new wave of government open source projects simply hook into practices that are already familiar to developers.
Among the new systems that make use of current, state-of-the art collaboration tools for software development are Apps for Democracy (created for the District of Columbia by CTO Vivek Kundra) and Apps for America (set up by the Sunlight Foundation on a national US level). Technically, these are fairly straightforward projects based on a version control system. But probably the most well-established and productive of these sites is Forge.mil, the Department of Defense collaborative software development site.
The Department of Defense, generally considered a conservative and cautious institution, has sought out open source software for its reliability for many years. A recent memo from the CIO’s office states (Wennergren, 2009):
To effectively achieve its missions, the Department of Defense must develop and update its software-based capabilities faster than ever, to anticipate new threats and respond to continuously changing requirements. The use of Open Source Software (OSS) can provide advantages in this regard.
Forge.mil6 was set up by , an agile software development firm. It differs from totally open sites such as Apps for Democracy by providing several levels of control. The site is open to all members of the US military and intelligence agencies, along with contractors sponsored by a military agency. However, it is closed to the rest of the world. By limiting access, it provides what the military sponsors feel is a safe space for accepting innovations.
One area of the site (software.forge.mil) is for open source software, but another area (project.forge.mil) is subdivided into more restricted areas for closed-source projects. The open source area serves the project area as a set of libraries and components, conceptually a platform for building more specific solutions. Military and intelligence units can set up projects and invite in contractors who develop closed-source code. There are also areas on Forge.mil for testing, certification according to government specifications, and listing the standards that the agencies want contributors to follow (external XML specifications, etc.).
Forge.mil benefited from several forward-thinking decisions:
Management did not cut off the original proprietary vendors, but required them to work within the new paradigm. This allowed organizational knowledge to be transferred smoothly to new, open source participants. Such a decision is probably easier for the DoD to enforce than smaller agencies, admittedly.
DISA worked with a respected and highly experienced company, CollabNet, to set up an Agile software development environment. CollabNet specializes in combining the efforts of multiple independent developers.
Management brought major stakeholders in early, both people inside the DoD who were needed to carry through the implementation, and outside vendors. Everyone made a commitment and was given tasks to do. This collaboration allowed them to learn each other’s issues and abilities as they went along.
Management ensured security on Forge.mil.
DISA required only 180 days to set up the first component of Forge.mil (SoftwareForge), an unheard of achievement in government. This engendered trust in the system and kept stakeholders engaged. Guy Martin of CollabNet, the award-winning lead community manager for Forge.mil (CollabNet, 2010), has described their work as a model for the Obama administration’s goals in transparency and open data (Martin, 2009).
Fluid development processes such as the ones used by Apps for Democracy and Forge.mil offer a great deal of promise, but there are very few examples of these government initiatives and existing ones are mostly quite young. In any case, it will take more than an end-run around traditional waterfall practices to migrate core servers and desktops to open source. All the insights in this paper about strategic planning and government responsibilities to the public are still critical to making choices that will ultimately improve agency operations and serve the public better.
Along with several other speakers, I also prepared an article for a special issue of the Journal of Information Technology & Politics. The draft on this web page is the text I submitted, but the referees asked for extensive changes that tightened up the article and made it more defensible. I condensed the key points into a list of conditions that tend to be present when open source is successfully adopted by government agencies:
An external trigger, such as a deadline for upgrading existing software
An emphasis on strategic goals, rather than a naive focus on cost
A principled commitment to open source among managers and IT staff responsible for making the transition, accompanied by the technical sophistication and creativity to implement an open source strategy
High-level support at the policy-making level, such as the legislature or city council
During article preparation, I pointed out to the journal’s editor that it would be appropriate to release an issue about open source under a Creative Commons ShareAlike license. He engaged the publisher Taylor & Francis in a discussion about the possibility, but they chose to maintain their standard licensing policy. I naturally support the right of the publisher to choose the license under which its work is distributed, since I work for a publishe myself. I am grateful that Taylor & Francis permits its authors to put prepublication drafts on the Internet.
1 Surveys have shown that developers of open source software prefer the term "free software," but because the term "open source" is ubiquitous in the United States federal government, that term will be used in this paper.
2 Open source advocate David López points out that open licenses have permitted Brazil to develop educational content in Portuguese, and Spanish agencies to translate software into languages not supported by vendors, such as Catalonian, Vaskish, and Galician.
3 Personal conversation with Joseph Reddix.
4 Material in this section that is not accompanied by citations comes from personal conversations between the author and participants, notably former CIO Peter Quinn.
5 COSPA’s process is echoed in the recommendations "WiBe-Framework - WiBe 4.1 methodology: Economic Efficiency Assessment in Federal Administrations (in particular with regard to the use of ICT and eGovernment)," WiBe. Retrieved September 17, 2001.
6 Much of the description of Forge.mil comes from personal conversations with consul tants who set up the site.
Berlind, David (2005). Microsoft vs Mass.: what ever happened to ’the customer is always right’?, ZDNet. Retrieved September 17, 2011.
Best, Jo (2004). Munich to stick with open source. C|Net News. Retrieved September 17, 2011.
Bierhals, Gregor B. (2009). Eurostat: standards and open source software for data interoperability. Eurostat. Retrieved September 17, 2011.
Chan, Anita Say (2008). Retiring the Network Spokesman: The Poly-Vocality of Free Software Networks in Peru (PDF). Science Studies, 20 (2), 78-99. Retrieved September 17, 2011.
CollabNet (2010). Federal Computer Week Honors CollabNet’s Guy Martin With Federal 100 Award. Retrieved September 17, 2011.
COSPA (2005). Work package 2: collection of requirements for OS applications and ODS in the PA and creation of a catalogue of appropriate OS/ODS solutions; deliverable 2.4 & 2.5: analysis of requirements for OS/ODS applications in the public administration (PDF). Retrieved September 17, 2011.
Final European Interoperability Framework - November 2004 (EN) (2004). Retrieved September 17, 2011.
Greene, Thomas C (2002). MS in Peruvian open-source nightmare. The Register. Retrieved September 17, 2011.
Groklaw (2010). EOOXML objections. Retrieved September 17, 2011.
Grove, Steve for Google (2009). White House videos on YouTube. Retrieved September 17, 2011.
IT Accessibility & Workforce Division (2010). 508 Law. Retrieved September 17, 2011.
Johnston, Stuart J (2007). Massachusetts adopts Office Open XML. InternetNews. Retrieved September 17, 2011.
Jones, Pamela (2008). What really happened at the BRM for OOXML & who attended - updates on results. Groklaw. Retrieved September 17, 2011.
Lai, Eric & Keize (2007), Gregg. Microsoft trounces pro-ODF forces in state battles over open document formats. Computerworld. Retrieved September 17, 2011.
Martin, Guy (2009). Government 2.0 From the Inside Out… Retrieved September 17, 2011.
Obama, Barack (2009). Transparency and open government memorandum for the heads of executive departments and agencies. Retrieved September 17, 2011.
ODF Alliance (2010). The case against OOXML (PDF). Retrieved September 17, 2011. No author is given, but another version (PDF) states that the document is "Based on contributions by Rob Weir at IBM and others." Although the document is undated, it apparently was written before the final ISO/IEC JTC1 vote on March 29, 2008.
OSOR (2008). FI: Ministry of Justice migrates to OpenOffice. Retrieved September 17, 2011.
OSOR (2010). OSOR.eu - open source observatory and repository. Retrieved September 17, 2011.
Orszag, Peter R. O., Director, Office of Management and Budget (2009). Memorandum for the heads of executive departments and agencies (PDF). Retrieved September 17, 2011.
Orszag, Peter R. O., Director, Office of Office of Management and Budget (2010). Guidance for Online Use of Web Measurement and Customization Technologies (PDF). Retrieved September 17, 2011.
Orszag, Peter R. O., Director, Office of Office of Management and Budget (2010). Guidance for Agency Use of Third-Party Websites and Applications (PDF). Retrieved September 17, 2011.
Schießl, Florian (2010b). Quality over time in Munich. No longer available online.
Schießl, Florian (2010c). OpenOffice.org für München — unsere Erfolgsrezepte (PDF). No longer available online.
Scola, Nancy (2009). Why the White House’s embrace of Drupal matters. Personal Democracy Forum techPresident. Retrieved September 17, 2011.
Thomson (2010). MP3 licensing royalty rates. Retrieved September 17, 2011.
Updegrove, Andy (2007a). P country upgrades continue - as do document committee signups as well. Retrieved September 17, 2011.
Updegrove, Andy (2007b). ODF vs. OOXML: War of the Words Chapter 4. Retrieved September 17, 2011.
Veterans Health Administration (2010). Requesting VistA Software. Retrieved September 17, 2011.
Wennergren, David M. (Performing the duties of the ASD(NII)/DoD CI CIO) (2009). Clarifying guidance regarding open source software (OSS). Retrieved September 17, 2011.
Wilpert, Gregory (2004). Chávez Announces that Venezuelan State Will Switch to "Free Software." Venezuela Analysis. Retrieved September 17, 2011.
World Wide Web Consortium (2001). W3C patent policy framework: W3C working draft 16 August 2001. Retrieved September 17, 2011.
World Wide Web Consortium (2004). W3C patent policy. Retrieved September 17, 2011.
The author would like to thank Peter Quinn and Joseph Reddix for their time and for their permission to use their interview material; to Anita Say Chan, Carlo Daffara, Chris Hankin, Gunnar Hellekson, David López, Aaron Shaw, and members of Open Source for America for their advice and pointers to key documents; to Pamela Jones for incisive corrections; and to Anthony Gold, Matthew Helmke, Don Marti, Terri Molini, and John M. Weathersby for comments that improved the paper.
Andrew Oram, an editor for the technical publisher and information provider O’Reilly Media, has also been writing articles on technology and its social implications since the mid-1990s (http://www.praxagora.com/andyo/professional/article.html). At O’Reilly Media, he specializes in open source, editing the first books put out by an American publisher on Linux and such ground-breaking works as Peer-to-Peer and Intellectual Property and Open Source. In addition to the the Journal of Information Technology & Politics, print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, and Internet Law and Business. He is also interested in providing better education for online communities, an issue he has researched at http://www.praxagora.com/community_documentation/. A long-time member of Computer Professionals for Social Responsibility, he worked with several organizations to promote socially progressive political positions in areas touching on Internet use, information sharing, and technological development. This article represents his views only.
Author’s home page
Other articles in chronological order
Index to other articles