Phil Rumens writes a thoughtful piece on the use of open source software in local government:

When open-source is discussed in the public sector, it is usually framed around transparency and reuse. The code behind products and tools built with public money is made open so that others can develop, adapt, and reuse it, and GDS recently published new guidance on this.

He makes a really good point about the breakout open source success of recent times – LocalGovDrupal:

Two factors are likely to have contributed to its success. First, Drupal itself is a mature product, originally released in 2001 and now on its eleventh major version, released in 2024, with older versions still supported. Second, it benefits from a large and active global community, with over a million members contributing to, maintaining, and supporting the platform.

It strikes me that this is where open source can have a much quicker impact, by taking existing projects that are proven to work at scale, and creating the themes, plugins or whatever is needed to make them fit the local government context – as opposed to starting from scratch.

That will necessarily mean focusing on software that supports ‘horizontal’ service areas that are common to organisations no matter what their sector, rather than specific verticals like housing, social care, or – dare I say it – planning. But there’s plenty to be getting on with in areas like ERP (ERPNext), CRM (SuiteCRM), workflow (Camunda) or document management (Alfresco). Or why not go all in and replace M365 stuff with Nextcloud?

How would this work? LocalGovDrupal offers the model:

• Form a club of councils to agree what modifications need to be developed.
• Pay into a fund (and hopefully attract some external funding).
• Find helpful, friendly agencies who know the software to develop the necessary code for plugins, modules and whatever else is needed.
• Encourage those agencies to create a market to support this software as it gets taken up across the sector.
• Keep up a sector-agreed roadmap of improvements and maintenance work too keep the software fit for purpose.

There are savings here, but also improvements in user satisfaction and – I think potentially most impactful – reduced support overheads. It might help to create the headspace to start thinking about tackling those pesky vertical, service-specific applications.