Go To
Main
Lsd Site

The two software cultures

Alternative approaches to the software problem and its solution

Most economists have a strong preference for the first solution, but recent events in the software industry have to some extent reopened the debate. The first set of events are connected to the negative effects of proprietary software, not least software owned by Microsoft. While there clearly are many advantages of this software, the pervasive economies of scale in the software industry and the large network effects and switching costs on the user side (Shapiro and Varian: "Information Rules") promotes an extreme market dominance that appears to be extended to many vital parts of the modern economy. This is, of course, a source of concern not only for governments and the general public but especially for firms that use software and for the community of software developers.

The second set of events are related to the free and open software movement, which to some observers appear to be a viable alternative or a healthy complement to the proprietary model of software development. Based on the traditions of the original Unix world of researchers and system administrators (not least the emphasis on public availability and free modifiability of the source code that defines computer software), there has been an evolution of non-proprietary software appears to have catched up with and in some respects even surpassed the proprietary software products. While this development of e.g. the Linux operation system and related software is based on the adoption of anti-proprietary software licences (like the GNU standard licences), these licences have deliberately left room for making a profit from quality control and distribution (according to the inventor of the GNU Licence: Stallman), and these investment areas are increasingly being exploited (eg. by Redhat's Linux distribution).

While economists have recently made important advances in the understanding of the first solution to the software problem, there has hitherto been little progress with respect to the understanding of the possibilities and limitations of the second solution. The reason appears partly to be that most economists approach software development and use from the outside. This lack of interest in the details of the development of computer software (and computer hardware) is not only found in the famous controversies on lock-in issues (cf. Shapiro and Varian; Liebowitz and Margolis). Even the history-friendly model of the computer industry of Malerba, Nelson, Orsenigo and Winter seems to suggest an outsiders view-even in potential extensions. Our general purpose of the note is to enter the blackbox of software development and use.

The necessity of concept differentiation

		Users demanding
		closed-source software	open-source software
Developers of	closed-source software	(1)	(2)
	open-source software	(3)	(4)

Figure 1. Matching two types of developers and two types of users

When evaluating the effects of this system of software development and distribution, it is important to recognise that there are at least two types of software developers and two types of customers (see Figure 1). On the one hand, we have developers of closed-source software and developers of open-source software (which is at least disclosed to individual buyers). On the other hand, we have users that demand closed-source software and users that demand open-source software. Apparently the situation (case 1) with closed-source software being developed for and sold to closed-source users is perfectly satisfactory. A necessary supplement is, of course, open-source development for customers that demand open-source solutions that they can check and improve for their own purposes (case 4). However, the closed-source firms will not normally respond to the open-source demand for their software (case 2) since they are afraid that the source can be leaked to their competitors. Similarly, specialised open-source developers can licence their software to individual firms in a way which hinders any sharing of code between the customers. This licensing scheme means that they are not willing to give the code away to customers that do not represent an effective demand (case 3).

From a superficial viewpoint this division of the software market into two segments (cases 1 and 4) seems perfectly rational. However, the possibility of spillovers are not exploited and the demand for open-source software is not treated properly. Actually, the demand for open source is an indication that the buyer is both a user and a producer of software, but due to normal licence restrictions users cannot share their bug fixes and improvements with other users except, perhaps, indirectly by giving away the improvements to the seller of the software. Similarly, the buyers of closed-source software cannot benefit directly from spillover effects from other users that have access to the open-source version of the software that they use (case 2).

From the viewpoint of the dominant producers of closed-source software this situation is very beneficial, and to many other parties it have also come to be seen as the only proper way of organising software production in a market economy. However, the people who accept the system belong largely to the two poles of the closed-source software culture. There are an increasing number of dissenters that represent an alternative open-source culture with roots back to a time when the production of open-source software was often done through a collaboration of parties that were both producers and users of software, and when the source was not only open for individual firms but also for the community as a whole.

A first look at free and open-source software development

The traditional distinction between "consumer" and "producer" doesn't make all that much sense, I think. A "consumer" doesn't actually take anything away: he doesn't actually consume anything [... T]he users act as another kind of producer: they don't produce the source of the product, but they produce information about the product and valuable knowledge about how the product can be made better.

Economists have with some right wondered how the development of free and open software is actually possible-given the tendency to free riding, etc. On this background many statements of the open-source process actually sounds like nostalgia for pre-industrial modes of software production. But our main economic scepticism is normally drawn from the culture of pure producers and pure users. In the world of MS Windows there has actually been produced rather little high-quality freeware and the so-called shareware is basically a special way of distributing and selling proprietary software. In the alternative producer-user culture there has also been public domain software that has been exploited - often by hijacking it as proprietary software after minor modifications. Furthermore, Unix was after a long period where AT&T accepted its near-free use transformed back into strict proprietary software in the beginning of the 1980s.

These experiences with proprietary software and freeware led to countermeasures, the most important of which is the GNU General Public Licence (Free Software Foundation 1991) developed by Richard Stallman with the help of law professors (Stallman 1999). The purpose of the GNU GPL and other similar licences-which have not hitherto been effectively challenged-was to protect a sharing-oriented culture of software development and use. The first goal of the related development efforts was to produce an alternative to the operation system Unix, and for trademark reasons this alternative could not be called Unix. Instead the main project was called GNU, a recursive acronym which means "GNU's Not Unix".

Core tools from the producer-user culture are the many-sided editor program Emacs, the GCC compiler for the languages C and C++ (as well as Pascal, Fortran, etc.), and non-GNU tools from e.g. the Berkeley project. However, for a long time there was a crucial missing element for a freely modifiable operation system (the kernel). This long-awaited element was provided by the Linux kernel, which quickly was distributed together with the more extensive GNU tools and other elements (so the name of the Linux system would more precisely have been GNU/Linux/++). The relatively wide distribution and use of the Linux-based system has created a potential for attracting support from some of the main players in the software industry (not only the weakened Netscape but also Sun, IBM and Intel) and this success has lead some participants in the process to try to generalise the concepts of Free Software and the GNU General Public Licence to Open Source Software including more than the GNU GPL.

There are obviously many motivations behind the thousands of developers of free and open software. These motives include the joy of programming and sharing, the wish to detach knowledge bases and careers from a lock-in to proprietary software, and the reputation among the peers that in many ways can be capitalised. However, the most important explanation is that free software developers are the superusers of their software and their modifications are meant to increase their own productivity in the use of the software.

The need for sharing of improvements is largely due to the fact that software modification and maintenance are very hard and bug-ridden. If they give their modifications away, then superusers have the advantage that others will try out the code, Often they will have a feedback, but even continued one-sided requests are a good sign of the quality of the software. The next level of software sharing is to participate in a collaborative, Internet-based project where each participant can specialise in what is of most concern to him or her and at the same time obtain improvements for other parts of the program. This is an informal way of implementing Adam Smith's and Ricardo's principles of division of labour according to absolute and comparative advantages. However, there is a need of coordination of the efforts of the specialised contributors, and this task is often left to a respected individual like Linus Torvalds. To the extent that all the development is covered by the GNU GPL, then it is impossible for an individual developer later to draw out his or her contribution. Of course, this model of cooperation presupposes among other things that the contributors are not direct competitors or that the project is of minor and more-or-less symmetric importance in the competition. But this situation is actually the norm rather than the exception in most of producer-user-based software development and use. This fact very much helps to explain the statements by free software gurus like Torvalds, Stallman and many others.

Evolutionary economic simulation between the two software cultures

The simulation-oriented researcher may react to the difficulties in at least two major ways that have close similarities to the strategies of the software developing communities at large. The first strategy is to keep the source code private or only to disclose it to a few trusted helpers. According to this strategy the simulation model should exploited in research papers that emphasise the obtained results and describes the model in general mathematical terms-preferably omitting core tricks of the computer implementation of the model. Additionally, the model could be distributed as a closed-source program so that other researchers and students can make sensitivity tests and apply the model to parameter settings that they are particularly interested in. The second strategy is to distribute the source code and the full documentation of the model together with accounts for the results and, perhaps, compiled versions of the model. In this case the users of the model are not only able to check the simulation results but also the implementation of the model. Furthermore, their corrections are not limited to alternative parameter settings; they can also start changing the basic structure of the model - provided that they have an adequate compiler and the necessary software libraries.P> Since the two strategies for distributing simulation models and their results closely resemble the two strategies depicted in Figure 1, the same type of reactions can be expected from economists. We tend to see Prisoner's Dilemma games and Free Rider games among the developers of simulation models. To avoid getting cheated we have to go for the suboptimal solution. But why is the non-cooperative strategy suboptiomal? Basically because it requires a lot of duplication of work, promotes sloppy programming of simulation models, and leads to a general scepticism against the use of simulation models as a core method of understanding complex systems. Furthermore, a long period of simulation work according to the closed-source method is very difficult to overcome. Even if the simulation model developers found a way of ensuring cooperation, they have large switching costs since their closed source is often badly constructed and characterised by bugs and quick hacks that emerge when software is produced under narrow deadlines and with no intention of being read by other researchers.

The historical chance of changing the situation for simulation model development has emerged because of the recent success of the free and open software movement. Actually, all the tools needed for advanced simulation model development are part of the standard distribution of Linux systems (and Unix systems), and these tools have also been ported to the different versions of MS Windows and the Macintosh OS. In this situation superusers will already have switched-or tend to switch-to GNU/Linux, while researchers that are less intensively engaged in simulation work will stick to Windows but still be able to run and test simulation models with software that is generally distributed under the open-source licences like the GNU GPL. Since software like simulation models that build on the GNU licence also have to be covered by the same licence, there is much pressure towards cooperative behaviour. At present the best way of ensuring the intellectual rights over some types of simulation models may actually be to make them public. The spillover effects between the different models tend to increase the speed of improvement and to increase the general reputation of the work.

The background of the Laboratory for Simulation Development

The intended role of the Lsd project can most easily be understood in relation to the Nelson and Winter tradition of evolutionary economic modelling and simulation. This tradition has roots in the relationship between economic research and Artificial Intelligence at Carnegie-Mellon. Thanks to Herbert Simon this research was closely connected to the frontiers of computer science-to which he especially contributed in the late 1950s and the early 1960s. So when Simon and Cyert and March started to talk about heuristic search and satisficing behaviour, they were on secure ground. Seen in relation to computer languages, their task was to translate the concepts of decision making into procedures or subroutines, i.e. subprograms that can be repeated over and over again. This exercise paid off quite well, but still it was far from transforming general economic theory. The reason was that economic theory is about agents who not only compute but also interact.

During the 1970s Nelson and Winter made major steps forward because they had a clear idea of how the computational procedures of economic agents change in a population of firms. Their explanation of this change is based on the evolutionary mechanisms of intertemporal inheritance, innovation and selection. It was obvious that to explore the patterns and problems of evolutionary processes, it was necessary to make computer simulations of them. Therefore, Nelson and Winter (together with a few PhD students) made their models and computer simulations of economic growth and industrial dynamics. These models have to some extent defined a trajectory of further modelling and simulation on the conditions of R&D as a determinant of industrial concentration, dynamic competition in alternative technological regimes, the relationship between innovators and imitators, etc. - see e.g. Silverberg, Dosi, and Orsenigo, Chiaromonte and Dosi, Silverberg and Verspagen, Kwasnicki, Malerba et al. A variant of the Nelson and Winter models has also had some influence in promoting evolutionary growth modelling and simulation (Silverberg and Verspagen).

These results may seem quite nice, but much more could have been obtained if a more productive software culture had emerged. The basic problem for the Nelson and Winter tradition is, in our opinion, that it has not yet been able to recreate the cumulative process of software development and use that to some extent existed in the 1970s and early 1980s (cf. the above mentioned series of papers). The reason is not only the turbulent development of hardware and software but also that software developers have had a marginal role in the research projects. Therefore, there has not yet been built a community of software developers and users with a pressure for coordination with respect to operation systems and languages, rules of documentation, sharing of programming know-how and source code, etc. Instead most projects start from scratch with respect to the development and use of simulation models. As a consequence we see an evolution of evolutionary modelling and simulation that is characterised by huge inefficiencies and high barriers to entry.

To change the rules of the game we suggest the development of an academic Internet-based exchange of auxiliary software and implemented simulation models under the GNU General Public Licence. This licence implies that receivers of software can freely use and modify it for their own purposes. However, if they distribute derived software, then they have to to do in an open-source form, and the derived software has to be covered by the GNU GPL. This implies a feedback to the original developer, but more importantly it implies a spillover to the whole community of developers and users of simulation models.

The problem with these suggestions of rules of the game is that they will only have beneficial effects in the long run if the community that follows the rules reaches a critical mass. Since evolutionary economic simulation is a small and fragmented activity, this critical mass is not easily obtained. The potential role of the Laboratory for Simulation Development is to function as an integrator between existing groups and to create a relatively easy mode of entry for new modellers. This means e.g. that Lsd has to embrace the two software cultures in a way that makes it relatively easy to move between them. To simplify the related discussion we shall assume only two types of users of Lsd: (1) developers that demand open-source software that helps them to do their job and (2) simple users that just want to run a compiled simulation model (and are not aware of the advantages of also having the source code).

Designing Lsd