Today we’re publishing a new white 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.
Download PDF Version of the paper »
Discussion and Comments »
Why Open Software
Open software is important. Important because it reduces lock-in to a particular solution and a particular vendor. This means more competition which lowers costs. It means more flexibility which makes for higher-quality software, better suited to user needs.
To understand why this is we start with four basic facts about software and government.
The economics of software production:
A. Cost structure: making the first copy of a piece of software is expensive but further copies are free. The cost structure creates a dilemma. To get the most value from a piece of software we want as many people as possible to have access to it — to use it, to improve it, to customize it. This suggests distributing software openly at the zero cost of copying. But this may leave us with no revenues with which to pay to create the first copy in the first place. Proprietary software chooses to restrict access and raise prices. This helps pay for the first copy but restricts use and improvement. Open software chooses to keep software free to use and build on. This helps longer-term flexibility, competition and choice. But it causes problems paying for the first copy.
B. Incrementalism: new code builds on old. This sharpens the previous dilemma: what software you invest in to day shapes your options tomorrow. It also leads to technology and vendor lock-in when the software is proprietary.
Switching costs are significant. It is costly to switch off a given piece of software once you start using it — and these costs grow over time. It is costly because you spend time and effort in learning how to use a piece of software, integrating it with your systems, extending and customizing it, etc. Switching to different software means incurring these costs again.
The future matters and is difficult to know: software is used for a long time — whether in its original or upgraded form. Predicting the future is thus especially important when purchasing software. But predicting the future is hard, and especially so for software. This is because software evolves rapidly — as do the user needs. Behavioural biases mean the level of uncertainty and level of future change are under-estimated. A a result lock-in is under-estimated.
Governments are bad at negotiating, especially in this environment. Hence the lock-in problem is especially acute for Government. Government are generally poor bargainers. This is because of the incentives faced by government as a whole and by individuals within government. Government is especially poor at making trade-offs between the near-term and the more distant future. They are even worse 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.
A. Lock-in to Proprietary Software is a Problem
Incremental Nature of Software (1) + Switching Costs (2)
Lock-in happens for a software technology, and, if it is proprietary, to a vendor
Zero Marginal Cost of Software (1) + Uncertainty about the Future in user needs and technologies (3) + Governments are Poor Bargainers (4)
Lock-in to proprietary software is a problem
Lock-in has high costs and is under-estimated – especially so for government
B. Open Source is a Solution
Lock-in is a problem
Strategies that reduce lock-in are valuable
Economics of Software (1)
Open-source is a strategy for government (and others) to reduce future lock-in
Why? Because it requires the software provider to make an up-front commitment to making the essential technology available both to users and other technologists at zero cost, both now and in the future
Together these two points
Open source is a solution
And a specific commitment to open source in government / civic tech is important and valuable
C. Open Source Needs Support
And Government / Civic Tech is an area where it can be provided effectively
Software has high fixed costs and a challenge for open source is to secure sufficient support investment to cover these fixed costs (1)
Governments are large spenders on IT and are bureaucratic: they can make rules to pre-commit up front (e.g. in procurement) and can feasibly coordinate whether at local, national or, even, international levels on buying and investment decisions related to software.
Government is especially well situated to support open source
Government has the tools to provide systematic support
Government should provide systematic support
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):
- 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.
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.
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:
- 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.
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.
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.