--- "FreeCiv" and its Discontents: Policy Lessons from Open Source Games: A Case Study by Solveig Singleton The passionate and often vitriolic debate between advocates of “open source” software and “closed” or proprietary models is now drawing the attention of policy makers. Open source efforts might be entirely non-profit and informally collaborative, or undertaken by a for-profit company that charges for computing and programming-related services rather than for X units of software. By contrast, the proprietary or closed development process does not entail the public release of source code; companies using this process mostly make their money selling units of software. This paper compares computer games developed through each process, to see what public policy lessons may be learned. In 1999, computer game developer Shawn Hargreaves wrote a fascinating paper on the dearth of open source computer games. Why, he asks, were there so few original and successful open source games, as compared to proprietary games? In this paper, Hargreaves suggests that games just do not lend themselves well to open source business models such as selling services. He describes two major differences. First, few people are interested in buying “services” associated with a game they have already played. Second, a large part of game development involves drawing, not programming; and the open source movement had not evolved to support stables of artists. Nevertheless, at the time, Hargreaves remained remains hopeful that more open source games could be developed, and suggests ways in which that might be done. Let’s leap forward to 2003. Hargreaves’s description of the difficulties of developing open source games remains largely accurate. What does this mean for the open source movement and, in particular, for public policy debates surrounding the future direction of intellectual property licensing? It tells a cautionary tale for those who would prefer open source out of ideology, without attention to results. Government procurement and research funding policies should remain neutral, preferring neither proprietary nor open source licensing. Open Source Games: A Closer Look Open source games have come a long way since 1999, but sections of Hargreaves’s paper could have been written yesterday. Some games have evolved more in the “services” direction than one might expect, with (proprietary) hits like Sid Meier’s Alpha Centauri and Diablo generating multiple releases. However, in most cases, once a game is out of the box and played for a few months, users lose interest. So the “services” model still will not work well to finance games. As a result, there are a few fine open source games out there, like FreeCiv, but it is a copy of an earlier, proprietary game, Sid Meier’s Civilization, a game of rising and falling early empires. An exception with greater claims to originality is NetHack, a text-based game. But, generally, games have not been a success story for the open source community. Indrema, the company founded a few years ago as an open source competitor to Nintendo and Sega to serve as a platform for open source game development, quietly folded. There are lots of open source game development tools furthered by companies like the now bankrupt Lokibut despite its dedication Loki could not persuade publishers to try open source games. Sun also started a games group to make Java more widely useful to game developers, but has not announced plans to make open source games itself. By and large, the consensus among gamers and developers is that open source games still lag behind propriety games in originality, sophistication, and artwork; many are clones of earlier proprietary or shareware games. This situation provides some general lessons for public policy. To see this, let’s take a closer look at the problem. No one has managed to make a successful ongoing commercial venture from open source games. Games require support for substantial colonies of artists and writers working in a consistent styleand also musicians, as the pleasingly ominous classical soundtrack of Total Annihilation illustrates. The difficulties for open source development come in because the artists likely will want to be paid regular salaries. Metallica has reportedly signed a deal to record game soundtracks for Vivendi Universal, and, if the band’s attitude towards peer-to-peer file sharing is any indication, will want to be paid up front, and will not come cheap. But even after those substantial up-front expenses are paid, the game could still flop. Games, like other entertainment industry products, including movies and music, require a big up-front investment and somebody willing to take a big risk. It is very difficult to predict hits, and money lost on flops must be made up on hits. (This may help to explain why many open source games imitate earlier, successful gamesimitation minimizes the risk that all the effort will yield a flop). To generalize further, the open source business model seems to have trouble coming up with large initial investments at the cutting edge of innovation, where risks are greatest. Game development is an extreme example, but these economic factors could also play out in other contexts in which the effects are more subtle. Other applications, such as medical, tax, or translation software, might also require programmers to team up withand payother experts. The difference between games and “other” software is not a difference of kind, but of degree. Computer languages and operating systems are near the low end of the spectrum in the degree to which programmers need extensive value added up front from non-programmers, while games are near the high end. Games involve extra risk from the hit/flop economics of entertainment, but there is risk in every frontier. Finally, the lag between the development of open source games and proprietary games illustrates the relative slowness of the open source development process in completing very complex projects. It may be no accident that Linux lags behind the Mac operating system or Windows in developing consumer-friendly interfaces suitable for a mass consumer market, although the (originally proprietary) Unix model from which its overall pattern is taken goes way back. Lessons for Public Policy It should not be surprising that the open source business model has weaknesses as well as strengths. There is room in the market for a long continuum of types of intellectual property license. The English language is public domain, as are many common story lines and much creative imagerybut few good novels are. Government cannot and should not pick winners and losers in the world of technology any more than in the world of language. Policy should be neutral. The following recommendations would help keep it so. • Innovators Should Not Be Required to Make Government-Funded Software Research Open Source. Some have suggested that all government-funded software research be released as open source. Open source advocate Bruce Perens, for example, argues: “The people pay for government-funded research; its fruits should be available to all of them equally. We promote Open Source/Free Software licensing of all taxpayer-funded software and data as a means of distributing research results fairly.” The implication that open source “belongs” to the public is a peculiar one, since open source is not public domain. The open source license entails considerable obligations, the legal implications of which are sometimes unclear. For example, the GPL rather complicates the question of fair use and derivative works. (A derivative work is a work based on another work, perhaps by including a part of the original work, or transforming it somehow). Most importantly, the public would not be best served by forcing innovators to work with one model of intellectual property license. If the purpose of government research is to fund projects otherwise too risky for the private sector to fund, the researchers will need some flexibility to ensure they are rewarded for taking the risk. Privatizing revenue streams through intellectual property or other means often serves the public well. • Procurement Policies should be Neutral. In several countries, including Brazil, China, Germany, and Singapore, government procurement policies have been rewritten to require preferences for open source. Proposed legislation in Oregon and Texas seeks to direct state officials to “consider” open source against proprietary software “on a value-for-money” basis. For any given software purchase, there might well be good reasonsincluding cost, quality, standardization, and security requirements to prefer either open source or proprietary versions. Presumably, a competent software buyer can weigh all of these factors while making his decision. Note that it will not always be clear which way these concerns cut. For example, the idea that open source code is more secure than closed source code is open to question. While there are a plethora of worms and viruses directed at Windows because of the political proclivities of hackers, this problem will not affect all proprietary software and might equally affect an open source program used by a political target. A government-mandated preference for one over the other simply leaves the end user with fewer options. Where government purchasing power drives the market, it might leave all users with fewer options. Furthermore, some of the political support for building preferences for open source into the process comes from anti-Microsoft sentiment, compounded in Europe by more general anti-American sentiment. There are mutterings that should Microsoft cut prices to meet the Linux competition, it would be illegal in Europe. This does seem to be looking the gift horse of competition in the mouth. Those who absolutely cannot overcome their animus against Microsoft should remember that many other companies besides Microsoft produce proprietary software, many of which are not American. In any case, enshrining Company A versus Company B battles in general technology policy would allow a faddish tail to wag what should be a stolid working dog. Conclusion The development of exciting ideas in software is not a matter of rote. The business is, as businesses go, still very young. As the years pass, many new models of developing and licensing software products will emerge. Some day, perhaps, someone will program a “software artist” to illustrate open-source games without the present problems of collaboration and risk. Tinkerers will continue to improve closed-source programs and general development models. There is no end to this process, no inherently-for-all-time best model, just as there is no “standard issue” computer user. In view of this, governments should stay well away from procurement and funding policies that prefer one model over anotherproprietary, open-source, or anything in between. Solveig Singleton is a lawyer and Senior Policy Analyst with the Competitive Enterprise Institute’s Project on Technology and Innovation. Notes: i. The “open source” development process includes releasing the source code of the software to the public along with the software; others may tinker with and improve on the code in turn so long as they in turn release their code, a process governed by the General Public License, or GPL. ii. Shawn Hargreaves, “Playing the Open Source Game,” July 1999, http://www.talula.demon.co.uk/games.html iii. See http://www.lokigames.com/about/faq.php3 (“Will your games be open source? We would like to, but this is a tough sell to traditional publishers…”). iv. See e.g. Avatar, “Tribsoft Interview • M. Pinard,” October 1, 2001, http://www.evil3d.net/articles/ interview/tribsoft/ (quoting Tribsoft founder Mathieu Pinard: If you would see the amount of code that the games done [sic] in the last few years, I don’t think we could imagine the Open Source community putting out 5-10 complete quality games per year… It’s just no longer possible to make games in your garage that will compete against the latest closed source games.) (quoting Michael Vance of LinuxGames, “Open source games are usually cheap remakes of old arcade games…Only in very rare exceptions, such as FreeCiv, can a large group of people come together and collaboratively build a game… the splintering and fragmenting of numerous little game projects is of little surprise.”); see also comments posted in response to Matt Matthews, “The Gift of Source,” August 31, 2002, http://freshmeat.net/articles/view/543. v. Quoted in Dan Farber, “Is Linux Outgrowing Its Roots,” ZDWire, August 14, 2002, http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2877434,00.html. vi. See generally Jeff C. Dodd, Brian Martin, and Raymond T. Nimmer, “Licensing Practices in the Open Source and Free Software Communities,” paper on file with author. vii. Drew Clark, “Debate Rages Over ‘Open Source’ Federal Software Procurement,” CongressDaily A.M., May 9, 2003; see also Sasiwimon Boonruang “IBM Aims to Link Public Agencies,” Bangkok Post, April 2, 2003, http://search.bangkokpost.co.th/bkkpost/2003/apr2003/bp20030402/database/02Apr2003_data06.html. Discusses procurement policy proposal for Thailand. viii. Clark, at Ibid. ix. See K. Yatish Rajawat, “Security Issues See Governments Make a Dash for Open Source Software,” The Economic Times, November 7, 2002, http://economictimes.indiatimes.com/cms.dll/xml/uncomp/articleshow?msid=27485720. Compare Robert Lemos, “Study: Equal security in all software,” CNET News.com, June 20, 2002, http://news.com.com/2100-1001-938124.html. Describes controversial Cambridge study concluding that there is no theoretical reason that open source would be more secure. Comments following the CNET article include the observation that the usual comparison of Windows to Linux in the security debate may be misleading, as Linux’s Unix precursors and Windows arose in such different environments; a better comparison would be between Linux and Solaris; see also Ina Fried, “Security experts find open-source flaws,” CNET News.com, September 19, 2003, http://news.com.com/2100-1002-5079549.html. Quotes Dan Ingevaldson, engineering manager for Internet Security Systems in Atlanta, “"In any given year there have been just as many vulnerabilities in the open-source community as there have been with Microsoft.” x. Ralph Nader to OMB Director Mitchell E. Daniels, Jr., 4 June 2002, http://www.cptech.org/at/ms/omb4jun02ms.html. Nader letter to OMB urging government to buy open source to improve security and competition in software markets. xi. K. Yatish Rajawat, “Security Issues See Governments Make a Dash for Open Source Software.” The Economic Times, November 7, 2002. _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/)
This archive was generated by hypermail 2b30 : Tue Nov 18 2003 - 08:07:02 PST