Software Pricing

by Philip Greenspun

Note that a marginally more coherent version of this article is included in Chapter 15 of Database Backed Web Sites.

Site Home : Research : One Article


We software developers live in a pre-industrial age. We don't build on each other's work, we reinvent the wheel over and over again -- and the bumps in the wheel. Ultimately, it is the user who gets the stuffing beaten out of him.

It is the way that software is sold that keeps software development mired in the 1950s. Software is put into packages and sold like tables or chairs. That's great because we have a highly efficient distribution and retail system for tables and chairs and because we've been buying things like tables and chairs for centuries. It would all work out beautifully for everyone if only tables and chairs needed periodic upgrades, if tables and chairs required documentation and support, if tables and chairs could be downloaded over networks, if users developed significant investments in the interfaces of tables and chairs, and if it cost $30 million to develop a slightly better table or chair from scratch.

Look at the choices that current software pricing forces people to make.

Johnny the user

Johnny the user is a university student. He wants to use Adobe PhotoShop for a class project and has a Macintosh on the Internet in his dorm room. He can buy PhotoShop for $500, he can steal it from a friend, or he can drive to Kinko's to rent a Macintosh for a few hours.

Suppose that Johnny buys PhotoShop. Adobe gets $500 and is happy. Johnny gets manuals and support and he's working efficiently. Johnny doesn't have to drive anywhere so society doesn't suffer from increased pollution and traffic congestion. Unfortunately, probably not too many students are happy about paying $500 for software that they're only going to use for a day or two. Also, when Johnny next wants to use the software, he'll probably find that the version he has no longer runs with Apple's new operating system, or that Apple has gone belly-up and his version doesn't run on his new Windows NT machine, or that the instructor wants him to use a program feature that is only in the latest version of PhotoShop.

Let's be realistic. Johnny probably isn't going to buy PhotoShop. He's going to steal it from Adobe by borrowing the CD-ROM from his friend's friend. He'll spend his $500 on a Spring Break trip to Florida. Unfortunately for Johnny, PhotoShop is almost impossible to use without the manuals. Johnny drives to the bookstore and spends $30 on a "I stole the program and now I need a book on how to use it" book. Johnny wastes some time; Adobe gets no money; society has to breathe Johnny's exhaust fumes and wait behind his jalopy at intersections.

If Johnny is remarkably honest, he may go to Kinko's and rent a Macintosh running PhotoShop. This is great except that the network was supposed to free users from having to physically move themselves around. Johnny is inconvenienced and society is inconvenienced by the externalities of his driving.

Amanda the User Interface Programmer

Amanda is writing some user interface code for an innovative new spreadsheet program. She wants it to appeal to the users of Microsoft Excel and Lotus 1-2-3 but knows that they have spent years learning the user interface quirks of those programs. Amanda has to choose between copying the user interface and spending 10 years in federal court or making her new program work in a gratuitously different manner (in which case each user has to spend several days relearning commands that they already knew in their old programs).

Joey the Image Editor Programmer

Joey wants to make a nice program for quickly converting all the images on a PhotoCD. Adobe PhotoShop does 99% of what his program needs to do. Unfortunately, lacking that last 1%, PhotoShop is useless for the task at hand. Adobe had no incentive to make the pieces of PhotoShop callable by other programs so Joey has to start from scratch or abandone his project. Should Joey succeed, his program will contain duplicates of code in PhotoShop. Joey's software, though, will have bugs that Adobe stamped out in 1991. It will ultimately be the user who is pushing the restart button on his Macintosh and losing work.

Adobe the Software Publisher

Adobe wants to maximize its revenue under the "tables and chairs" software vending model. It will do this by keeping manuals and documentation out of the hands of users who don't pay, e.g., by not putting full documentation up on the Web. Adobe will withold support from users who stole the binary. Adobe will sue companies who copy the PhotoShop user interface. Adobe will not share its internal program design with anyone.

Choices Summary

Selling software like tables and chairs forces users to make a buy/steal choice with a threshold of $500. It forces thousands of confusing new user interfaces into the marketplace every year. It forces programmers to start from scratch if they are to market anything at all.

A Better Way

Suppose that users paid $x/year to a licensing consortium for the right to use any software that they wished. Their computer somehow kept track of whose instructions they were actually executing and filed a report once a month to the licensing consortium. Based on those reports, the licensing consortium would apportion their revenues to the actual software publishers.

Let's revisit the same people under the new model...

Johnny the user

