I almost couln't believe it: The solution had been right in front of me for years. So many days of client work in frustration as to why content management had to be so complicated. But now it was clear! In fact, I felt bad for not seeing it earlier as to how obvious it was...
But let's step back for a moment and look at what happened.
The idea for Commitspark stems from several freelance projects where I worked on integrating existing Content Management Systems into the technical architecture and workflows present at my clients. And with content I mean text-like content, i.e. copy text, headlines, page slugs, SEO text, and so forth (but not images, videos, product data, ...).
But as simple as managing text content many sound in theory, in practice it becomes very complex, primarily due to a single design choice made by all major CMSs available today.
To understand what I'm talking about, let's look at what the implications would be in the software development world, if we were to apply the CMS way of working to software development:
Assume we have a software project with 500 code files. Let's also assume a developer will typically change multiple files for each new feature built. As we typically have many more than just one developer, it means many of our files are constantly changing. So let's say one developer has finished a feature.
Working like in the CMS world, a developer would now have to individually publish each file modified during development into production. But forget one file and most of our application will be broken. Same if we publish the wrong file. Also, how do we handle files our developer changed but that already contain changes from other developers? Do we remove their work? Do we wait until they are also finished with their changes, over time causing everyone to wait for everyone else?
Propose this way of working to any sane software developer today and they would consider you out of your mind. So it appears there exists a much better approach in software code compared to the way content editors work on content today.
Now, to get back to my frustration with Content Management Systems, given my a background in software development, it really bugged me how content had to be published entry by entry. But I couldn't pinpoint how to do it better until I realized that content publication processes are almost identical to code publication processes in software development. In other words: Let's consider treating content as code.
Why? In the end, we have the same steps to follow: Writing new or changing existing code/content, iterating over those additions and changes until the desired quality is met, getting approval, and finally merging/publishing everything into some form of production environment.
So given that software developers appear to have a much more powerful approach at their disposal, wouldn't it make sense to apply this to content management as well?
This is where Git comes into play. Conceived by Linus Torvalds (of Linux fame), Git enables solving the workflow issues of multiple people working on a software project so well, that it has become the de-facto standard in software development today. In fact, as a developer I have been using Git for so many years that I don't even think about working with other comparable tools anymore.
One of the main factors of Git's success is the ability to let developers very easily compartmentalize related code changes into branches so that work in each branch can be completed independently. Once a branch is ready, the changes in it can then be merged (applied) to the trunk, i.e. main branch.
This means all the issues with forgetting to publish some changes, of conflicts with unrelated work and generally of everything happening at the same time in a single place, can be drastically reduced by treating Content as Code and building on Git.
With Commitspark, I took this notion of Content as Code to reality, taking into account the insights of several challenging client projects. As such, Commitspark makes establishing content management workflows that are extremely hard or impossible to achieve with existing CMS systems easily achievable.
The benefit: Faster time to publish, more consistent quality, less coordination overhead, and overall a much less stressful experience for everyone involved.
I will publish more articles outlining the concepts behind Commitspark and the possibilities it opens up over the coming weeks. As of today, the core of Commitspark is available Open Source, with a first release at https://github.com/commitspark/graphql-api.
Sign up for our newsletter.