Article Preview
TopIntroduction
With the increasing popularity of open source software such as Mozilla Firefox, Linux, Apache, and mySQL in the business world, open source software is attracting more and more attentions in the academic community as well (Xu et al., 2011; Aksulu and Wade, 2010; Crowston and Scozzi, 2008). Advocates of open source software development argued that it could improve software product quality, encourage software evolution and innovation, and enhance business values (Mehra and Mookerjee, 2012; Allen, 2012; Shaikh and Cornford, 2012; Chengalur-Smith, Nevo and Demertzoglou, 2010; Amrit, 2009; Brydon and Vining, 2008; Long and Siau 2005, 2006, 2007, 2008; Long et al., 2007; Raymond, 2001; O’Reilly, 1999;). Among others, one key advantage of open source software is its assumed high quality due partly to the intensive peer review or “many eyeballs”. Members of the open source communities give direct, specific and immediate feedback to the software code written by others. All members have access to the source code and can submit code patches. This software development model is called “Bazaar” model by Raymond (2001). Traditional cathedral models (Raymond, 2001) of information system development are in short of second party review. OSSD, or parallel development through Internet (Krogh, 2003), has practically been proven to be a very successful counterstrategy to this problem.
Although this “Bazaar” model of OSSD (Open Source Software Development) naturally encourages innovation and software evolution, it also causes some problems. Requirements analysis and conceptual modeling of the problem domains are issues (e.g., see Chua et al., 2012; Bucher and Diner, 2012; Chan et al. 2012; Poels 2011; Edwards and Sridhar, 2005). The virtual environment (e.g., Nath et al., 2008) and motivation of team members (e.g., Liu et al. 2010) need to be addressed too. Also, lacking of conformity and unstructured project management tends to decrease the survivability of the OSSD project. In OSSD, there are no formally documented norms or customs except for the implied customs and taboos learned through experience, not to mention any comprehensive development process guidelines. Cusumano (2004) believed that many OSSD projects are “semi-organized chaos”. The state of affairs of OSSD urgently calls for an increased understanding of the unique OSSD process and the development of OSSD process models to help guide OSSD project management.
The nature of OSSD projects is dynamic. Collaborations in OSSD are extraordinary, which makes a systematic software development process very imperative. The unique features of OSSD imply that many existing standardized or quasi-standardized software development processes such as CMM (Capability Maturity Model) and UP (Unified Process), cannot be readily applied to OSSD.