Paul Hammant's Blog: GitHub as a CMS to end CMSes
Exec Summary
GitHub can be used as a site serving tool. It is actually a pretty usable CMS even for non-technical folks. With some more tweaks it could be a killer platform for content with all the wonderful potential from forking and pull requests, thereby changing the industry even more than it has done.
Context
My annual ThoughtWorks '360 review' turned up that everyone loves me, but a subset of those penning opinion/feedback about me say I'm not great at our social responsibility values. They're not saying I'm ignorant of them, it's just that I don't spend a lot of time pushing things in that space (Open Source being 'free' is not a social benefit; at least not for the bits and pieces I get involved with). Its true of course, so I thought I'd remedy it a little in a way that leverages my skills.
Hosting a site in GitHub
This is not new of course as it has been possible with 'Github Pages' for a while. Jekyll is the technology that glues a few others together to make it work for GitHub. They have a 'sites' page that shows many sites, but 95% of those are news/blog centric.
On GitHub I (as my alter-ego 'content-experiment') made a pure site to hold the content of the first few years of Rabbie Burn's poetry.
Source on GitHub: http://github.com/content-experiment/content-experiment.github.com
GitHub Auto-generated site: http://content-experiment.github.com/
The source is markdown, and there's a simple (albeit a little dirty) layout/decorator being applied to make it a site feel.
There's nothing particularly revolutionary about what was done to that moment, as everyone knows GitHub can host the source for a site, and automatically redeploy it as changes are pushed.
Forking the site, and auto-publishing that too
As myself (user paul-hammant) I forked the same repository in GitHub. I did this in the web interface of course.
Then to simulate a less technical user I chose to initiate the editing of the front-page using the 'Edit this file' button inside the github interface:
I then edited the file (added a link at the bottom, explained wikipedia reference a little better), and committed with a suitable message from within the web page:
I committed that and GitHub deployed that too. The URL is different, but that's a good thing as 'paul-hammant' may have different views on what is correct for a Rabbie Burns poem site to 'content-experiment'.
Source on GitHub for the fork: http://github.com/paul-hammant/content-experiment.github.com
GitHub Auto-generated site: https://paul-hammant.github.io/content-experiment.github.com/
The change that I made: http://github.com/paul-hammant/content-experiment.github.com/commit/a8577fbfedf1c521f5810e94846da3e2ca1ecde8
The important thing at this stage is that I made all these changes as if I were an non-technical end-user who cannot do SCM operations on the command line or in a GUI.
Within GitHub's existing workflow there is a means to get content back to the original repo via 'pull requests'. That too would be easy for a the non-technical end-user to do.
Keeping the fork up to date with changes in the original.
If you have made a fork, it is relatively easy to keep up with the original's changes. GitHub has a "fork-queue" facility that allows you to work through the changes made 'upstream'. Here is a screen shot of a work-flow where I was applying a couple of upstream changes. I've yet to hit the "update branch" button to complete the workflow:
Well nearly complete; The automatic regeneration of the site does not
kick in :-(
Given the folks at Githib can read my mind, I expect it is fixed
already.
Where would this be used?
For Social good?
Well there's little social benefit for the publishing of the poems of a dead Scotsman.
The same technology choices could be well suited for groups that are distributed, and under some pressure to not participate in the content. Say for example the citizen uprising in Egypt (January this year) where individuals might have been blocked from the internet for long periods of time. A GitHub repo/site for the content could very effectively be pushed around the streets on USB flash drives. More importantly content (as commits) could also be brought back to the GitHub repo by USB thumb drives in the pockets of couriers.
Similarly the aftermath of hurricanes, earthquakes and other disasters affecting communication, could benefit from flash-drive sharing of websites (up and down-stream).
Even more amazingly for social benefit, the same content could be published multiple times on real domain names. Over a period of time content on each would converge as merge work is done (by technical folks). Content could also diverge (think wikipedia versus conservapedia). Ot maybe alternately diverge then converge - it's all good.
Granted for the editing of content without the comforts of an available GitHub, means learning Git's command line workflow. Similarly, while viewing content is possible without a web-server it is going to be better offline with Jekyl etc locally installed.
There I have made my first payment to the social gods of ThoughtWorks.
For the lovers of corporate content?
This works too for anything where a company might have used a CMS for. Why? Well there's a natural workflow built into this tool-chain. And its workflow that differentiates CMSs from wikis. What is alluring (but presently incomplete) is the simplification of an entire genus of commercial tool. Even wiki's stand to be better for use of Git(hub) as a backing store. No more proprietary data stores or obscure table shapes. No more second class history of files in the user interface. Even merge through rename (the new high bar of SCMs) is perfectly usable here.
What do the GitHub folks have to do to make this better?
- Merge/pull changes from upstream could also be a web-operation. Right now it's for devs on the command line only. Phase one would be a web button to perform merges where there are no clashes. Phase two would be a mediation UI for clashes (I realize that's hard).
- Some controls in web pages (maybe just Javascript) that would make it obvious that the content being perused is a fork of something else. Similarly, that other forks exist. Though I can't see conservapedia linking back to a page in wikipedia (assuming there is at least one that was not started completely from scratch), I can see more friendly groups racing towards mutual goals over time. The control could be as simple as a drop down that the decorator developer would put in the template to facilitate the end user jumping to the same page in a different fork.
- Rename and delete as operations via the web-interface
- Links from the web-interface to the gh-pages version of the same page (for the same fork).
- A preview button so the user can see an approximation of the markdown (or textile, etc) processed content, before hitting commit.
- Allow private GitHub repos to publish private gh-pages content. Corporations will probably fine-tuned visibility setting, if only for non-live experiments and approvals workflows.
What could I have done that would make this more convincing?
- Use Real domain names for the sites, e.g. rabbiespoetry.com. That's as simple as a CNAME file in Git and some name-server work for the domain in question. Even the repo that was forked could opt to map it's published content to a different domain name. Git hub have concisely documented how to do this.
- Demonstrated some more complex edits, renames or merge scenarios.
- Had a wiki-style 'edit this page' link in the published version - added by the decorator.
- Had some demonstration of non-text content being published. Either media files (yeesh they hurt source control) or structured things like GPS data and JSON bits & pieces.
I'm returning to an obsession of course
Those that have been reading my blog for a while, know that I previously had a DAV-based wiki that saved to Subversion (and leveraged Sitemesh as a decorator) and used a fat editor like KompoZer (I'm editing this page in KompoZer)
What can Git/hub affect next ? I'm thinking that even a Reddit threaded conversation system could be git-backed. At least on the small scale. It's painfully clear that the majority of the online forums that have threaded conversations have terrible interfaces. The utility that Git and GitHub provide could surely revolutionize (or servicify) those too.
Git and GitHub is changing everything - wake up folks!
Updates
Aug 22nd, 2011 - Update: Another GitHub user, Fil Rezo, has forked the Robert Burns repo into another another and added images & tags. Take a look.
Dec 5th, 2012 - Update: GitHub allow file creation via their web interface. See their blog entry. It does not trigger a rebuild of the GitHub Pages site though :-(
Jan 2nd, 2013 - I did a follow on article: GitHub Pages as a CMS again.
Nov 1st, 2014 - Link to Development Seed article promoting Jekyll instead of Drupal