Equalising code and content

The journey to Gin (part 2)

Back in February of 2017, several months after my near-catastrophic error, I attended a Hacks/Hackers event in London. That evening I heard Matt Kiser, the founder of WTFJHT, speaking about the creation of his site, the tools and services he uses, and how he made the collaborative aspect of the site work. In the process, he inadvertently vindicated an idea that had been tumbling around in my mind for some time: code and content can (and maybe should) share the same workflow.

A repurposed workflow

Matt explained that WTFJHT is built using Jekyll, a static site generator. All the content is in text files that are formatted in Markdown and parsed by Jekyll; there is no database. All the files are in a public GitHub repository that anyone can fork and modify in order to contribute to the site. Changes are submitted via pull-requests, meaning they must be reviewed before they are applied and deployed. This is a familiar process for developers, but here it's being used as an editorial workflow.


As I've worked in a couple of large publishers, I've had the opportunity to observe both development and editorial workflows. The similarities are pretty clear to me.

People are usually working on different parts of the product, so an individual team member's work usually won't have an impact on another. But even when there is overlap, regular updates and communication among team members can mitigate any major conflicts. Finally, it might also be the case—depending on the team and structure—that a senior member is responsible for some form of quality control before work is published/deployed.

The above is fairly typical. Yet, in practice, there are fundamental differences between development and content teams when it comes to the specifics of how the workflow manifests, and this is almost certainly down to the tools that they have available.

Traditional tools

Speak to pretty much any developer, even the least experienced, and they've almost certainly heard of version control. I've never come across a developer that doesn't know what a VCS is (although I'm sure there's one out there somewhere, just as there are those who flat out refuse to adopt any form of version control. Yes, they exist too). In contrast, I've found that the typical content creator has a very limited—if any—idea of version control. At best, they have a concept of history or versions, as found in software like Microsoft Word or Wordpress.

Also common among content creators are the various approaches to saving backups of work: creating new copies of a file with a new name, copying files to date/time directories, or saving copies in services like Google Drive and Dropbox. There are more, I'm sure. While these aren't terrible ways to protect your work, they're far from the best. A developer would be laughed at and/or scorned if he or she was doing any of the above instead of using a proper version control system, yet, in content teams, it's the norm.


It's not difficult to understand why the average content creator has no idea about version control. In development it's standard practice to use a VCS of some kind: it protects both the temporal and monetary investment, as developers (and, therefore, their work) can be very expensive. Imagine all that hard work was suddenly erased because somebody accidentally deleted the wrong directory...

But what about the value of the content and those who write it? It should be plain as day. Websites and applications alike are dependent, to varying degrees, on their content, not just code. Blog posts, marketing material, documentation, and general information all play vital roles, and yet the content often lacks the same level of protection as code. This is partly because there is no encouragement or instruction to use proper versioning tools, which may itself be a result of ignorance. Another part of it, I think, is that the content is undervalued, possibly because the content creators are too.

Out of control

Of course, the role of content varies, depending on where and how it's being used, and that affects its value. But isn't this also true of code? Yet, even the most trivial feature, plugin, addon or script is likely to be placed under version control by any reasonable developer. Often one of the first thoughts for a developer when creating a new codebase: create a repository, get it under version control. In the world of content creation, however, version control is, at best, an afterthought and, at worst, it's relegated to oblivion by ignorance. Naturally, the risk doesn't become apparent until things go wrong.


Of course, things had already gone wrong for Oh My Word!, many months ago. Hearing Matt's talk and learning about WTFJHT made me realise why I hadn't put Ghost or any other CMS back in place so that content creation could continue: I wanted a better way of protecting the content, beyond simply making backups. I was looking for a CMS with fully integrated version control. Once I realised what I was looking for, I tried to find one. Unfortunately, I couldn't find a CMS that had the level of integration I was after. Naturally, the challenge of creating a CMS with version control at its core was appealing, so I decided to build it.