Johnny can decide whether to (1) pay his $x/year and get everything or (2) buy a few important packages under the tables and chairs model and steal/rent everything else. Assuming he pays the $x/year, Johnny may legally run any software that he finds useful. It gets delivered via the Internet to his machine along with any documentation and support that he may need.

Amanda the User Interface Programmer

Amanda still wants her users to be able to employ the familiar Lotus user interface. It is now in Lotus's interest to tell other programmers how to call their user interface code. Every time a Lotus menu is displayed or command is run, Lotus is going to get some extra money from the licensing consortium. Amanda's company will get paid when her new spreadsheet core program is executing. Lotus and Amanda's company are sharing revenue and it is in both of their interests to make the user productive.

Joey the Image Editor Programmer

Adobe now has an incentive to document the internal workings of PhotoShop. Joey can tap into these and add his 1%. Because PhotoShop is an old and well-debugged program, the user gets a much more reliable product. Joey only gets 1% of the revenue derived from any user's session with "his" software, but he only did 1% of the work so he can move on to other projects. Furthermore, because he doesn't have to come up with an attractive physical package, his cost of entering the software market is considerably reduced.

Adobe the Software Publisher

Adobe's main goal now is to get as many people as possible to run PhotoShop and for as long as possible. All the manuals immediately go up on the Web, possibly open only to people who are licensing consortium subscribers. Making telephone and email support fast and effective becomes a priority because Adobe doesn't want any user to give up on PhotoShop and run Doom instead. Hardcopy manuals are mailed out free or at nominal cost.

Adobe sponsors conferences to help other software developers call PhotoShop's internals. Adobe will not file any look and feel lawsuits because they're getting paid every time someone uses their user interface code.

New World Order

Five years after the software licensing consortium is in place, the world looks very different. Fewer programs are written from the ground up, fewer users stab away cluelessly at stolen programs for which they lack documentation, fewer look and feel lawsuits are filed, fewer bugs are created. Roughly the same amount of money is flowing to the software publishing industry, but the industry has better information about who its customers are and how useful they find their products.

A less radical approach

Renting software rather than the physical machines on which it is installed would achieve some of the same goals as blanket licensing and metering. Certainly a casual user would prefer to spend $1/hour trying out PhotoShop than $500 for "the package" and then $100/year for updates. Adobe would then have many of the same incentives to make documentation and support readily available.

However, renting software would not solve the deeper problem created by software developers standing on each other's toes rather than each other's shoulders.

Privacy

I probably wouldn't want my employer to know that I spent 95% of my time running Netscape and Doom when I was supposed to be using Word and Excel. One needs to use public-key encryption to make it impossible for

Conclusion

Selling software like tables and chairs worked pretty well when the personal computer was young. However, it doesn't make sense in a networked world.

Acknowledgements

The good ideas in this paper are due to Steve Ward. The bad ideas are mine.
Copyright 1996 Philip Greenspun


philg@mit.edu

Reader's Comments

Don't you think Java is the solution?

-- Vincent --, February 17, 1997
Certainly Java would be helpful, but Java is only a technology that would help achieve the goal that Phil has described. First you have to build the business model that is envisioned here. That's the hard part, the technology to drive it is the easy part.

-- Justin Loeber, November 6, 1997
There's just one small problem with creating a time-based system for distributing revenue: Everyone will want to have their code executed for the most time. What's a really easy way to have your code executed longer? Make it really inefficient. You want to open a file? Let's catalogue your entire hard disk and find all possible places that file might have moved to, checking by file name, creation date and file size, and then look to see that it was in its original place after all (well, naturally that's ridiculous, but you get the point). What this would lead to is user interfaces, like Microsoft's Developer Studio, that require 100% of my PII 266 CPU just to move the mouse around the screen. All incentive to be efficient is lost, and people will write more and more slow, bulky code: they will turn into Microsoft Clones. This can't be good for anyone.

-- Timothy Terriberry, May 31, 1998
For the answer to the questions raised in this article, go to http://gimp.org

The GIMP is a free "open source" alternative to Photoshop. It's fully extensible, fully featured, and fully supported.

This is not Windows shareware. This is Open Source software for Linux.

-- pehr anderson, June 10, 1998

find the idea very interesting and a step in the correct direction though many faults to iron out. This idea would entitle Microsoft to an even large portion of the pie. Because most of the time that windows is running it is executing Microsoft code. Even when it is idle. Microsoft also write most of the library source that Visual C++ programs call. Though on the other side this idea may also lend to people creating alternative user interface other than Windows. For example: instead of my code calling a useless Windows API functions to get a edit box I would call another companys functions to get a very powerful edit box (than will do spell checking etc.). A great idea that at the moment has lots of bug. Edison did not get the light bulb right the first time.

