Recently by David Guenette

The Gilbane Group’s new web-based survey for book publishing professionals has just gone live. This “Blueprint” survey is one of the research mechanisms for our upcoming study A Blueprint for Book Publishing Transformation: Seven Essential Processes to Re-Invent Publishing. The study will be published in June 2010, and all participants in this survey will have full access to the full-length study posted on The Gilbane Group website and through the websites of the sponsors of the report.

Please note: This survey is for high- and mid-level book publishing professionals. If this does not describe you, please do not take this survey.

TAKE SURVEY

This 10-minute survey seeks to gain detailed information about what is really happening among the full spectrum of book publishers related to ebook and digital publishing efforts, and will identify the "pain points" and barriers encountered by book publishers when it comes to their developing or expanding digital publishing programs.  Issues such as royalties, digital format choices, and distribution difficulties are addressed.

For more information about A Blueprint for Book Publishing Transformation: Seven Essential Processes to Re-Invent Publishing, or other activities of The Gilbane Group Content Technologies and Strategies practice, please email Bill Trippe.

The Gilbane Publishing Practice is diving deep into the transformation of publishing as more and more publishers realize that the digital domain can not be ignored.  Not that there aren’t plenty of publishers—especially in STM and other professional publishing efforts—already very active in digital publishing.  Still, trade publishing, for example, is seeing the very real opportunities in eBook markets, and we’re wrestling with what makes for best practices for them.

Not that anyone's strategy makes for a “one-size-fits-all” approach. There are some trade publishers that have started in on or already have well-established single repository XML-based content management systems, the benefits of which are tremendous not just for eBooks, but for content re-use, custom publishing, localization and translation, and even to varying extents, integration with other line of publishing business systems. In trade publishing, however, there are plenty of publishers that have diverse collections of editorial and production platforms—often the result of the long history of mergers and acquisitions in this industry—and the level of integration within these editorial and production systems is ad hoc, at best, never mind effective tie-ins with marketing or sales systems, or royalties, or rights, etc.  You know who you are.

So, what is the trade publisher supposed to do?  While the ideal solution might be to create content chunks rich with meta-data that feed workflows across not just departments like production, but in and out of all of the other business systems as needed, there is a lot of time and money that goes into such a set up. For trade publishers with publishing systems that work—and maybe it doesn’t really matter if it’s taken a lot of gum and baling wire—what really is needed to add eBooks to the mix?

Companies like Aptara and even newer comer Tizra, along with well-established composition and conversion services, will tell you that if you can output in PDF, they can make eBook for you. And depending on the vendor, the eBook production may be very inexpensive, or have very sophisticated features, or be ready to market and sell, or some combination. SaaS is becoming more common for such processes, so investment, too, is relatively painless. Let’s think of this class of eBook production as “tigers.”  This class of solutions offers impressively quick solutions and a good range of capabilities across a growing number of vendors, and represent a strong competitive argument.

XML-based repository digital asset and content management platforms, with their ability to embed rich metadata that may even enable actionable content to other publishing systems—including sales and distribution—stand as a class we can think of a “grizzly bears.”  There is no doubt that this class of digital publishing solutions is a competitive strategy choice itself. One example is Wave Corporation, another is Mark Logic.  Some solutions work better with publishing business-specific platforms (e.g., Klopotek, Firebrand, MEI).

Of course it may not be an either/or question.  Recent news from codeMantra, about partnering with Mark Logic, points to the combining of the tiger and the grizzly. A “tizzly,” anyone?

Keep an eye open for our efforts to answer such questions, and if you are a vendor in this space, please be sure to contact Bill Trippe or Ralph Marto about participating in our multi-client reports. To read more about our Gilbane Publishing Practice consulting services, click here.

Look into almost any publisher’s history, and if it has a good number of decades behind it, chances are very good that you’ll see that the publisher was its own printer. Houghton Mifflin Harcourt is but one example: it’s origin stems from the merger of publisher Ticknor & Fields and Riverside Press, an old Cambridge-based printer founded by Henry Oscar Houghton.

