The User Disenfranchisement Movement

"Arguing in My Spare Time" No. 2.05

by Arnold Kling

May not be redistributed commercially without the author's permission.
Index

Recently, some software development consultants with whom I work brought up the subject of "open source" software. They pointed out that some developers are willing to take lower pay in exchange for being allowed to spend a fraction of their time working on open source projects. The company gets the remaining share of the developer's time. With top-flight developers, this can be a win for the company.

("Open source," for those who are not initiated, is software where the source code is made available to the user. With ordinary proprietary software, the user only receives compiled executable files, keeping the inner logic of the software hidden. In contrast, with open source, the user can see all of the logic, and the user can copy it or modify it at will. This characteristic tends to be incompatible with selling the software, so "open source" software typically can be obtained for free.)

The consultants were suggesting that we "open source" some work that they are doing for us. They argued that what we are building involves some "bleeding edge" capabilities that have applicability far beyond our narrow requirements. The benefit of going open source is that some of the most challenging issues might be addressed by other programmers, who would be eager to extend the functionality of what we release.

I said that one of my worries was that once the consultants release the software, they will spend all of their time talking on the phone with cranky users. Many of these users would be trying to develop enhancements that would have no value to us.

Later, it occurred to me that this concern might be misplaced. With "open source" software, we do not need to be distracted by difficult users. We can give users the finger and tell them that if they don't like the software they can fix it themselves.

This is the other side of the "open source" coin. The end-user, who is the raison d'etre for the proprietary software developer, can be safely ignored by the "open source" developer. The "open source" developer has two powerful weapons to wield against the attacking user. One weapon is that the user did not pay for the software. The other weapon is that with the source code public, you can tell users that if they really want a feature or a fix they can program it themselves.

The relationship between users and developers is nearly always tense. The "Dilbert" comic strip often depicts the conflict between the marketing department and the engineering department, which is characteristic of software development within most "Dilbert sector" companies, such as banks and telecommunications firms, where the users are internal to the firm. Developers of software products also must contend with user feedback, from external users who purchase the product.

Dealing with users is difficult. They come up with requirements that wreck your underlying data model. They come up with ways of using your software that expose weakness in its architecture. Life certainly would be a lot easier for developers if they did not have users to contend with.

This leads to the revelation of what makes "open source" an alluring model for software developers. The ultimate appeal of "open source" is not the ability to overthrow Microsoft. It is not to implement some socialist utopian ideal in which idealism replaces greed. The allure of the "open source" movement is the way that it dismisses that most irksome character, the ordinary user.

With "open source" software, the only user with any influence is a user with the "right stuff" to go into the code and enhance the software. As an "open source" developer, you never have to attend meetings with corporate suits. Instead, your only communication is with an elite mailing list of co-developers. You don’t have to worry about having focus groups test the usability of your software. Your users are gear-heads who think that escape sequences constitute an intuitive interface. You don’t have to worry about a marketing department spoiling the elegance of your design by promising features that you did not anticipate.

Open source software allows developers to focus on their own ideas for software design. Accordingly, open source software is likely to be successful in environments where very few of the requirements come from technically deficient users. However, if most of the requirements come from business and consumer users, the expectation is that open source software will not win. For example, do not hold your breath waiting for an open source general ledger program to become the market leader.

By the same token, it would be surprising to see the open source browser from Netscape capture more than a small share of the market. Web browsers are being used by many of the newest and least technically sophisticated consumers in the computer market. The chances of this constituency being better served by open source software than by proprietary software are quite slim.

Today, one of the leading examples of "open source" success is the Apache web server. It fits our model only because we take it for granted that running a Web server requires considerable technical savvy. No one is going to be able to develop a proprietary Web server whose features appeal more to the cognoscenti. However, if someone were to develop a web server with enough self-configuration capability to enable an ordinary civilian to run it as easily as a spreadsheet, the glory of the "open source" web server would fade. I would not be surprised to see the paradigm of the Web server as the province of Unix geeks overthrown in the next five years. I would be more surprised if that paradigm were to persist. And when ordinary civilians run web servers, my prediction is that those servers will be proprietary.

I am not saying that "open source" is evil or wrong. What I am saying is that its popularity in the developer community may provide a misleading indication of its Darwinian fitness. Increasing the influence of technical users while taking away the leverage of non-technical users is not necessarily going to emerge as the dominant approach. Software that is developed by a process that diminishes the role of the non-technical user is going to mutate differently than software in which consumers have a say through the market or in which non-technical business executives have a say by virtue of their power in a company. A reasonable bet is that both types of software will continue to exist, since each model has advantages in different situations. What is rather implausible is a scenario in which the dominant process in software development turns out to be the one which disenfranchises the user.