Etiel Petrinja
email: etiel.petrinja@unibz.it

Alberto Sillitti
email: alberto.sillitti@unibz.it

Giancarlo Succi
email: giancarlo.succi@unibz.it

Adoption of OSS Development Practices by the Software Industry: A Survey

The paper presents a survey of aspects related to the adoption of Open Source Software by the software industry. The aim of this study was to collect data related to practices and elements in the development process of companies that influence the trust in the quality of the product by potential adopters. The work is part of the research done inside the QualiPSo project and was carried out using a qualitative study based on a structured questionnaire focused on perceptions of experts and development practices used by companies involved in the Open Source Software industry. The results of the survey confirm intuitive concerns related to the adoption of Open Source Software as: the selection of the license, the quality issues addressed, and the development process tasks inside Open Source Software projects. The study uncovered specific aspects related to trust and trustworthiness of the Open Source Software development process that we did not find in previous studies as: the standards implemented by the OSS project, the project's roadmap is respected, and the communication channels that are available.

Introduction

The Open Source Software (OSS) industry is continuously growing and it is influencing also practices that are part of the traditional software development process [START_REF] Capiluppi | First International Workshop on Emerging Trends in FLOSS Research and Development[END_REF]17,20]. OSS development is supported by software companies and OSS projects are not interesting only to enthusiasts and volunteers [START_REF] Dueñas | Apache and Eclipse: Comparing Open Source Project Incubators[END_REF]. Similar initiatives are not limited to the software area alone, but they are encompassing also areas as book publishing, scientific publishing, and other familiar areas [START_REF] Goth | Sprinting toward Open Source Development[END_REF]. The benefits that OSS brings are an interesting research area [16] and many studies have been conducted in the past decade. An important research initiative is focused in the definition of measures that based on empirical values characterise the OSS, and allow standard measurement of its quality. The grouping of these measures in a form of an assessment methodology provides to the software industry a convenient tool that can be used before adopting a new OSS product.

The number of OSS projects implementing similar functions is large. The quality of those projects depend on the development process used inside the project and the skills of participants in the community that are participating to the development. Companies interested in reusing OSS components should be able to select the OSS product that best suits their needs. This is usually a challenging task that requires assessment tools and skills but it also takes time to be performed. Several assessment methods for OSS have been proposed and new ones are under development; some of the already available are:

• the QualiPSo OpenSource Maturity Model (OMM) (2009) [14],

• the Open Business Readiness Rating (OpenBRR) (2005) [24],

• the Open Source Maturity Model (OSMM) from Cap Gemini (2003) [START_REF] Duijnhouwer | Capgemini Expert Letter Open Source Maturity Model[END_REF],

• the Open Source Maturity Model (OSMM) from Navica (2004) [12],

• the Open Business Quality Rating (Open BQR) (2007) [21], and • the Methodology of Qualification and Selection of Open Source software (QSOS) (2004) [START_REF] Origin | Method for Qualification and Selection of Open Source Software (QSOS)[END_REF].

The aim of the study was to understand which are the key OSS development activities perceived as important by experts from the software industry. Those activities will influence the creation of a new assessment method that is addressing the OSS development process. The methods listed (except QualiPSo OMM) are focused in the OSS product and not in the development process. The development process has an important role when deciding to adopt an OSS product. Product characteristics alone are usually not a sufficient indicator of quality for stakeholders that are interested to actively participate in the OSS project. Specially for software integrators that plan to create a new software product reusing OSS components.

Adoption and integration of a OSS product is strongly related to further modifications of the product, therefore a good interaction with the community developing the product is essential. Process aspects have to be identified and assessed; the best known process assessment methodology in the software domain is the Capability Maturity Model Integrated (CMM/CMMI) [START_REF] Humphrey | Characterizing the software process: a maturity framework[END_REF]19]. However, the CMMI is not appropriate for assessing OSS projects. It is complex, it does not focus on single projects but on the software company, and it does not address OSS specific aspects as: contribution level, reputation of the project, licenses used, etc. The aim of the new assessment methodology is to propose a CMMI-like method able to address OSS specific aspects. Software companies are knowledgeable in CMMI, therefore we planed to leverage on this skills of experts working in software companies.

The development of a OSS development process assessment methodology is one of the results of the EU funded project QualiPSo [15]. The basic task for defining the methodology was to conduct the survey, presented in this paper, and collect data related to the practices and trust elements in the development process of surveyed companies. Even if a higher quality of OSS products in comparison with closed source software products was demonstrated in several case studies [START_REF] Dibona | Open Sources: Voices from the Open Source Revolution[END_REF][START_REF] Birendra | Quality and Profits Under Open Source Versus Closed Source[END_REF]11], OSS is generally still perceived of low quality. The trustworthiness of OSS is an aspect we consider critical for a larger usage of OSS.

We included in our study more than 50 professionals working for 20 European software companies including: Siemens (Germany), Engineering Ingegneria Informatica (Italy), Bull (France), Atos (Spain), IBM, Mandriva (France), Thales (France), and others. A similar survey focused on OSS communities was published in 2008 [13].

The results of the study provided a set of best practices related to the OSS development process and a set of elements that bring trust to participants of the survey. Trustworthy elements are elements that when addressed during the OSS development process, guarantee to developers, users, and software integrators that the project is of good quality.

The paper is organized as follows: in Section 2 we describe the survey with the presentation of the methodology used. Section 3 is dedicated to the results of the survey, highlighting key aspects of the OSS development process. The last section contains conclusions and indications of possible future work.

The survey

The European software industry is interested in OSS because it is an expanding market alternative to the closed source software market where non-EU, mainly US, software companies have a strong position [START_REF] Burzynski | The internationalization of the software market: opportunities and challenges for brazilian companies[END_REF]. OSS is an area where European software companies can offer their expertise and implement new business models [22]. The study presented in this paper is part of a large research conducted with the aim to improve the adoption of OSS by the software industry.

Interviews with European software companies

