Our thinking about “monopoly” may need to be recast in the Internet age. This is a complicated question to consider and we need to start gathering some good minds around it.

Network effects were noticed before there was an Internet. Both the phone company and the electric company were networks, and it became clear about a century ago that everything worked better for everybody if they WERE monopolies and everybody was hooked up to the same network, not competing ones. So phones and electricity became regulated monopolies, with prices and other behavior, including mandated service levels, controlled. Whether because of a changing ethos or because things became more complicated, or both, “competition” has been introduced in both spheres over the past two or three decades. With debatable results.

Amazon’s dominance — which is not a monopoly but which certainly looks like unassailable hegemony in the world of online bookselling — can be largely attributed to brilliant execution and maintaining a tight focus on serving the customer. But part of their success at eliminating meaningful competition for online book sales has to do with the nature of the Internet. Online likes one winner in many spaces because it serves the users better NOT to fragment aggregations. If Amazon’s reader reviews were spread over 1000 web sites, they wouldn’t be as useful to the consumers. And their recommendation engine thrives on data; fewer customers would mean less helpful recommendations for those customers remaining, and the concentration at Amazon means less useful recommendations come from all their retailing competitors. This is an edge that may not stay with the retailer forever, though, because the playing field for information about books is being leveled by social networking sites. That’s why Amazon is investing in them.

This tendency to concentration makes it urgent for publishers to get into niches and start trying to own them while they have legacy advantages. If the history of the Net so far is any guide, each information and interest niche will end up being owned by a very small number of players; often it will boil down to one. We seem to have been pretty fortunate with the dominant players (perhaps we should call them “monopoly threats”) that have emerged so far, among them: Amazon, Google, ebay, Craigslist, wikipedia, and a now-emerging Facebook. They’ve executed well and kept their eye on the stakeholders they serve. They, so far, have been more benign dominators than were Microsoft and AOL, two big winners on the previous go-round.

But government is going to have to start thinking through public policy toward what will be an increasing number of dominant players in many niches. “Breaking them up” will seldom be a sensible answer: they often became monopolies because of natural causes and effects and if they were broken up, they’d recreate themselves (as the phone companies have been doing.) But leaving things to the market when there is no market is just trusting to luck.

The futility — or self-defeating nature — of “breaking them up” is obvious if we consider the possibility that Facebook or LinkedIn develops a dominant or near-monopoly position. The success of both sites, and their value to their users, is directly related to the number of people using them.

So breaking up a monopoly or dominant position built on the competitive advantage of a robust database tied to network effects would damage the users. That’s certainly not the objective for society trying to control monopolies.

One possibility is that we should allow combinations of suppliers or users when they are faced with a monopoly. Another is that stakeholders should be identified and, somehow, through mediation or legislation, their legitimate interests should be defined and somehow protected. But we have enough understanding of the Net and network effects now to see that our legacy thinking about monopolies, how to live with them and how and whether to manage them, may need some reconsideration. And we need some people who are NOT lawyers or economists joining those who are in the conversation.

A recent mailing list discussion about this produced a wide range of opinions. On one extreme is the notion that all market dominance is bound to be exploited and the government’s inability or unwillingness to control Microsoft is held up to have allowed damaging predatory behavior (pointing, first of all, to the demise of Lotus and OS/2.) On the other side are those who say the market and the rapid changes fostered by technology are all the control we need. That side too, can point to Microsoft and its current challenges as proof that no government hand is needed, even in the Internet age.

Certainly, one can see the possibility that Google will be challenged by vertical search (and just plain vertical sites) and that Amazon’s dominance in physical book distribution online will be hard to extent to ebook distribution (a topic I will explore further in an upcoming post on my own blog).

George’s point is that XML “is not enough.” Books will live in a larger world also using XML and highly internal standards and procedures for XML use, internal to a company or internal to the book business, do not necessarily equip a publisher to live in the larger world of the semantic web.

We don’t disagree with George’s premise that XML can be used to position publishers better for the semantic web. The question for all publishers will be how much they can take on how fast, particularly in pursuit of models and opportunities that haven’t really emerged yet. But the most forward-thinking always lead the target a bit, and George’s post enumerates one aspect of that.

We urge our readers to check out George’s post. And we encourage George to put his XML commentary right here on this blog; we’re delighted to receive it.

Related:

• See more StartWithXML posts

We got some great questions afterwards. On reflection, we realized that they touched an important theme: the need for CEO-level support for the change initiatives to put XML into the workflow. There are savings of time and money to be made by doing this, but that’s not the immediate result. In the short run, the changes require more work, more effort, and, sometimes it would seem, generate a less desirable result.

This echoes what we’ve heard from Andrew Savikas of O’Reilly. Instead of characterizing the two elements of a publishing organization as “hard (production, accounting, ops) and “soft” (editorial, marketing), Andrew says that for XML change they are “hard” and “harder.” Trying to get the most creative people in a publishing company to do something that is “harder” requires a top-down understanding that doing it is important to the business.

That’s why we asked David Young, the CEO of Hachette Books in the US, to deliver our keynote address. He’ll be speaking on the topic “XML: Why Bother?” That’s the question every CEO must answer to get the collaboration up and down an organization that large and systemic change requires.

Related:

• See more StartWithXML posts

We will start blogging a bit about the results later in October. Complete results will be published in our Research Paper, which will debut at the Forum on January 13, 2009 at the McGraw-Hill Auditorium.

There’s no attempt to be “scientific” here, but we are getting some very though-provoking results.

Related:

• See more StartWithXML posts

