Open Source by Any Other Name...

As I noted on Tuesday, the UK government has been pretty much a total disaster when it comes to using open source. Indeed, it has arguably been a total disaster when it comes to using computers of any kind, spending far more on this area than...


As I noted on Tuesday, the UK government has been pretty much a total disaster when it comes to using open source. Indeed, it has arguably been a total disaster when it comes to using computers of any kind, spending far more on this area than any comparable European government. Moreover, the stuff is almost always late, and rarely works properly.

Of course, I am not the first or last to notice that, and various groups have offered advice on how to fix this lamentable state of affairs. Here's the latest:

Despite spending around £16 billion per annum, Whitehall and Westminster often see IT as a necessary evil: a risk to be mitigated rather than an opportunity to be exploited.

Information technology should be a transformational force, a tool to enable government not only to improve public services but to dramatically improve the relationship between citizen and state.

System Error: fixing the flaws in government IT sets out the case for a new approach to IT in the public sector

Fab title, no?

I must declare an interest here: I was interviewed by one of the authors of the report, and spent some time talking about – you guessed it – the virtues of open source, and how it could be usefully applied to the government machine. So I was pleased to see the following in the full report (freely available online - .pdf):

The review of commodities options should also strongly consider where it might be possible to use open source alternatives. This is in line with the Government's current approach and similar moves towards open source are being adopted by other governments. Many open source offerings do not charge licence fees. For example Microsoft Office's most basic business package retails for over £200 per licence yet where government users do not require all of the more advanced functionality provided by this package, open source communities like OpenOffice could provide more basic word processing, spreadsheet, and presentation solutions with no license costs.

It should be noted that open source does not always mean ‘free' and some open source products have commercially run accreditation and support arrangements which are designed to meet many traditional concerns relating to security and maintenance support. However, open source is also fundamentally more compatible with an agile approach as innovative changes and additions to the source code can be made directly without having to go through a proprietary solution's owner or incur costly change requests.

Now, in a 100-page report, those two paragraphs might seem to be rather thin gruel, but actually I'm not too worried by this apparently perfunctory dismissal of open source and its virtues. Because it turns out that the entire report is essentially an espousal of precisely those virtues, albeit without fully admitting that fact.

To see this, consider the following explanation of the core ideas in the Executive Summary:

A totally new approach is needed that emphasises adaptability and flexibility while retaining the benefits of scale and collaboration across government. It is necessary to tackle two important aspects simultaneously – delivering government-wide efficiencies of scale and interoperability while facilitating rapid response and innovation at the front line. We describe these twin tracks as ‘platform' and ‘agile'. This report demonstrates that by implementing both of these elements, government could see cost and time savings while delivering a more effective and flexible service.

So the two key buzz-words of the report are "platform" and "agile". Let's explore those in turn.

The platform will focus on the basic IT items across government that encourage interoperability and increase value for money by sharing infrastructure and reducing duplication. There is no final, stable solution for what is inside or outside the platform as it needs to evolve with technology. However, there is currently a great deal of government IT run separately by departments, which should be included in the platform. We suggest the following changes should be made:

Commoditisation. IT should be purchased as commodity items across government and should include well established parts of IT infrastructure (e.g., non-specialist PCs, printers, low tier storage and standard servers) and basic versions of software (e.g., common desktop applications, human resources and finance packages).


Common standards. This is a complex area, but government should start by considering which standards are currently being used most widely across the public sector. Supplementing this, government can look to existing industry standards or those published by internationally recognised bodies. However, where suitable open standards exist (such as those produced by the World Wide Web Consortium) government should promote their use.

One of the reasons open source is so powerful – and so cheap – is because it commoditises previously complex and expensive technology. One of the ways it does that is through the use of open standards to facilitate interoperability. So the "platform" described above maps very easily on to the world of open source which is naturally commoditised and based on common – and open – standards.

So what about the "agile" bit? Here's what it says:

In general, agile projects follow four main principles: modularity; an iterative approach; responsiveness to change; and putting users at the core:

Modularity. Modularity involves splitting up complex problems and projects into smaller components and portions of functionality which can be prioritised. Each module should be capable of working both in a standalone fashion and in concert with other modules. This can reduce the time to delivery, enabling users to access the functionality of modules developed early, without necessarily having to wait until all of the original specification has been built. It can also make upgrades and changes easier as systems can be altered module by module or new modules can be added to the original design.

An iterative approach. An iterative and incremental approach acknowledges that the best solution and means of delivering it are not always known at the start. By trialling in short iterations, receiving feedback and learning from mistakes a much more successful system can evolve than if everything is planned and set in stone at the outset.

Responsiveness to change. Shorter iterations and regular reviews provide opportunities for changes to be made and priorities adjusted within an agile project. The solution is developed in line with a prioritised requirements list, with users and technical experts agreeing what they will focus on in the current iteration. Should the business needs change, or new technological solutions become apparent, the prioritisation of requirements on the list can be easily amended.

Putting users at the core. Agile projects ensure that users or business champions are embedded within the project team. This enables the business to provide continuous input and refinement, ensuring that what is delivered meets their needs. It also demands that business become closer to IT development than has sometimes been the case.

Again, this amounts to a ringing endorsement of the open source way, rephrased using terms like "agile" instead.

For example, "modularity" is why Linus was able to share the task of writing the Linux kernel in the first place, handing off big chunks – modules – to his lieutenants, who then coordinated the work by hundreds of hackers across the world.

Similarly, "iteration" and "responsiveness to change" are simply another way of expressing the "release early, release often" ethos that lies at the heart of open source. Because of the tight feedback loops in the community, this kind of iteration comes naturally, as does the "putting users at the core" mentioned in the last paragraph.

So, all-in-all, I'm delighted that far from being sidelined, the open source ethos actually suffuses the entire report, and forms the underpinning for its two central ideas. Whether that's because of my persuasive eloquence during the interview, or whether it's just a case of great minds thinking alike, I wouldn't like to say....

Coupled with the earlier statement from the Cabinet Office in support of truly open standards, discussed in my previous post, the pressure for widespread adoption of open source software by the UK government seems to be building inexorably. Let's hope that pressure is released before the entire government IT machine explodes.

Follow me @glynmoody on Twitter or

Find your next job with computerworld UK jobs