ABSTRACT

Innovation in the FLOSS con text has been ana lyzed based on several per spect­ ives: some studies have investigated the innov at iveness of the FLOSS products (product in nova tion), others the innov at iveness of the software de velopment pro­ cess (pro cess in nova tion), or of the business model (organ iza tional in nova tion) and/or the con sequences associated with the de velopment of the FLOSS licenses (institutional in nova tion). Consistent with the aim of the chapter, an overview of the first two per spect ives is reported below. The results of research on the innov at iveness of the FLOSS products are con­ trasting. FLOSS seems to be more innov at ive than proprietary software (Lorenzi & Rossi, 2007). However, in a sample of 500 FLOSS pro jects, Klincewicz

(2005) identifies only 64 innov at ive products, just five of which are clas si fied as rad ical innovations. The FLOSS de velopment pro cess is con sidered a “disruptive in nova tion” (Dalle et al., 2007). The de velopment is based on what Benkler (2002) defines as a form of “common based peer production”, named by von Krogh and von Hippel (2003) as the “private­ collective” model of in nova tion, wherein “de velopers obtain private rewards from writing code for their own use, sharing their code and col lect ively con trib ut ing to the de velopment and improvement of software”. The FLOSS de velopment model is thus proposed as a third in nova­ tion model, after private investments and the col lect ive action model, able to capture a combination of the ad vant ages associated with the other models. The specific pro cesses carried out within FLOSS pro jects can be clas si fied as indi vidual and group pro cesses (Crowston, 2007). Individual pro cesses mostly deal with software de velopment, and usually involve planning (although most teams do not plan at all), requirements ana lysis, coding, release, maintenance and pro ject management. Group pro cesses involve member recruitment, sociali­ zation, decision­ making, co ordination, cohesion/group maintenance, conflict res­ olu tion and field sup port. Only a minor part of the indi vidual pro cesses is pub lic (Crowston & Scozzi, 2008; Howison, 2009; von Krogh et al., 2003). The private ones, which also are the most time­ consuming and those that require more effort, are not vis ible to the com mun ity/external ob ser vers. A rel ev ant example is repres ented by the know ledge acquisition/learning pro cess. Although the source code and most of the communication exchanged among de velopers is pub lic, the specific expertise needed to create and further improve the code, as well as some pro ject values and the cri teria the de velopment is based on, are (usually) mostly private to de velopers and comprise the pro ject implicit know ledge (Grand et al., 2004). Lakhani and von Hippel (2003), who studied the field sup port pro cess in depth, found that learning is the first mo tiva tion1 to take part in FLOSS pro jects and the only one able to explain why de velopers accept carrying out mundane work (such as field sup port). Hemetsberger and Reinhardt (2004), based on a case study on the KDE pro ject, investigated the pro cess of know ledge cre ation and sharing in FLOSS pro jects. They found that re­ experience within the teams is enabled by the use of technologies and task­ related features (e.g. CVS, modular structure of software, comments on source code by programmers, mailing lists), guidance, openness and legitimate peripheral parti cipa tion, as well as by the adoption of asynchronous communication and ritual experimentation. Such elements allow the cre ation of a transactive group memory. Group mainte­ nance is another pro cess by which, in the attempts to reduce the effect of the scarce geographical, cultural and social proximity, the teams try to augment the cognitive proximity among pro ject members. Such a pro cess, unlike what is usually thought, is often accomplished by face­ to­face meetings – examples of what Torre (2008) refers to as “tem poral geographical proximity”. Different types of conferences and ad hoc meetings exist to achieve that aim (e.g. Apa­ cheCon, Comdex, PloneCon, OSCon, OSDC, Ottawa Linux Symposium, Debi­ anConf ). Face­ to­face meetings are rarely based on a detailed agenda, being

specifically devoted to socialization, team­ building and training, rather than working. Usually they happen in the course of the pro ject, rather than at its start as is typical of traditional pro jects (kick­ off meetings). Interestingly, not all de velopers meet at once (Crowston, 2007). To assess the success of in forma tion sys tems, different models are proposed in the liter at ure, the most cited being in DeLone and McLean (2003). Based on that model, Crowston et al. (2006) identified a range of meas ures and indic ators to specifically assess the success of FLOSS pro jects. Measures include sys tem and in forma tion quality (e.g. code quality, docu mentation quality), use (e.g. number of users, downloads, re­ use of code), user satis fac tion (e.g. user ratings), indi vidual and organ iza tional impacts (e.g. eco nomic im plica tions), pro ject output (e.g. de veloper satis fac tion), pro cess (e.g. number of de velopers, time between releases), outcomes for pro ject members (e.g. know ledge cre ation and indi vidual reputation), re cog ni tion (i.e. mention on other sites), and involvement of the users and porting of the pro ject output to different systems.