The qualitative study gives an overview of OSS related development practices used in European software companies, the adoption of new OSS development procedures, and the usage of OSS products. Interviewees were asked which factors influence their perception of the quality of the OSS process and what is their opinion about a wider adoption of OSS in the company. The questionnaire was developed by defining specific topics and identifying possible questions. We decided which questions are important for the OSS development process and which aspects characteristics of the final OSS product should be also collected to understand better the development process. The complete questionnaire is available as part of the results of the QualiPSo project at www.qualipso.org.

Methodology

The design of the research was based on the approach proposed by Silverman [18]. The approach requires the design of a structured and formal research involving two basic and partially related decisions:

• The method, that is, whether performing a quantitative or a qualitative investigation.

• The methodology and the specific technique for gathering data (with an interview, a questionnaire, with observations, etc.).

The decision is based on the evaluation of major goals of the research and the type of information required. As far as opinions on OSS products were concerned, our goal was to investigate those OSS product factors that influence the trustworthiness of the OSS development process. Following the approach proposed by Silverman, this kind of information requires a qualitative investigation. Our research methodology was based on a semi-structured questionnaire where some of the questions were closed (offering a limited list of possible answers) and other questions were open allowing to provide any answer from the interviewee. The questionnaire has been filled in during face-to-face or telephone interviews. The interviewees were employees of European software companies. The first set of interviewees was selected by the companies that were involved in the QualiPSo project (19 partners) [15]. An additional set of companies was selected based on their involvement in OSS projects. The total number of interviewees was 53.

During the second phase, we conducted a quantitative study by creating a shorter questionnaire on key elements and submitting the questionnaire to mailing lists, conferences, and using it during personal meetings. We designed a web version of the questionnaire and we collected most of the answers through a web form. The second questionnaire reused many questions from the first version and additionally (randomly) listed answers obtained during the first iteration of the research. We closed most of the questions (providing possible answers) aiming to identify the priority of answers compared between them. We excluded outliers and incomplete answers from the first iteration. The results of the on-line questionnaire are just one part of the results of the study presented in this paper. We compared the results obtained with personal interviews and results obtained with the survey; the syntheses of the results of the two iterations is presented in this paper.

The overall structure of the research was based on the Goal Question Metric (GQM) approach [2]:

1.Goal: Identify trust related issues in the adoption of OSS in the European software industry.

2.Question:

The questionnaire includes 53 questions with additional sub-questions. They were developed to ask the interviewee on specific goal related issues.

3.Metric: Metrics about the level of adoption and the trust in OSS process are selected to be able to measure answers to questions defined in the precedent step.

The final form of the questionnaire was achieved through several iterations of drafts. The questionnaire was divided into sections covering different topics related to the OSS development process. The three main sections focused on:

1.trust and quality related aspects; 2.stakeholders related aspects as the roles and responsibilities used inside the development process; and 3.aspects related to the technology used.

The data gathering process was organized as follows:

• The respondents were contacted to determine their general interest in the study.

• The questionnaire was sent to the respondents to verify the actual availability.

• Data were collected by personal or telephone interviews in English.

• The results of the interviews were recorded and the interviewees were asked for a final check.

The majority of interviews was conducted at the interweave working place. We travelled to meet the majority of interviewees. Only in few cases the interview was done through a conference call. The duration of the interviews was not specially recorded and varied between different interviews. However the interviews lasted approximately one hour. We were not able to measure the duration of the surveys performed on the web. However, we have tested the survey questionnaire with colleagues before publishing it on the web and the mailing lists and the time necessary to complete the questionnaire varied between thirty and forty-five minutes. There were always two interviewers present during interviews. One was usually reading questions and the other was writing the answers. Two persons were able to collect more detailed responses from the interviewed person and limited the duration of interviews. Soon after the end of the interview, the answers recorded in the protocol were sent back to the interviewed person. Only upon a positive feedback from the interviewee, the questionnaire was considered accepted and the data were processed.

Participants were guaranteed anonymity and the information reported was reviewed so that no single person or company can be identified. The number of individuals interviewed from each company varied from one up to six employees per company. The people interviewed were developers and managers in companies included in the study.

Results

We present the results about three types of aspects in separate subsections, to summarize the results of: quality related aspects, OSS development stakeholder related aspects, and technology aspects. Some of the 53 collected questionnaires were not filled completely; however, the key questions that were focused on topics presented in this paper were filled in more than 90% of the questionnaires. During the second phase of the study, we obtained 56 filled questionnaires. The subjects involved in the two phases were different, nevertheless the results of the second phase confirmed the results obtained during the first phase.

Trust and quality related aspects

The interviewees spontaneously mentioned various factors that influence the trust they have in the OSS process. The most frequently mentioned criteria were:

• the availability and the quality of the documentation about the OSS product, • the number of downloads and the number of potential users of the OSS product, and • open standards used for the development of the product.

A list of the most important characteristics and the percentage of respondents that think that a characteristic influences trust is presented in Fig. 1. For example, the popularity of the product was listed as important by 81% of the respondents. Identified characteristics confirm the results of previous studies; however, some unexpected aspects have been reported. Interviewers asked the respondents only what they consider important when they think about trustworthiness of the OSS development process. This focus allowed to discover some aspects that are considered important specially for the trustworthiness. Some additional interesting aspects recorded were: the importance of companies and the industry that is sponsoring the OSS project, the presence of an independent body that checks the product and the development process used. We were especially interested in the perception of the importance of the development process. Half of the surveyed participants were working for companies that are concerned about the development process. The other half reported that they are almost completely uninterested in the process and the interest was merely focused on the characteristics of the OSS product. The companies that just wanted to use the product were in general not interested in the development process. On contrary, the companies that wish to further develop the product were interested also in the development process.

