Drupal 8 at Comic Relief

Over the last year a key objective for the Technology team at Comic Relief has been to build products not websites. Tech Lead, Peter Vanhee, explained in a previous blog post how we’re using Drupal 8 to create a reusable platform product for building campaign websites. Since then the team have been working to deliver another website using the platform codebase and also preparing to open-source the codebase.

We have now opened up this codebase – you can find it here.

Being open makes us better

We strongly believe that working in the open and contributing to the open-source community makes our products better and makes us stronger as a team. It helps us prioritise work more easily as we can be clear about what is and isn’t important to the product, it allows us to say “no” to one hit wonder feature requests and it makes us stricter about dealing with technical debt and ensuring we have appropriate detail in supporting documentation. It is also a fantastic and motivating feeling for the whole team to know that their work is open to others to see and contribute to, and we hope it will allow us to engage further with the thriving open source community and get some external help to expand our codebase further.

Many charities and not for profit organisations are not big enough to have the size of development team we are lucky to have. We feel strongly that we want to help smaller organisations when we can and one of our main motivations for making our platform product open was that other organisations can use it to build their websites. This has already proved successful with Comic Relief’s sister organisation, Red Nose Day USA, using our code to deliver their website in May, shaving months off the time it took to deliver.

Journey to open source

We had to overcome a few obstacles before we were able to open our codebase. These were mostly due to a lack of understanding about what open-source meant and what benefits it could bring to Comic Relief.

Some people asked why we would give away our hard work for free – our view is that we are already benefiting from using Drupal 8, which is open source software itself, so feel that we have a duty to contribute back. We also feel that we have additional, possibly unique, knowledge to add to the community based on our experience of delivering high profile campaign websites each year. We know that Drupal is a commonly chosen technology for other charities and we believe that reducing duplication of work in the sector is worthwhile and an example of how Comic Relief is able to support other charities in a way beyond purely financial.

There was understandable nervousness around security. There is of course a lot diligence required before making code public, including selecting the right license (we choose GNU GPL v2), managing secrets and ensuring that everyone is happy for feature conversations to be available for everyone to see. These considerations are not to be underestimated and take time to resolve. It is also something that needs constant review and should be built into ongoing working practises and team culture. For us, the discipline and professionalism required for working in the open is a significant benefit.

Also, there were a few questions about why we needed to open-source. This was particularly pertinent when it came to prioritising development work as the work required to get us ready to open-source sometimes meant that there was delay to new features being delivered. We combatted this by being clear about the benefits to Comic Relief – there are many, as mentioned above, but additionally we believe the quality of our work will increase with more people to spot bugs and help fix them, we will see an increase in efficiency and reduction in duplication and we will hopefully receive contributions from others that will improve our codebase even further.

Our advice if you’re wanting to open-source your code, or code in the open, is to engage the rest of your organisation early and listen to any reservations people may have. When confronted with internal reservations around going open source, it required us to have patience and perseverance in order to educate our stakeholders about the benefits and reassure them about their perceived risk. Be clear about what the benefits are to your organisation and highlight how the way you work will continue to support your open-source software appropriately. We also found it helpful to show examples of other organisations who have worked in the open such as the BBC, the Guardian and the Government Digital Service.

What is next

Our intention is to continue to open-source our code where we think it could be useful to others and to code in the open wherever possible. We have kick started a mindset shift so that at the start of each new project we try to be open, rather than closed, from the beginning. Live examples of this include developing the pattern lab (which we hope will be useful to partners) and the grants API (demonstrating that prototypes can be developed in the open).

We’re hoping to have discussions and feature requests coming in from other charities looking to adopt our technology and we’ll continue to add new components to the codebase and will be maintaining our workflow queues to organise new work and future iterations.

Finally, we’d love to see other charity websites being powered by our codebase, so please take a look at our open GitHub repositories here. We’d love to hear what you think and your experiences of moving towards open source, or working in the open.

Our journey to open source would not have been possible without the hard work of Peter Vanhee, Caroline Rennie, Andy Phipps, Heleen Mol, Adam Clark, Gustavo Liedke, Zach Bimson, Carlos Jimenez, Pradip Pack, Girish Nair and Zenon Hannick.

5 comments

  1. This looks like a really valuable way to approach the projects requirements! I’m interested, how big is your development team and how is it structured, roughly? i.e. the split between back-end, front-end, QA, PMs etc? Do you feel the teams size made this way of working easier or harder?

    Like

    1. Hi Mark, thanks for reading and commenting. We divide ourselves into “squads” and these small groups each work on a particular product/problem. A typical squad is usually 4-6 people and might include 1-3 developers, a designer, a product manager, delivery manager, we will also have various “friends of the squad” who might contribute occasionally but don’t need to be involved in everything. The development team is pretty evenly split between back end and front end developers. I think a smaller more focused group improves productivity and morale, and I prefer this as a way of working. Best, Clare

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s