Commentary on policy
From OpenEGov
Response to the document:
Open Source Software - Use within UK Government Draft version 2 - Redraft responding to public consultation (March to June 2004) (see the documentation page for this document and the reply to the response below)
sent to Ian Watmore, head of the e-Government Unit on 2004-09-19
Summary:
Open Source Software (OSS) has merits specifically and widely applicable to public sector service provision. It seems that consultation on the policy regarding OSS adoption has been conducted without due regard to Cabinet Office guidelines.
Further the consultation appears to have been conducted as though OSS were only a technical issue and so has omitted a range of Cabinet Office, Treasury and OGC considerations.
There are wider issues relating to transparency and fairness in the delivery of public services that need to be brought in to the debate.
The document uses the subheading 'response to public consultation'. However, not only is the document itself not available to the public, but the consultation was carried out only with a subset of those organisations which had been involved with the discussions leading to the previous (2002) version of the document; a subset which omitted those bodies representing free software developers, who only discovered the existence of the consultation by chance. Of course this conflicts with both letter and spirit of the Code of Practice on Consultation, which begins with the words 'Consult widely.. ' and goes on to clarify that
'it is important to identify proactively relevant interested parties and those whom the policy will be likely to affect' (criteria 1, 1.3).
In this case the interested parties were already known from the previous exercise, but omitted in spite of this
The purely procedural aspects of the consultation are not the only ones which seem to have been poorly organised. The absence of any sign of an RIA (Regulatory Impact Assessment, (criterion 6)) would seem to be a serious oversight. While the policy proposed in the draft is non-legislative and limited to the public sector, it is made very clear in the Cabinet Office Guide to Regulatory Impact Assessment both that an RIA should be carried out for
'all proposals (legislative and non-legislative) which are likely to have a direct or indirect impact (whether benefit or cost) on business, charities or the voluntary sector' (1.6)
and that 'any published proposal or set of options' with such impact should be 'accompanied by an RIA even if your recommended option is not regulatory' (1.3).
The policy clearly does have an impact on business (the pool of companies providing free software solutions does not coincide with the pool providing proprietary solutions, so there is also a redistributional impact). It has an impact on charities, which are already tending to use free software solutions and may benefit from a wider range of free software encouraged by a more enthusiastic government takeup; and it has a similar impact on the voluntary sector - with the added factor that a large part of free software development actually takes place within the voluntary sector. It also has an impact on other areas of society: for example, will the UK have a sufficient pool of free software experts to stay competitive in a future software market which has become more service oriented? This type of issue is completely bypassed in the draft policy. The formal need for an RIA seems hard to argue against. Yet version 1 of the draft had no accompanying RIA; version 2, presumably moving closer to a finalised policy, still has none.
The lack of an RIA is particularly important in this case given the emphasis within the RIA guidelines on the importance of non-financial issues such as equity and fairness. Many of the key issues in the free software/closed source debate concern such issues, and omitting them to concentrate only on Value for Money seriously risks distorting the idea behind Value for Money itself, which is not intended to be a purely financial criterion.
This aspect was emphasized in the Office of Government Commerce's Open Source Software- Guidance on implementing UK Government Policy, which says that
'value for money is defined as 'the optimum combination of whole-life cost and quality (or fitness for purpose) to meet the users requirement'. This is not synonymous with lowest price.'
The relative weight of fitness for purpose will vary case by case; there are some cases where the fact that software is open source is essential to a particular use. For example:
- Given the requirements of the Open Government Code and the Freedom of Information Act, citizens may have the right to know how a particular tax or benefit has been calculated. Closed-source code may make this impossible (for example, if the originating company has ceased trading), or at the least more costly.
- Given the emphasis around the world on a transition to electronic vote counting, political parties will need the right to inspect any software used in the process
- Software used for classified purposes must be known not to have back-doors or communicate secretly with third parts. The problem of ascertaining this with closed-source software has been tacitly admitted by some proprietary software companies, which provide a limited open-source version of their code for governments
There are many other cases where open source software may not be essential, but has a strong advantage in fitness for purpose by its nature. Software used for long-term record storage, for example: if the data is to be accessed in future, then proprietary formats used by closed source applications are clearly not suitable, given the relatively short life of many IT companies. Standard formats in conjunction with closed source software may be some improvement - but there is a long history of minor 'tweaks' to such standards making data in practice hard to access with anything other than the original software. Only open source software gives a full guarantee that the data will be accessible in the future.
The list above is clearly only suggestive â but a more exhaustive discussion, whether as part of an RIA or a fuller public consultation, would have been likely to raise many more considerations; which is exactly the issue here. At their most general these considerations centre on issues of citizens' rights, fairness, transparency and the creation of public goods as a benefit to the whole of society.
As the Green Book says,
'wider social and environmental costs and benefits also need to be brought into any assessment. They will often be more difficult to assess but are often important and should not be ignored simply because they cannot eaily be costed' (Green Book, 5.12).
Considerations such as those above need to be explicitly brought into any policy recommendations concerning value for money; leaving them implicit will in practice lead to them being ignored â unless each organisation implementing the policy is to rediscover the findings of the original consultation. This tendency has already led to highly visible problems such as those involved with the negotiations in Newham; it is hard to imagine that that won't simply be repeated without more explicit guidance.
A discussion of wider social costs and benefits is an essential part of any serious consultation on the use of free software. I would therefore call on the e-government unit to abandon this flawed consultation and begin from scratch with a consultation which follows the government codes of practice in allowing wide participation, in including an impact assessment, and in taking non-price issues into serious consideration. We believe that were such a consultation to take place, a very different set of policy conclusions might be arrived at, and we would strongly urge that the 'next steps' proposed in the draft document are not taken without such a consultation. The public interest element in R & D software is clearly large and complex and deserves full and public discussion.
Signed
Graham Seaman (IT Consultant, Libretech Ltd; member of the free software associations AFFS and Hipatia, but writing as an individual)
