Update literature-review-research-on-usability-and-open-source-softwa…

…re.md

tippo: Brook’s to Brooks’s

USER Findings by chapter/Literature Review/literature-review-research-on-usability-and-open-source-software.md

@@ -20,7 +20,7 @@ Usability experts are rarely involved in open source projects (Raza, Caprez 2012
 Open Source projects are often defined as communities of developers or hackers. This can be already found in Reymond’s “The Cathedral and the Bazaar” in which he suggests “Treating your users as co-developers”. As Bødker describes: “the strong sense of emotional belonging that the community commands tends to preclude the possibility of seeing beyond their own motivations.” Raymond also claims that “given enough eyeballs, all bugs are shallow.” which Nicols refers to when saying: “The OSS approach fails for end user usability because there are 'the wrong kind of eyeballs' looking at, but failing to see, usability issues.” Dunguid points out that the principle, even within software development, only focuses on fixing bugs, not on other aspects of development. Despite these limits to apply developer’s methods to non-code creations, Rajanen (2015) notes that skills in programming can help to get design improvements accepted.
 
 **Modularity, Coherence, Architecture**
-A commonly cited aphorism by “Brook’s Law” suggests that adding more developers to a delayed project will delay it more (Ch.2 of  “The Mythical Man-Month”: “Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later.”). Open Source projects allow parallel development and seem to avoid this problem (Nicols 2002, Feller, Fritzgeralt 2001, p 85; Raymond CatB, Ch ”How Many Eyeballs Tame Complexity”). However, this mode of collaboration demands modularity (Benkler 2002). Not all products can be worked on with such a peer-production approach, since they might not be easily modularized without sacrificing essential traits; Benkler suggests that e.g. “Novels…are likely to prove resistant to peer production”; Dunguid, too, shows that other modes of production might also run into problems, even if they already use a mode of peer-production (e.g. Wikipedia). Dunguid suggests that software production, particularly the fixing of bugs, might be a mode that works very well in peer production but the principles of it might not easily transfer to other media. Hill and Monroy-Hernández 2013 evaluate the claim that peer production improves the quality for results empirically. They find that the artistic quality of computer games does not benefit from peer production.
+A commonly cited aphorism by “Brooks’s Law” suggests that adding more developers to a delayed project will delay it more (Ch.2 of  “The Mythical Man-Month”: “Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later.”). Open Source projects allow parallel development and seem to avoid this problem (Nicols 2002, Feller, Fritzgeralt 2001, p 85; Raymond CatB, Ch ”How Many Eyeballs Tame Complexity”). However, this mode of collaboration demands modularity (Benkler 2002). Not all products can be worked on with such a peer-production approach, since they might not be easily modularized without sacrificing essential traits; Benkler suggests that e.g. “Novels…are likely to prove resistant to peer production”; Dunguid, too, shows that other modes of production might also run into problems, even if they already use a mode of peer-production (e.g. Wikipedia). Dunguid suggests that software production, particularly the fixing of bugs, might be a mode that works very well in peer production but the principles of it might not easily transfer to other media. Hill and Monroy-Hernández 2013 evaluate the claim that peer production improves the quality for results empirically. They find that the artistic quality of computer games does not benefit from peer production.
 
 **Media, Communication, Coordination**
 To coordinate large projects, one might assume that roadmaps, design documents and other artifacts might play an important role in defining requirements of the software. However, such artifacts are not very prominent in many open-source projects (Alspaugh/Sacci). The coordination happens in forums and mailing lists (Bødker, Alspaugh/Sacci) in ongoing deliberation. Additionally, the code itself is a resource for structuring collaboration (Bolici et.al. 2016). The coordination via ongoing communication and working on code is different from the common modes of working for designers, who often coordinate via representations of users and future products (Dix 2011 or Bødker 1998 for a general overview, but also Wilkie, 2010; Akrich 1995;) That many typical representations for UX work are absent in open source projects is also noted by Benson et.al., pointing out that both user profiles and representations of the work process for designers don’t exist in the project they analyzed.