We’re a worker-owned agency that designs, builds and supports websites for organisations we believe in.

Sharing Drupal code between UK Councils

At Agile Collective we are excited to be working alongside DXW Digital with Croydon Council, Brighton & Hove City Council, Bracknell Forest Council and Oxford City Council on a discovery phase funded by the Ministry of Housing, Communities & Local Government (MHCLG) to explore how councils can share Drupal code for their public facing web publishing systems. One of the underlying principles of the project is to work in the open, so we get to talk about it as we go!

Take away

As a quick take away, it in increasingly clear that councils should try to develop code collaboratively and in the open for three main reasons:

  • Duty: Public sector organisations are funded by public money, through taxes. Therefore, arguably they have a duty to share anything that can be shared back with the public, ideally through appropriate open licencing. This is strongly promoted in the Local Digital Declaration and by the Government Digital Service.
  • Efficiency: UK councils (local government) have many overlapping requirements for web publishing, so there is huge potential value in collaborating rather than duplicating effort solving the same problems.
  • Provide better services: collaborating leads to sharing of knowledge and experience which in turn will allow councils to make better evidence based decisions and ultimately provide better user experience and better content to citizens.


A blog post by Will Callaghan about a year ago while working at Brighton & Hove Council generated further discussion on Twitter, which started to buid momentum around the concept of sharing code between councils. Since moving to Croydon Council there have been a number of updates on how Croydon Council is now sharing Drupal code with Brighton & Hove, Overcoming barriers to code sharing, and how the current iteration of the code sharing project is up and running. This post aims to build on those with new issues and thoughts that are coming out of the discovery work in progress. I encourage you to read those posts for more background. This post covers some of the motivations to share and work in the open as well as some of the potential obstacles that are emerging.

Motivations to share

Many councils use Drupal for publishing content to their users and guiding them towards online transactional services. Most councils tend to use a separate system for transactional forms, such as GOSS or FirmStep, but still use the web publishing platform to guide users through whether they need a particular service and the things they will need before starting the form filling process. So to be clear, we are currently focussing just on the publishing platform, not the transactional services with form interactions such as apply for things, pay for things or report on things.

GDS invested heavily in user research and user testing through which they developed evidence based design system ( Many councils have adopted aspects of the GDS design system rather than duplicating the research and decisions on styles, components and patterns. This has been made possible by GDS sharing their work openly, something that has almost certainly improved user experience and saved money.

The fact that most councils share common requirements for publishing information to citizens makes it fairly obvious that working together on some aspects of functionality will save time and money and result is better user experience for more people. For example, let’s look at the step by step navigation pattern that is recommended by GDS to present users with clear steps to getting where they need to be. This is useful for guidance when there are a number of checks that a user should consider before taking an action (such as starting to fill in a form to interact with a service).

This is a great example of functionality that does not come out-of-the-box with Drupal core. It could be achieved in a number of ways: book module, using a views block for the navigation of related nodes, or custom coding. With appropriate research, development and testing, a module could be developed to provide the appropriate functionality that follows the default design patterns suggested by the GOV.UK design system. This could then be shared between councils who need it, saving time and perhaps freeing up resources to work on other challenges.

It is worth noting at this point that it is possible to share code with it being fully open. A closed group of councils could share code between them and not publicise it or open source it. Personally, I think this would be missing a trick in a huge way, based on all the points covered below on the benefits of working in the open.

So councils have much to gain by sharing code with each other based solely on their similar functional requirements. Let's move on to looking at why to work in the open.

Motivations to work in the open

The benefits of working in the open have been documented and promoted by GDS (Government Digital Service) for a while, and are clearly summarised in the 2017 blog post

Let’s just reiterate the main points in that blog post.

  1. It encourages good practice.
  2. It makes collaboration easier.
  3. External users can help make it better.
  4. Others can learn from your work.
  5. It makes it easier to share standards.
  6. It improves transparency.
  7. It clarifies ownership.

These are all very good reasons for working in the open.

I would argue that it is also the right thing to do wherever possible.

The recent Local Digital Declaration further underlines the benefits of working in the open, recommending that all new solutions should follow the Technology Code of Practice which includes using open source and being open source. Many councils have signed up to the local digital declaration (, which should help to smooth the path to working in the open.

Potential obstacles

Overhead of updating legacy code

For councils that have developed a significant quantity of code without the intention of making it public, the prospect of sharing publicly might present a challenge. It could take a lot of developer resource to review all the existing code for coding standards, ensure the code is modular enough for re-use, naming conventions are generic etc. At a recent meetup, the concept of 'codeshame' was mooted as another potential factor, that you might not be confident with your architectural decisions or code that has been developed against a tight deadline.

Mitigations: This is one very good reason for developing in the open from the start, forcing the decision about naming conventions, coding standards and best practices at the start of the work rather than half way through. For councils with legacy code that might need to be refactored, this overhead will be very real for anything they want to share publicly, but the benefits of moving to working openly and collaborating are likely to make this worthwhile.

Perception of ‘freeloaders’

A council that has funded the development of code might have a sense of ownership over that code and feel resistant to just giving it away. Depending on the licence, a third party might be able to simply take that code and make use of it without contributing anything back.

Mitigations: This is a common perception that I believe to be born out of a proprietary mindset, one where you might want to commercialise your intellectual property, something that is unlikely for councils. The counter argument to this is that you don’t actually lose anything by giving the code away, you still have the code, but other people can gain. As an extension to this argument, for work that was funded with taxpayers money, why shouldn’t other people gain if they can? There is also a far greater potential for payback giving your code away, where other people can add value to your work or fix bugs or extend it in new and unforeseen ways.

Proprietary culture

Procurement departments within Councils are used to dealing with proprietary software licences, with a cost and an agreed warranty or service level agreement in the case of software as a service. Shifting to using an open source software with no inherent warranty or SLA might present an obstacle for traditional procurement rules. There is also the perception that anything that is free just can’t be any good.


The question as to what licence to publish shared code is an interesting one. GDS uses the MIT licence for all their original code. Drupal is published under the GPL. In many ways the GPL would seem to be a good fit, as it flows well from the upstream licensing. As part of the current discovery phase we are exploring different licensing options available to the LocalGov group and taking legal advice.


Assuming that the code is public and the work is in the open, with contributions from a growing number of councils, the question of governance is thrown into sharp focus.

  • What is required to be in the LocalGov group?
  • How do we manage the direction of development?
  • How do we collaborate to develop and maintain a product roadmap?
  • How are decisions made?

These are all really interesting unanswered questions that we are working through with the initial stakeholders and we hope to have a better sense of direction soon.


It is still early days, as we’re still in sprint 1 of the 3 sprint discovery phase. By the end of discovery, the team aims to deliver a report on the business case, the evidence gathered from user research and the recommendations on the technical, licencing and governance of the LocalGov Drupal project. So far we have interviewed 6 councils, started the auditing of the existing Drupal modules, configuration and themes developed by Brighton & Hove and Croydon councils and have started to explore the licensing and governance options.

We’ll post further updates here as we progress.

In the mean time, do please get in touch if you have suggestions, questions or general interest in public sector Drupal code sharing, or find me on Twitter at

Meet the Authors
Back to blog