| |||||||||||||
|
| |||||||||||||
The Game Theory of Open CodeThe Game Theory of Open CodePosted Jul 17, 2002 14:51 UTC (Wed) by DeletedUser2025 ((unknown), #2025)Parent article: The Game Theory of Open Code
I agree with the paper's conclusions, with one proviso. Its conclusions are limited to commercial software - software that must be sold by a company for profit. It does not look closely at software that is primarily a tool that complements companies' primary products or aids the companies' business processes. When software is a company's primary product, it must be sold for profit, and opening the code removes much of the competitive advantage the company might have. In this case, it makes no business sense whatsoever to open the code. When the software is considered a tool rather than a product, however, then opening the code can really work. Although the author glibly dismisses internal development, I believe that this is the primary area where open source will succeed. There are many companies now that are paying developers to work on open source projects - not to be able to sell the products, but to use the products as tools that complement their business processes or commercial products. Look closely at the developers involved in any major open source project, and you'll see evidence of this. Even when software is developed internally, it often meets the needs of others as well. If it's open, then it can be developed and used by everyone who has similar needs. Look at the history of Samba, for instance. It was developed to meet an internal need, and then stagnated when that need disappeared. Since Andrew had opened the source, though, development resumed as others had the same needs. Now it's very widely used, both in businesses and home networks. Even with many competing software-as-products (PathWorks, LM/X, Lan Manager for Unix), Samba became popular. The Samba example is not equivalent to the "Company C" scenario in the paper, however. Samba was not developed or released as a product. It was never expected to make a profit. Instead, it was developed as a tool, and the open code allowed everyone who had a need for the tool to improve it until it met their needs. Ultimately, I have to wonder whether the idea of software as a product will die out in the end. When open collaboration can provide effective, low-cost, customizable software (like Linux, Apache, PostgreSQL, Perl, PHP, et al.), it's hard to imagine any way that software as a product can compete. If I am right, of course, this would mean an eventual restructuring of the whole software economy, with all the related financial and political turmoil that that would entail. I think we can see the beginnings of this turmoil already, with the big push in many countries for legislation supporting proprietary software (like CBDTPA), or supporting open software. Ultimately, though, this battle will be won and lost in the trenches, by the overall utility of the software, not by legislation.
(Log in to post comments)
|
|
||||||||||||