-- Adrian Jones, August 25, 1998
About Timothy Terriberry's comment, the user would presumably be able to choose which components to install. Given this choice, users would select the fastest software with the best features. They do this now, only with a less granular system of buying whole software packages instead of just features they need. Also of course there are marketing considerations that will always exist (though they are evolving a bit with the web), and compatibility issues that the proposed system of buying features could help eliminate.

-- Sean Foy, May 16, 1999
Of course, all of this will be obsolete in a few years. Software is not going to be sold nor rented anymore. It is going to be free, as in freedom, and will come accompanied by source code.

Software will not be sold anymore. *Service* will be sold, and tech support, and customization.

Bye bye BillG, LarryE, and all the others who won't get it.

-- Nicola Larosa, June 24, 1999

This theory (free software), much more in vogue now, than when the page was written in '96 or so has some good sides, in fact Phil is using this model for his software, (ACS, etc.), and as far as I can tell, building a business by means of service contracts.

Note that a free software world implies different goals for software developers -- the money must now be made in service and support. Developers walk a fine line -- the software must be good enough to encourage people to use it, but not so good that they obsolete themselves.

The ACS walks this line, in my opinion -- it's not a turnkey solution. It's not even that easy to determine the download site for the software. (http://software.arsdigita.com) Once installed, it does everything, and the kitchen sink, and it does it fairly quickly. I really like it, by the way.

But, Ars Digita does not have the same constraints that a commercial software company does: they code toward two principles: 1) Makes sense to them, (that is developer user interface) 2) Desirable Feature list, (that is, the world will want to use, and install it)

These are nice principles if you're a service company; Your software is easy to install (for you), and companies want it. Additionally, your average MIS person who can read and understand the feature list will be totally incapable of configuring anything remotely like Oracle, which means that once a company has signed on to the idea of your software, they will have to pay you to get it, after all.

All this is not to say Phil is not doing good things with Ars, or even that he was not benevolent to release the code to the ACS. The ACS has definitely driven interest in AOLserver, as far as I can tell from the mailing list, and Phil has saved me personally hundreds of thousands of dollars in developer fees. Way to go Phil!!

It's only to make the point that free software is not viable in a utopian sense. There are new economic rules attached to free software, something that recent converts to the Open Source Movement (TM) [some sarcasm here] don't seem to understand. Every company is out to make money, by default. While programmers are human, software will cost. It's just a question of how you will pay.

-- Peter Vessenes, July 30, 1999

