"...looking at open-source practices in the computer game community [...] what we see is something different than what's advocated in the principles of software engineering."
Free/Libre Open Source Software (F/LOSS) development practices are gaining momentum in the computer game industry. This traditionally proprietary industry is becoming more interested in the F/LOSS paradigm for developing complex software projects. Managers and developers need to understand the potential that incorporating F/LOSS practices into their proprietary production cycle offers.
Typically, proprietary and F/LOSS software development processes are compared in terms of property rights, revenue distribution and power within a network of actors. Coordination and control practices, mediating artifacts and development tools, and the interactions between the different actors involved in the development are often neglected. Proprietary and F/LOSS development differ in terms of the knowledge exchanges between the relevant actors and the different strategies employed to overcome information asymmetries. Recognizing this difference is an essential step for evaluating how proprietary, closed-source software houses can benefit by integrating various F/LOSS practices into their development agenda.
Computer Gaming and the F/LOSS Community
The interaction between F/LOSS and computer games development goes back at least ten years and can be associated with two distinct, albeit intertwined trends: i) the efforts undertaken by some large industry players to leverage user-base potential into the development of proprietary computer games; and ii) the emergence of user/developer communities pursuing independent gaming projects.
These trends originate with end users modifying the code to enhance and customize their gaming experience. Long before incorporating end users into the production cycle became a common practice, many games, such as Wolfenstein 3D, gained popularity after their formats had been reverse engineered. This unlocked the possibility for the masses to edit default specifications (such as scenarios, maps, characters, and rules of interactions), thus "modding" the game environment according to the user's preference. Some software game companies, such as id Software and Epic Games, became proactive and started to explicitly co-opt their user-bases into the production cycle by eliciting the development and sharing of user-generated content. In most cases, they deliberately opened the peripheral specifications of their gaming platforms or shared part of the code according to liberal licensing terms. Some provided specific tools such as map editors, aimed at easing the participation of technically unskilled users.
The advent of online gaming communities reinforced this tendency. Online gaming allowed individual gamers to share their interests within a community. It is through this superficial involvement that most gamers became first "modders", and, over time, outright developers. Early communities revolved around projects building upon large proprietary software, which was later released as open source. This allowed the modification and development of F/LOSS variants of proprietary versions of games. The emergence of independent open source communities developing original games has since become more frequent.
Computer gaming seems to be very popular among F/LOSS communities: as of October, 2008 the SourceForge repository shows 29,831 game projects. Software developed in these communities includes role-playing games, simulation games, Multi User Dungeons, first person shooters, arcades, and board/card/strategy games. SourceForge's activity rank shows that among the 100 most active projects, 7 belong to the category "Games/Entertainment". Almost 60% of the computer game projects have end users as their intended audience. The remaining ones are software projects such as toolkits, modeling, rendering, and animation engines--frameworks that target developers.
Nature of F/LOSS Communities
It is difficult to sketch the development cycle for the typical F/LOSS computer game project due to the highly heterogeneous nature of F/LOSS communities. While early studies have convincingly contrasted F/LOSS development with closed source models, they subsumed the existence of "a unified community with shared values, motives, and development approaches". Overall, these studies have failed to understand the nature of the processes of F/LOSS deployment, development, and implementation, as well as the contexts in which those processes occur. Recently it has been recognized that it is more fruitful to examine F/LOSS development in terms of attributes of a complex socio-technical system rather than technical enhancements. recent. This new approach focuses on the interplay between the different actors and the various artifacts for interpreting the complex nature of the socio-technical processes that occur within F/LOSS communities.
There are several artifacts in F/LOSS communities that have the "ability of connecting different social worlds and sustaining socio-technical interactions" (See the publication by the authors of the next article in this issue). This can be seen in licensing schemes, which act as mechanisms involving interested participants such as hackers from the F/LOSS community and software corporations in the OSS industry. Different kinds of licenses provide different incentives for participation in the innovation process, according to the specific business model employed by the firm. For instance, GPL-like licenses, unlike BSD-like licenses, restrict the incorporation of incremental and cumulative innovations into a proprietary product. This deters participation from firms that place a strong emphasis on direct revenues schemes, while attracting firms from complementary industries or with complementary business models.
Different licenses represent artifacts that structure activities and practices through the imposition of differing political and technical boundaries, affecting the participation of actors and the implementation of innovations. Accordingly, the free/open identity is the result of negotiation between participants in everyday interactions and practices. For instance, the decision to release code under a particular license is interpreted as the result of the participants' negotiation of the direction in which one wants the technology to evolve, the boundaries of the community to be set, and so forth.
Despite the difficulties in deriving a unified model of the development process, it is still possible to generally describe which processes and practices are popular in F/LOSS computer game projects. In doing so, we will try to highlight the major differences with the proprietary model. A typical project revolves around a community of stakeholders in which end users and developers have overlapping roles and identities. The social structure of the project is onion-like, making it possible to distinguish between different levels of involvement in the project. Central to the project are the core developers that contribute the largest part of the code and who may take part in fundamental decision making for the project, such as the design of the architecture. External layers represent a more partial involvement in the development activities and include co-developers that provide: i) patches and bug fixes; ii) localization activities; or iii) more episodic contributions of a larger piece of code. A more external layer is represented by active users that are involved in various feedback activities, such as testing and bug reporting. Usually, a fundamental role is played by the project leader--often the initiator of the project-- who is strongly involved in the development of the early releases of the software. Over time, the project leader undertakes more general activities of project coordination.
Typically, contribution efforts in a project are skewed and centralized into a very small subset of participants. This has proved particularly true for fundamental activities such as coding, suggesting the existing tension regarding the preservation of conceptual integrity and the development direction of the project. This phenomenon is less evident for less critical activities such as bug tracking and fixing, in which more man-power is always welcomed.
The overall picture is rather distant from Raymond's idea of a "great babbling bazaar of differing agendas and approaches [...] out of which a coherent and stable system could seemingly emerge only by a succession of miracles". Most of the time, contributions to the project are highly monitored and peer-reviewed by various forms of hierarchical control in order to preserve, albeit within a highly decentralized development environment, the conceptual integrity of the project.
Developing Game Software in a Fully Proprietary Environment
In order to understand the contrast between F/LOSS and proprietary game development, we describe the typical development process occurring in the game console software industry, which is normally fully proprietary from top to bottom.
Essentially, the console producer has two main sources of games for its product. It can use internal resources to both design the game and publish it. Or, approved external developers can submit project ideas to internal or independent publishers. Publishers, in turn, decide on the marketability of the proposal and whether or not to fund the project. If approved, the developer produces the game code and releases it to the publisher who sends the code to the console manufacturer. The manufacturer then gives final approval of the software project as a whole after one or more rounds of code testing--in the console market, the game needs to be released with zero-defect quality as a goal. The practice, common in the PC games market, of a rushed release that is patched with remote upgrades by the end user, has not been feasible up to the current generation of consoles. Once the release is accepted, the console manufacturer takes care of the production of the physical copies of the game. In turn, the manufacturer releases the copies of the game back to the publisher who manages the downstream relationships with distributors and retailers.
The complex interplay between these actors is usually described in terms of two kinds of exchanges. The first, direct monitoring of the output of the development and publishing cycles, is linked to the negotiating power of partners and finds its natural expression in contracts and legal agreements. The second exchange consists in the financial flows between the involved parties.
With this perspective in mind, it appears obvious that developers are marginal actors in the network of interdependencies that ultimately generate the end product, as they are completely dependent on both the console manufacturers and publishers. However, this view does not capture one of the essential ingredients of developing a successful piece of gaming software: the ability to tap strongly asymmetric sources of ideas, creativity, and technical coding expertise. With this perspective, we discover a few layers of complexity that can hardly be considered secondary to the whole process. We believe that the social role of development tools and middleware as both control tools and boundary objects between idiosyncratic domains of knowledge and ideas is key to understanding this development model.
Most projects involve the conception and development of several functional code modules that are combined in the end product. We distinguish two categories of modules: i) key modules that set the product apart from competing products and are where the developers concentrate most of their expertise; and ii) peripheral modules which complete and integrate key components and are less critical for the success of the game. Peripheral modules often rely heavily on third party development tools to port the process from the high level code produced by the creative artists within the development team into the specific, compiled code that can be run on any hardware combination. This allows developers to concentrate on the internal mechanics of the software they are producing without investing resources in researching the specific hardware architectures of each platform.
The importance of these tools in the development process cannot be overstated. According to developers, trying to interact directly with the development libraries provided by the console manufacturer has several shortcomings. First and foremost, there are problems related to the different knowledge domains that the parties control. The distance between competences is particularly relevant in the case of graphic artists, which are usually part of the peripheral development team, and the manufacturer's developers that produce the low-level libraries provided with the development kit.
This knowledge gap cannot be typically filled by most developers, hence the importance of the middleware producers. Technically savvy developers might, in principle, be able to bridge this gap. However, internal development of tools is usually economically non-viable. Thus the tendency to buy the tools on the market. The downside derives from relinquishing control to third parties of the implementation of high level ideas into working code. We need to underscore that, at least in principle, the more complex the hardware and the faster the cycles of development for these platforms, the less a developer will likely adopt a make strategy for its middleware. We believe there is a progressive loss of competence on the translation mechanisms from the high level, descriptive languages typically used by creative artists into the lower level code required by the different platforms.
A Comparison and Some Critical Remarks
Comparing proprietary and F/LOSS in terms of property rights on the software code produced can be misleading. A first useful dimension along which to compare these processes can be defined by the actors involved. In the F/LOSS development process, there is typically a good level of technical knowledge homogeneity between the core developers, content providers, or more peripheral users. User/developers are a characteristic feature of F/LOSS development, and there is no equivalent in the proprietary domain. However, these actors are severely limited from a coordination point of view, being seldom co-located and often not sharing a clearly defined production plan. In the proprietary case, we find the opposite. The actors involved in the development process do not typically suffer from coordination problems. Within the company, coordination is solved by hierarchy while inter-firm coordination is managed through a double mechanism of contracts and quality control interactions. However, knowledge quality and heterogeneity constitute the main problems. In console development, users are not considered a meaningful source of feedback and even the actors directly involved possess highly differentiated competencies, strictly associated with the phase of the development process they specialize in.
We observe the emergence of two differentiated sets of tools used by developers. In the F/LOSS world, coordination tools such as mailing lists and CVS repositories are prevalent, but software tools used to directly produce other pieces of code are seldom employed. In the proprietary console software development market, tools bridge high-level, creative software pieces, usually produced by artists or storytellers with a very shallow programming experience, and lower-level code that can be compiled on a given platform. The presence of asymmetries in knowledge domains between the different actors creates room for third parties to introduce tools that reinforce these asymmetries. If a manufacturer stops making lower level software, it will eventually lose that ability either directly, because of a lack of practice, or indirectly, by losing tech savvy personnel or failing to attract competent programmers.
In contrast with what typically happens in F/LOSS communities, proprietary developers have a limited say in the way development tools are reshaped and modified by either the console manufacturer for the inner layers of the software kit, or by the middleware producers for the outer layers that interface with the high level language. In this regard, we might add that middleware mediates between the console hardware producer and the end product software developer not merely from a technical standpoint. In fact, the ability to filter, select and scrutinize the middleware producers' work is one of the main tools that the console producer has to influence the developer's work. By contrast, F/LOSS computer gaming communities can be thought of as an archetypal instance of a user-driven or community based innovation model in which end users are viewed as a fundamental driver in the innovation generation process.
It is apparent that the interplay between property rights on the final code, coordination needs, relative heterogeneity of actors' knowledge domains and the tools they adopt is very complex. However, the analysis of this interplay is central when trying to understand new trends emerging in the proprietary software development world, which seems to be more and more bent towards capturing features typical of F/LOSS development into their production mode.
This article was adapted from Designing, Producing and Using Artifacts in the Structuration of Firm Knowledge: Evidence from Proprietary and Open Processes of Software Development. Università degli studi di Trento. DISA Technical Report, 116, 2006.
Recommended Resources
Understanding the Requirements for Developing Open Source Software Systems
Free and Open Source Development Practices in the Game Community