“FreeCiv” and its Discontents: Policy Lessons from Open Source Games: A Case Study

Full Document Available in PDF

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.[i]

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.[ii] 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.

[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.