Is coding in the open right for your organisation?

One of the design principles that underpinned the digital renaissance in UK government was — and still is — ‘Make things open: it makes things better’.

For this article, I’ve focused specifically on the ‘coding in the open’ part. I’ll cover how it benefits public sector organisations, and how — in the right circumstances — it can yield a strategic advantage to commercial organisations also.

Acting on principle

In UK government, this openness is intended to manifest in a few different ways:

by being transparent about the performance of a product or service;
by opening the source code for others inside and outside government to inspect and reuse freely; and
by using and contributing to open standards, rather than reinventing the wheel.

These guiding principles are part of the Service Standard, which is used to assess the services the public accesses primarily online and through other non-digital means also.

Reusable, open source components

Not everything that digital teams across government create necessarily lends itself to reuse; some services understandably meet very specific needs. But when a team solved a more generic problem, other teams could take advantage also.

One example I remember from my time at the Ministry of Justice was a rather elegant way to calculate a duty roster for defence solicitors with differing constraints on their availability. The open code repository meant other teams could reuse it for other services with a people rota.

Platform capabilities

Other components were intended for reuse to address common needs across government from the outset. With all the government departments and agencies essentially federated, it was all too common for each team in each organisation to reinvent the wheel over and over. Making teams aware of available, easy-to-implement solutions to common problems helped them to save time and effort, crucially saving taxpayers’ money, and leaving them to concentrate on the more specific problems they were trying to solve with their service.

One of the earliest examples was the design system. With so much user research and testing into the ease of use, understanding and accessibility of the visual components for the GOV.UK site, it made perfect sense for the Government Digital Service (GDS) to make the design system as easy to reuse as possible. By making it a no-brainer for other teams to implement (instead of rolling their own inferior versions), it created its own gravitational pull and the benefit was multiplied. Later reusable service components included accepting payments and sending notifications to people through different channels (SMS, email, post).

Reuse by other national governments

It wasn’t just about straight reuse from a central source, though. Other teams from outside of GDS (even from outside of UK government entirely, although rarely) would contribute improvements back to the code base. If you’re familiar with open source software, many of the same advantages of having many sets of eyes on the design and code translated across. The digital community working across UK government remains sizeable.

Admittedly, much of the code created by digital teams in UK government is not directly useful to individuals, other open source projects or commercial organisations. Other governments however did see the immediate benefit of remixing the principles, designs and code for their own burgeoning digital services. The digital services for the US, Australia and New Zealand were quick off the mark to reuse and adapt GDS’s work, later Canada, Germany, Peru and others. While each has progressed down its own evolutionary track, the similarities remain evident.

Avoiding vendor lock-in

It’s not just about being civic minded or public spirited. One of the many challenges faced by government is vendor lock-in. Vendor lock-in is expensive.

Once a commercial vendor has sold in their proprietary enterprise software, particularly when it’s been highly customised, it’s incredibly hard to update or change without having to pay the vendor vast amounts of cash. (It’s as if the vendor planned it that way.) There are plenty of these ‘big IT’ projects lingering across central and local government in the UK, few going well and many not at all, underlining how difficult it is to escape their legacy even after more than a decade of government departments having access to in-house digital teams.

Not all proprietary software can be avoided. It’s unrealistic to expect a small digital team to be able to deliver a complex accounting and procurement system from scratch. But in situations where viable alternatives already exist or can be created from scratch, creating open source software in-house will almost always work out cheaper and quicker in the long run — even if it has to be retired and replaced wholesale by a new in-house iteration after a few years.

Beyond the direct costs involved, subsequently renegotiating vendor contracts can also be a lengthy, drawn-out and expensive affair. A relatively amicable contract discussion with Oracle to open up API access to a database instance used by UK prisons still took a couple of years to conclude, forcing the digital team to work around the lack of programmatic access to the prisoner records at extra cost and delay.

Encouraging better practices

