Linux Today: Linux News On Internet Time.

More on LinuxToday

The Problem with Proprietary Software

Aug 22, 1999, 15:39 (25 Talkback[s])
(Other stories by Peter D. Kovacs)


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame

[ The opinions expressed by authors on Linux Today are their own. They speak only for themselves and not for Linux Today. ]

Contributed by Linux Today reader Peter D. Kovacs

While doing some research for an independent study on the topic of the economic benefits of Open Source software, I discovered something quite extraordinary. It explained something so simple and so elegant that I never thought of it before. There is a real economic problem with proprietary software, not just the technical problems that you and I could easily name.

First consider that there are 2 different types of "ease-of-use". That is "ease-of-learning" and "ease-of-operation". These two are often very different beasts. Beginners want a program that is easy to learn, that is a program with "wizards", help menus and a lot of handholding. Power users are less interested in these things and are looking for easy and fast ways to get the job done. Blender, the well known 3D animation software is a good example of software that is easy-to-operate, but definitely not easy-to-learn.

When a software company is deciding how to design their software they have to take into account several things. First, what is their target market? If their target market is the casual, mainstream user then they have to weigh the costs and benefits of how they design their program. Do they design their software so that it is easy to operate, so that people who already know how to use the software can get their jobs done faster? Or do they design their software so that it is easy to learn? Since most of the cost of developing software is in the design and implementation stage, this is a major decision for any software manufacturer. Let's look at the consequences of both.

If the company designs their software so that it is easier to operate then this gives the software more value to those users that already understand how to operate the software. For those users who don't know how to operate the software, they are still faced with a substantial learning curve (i.e. a high cost of learning) before they can realize these benefits. The result: the users who already know how to operate the software (and thus, probably already own the software) are willing to pay more, because the software is worth more to them. However, those who don't understand, are not any more willing to pay for the software.

If the company designs their software so that it is easier to learn, the result is very different. The software doesn't have any more value to those who already understand how to operate the software. However these people probably already own and use the software on a regular basis. For the user who does not understand how to use the software, the software is suddenly easier to learn. The software is more valuable for them and they are more willing to pay to use the software. The result: The software manufacturer increases market share because more people can use the software now.

While this is a generalization, it holds in most cases concerning proprietary software developers. I'm sure we could all think of examples both pro and con, but for mass-market software this is pretty much the case.

Why is this a problem? Well, for those of us who take the time to learn how to use software packages the manufacturer stops caring about us. The manufacturer is more interested in users who have yet to learn his software so that he can increase his market share. If the manufacturer does still care about the power user, it is usually through a higher priced "professional" version of the software.

As we all know, open source software has a very different set of motivations and usually the opposite result occurs. As a general rule, most open source software tends to be difficult to learn, but very easy to operate once you get over the learning barrier. Whether or not this is good or bad is the subject of another essay. Needless to say, I would much rather spend a week or two learning some software and be able to use it efficiently rather than understand instantly how to use a package and have to suffer through using it.