Keeping an ‘open’ mind
Open source, open standards, open support… for the digital teams tasked with deploying e-government services, the first obstacle is understanding the rhetoric. Government policy now advocates digital projects be “open by default” but there remains confusion over what constitutes open and whether projects that don’t toe the line will get the green light.
There are numerous options open to digital teams that aren’t pure play open source. For example, there are commercial off-the-shelf (COTS) solutions that use open standards. These adhere to standards that ensure interoperability of software and hardware. Such products offer support for open standards such as .NET, Java, XQuery etc add-ons, again ensuring interoperability with the flexibility to swap modules in and out.
So why is the “open by default” policy in place? Open source is a great foundation stone for building digital services upon and the mandate will ensure that government services can be modified or enhanced and reused, making them cost effective. It’s one of the main tenets of the Digital Service Standard under the old Government Digital Strategy which states that “all new source code should be open”; a concept that was reinforced in the revised Technology Code of Practice released back in August, which states that government projects must “make things open” and “interoperable”. Ultimately, it gives these departments full control over the project but that also equates to full responsibility.
To help drive adoption, the Government Digital Service (GDS) recently appointed its own champion to the cause in the form of Anna Shipman. As Open Source Lead, she aims to make “more government code open, improving the reusability of the open code we already have”. Open standards-based code is just “coded in the open”, she says, advocating that “extra steps could be taken” to go pure open source… I am not sure I totally agree on this point. Open source code is not always the most cost effective or productive solution for the job in the short or the long term. Resource, in terms of time, budget and skills, is scarce and therefore to go pure open source is often unfeasible.
For large organisations with internal development communities on tap with strong project management and deep pockets, open source development is an option. There’s no vendor lock-in, the service can be customised to fit bespoke requirements, (although we mustn’t forget there will be an on-going workstream needed to maintain this code).
Where open source falls down is in less experienced hands. Projects can snowball requiring an army of developers and technical support. Vendors may use the lure of open source licences but involve services effort that then generate 80 percent of life-time costs. Or the department becomes heavily reliant upon third party developers who, familiar with the quirks of the code, then need to be retained. The notion of a community of developers continually improving the code also does not hold true, except for mainstream open source products like Linux. Individual organisations will still need to pick up costs and effort associated with maintenance and improvement of their own projects.
For those with limited resources, a COTS (commercial off the shelf) solution may be the better way, providing faster deployment, less risk, controlled costs and easier maintenance. If the vendor supports open standards even better, as interoperability with third party systems and data sharing is then possible. But COTS is of course not without its drawbacks. There’s the dreaded vendor lock-in; and some COTS products have an inability to customise with code; and sharing is often limited due to strict licensing agreements.
A compromise between the two is possible in the form of low-code solutions. Low-code uses a commercial operating layer upon which to build, manage and control services and can also integrate with open source extensions. Because it doesn’t require the designers to be proficient at coding, it enables rapid creation, collaborative design and development. The internal team retains ownership of the services created and can easily reconfigure, repurpose and share these, giving them autonomy over the solution without the ruinous long term support costs of bespoke coded solutions.
In short, there are pluses and minuses to both open source and COTS approaches. Low code offers a good compromise but ultimately the right solution will be determined by the resources, budget and requirements of the project itself. Advocating open source irrespective of the needs of the team will see projects fail and costs escalate as a reliance upon vendors is replaced by a reliance upon developers. The Technology Code of Practice states that “equal consideration must be given to free or open source software when you choose technology” and that cuts both ways. We need to be able to choose the technology to fit the task, with priority given to interoperability and future transformation.
I hope this was useful!