The cost of the license was one of the characteristics addressed specifically by a question in our questionnaire. We considered this factor important because it is one of the most influential aspect emerging from the results of previous OSS studies [23]. Interviewees stressed the importance of the license cost of OSS in comparison with proprietary software. An additional question was if the total cost of the ownership (TCO) affects the importance of the cost of the license; and the answer was unexpectedly negative. The absence of an initial license cost allows users to test and experiment code modifications; this is a positive aspect of OSS in comparison with proprietary software. The absence of license costs contributes strongly to an easier and larger adoption of OSS products. Subsequent training and maintenance costs encountered are considered less important than the benefits users have at the beginning of the use of a OSS product. The survey confirmed that testing is an important part of the adoption process of a new OSS product. Surveyed companies test OSS using manual and automatic tests. Manual tests are usually unstructured and often done ad-hoc. Automatic tests are structured and standardized. Details of the testing procedure depends on the importance the new OSS product has for the company.

Despite the availability of some assessment methodologies as QSOS and OpenBRR, the surveyed companies usually use their own set of criteria to test the quality of a OSS product. Many of these criteria are already part of the listed methodologies but the methodologies are not yet well established and known by the industry and their use is still limited.

Aspects that companies consider important when testing OSS vary considerably across companies and the summary described in this paper presents characteristics mentioned by a large percentage of interviewees. The testing process is usually done informally by developers of the company (80%). Testing is also done by the OSS community that is using the product and that reports bugs and proposes new features and improvements. OSS communities are a good short-cut for companies when they need to choose which OSS product to adopt, as communities can provide volunteers for the testing process. If they need additional test results related to each company's specific requirements, they conduct in-house tests carried on either by a group of specialized developers, by the project manager, or sometimes also by external teams.

Two frequently mentioned characteristics considered important for assessing the quality of OSS are: results of in-house or external tests of the product, and the size of the user community. Both were mentioned by all the participants to the study (as evident from Fig. 2). The number of users that already use a OSS product is an indication of the variability of opinions and comments about the product that can offer insight in aspects of the OSS project. Another important aspect is the type of standards implemented inside the OSS project (73%). This aspect is often related to technologies, programming languages, and frameworks used and supported by projects. Documentation is also considered important by three-fourths of the companies. Satisfaction of user expectations reported on forums and mailing lists by the community of users of the product are considered important by half of the surveyed interviewees. Just half of the interviewees consider important the process followed (either the Rational Unified Process -RUP, a process assessed according to the Capability Maturity Model -CMM, an IT Infrastructure Library -ITIL benchmarked process or others) for the development of the product. Less frequently mentioned aspects are: the availability and use of measures such as bug reports, the size of the components, the certification of the quality of the product by a third-party company, and others. The answers are graphically presented in Fig. 2.

Aspects related to stakeholders

Roles and responsibilities of people inside companies participating in our research play an important role when considering the adoption and development of OSS.

Surveyed companies use OSS products but in some cases they also develop OSS. There is a correlation between the development of OSS and its usage. Part of the participants only use OSS products, however the interviewees that participate in the development of OSS products usually also use the product. This behaviour was expected and it was reported in previous studies. We have asked how are the OSS projects managed inside the companies and which are the responsibilities related to OSS. For most of the companies, OSS development is only one of their development activities. The majority of companies involved in the survey, is still exploring the OSS development and their current OSS development approach is a mix set of activities typical of a proprietary software development and of OSS development (as the one adopted by OSS communities as Linux Kernel, Apache, and others). The number of developers and the size of OSS communities formed by the companies is still rather small. They are typically composed of up to 100 developers and contributors and onl y rarely reach 1000 contributors. A limited OSS development approach is evident from the responsibilities that members of the OSS community have. Important decisions and responsibilities are assigned to employees of the company. This way, companies still maintain the leading role and decide the development directions of the OSS project. This way companies lose important advantages that a more democratic OSS development process offers, such as a larger amount of source code contributions, the development based on meritocracy, and better motivation for the involvement in the OSS development process.

As for the roles and responsibilities, also the definition of requirements and implementation of new features is influenced strongly by the business strategy of the companies. After the implementation of critical features that are imposed by architectural and design decisions; key contributors of new features are customers of surveyed companies. More than 80% of interviewees consider more important the suggestions from their regular customers than suggestions coming from the OSS community. Decisions of which features are implemented first are usually taken by the coordinator of the project that is almost always an employee of the company.

Technology aspects

The technology used inside OSS projects is an aspect that strongly influences the whole OSS project and specially the development process. Interviewees answered in details on questions related to technology related aspects and showed a high interest on these characteristics. We dedicate this subsection to answers of interviewees to some strongly perceived technology aspects.

Surveyed companies use different operating systems for developing OSS; Linux is the most frequently used. Some companies also use the Windows operating system and sometimes Solaris, in addition to Linux. Fig. 3 presents the percentage of use of each operating system.

characteristics.

The large majority of the OSS projects developed by the companies, create and maintain the documentation for the OSS product. More complex and thoroughly developed projects have a diversified documentation for different types of stakeholders, e.g., the user's manual, the developer's manual, and the manual for administration of the OSS product. Since high quality documentation of OSS projects was identified as one of the key trustworthy elements, companies invest a considerable effort to create the documentation of their projects. The documentation is stored in formats types as: readme files, wikis, web pages, user guides, as comments to the source code, and in other forms. Developers are responsible to write the documentation related to their part of the project. Only occasionally the documentation is written by specialized in-house or external groups of experts.

Conclusions

The study presented in this paper has confirmed the interest of European software companies in OSS in general and also in the OSS development process. The majority of the surveyed companies are trying to participate on the OSS market starting with small, exploration projects and then incrementally extending them. The majority of companies participating in the survey started mixed proprietary-OSS projects. OSS products developed are free to be used and improved by everybody and the source code is available; the development process, the management responsibilities and evolution of the project are, however, coordinated by the company that started the project. The quality of the OSS development process and the lack of a high quality assessment process, that can be used to measure characteristics of the development process, is one of the main limitation to a wider diffusion of OSS. The key issue is related to the perceived quality of OSS and the trust people have in its development process. The survey was focused on the usage of OSS in the European software industry and the results sheds some light on this growing market.