Today, of course, a lot of publishers typically use big printers such as Quebecor, RR Donnelley, or others. With the digital content streams getting under control among publishers of many stripes, together with the growing capability of production printing hardware and software, print on demand (POD) is already mainstream option. Witness Lightening Source.

A recently received press releaseannounced the planned acquisition of Océ, which provides high volume production printing platforms, by Canon, known for its consumer items like cameras and ink jet printers, but also for office equipment such as copiers and printers.

It turns out the Océ’s production printers are behind a good portion of the big POD services, and these machines are able to provide cost-effect alternatives to regular printing in many cases. As publishers seek to extract value out of backlists and custom books by digitizing the content and managing workflow, POD can enable them to produce runs too small for regular printing. But right-sized and right-cost POD can offer attractive margins when the digital content has been managed right.

It makes me wonder if publishers will take the POD in-house, given the relatively modest POD platform expenses, so that the publisher can capture a greater part of the margin on small press runs. Who knows? Maybe the separation of publishing and printing will turn out to have been a temporary anomaly.

With Kindle et al., it can be easy to get stuck on eBooks as the output, but with the right technologies addressed by the digital stream, what shouldn’t be overlooked is POD. PDQ, QED.

With the advent of Kindle, from Amazon, a second dedicated ebook reader device has made the news, not counting the press and high hypes of the many preceding, deceasing ebook device contenders. There is a lot to like about Kindle on the face of it: like the Sony reader, Kindle uses the very effective E-Ink display, and few argue that the display lacks sufficient print page fidelity. But, so what? If you want good black type on white, readable only when illuminated by lamp or sun, the book itself has proved a pretty good format.

But, of course, Kindle promises much more, including all the old bromides about ebooketry like storing many titles, interactive index capabilities, bookmarking, etc., but there are some new tricks in Kindle that may indeed spark new interest. The best one is that through cellphone data network connectivity, the user may order new titles anywhere and anytime the cell network works (which, admittedly, is a whole lot more where and when than Wi-Fi, unless one happens never to leave the office or home network, or lives in a Starbucks). Hats off to Amazon for this innovation. Other features include some sort of Web browsing, an online ebook ordering system that should be second nature to Amazon, and, kinda, MP3 playability. But many of the newest features Kindle offers are more disappointment than delivery, and these shortfalls have everything to do with one of the biggest conceptual problems of dedicated ebook readers in the real world: The additional device conundrum.

While readability is a key requirement for an ebook device (and the lack of which helps explains why PDAs have proved to be a poor ebook market factor), the human species has neither physically evolved more hands, nor has human culture fashioned more pockets. Like 99% of people, I have enough trouble making sure that I have my keys with me when they might be needed, and when you throw in the now essential cellphone, it can seem like half of each day is spent performing the mime of pocket swatting. (Thank god I long ago gave up smoking, and now no longer have to also pat myself down to see about matches or the pack.) People sherpa the minimum, and the idea of having a cell phone, and a PDA, and an MP3 player, and a laptop, and an ebook reader doesn’t require a lot of imagining to be seen as unattractive. And that’s before you figure than anyone hitting their forties also has to carry reading glasses, not to mention for some of any age inhalers or secure ID cards, and for many, breath mints, handkerchiefs, gloves or mittens, and the wallet or two. I’m sure that this is all good training if you’re going to be a combat grunt, but for daily living our current list of the things we carry is a burden.

That’s what drives me crazy about Kindle. It has a built-in cell phone, but there’s no option to use it for anything else other than ordering a book. It has the ICs and jacks for playing MP3 files, but no playlist management, nor—absurdly enough, considering that Amazon is set up to sell things like music—any iTunes-like music downloading. The critical assessment of the Web browsing capability of Kindle is not fully formed, but there’s already plenty of complaint about the Kindle’s shortcomings there. Even one of the strong features of Kindle—E-ink—comes with its own drawback; while promotional copy claims that it is just like reading a page, that also means that you can’t read without a light, so better add a booklight to your pack, even as you’re carrying an electrically powered “book.” And with Kindle’s fundamental lack of support of PDF files—without question the single most widespread format for ebooks—you have to wonder, “What were they thinking?!”

