How Open Source Procurement Works in Government: A 2026 Guide

How open source procurement works in government is simpler than most people expect: it is the ordinary public purchasing process, run with open source software treated as an equal option rather than a special exception. The agency defines the need, researches what exists, prices the whole life of the software, publishes technology-neutral tender documents, awards against those criteria, then manages patches, upgrades and exit. The one thing that changes is what you pay for, because there is no licence fee to negotiate.

That shift catches a lot of teams out. Rules written to buy proprietary licences assume the money goes to a vendor who owes you support, and open source procurement often has no such vendor. This guide walks the full lifecycle, then the licence, security and lock-in questions that decide whether the outcome is genuinely better.

Table of Contents

• What Is Open Source Procurement?
• Why Governments Choose Open Source Software
• How the Procurement Process Usually Works
• How open source procurement works in government, stage by stage
• 1. Identify the need and write the business case
• 2. Research the market and consider an open market approach
• 3. Choose a sourcing route
• 4. Model total cost of ownership over the whole life
• 5. Engage suppliers and publish tender documents
• 6. Evaluate responses and award the contract
• 7. Transition, manage and maintain
• Which Procurement Route May Apply?
• What Should Agencies Specify About the Software License?
• How Do Agencies Evaluate Security and Quality?
• How Does the Government Avoid Vendor Lock-In?
• What Happens After the Contract Is Awarded?
• Frequently Asked Questions
• Can governments buy open source software?
• Is open source software automatically cheaper for a government?
• Does open source mean the government owns the software?
• Can a government require a vendor to modify open source code?
• How do governments evaluate the security of open source software?
• What is the difference between open source procurement and hiring developers?
• What to Do First

What Is Open Source Procurement?

Open source procurement is the process a public body follows to decide whether to use, customise, commission or build software released under an open source licence, and how to fund the support that keeps it running.

One piece of disambiguation first, because the phrase gets used two ways. Buyer-side open source procurement is what this article covers: an agency obtaining software that is already open. Publisher-side open source is a different activity, where a government releases code it built under an open licence so anyone can reuse it. Both matter, and plenty of agencies end up doing both, but the purchasing lifecycle only applies to the first.

Buying open source is not the same as buying proprietary software with a discount. A proprietary deal is mostly a negotiation over licence terms, with support and upgrades bundled in. An open source deal is mostly a negotiation over who does what: who patches it, who monitors releases, who fixes a broken integration, and what happens when the key developer retires.

It also shifts obligations onto the agency. A commercial licence usually includes indemnities and a support commitment. An open source licence, OSI Approved or otherwise, grants rights and imposes conditions instead: you may use, modify and redistribute the code, and you must meet attribution and licence obligations when you do.

So the question an open source tender has to answer is not “how much is the licence”. It is “what does it cost to run this responsibly for ten years, and who is accountable for each part of that”.

Why Governments Choose Open Source Software

Public bodies keep coming back to open source for the same set of reasons, and they are mostly about control rather than cost.

Avoiding vendor lock-in. Once a proprietary platform runs citizen records, tax filings or a permit system, switching costs climb every year and the negotiating position gets weaker. Open source software does not remove switching costs, but it moves them from “you would have to rewrite the application” to “you would have to find and pay a team to migrate the data and reconfigure it”. That is a very different conversation.

Being able to read the code. Inspectable source code changes who is trusted. Auditors, regulators and security teams can check what a system actually does rather than relying on a supplier’s assurance. For software handling sensitive personal data, that is not a nice-to-have.

Interoperability and open standards. Open source is the most reliable supply of software that speaks documented, non-proprietary interfaces. An agency can integrate a records system with a payment system or a mapping service without both sides negotiating a private API under NDA.

Continuity. Multiple firms can support the same codebase, and a new supplier can step in. That is why the US federal government moved to an open-source-first posture in its 2016 policy, why the General Services Administration pushes open-source alternatives in its schedules, and why agencies such as the Centers for Medicare and Medicaid Services set up an open source program office to handle policy rather than leaving it to individual project teams.

