If you believe the world of reusable object-oriented software components is upon us, you might give some thought about how to measure the value of software. For OO pioneer Brad Cox, the best way to measure the worth of code is by the amount of use it receives, not the number of copies sold. Consequently, says Cox, programming tool vendors wanting to distribute their wares may want to follow the lead of WKRP, instead of Egghead Software.
It's Cox's view that today's software industry faces some of the same challenges the music industry confronted years ago when radio stations began playing music free-of-charge to listeners. Instead of crying the blues, the melody moguls adopted the concept of pay-per-use, a notion that simply means radio stations receive music free-of-charge, paying for it as songs are played. Industry-sponsored clearing houses (ASCAP and BMI) monitor this process by, among other functions, receiving payment from radio stations and distributing royalties to publishers.
Cox proposes that software vendors also distribute programs free-of-charge, allowing users to pay for software only as it's used. No, this isn't shareware in sheep's clothing. To use the software, you need a unique add-in board--provided at no charge by an ASCAP-like software clearing house--that unlocks the software for use and logs it as it's accessed. The user then uploads (via an 800 phone number) usage information to the clearing house, receiving an invoice by return mail.
Instead of the phone system, the add-in card can be equipped with an RF modem, allowing the board to wake up at certain times to automatically broadcast software-usage data to the host. If the user doesn't pay the piper on time, the host broadcasts a shut-down message until the bill is paid. Software updates and other information can also be transmitted.
Pay-per-use seems more apropos for tool developers than end users. First of all, it's ideally suited for reusable, high-level software components that can be assembled into working programs. Having a storehouse of thousands of C++ classes at your fingertips is tantalizing; having to pay for each and every one isn't. With the current pay-per-copy model, you buy the whole enchilada just for access to a few. With pay-per-use, you have access to a storehouse of components, but only pay for those you use, as you use them. Implicit in this concept, of course, is a royalty-free distribution license covering software passed on to end users.
Just as radio station end users don't pay to hear music, neither will software end users be inclined to spring for pay-per-use programs. (I certainly don't want to hear the cash register ring every time I launch my word processor.) However, pay-per-use might eliminate some headaches for network administrators. Every time an application program is copied from a server to a network workstation, the "use" is logged, broadcast, and invoiced--and documentation is immediately express mailed back to the site. The administrator only has to manage a single in-house copy. To some degree, this oversimplified sketch describes technology that's already in place: Hewlett-Packard's NetLS software, for instance, "floats" licenses around a network, logging charges based on time used.
Nor is there any reason why pay-per-use and pay-per-copy can't reside on the same system, particularly for developers. Programmers would likely have pay-per-copy compilers, roll-your-own classes, and pay-per-use components. (In fact, we already accept a pay-per-copy/use mixed model with the phone system: We "pay-per-copy" for local phone calls and "pay-per-use" for long distance.) Individual programmers might very well want to pay per copy for some components, particularly for those objects they frequently use.
Before pay-per-use software--or, for that matter, the concept of reusable components--will be accepted, standardization is a must. We'll want, for example, to share components across various vendor products: A C++ class must work with any C++ compiler. This is being addressed by the ANSI committee, which is making progress. The bad news is that the ANSI process takes time; witness standard C.
But standards within a language definition aren't enough. We'll also want to share code across languages; objects common to both Smalltalk and C++, for example. This issue is also being addressed, in one case by the Object Management Group, whose goal is to define a framework--a common object model--to develop a heterogeneous applications environment across various hardware and operating systems.
The optimum environment for pay-per-use may be in a team or "megaprogramming" environment rather than the one-person/one-computer shop. Megaprogramming, a concept described by Michael Floyd in DDJ January 1991, views programming in terms of designing and composing software components on a grand scale. Reusable class libraries designed for team programming settings are also becoming available; ParcPlace's recently released Objectworks\C++ Version 2.4 lets programmers load and browse each other's C++ code without interrupting each other.
If either megaprogramming or team programming is in our future, pay-per-use software in one form or another may play an important part in it.
Copyright © 1991, Dr. Dobb's Journal