Security concerns are a frequent counter to opening your code, a common argument being it would make it easier for bad actors to exploit otherwise hidden vulnerabilities. ‘Security through obscurity’ is not an effective approach. The likelihood is that a suitably determined individual would use a decompiler to find the vulnerabilities even without access to the source code.

“If you look at all the bugs in closed source products, the people that find the bugs don’t have the source, they have IDA Pro [a software disassembly tool], it’s out there and it’s going to work on open and closed source binaries — get over it.”
— Dr. Ian Levy, Technical Director, NCSC, in an interview with ZDNet in 2013

Instead, think about the effect opening your code might have on your development culture. As CTO of Kooth Anna Shipman wrote while still at GDS, “When other people can see your work, you tend to raise your game.”

This is not to insinuate that all closed-source developers are chucking out shonky code. Hopefully we can all relate to the urge to give things we’re proud of that extra bit of polish when we know they’ll be seen by others. It’s that little nudge we sometimes need ~~to get dressed while working from home~~.

What can commercial organisations learn from this?

Clearly government and for-profit organisations do not operate in the same way. They have different financial responsibilities and goals. Companies can be understandably concerned about opening up their intellectual property to the market — and competitors — or giving away something of value that they could sell. So why bother, then?

Attracting developer talent

A common advantage cited is that open source helps to attract developer talent because they can see the quality and style of code, and the products the organisation is working on. This may be a handy side-effect of choosing to code in the open, but I suspect it’s not sufficient commercial reason by itself.

Inner sourcing

There is a halfway house, an option for organisations concerned about opening up their intellectual property to all. ‘InnerSource’ applies the same principles and mindset of an open source software project, but within the confines of the organisation. Some then take it further by fully opening the projects at a later date.

This approach limits both the downsides and the benefits. While there remains scope for component reuse, doing so will be of greater benefit to organisations with larger development teams working on many products in parallel. The same is true for the benefits of building a developer community around the code. However, some of the cultural nudges towards better practices may be less effective if the audience is restricted to peers within the same organisation.

Platform lock-in as a strategic play

Wardley map of a hypothetical TV media industry. Open sourcing the production systems would have the net effect of commoditising the creative studios (Credit: Simon Wardley CC-BY-SA 3.0)

Given the earlier comments about vendor lock-in, it’s ironic that platform lock-in is one of the more compelling reasons for companies to open-source a product. Simon Wardley describes an example of this kind of strategic gameplay, which he calls Fool’s mate.

(I’m going to apologise in advance for using Tesla as an example. My views don’t exactly align with those of Tesla’s CEO. Complaints to the usual address, thanks.)

Tesla charging at a Supercharger station (Photo by Dario on Unsplash)

As a recent example of this gameplay, take the moves by most electric vehicle (EV) manufacturers to standardise on the North American Charging Standard (NACS) in the US for the plugs used to connect the car to a charging point. NACS was originally Tesla’s design, and has various advantages over the existing options. Tesla open-sourced the design in late 2022. Within a year, most car manufacturers had declared they would adopt it.

Tesla, you may recall, has a US-wide network of ‘superchargers’. Most other EV manufacturers don’t want to invest in building their own charging network from scratch, and access to fast chargers tends to influence buyers’ decisions to purchase an EV. Moreover, most of the cost of accessing the charging point goes to the car owners, so manufacturers get what they want (more EV purchases) for the much lower cost of switching their vehicles to use NACS.

Thank you very much, says Tesla. Their open source move has driven (pun intended) a large and growing new market segment (non-Tesla EV owners) to their charging network, each paying a premium rate for charging that goes straight into Tesla’s pocket. Despite the design now being open to all, Tesla has the first-mover advantage of having an existing supercharger network for the time being and few competitors willing to invest in building a challenger. It could also funnel this extra cash into furthering their lead in this regard, although after firing the supercharger team, that doesn’t appear to be the current plan.