Sovereignty and residency. Where data must stay in a jurisdiction, an agency can host and inspect the code itself rather than trusting that a foreign vendor’s datacentre meets the requirement. Open source is a necessary condition for that control, though not a sufficient one.

Not every project should be open source. Agencies building something with no other buyer, or code whose disclosure would undercut a legitimate operational or security requirement, sometimes have a perfectly good reason to keep it closed. Blanket open-by-default policies work better as a default with documented exceptions than as a rule with loopholes.

How the Procurement Process Usually Works

How open source procurement works in government, stage by stage

The lifecycle below is the generic shape most jurisdictions use. Stage names differ and thresholds vary, but the sequence is remarkably consistent across the US, UK, EU, Canada and Australia, because it follows the logic of a public buying decision rather than any one country’s statute.

1. Identify the need and write the business case

The agency defines the problem, not the product. A case for change sets out the service outcome, the current pain, and what success looks like in measurable terms. A business case that starts with “we need a specific platform” quietly forecloses the open source option, because the only way to satisfy it is to buy that platform.

2. Research the market and consider an open market approach

Before writing any tender, teams survey what already exists: established open source projects, commercial support providers for those projects, and proprietary products in the same space. Some jurisdictions treat this as an open market approach, where the agency publishes its intended outcome and lets suppliers propose the solution, rather than writing a specification around a product it has already chosen.

3. Choose a sourcing route

Buy off the shelf, customise an existing project, commission a vendor to build, or build in-house. This decision drives everything downstream, including the tender instrument and the evaluation criteria. Decide it here, not after bids arrive.

4. Model total cost of ownership over the whole life

Price the full life of the system, not year one. Whole-of-life costing is what turns the licence comparison into a real comparison, because it forces the staff, support contract, hosting, security scanning, upgrade work and exit costs onto the same page as the subscription fee.

5. Engage suppliers and publish tender documents

Issue the tender through whatever electronic system the jurisdiction uses, with requirements written to be technology-neutral. Bidder questions get published with answers so every bidder sees the same information. If the route is a pre-approved framework, the agency may simply call off against it instead of running a new tender.

6. Evaluate responses and award the contract

Assess bids against criteria published in advance: whole-of-life cost, technical fit, licence and security posture, support model, interoperability, and demonstrated exit planning. Award, then sign, then publish the decision and the reasons when the jurisdiction requires it.

7. Transition, manage and maintain

The service goes live against acceptance criteria, then enters contract management for the rest of its life: service levels, release monitoring, patches, upgrades, contribution decisions, renewal, and eventually migration or decommissioning. Most open source procurement quietly fails here, because the funding stops after go-live.

Illustrative whole-of-life figures, not quotes, for a 400-seat deployment over five years. Unit costs only, shown per seat per year so the shape of the comparison is visible:

Sourcing option	Licence cost per seat	Support and hosting	Staff and upgrade work	Exit cost, year five
Proprietary subscription	Highest, rising at renewal	Mostly bundled	Low, upgrades are vendor-led	High, migration or replacement
Open source plus commercial support contract	None	Annual support contract per deployment	Moderate, integration and upgrade effort	Low, code and data are portable
Open source plus funded maintenance in-house	None	Internal team, occasional specialist input	Highest, you carry the capability	Low, but the capability leaves with the staff
Commissioned open source build	None	Vendor contract for a period	Moderate, depends on the contract	Varies, depends on what you own

The pattern holds across most of these comparisons: the licence line disappears, the support and staff lines grow, and the year-five exit line drops sharply. What changes between projects is whether the agency has the staff to carry that shift.

Which Procurement Route May Apply?

Five routes cover almost all government software buying, and they differ by value, competition requirement and how much specification the agency writes.

