Why Open Source Software Matters for Government and Civic Tech - and How to Support It

Today we’re publishing a new research paper looking at whether free/open source software matters for government and civic tech. Matters in the sense that it should have a deep and strategic role in government IT and policy rather than just being a “nice to have” or something “we use when we can”. As the paper shows the answer is a strong yes: open source software does matter for government and civic tech – and, conversely, government matters for open source. The paper covers:

• Why open software is especially important for government and civic tech
• Why open software needs special support and treatment by government (and funders)
• What specific actions can be taken to provide this support for open software by government (and funders)

We also discuss how software is different from other things that government traditionally buy or fund. This difference is why government cannot buy software like it buys office furniture or procures the building of bridges – and why buying open matters so much.

The paper is authored by our President and Founder Dr Rufus Pollock.

Why Open Software

We begin with four facts about software and government which form a basis for the conclusions and recommendations that follow.

1. The economics of software: the first copy is expensive whilst additional copies cost nothing (high fixed / zero marginal costs); software is incremental: new code builds on old. The cost structure creates a dilemma between finding ways to pay for the first copy and distributing the software at its low cost of copying – distributing at this zero cost is important to ensure access for all potential users and reusers. Proprietary software resolves this dilemma by raising prices: this helps pay for the first copy but restrict access and reuse. Open source favours efficient pricing and access but has the problem of raising funds to make quality software in the first place. The incremental nature of software sharpens this dilemma and leads to technology and vendor lock-in when the software is proprietary.
2. Switching costs are significant: it is (increasingly) costly to switch off a given piece of software once you start using it. This is because you make “asset (software) specific investments”: in learning how to use the software, integrating the software with your systems, extending and customizing the software, etc. These all mean there are often substantial costs associated with switching to an alternative later.
3. The future matters and is difficult to know: software is used for a long time – whether in its original or upgraded form. Knowing the future is therefore especially important in purchasing software. Predictions about the future in relation to software are especially hard because of its complex nature and adaptability; behavioural biases mean the level of uncertainty and likely future change are underestimated. Together these mean lock-in is under-estimated.
4. Governments are bad at negotiating, especially in this environment, and hence the lock-in problem is especially acute for Government. Government are generally poor decision-makers and bargainers due to the incentives faced by government as a whole and by individuals within government. They are especially weak when having to make trade-offs between the near-term and the more distant future. They are even weaker when the future is complex, uncertain and hard to specify contractually up front. Software procurement has all of these characteristics, making it particularly prone to error compared to other government procurement areas.

The Logic of Support

Note: numbers in brackets e.g. (1) refer to one of the four observations of the previous section.

How to Promote Open Software

We have established in the previous section that there is a strong basis for promoting open software. This section provides specific strategic and tactical suggestions for how to do that. There are five proposals that we summarize here. Each of these is covered in more detail in the main section below. We especially emphasize the potential of the last three options as it does not require up-front participation by government and can be boot-strapped with philanthropic funding.

1. Recognize and reward open source in IT procurement.

Give open source explicit recognition and beneficial treatment in procurement. Specifically, introduce into government tenders: EITHER an explicit requirement for an open source solution OR a significant points value for open source in the scoring for solutions (more than 30% of the points on offer).

2. Make government IT procurement more agile and lightweight.

Current methodologies follow a “spec and deliver” model in which government attempts to define a full spec up front and then seeks solutions that deliver against this. The spec and deliver model greatly diminishes the value of open source - which allows for rapid iteration in the open, and more rapid switching of provider - and implicitly builds lock-in to the selected provider whose solution is a black-box to the buyer. In addition, whilst theoretically shifting risk to the supplier of the software, given the difficulty of specifying software up front it really just inflates upfront costs (since the supplier has to price in risk) and sets the scene for complex and cumbersome later negotiations about under-specified elements.

3. Develop a marketing and business development support organization for open source in key markets (e.g. US and Europe).

The organization would be small, at least initially, and focused on three closely related activity areas (in rough order of importance):

1. General marketing of open source to government at both local and national level: getting in front of CIOs, explaining open source, demystifying and derisking it, making the case etc. This is not specific to any specific product or solution.

2. Supporting open source businesses, especially those at an early-stage, in initial business development activities including: connecting startups to potential customers (“opening the rolodex”) and guidance in navigating the bureaucracy of government procurement including discovering and responding to RFPs.

3. Promoting commercialization of open source by providing advice, training and support for open source startups and developers in commercializing and marketing their technology. Open source developers and startups are often strong on technology and weak on marketing and selling their solutions and this support would help address these deficiencies.

4. Open Offsets: establish target levels of open source financing combined with a “offsets” style scheme to discharge these obligations. An “Open Offsets” program would combine three components:

1. Establish target commitments for funding open source for participants in the program who could include government, philanthropists and private sector. Targets would be a specific measurable figure like 20% of all IT spending or $5m.

2. Participants discharge their funding commitment either through direct spending such as procurement or sponsorship or via purchase of open source “offsets”. “Offsets” enable organizations to discharge their open source funding obligation in an analogous manner to the way carbon offsets allow groups to deliver on their climate change commitments.

3. Administrators of the open offset fund distribute the funds to relevant open source projects and communities in a transparent manner, likely using some combination of expert advice, community voting and value generated (this latter based on an estimate of the usage and value of created by given pieces of open software).

5. “Choose Open”: a grass-roots oriented campaign to promote open software in government and government run activities such as education.

“Choose Open” would be modelled on recent initiatives in online political organizing such as “Move On” in the 2004 US Presidential election as well as online initiatives like Avaaz. It would combine central provision of message, materials and policy with localized community participation to drive change.