New Trends in Electronic Publishing

I'm a consultant (sounds like an admission) in the publishing industry and throughout my career I've developed and integrated new technologies to help publishers stay competitive. Everything from back-room content management to user-facing "wow" tools. And, I'm noticing some trends in the publishing business lately. Especially in electronic publishing. These are some things I'm observing from my clients specifically, and from public media (annual reports, news, and so on). I think we're seeing a big shift in the way publishers generate revenue, away from the value on information.

One well known revenue shift is towards advertising revenues. This is an old model, of course. Newspapers have been at it forever, and online search engines for years. But more recently, we're seeing a larger shift of revenue away from subscription sales for information resources and towards advertising. I think this is driven by a couple of factors.

First is the nature of the internet and social networking. These are creating an underlying expectation of free information on the web. No news there! But this is creating new revenue streams in the form of advertising that are replacing traditional subscription revenues. And with tools like Google's AdSense, this is easier than ever to do, making it possible for just about anyone to create an ad-driven information portal.

The second factor is the rise in information portals repurposing and rebranding content for their own purposes. Tools like RSS and aggregators like Feedburner make it easy to brand your own content, creating a demand for and an expectation of specialized information sources. In a sense, this is dividing the traditional publishing industry into two parts -- information creation and information dissemination. Publishers used to integrate both these functions under one roof, but in the repurposing/rebranding scenario lines between these functions become clear. New revenue streams are being created and recognized by selling content for aggregation, repurposing and rebranding.

Related to this is the increasing role public entities are playing in the information dissemination arena. A large market used to exist for private publishing of government information. In the old days, these publishers took government data and added value through indexing or other finding aids and sold the improved access. As technology tools have improved, government agencies are more easily and readily able to perform this publishing themselves. So adding content value has become more important to the ability to create revenue than using technology to improve access.

And this is exacerbated by the economy. With more choices and less budget, customers will opt for the cheapest product that reduces their workload. User expectations are indeed greater. Users now expect to access content with minimum wasted time and maximum accuracy. To stay competitive, publishers need more sophisticated user-facing technology to meet these expectations. In turn, new revenue streams are coming from sales of integrated technology and content or from the sale of the technology itself (software products).

So, do I have a conclusion from this? Not really. I don't think anyone can accurately predict the course of publishing over the next few years. I do think publishers need to keep their tools sharp. My personal belief is that investments in the right technology will win out in the end, but mostly because it will enable the publisher to be ready to respond to changes more rapidly. Of course, I'm a techy saying this, so my view is slanted. I'm reminded of a joke by Emo Phillips: "I used to think the brain was the most important organ in the human body, then I realized what was telling me this!" But I can't help thinking that technology investment, especially in these tough economic times will out.

Getting Some Real Offshore Experience, Redux

I posted about getting some real experience working with an offshore development group. As I said, we entered into this arrangement with a short-term trial to see how it would work out. We ended that trail today and I guess I still have mixed results to report.

Working with an offshore team in an Agile world is annoying. A lot of time is lost because the offshore developers are not co-located (even within the same time zone). I would say that my initial conclusions about the TCO for code developed still holds -- about he same or even more than the cost of doing it with our regular development team.

We had some problems with the develop initially assigned to work with us. To their credit, the offshore company took care of that, replacing the one with a more mature/professional developer. We lost some time and money in that transition, but the startup cost of this kind of relationship cannot be underestimated.

I guess the conclusion I've come to is this, write good specs and way overestimate the cost. But the skills are there. I will work with this group again (probably). Next project we get.

Getting Some Real Offshore Experience

In a former post (see "Offshore Development Woes"), I wrote some personal conclusions from reading Martin Fowler on "Using an Agile Software Process with Offshore Development". It was a summary of what I got from Mr. Fowler's experiences. Interestingly, though I have worked with many developers from many Asian countries over the years, I have never actually worked with an offshore software development company performing development for hire under my direction. It's easy to be an armchair critic.

But that's changed, at least a little. Faced with a recent influx of development projects and a lack of staff to get them done in a timely manner, I decided to develop a relationship with a firm based in India. Being the cautious type I am, our initial foray into this arrangement was for a limited time and scope -- I really wanted to see how well it would work out. And I was especially intrigued given Mr. Fowler's experiences because we too are an agile development shop. I had misgivings based on the rapidity of our development and the time and language differences. But the hourly rates proffered were downright seductive. I figured that at the $25 per hour rate we were being charged, we could afford to lose some time to these difficulties and still come out ahead. And I really want it to work.

It's now been 7 weeks into this trial and I guess I have mixed results to report. First, as Mr. Fowler observed, there is no real cost savings in spite of the seductive hourly rate. Between the language barriers, the time differences, things just plain take longer. A lot longer. And that costs. It's not like the developer in India isn't charging me for those differences. We use email and Skype to get our communication done since written English at least removes accents from the equation. And our developers in India work odd hours, so in spite of the 9.5 hour time difference, I can usually talk to them throughout the morning.

But I've now worked with the group on three development tasks. The initial effort was to get the existing project development infrastructure (Eclipse, Tomcat, CVS, MySQL, and the project code) up and running. I have to say, I was impressed with how quickly and smoothly that happened. It showed that the Indian team was well acquainted with these tools. So we moved on to actual development tasks. I made an effort to be more clear and concise than I usually am in providing task writeups. We had several email exchanges asking for clarification and I got my first code delivery in about a week. I was very disappointed. The code was no where near complete, was undocumented, did not follow style guidelines, and was generally unproffesional (a java package name of "jesus.xml"?). But the real problem was the lack of some basic computer science -- a huge switch construct instead of arrays; a single large method instead of encapsulation, and so on. I rewrote the code and sent it back with further instructions on what I was looking for.

To make a long story short(er), this seems to be the pattern -- delivered code is under-par, I rewrite it and return it, and they then follow my pattern. This put the first several tasks way over budget.

We did make a complaint to the management team. Their solution was to add another resource (a more senior programmer) to the team. At their own cost (to their credit). But now, every detail is being questioned and designed out in advance. We've lost our agile approach. And the costs are higher still, since I spend so much time trying figure out the answers to their questions.

So, in all, this effort has proven to be more costly than we had hoped and it pushed our project costs over budget. It may be that a different team from India could perform better, or that if we developed using a traditional "waterfall" life cycle, things would be better. But this has not been a success for us.