Interviewees report that companies, that are releasing some of the management and planning aspects of the project to the OSS community, are observing growing contributions from volunteers. Benefits provided by OSS communities allow faster improvement of OSS projects. Interviewees reported a perceivable improvement of the business in companies that have started to use OSS and that have decided to use the OSS development process for some of their projects. The key result of the study was a set of characteristics that are considered important for improving the quality of the OSS development process. The most important one are: the quality of the documentation, the number of the users of the OSS product, and standards implemented by the OSS project. These characteristics were used for the definition of an assessment methodology that is now in the process of validation and refinement.

Fig. 1 .

 1 Fig. 1. Trustworthy factors related to the OSS development process.

Fig. 2 .

 2 Fig. 2. Criteria for assessing the quality of OSS.

The most frequently used programming language is Java which is regularly used by all the companies. C++ is the second most frequently used programming language. The surveyed companies use also other languages as: C, Python, PHP, Perl, some proprietary domain languages, JavaScript, MS proposed languages, and others. Languages and technologies usually influence the development methodologies used and also the efficiency of specific development activities. The frequent use of Java and Linux confirmed our expectations related to the language and the platform used by OSS communities. Fig. 4 presents the frequency of the use of programming languages. The surveyed companies that develop OSS, do it incrementally (80%) with small exploration projects, starting with some basic features and releasing the first versions of the product. New features are added later according to new requirements collected first by the customers and then by the community. Such development is similar to the process followed in OSS communities that are not strongly influenced by software companies. The results of the survey also show that in some cases, the core part of the project is entirely developed and implemented inside the company and only then it is disclosed to the community and opened for new suggestions.

Two important aspects of OSS projects that are supported by the surveyed companies are: the use of open standards, and the modularization of the system architecture. From the survey, we could not identify a OSS development strategy that was used by the majority of companies. The methodology usually depends on the type of the company, the OSS project, the technology used, and several other


Walt Scacchi
email: wscacchi@ics.uci.edu

Modding as an Open Source Approach to Extending Computer Game Systems

This paper examines what is known so far about the role of open source software development within the world of game mods and modding practices. Game modding has become a leading method for developing games by customizing or creating OSS extensions to game software in general, and to proprietary closed source software games in particular. What, why, and how OSS and CSS come together within an application system is the subject for this study. The research method is observational and qualitative, so as to highlight current practices and issues that can be associated with software engineering and game studies foundations. Numerous examples of different game mods and modding practices are identified throughout.

Introduction

User modified computer games, hereafter game mods, are a leading form of user-led innovation in game design and game play experience. But modded games are not standalone systems, as they require the user to have an originally acquired or licensed copy of the unmodded game software.

Modding, the practice and process of developing game mods, is an approach to end-user game software engineering [START_REF] Burnett | End-User Software Engineering[END_REF] that establishes both social and technical knowledge for how to innovate by resting control over game design from their original developers. At least four types of game mods can be observed: user interface customization; game conversions; machinima; and hacking closed game systems. Each supports different kinds of open source software (OSS) extension to the base game or game run-time environment. Game modding tools and support environments that support the creation of such extensions also merit attention. Furthermore, OSS game extensions are commonly applied to either proprietary, closed source software (CSS) games, or to OSS games, but generally more so to CSS games. Why this is so also merits attention. Subsequently, we conceive of game mods as covering customizations, tailorings, remixes, or reconfigurations of game embodiments, whether in the form of game content, software, or hardware denoting our space of interest.

