Coding in the open

We talk a lot about Open Source at GDS. GOV.UK is built on open source software and, to a degree, built as open source software. It’s a topic we care passionately about because it helps us maintain our focus on user needs by helping us to quickly test and iterate software and systems.

The software world has a rich and growing range of tools to build your own software on. From operating systems such as GNU/Linux, web servers such as Apache or nginx, databases like MySQL, Postgres or MongoDB, the tools are there so we don’t have to do it all ourselves.

The challenge is often in knowing which of those tools are right for the job you’re focussed on.

Solving problems with the right tools

By choosing open source we can quickly try the tools that seem right, test them out, and make a decision about whether this is the right solution and start using the software straight away. A good example of that is the Elasticsearch search engine that Rob wrote about a few months back. From what we were reading it seemed like it’d be simpler for us to work with than solr, and we were able to dive in and try it out without a lengthy pre-sales process or costly and complex licensing arrangements. Instead, we test, we decide, we get on with tailoring our choice to best serve the user needs we’re focussed on.

There are open source tools that cover most of what we’re doing. We can analyse which are going to fit together in the ways we want, and where we should write our own code to make sure we’re building the best product we can in a way we can maintain. One of my fellow GDS architects, Paul Downey, has often likened our approach to that advocated by JP Rangaswami in his “open source pyramid”:

For common problems use Opensource.
For rare problems use Buy.
For unique problems use Build.

Make things open: it makes things better

We’re also making our code available for others to use. We tend to talk about that as Coding In The Open rather than Open Source. Partly because we’re not currently in a position to build and support a community around that code, and partly because most of it’s so tailored to our system that we’re not sure how useful it will be to others right now. But rest assured, if you see something useful you can use it – it’s published under an MIT licence.

We don’t want to jump to conclusions about what people will want to use, but we’re eager to hear from other people who might have overlapping needs. Together we can work out which components would be good to extract and package up in a way that makes them easier to share.

There are, of course, a few pieces that were so clearly standalone components that we think they’d be great for others to use. In his first week with us Nick Stenning put together unicorn_herder to help us manage the unicorn application server that our ruby applications rely on. It’s one of a few examples you can find in our github account.