[work in progress; comments solicited]
Back in the mid 90s, one would regularly read about the Future of Software being something like this: when you want to build an application, you find, licence and assemble a whole bunch of components from individual software vendors. You plug them together, according to well-defined interfaces, perhaps write a few high-level components of your own, and deliver the whole assembly the the customer.
Stop selling software. Give it away. Get paid for its use. Meterware is so logical it could be the foundation of the new, networked economy.[...]
Treating ease-of-replication as an asset rather than a liability, superdistribution actively encourages free distribution of information-age goods via any distribution mechanism imaginable. It invites users to download superdistribution software from networks, to give it away to their friends, or to send it as junk mail to people they've never met.
Why this generosity? Because the software is actually "meterware." It has strings attached, whose effect is to decouple revenue collection from the way the software was distributed. Superdistribution software contains embedded instructions that make it useless except on machines that are equipped for this new kind of revenue collection.
Superdistribution-equipped computers are otherwise quite ordinary. They run ordinary pay-by-copy software just fine, but they have additional capabilities that only superdistribution software uses. In Mori's prototype, these extra services are provided by a silicon chip that plugs into a Macintosh coprocessor slot. The hardware is surprisingly uncomplicated (its main complexities being tamper-proofing, not base functionality), and far less complicated than hardware that the computer industry has been routinely building for decades.
Electronic objects intended for superdistribution invoke this hardware, which provides instructions. These instructions check that revenue-collection hardware is present, prior usage reports have been uploaded, and prior usage fees have been paid. They also keep track of how many times they have been invoked, storing the resulting usage information temporarily in a tamper-proof persistent RAM. Periodically (say monthly) this usage information is uploaded to an administrative organization for billing, using encryption technology to discourage tampering and to protect the secrecy of the metered information. (Think of your utility bill.)
To get there, we would have needed a few things. Firstly, new technologies that allowed programs to be reliably assembled at run time from component libraries. This is more than just dynamic linking: you need to think about finding the right components, versioning, making state persist, and so on. Given the processor speeds of the time, they needed to be (mostly) native binaries, rather than some kind of bytecode. The technologies here include things like OS/2's SOM, COM, Objective C, and so on. Most of these use a kind of looser linking than we normally have with C, in an attempt to allow the libraries to evolve without breaking the applications.
Secondly, you need an economic model to support it. If people are going to publish and sell small component libraries you need a way of licensing them and a way of arranging payment. If the components are going to be very fine-grained, this converges on almost a kind of micro-payment system, particularly if you want per-use licensing.
I find this really fascinating because it's so close, and yet so far, from what we have in free operating systems. A free Unix system is built from components written by many individual and independent programmers, which are in turn assembled by other people. Possibly there are several layers of assembly: subsystem maintainers knit up all the parts of the USB Storage system, which is in turn assimilated by somebody else into the USB system, which Linus merges into the kernel, which somebody else patches for optimal desktop performance, and that is in turn only one part of the distribution.
Despite the similarities, free software seems to be proving that the Superdistribution model is fundamentally wrong.
Putting code into binary, closed libraries, just doesn't work very well. At least, it works far less well than open source libraries. It ignores some fundamental properties of software: that defining interfaces and documenting behavior is as hard or harder than implementing the behavior. Even if you never change the source, having read access to it as the ultimate documentation is incredibly useful. Eric Raymond has a good discussion of the problems with binary libraries in his book The Art of Unix Programming.
Even assuming the library has good test coverage by the publisher, it will always hit situations in the real world that weren't contemplated, especially when it's put into a complex ecosystem of other components. Testing and documentation can't cover every conceivable use.
As if binary libraries weren't bad enough, Cox suggests that the components need to be subject to DRM to protect the revenue stream of the author. We need new hardware, a la Paladium. This makes sense within his economic model, but consider how horrible it would be to use. “Protecting” the code would probably require that it be kept shrouded and encrypted: not only is there no source for the application developer, but probably not even any ability to use a low-level debugger. And just think about the bugs DRM can introduce. Pay per use requires some amount of DRM, but DRM from the user's point of view makes the components strictly worse. At most it is tolerable; at worst it blocks the project entirely.
As an example of strong DRM: I'm quoting some of Cox's writing above. How should I arrange payment for this quotation? How should I arrange for you the reader to pay him for reading 10% of his essay? Why should I give up emacs and Mozilla in favor of tools that restrict my ability to copy and paste? (I think Xanadu was trying to charge by the byte, and who uses Xanadu?)
So: Stop selling software. Give it away. Work out some other way to make money, because pretending it's not replicable is not it. Profit.
Archives 2008: Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May
Copyright (C) 1999-2007 Martin Pool.