Designing a New Software Distribution Process

In reading this month’s Wired Magazine (not yet online unfortunately) I found its article about the new Red digital movie camera fascinating. Based on a new chip, it shoots at very high pixels and can execute enough shots per second to compete with film. Moreover, it has the ability to selectively focus part of its picture while leaving other parts fuzzy, a technique used in every movie to focus the attention of the viewer. Plus, it cost 10% of what less-capable digital movie cameras cost, as well as less than one month’s rent for a Panavision camera.

Still, all is not perfect with the camera: to store its digital information costs about $12,000 per year, while regular film only costs $1,000. Despite such criticism, Bengt Jan Jonsson, cinematographer for the Fox TV show Bones, is quoted as saying “Honestly, if you proposed the film work-flow today, you’d be taken to the city square and hung. Imagine I told you we’re going to shoot on superexpensive cameras, using rolls of celluloid made in China that are a one-time use product susceptible to scratches and that can’t be exposed to light. And you can’t even be sure you got the image until they’re developed. And you have to dip them in a special fluid that can ruiin them if it’s mixed wrong. People would think I was crazy.”

This discussion comparing the merits of digital vs. film: look at these small shortcomings in the new process, when what we’ve has worked for over a hundred years vs. the established process is familiar but doesn’t make sense if examined objectively is reminiscent to me of the proprietary vs. open source debates that go on.

CIOs comfortable with the current way things are done criticise open source: there’s no throat to choke, the vendors aren’t big enough to service my organization in the way we’re familiar with, what is this community thing anyway? All valid to a lesser or greater extent.

However, those responses are formed without examining the flip side: how do things work today and does that process make sense? To echo Jonsson, imagine I told you “Someone is going to create a software product, spend as much selling it to you as you pay the first year, refuse to let you try it enough to determine whether it will really work in your environment, keep the internal code secret and not let you examine it, forbid you from publishing benchmarks so that its performance can be compared to other products, charge 20% of the initial price each year for maintenance whether you need it or not, and potentially pull it from the market due to internal business reasons with no possibility for you to do anything about it. Oh, and by the way, if they do keep in the market, they may come up with mandatory upgrades requiring additional fees.” People would think I was crazy.

Now, I don’t know how Red will fare in the marketplace. A number of filmmakers are creating new releases with it, so it capabilities will soon be on display in theaters around the nation. But the responses to it are common to new market entrants: It’s not exactly what I’m used to, so I’ll pooh pooh it and keep doing what I’ve always done. If Red delivers on what’s described in the magazine article, there’s no doubt in my mind that it will sweep through the movie camera business. It’s too compelling.

The same kind of responses

are voiced about open source: it’s different and I want to stick to what I know. Just as Red’s advantages are so significant that it will revolutionize the market, so too will open source revolutionize the software market. There was a time when making a long-distance telephone call required contacting an operator to put it through. When direct dialing first came on the scene, many people rejected it due to unfamiliarity and assuredness that a machine could never be as accurate as an operator. Just as we look back from today’s vantage point on long-distance operators with disbelief, we will someday look at the proprietary software process with puzzlement.