User:Rbsuelila it3a

The Emerging Economic Paradigm of Open Source

* Bruce Perens  * Senior Research Scientist, Open Source * Cyber Security Policy Research Institute, George Washington University. * Last edited: Wed Feb 16 06:22:06 PST 2005

Abstract

Open Source developers have, perhaps without conscious intent, created a new and surprisingly successful economic paradigm for the production of software. Examining that paradigm can answer a number of important questions.

It's not immediately obvious how Open Source[1] works economically. Probably the worst consequence of this lack of understanding is that many people don't understand how Open Source could be economically sustainable, and some may even feel that its potential negative effect upon the proprietary software industry is an overall economic detriment. Fortunately, if you look more deeply into the economic function of software in general, it's easy to establish that Open Source is both sustainable and of tremendous benefit to the overall economy.

Open Source can be explained entirely within the context of conventional open-market economics. Indeed, it turns out that it has much stronger ties to the phenomenon of capitalism than you may have appreciated.

A Strong Economic Foundation In the early days of Open Source, its proponents did not fully understand its economics. Through our lack of understanding, we created the perception that Open Source's economic foundation was intangible. This led many people to feel that Open Source would not be sustainable over the long term and would be incapable of scaling to meet the market's need for new technology. It's important to correct that perception now. In The Cathedral and the Bazaar[16], Eric Raymond attempted to explain Open Source as a gift economy, a phenomenon of computer programmers having the leisure to do creative work not connected to their employment, and an artistic motivation to have their work appreciated. Raymond explains excellently how programmers behave within their own private subculture. The motivations he explored dominated during the genesis of Open Source and continue to be effective within a critically important group of Open Source contributors today.

Raymond did not attempt to explain why big companies like IBM are participating in Open Source, that had not yet started when he wrote. Open Source was just starting to attract serious attention from business, and had not yet become a significant economic phenomenon. Thus, The Cathedral and the Bazaar is not informed by the insight into Open Source's economics that is available today.

Unfortunately, many people have mistaken Raymond's early arguments as evidence of a weak economic foundation for Open Source. In Raymond's model, work is rewarded with an intangible return rather than a monetary one. Fortunately, it's easy to establish today that there is a strong monetary return for many Open Source developers. But that return is still not as direct as in proprietary software development. Thus, I'll ask you to follow a few more steps than you would in understanding the economics of proprietary software.

Efforts At Collaboration Without Open Source Licensing

Consortia used to be the standard means of collaborating between companies upon software development. Closed consortium software development has a record of titanic failures. More recently, Billion-dollar closed consortia have a record of being replaced by more successful Open Source projects. Consider Taligent and Monterey, two consortia intended to create a replacement for Unix. Linux replaced them. Consider the Common Desktop Environment project, which has been replaced by the Open Source GNOME desktop at most of the companies that supported CDE.

A few years ago, the huge agricultural corporation Cargill founded a consortium with the stated intent of providing its partners with the benefits of Open Source while also providing secrecy and sharing the benefits of the software only with consortium members. This is called a gated community. Two years later, Cargill walked away from the project it founded. A closed consortium is simply the wrong structure for the development of non-differentiating software. It makes sense to throw the doors wide open when you don't have differentiation to protect. and admit members that can make a useful contribution even when they can't pitch in funding. A consortium costs more because there are fewer members to share cost and risk than with an Open Source project, yet there's much more structure and overhead than there would be for an equivalent Open Source project. Closed consortia generally are directed through pay-for-say, while technical merit would be the case for Open Source. With pay-for-say, a member can work to the detriment of the overall project when that is to the member's advantage. Consortium product planning often devolves into irresolvable arguments among the companies, because each has a different marketing idea and marketing arguments between companies are subjective and difficult to resolve.

Given the poor history of consortium development and, in contrast, the high rate of success for large Open Source projects carried out by the same groups of companies, it seems that the fairness imposed by Open Source licensing is an essential component of effective collaboration between a large number of parties with different interests.

The Open Source Paradigm

In the Open Source paradigm, multiple entities (individuals, companies, academic institutions, others) come together to develop a software product. Generally the initial development is done by a single entity as in the in-house and contract development paradigm, and the software is released to the public as soon as it is useful to others, generally before it would be considered a finished product and thus much earlier than a retail product would be released. Once the software is useful, other entities make use of it. Only when the software becomes useful to others does the Open Source paradigm work fully, because only then will other parties have an incentive to use the software. Once they are using the software, these other parties will have an incentive to extend the software to implement additional features that are of interest to them. This extension is performed by the customer's own employees or contractors under the customer's control.

The incremental cost of adding a feature is much smaller than the cost of the entire development. Parties that create modifications have an incentive to write them in such a way that they will be accepted by the other developers on the project and will be merged into the main body of source code that is shared by all developers. If this merge does not happen, the continuing cost of maintaining the added feature will be higher, since its developers must track changes to the main source code and maintain compatibility with that changing base.

Thus, Open Source tends to foster a community of developers who make contributions to a useful product. The cost and risk of developing the product is distributed among these developers, and any combination of them can carry on the project if others leave. Distribution of cost and risk begins as soon as the project is mature enough to build a community outside of its initial developer.

Open Source is developed directly by its end-users. For example, Apache web server features are added by the companies that need those features to operate their own web sites, or sometimes by contractors working for those companies.

Is Open Source Self-Sustaining?

Many people have trouble understanding how Open Source could be self-sustaining if it does not operate according to the retail development paradigm. What pays for such software? It is funded directly or indirectly as a cost-center item by the companies that need it. Those companies need a great deal of cost-center, non-differentiating software. They are willing to invest in its creation through the Open Source paradigm because it allows them to spend less on their cost centers by distributing the cost and risk among many collaborators, and makes more efficient use of their software dollar than the retail paradigm. This is essentially the same source of funding that pays for proprietary software. It's important to remember that the software manufacturer isn't the ultimate source of funds: the customer is.