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 i conf-transition


Published on

Transitions from grant funding to peer production for scientific software

Published in: Science
  • Be the first to comment

  • Be the first to like this

Howison i conf-transition

  1. 1. Sustaining scientific infrastructures: transitioning from grants to peer production James Howison School of Information University of Texas at Austin 3 March 2015 @jameshowison (slides on slideshare, see twitter for link)
  2. 2. @jameshowison "Carole Goble by Rob Whitrow (15682291039)" by Computer Science Manchester - Carole Goble by Rob Whitrow.
  3. 3. Extension needs up-to-date code @jameshowison
  4. 4. Supporting mid-range infrastructures • How ought we to support the continuous development of mid-range scientific infrastructures? • What happens when the grant ends? – It’s hard, hard work to keep the code from inevitable “bit-rot” @jameshowison
  5. 5. Just open source it! (How hard can it be???) @jameshowison
  6. 6. Open projects are not like grants 1. Governance 2. Collaboration infrastructures 3. Contribution processes 4. Service center vs. Base for community “open sourcing” means full-on sociotechnical change @jameshowison
  7. 7. A literature on transfer to open? • Copious literature on commercialization, “Technology Transfer” • Happily, promising literatures – Studies of open source and online communities (Resnick, Crowston, Wiggins, Kittur, Kraut, Lampe, Ellison, …) – Studies of scientific practice (Palmer, Borgman, Vertesi, Edwards, Olsons, Finholt, Lee/Bietz, Østerlund, Sawyer, Tapia, Ludders, …) – Studies of infrastructural work (Bowker, Jackson, Vertesi, Ribes, …) @jameshowison
  8. 8. How can scientific software projects successfully transition from grant support to thriving peer production communities? Research Design: theoretically sampled case studies @jameshowison
  9. 9. Questions for each case: How did they succeed or fail in building peer production? – What actions were taken to change the project? – How did routines in the project change as a result? – What conditions are relevant to the success of those actions in causing change? @jameshowison
  10. 10. Sampling success and failure • Very hard to have people talk about failures – Records are often unavailable – Constant problem in studies of open source • I’m going to try a panel study – Enroll early, before outcome clear – Build trust, chart course, keep records – Selected the NSF SI2 funding program (program officer support) @jameshowison
  11. 11. Method: analysis • Identify work episodes – Ground interviews in specific production work. – Source-code repositories help immensely – “Digital trace ethnography” (Ribes and Geiger) • Identify socio-technical changes that divide project into stages – Investigate actions that precipitated changes • Project Narratives with illustrative vignettes @jameshowison
  12. 12. ENZO @jameshowison
  13. 13. ENZO pilot study Data: • 5 interviews, so far (thanks Eunyoung Moon!) • Publications, websites, workshop websites, source code repositories • Analysis: – Creation of timeline – Identification of episodes and 4 project phases (with their precipitating events) @jameshowison
  14. 14. @jameshowison • No central base to which changes are coming and going • Copy and pasting features across personal branches • Single lab
  15. 15. @jameshowison • ENZO lab reforms as “Service Center” (grant) • Mainline branch internally, releases externally • Little expectation of contributions coming back in • “Friendly user” labs internally functioning like “early days”
  16. 16. The “Week of Code” • Director of external lab (former post-doc) has new job at Stanford (with startup funds!) • Learns of various versions through conversations at conferences and reviewing(!) • Focus is on collaboration infrastructure, not governance. • Begin with the code of those not present @jameshowison
  17. 17. @jameshowison • Central branch to which both core and outsiders contribute • Development continues separately in external labs • Called “Wild West” by participants, autonomy concerns.
  18. 18. @jameshowison • Introduction of “code revision” (pull requests) • External lab members on similar footing to Core members • Review helps members not “step on each other’s work”
  19. 19. Change • What hasn’t changed: – Motivations (code is side-effect of scientific inquiry, papers first, code second), no commercial value • Challenges to change – Leadership’s emotional connection, difficulty of passing on leadership. – Giving up autonomy (being “blocked” in one’s work) @jameshowison
  20. 20. What worked • Always: collaboration technology before governance (contra “Collaboration Readiness” (Olson et al.) TORSC?). • Social proof: visible action in public • Inspiration from open source • Working alongside, rather than with. Superposition rather than Teamwork. @jameshowison