Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Howison rutgers-open superposition


Published on

Presentation on research on the organization of open source software production, describing the theory of open superposition.

Published in: Science
  • Be the first to comment

  • Be the first to like this

Howison rutgers-open superposition

  1. 1. James Howison Collaboration through Open Superposition: A theory of the open source way CC Credit: Rutgers LIS Lecture Series 14 April 2015 Work supported by the NSF 03-41475, 04–14468, 05-27457 and 07–08437 @jameshowison
  2. 2. “Let’s do this the open source way?” Sounds great, right? Lots of people volunteering for the enjoyment of it, working together, sharing stuff, meritocracy, contributing stuff, fighting the man, all without raising money or top- down management. Open innovation, open platforms, open hardware, open data, open government, open NASA, citizen science … @jameshowison
  3. 3. CCCredit: @jameshowison
  4. 4. CC Credit: @jameshowison
  5. 5. What ought we learn from Open Source? • Highly successful distributed work – In surprising circumstances: highly interdependent work, many failures, at distance, while working with unreliable volunteers! • Literature focuses on what Rousseau et al. 2006 call teamwork rather than taskwork • e.g., Agerfalk and Fitzgerald 2008; von Krogh and von Hippel 2003; Scacchi et al. 2006; Stewart and Gosain 2006 • Less study of what they are working on, despite the importance of technology to Information Systems – Technology as “work in progress” Orlikowski and Iacono (2001) – Only small number of studies examining what is built (Zammuto et al. 2007, Malhotra and Majchrzak 2012) @jameshowison
  6. 6. Outsourcing to an unknown workforce? (Agerfalk and Fitzgerald @jameshowison
  7. 7. A research arc for theory development • Participant Observation – one case – live participation and observation • Replication – two cases chosen by replication logic – Archival study • Theory development – Develop theory and demonstrate it’s usefulness @jameshowison
  8. 8. Goal: An image of FLOSS production CC Credit: @jameshowison
  9. 9. Discovery through Participant Observation @jameshowison
  10. 10. Task: The Container Column @jameshowison
  11. 11. How it was built @jameshowison
  12. 12. BibDesk 2.0? @jameshowison
  13. 13. CC Credit: l-libdev/5140646741/ @jameshowison
  14. 14. Task: “Web Groups” June 2003 (Email) I really want to use this, but the conditions have never quite been right - either I was waiting for … RSS+RDF (now looks like it'll never happen) or … an XML bibliographic file format … (could happen now, but I ran out of free time). @jameshowison
  15. 15. What didn’t happen Image Credit: marketing materials @jameshowison
  16. 16. Task: “Web Groups” June 2003 (Email) I really want to use this, but the conditions have never quite been right - either I was waiting for … RSS+RDF (now looks like it'll never happen) or … an XML bibliographic file format … (could happen now, but I ran out of free time). Jan 2007 (Email with patch): It was much easier than I expected it to be because the existing groups code (and search groups code) was very easy to extend. Kudos - I wouldn't have tried it if so much hadn't already been solved well. Thanks! @jameshowison
  17. 17. Discovery Findings 1. Individual work with personal motivations 2. Superposition of layers 3. Productive Deferral CC Credit: @jameshowison
  18. 18. But that’s just one case! (and what’s the point of theorizing about idiosyncratic situations?) @jameshowison
  19. 19. To the Archives! The evidence is here, somewhere. CC Credit: photos/hamadryades/ @jameshowison
  20. 20. Replication: Fire and Gaim • Specific RQs: – What proportion of work was individual? – Any evidence of “productive deferral”? • Fire and Gaim – Multi-protocol instant messaging clients – Community-based open source – Similar task and collaboration infrastructure to BibDesk @jameshowison
  21. 21. Tasks: changes to shared outcomes Version Number Headings and Indenting Bullet Points Developer Initials Tracker Numbers @jameshowison
  22. 22. Release Notes Dev Email Bug Tracker RFE TrackerUser Forum TaskOutcome Task Relevant Documents TaskOutcome Task Relevant Documents TaskOutcome Task Relevant Documents CVS Search and assign Relevant Documents @jameshowison
  23. 23. Illustrative Co-work @jameshowison
  24. 24. Illustrative Individual Work 30 (of 106) tasks consisted of a single Action: Core Production@jameshowison
  25. 25. Tasks were individual @jameshowison
  26. 26. Evidence for Deferral @jameshowison
  27. 27. Deferral • E.g. Fire Task 9: – March 2003 • a user requests that the away message only be sent when it changes. • one of the developers assigns the request to himself, indicating acceptance of this as a desirable feature. – October 2003 • Different developer re-assigns the feature to himself and says, • This is possible now with the `once' option for how often to send away messages. We just need to reset the message count when changing state.... I think I have a fix for this... probably will check it in the next week or so. • Fix checked in @jameshowison
  28. 28. An image of FLOSS production: Open Superposition • Work is done in Tasks that are – Individual – Short – Layered • Complex work is often deferred – Until it is easier (doesn’t always happen!) Other types of work build on this base @jameshowison
  29. 29. A model of software development @jameshowison
  30. 30. Superposition Reference Display Time 1 Reference Display Container Column Time 3Dev Time Container Column @jameshowison
  31. 31. Missing step in Complex Work RSS+RDF Web Groups XML or RSS+RDF Web Groups Time 1 Time 3Dev Time (one not both) ? @jameshowison
  32. 32. Multi-person interdependent work ("Co-work") Time 1 RSS+RDF Time 3 RSS+RDF Web Groups Web Groups Interpersonal dependency Dev Time Undermines self locus of control, autonomy and, since failure of one is failure of all, anticipation of payoffs. @jameshowison
  33. 33. Productive Deferral Dev TimeTime 1 Deferral Time (2 years)…… Reconsideration Time n Groups Search Search Groups Independent superposition continues, resulting in: Web Groups Groups Search Search Groups Web Groups @jameshowison
  34. 34. Theorizing 1. Why are these patterns of work observed? 2. How can complex software result from this way of working? 3. Under what socio-technical contingencies is this likely to be successful? @jameshowison
  35. 35. Motivation and Experience • Ke and Zhang (2010) based on Ryan and Deci (2000). Highest effort from: 1. Anticipated payoffs (extrinsic or intrinsic) 2. Locus of regulation (self over other) 3. Positive affect (autonomy, competence and relatedness) Individual tasks in shared volunteer environment match extremely well @jameshowison
  36. 36. Why these patterns of individual work and deferral? • Fewest dependencies, lowest coordination challenges and costs • Closest match to motivational situation of FLOSS participants. – Increases autonomy without eliminating relatedness @jameshowison
  37. 37. Ok, but can this really work? • Software development is highly complex, interdependent, work (e.g., Herbsleb et al. 2001)) • Can such simple steps really get the job done? @jameshowison
  38. 38. Imagine trying to plan this 1. Identify desired outcomes (design) 2. Design a task sequence that reaches them 3. Find people who are: – Motivated to do each task – Able to do each task – At just the right time Crippling search costs! @jameshowison
  39. 39. Application-led search • Openness and availability of application • Task identification through situated use (e.g., Suchman 1987) “Porches fill in by stages, not all at once, you know. ... it happens that way because [the family] can always visualize the next stage based on what’s already there” (Brand 1995, quoting an architect) @jameshowison
  40. 40. But why does deferral make things easier? • Layered tasks makes deferral more likely to be productive • Small layers can compose in different ways. They provide option value. (e.g., Baldwin and Clark 2001) • Small layers are easier to understand, especially over time. (e.g., Dabbish, 2011; Boudreau at al 2011) @jameshowison
  41. 41. @jameshowison
  42. 42. Contingencies for Open superposition • Attributes of object of work – Layerability – Low instantiation costs – Low distribution costs • Irrevocable openness • Time @jameshowison
  43. 43. Layers vs Steps CC Credit: 6136724/ CC Credit: 997160501/ @jameshowison
  44. 44. Irrevocable openness Free and Open Source Licenses prevent this. CC Credit: 0/5637893667/ @jameshowison
  45. 45. Time == Money CC Credit: 600562651/ This guy hates to wait @jameshowison
  46. 46. What to learn from FLOSS? • Much excitement about FLOSS about easing interdependent collaboration – Studies of leadership, governance, technologies (e.g. CVS), culture, processes … • What if the “something else” is simpler than that? @jameshowison
  47. 47. Redesigning work for Superposition • Irrevocable openness (licenses) – Ensure the “rug” can’t be pulled from under • Open access for situated searching – How can we conduct the widest search to match interests and motivations? • Layerable artifact with independent payoffs – Can we build up small contributions? • Time – the hardest aspect of all? – How long can we wait for success? @jameshowison
  48. 48. New research: Open superposition in Scientific Software? • Similarities: – Software and a culture of openness – Use-value motivation and open search • Differences: – Limited userbase – Grant funding is a kind of investment – Academic reputation as motivation discourages integration • New NSF CAREER grant to study transitions from grants to peer production – Six initial case studies, then panel study of SISI NSF program @jameshowison
  49. 49. Open Superposition Howison, J., & Crowston, K. (2014). Collaboration through open superposition: A theory of the open source way. MIS Quarterly, 38(1), 29–50. @jameshowison