some of the ideas in this page reminded me of the OpenDoc project at Apple, which seemed to be quite a good idea. the trick (as far as i rememeber) was not to work with programs but with documents, and use small & simple 'editor' modules (or 'viewers' if you didn't want to edit the contents) that were called when you clicked on each part of them. i find myself sometimes working on projects that have multiple programs involved, and this would be a great way of working. i.e: the first section has some text & tables describing the idea, next section some math and programming code, then another with some images, etc. and the 'modules' would be much more cheaper than a full program, less disk-space-hungry, easier to update and develop, etc. add to this open-source and you get quite near the ideal.

-- Santiago Peressn, January 10, 2000
I was reminded of Philip's essay while reading yet another article bemoaning the state of commercial software.

In the main, Philip's ideas are generally sound, and are predictive of the direction applications software will be forced to take in the long run. However, his essay misstates a key point: commercial software is not sold like tables and chairs. If you've ever read the contract of adhesion that accompanies any commercial software (called, tellingly, the User's -- not Owner's -- Agreement), you know this is true.

When you buy a table or a chair, you own it outright and are permitted to do just about anything you want with it. When you "buy" Microsoft Word, you are only buying the right to use the software -- and then only in carefully prescribed ways. You do not "own" the software in any meaningful way. Moreover, violation of the Agreement terminates your dearly-purchased rights, and subjects you to civil and possibly criminal liability. Pottery Barn should be so lucky.

Thus software makers are already in the business of selling licenses. And this is what makes Philip's ideas seem so prophetic: with the speed and power of the Internet, software companies clearly see the day coming when they will be free of the tyranny of table-and-chair marketing and distribution. After all, what rational seller would choose the inefficiencies of packaging and supporting SkunkWare 2000 -- itself guaranteed to be outdated long before it reaches your local software retail outlet -- when he could simply upload it to the network and wait for his Users to come to him, like flies to a spider?

-- Max Ernst, March 21, 2000

Update: GIMP is available for Win32 here

-- Daniel Bodart, March 23, 2000
I wonder if the concept of "Web services" will provide at least part of the solution. These are "programs" written for the Web that can communicate with other similar "programs" using a well-defined protocol. For example, Microsoft has a protocol called SOAP (Simple Object Access Protocol) that uses XML over HTTP to make method calls to any other Web service on the Internet and receive results.

So I could write a component that (say) provides a sophisticated calendar service, and you could use it by calling its published method interface (API, if you will) and using its results to build something at your Web site.

An ASP-type organization could tie several of these Web services together and form a larger entity, paying royalties based on usage to each of the Web services' authors.

I'm sure there are (and will be) alternatives to SOAP; I'm just using it here as an example of what could be done.

-- Kuryan (Obi) Thomas, June 9, 2000

I have had the same thought about music. At some point the music companies are going to do an end run around Napster and put encrypted music on the Internet. Suppose you buy a CD, hate it, and never listen to it again. You just wasted $15. It would be better to pay $30 a month and obtain the right to listen to any music. Artists would be paid based what people listened to most. Congress might have to grant a partial anti-trust exemption to enable music companies to set this up.

-- Michael Alexander, July 24, 2000
Just like me, I believe a lot that is in the computer industry has felt the inherent problem of the current business model of the software industry deeply. Since I started learning computers, I feel more and more that the software industry is actually a service industry, that is we should be charged per usage rather than per package. However, both business and technical problems exist; the business people do not want invest yet another big money to revolutionize the distribution network to support the new business model, the network bandwidth is not yet there earlier. However, I believe that the world is converging to what is optium, the ASP model arises, which I believe is what we are after. The challenge now is probably the change of our mindset to adopt this model... Also the open source wave now is also leading us to the next generation of computing business. Just give it more time, as changing people's mindset is probably the biggest, and most time consuming part of the whole revolution!

-- Kai Yuen Kiang, January 25, 2001

Rajesh K. , MCA, PSG Tech. India


Halo Sir!

I am deeply impressed by the solution you have given. I used argue with both my classmates and my Teachers that changes in Technology or Modelling techniques are not going to help us solve this buggy situation BUT ONLY a proper Business model of "Live and Let Live" can.

I think the model of Sharewares constitute a good/BETTER approach. We do pay our bills for telephone and Electrocity - WHY NOT for Software. Big Corporates can Lease others can rent. Also there is lot of stress in programming only in IT education ( and Stress comes naturally in programming). I think we have to learn building with Bricks rather than Start making bricks of our own - Less costlier and More Efficient.

Forming consortiums will never help until the academia and PLs change thier attitudes.

Any way I love Computers!

Thanx for the oppurtunity to express!!
BEST WISHES
RAJESH K MCA
PSG College of Technology
India.


-- Rajesh Kalyanaraman, March 16, 2001

RAJESH K:

> I think the model of Sharewares constitute a good/BETTER approach.
> We do pay our bills for telephone and Electrocity - WHY NOT for Software.

We've tried to do it. In practice it is a chore to pay your shareware or rental bills for each little piece of software you use. You become dependent on any vendor that implements a proprietary data format or protocol (a la MS Office), and the prices for serious users become outrageous very quickly.

Nothing short of freedom will ever do.



-- Leandro Dutra, March 27, 2001
The New World Order
Six Years In

The Software consortium is bought by venture capitalists. Little Davey comes up with a new software idea, but since Vickey the Venture Capitalist didn't like him in undergraduate education, she blocks his sfotware from entering the consortium. Davey has no way to sell his software, except on the open market, but no one buys from there anymore. or Maybe Davey is writing software that competes with Minisoft, the largest and most powerful software company ever created. Minisoft's director decides that he will withdraw his software from the consortium unless Davey is prevented from partaking in the consortium...
Lastly, since no one is building software from the ground up, very little innovation is made. While every single program shares an easy to use interface, no one risks creating a new, possibly better interface since they don't need to.

-- Ian MacAllen, April 20, 2001
I've spent a bit of time this year thinking about how silly the current software pricing models are. Seems Phillip was 5 years ahead of me, judging from the date on this article. It strikes me that the tables and chairs model will not survive another decade, and something along these lines would make a good replacement.

In fact, the more I think about it, the more I like it. I think it's a better model for some situations than the current open source licences, because there's more motivation for maintaining, documenting, and improving the code. There would be a much bigger focus on maximising reusability, getting the interface/API right, and good documentation, which really can't be a bad thing. And it's probably more acceptable to the average company than the standard open source revenue models.

Anyhow, I'm not sure if Ian was speaking seriously or merely applying a topical ArsDigita analogy (for those of you reading this in a few years time, check the ArsDigita legal history...), but in response, I would say:

1) The consortium could be constructed as a democratic alliance of the software developers, rather than a separate entity vulnerable to VC shennanagins. And I see little motivation for the consortium having barriers to entry.

