Multi-council Drupal code sharing: Discovery, Sprint 1 notes

Croydon, Brighton and Hove, Bracknell Forest, and Oxford City Councils have joined forces to understand how councils co-develop and share open-source website code on Drupal. Here’s everything we’ve posted so far.

What we’re thinking about

Discovery problem statement: “How might we help councils co-develop, share and maintain open-source code for their citizen-facing websites?”

The assumption we’re trying to prove is:

“if we make it easy for councils to first understand what open-source can offer, and then to offer a reliable code-base that they can use (either themselves or through suppliers) to develop their websites, that will enable them to make more informed investment decisions around their website tech”.

In order to test this hypothesis, we decided that we need to understand:

1. how councils in the UK have developed and are maintaining their websites
2. who makes the decisions around procurement and tech choices
3. what works well for them and what doesn’t
4. what assumptions councils make about open-source technology
5. how councils that might work together on this can take decisions and agree on a roadmap
6. what kind of licensing arrangements exist in the open-source world, and which of those might provide a way forward for us

The method of Discovery is based on doing primary research with councils to understand their needs, and also to conduct technical discovery into the codebase that Croydon and Brighton-Hove have at the moment. The latter is geared towards understanding common content types, provide clarity around architectural decisions, and around licensing and governance choices that open-source software necessitates.

What we’ve been doing

User research

We spoke to 9 councils in total in the first sprint, which has been very useful to answer some of these questions.

We know that our users (as in councils) have varying degrees of experience with open-source platforms, and especially with Drupal. That points to different user groups who are either currently on Drupal or on other systems.

The other difference we’ve come across is between:

1. those that are currently happy with the way their website is serving their users, and how the council is maintaining that product
2. those that have some sort of an issue with their website, either in that they are locked in proprietary systems that might be costly, inflexible and slow to react to change, or in that they are restrictive for councils to meet their users needs.

We also know that councils have an increasing understanding of open-source options, but more work is needed to firm up the offer around the stability and permanency of open-source products. This is essential to councils because their websites are one of the key pillars of service delivery on the local level.

Governance and licensing discovery

We are also looking at how councils might join in and out of a code-sharing arrangement, and what this means practically. We are investigating what options we have based on different open-source models, ranging from tightly-knit “clubs” to more loosely-coupled arrangements that rely on informal agreements between partners. 

We know from user research that councils need some sort of an agreement to take the collaboration forward, but this currently looks like a minimal MoU that we can experiment with. This aligns nicely with our intentions to keep governance to a minimum, but as much as required in an agile manner.

From a licensing point, we’ve had discussions around copyleft vs permissive licences. The main difference is if an open-source project is on a copyleft licence, its users cannot take that code and re-release it in a proprietary licence, whereas in permissive licenses that is possible. For Discovery and Alpha, we envisage this project to follow a private development model, where a public-sector body establishes an open-source repo, deposit their code and use that as a centralised development environment where others can join.

Technical discovery

The technical discovery in sprint 1 has focused on auditing the code and configuration that is in use on the existing council websites with a view to what work will be needed to allow other councils to adopt a shared code base. 

Brighton & Hove City Council developed their site in Drupal 8 before there were any discussions for  sharing code or configuration with other councils. Croydon Council have since adopted most of the same configuration and custom code for their site, extending and customising where needed. The code is largely well written and a reasonable content model has been established in both cases. 

However, it is clear from early analysis that significant development work will be required to ensure the content model and related custom code is fit for purpose for any new council to take and use as a foundation for a new website. 

Currently there are many relationships between content types, with heavy use of entity reference fields to establish relationships to other content types, taxonomies and paragraph components. This makes sense in each of the existing sites, but will make it hard for a new council to enable or disable certain content types without breaking dependencies. 

The new shareable product will need to provide a clear core content model and make appropriate and limited architectural decisions. This is likely to include a collection of content types and taxonomies that all councils are assumed to need. Additional optional features could include other content types and custom behaviours that can then be enabled if required. 

We will continue auditing the code and themes in sprint 2, but we can already see the following areas of focus for development in a potential alpha phase. 

• Define core content model
• Re-architect content types to remove dependencies
• Refactor custom code to: 
  • Follow new content model
  • Follow coding standards 
  • Remove dependencies 
  • Adopt consistent naming conventions
• Develop install profile
• Develop modular features with optional content types and functionality
• Develop a custom base theme with the right balance of assumption and flexibility 
• Write clear documentation
• Add automated tests

What’s next?

• We are aiming to speak to more councils to uncover mode needs. We are hoping to speak to councils that are unhappy with their current website setup (because of user needs, tech or contracts), and have not used an open-source option before. Another group we’re hoping to target is those that might just want to benefit from the codebase, without necessarily expecting to have a say in the decisions taken, i.e. smaller councils that will look to consume the output.
• We will continue with the code audit, content type audit and theme audit
• We will draft guidelines for best practices, coding standards and development workflows
• We will try to align possible models of governance with potential ways of getting different council product managers to work together and agree on priorities
• We will propose a licencing and development model and test with the current group