Last month I had intended to write something about debugging, the theme of that issue. I didn't, and the reason probably goes back to the middle of the last decade, to a decision that haunts me to this day.
It's not true, as former Apple evangelist and current spokesmodel Guy Kawasaki wrote recently, that all computer writers have serious conflicts of interest. Guy is a master of speaking for himself, but he probably shouldn't try to speak for other writers. For the record, I have never been an employee of a computer or software company, have never held stock in a computer or software company, have never been romantically involved with an employee of a computer or software company, and have, with one exception, never done contract work for any computer or software company.
I'm not telling you this to brag, as will be apparent momentarily, or even to show you how dull my life is. Rather, I'm setting up a context for confession. Because there was that one exception.
It was back when I was warming the chair for Jon Erickson as editor-in-chief, the Macintosh was new, and I was spending a lot of time talking with the intrepid developers for that new Platform. One day one of the most intrepid, Steve Jasik, called me. Steve had written an interesting code-snooping tool called MacNosy. Steve had also written the manual for MacNosy, and it could also be called interesting. He felt that maybe it could use some work and wanted to know if I wanted the job.
I hadn't done any documentation and thought I should get some experience. I also thought it would be good for the magazine for me to work closely with a software developer on a commercial programming tool. I had programmed, I had looked over the shoulders of developers, I had edited code, but I hadn't sat at a developer's elbow day after day as he coded an application. I understood how difficult the documentation writer's job was, but fool that I was, I thought I could handle it.
Working with Steve proved to be a Beckettesque experience. Laconic is the word for Steve's conversational style. Mostly he typed at me. "And you can ..." he would begin, then type, and a table of hex codes would appear in a window. Or: "Of course, you've got this..." and he would triple-click on a piece of code and some more code would appear in another window. Any reasonable person would have insisted that Steve explain all these off-hand demonstrations, but a deep flaw in my character makes it difficult for me to admit to ignorance of anything. Conversing productively with Jasik would have required just such an admission about 90 times an hour. My ego wasn't up to it.
Ultimately I gave up and passed the project on to someone else. Steve's documentation still acknowledges me, I think, but for what I couldn't say.
I never took any money from Steve for my efforts. But that doesn't get me off the hook for conflict of interest, because there remains the possibility that anything I write about Steve's products is tainted with a sense of guilt at not finishing that documentation project.
I ran into Steve in an Apple Developer room at MacWorld Expo in Boston in August, demo-ing his debugger. "Want to see the latest and greatest?" he asked, and I, motivated I know not to what degree by guilt, fixed my eyes on the screen. The debugger, I was happy to see, is a much more visual product than the original MacNosy: For example, it uses bar graphs to show usage of subroutines. This time, when Steve said "And you can..." and typed, these clearly labeled bar graphs popped up, and I got it.
But I didn't ask to see the docs.
There were some cute products at the show, including a solar panel for Power-Books and a morphing tool that jammed the aisle with people watching the demo of George Bush's face slowly and eerily transforming into Bill Clinton's. It's worrisome to a writer to see a joke told without words. Video, I sometimes worry, is the enemy of words. Then I remember that video, like everything else in the world, is subject matter, and I quit worrying.
The hot products were chiefly in the video realm, where it's getting more possible to do serious video post-production on the desktop with equipment that doesn't cost an arm and a leg. I know it doesn't make any more sense to say "more possible" than it does to say "a little bit dead," but the state of this field seems best described by this kind of logic. Right now, there are tools for controlling analog video devices from the computer, tools for editing digital video on the computer, a standard format for video, powerful compression software, boards for capturing analog video digitally, boards and monitors for displaying video--all the pieces seem to be available, but putting them together is difficult. But it's getting more possible.
As usual, the most interesting part of the show was the parties, at one of which I ran into another pioneer Mac developer who is now doing distribution. Well, sort of distribution; he is making a business of acquiring software for companies. Although he currently represents large companies that buy in sufficient volume to justify hiring a buying service, he had some thoughts about how his service could be provided to ordinary consumers. Although he's not ready to go public with his ideas yet, it is intriguing to consider the consequences of a shift in emphasis between buyer and seller in the software market. I mentioned Brad Cox's concept of pay-per-use as expressed in his then-upcoming DDJ article "Superdistribution and Electronic Objects" (see page 44 in this issue), and he agreed that some new ideas about connecting buyers and sellers were going to be needed to make object libraries really useful.
NeXT (no, it wasn't exhibiting at the Expo, although Silicon Graphics was) is using one fairly conventional technique for connecting customers and vendors for software objects. The NeXT ObjectWare Catalog contains a hundred or so objects, ranging from interesting tricks to highly useful components. Some of the objects are commercial products and others are freebies from academics. There's nothing new about selling software by catalog, but the dynamics of the object market may make channels like this more important than before.
I also ran into Steve Rosenthal at the Expo, an old friend and a writer who has appeared in these pages and in many other mags. He is one of the more trenchant observers of media today; and he took me media trolling.
We screened Todd Rundgren's latest Toaster video, Theology. Nutek, whose Video Toaster is Rundgren's video tool of choice, has been showing his Change Myself video for some time now, but this latest work is technically and artistically much better. It was enthusiastically received at this year's SIGGRAPH, as it should have been. With all due respect to the masters of new video at Lucas Films and elsewhere, what Rundgren is up to is the best demonstration of the artistic potential of computers and video I've ever seen.
We wound up in an MIT basement where Steve moderated the third Media Event, an informal gathering of video developers and others interested in issues related to the confluence of technologies that the Media Lab folks are so deeply into. One viewpoint expressed at the media event interested me particularly. In a discussion of rights, it became clear that those present don't want software to enforce copyright, even if that is possible. The copyright page in a book informs, it does not enforce, and the developers indicated that they would like to see such a scheme of informing rather than enforcing in video.
How to inform is still a tricky issue. Do you label every frame somehow? The issue is crucial, because digital technology makes it easy and tempting to put together works by using existing video. The more this is done, the more often it will be the case that the video clip you want from Fred is not really owned by Fred: He got it from Alice, who got it from Geoff, but Alice doesn't know how to get in touch with Geoff any more. The solution is to attach owner/creator information to the clip, but "clip" is not a well-defined unit. Hence the unappealing idea that you might have to attach this kind of information to every single frame of a video. The extra bytes are no big deal, but all copying, editing, and encryption software would have to know about the copyright information, and preserve it through transformations. Tricky.
But not everyone feels that informing users about copyright is adequate protection, and there will continue to be proposals for ways to incorporate some protection into software and other digital products. The concept of monitoring use and charging users on a per-use basis, as discussed by Brad Cox and by Jon (in his October 1991 editorial) is certainly interesting.
I have a variant proposal. I think of it as software subscription, but that term may already be claimed; I know that Microsoft calls their automatic upgrade deal, Microsoft Maintenance, a software subscription. But there is nothing new about my idea, anyway, except possibly how the already-existing pieces fit together. And someone else may already have put them together. Maybe this is another one of those things done 20 years ago on mainframes. Maybe some software vendor is doing it today and I just haven't noticed. I claim no priority. But on the theory that we need several fleshed-out proposals to pick away at, I put mine forth for the picking.
Your application is distributed freely online just like freeware or shareware. All documentation is electronic and supplied with the application. The application may also be sent directly and freely to target customers through mail-order lists, and other distribution methods are possible. But it won't appear on dealer shelves, and nobody will be charged for merely receiving the disk containing the program. Payment is for use.
The program contains a use counter, and is shipped with the counter set at a low value, like ten. Anyone who gets his or her hands on one of your disks, or on a copy someone has made of one of your disks, gets ten free uses of the application. Or fewer than ten: Fred might try your application once, then make a copy for a friend. Copying the disk copies the current counter value, so Fred's friend will have only nine free uses. The application should probably do something useful when the counter gets to zero, such as telling Fred's friend how to get in touch with you.
If Fred (or his friend) decides the application is worth using more than ten times, he calls the number you display in a splash panel, and orders more uses. He can place the order before the counter gets down to zero, but it's not a problem if he waits until the last minute, because the purchased uses are available immediately.
The technology for delivering uses is basically the same as is used in font CD-ROMs. With these products, Fred can call and give his serial number and a credit card number and the font he wants to buy, and he is given, over the phone, an encryption key to unlock the font on the disk. He keys it in, and he's got the use of the font. (He already had the font itself; it was there on the disk.)
The process is similar for buying uses of your application. Fred gives you his serial number and a credit card number and the number of uses he wants. He gets back a key that, rather than decrypting a particular file, resets the application counter to a particular value. If this is his first purchase and he got the application from someone else, there will need to be an additional interchange: He gives you his credit card number and you give him a different key, which, when he types it in, inserts a new serial number into his copy of the program.
You might give Fred the ability to specify any number of uses, or you might want to restrict him to certain values. One plan might be: $20 for 10 uses, $100 for 100 uses, $200 for 1000 uses, and $500 for unlimited uses (or effectively unlimited; maybe you set the counter to 65,535). Another, more security-minded plan would allow only relatively small use purchases: no more than 100 uses per call, say, or in an extreme case, no more than ten.
There are some obvious security problems in this scheme. For one thing, the counter is on the disk, so it can obviously be changed by a sufficiently adept user. But this would require some serious effort, since the portion of the code containing the counter would be encrypted. Another problem is that, as I have described the system, there is zero copy protection. To encourage wide distribution of sample copies of the application, you let all copies be full working copies, indistinguishable from the originals. This means that if Fred has purchased 1000 uses and now copies the disk, he can give a friend a 1000-use free copy. Not good.
There are various ways to deal with this, from only allowing reasonably small numbers of uses to be purchased at one time to a fairly benign copy-protection gimmick that would allow unlimited copying, but would reset the counter on any copy to a low number.
Note, though, that the copy is only free until its counter runs down. Now when Fred's friend tries to get more uses, he will have to get himself a new serial number and start paying. You know that he needs to get himself a serial number because your software notices that his serial number and his credit card number don't agree (unless he has stolen Fred's, in which case Fred has a problem, not you).
More than this, your software can also determine: 1. that this is a copy (by the lack of agreement of serial number and credit card number); and 2. that it was copied with the counter set high (because the last usage purchase on this serial number was a large number). Given these facts, you could then tell Fred's friend that you would be glad to sell him more uses, but that he will first have to pay you what he owes you for past uses.
You could only do this if you had informed him before he ever used it that his copy was a special kind of copy, and that, say, only the first ten uses were free. But it would be possible to drop that warning message into the application when the original user (Fred) made that large use purchase. Since Fred's disk and his friend's are identical, the message would have to make sense to both of them. A splash screen like this might do it:
WARNING: Use of this program may cost you money. 100 uses of this program have been purchased by Fred Grimly. While this program may be copied freely, its use by anyone other than Fred Grimly will be charged to the user at the rate of $5 per use. If you are not Fred Grimly and do wish to use the program, we recommend that you register it by calling 1-800-555-5555. Registering the program will allow you to purchase uses at a substantially lower cost and will allow you to be informed of upgrades, bugs, and related products.
It seems to me that a system like this should work, and would result in greatly reduced marketing costs, no fighting for shelf space in computer stores, elimination of paper documentation costs, excellent information on the actual use of your product, more flexibility in pricing, fairer pricing, and better contact with your customers.
That's how it seems to me. But running into Steve Jasik at MacWorld Expo has temporarily humbled me, so that I suspect that this idea is fatally flawed.
So where is the fatal flaw?
Copyright © 1992, Dr. Dobb's JournalThe Laconic Programmer
The Democrat, the Republican, and Various Other Parties
Media Trolling in the Basements of Boston
Subscription Software
Buying Uses
Fixing the Holes