Route	Typical use	What the agency publishes	Watch out for
Small purchase or direct purchase	Low-value items, single known product	Minimal paperwork, often a quote	Thresholds differ widely by country and by agency, so check the local rules before assuming a value qualifies
Competitive tender (request for tender)	Well-understood need, specification-first	A detailed specification and contract terms	A tight specification can quietly exclude open source if it names a product or a proprietary interface
Request for proposal	Outcome known, solution open	Requirements, evaluation criteria, output-based terms	Harder to compare bids fairly; the criteria must still be published in advance
Framework agreement or consortium	Recurring needs across many agencies	Framework terms once, then call-offs	Requires cross-agreement agreement, which slows the first purchase down
Open source specific or marketplace route	Publishing or reusing open code, or buying through a curated catalogue	Contribution and reuse terms rather than a bid	This is the publisher side of open source; it does not remove the need for procurement when you are buying

Two rules are worth stating plainly, because they are where most mistakes start. Licence fees cannot be the reason a solution fails evaluation, and requirements cannot name a product unless the need genuinely only that product can meet. Both rules exist to keep competition open, and both are routinely breached by accident in documents written in a hurry.

Co-procurement is worth a mention. Several agencies or municipalities can pool demand, agree common requirements and share the cost of running a tender, which is how small jurisdictions get access to serious technical evaluation. Foundations such as the Foundation for Public Code support exactly this kind of shared procurement, and it is a practical answer to “we cannot afford to evaluate this properly on our own”.

What Should Agencies Specify About the Software License?

Licence terms belong in the tender documents, not in a negotiation after award. By the time an agency is discussing obligations, the obligations are already fixed by the licence the vendor chose.

Cover at least these points: which licence each component is offered under, and whether it is an OSI Approved licence; what happens to third-party components with different or conflicting terms; attribution and notice obligations; whether the agency may modify and redistribute; who owns modifications the agency pays for, and whether those modifications are contributed upstream; how source code access, escrow or audit rights are handled; what vulnerability disclosure and patch timelines the supplier commits to; and how updates are handled when a component reaches end of life or its licence changes.

A copy-ready clause block, adapted to your jurisdiction’s drafting rules:

Technology neutrality. Solutions will be assessed on functional capability, whole-of-life cost and quality, not on the licensing model or brand of the components supplied. Licence fees will not be applied as a pass or fail criterion.

Software bill of materials. The supplier will provide a machine-readable software bill of materials covering all first-party and third-party components, with a defined format and an update on each release that changes a component.

Rights to use and modify. The supplier warrants that the deliverable may be used, modified and maintained by the agency and its service providers for the contract term and for as long as the agency operates the service.

Source code access. Source code for all customisations will be placed in the agency’s control at no additional charge, in a documented repository, with documentation sufficient for a competent team to build and deploy.

Portability and exit. Data will be exportable in documented, open, non-proprietary formats, and the supplier will support migration to any replacement supplier at cost.

The software bill of materials clause has moved from nice-to-have to expected in a lot of jurisdictions. Once an agency requires a machine-readable list of every component, it can scan those components, track their licences automatically and answer a vulnerability question in minutes instead of weeks.

How Do Agencies Evaluate Security and Quality?

Evaluate each product on its own merits, which is what most national open source policies actually instruct. Do not treat openness as either a security guarantee or a security objection.

Openness does change the disclosure model. Popular open source code is read by thousands of independent researchers, so serious flaws are often found and disclosed in public, quickly and with wide impact. Heartbleed and Log4Shell are the two examples that changed agency practice, because both showed the same code running in millions of systems. The realistic reading is neither “open code is safe” nor “open code is a security liability”: vulnerabilities get found, and the question is who is responsible for patching once they do.

In practice, agencies score security and quality on a set of concrete things: whether independent review of the code is possible and has happened; how vulnerabilities are tracked and how fast security releases land; whether the project has active maintainers with more than one person able to merge code; whether documentation covers deployment, upgrade and troubleshooting; accessibility conformance if the service serves the public; how personal data is handled, where it is stored and who can reach it; where the software runs, in the agency’s cloud, a vendor’s cloud, or on-premise; whether a support arrangement with a service level actually exists; whether it integrates through documented interfaces; and the whole-of-life cost.