We have tried to make the points that new revenue opportunities will be small dollars and we’ve suggested that XML-structured content facilitated profitable exploitation of those opportunities. Gale has taken a big step in taking costs out by sharply reducing transaction costs for both buyer and seller through this Web site. Gale already has rich databases of content so they can create a standalone offer. Other publishers will be waiting for vertical aggregators (one of which is Gale) to pull their content into offerings like this.

It is pretty likely that those vertical aggregators will find XML-structured content easier to ingest and offer seamlessly than content which is not. And the quantity of content suitable for a vertical will be another way an aggregator will rank the potential providers of content, so the sooner content starts to live in XML, the more attractive a publisher will be when opportunity knocks.

Related Stories:

• Why You Should Care About XML
• Chunks and Verticals and Niches — Oh, My!
• XML and APIs: Perfect Together
• Visualizing the Advantages of StartWithXML
• See more StartWithXML posts

1. Until very recently, we lived in a world where the book was the sun and everything else orbited around it. Now the CONTENT, the IP, is the sun, and the book is relegated to one of the satellite bodies (still often the biggest, but it is a lot different to be Jupiter than it is to be the sun!) When what is at the “core” is different, the processes to create it have to change.

2. A StartwithXML workflow effectively makes the content file into a database. Just about any information relevant to the book, or any piece of the book, can be associated to the content in an XML file, just as it can in a database. Up until now, this has been seen primarily as a tool for production: the database holding information about document structure that translates into the presentation in each iteration. But the capability applies just as well to rights data, marketing data, or fragment identification.

Can these things be accomplished in other ways? Almost certainly, yes, but XML has the advantage of being an accepted standard, and although it may (will) require some dialog between entities sharing it, using XML is the fastest way to enable machines to talk to machines about anything related to a book’s content.

Related:

• See more StartWithXML posts

But it isn’t like publishers aren’t already aware that how authors deliver to them matters! Poking around the Web for other reasons, I found instructions to prospective authors on the site of a publisher I didn’t previously know, <a href="http://possibilitypress.com/about/authors/default.html”>Possibility Press.

As you will see, this publisher instructs anonymous (prospective!) authors about the margins and fonts they should use in Word, and what naming conventions to employ when they save the files (in the specific way that Possibility directs.)

For publishers who have already taken steps like these, the move to StartwithXML will be more like a refinement of current techniques than a wholesale change of procedure. And even if compliance is not 100 percent, and it almost certainly is not, it would seem likely that the work of creating these instructions is saved many times over in reduced work processing the manuscripts at the publisher’s end.

Related:

• See more StartWithXML posts

Among other things, our critic suggests that the usual consequence of having an author mess with the code is that the next job the packager or publisher has to do is pull out a lot of not-useful clutter.

What are we looking for? We want the biographies within a historical book that are used to introduce the characters. We want the place descriptions from any book — many from novels — that would be of interest to anybody visiting or looking for information about the place. We want to know which of the woodworking projects in a collection are suitable for Christmas, or require minimal tools, or a minimal skill level, so that we can create different collections for different audiences.

All things like this, the author will know best, usually better than the copy editor. Also better than the acquiring editor. And certainly better than the managing editor.

Extracting the value of the author’s knowledge and developing the tool sets and workflows that make it functional to incorporate it in the XML document of a book will require a lot of reinvention. In that sense, “not in this lifetime” is an accurate metaphor for when it will happen. Publishing needs some “born again” changes and this is one of them.

Related:

• See more StartWithXML posts

Mark offered the observation that too many people in publishing don’t understand what constitutes an “asset.” He maintains that a content asset has two components: the intellectual property itself and the right to use or license it. The content without the rights information is actually a liability, because you’d have to expend effort (which means money) researching the rights situation before you could use or license the intellectual property.

For all the money and effort spent by publishers on DAM systems over the past several years, very few consistently store rights information with the intellectual property. VERY few. One of the things we’ve learned quickly in the StartwithXML project is that, while an XML repository readily enables storing rights information with the IP, almost nobody uses it that way. One of the leading companies enabling XML workflows actually described our suggestion that the XML document should hold rights information as “a very good idea.” It was also, to them, a somewhat novel idea! And they are a cutting edge company on XML workflows.

So chalk up one more reason to go through the pain of the process change to a StartwithXML workflow. If Mark’s formulation is right, and I think it is, doing so is the difference between creating assets and creating liabilities with each new piece of IP!

Related:

• See more StartWithXML posts

No publisher of any size or scope can be beyond the XML conversation that is now taking place across the industry. That content must be kept in a repository of XML files has become common understanding. And all the content-generation tools we use — Word and InDesign and PDF prominently among them — enable an XML export, so publishers are finding they can create a post-production XML’d version of their content for their archive.

That alone is necessary, but not by itself sufficient, to achieve even the first goal of making conversion — to a different book output like large-print or to the Web or to any of many ebook formats — cheap and easy. You can use Word or PDF to get to XML, but without the discipline of a StartwithXML workflow, you will often — usually — get an output that working with XML discipline wouldn’t have allowed you to create. If you don’t apply the discipline, the XML output doesn’t solve your problem. And even if it did, it only scratches the surface of what XML can potentially offer to publishers in getting them closer to new revenues and cutting costs.

The “StartwithXML” project will explore all the issues of moving to a StartwithXML workflow through interviews and case studies with publishers and with the channel partners they will be working with to reach new readers in new ways. We’ll be looking at what benefits can come to a publisher today from working this way, and what important steps to the future are enabled for those doing this (and cut off from those who don’t.)

I am introducing the project this morning (Friday, 12 September 2008) at the BISG Annual Meeting. That talk covers the who, what, why, when, and how. The discussion will be continuing in this space from now.