The publishing world is full of content management horror stories. Those who have survived Cthonic publishing monstrosities such as "The Legacy Java Platform", "Our Little Fork of Moveable Type" or "The In-house Academic Language Backend" will talk at length about their trials. With foxhole-flashback-sincerity, they will tell you about exasperating rendering times, byzantine patch systems, the quick accumulation of idiosyncratic work-arounds and frontpages laid out by matching up 50-some-odd numbers with headlines. That's not an exaggeration. We actually lay out our frontpage by creating new blog entries -- that represent headlines -- linking them to the appropriate entry and then picking from a drop down menu the number of the story slot we want this headline to go in. It's like watching Roger Penrose multiply with an abacus.
There are two explanations for this endemic of publishing paralysis. Either no one has made a good CMS yet -- perhaps putting words and pictures on pages is the limit of our engineering capacities -- or the CMS is a broken concept. As anyone who has used Wordpress can agree, the first suggestion is patently wrong. There are some wonderfully-made, rich and deep CMSes out there. Graham Ashton's Nesta is a minimalistic wonder. Wordpress has accumulated a huge feature set and can produce professional looking pages -- see Time's Lightbox blog -- almost as well as the bespoke systems the rest of us rely on. Drupal has lots of books written about it and its own conference and everything. Clearly there are good products out there.
Where is the disconnect? Nesta, Wordpess and Drupal produce great blogs. However, we are making new-media newspapers, next-gen magazines, and hyperlocal, pulse-finding micro streams. We can't save journalism without demanding more from our CMS. This is where the problem starts. The CMS has to be everything to everybody. Wordpress has to optimize for both the cat-picture faithful and the ring-bejewled, hair-fisted mogul. Moveable Type has to work whether you are running a lad mag or poetry journal. This is an impossible proposition. Even if some divine piece of code could satisfy every current publishing need, in months or weeks or days some new format minotaur would be born with sui generis demands.
Well, what about plugins? Beautiful plugins. A Noah's ark of taggers and flaggers. Sort by color, permalinks to permalinks, haiku urls! What more could you want? The problem is that the plugin paradigm is irredeemably flawed. Setting aside the fact that most popular CMSes have chosen their plugin language unwisely -- Moveable Type uses Perl. Drupal, Wordpress and Joomla use PHP. -- the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren't designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of programmers.
At TPM, we have spent four years pouring our time and talents into trying to square the circle that is getting Moveable Type to keep up with our mercurial needs. A few months ago we realized it was time to put away our protractors and find a new enterprise. This is what inspired the creation of the new publishing system that we are developing.
Instead of revolving around a monolithic central piece of software, we have adopted the paradigm of feature-as-app. Our frontpage: an app. Our slideshow: a different app. Article publishing: yet another app. You get the picture. At the heart is a simple and flexible API that digests manifold requests from the different applications. For example, Moveable Type is great at publishing entries and updating its database accordingly. Our new system will simply wrap the MT database in a cached layer and incorporate its content. Our new gallery app -- currently active on the site -- creates slideshows, writing its changes to central datastore as well. The frontpage maker reads from the API and is made aware of MT updates, galleries, and all other content that has passed through the system.
How does this solve the CMS problem? Isn't this just a metastisized not-invented-here-syndrome?
First, the core of our new system is its input-agnostic API. This makes it easy to drop in replacements for facets that have outlived their usefulness. One day, we may no longer want MT publishing our entries. All we have to do is write a wrapper for Tumblr, Wordpress, or some new backend and we are set. We don't have to worry about dependencies being broken. Because all requests go through Baroque, all requests are translated into generic requests. From the point of view of the other apps, nothing has changed.
Furthermore, we are not tied to any language or technology. Through the core of our system is written in Ruby, any language that can make a request to the API -- details on this to come in subsequent entries -- can talk to Baroque. Rather than design the system just for our needs, we are designing it to be used by future editors and developers who think every feature was misconceived. That's fine with us. Just drop in something new.
On Monday we launched the second component of this incipient media-death-star, our frontpage publisher - nee Baroque. To get an idea of how it works watch a quick demo we made. It's fast, formless and - best of all - built completely outside of our CMS. Currently, MT's publishing engine notifies Baroque to cache new entries but it would be trivial to plug any other data source in. Eventually, when the core API and datastore is complete, MT won't talk to Baroque directly at all. On this day, we will finally loose the shackles of the monolithic CMS model.
We realize that we have a lot left to accomplish. The core data exchange and API of our new publishing ecosystem is embryonic, at best. However, the strides we have made already assure us that we are on the right track. Furthermore, we hope that we can start a discussion -- or rather resume and stoke the fires of the already happening conversation -- about the future of publishing platforms. We are passionate at TPM about pushing this technology forward and would love for your comments. We look forward to writing more about this soon.