Viacom’s Comedy Central stars, The Daily Show and The Colbert Report, should be downloadable for free. And there’s a good, convincing reason for this that all the people involved should agree with.

After Google’s acquisition of YouTube, Viacom’s lawyers started asking for the ever-popular clips of their shows to be taken off the site. And much to the chagrin of YouTube faithful, Google complied.

Several things make this silly. First, both shows are topical. Lost might be good a year from now, but old episodes of John Stewart’s antics are really only fascinating to computer scientists. And second, the Internet postings of their shows are one of the main drivers of their popularity — as evidenced by Stephen Colbert’s collective hacking of Wikipedia and rigging a vote for a bridge in Eastern Europe.

So why should it be free?

Well, not free exactly. There’d be an ad (or ads) you can’t skip. But here’s the kicker for advertisers:

• You’d be able to specify a target audience (in other words, viewers would be asked to disclose basic stuff like their gender and age)
• You’d find out who watched the ads
• You could tailor content to the time it was downloaded and geographic region with great precision
• You could have a call to action (a clickthrough) to the product or service

To an advertiser, this is gold. An old adage goes, “I know half of my advertising budget is wasted; I just don’t know which half.” One of the reasons that online advertising is enjoying such a bull market is that it’s far more measurable than traditional broadcast media because of traceability and targeting. This “free” download of content would fare far better than the traditional advertising model.

Who loses? Well, you could argue that viewers lose a minute or two; but they get the clear conscience and uninfected desktops that come from not using illegal means to get their shows. The networks get a better advertising product. And the advertisers get targeted messages whose effectiveness they measure.

It seems that the only losers are regional telcos and cable providers. The same guys who want to have tiered bandwidth on the Internet (I’m listening to Vint Cerf debate net neutrality as I type.) As the alternatives — VOIP, downloadable TV shows, and the like — become more and more compelling, the traditional models for telcos and regional cable companies are starting to crumble.

Let’s define the two camps.

• The operations teams are responsible for keeping things running. Their view is that change is the leading cause of problems. A support team member I know has a big sign marked, “What Changed?” on his wall as a constant reminder of this.
• The engineering teams like change. They’re the agents of change. They get yelled at when they don’t change things fast enough.

So the battle lines are drawn. Operations abhors change in any form. This is true whether they run the infrastructure, the OS, the network, the data center, or a particular application.

At the same time, the engineers want to deploy fixes and enhancements as quickly as possible. They’re limited in their ability to test the changes before they go into production; then they have to throw them “over the wall” into operations.

At this point, lots of things go horribly wrong.

• The change fails hard, causing operations to reject it.
• The change doesn’t break, leaving everyone tip-toeing around and seizing on any anecdote that might confirm whatever suspicions they harbor.
• The change exhibits some strange behavior with whatever monitoring hooks have been put into place. But if the engineers put the instrumentation in, operations insists it’s not valid for a production environment; and if the operations teams are monitoring it, then the engineers say it’s not getting them enough detail.

And of course, the United Nations of marketing sits by, wondering why the conflict is happening and lumping both operations and engineering into the “technical people” bucket.

How do we declare a truce between these two groups?

It starts with consensus before any of the deployments. Very few organizations set expectations before a change, and fewer still agree on metrics, monitoring methods, and thresholds. Any change will have an effect, but if the company is unable to measure that effect, fighting will follow.

Changes will almost certainly have one or more of the following impacts:

• A change in capacity, where the application can handle more (or less) concurrent users.
• A change in performance, either from the network (bigger content, more objects) or from the application (dynamic pages, back-end queries). This may be a complex effect: Switching to a content delivery network may speed things up for some users and slow down others.
• A change in operating cost as a result of more or less self-maintenance. A new database might require more administration, or more frequent backups.
• Additional support costs because the system is harder for end-users to operate or because they need assistance with upgrades
• Different availability and reliability because of maintenance window changes, or the Mean Time Between Failure (MTBF) of new components.

Both engineering and operations must realize that change is a constant, but that the impact of changes needs to be verified and tracked. Without expectations set ahead of time, the effects of a change will lead to blame and recrimination. But if a company agrees on what kinds of impact are expected and how to measure them beforehand, we can at least keep the fighting down to regional skirmishes instead of an all-out battle.