Don Marti

Thu 29 Sep 2005 06:27:30 AM PDT

Cory Doctorow goes to HP

Martin Fink from HP said he wanted to reconcile open source software and DRM, so early this year I wrote "If You Don't Believe in DRM, It Can't Hurt You", which Cory Doctorow quoted in a talk on DRM for...HP.

After I put up the "If you don't believe" piece. I was expecting to hear from readers who had some kind of a business case for DRM "at the office". Not DRM imposed on customers, Apple iTunes style, but the "you-can't-forward-this-mail" stuff. But not a thing.

I had a pretty good idea that it's better to spend your IT budget on actually creating value than on going back and making your email system flaky again by imposing the added complexity of DRM, but a Geoffrey Moore talk on IT Conversations really helped me understand where DRM fits in, or doesn't. Some definitions:

Core: "Any process that contributes directly to sustainable differentiation leading to competitive advantage in target markets."

Context: "All other processes required to fulfill commitments to one or more stakeholders."

The important thing about Core is that you want to do it better than other companies, and succeed in the market. The important thing about Context is that you need to get as many resources as possible out of doing it, in order to concentrate on Core. How? Centralize, Standardize, Reengineer, Automate, Outsource. (Listen to the whole talk. It's good.)

So, where does the "prevent recipients from forwarding your mail" project fit in? Is a customer going to buy from you because when you send them a proposal, they can't forward it? Not likely. So unless you're selling the DRM system itself, it's not Core.

That leaves Context. Here's an almost-perfect example of a Context project: Network Management with Nagios by Richard C. Harlan. (4 out of 5: centralized, standardized, reengineered, automated, but run in-house). No customers buy tractors because John Deere manages its network well. But notice the mentions of financial constraints. This project has to get done cost-effectively so they can invest in R&D on the next generation of GPS-enabled tractors. (Tractor projects and GPS projects: Core) You need just as much control over a Context process as over a Core one. The difference is that you use that control in different ways to achieve different goals.

Now imagine that you do see some business value in adding "do-not-forward" DRM to your mail system, as a Context project. Can you take that and centralize it? Probably. Standardize? No—DRM systems don't and won't play nice with each other. Reengineer? No. Not reengineering DRM is what the DMCA is all about. Automate? Likewise. Sure, you could outsource the whole thing...but how good of a deal are you going to get offered when it's time to renew the contract with the Vendor Who Controls All Your Mail?

Moore points out that Core processes become Context as competitors copy them, and that's unavoidable. But office DRM starts out as something that can't be Core, and makes terrible Context too. Strangely enough, thanks to the apparently pro-DRM DMCA, DRM for the office is condemned to be just an irredeemable money drain that goes on indefinitely.