Recent talk about e-book readers and format interoperability (or lack thereof) got me thinking anew about the segmented nature of content management solutions. It’s axiomatic that content distribution is migrating to a multi-platform model, but the tools available to make it work remain pretty specialized.
A moment of clarification: there ARE vendors who sell content management solutions, and some of them may tell you their products DO work end-to-end. I’ll reserve judgment there and say, yeah, but … Can you distribute my content seamlessly? Do you work with any other vendor I pick? Can you also support my web site and blog? How about content archiving?
And… I’ll stop there. My point is: this stuff should be interoperable, and it isn’t. And I’ll go one step further: it’s mostly our own fault.
Of course, part of the problem starts with a moving target. Systems written today came off drawing boards that were barely web 1.0. Perhaps the rapid rise of social media could have been anticipated, but it still takes time to conceive, write and deliver credible tools.
But I think the bigger problems are evident not in planning but implementation. It is a rare publisher who is willing to adjust to make best use of an off-the-shelf content management product. We want bells, whistles, optional bells and whistles, plus the ability to customize down to the user level. And then we’d like vendors to rewrite some essential code. This call for flexibility drives complexity, which drives cost, which demands scale… and how many publishers can truly say they are “big” enough to warrant special consideration?
In a recent blog post, Kassia Krozser underscored the larger risk book publishers take by insisting that they continue to play in their own sandboxes. In her view, making it hard for companies like Apple to do business with us doesn’t make Apple better; it makes Apple think the publishing market is too small and too idiosyncratic to pursue profitably.
For companies looking to place big bets on promising future opportunities, publishing offers moderate scale, slower growth and a reputation as a finicky customer base. Layer in the longer lead times required to develop tools, a fragmented value chain, and a convoluted review and approval process all too familiar to those of us who work in publishing, and you may think it’s a wonder any vendors market in this space.
One of the “aha” moments in our StartWithXML project came in the form of a diagram, two nested shapes that showed visually how XML can be a tool to help publishers migrate from process complexity, which costs time and money (and adds little value, in my view) to content agility. Multiple formats and multiple uses aren’t coming; they are here. The tools required to support content agility may be supplied by others, but making good use of those tools depends on changes that publishers need to start making first, and now.
