Buying software on its merits: neutrality, preferences and mandates

Government software policy can set a rule for comparing products, express a preference for a licensing model, or require that model. These approaches differ in what they leave to the purchasing authority. A preference can still allow a comparison between alternatives; a mandate can restrict the eligible alternatives before that comparison begins. The Center for Strategic and International Studies survey records examples of both, alongside advisory policies and research and development activities. Its classifications describe the actions reported, rather than a judgment about which approach was preferable.

Policy type and policy outcome

The survey separates the action from its status. Mandatory, preference, advisory, and research and development appear as action labels; approved, proposed, and failed appear as status labels. An approved advisory policy does not mean that every agency adopted open-source software. A proposed mandatory bill does not mean its restrictions became law. Reading the action and status together keeps a statement of intent distinct from a requirement that took effect.

The examples below show how those distinctions worked in the survey. The entries retain its dates, labels and outcomes. The details also show why the label alone cannot explain a procurement rule: an open-source preference might still require a cost comparison, while guidance might explicitly call for consideration of proprietary alternatives.

The reasons recorded for different approaches

The survey reported that Argentina's public IT institutions promoted open-source use for lower costs, local employment and security. Its Cambodian entries described reducing dependence on proprietary systems and developing local skills as policy goals. These were the governments' stated reasons. They do not establish that every open-source product produces those results, or that a preference achieves them in every setting.

The case for neutrality appeared in entries that treated the development model as one part of the comparison. CSIS reported that Canada's policy did not distinguish between software development models. It also described an Australian government document that placed fitness for purpose and value for money at the center of purchasing decisions. On that account, eligibility for consideration and the outcome of a particular purchase were separate questions.

Both kinds of policy therefore addressed public objectives beyond the label attached to a product. Preference policies placed weight on goals such as skills, access or reduced dependence. Neutrality policies emphasized comparing alternatives against the business requirement. Their different rules concerned how those objectives entered the decision, rather than removing cost, security or capability from the discussion.

Price, cost and the service required

Public purchasing includes the design of a tender, the selection of a supplier and the management of delivery. Wikipedia’s public-procurement overview describes competition and the way specifications shape participation. For software, the lowest purchase price and the most suitable service are different concepts. A price is a cost item; the purchasing requirement describes the work the system is expected to perform. That distinction helps explain the policy emphasis on value for money.

Wikipedia’s explanation of total cost of ownership describes a financial estimate covering direct and indirect costs over a product's life. Its software examples include installation, integration, license compliance, migration, training, downtime, security, upgrades and decommissioning. It also states that the estimate does not, by itself, measure fitness with an organization's strategic goals. A cost comparison and a capability assessment answer related but different questions.

Wikipedia’s account of vendor lock-in defines dependence in terms of substantial switching costs. Existing data formats, compatible systems and established working practices can affect a move to another solution. Source-code access, the cost of operating a system, and the ability to leave a supplier are consequently distinct parts of a comparison. None follows automatically from the initial license fee.

The UK example

The UK's October 2004 guidance was recorded by the CSIS survey as advisory and approved, describing a value-based comparison without an open-source preference. The March 2009 entry in the same survey was classified as preference and approved; that policy considered both licensing models, lifetime costs and a preference for open source when overall costs did not differ significantly. The later entry illustrates how comparative evaluation and a conditional preference could appear in the same policy.

GOV.UK’s technology guidance calls for equal consideration of open-source software and asks about user needs, support, training, maintenance, security, scalability and licensing. It also includes exit and transition costs. These are assessment factors stated by the guidance, rather than a conclusion that a licensing model always offers the best value.

The procurement rules page places these comparisons within purchasing procedures. The world policy survey shows how governments used different action types, while the document-formats page explains the relationship between stored records and future software choices.