Politech: Solveig Singleton on open source, games, and public policy

[Declan McCullagh <declan () well com>]

---

"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 Loki­but 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 style­and 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 
games­imitation 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 with­and pay­other 
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 
imagery­but 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 reasons­including 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 
another­proprietary, 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/)