"If you keep proving stuff that others have done, getting confidence, increasing the complexities of your solutions - for the fun of it - then one day you'll turn around and discover that nobody actually did that one! And that's the way to become a computer scientist."
Richard Feynmann.
First of all I would like to stress that the Internet can significantly reduce the costs of providing some types of software like OS, compilers or utilities. The Internet makes it possible to produce an infinite number of remotely accessible perfect copies of a computer program, multimedia presentations, or interesting e-mail discussions.
It is generally accepted that the fact that the cost of duplicating a computer program is close to zero creates important differences between computer programs and other consumer products. These differences are to a certain extent ignored or suppressed in the conventional "shrink-wrap" software distribution model. I think that the creation of a program is similar to the creation of applied theory. I would like to classify programming as a special kind, or at least a close relative, of scientific activities. The second important difference between software and other consumer products is that minor modifications are easy. Software can be more adaptable. Here again the important analogy with science holds.
In both science and programming,those involved aren't in it for the money. Most of the OSS developers are doing it to chase a dream, not to build up their bank balances. They can be motivated for a variety of reasons but simply there are many with great programming abilities that often are underutilized in their current (often corporate) environments. Some want a particular tool and found that is either unavailable or too expensive so they try to build one themselves. Again they are chasing a dream, not the competition.
Due to the Internet, it is now possible to create a virtual team for software development, parallel to the interests in science where several researchers interested in a particular phenomenon create a virtual scientific community to resolve a question or problem.
Team structure and responsibilities can be a dynamic process. Software will be produced not by an isolated person or a group of persons, but by a deeply interwoven network of actors. I would like to stress that virtual teams probably resemble historical informal communities of scientists that used hand-written letters to share achievements, ideas and criticism.
Yet little is known about how Internet-based virtual teams (IVT) really operate and what problems develop in that sort of cooperation. Some evident problems are:
* overload and subsequent burnout of leading developers due to excessive load, with significant loss of interest in a given product;
* a conservative approach to architecture (it's really difficult to change the architecture of a product after its development has started)
* e-mail based written communication to some degree tends to distort meaning and invite fights and flame wars.
There are several other visible problems with open source projects that were pointed out by others. Understanding these problems probably can help current and future open source projects. Again, I strongly believe that the problems of open source are by and large the same as those that confront academic culture and are better understood in this context. From a theoretical point of view, participants in an open source project should probably be considered as a special kind of academic workers. Solutions for typical problems developed in academic community are directly applicable to open source and its use can probably provide important benefits to the open source development model.
The financing of open source projects is very similar to the financing of applied science. Sometimes scientific research is funded indirectly, because individuals employed in a particular institution become interested in a particular phenomenon and research with existing funds. A considerable number of open source software developers work either in academic institutions or large corporations. Large corporations usually provide a very good environment for open source projects as they often contain niches where gifted developers are partially unemployed or underemployed due to various internal issues. The initial development of Unix at Bell Labs is a good example of such possibilities.
Recently several large corporations used a second avenue of financing of open source projects. When a given open source project can promote a strategically important hardware component, programmers can be assigned to it. This activity becomes a standard "loss leader". Digital contributions to Linux seems to belong to this scheme. Current Intel and IBM interest in Linux seems to fall into this category.
Linux distributors and IBM activity on Apache are examples of a third way. In these cases, companies try to improve on a product that they sell or improve their position against Microsoft. This is also very close to applied science paradigm where businesses take research results and commercialize them.