2) While it's likely that good code and good interfaces would get used over and over again, people have different ideas about what counts as good. Also, if writing your own improved version of someone else's module meant that (a) you got a bigger share of the profits from people using your program, and (b) you got profits from people deciding to use Ian's improved widget rather than Adobe's tired old one, then I would say there was plenty of motivation to write new code. Adobe might even choose to adopt your widget to improve Photoshop (if it was only 0.03% of the code, it would hardly cost them anything) in which case you'd get a share of every sale from then on!

Finally, I think the user costs would have to be fixed by how much code was used, rather than a set price per month, otherwise people would just get together and buy a single "account" between them. This model already implies keeping track of how much code the users are actually running, but on a usage pricing system there would have to be some very clever code to prevent hackers from faking their usage stats.

Oh well, enough dreaming. Back to work :-)

-- Seth Wagoner, May 5, 2001

Software was never meant to be horribly expensive and thereby out of bounds of simple folks with needs. Bill G went horribly wrong thinking no one will buy his software and hiked his price and lo! behold he has started a trend and he and rest of the software people are suddenly the richest people in the world. I cannot understand how a MS Window can cost approx 200USD time and time again and still be crap and yet people get richer. Perhaps software should be like music cd's, cheap enough for every one to buy and thereby generate enough volume for the company to make a decent profit.

-- Barfungpa tops, August 4, 2001

I think the previous comment about the 'radical approach' encouraginginefficient code is the tip of the iceberg. In fact, I think the sampling/feedbackpart of the proposed scheme would have to be very carefully thought out in lightof the existence of Byzanine, profit-seeking people.

Lets look at some of the ways various measurement systems could be subverted:

I think it is fair to generalise and say that any system attempting to meter outa resource in a 'fair' manner will always fail by having its choice mechanism exploited!

One way out is to have the user decide; perhaps they rank their installed softwareevery month to say how much that software is contributing to their total benefit.This though would become a pain in the neck to do, and I'm sure trojans and free-holiday-offer-if-you-rank-our-software-number-1 schemes would arise.Also advertising.

Returning to the automatic measurement system, to explore that a bit,I notice we're always talking about positively-reinforced systems.My guess is that (like stable systems) you instead insert some kind of negativefeedback flow, e.g. like the least money is delivered to the software with the highest penalty; penalities being something else that's measured.

Obviously some penalty schemes could just be converted into positives so theyhave to be avoided:

Off the top of my head, I can't think of a workable penalty measurement.Maybe this is just totally wrong.

oh bugger its 3am zzzz

-- David L, February 10, 2002

What about all us poor buggers who are going to be stuck with slow connections for quite a while? Ok for all you cable guys living in the US. Most of the world doesn't have the required infastruction and will not have it for quite a number of years at a decent price. Not mention latency and performance problems even on cable that will occur. Yes, you have it cached locally then obviously, security problems. Yes, I'm being a pessimest(Unusual for me), Sorry.

-- Christian Sherriff, March 4, 2002
The problem is that you are introducing a middle man, a consortium, which adds a cost on the supply chain:
programmer - middleman - consumer
The more efficient economic model would be for the programmer to charge the consumer directly for services. I think we are starting to see that today with the growth of web based applications. With this, the user can be charged directly for services, and this could be based upon whatever sales model the programmer decides is best.
I probably have a slightly biased opinion towards this as I run two systems based upon this model, a flash card system and a collaborative system where primarily I make a little tiny amount of money on ads and small services, and spread them along a large user base. This has worked out fairly well, since there are no transaction costs for the user, and the only application they have to keep up to date is their browser.

-- Rob Kohr, February 27, 2006
I think the original text is kind of old now, nevertheless as rob has pointed having a middle man is not going to be effective on the long run, due to practical reasons. That's where FOSS is going to play a major role in the scenario phill explained.

With FOSS nothing will come without a cost but,it's gauranteed to be cost effective compared to proprietary software.

-- Kosala Atapattu, October 2, 2006

Wow this was absolutely brilliant to read. Some great predictions here.

Now about 8 years after the last comment and 18 years! after the post was written we have mature Software as a Service (SaaS) in the Cloud!

-- Rohan Kamalia, March 24, 2014

Add a comment | Add a link