howison i conf-transition

20
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)

Upload: james-howison

Post on 17-Jul-2015

211 views

Category:

Science


0 download

TRANSCRIPT

Sustaining scientific infrastructures: transitioning from grants to peer production

James HowisonSchool of Information

University of Texas at Austin3 March 2015

@jameshowison(slides on slideshare, see twitter for link)

@jameshowison

"Carole Goble by Rob Whitrow (15682291039)" by Computer Science Manchester - Carole Goble by Rob Whitrow.

Extension needs up-to-date code

@jameshowison

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

Just open source it!

(How hard can it be???)

@jameshowison

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

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

How can scientific software projects successfully transition from grant support to thriving peer

production communities?

Research Design:

theoretically sampled case studies

@jameshowison

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

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

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

ENZO@jameshowison

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

@jameshowison

• No central base to which changes are coming and going• Copy and pasting features across personal branches• Single lab

@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”

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

@jameshowison

• Central branch to which both core and outsiders contribute• Development continues separately in external labs• Called “Wild West” by participants, autonomy concerns.

@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”

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

What worked

• Always: collaboration technology beforegovernance (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