The most direct way to become a game mod developer (a game modder) is through self-tutoring and self-organizing practices. Modding is a form of learninglearning how to mod, learning to be a game developer, learning to become a game content/software developer, learning computer game science outside or inside an academic setting, and more [START_REF] El-Nasr | Learning Through Game Modding[END_REF][START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF]. Modding is also a practice for learning how to work with others, especially on large, complex games/mods. Mod team efforts may also self organize around emergent software development project leaders or -want to be‖ (W.T.B.) leaders, as seen for example in the Planeshift (http://www.planeshift.it/) OSS massively multiplayer online role-playing game (MMORPG) development and modding project [START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF].

Game mods, modding practices, and modders are in many ways quite similar to their counterparts in the world of OSS development, even though they often seemingly isolated to those unaware of game software development. Modding is increasingly a part of mainstream technology development culture and practice, and especially so for games, but also for hardware-centered activities like automobile or personal computer customization. Modders are players of the games they reconfigure, just as OSS developers are also users of the systems they develop. There is no systematic distinction between developers and users in these communities, other than there are many users/players that may contribute little beyond their usage, word of mouth they share with others, and their demand for more such systems. At OSS portals like SourceForge.net, the domain of -Games‖ is the second most popular project category with nearly 42K active projects, or 20% of all projects 1 . These projects develop either OSS-based games, game engines, or game development tools/SDKs, and all of the top 50 projects have each logged more than 1M downloads. So the intersection of games and OSS covers a substantial sociotechnical plane, as game modding and traditional OSS development are participatory, user-led modes of system development that rely on continual replenishment of new participants joining and migrating through project efforts, as well as new additions or modifications of content, functionality and end-user experience [START_REF] Scacchi | Understanding the Requirements for Developing Open Source Software[END_REF][START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF][START_REF] Scacchi | Free/Open Source Software Development: Recent Research Results and Emerging Opportunities[END_REF]. Modding and OSS projects are in many ways experiments to prototype alternative visions of what innovative systems might be in the near future, and so both are widely embraced and practiced primarily as a means for learning about new technologies, new system capabilities, new working relationships with potentially unfamiliar teammates from other cultures, and more [cf. 21 ].

Consequently, game modding appears to be (a) emerging as a leading method for developing or customizing game software; (b) primarily reliant of the development and use of OSS extensions the ways and means for game modding; and (c) overlapping a large community of OSS projects that develop computer game software and tools that has had comparatively little study. As such, the research questions that follow then are why do these conditions exist, how have they emerged, and how are they put into practice in different game modding efforts.

This paper seeks to examine what is known so far about game mods and modding practices. The research method in this study is observational and qualitative. It seeks to snapshot and highlight current practices that can be associated with software engineering and game studies, as well as how these practice may be applied in CSS versus OSS game modding. Numerous examples of different game mods and modding practices are identified throughout to help establish an empirically grounded baseline of observations, from which further studies can build or refute. Furthermore, the four types of game mods and modding practices identified in this paper have been employed first-hand in game development projects led or produced by the author. Such observation can subsequently serve as a basis for further empirical study and technology development that ties together computer games, OSSD, software engineering, and game studies [START_REF] Scacchi | Understanding the Requirements for Developing Open Source Software[END_REF][START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF][START_REF] Scacchi | Free/Open Source Software Development: Recent Research Results and Emerging Opportunities[END_REF][START_REF] Scacchi | Game-Based Virtual Worlds as Decentralized Virtual Activity Systems[END_REF].

Related Research

Two domains of research inform the study here: software extension within the field of software engineering, and modding as cultural practice within game studies. Each is addressed in turn.

Software Extension

Game mods embody different techniques and mechanisms for software extension. However, the description of game mods and modding is often absent of its logical roots or connections back to software engineering. As suggested, mods are extensions to existing game software systems, so it is appropriate to review what we already know about software extensions and extensibility.

Parnas [START_REF] Parnas | Designing Software for Ease of Extension and Contraction[END_REF] provides an early notion of software extension as an expression of modular software design. Accordingly, modular systems are those whose components can be added, removed, or updated while satisfying the original system functional requirements. Such concepts in turn were integrated into software architectural design language descriptions and configuration management tools [START_REF] Narayanaswamy | Maintaining Evolving Configurations of Large Software Systems[END_REF]. But reliance on explicit software architecture descriptions is not readily found in either conventional game or mod development. Hentonnen and colleagues [START_REF] Henttonen | Integrability and Extensibility Evaluation in Software Architectural Models-A case study[END_REF] examine how software plug-ins support architectural extension, while Leveque, et al. [START_REF] Leveque | Extensibility and Modularity for Model-Driven Engineering Environments[END_REF] investigate how extension mechanisms like views and model-based systems support extension, also at the architectural level. Last, the modern Web architecture is itself designed according to principles of extensibility through open APIs, migration across software versions, network data content/hypertext transfer protocols, and representational state transfer [START_REF] Fielding | Principled Design of the Modern Web Architecture[END_REF]. Mod-friendly networked multiplayer games often take advantage of these capabilities.

Elsewhere, Batory and associates [START_REF] Batory | Achieving extensibility through product lines and domain specific languages: a case study[END_REF] describe how domain-specific languages (for scripting) and software product lines support software extension, and now such techniques are used in games that are open for modding. Next, OSS development as a complementary approach to software engineering, relies on OSS code and associated online artifacts that are open for extension through modification and redistribution of their source representations [START_REF] Scacchi | Free/Open Source Software Development: Recent Research Results and Emerging Opportunities[END_REF]. Finally, other techniques to extend the functionality or operation of an existing CSS system may include unauthorized modifications that might go beyond what the end-user license agreement might allow, and so appear to fall outside of what software engineering might anticipate or encourage. These include extensions via hacking methods like code injection or hooking, whose purpose is to gain/redirect control of normal program flow through overloading or intercepting system function calls, or provide a hidden layer of interpretation, which allow for -man in the middle‖ interventions. So software extensions and extensibility is a foundational concept in software engineering, as well as foundational to the development of game mods. However, the logical connections and common/uncommon legacy of game modding, OSS development, and software engineering remain under specified, which this paper begins to address.

Modding as Cultural Practice

Game modding is a practice for user content creation that creates/networks not only game mods but game modders. Within anthropological, behavioral, and sociological studies of computer game play, modding has been studied as an emerging cultural practice that mediates both game play and player interaction with other players (including the game's developers). In some early studies, modding has been designated as a form of -playbour‖ whereby player actions to create game extensions for use by other players is observed as a form of unpaid (or underpaid) labor that primarily benefits the financial and property interests of game development corporations or hegemonic publishers [START_REF] Kücklich | Precarious playbour: Modders and the digital games industry[END_REF][START_REF] Postigo | Of mods and modders: Chasing down the value of fan-based digital game modifications[END_REF][START_REF] Yee | The Labor of Fun: How Video Games Blur the Boundaries of Work and Play[END_REF].

Game modding also modifies or transforms game play experience, since what is play and what is experience(d) are culturally situated. Examples of this may include single player games being modded into multi-player games. So the experience of single player versus the game environment is transformed into other situations including player versus player, multi-player group play, or team versus team play. Similarly, the modding of games to enable experiences other than expected game play, like using a modded game for storytelling or film-making experiences is also a practice of growing interest, with the emergence of a distinguishable community of gamer-filmmakers who produce machinima (described later) as either a literary medium, or an art form [START_REF] Kelland | From Game Mod to Low-Budget Film: The Evolution of Machinima[END_REF][START_REF]The Machinima Reader[END_REF][START_REF] Marino | 3D Game-Based Filmmaking: The Art of Machinima[END_REF].

Other studies have observed that user/modders also benefit from modding as a way to achieve a sense of creative ownership and meaning in the modded games they share and play with others [START_REF] Postigo | Video Game Appropriation through Modifications: Attitudes Concerning Intellectual Property among Modders and Fans[END_REF][START_REF] Scacchi | Understanding the Requirements for Developing Open Source Software[END_REF][START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF][START_REF] Sotamaa | When the Game Is Not Enough: Motivations and Practices Among Computer Game Modding Culture[END_REF], and that game mods and modding practices become central elements in what constitutes play with and through games [START_REF] Taylor | The Assemblage of Play[END_REF]. Finally, as already observed, OSS project portals like SourceForge host thousands of OSS game development projects that develop and deploy role-playing games (4.3K projects), simulation-based games (2.6K), board games (2.3K), side-scrolling/arcade games (2K), turn-taking strategy games (1.7K), multi-user dungeons or text-based adventure/virtual worlds (1.6K), first-person shooters (1.6K), MMORPG (0.6K) and more. So development of OSS games and related game development tools can be recognized as a central element in the cultural world of computer games and game development, as well as the world of OSS development [START_REF] Scacchi | Understanding the Requirements for Developing Open Source Software[END_REF][START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF][START_REF] Scacchi | Free/Open Source Software Development: Recent Research Results and Emerging Opportunities[END_REF].

Four Types of Game Mods

At least four types of game mods are realized through OSS development practices. These include (i) user interface customizations and agents, (ii) game conversions, (iii) machinima, and (iv) hacking closed source game systems. Each is examined in turned, and each is facilitated (or prohibited) according to its copyright license.

User Interface Customizations and Agents

User interfaces to games embody the practice and experience of interfacing users (game players) to both the game system and the play experience designed by the game's developers. Game developers act to constrain and govern what users can do, and what kinds of experience they can realize. Some users in turn seek to achieve a form of competitive advantage during game play by modding the user interface software for their game, when so enabled by game developers. These mods acquire or reveal additional information that users believe will help their play performance and experience. User interface add-ons subsequently act as the medium through which game development studios support game product customization, which is a strategy for increasing end-user satisfaction and thus the likelihood of product success [START_REF] Burnett | End-User Software Engineering[END_REF].

Three kinds of user interface customizations can be observed. First and most common, is the player's ability to select, attire or accessorize a player's in-game identity. Second, is for players to customize the color palette and representational framing borders of the their game display within the human-computer interface, much like what can also be done with Web browsers (e.g, Firefox 4 -personas‖ and -themes‖) and other end-user software applications. Third, are user interface add-on modules that modify the player's in-game information management dashboard, but do not modify the underlying game play rules or functions. These add-ons provide additional information about game play state that may enhance the game play experience, as well as increasing a player's sense of immersion or omniscience within the game world through perceptual expansion. This in turn enables awareness of game events not visible in the player's pre-existing in-game view. Furthermore, some add-on facilities (e.g., those available with the proprietary World of Warcraft MMORPG, scripted in the LUA language) accommodate the creation of automated agent scripts that can read/parse data streamed to the UI within an existing or other add-on dashboard component, and then provide some additional value-added play experience, such as sending out messages or status reports to other players automatically. Such add-on agents thus modify or reconfigure the end-user play experience, rather than the core functionality or play mechanics available to all other of the game's players. Consequently, the first two kinds of customizations result from meta-data selections within parametric system functions, while the third represents a traditional kind of user-created modular extension; one that does not affect the preexisting game's functional requirements, nor one included in the operational source code base during subsequent system builds or releases, unless they do alter the software's requirements (e.g., by introducing a new security vulnerability or exploit that must be subsequently prevented).

Game Conversions

Game conversion mods are perhaps the most common form of game mods. Most such conversions are partial, in that they add or modify: (a) in-game characters including user-controlled character appearance or capabilities, opponent bots, cheat bots, and non-player characters; (b) play objects like weapons, potions, spells, and other resources; (c) play levels, zones, maps, terrains, or landscapes; (d) game rules; or (e) play mechanics. Some more ambitious modders go as far as to accomplish (f) total conversions that create entirely new games from existing games of a kind not easily determined from the originalgame. For example, one of the most widely distributed and played total game conversions is the Counter-Strike (CS) mod of the Half-Life (HL) first-person action game from Valve Software. As the success of the CS mod gave rise to millions of players preferring to play the mod over the original HL game, then other modders began to access the CS mod to further convert in part or full, to the point that Valve Software modified its game development and distribution business model to embrace game modding as part of the game play experience that is available to players who acquire a licensed copy of the HL product family. Valve has since marketed a number of CS variants that have sold over 10M copies as of 2008, thus denoting the most successful game conversion mod, as well as the most lucrative in terms of subsequent retail sales derived from a game mod.

Another example is found in games converted to serve a purpose other than entertainment, such as the development and use of games for science, technology, and engineering applications. For instance, the FabLab game [START_REF] Scacchi | Game-Based Virtual Worlds as Decentralized Virtual Activity Systems[END_REF] is a conversion of the Unreal Tournament 2007 retail game, from a first-person shooter to a simulator for training semiconductor manufacturing technicians in diagnosing and treating potentially hazardous materials spills in a cleanroom environment. This conversion is not readily anticipated by knowledge of the Unreal games or underlying game engine, though it maintains operational compatibility with the Unreal game itself. So game conversions can re-purpose the look, feel, and intent of a game across application domains, while maintaining a common software product line

[cf. 3].
Finally, it is common practice that the underlying game engine has one set of license terms and conditions to protect original work (e.g., no redistribution), while game mod can have a different set of terms and conditions as a derived work (e.g., redistribution allowed only for a game mod, but not for sale). In this regard, software licenses embody the business model that the game development studio or publisher seeks to embrace, rather than just a set of property rights and constraints. For example, in Aion, an MMORPG from South Korean game studio NCSoft, no user created mods or user interface add-ons are allowed. Attempting to incorporate such changes would conflict with its EULA and subsequently put such user-modders at risk of losing their access to networked Aion multi-player game play. In contrast, the MMORPG World of Warcraft allows for UI customization mods and add-ons only, but no other game conversions, no reverse engineering of the game engine, and no activity intended to bypass WoW's encryption mechanisms. And, in one more variation, for games like Unreal Tournament, Half-Life, NeverWinterNights, Civilization and many others, the EULAs encourage modding and the free redistribution of mods without fee to others who must have a licensed copy of the proprietary CSS game, but not allowing reverse engineering or redistribution of the CSS game engine required to run the OSS mods. This restriction in turns helps game companies realize the benefit of increased game sales by players who want to play with known mods, rather than with the un-modded game as sold at retail. Mods thus help improve games software sales, revenue, and profits for the game development studio, publisher, and retailer, as well as enable new modes of game play, learning, and skill development for game modders.

Machinima

Machinima can be viewed as the product of modding efforts that intend to modify the visual replay of game usage sessions. Machinima employ computer games as their creative media, such that these new media are mobilized for some other purpose (e.g., creating online cinema or interactive art exhibition). Machinima focuses attention to playing and replaying a game for the purpose of story telling, movie making, or retelling of daunting or high efficiency game play/usage experience [START_REF]The Machinima Reader[END_REF][START_REF] Marino | 3D Game-Based Filmmaking: The Art of Machinima[END_REF]. Machinima is a form of modding the experience of playing a specific game, by recording its visual play session history, so as to achieve some other ends beyond the enjoyment (or frustration) of game play. These play-session histories can then be further modded via video editing or remixing with other media (e.g., adding music) to better enable cinematic storytelling or creative performance documentation. Machinima is a kind of play/usage history process re-enactment [cf. 18] whose purpose may be documentary (replaying what the player saw or experienced during a play session) or cinematic (creatively steering a play session so as to manifest observable play process enactments that can be edited and remixed off-line to visually tell a story). Machinima mods are thus a kind of extension of game software use experience that is not bound to the architecture of the underlying game software system, except for how the game facilitates a user's ability to structure and manipulate emergent game play to realize a desired play process enactment history.

Hacking Closed Game Systems

Hacking a closed game system is a practice whose purpose oftentimes seems to be in direct challenge to the authority of commercial game developers that represent large, global corporate interests. Hacking proprietary game software is often focused not so much on how to improve competitive advantage in multi-player game play, but instead is focused on expanding the range of experiences that users may encounter through use of alternative technologies [START_REF] Huang | Hacking the Xbox: An Introduction to Reverse Engineering[END_REF][START_REF] Scacchi | Free/Open Source Software Development Practices in the Game Community[END_REF]. For example, Huang's [START_REF] Huang | Hacking the Xbox: An Introduction to Reverse Engineering[END_REF] study instructs readers in the practice of -reverse engineering‖ as a hacking strategy to understand both how a game platform was designed and how it operates in fine detail. This in turn enables reconfiguration of new innovative modifications or original platform designs, such as installing and running a Linux operating system (instead of Microsoft's proprietary CSS offering). While many game developers seek to protect their intellectual property (IP) from reverse engineering through end-user license agreements (EULAs) whose terms attempt to prohibit such action under threat of legal action, reverse engineering is not legally prohibited. Consequently, the practice of modding closed game consoles/systems is often less focused on enabling players to achieve competitive advantage when playing retail computer games, but instead may encourage those few so inclined for how to understand and ultimately create computing innovations through reverse engineering or other modifications.

Closed game system modding is a style of software extension by game modders who are willing to forego the -protections‖ and quality assurances that closed game system developers provide, in order to experience the liberty, skill, knowledge acquisition, conceptual appropriation (-pwned‖), and potential to innovate, that mastery of reverse engineering affords. Consequently, players/modders who are willing to take responsibility for their actions (and not seek to defraud game producers due to false product warranty claims or copyright infringement), can enjoy the freedom to learn how their gaming systems work in intimate detail and to potentially learn about game system innovation through discovery and reinvention with the support of others like-minded [cf. 20]. Proprietary game development studios may sometimes allow for such mod-based infringement of their games. For example, the team of modders behind the hacking and conversion of the singleplayer CSS game, Grand Theft Auto, have produced an OSS (now GPL'd) game mod using code injection and hooking cheating methods to realize a networked multiplayer variant called Multi Theft Auto, that Rockstar Games has chosen not to prosecute for potential EULA violation, but instead to embrace as GTA fan culture [START_REF] Wen | Multi Theft Auto: Hacking Multi-Player Into Grand Theft Auto With Open Source[END_REF]. Nonetheless, large corporate interests may assert that their IP rights allow them to install CSS rootkits that collect potentially private information, or that prevent the reactivation of previously available OSS (e.g., the Linux Kernel on the Sony PS3 game console2 ) that game system hackers seek to undo.

Finally, games are one of the most commonly modified types of proprietary CSS that are transformed into -pirated games‖ that are -illegally downloaded.‖ Such game modding practice is focused on engaging a kind of meta-game that involves hacking into and modding game IP from closed to (more) open. Game piracy has thus become recognized as a collective, decentralized and placeless endeavor (i.e., not a physical organization) that relies on torrent servers as its underground distribution venue for pirated game software. As recent surveys of torrent-based downloads reveals, in 2008 the top 10 pirated games represented about 9M downloads, while in 2009 the top 5 pirated games represent more than 13M downloads, and in 2010 the top 5 pirated games approached 20M, all suggesting a substantial growth in interest in and access to such modded game products 3 . Thus, we should not be surprised by the recent efforts of game system hackers that continue to demonstrate the vulnerabilities of different hardware and software-based techniques to encrypt and secure closed game systems from would be crackers. However, it is also very instructive to learn from these exploits how difficult it is to engineer truly secure software systems, whether such systems are games or some other type of application or package.

Game Modding Software Tools and Support

Games are most often modded with tools providing access to unencrypted representations of game software or game platform. Such a representation is accessed and extended via a domain-specific (scripting) language. While it might seem the case that game vendors would seek to discourage users from acquiring such tools, a widespread contrary pattern is observed.

Game system developers are increasingly offering software tools for modifying the games they create or distribute, as a way to increase game sales and market share. Game/domain-specific Software Development Kits (SDKs) provided to users by game development studios represent a contemporary business strategy for engaging users to help lead product innovation from outside the studio. Once Id Software, maker of the DOOM and Quake game software product line, and also Epic Games, maker of the Unreal software game product line, started to provide prospective game players/modders with software tools that would allow them to edit game content, play mechanics, rules, or other functionality, other competing game development studios were pressured to make similar offerings or face a possible competitive disadvantage in the marketplace. However, the CSS versions of these tools do not provide access to the underlying source code that embodies the proprietary game engine-a large software program infrastructure that coordinates computer graphics, user interface controls, networking, game audio, access to middleware libraries for game physics, and so forth. But the complexity and capabilities of such a tool suite mean that any one person, or better said, any game development or modding team, can now access modding tools or SDKs to build commercial quality CSS games through OSS extensions. But mastering these tools appears to be an undertaking likely to be only of interest to highly committed game developers who are self-supported or self-organized.

In contrast to game modding platforms provided by game development studios, there are also alternatives provided by the end-user community. One approach can be seen with facilities provided in meta-mods like Garry's Mod or the AMX Mod X mod-making package. Modders can use these packages to construct a variety of plug-ins that provide for development of in-game contraptions as game UI agents or user created art works, or to otherwise create comic books, program game A different approach to end-user game development platforms can be found arising from OSS games and game engines. The DOOM and Quake games and game engines were released as free software subject to the GPL, once they were seen by Id Software as having reached the end of their retail product cycle. Thousands of games/engines, as already observed, have been developed and released for download. Some started from the OSS that was previously the CSS platform of the original games. However, the content assets (e.g., in-game artwork) for many of these CSS-then-OSS games are not covered by the GPL, and so user-developers must still acquire a licensed copy of the original CSS game if its content is to be reused in some way 4 . Nonetheless, some variants of the user-created GPL'd games now feature their own content that is limited/protected by Creative Commons licenses.

Opportunities and Constraints for Modding

Game modding demonstrates the practical value of software extension as a userfriendly approach to customizing software. Such software can extend games open to modding into diverse product lines that flourish through reliance on domain-specific game scripting languages, and integrated SDKs. Modding also demonstrates the success of end-users learning how to extend software to create custom user interface add-ons, system conversions, replayable system usage videos, as well as to discover security vulnerabilities. Game modding therefore represents a viable form of enduser engineering of complex software that may be transferable to other domains.

Modding is a form of OSS-enabled collaboration. It is collaboration at a distance where the collaborators, including the game developers and game users, are distant in space and time from each other, yet they can interact in an open but implicitly coordinated manner through software extensions. Comparatively little explicit coordination arises, except when CSS game developers seek to embrace and encourage the creation of OSS game mods that rely on the proprietary CSS game engine (and also SDK), as a way to grow market share and mid share for the proprietary engine as a viable strategy to entry into the game industry.

However, mods are vulnerable to evolutionary system version updates that can break the functionality or interface on which the mod depends. This can be viewed as the result of inadequate software system design practice, such that existing system modularization did not adequately account for software extensions that end-users seek, or else the original developer wanted to explicitly prohibit end-users from making modifications that transform game play mechanics/rules or unintentionally allow for modification or misappropriation of copy protected code or media assets.

Last, one the key constraints on game modding in particular, and software extension in general, are the rights and obligations that are expressed in the original software EULA. Mods tend to be licensed using OSS or freeware licenses that allow for access, study, modification, and redistribution, rather than using free software licenses (e.g., GPLv2 or GPLv3). Software extensions that might be subject to a reciprocal GPL style license require that the base/original software system incorporate an explicit software architectural design that requires the propagation of reciprocal rights across an open interface, except through an LGPL software shim [START_REF] Alspaugh | Intellectual Property Rights Requirements for Heterogeneously Licensed Systems[END_REF]. Otherwise, the scope of effectiveness and copyright protections of either free or non-free software (or related media assets) cannot be readily determined, and thus may be subject to copyright infringement or licenses non-compliance allegations. They may also be treated as social transgressions within a community of modders whose perceived ownership of the game mods demands respect and honor of a virtual license that may or may not be legally valid [START_REF] Alspaugh | Software Licenses in Context: The Challenge of Heterogeneously Licensed Systems[END_REF]. As the OSS community has long recognized, software rights and freedoms are expressed through IP licenses that insure whether or not a person has the right to access, study, modify, and redistribute the modified software, as long as the obligation to include a free software license is included that restates these rights in unalterable form, is included with the OSS code and its modified distributions.

Conclusions

Modding is emerging as a viable approach for mixing proprietary CSS systems with OSS extensions. The result is modded systems that provide the benefits of OSSD to developers of proprietary CSS systems, and to end-users who want additional functionality of their own creation, or from others they trust and seek to interact with through game play.

In contrast, modding is not so good for protecting software and media/content copyrights. Modding tests the limits of software/IP copyright practices. Some modders want to self-determine what copy/modding rights they have or not, and sometimes they act in ways that treat non-free software and related media as if it were free software. Who owns what, and which copy rights or obligations apply to that which is modded, are core socio-technical issues when engaging in modding.

This study helps to demonstrate that game modding is becoming a leading method for developing or customizing game software, whether based on proprietary CSS or OSS game systems. OSS-based software extensions are the leading ways and means for modding game-based user interfaces, converting games from one style/genre to another, for recording game play sessions for cinematic production and replay, and for hacking closed source game systems. Finally, the development of computer game software and tools itself represents a large community of OSS projects that has had comparatively little study, and thus merits further attention as its own cultural world as well as one for OSS development. This last consideration may be important as other empirical studies of OSS development that rely on data from SourceForge will increasingly include OSS game projects within large project samples. This study has therefore begun to address why and how these conditions have they emerged, and how are they put into practice in different game modding efforts. Future study should also consider whether and how modding might be applied and adopted in other application domains where CSS can be extended through OSS mods.

3 For 2008 ,

 32008 see http://torrentfreak.com/top-10-most-pirated-games-of-2008-081204/ For 2009, http://torrentfreak.com/the-most-pirated-games-of-2009-091227/ For 2010, http://torrentfreak.com/call-of-duty-black-ops-most-pirated-game-of-2010-101228/ conversions, and produce other kinds of user created content. But both packages require that you own a licensed CSS game like Counter-Strike: Source, Half-Life2 or Day of Defeat: Source from Valve Software.

See http://www.sourceforge.net/softwaremap/index.php, accessed 15 April

The number one category of projects is for -Development‖ with more than 65K OSS projects, out of 210K projects. So OSS Development and OSS Games together represent half of the projects currently hosted on SourceForge.

For details, see http://en.wikipedia.org/wiki/George_Hotz#Hacking_the_PlayStation_3 .

For example, see http://assault.cubers.net/docs/license.html, accessed 13 April 2011.

Acknowledgments

The research described in this paper has been supported by grants #0808783 and #1041918 from the National Science Foundation, and grant #N00244-10-1-0077 from the Naval Postgraduate School. No review, approval or endorsement implied. The anonymous reviewers also provided helpful suggestions for improving this paper.