The transaction-based pricing trend [for software packages]

There are two major reasons that pricing of user licenses for software has been a continual struggle: (1) software doesn't wear out-throwing suspicion on depreciation-based structures-and (2) the cost of replication is infinitesimal-raising questions about unit pricing. The problems of pricing grow in direct proportion to the anticipated number of users per license. With the trend towards object-oriented programming, it may be time to move towards a new regimen that more closely aligns the price of software with the continuing benefits that users derive. What if each object included an embedded pricing function? The pricing function would set the price that the designer would pay the object's author. Each time the program was licensed to a user, the designer would receive an invoice that was automatically generated by the object. This permits the author to post the object in its entirety within an electronic catalog and wait for the royalty checks to arrive. The embedded pricing function presents several problems. First and foremost, it presupposes that the user is going to pay a flat fee for using the program. This supposition is based on the premise that all users are alike or so nearly alike that a single pricing scheme could be implemented. To avoid this problem, the price users are charged for the program must be directly tied to the benefits they derive. Each time the program completes an activity, the pricing function would automatically bill the user for a transactional fee in much the same way the designer is billed for using the object