The maintainership question deserves more weight than it usually gets. A project with one dominant contributor is a staffing risk, not just a community-health risk. Where a service is critical, an agency should ask for a continuity arrangement that does not depend on one person staying employed somewhere.

How Does the Government Avoid Vendor Lock-In?

Lock-in is not avoided by using open source. It is avoided by the contract terms around it.

Five levers do most of the work. First, open standards and documented interfaces, so integrations can be rebuilt or replaced. Second, exportable data in open, documented formats, with export tested before signature rather than assumed. Third, source or escrow access for customisations, so the agency is never dependent on one firm’s goodwill to fix a defect. Fourth, a transition plan written at award, with dates, costs and responsibilities, so migration is a known work item and not an argument in year eight. Fifth, clear ownership of public-sector customisations, ideally with those changes contributed upstream so that every future upgrade benefits from them.

That last point is where open source contracts often go wrong. An agency funds a local vendor to build a bespoke module, the code sits in a private fork, and two years later neither upstream nor the vendor will accept an upgrade patch. Funding upstream contribution instead of a private fork is cheaper and keeps the exit door open.

What Happens After the Contract Is Awarded?

Contract administration is where most of the risk sits, and where open source procurement most often underperforms. Award is the easy part. Somebody still has to watch release notes, apply patches on a schedule, upgrade dependencies, keep the documentation current, and decide every year whether the support contract is still worth renewing.

Set the acceptance criteria before go-live and test against them. Define what the service level agreement covers, including response times for defects and for security patches, since those are usually different commitments. Record what was accepted, which version, and which components, because that record is what makes the next upgrade or an exit cheap.

Assign an owner. Open source projects publish on a rhythm, and nobody notices a release nobody reads. The maintenance budget has to be a recurring line with a named person attached, not a one-off project cost, and this is where the capital-to-operating shift bites: the money for a proprietary subscription is capital expenditure in many accounting frameworks, while the staff and support that replace it are operating expenditure, and a budget that only funds the first one cannot buy open source properly.

Then decide how the upstream project gets funded. This is the part most procurement frameworks were never built for. Four mechanisms work:

Mechanism	How the money moves	Procurement friction	Trade-off
Donation or sponsorship	Small amounts, often discretionary budget, direct to a project	High, and awkward to audit	Good faith, poor accountability
Support or SLA contract	Agency buys a defined support commitment from a supplier	Low, this is standard procurement	Needs a real entity and a purchasable service on the other side
Sponsored feature development	Agency contracts a named developer to build a specific change	Moderate, scoped as a deliverable	Direct money to a clear outcome, and usually upstream
Public fund	A pooled public fund, such as a sovereign technology fund, funds maintenance across projects	Low at the agency level, high at fund level	Adds a layer, but spreads cost across many users

The mechanism that keeps coming up in practice is the third one. A Canadian public service organisation needed a specific improvement in an open source project, and the route that worked was contracting a developer to contribute that improvement, with the change pushed upstream rather than held in a private branch. The money buys a deliverable, which is something a procurement framework already knows how to handle.

The obstruction is worth naming too. Individual maintainers often decline public money because a single large state sponsor looks like pressure to build backdoors, or like an audit waiting to happen. Terence Eden, formerly of the UK Government, described being asked to find a way to pay for all the open source software the government was using as a surprisingly hard problem. The mitigations are structural: many sponsors rather than one, contributions written into the contract, and published payment terms so everyone can see who pays for what.

Before go-live, answer the question nobody asks until year five: who owns and maintains this if the current team and vendor both leave. Write it down. That single sentence prevents most of the bad endings.

Frequently Asked Questions

What to Do First

Start with the business case, not the product. If the need is written as an outcome, you keep the open source option open through every later stage; if it is written as a specification for a named tool, the procurement decision has already been made before anyone has looked at the market.

Then do the unglamorous part early: name the person who will maintain this in year three, and confirm the budget line that pays them. That single question filters most of the bad open source projects, and it is the one most often skipped.