Jane Roberts strategy director at Toplevel and asks whether more clarity is needed to stop departments from tying themselves in knots over what kind of ‘open’ to use.
How do you define open for government? Photo credit: Flickr, MIKI Yoshihito
Open standards and open source are widely advocated in digital government. Open is seen as the antithesis to the closed proprietary offerings and licensing tie-ins that were associated with commercial IT deployments during the last decade.
But is this too black and white?
One could argue that public sector organisations are now ignoring viable solutions because the tide has turned and the message from Whitehall is vendors are villains.
So could the government’s endorsement of open be backfiring, forcing departments to invest in bespoke solutions that are complex to manage, integrate and iteratively upgrade?
To start with, it’s worth pinning down what these terms mean. Open source software is computer software whose source code – the part that programmers and developers can manipulate to change how something works – is freely available for modification or enhancement by anyone.
In contrast, open standards are IT and digital industry-recognised principles concerned with how to develop and agree standards and specifications to ensure that interoperability exists between any software or hardware product, and that those systems are compatible with each other.
Crucially then, open standards can be used by commercial vendors, and there are lots of examples of this, a prime one being Microsoft’s .NET, which provides a lot of support for open web standards such as XML and SOAP.
The Government Digital Service is a firm advocate of open standards, as they support flexibility and change, have a sustainable cost, and enable suppliers to compete on a level playing field.
“Whether they are designed and built in-house, outsourced, or commercial off-the-shelf (COTS), government bodies must require solutions that comply with open standards,” reads GDS guidance.
COTS describes software or hardware products that are ready-made and commonly available, and are designed to be implemented easily. This idea is that this saves the high cost and effort of bespoke development. Examples include Microsoft Office, Sage Accounts and SAP.
It’s clear that GDS itself recognises that open standards do not equate to open source – but that message is not necessarily filtering down, and many government departments are confused over whether they can use a COTS solution.
Runaway budgets and technical risk
Open standards are a great foundation for digital solutions. However, open source can see one task-master (the vendor) substituted for another (the developer).
Open source solutions might benefit from customisable code and a collaborative developer community that helps deal with issues such as software bugs, but they also require in-depth programming knowledge.
In reality, you can end up swapping vendor lock-in for third party developers who know the software.
Projects can explode in size, resulting in involvement from an army of developers, content designers, user-interface designers, business analysts, quality-assurance testers and user researchers. This ends up creating a massive technical team, potentially leading to longer development cycles and runaway budget spend.
In contrast, open standards COTS solutions reduce technical risk.
Interoperability with third-party systems and data sharing is easier to achieve and solutions are battle-hardened in the market, as the code is not open for hackers to exploit.
Platforms often have existing pre-built modules, allowing for simple service deployment and expansion, making it easier for non-coders to manage these solutions.
But the downside is that there can still be support contracts and licensing terms involved. That said, because open standards have been used, the organisation is not locked in and can more easily switch supplier.
A third way
Both open source and COTS have their merits. For those with larger budgets, a strong resource base, and unique requirements with access to large or pan- government internal developer communities, an open source development approach makes sense.
Meanwhile, for those with tighter budgets or limited access to developers and project management experience of software development cycles, a COTS approach can give fixed development costs and provide future development and support.
But there is a third option.
Low code or hybrid solutions are COTS products that utilise open source elements. This involves an out-of-the-box solution that can then be tweaked and coded or customised with open source extensions that can be bolted on.
Modules can be changed or added, providing the organisation with the flexibility and investment protection of open source and the reduced development effort associated with COTS.
Confusion slows progress
Open source and COTS are both great options for digital projects as long as they are open standards-based and provide modular flexibility. They both have their strengths depending on the organisation’s resources, project management experience and budget.
But out in the marketplace, we routinely find that government organisations are struggling to interpret these terms and the relevance of each approach to their own projects.
In some instances, concern over what is or is not an accepted approach is creating confusion and slowing down progress, which is the antithesis of the aims of the digital agenda.
Thankfully inroads are being made.
At the local government level there’s the Local Government Digital Service Standard (LGDSS). Based on the Digital by Default guidelines, this aims to provide guidance to councils and advocates open standards with the sharing of source code and service design where possible.
There’s also the recent supplier standard for digital and technology service providers, which unites the expectations of government buyers and suppliers by determining the key principles for any digital government project.
This very clearly states that services are to be built on open standards, signalling a less strident approach to solutions and freeing government departments to determine the best solution for them.
This move away from a prescriptive selection model by the GDS is a welcome decision, and ultimately shows that digital government design as a process is maturing.
This can only be good news for us all – but more work still needs to be done to reduce the confusion that is stopping departments from getting the best out of their digital services.