Yes, I’d love to have an ebook device with seamless book ordering. But gosh darn it, it better handle phone calls and calendars, text entry and music playlists, and a good enough Web browser before I’d consider it. Throw in a breath mints storage bin, and I’m sold.

With the advent of Kindle, from Amazon, a second dedicated ebook reader device has made the news, and there's a lot to like about Kindle on the face of it. But the old hobgoblin of too many dedicated devices still reigns.

That’s what drives me crazy about Kindle. It has a built-in cell phone, but there’s no option to use it for anything else other than ordering a book. It has the ICs and jacks for playing MP3 files, but no playlist management, nor—absurdly enough, considering that Amazon is set up to sell things like music—any iTunes-like music downloading. The critical assessment of the Web browsing capability of Kindle is not fully formed, but there’s already plenty of complaint about the Kindle’s shortcomings there. Even one of the strong features of Kindle—E-ink—comes with its own drawback; while promotional copy claims that it is just like reading a page, that also means that you can’t read without a light, so better add a booklight to your pack, even as you’re carrying an electrically powered “book.” And with Kindle’s fundamental lack of support of PDF files—without question the single most widespread format for ebooks—you have to wonder, “What were they thinking?!”

A fuller discussion can be found in our Publishing Practices Blog, in Ebook Readers, Unite!

Bill Trippe’s post on January 04, 2005, “ECM and Business Process Management,” and the discussion emerging from Bill Zoellick’s post on January 08, 2005, "Sarbanes-Oxley: Too Narrow?” (especially comment by Glen Secor) make me think about the issue of DRM transactional infrastructure. Glen Secor’s comment, especially, while framing the compliance issue more usefully in regard to effective implementation strategies, also helps highlight the significant challenge ahead for DRM (or, in Glen’s usage, ERM, for enterprise rights/[business]rules management).

When the scope of integration becomes as wide as Glen argues it must, it seems to me that the DRM infrastructure requires ubiquity. After all, what we’re talking about is governing content not just between and among departments within an enterprise, but also among partners, suppliers, regulators, and a dozen other categories of participant that aren’t necessarily easily anticipated. The good news is that the DRM approach to security, compliance, and business process integration of content is theoretically flexible and applicable—arguably the best single strategy to show up to date. The bad news may be that theory will move to practice only when a sufficient DRM transactional infrastructure emerges.

But what is a sufficient DRM infrastructure? At best it would be one or a number of trusted environments that provide ubiquitous business rule transaction management common to all participants, so that enterprises could concentrate on defining and associating the business rules needed with all types of content. Since DRM platforms must not only accept and manage rules associated with content, but handle financial transactions and regulatory demands (among other things), and since the advantages of electronic commerce brings with it fast-changing relationships and conditions, the best solution is to use a DRM system in which all others can and will participate.

There are reasons for hope, albeit, perhaps, not in regard to a quick-to-emerge DRM ubiquitous infrastructure. XML-based common meta-data structures provide portability and platform independence to a large degree, and there have been some early efforts toward defining DRM meta-data with XML (ContentGuard’s XrML being the best known, but hardly the only effort). In short, the general industry trend toward abstracting meta-data above platforms means that DRM in the enterprise already has some applicable structure. However, apart from some limited examples—Authentica and Adobe come to mind—there’s still not much in the way of DRM “editorial interfaces” (i.e., rules definition and association) for content management. Fortunately, there’s little barrier to the creation and improvement of such interfaces, and preferably within CM platforms themselves.

But the question remains: is widespread compliance, security, and business processes associated with content likely without a general infrastructure such as the “Trusted Environment” on the Intertrust model? There are plenty of small- and mid-sized companies that won’t be able to afford particular DRM solutions that are not generally addressable. There is a great amount of work left to do to bring DRM into the enterprise, and while some pieces of the puzzle are in place or on their way, I wonder if the lack of working generalized trust environments remains the missing necessary piece for all sorts of “content governance” implementations.