Given this unexpected twist, it’s difficult to tell whether this was an intentional play, nevertheless this is how it has played out. The game Tesla was actually playing was to make their existing estate of superchargers more profitable and to defend against a competing charging network rendering theirs irrelevant by strengthening usage of an alternative standard connector. And now that everyone has adopted the NACS standard, Tesla’s customers will likely gain access to any new non-Tesla charging stations built by its competitors. Tesla achieved all this by open-sourcing the connector. Time will tell whether it can capitalise on this gameplay.

Final thoughts

Should your organisation code in the open? As always, context matters most. As we’ve just explored, the choice of whether companies should open up a particular component, product or platform very much depends on the competitive market, and whether there is inertia (resistance to commoditisation) that can be exploited to achieve something more valuable.

For public sector organisations, there is a responsibility to the taxpayers funding their work to be open and transparent in how they are doing so. If this has the side-effect of improving the quality of what is delivered, so much the better.

A bit of increased scrutiny keeps us all a bit more honest. That’s no bad thing.

References and further reading

Guiding principles

‘Government Design Principles’, Government Digital Service

‘Service Standard’, Government Digital Service

Reusable components

Defence Solicitor Service Rota, Ministry of Justice Digital & Technology

GOV.UK Design system, Government Digital Service

GOV.UK Pay, Government Digital Service

GOV.UK Notify, Government Digital Service

GOV.UK Forms, Government Digital Service

GOV.UK One Login, Government Digital Service

Examples of other countries’ digital services

‘DigitalService4Germany: Entwickeln für den Staat’ [‘DigitalService4Germany: Developing for the State’] by Lina Rusch and Matthias Punz, Tagesspiegel (16 Sep 2020, retrieved 17 Sep 2024)

Vendor lock-in

Prison API, Ministry of Justice Digital & Technology

‘Making prison visits easier to book’ by Mike Bracken, Government Digital Service (8 Jul 2014, retrieved 17 Sep 2024)

‘£214m effort to modernize SAP ERP in UK govt systems marked Code Red’ by Lindsay Clark, The Register (27 Jul 2023, retrieved 17 Sep 2024)

Better practices

‘Security through obscurity’, Wikipedia (retrieved 17 Sep 2024)

‘Six open source security myths debunked – and eight real challenges to consider’ by Nick Heath, ZDNet (23 Apr 2013, retrieved 17 Sep 2024)

‘The benefits of coding in the open’ by Anna Shipman, Government Digital Service (4 Sep 2017, retrieved 17 Sep 2024)

‘Business Case For Contributing to Open Source’, Tobie Langel, freeCodeCamp Talks (26 Aug 2021)

‘Why we code in the open’ by Dave Rogers and Steve Marshall, Justice Digital (21 Feb 2017, retrieved 17 Sep 2024)

InnerSource

‘An introduction to innersource’, GitHub (retrieved 17 Sep 2024)

‘Creating an innersource culture at Booz Allen Hamilton’ by Ki Lee, Booz Allen Hamilton (23 May 2017, retrieved 17 Sep 2024)

Open source as strategic gameplay #

‘Get over it: Microsoft is a Linux and open source company these days’ by Steven J. Vaughan-Nichols, The Register (13 Jul 2022, retrieved 17 Sep 2024)

‘Fool’s mate in Business’ by Simon Wardley, Bits or pieces? (29 Nov 2014, retrieved 17 Sep 2024)

‘Open source as weapon’ by Simon Wardley, Bits or pieces? (6 Dec 2015, retrieved 17 Sep 2024)

‘Opening the North American Charging Standard’, Tesla (11 Nov 2022, retrieved 17 Sep 2024)

‘North America Charging Standard (NACS) Announcements’, Edison Energy (21 Jun 2024, retrieved 17 Sep 2024)

‘Tesla’s Supercharger Woes Are a Bad Omen for All EV Owners’, by Jackson Chen, Inverse (1 May 2024, retrieved 17 Sep 2024)

Is coding in the open right for your organisation?

In this article