Councils often solve the same digital problems in isolation.
One team improves a directory. Another builds a better news feature. A supplier creates a useful fix for consultations, events or service pages. Then, a few months later, another council pays to solve almost the same problem again.
Sharing code helps break that pattern. For councils with in-house developers, this means teams can build on existing work. For councils that rely on suppliers, it means commissioned work can create value beyond a single contract.
This is not a radical idea. The UK government’s Technology Code of Practice asks public sector teams to be open, use open source, and share and reuse technology. The GOV.UK Service Manual also says new source code should be made open and reusable unless there is a good reason not to.
Sharing code reduces duplicated work
Local government has many shared needs.
Residents need to find bin collection times, report problems, read service updates, book events, make payments, and understand available support.
Local details change, but the underlying digital patterns are often very similar.
When councils share code, one team’s solution can become a starting point for another. That does not mean every council has to use the same website in the same way. It means common problems do not have to be rebuilt from scratch every time.
This is especially useful when budgets are tight, and teams are stretched. A reusable component may not solve the whole problem, but it can save days or weeks of work.
Sharing code gives suppliers a better starting point
Code sharing is not only useful for councils with development teams.
Many councils work with external suppliers for design, development, support and hosting. Open code gives those suppliers a stronger foundation. They can spend less time rebuilding basic features and more time adapting services to a particular council's needs.
It also reduces supplier lock-in.
The GOV.UK Service Manual says code developed by a third party, such as a development agency, should be made publicly available where appropriate. That matters because work paid for with public money can then be reused, inspected and improved.
Suppliers can still compete. They compete on quality, accessibility, delivery, support and judgement. They do not need to compete by hiding useful code.
Sharing code improves quality
More people looking at code can mean better code.
A feature used by one council may only meet one set of needs. A feature tested by several councils is more likely to handle different content models, accessibility needs, editorial workflows and edge cases.
This is one of Drupal's strengths. Code hosted on Drupal.org is licensed so it can be downloaded, reused, modified and distributed under the GPL.
LocalGov Drupal builds on that model. Local Digital describes LocalGov Drupal as creating a shared pool of code, resources, research, and expertise for councils in the UK on the Drupal platform.
That shared pool matters. It means one organisation doesn't shape features alone. They are tested against real council needs, across different teams and suppliers.
Sharing code makes long-term maintenance easier
A council website is not finished when it launches.
Content changes. Drupal changes. Accessibility standards evolve. New service needs appear. Team members move on. Supplier contracts end.
Shared code makes maintenance easier because the knowledge is not locked away in one organisation. Release notes, issue queues, documentation and version history all help future teams understand what changed and why.
This is also where the LocalGov Drupal core team plays an important role.
The core team reduces risk by reviewing contributions, managing releases, encouraging shared standards, and keeping work aligned with the wider distribution.
Not every feature belongs in core. Some work is better kept as a separate module or local customisation. That judgement is important.
The core team also helps councils and suppliers avoid fragmentation. Without that role, shared code can become a box of spare parts. With active maintainers, it becomes a more reliable shared product.
Drupal.org also provides useful assurance. Stable releases for the LocalGov Drupal project are covered by Drupal’s security advisory policy.
The risks are real, but manageable
The main risks usually don't come from sharing code. They are normal software risks: poor maintenance, unclear ownership, weak testing, or accidental exposure of sensitive information.
These risks are also manageable.
Publishing code does not mean publishing passwords, API keys, personal data or private configuration. The GOV.UK Service Manual is clear that teams should review code before opening it and avoid exposing secrets.
Security issues also have established routes.
Drupal provides a private process for reporting security vulnerabilities, and its security team works with maintainers to create fixes and coordinate announcements.
That does not remove the need for care. Councils still need suppliers or internal teams who understand version control, testing, releases and patching. But the risk is often lower than maintaining closed, bespoke code that only one supplier understands.
The NCSC also points to version control, peer review and automated testing as tools that can help manage risk in modern development.
A practical step for every council
The simplest step is to ask one question at the start of each digital project:
Could another council reuse this work?
If the answer is yes, build that into the brief. Ask suppliers how they will contribute reusable work back. Ask where the code will live. Ask how it will be documented, reviewed and maintained.
Sharing code is not about giving work away for nothing. It is about making sure public money creates public value.
For council teams, that means less duplication, more resilience and better services. For residents, it means quieter improvements: pages that work better, forms that are easier to use, and digital services that are easier to maintain long after the project has launched.